Passwd

[Java] Jackson - ArrayNode 다루기

비번변경 — Mon, 13 Apr 2026 16:38:13 +0900

개요

Jackson에서 다루는 JsonNode, ObjectNode는 기본적으로 단일 JSON 데이터를 취급한다. 하지만 JSON 데이터는 Array도 지원하고 있다. 때문에 이번 글에서는 Java에서 JSON Array를 다룰 때 사용하는 ArrayNode에 대해 알아본다.

ArrayNode

ArrayNode는 Jackson 라이브러리에서 JSON 배열([...])을 표현하는 클래스이다. ObjectNode와 동일하게 JsonNode의 자식 클래스이고, 불변성을 가진 JsonNode와 다르게 데이터의 추가와 수정이 가능하다.

사용법

생성 및 요소 추가

생성은 ObjectNode와 같이 ObjectMapper.createArrayNode를 사용하고, 값 추가는 add 함수를 사용한다.

아래는 ArrayNode를 생성하고 기본 데이터 타입, ObjectNode, ArrayNode를 추가하는 예시 코드이다.

import com.fasterxml.jackson.databind.ObjectMapper;
import com.fasterxml.jackson.databind.node.ArrayNode;
import com.fasterxml.jackson.databind.node.ObjectNode;

public class main {
    public static void main(String[] args) {
        ObjectMapper objectMapper = new ObjectMapper();
        ArrayNode arrayNode = objectMapper.createArrayNode();
        
        // 기본 타입 추가
        arrayNode.add("text");
        arrayNode.add(42);
        arrayNode.add(3.14);
        arrayNode.add(true);
        arrayNode.addNull();
        
        // ObjectNode 중첩
        ObjectNode obj = objectMapper.createObjectNode();
        obj.put("name", "passwd");
        arrayNode.add(obj);

        // ArrayNode 중첩
        ArrayNode inner = objectMapper.createArrayNode();
        inner.add(1).add(2).add(3);
        arrayNode.add(inner);
        
        System.out.println(arrayNode);
    }

직렬화

기존과 동일하게 objectMapper.writeValueAsString를 사용한다.

import com.fasterxml.jackson.core.JsonProcessingException;
import com.fasterxml.jackson.databind.JsonNode;
import com.fasterxml.jackson.databind.ObjectMapper;
import com.fasterxml.jackson.databind.node.ArrayNode;
import com.fasterxml.jackson.databind.node.ObjectNode;

public class main {
    public static void main(String[] args) {
        ObjectMapper objectMapper = new ObjectMapper();
        ArrayNode arrayNode = objectMapper.createArrayNode();
        
        // 생략

        try {
            System.out.println(objectMapper.writeValueAsString(arrayNode));
        } catch (JsonProcessingException e) {
            throw new RuntimeException(e);
        }
    }
}

요소 접근

ArrayNode 요소에 접근할 때는 get, path를 사용한다. 배열과 동일하게 인덱스로 접근하면 된다.

import com.fasterxml.jackson.core.JsonProcessingException;
import com.fasterxml.jackson.databind.JsonNode;
import com.fasterxml.jackson.databind.ObjectMapper;
import com.fasterxml.jackson.databind.node.ArrayNode;
import com.fasterxml.jackson.databind.node.ObjectNode;

public class main {
    public static void main(String[] args) {
        ObjectMapper objectMapper = new ObjectMapper();
        ArrayNode arrayNode = objectMapper.createArrayNode();

        // 기본 타입 추가
        arrayNode.add("text");
        arrayNode.add(42);
        arrayNode.add(3.14);
        arrayNode.add(true);
        arrayNode.addNull();
       
        System.out.println(arrayNode.get(0));
        System.out.println(arrayNode.get(0).asText());
        System.out.println(arrayNode.path(1));
        System.out.println(arrayNode.path(1).asInt());
    }
}

역직렬화

역직렬화할 때는 ObjectNode와 동일하게 JsonNode로 역직렬화한 뒤 ArrayNode로 형변환해야 한다.

import com.fasterxml.jackson.core.JsonProcessingException;
import com.fasterxml.jackson.databind.JsonNode;
import com.fasterxml.jackson.databind.ObjectMapper;
import com.fasterxml.jackson.databind.node.ArrayNode;
import com.fasterxml.jackson.databind.node.ObjectNode;

public class main {
    public static void main(String[] args) {
        ObjectMapper objectMapper = new ObjectMapper();
        String json = "[1, 2, 3]";

        try {
            JsonNode jsonNode = objectMapper.readTree(json);
            ArrayNode arrayNode = (ArrayNode) jsonNode;
            arrayNode.add(0);
            System.out.println(arrayNode);
        } catch (JsonProcessingException e) {
            throw new RuntimeException(e);
        }
    }
}

참고 문서

https://yeonyeon.tistory.com/136

https://getthismoment.tistory.com/82

[Java] Jackson - ObjectNode 다루기

비번변경 — Fri, 10 Apr 2026 11:26:09 +0900

개요

2026.04.08-[Java] Jackson - JsonNode 다루기에서 JSON 데이터를 다루기 위한 기본적인 클래스인 JsonNode에 대해 알아보았다. 하지만 JsonNode는 불변 객체로 값 수정을 할 수 없기 때문에 값을 수정하거나 추가하는 등의 작업을 수행하기에는 적합하지 않다. 이런 경우를 위해 Jackson은 ObjectNode라는 클래스를 제공한다.

사용법을 알아보자.

ObjectNode

Jackson의 ObjecNode는 JSON 객체를 Java 코드 상에서 동적으로 생성, 수정, 삭제할 수 있는, 즉 변경 가능한(Mutable) JsonNode 하위 클래스다. 빈 ObjecNode를 생성하여 put, set과 같은 메서드로 키와 값을 추가할 수 있어 유영한 데이터 조작이 필요할 때 사용한다.

사용법

먼저 ObjectNode를 생성하여 값을 추가한 뒤, 직렬화해 보겠다. 빈 ObjectNode는 ObjectMapper.createObjectNode로 생성하고, put을 사용해 값을 추가한다.

import com.fasterxml.jackson.core.JsonProcessingException;
import com.fasterxml.jackson.databind.ObjectMapper;
import com.fasterxml.jackson.databind.node.ObjectNode;

public class main {
    public static void main(String[] args) {
        ObjectMapper objectMapper = new ObjectMapper();

        ObjectNode root = objectMapper.createObjectNode();
        root.put("name","John");
        root.put("age", 20);

        try {
            System.out.println(objectMapper.writeValueAsString(root));
        } catch (JsonProcessingException e) {
            throw new RuntimeException(e);
        }

    }

다음으로 역직렬화를 해보자. JSON 문자열을 ObjectNode로 변환할 때는 JsonNode를 거쳐야 한다. 때문에 ObjectMapper.readTree로 JsonNode 객체를 얻은 뒤, ObjectNode로 형변환하여 사용하면 된다.

아래 코드는 JSON 문자열을 ObjectNode로 변환하여 값을 추가한 예시다.

import com.fasterxml.jackson.core.JsonProcessingException;
import com.fasterxml.jackson.databind.JsonNode;
import com.fasterxml.jackson.databind.ObjectMapper;
import com.fasterxml.jackson.databind.node.ObjectNode;

public class main {
    public static void main(String[] args) {
        String json = "{\"name\":\"Passwd\",\"age\":30}";

        // ObjectMapper 생성
        ObjectMapper objectMapper = new ObjectMapper();
        JsonNode jsonNode = null;
        try {
            jsonNode = objectMapper.readTree(json);

            // JsonNode -> JsonNode
            ObjectNode node = (ObjectNode) jsonNode;
            
            // 값 추가
            node.put("sex", "male");
            System.out.println(node);
        } catch (JsonProcessingException e) {
            throw new RuntimeException(e);
        }
    }
}

참고 문서

https://yeonyeon.tistory.com/136

https://dejavuhyo.github.io/posts/java-jackson-jsonnode-objectnode/

https://getthismoment.tistory.com/82

[Java] Jackson - JsonNode 다루기

비번변경 — Wed, 8 Apr 2026 10:18:11 +0900

개요

2026.04.07-[Java] Jackson - JSON 문자열을 Map으로 변환에서 JSON 문자열을 Java Map으로 변환하는 방법을 살펴봤는데, 이 방식에는 타입 안정성이 낮다는 한계점이 존재한다. 때문에 DTO(Data Transfer Object)를 생성하지 않고 데이터를 Java 객체로 변환할 때에는 일반적으로 좀 더 안정적인 JsonNode를 활용한다.

이번 글에선 JsonNode에 대해서 알아보려고 한다.

JsonNode

Jackson이 제공하는 불변 추상 클래스로, JSON 데이터를 트리 구조로 다루기 위해 제공한다. DTO 정의 없이 유연하게 데이터에 접근하고, 복잡한 JSON 구조를 탐색하고 가공할 때 적합한다.

특징

- 트리 기반 : JSON 데이터를 노드 단위로 표현하여 구조 파악에 용이하다.

- 유연성 : DTO나 Map과 다르게 JSON 구조가 유동적이고 명확하지 않을 때 필드 존재 여부와 타입을 확인하여 안전하게 값을 처리할 수 있다.

- 불변성 : 데이터 추가, 수정할 수 없다.

- 타입 : 문자열, 숫자, Boolean, 배열, 객체 등 다양한 JSON 데이터 형식을 표현한다.

사용법

JSON 문자열을 JsonNode로 변환할 때에는 기존에 Map과 DTO로 변환했던 것과 다르게 ObjectMapper.readTree를 사용한다.

import com.fasterxml.jackson.core.JsonProcessingException;
import com.fasterxml.jackson.databind.JsonNode;
import com.fasterxml.jackson.databind.ObjectMapper;

public class main {
    public static void main(String[] args) {
        String json = "{\"name\":\"Passwd\",\"age\":30}";

        // ObjectMapper 생성
        ObjectMapper objectMapper = new ObjectMapper();

        JsonNode node = null;
        try {
            node = objectMapper.readTree(json);
        } catch (JsonProcessingException e) {
            throw new RuntimeException(e);
        }
        System.out.println(json);
        System.out.println(node);
        System.out.println(node instanceof JsonNode);
    }
}

JsonNode를 문자열로 출력하면 JSON 문자열과 동일한 결과가 나온다.

값 읽기

특정 키의 값을 읽을 때는 get 또는 path를 사용한다.

System.out.println(node.path("name"));
System.out.println(node.path("name").asText());
System.out.println(node.get("name"));
System.out.println(node.get("name").asText());

직렬화

JsonNode를 다시 직렬화하는 방법은 기존과 동일하다. 이 때 writerWithDefaultPrettyPrinter를 사용하면 들여쓰기와 개행이 포함된 문자열을 얻을 수 있다.

System.out.println(objectMapper.writeValueAsString(node));

// pretty string
System.out.println(objectMapper.writerWithDefaultPrettyPrinter().writeValueAsString(node));

참고 문서

Spring API에서 JSON 요청은 Map, DTO, JsonNode 중 무엇으로 받아야 할까?

Java JsonNode get과 path 차이

[Java] Jackson - JSON 문자열을 Map으로 변환

비번변경 — Wed, 8 Apr 2026 10:11:51 +0900

개요

2026.04.06-[Java] Jackson - JSON 다루기에서 JSON 문자열과 Java 객체 간에 데이터 변환 수행 방법을 알아보았다. 다만 이 방법은 데이터 모델 클래스를 별도로 만들어주어야 한다는 번거로움이 있다. 클래스가 아니라 단순 Map으로 처리할 방법은 없을까? 정리해 둔다.

JSON 문자열 -> Map

JSON 문자열을 Map으로 변환하는 건 별도 클래스로 변환하는 것과 동일한 방식으로 처리할 수 있다.

import com.fasterxml.jackson.core.JsonProcessingException;
import com.fasterxml.jackson.databind.ObjectMapper;
import java.util.Map;

public class main {
    public static void main(String[] args) {
        String json = "{\"name\":\"Passwd\",\"age\":30}";

        // ObjectMapper 생성
        ObjectMapper objectMapper = new ObjectMapper();
        try {
            // JSON 문자열을 Map으로 변환
            Map user = objectMapper.readValue(json, Map.class);
            System.out.println(user);
        } catch (JsonProcessingException e) {
            throw new RuntimeException(e);
        }
    }
}

만약 중첩이 있거나 복잡한 경우에는 타입 안정성을 위해 전체 제네릭 타입 정보를 전달하는 TypeReference를 사용해도 된다.

import com.fasterxml.jackson.core.JsonProcessingException;
import com.fasterxml.jackson.core.type.TypeReference;
import com.fasterxml.jackson.databind.ObjectMapper;
import java.util.Map;

public class main {
    public static void main(String[] args) {
        String json = "{\"name\":\"Passwd\",\"age\":30}";

        // ObjectMapper 생성
        ObjectMapper objectMapper = new ObjectMapper();
        try {
            // JSON 문자열을 Map으로 변환
            Map<String, String> map = objectMapper.readValue(json, new TypeReference<Map<String, Object>>(){});
            System.out.println(map);
        } catch (JsonProcessingException e) {
            throw new RuntimeException(e);
        }
    }
}

Map -> JSON 문자열

반대로 Map을 JSON 문자열로 직렬화하는 방법도 기존과 동일하다.

import com.fasterxml.jackson.core.JsonProcessingException;
import com.fasterxml.jackson.core.type.TypeReference;
import com.fasterxml.jackson.databind.ObjectMapper;

import java.util.HashMap;
import java.util.Map;

public class main {
    public static void main(String[] args) {
        Map<String, Object> map = new HashMap<>();
        map.put("name", "Passwd");
        map.put("age", 30);
        
        // ObjectMapper 생성
        ObjectMapper objectMapper = new ObjectMapper();
        
        try {
            // Map을 JSON 문자열로 변환
            String jsonString = objectMapper.writeValueAsString(map);
            System.out.println(jsonString);
        } catch (JsonProcessingException e) {
            throw new RuntimeException(e);
        }

    }
}

다만 Map을 활용하는 건 오타에 취약하고 데이터 의미를 파악하기 어렵다. 또한 존재하지 않는 키를 참조하거나 잘못된 타입으로 형변환 하는 등의 오류를 수반할 수 있다.

참고 문서

https://4urdev.tistory.com/92

https://codewos.tistory.com/67

[Java] Jackson - JSON 다루기

비번변경 — Tue, 7 Apr 2026 10:42:12 +0900

Jackson

Jackson은 대표적인 Java JSON 라이브러리 중 하나로, Java 객체(POJO, Plain Old Java Object)를 JSON 형식의 데이터로 직렬화하거나 JSON 형식의 데이터를 Java 객체(POJO)로 역직렬화한다. 또한 JSON 뿐만 아니라 Avro, BSON, Smile, Properties 등 다양한 데이터 형식을 지원하기도 한다.

현재는 2.x(com.fasterxml.jackson), 3.x(tools.jackson) 버전이 유지보수되고 있다. 2.x 버전 기준으로 Jackson은 세 개의 코어 모듈로 이루어져 있다.

jackson-core : 스트리밍. 가장 낮은 수준의 입출력 처리를 지원하면 JsonParsor, JsonGenerator을 통해 코튼 단위로 데이터를 읽고 쓴다.
jackson-annotations : 범용 어노테이션
jackson-databind : Databind. 데이터를 트리 구조로 표현하거나 객체와 데이터 간 자동 매핑을 수행한다.

설치

작성일 기준 가장 많이 사용 중인 것으로 추정하는 2.x 버전으로 설치한다. 참고로 이 글에서는 gradle로 의존성을 관리하고 있기 때문에 build.gradle 파일의 dependencies에 아래 내용을 추가한다.

dependencies {
    implementation 'com.fasterxml.jackson.core:jackson-databind:2.16.1'
}

jackson-databind는 jackson-core, jackson-annotations 모두 의존하고 있기 때문에 jackson-databind만 추가해 주면 된다.

사용법

Jackson은 ObjectMapper라는 클래스를 선언하는 것부터 시작한다. 즉, Jackson은 ObjectMapper를 통해 Java 객체와 JSON 문자열 간의 데이터 직렬화와 역직렬화를 수행한다.

예로 들어 아래와 같은 Java 객체를 JSON 문자열로 직렬화한다고 하자.

public class User {
    String name;
    int age;
    
    // 기본 생성자, Getter, Setter 생략
}

이 경우, 아래와 같은 흐름으로 객체를 직렬화할 수 있다.

import com.fasterxml.jackson.core.JsonProcessingException;
import com.fasterxml.jackson.databind.ObjectMapper;

public class main {
    public static void main(String[] args) {
        User user = new User("Passwd", 30);
        
        // ObjectMapper 생성
        ObjectMapper objectMapper = new ObjectMapper();

        try {
            // 객체를 JSON 문자열로 변환
            System.out.println(objectMapper.writeValueAsString(user));
        } catch (JsonProcessingException e) {
            throw new RuntimeException(e);
        }
    }
}

반대로 JSON 문자열을 역직렬화하는 방법은 다음과 같다.

import com.fasterxml.jackson.core.JsonProcessingException;
import com.fasterxml.jackson.databind.ObjectMapper;

public class main {
    public static void main(String[] args) {
        String json = "{\"name\":\"Passwd\",\"age\":30}";

        // ObjectMapper 생성
        ObjectMapper objectMapper = new ObjectMapper();
        try {
            // JSON 문자열을 객체로 변환
            User user = objectMapper.readValue(json, User.class);
            System.out.println(user.getName() + ", " + user.getAge());
        } catch (JsonProcessingException e) {
            throw new RuntimeException(e);
        }
    }
}

참고 문서

https://github.com/fasterxml/jackson

[Java] Jackson - ObjectMapper 사용법

[Gradle] Task

비번변경 — Mon, 6 Apr 2026 11:30:52 +0900

개요

2026.03.27-[Java] Gradle 기본 개념에서 Task에 대해 언급했는데 이번 글에서 조금 더 알아보려고 한다.

Task

Task는 빌드가 수행하는 독립적인 실행 단위를 말하며, 클래스 컴파일, jar 생성, javadoc 생성 등의 작업이 해당된다.

일반적인 작업 유형은 다음과 같다

- 소스 코드 컴파일

- 테스트 실행

- 패키징 생성

- 문서 생성

- 저장소에 빌드 아티팩트 게시

각 작업은 독립적이나 다른 작업이 먼저 실행될 수 있으며, gradle은 가장 효율적인 작업 실행 순서를 파악하고 최신 상태인 작업은 건너뛴다.

Task 수행

아래 명령어로 Task를 실행시킬 수 있다.

./gradlew TASK_NAME

# 예시
./gradlew build

## 사용할 수 있는 task 확인
./gradlew tasks

## 기존 output 제거
./gradlew clean

gradle은 각 태스크가 내부적으로 의존하는 관계를 파악한 후 가장 먼저 수행해야 하는 task 순서대로 수행한다. 가령 build를 수행하면 compileJava, testm jar 등도 함께 수행한다.

Task 종류

gradle은 다양한 태스크를 가지고 있다. 이 글에서는 대표적인 태스크만 정리한다.

build

애플리케이션 소스코드를 실행화하는 task로, 라이브러리 의존성 확인, 리소스 파일 패키징, 소스 코드 컴파일, 테스트 코드 수행 등을 수행하여 산출물인 apk 파일을 생성한다. 태스크가 성공적으로 완료되었다면 모든 테스트를 통과하여 애플리케이션이 생성되었음을 의미한다. 그리고 프로젝트의 build 디렉터리에 수행 결과를 생성한다.

classes : java 소스 파일에 대해 컴파일러를 실행한 결과인 컴파일된 .class 파일을 포함한다.
libs : 생성된 jar 파일, 실행 또는 게시할 수 있도록 컴파일된 클래스가 포함된 아카이브를 저장한다.
reports : 테스트 결과를 요약한 HTML 보고서를 포함한다.

gradle은 기본적으로 재빌드 시 이전 빌드와 비교하여 재빌드가 필요한 부분만 판단하여 빌드하는 증분 빌드를 지향한다. 이때 필요한 부분만 빌드할 수 있도록 캐싱하는 것을 빌드 캐시라고 한다.

clean

build를 통해 생성된 모든 아티팩트를 포함해 빌드 캐시, gradle 디렉터리 등 산출물을 삭제하여 프로젝트를 초기 빌드 상태로 되돌린다. 캐시 된 데이터가 많은 경우에는 캐시 데이터를 불러오는 시간이 디스크 저장 데이터를 불러오는 시간보다 길어질 수 있어 전체 빌드 시간이 증가할 수 있다. 또한 디스크 공간 부족으로 빌드가 실패할 수 있기 때문에 clean 태스크를 통해 빌드 시간을 단축하고 안정성을 올릴 수 있다.

test

프로젝트에 구현된 단위 테스트를 실행한다. 기본적으로 모든 단위 테스트를 수행하는데, 옵션을 통해 특정 테스트만 수행할 수도 있다.

# 특정 하위프로젝트 전체 TestCase 수행
./gradlew <module>:testDebugUnitTest

# 특정 패키지에 대한 TestCase 수행
./gradlew <module>:testDebugUnitTest --tests "<package>.*"

# 특정 TestCase만 수행
./gradlew <module>:testDebugUnitTest --tests "<package>.<test_name>"

dependencies

프로젝트에서 사용하는 라이브러리에 대한 의존성 트리를 확인할 수 있다.

./gradlew dependencies
./gradlew <module>:dependencies

gradle에서는 하나의 라이브러리에 대해 서로 다른 버전을 사용할 때 발생하는데, gradle은 사용자가 어떤 버전을 사용할 지 알 수 없기 때문에 에러 메시지를 출력한다. 이때 사용자가 의존성 트리를 활용해 문제가 되는 라이브러리를 찾아 해결하는 방식으로 활용할 수 있다.

참고 문서

[Gradle] Gradle - 기본 구조 알아보기

[Android] Gradle Task 종류 및 사용법

[Gradle] 종속성 관리

비번변경 — Fri, 3 Apr 2026 10:28:23 +0900

개요

Gradle의 주요 기능 중 하나는 프로젝트의 종속성을 편하게 관리할 수 있다는 것이다. 이번 글에서는 Gradle에서의 종속성 관리에 대해서 알아보려고 한다.

종속성

Gradle에서 종속성이란 프로젝트 빌드를 지원하는 jar, 플러그인, 라이브러리 및 소스 코드와 같은 외부 리소스를 의미하는데, build.gradle이라는 빌드 스크립트에서 선언된다.

Gradle은 종속성을 다운로드, 캐싱, 해결하는 작업을 자동으로 처리하여 사용자가 직접 관리할 필요가 없게 한다. 또한 버전 충돌을 처리하고 유연한 버전 선언을 가능하게 한다. 그리고 일련의 자동화 기술을 바로 종속성 관리하고 한다.

종속성 선언

종속성은 아래 예시와 같이 선언하면 된다.

1번의 경우 java-library 플러그인을 적용한다는 것을 의미하고, 2-3번은 각 라이브러리에 대한 종속성 추가를 의미한다. 라이브러리 추가에 사용한 메서드(implementation, api)가 서로 다른데 gradle은 필요에 맞는 메서드를 선택하여 사용할 수 있도록 여러 가지 메서드를 지원하고 있다.

구성	설명
implemantation	컴파일, 런타임에 필요한 종속성
api	컴파일, 런타임에 필요한 종속성이 게시된 api에 포함되어 있음
compileOnly	컴파일에만 필요한 종속성
compileOnlyApi	컴파일에만 필요한 종속성이 게시도니 api에 포함되어 있음
runtimeOnly	런타임에만 필요한 종속성
testImplementation	테스트를 컴파일하고 실행하는데 필요한 종속성
testCompileOnly	테스트 컴파일에만 필요한 종속성
testRuntimeOnly	테스트 실행에만 필요한 종속성

종속성 확인

gradle은 dependencies task를 사용해 종속성 트리를 확인할 수 있다. 실행 명령어는 다음과 같다.

# app 프로젝트 내 종속성 확인
./gradlew :app:dependecies

버전 카탈로그 활용

버전 정보는 build.gradle에서 분리해 특정 카탈로그에 모아서 관리할 수도 있다. 카탈로그는 libs.versions.toml로 정의하며, 루트 폴더의 gradle 폴더에 위치해야 한다.

카탈로그는 4개의 섹션으로 이루어져있다.

[versions]: 플러그인과 라이브러리가 참조할 버전 번호를 선언한다.
[libraries]: 빌드 파일에서 사용되는 라이브러리를 정의한다.
[bundles]: 종속성 집합을 정의한다.
[plugins]: 플러그인을 정의한다.

libs.versions.toml

아래는 카탈로그에 정의한 정보를 참조하여 작성한 build.gradle이다.

build.gradle

참고 문서

[Gradle] Gradle - 기본 구조 알아보기

빌드 종속 항목 추가

[Gradle] settings.gradle / build.gradle

비번변경 — Thu, 2 Apr 2026 14:57:08 +0900

개요

최근 2026.03.30-[Gradle] 프로젝트 구조와 Wrapper 글을 통해 gradle 프로젝트의 구조와 wrapper에 대해서 알아보았다. 이번 글에서는 gradle의 설정 파일에 해당하는 settings.gradle에 대해서 알아보려고 한다.

settings.gradle

settings.gradle은 프로젝트의 구조를 정의하고 빌드에 하위 프로젝트를 추가하는 역할을 담당한다. 싱글 모듈 프로젝트인 경우에는 선택적으로 사용하고, 멀티 모듈 프로젝트인 경우에는 모든 하위 프로젝트를 선언하기 위해 필수적으로 사용해야 한다.

settings.gradle은 크게 두 가지 요소로 구성된다.

프로젝트 이름 (rootProject.name)

하나만 존재한다.

하위 프로젝트

해당 프로젝트에 포함된 하위 프로젝트를 선언한다.

build.gradle

build.gradle은 빌드 구성, task, plugin에 대한 세부 정보를 포함하며, 최소 하나의 빌드 스크립트로 구성된다. groovy, kotlin으로 작성하며 멀티 모듈 프로젝트에서 하위 프로젝트는 자신의 루트 디렉터리에 build.gradle을 가진다.

빌드 스크립트는 플러그인과 종속성을 지정하는데, 이때 종속성은 gradle 자체 또는 빌드 스크립트에 필요한 플러그인, 라이브러리, 그리고 프로젝트 코드 컴파일 및 실행하기 위한 라이브러리 종속성에 해당한다.

아래는 build.gradle 예시이다.

1. 플러그인

gradle 기능을 확장하고 프로젝트에 task를 추가하는 작업. 플러그인 추가는 플러그인 적용이라고 하며 예시에서는 application 플러그인을 추가한 모습이다.

2. 종속성

예시의 경우 jUnit Jupiter를 의존성에 추가한다.

3. convnetion properties

사용하고자 한 플러그인에 convention property를 지정한다. 예시는 application 플러그인에 필요한 mainClass 속성을 지정한다.

참고 문서

[Gradle] Gradle - 기본 구조 알아보기

[Gradle] 프로젝트 구조와 Wrapper

비번변경 — Wed, 1 Apr 2026 09:52:36 +0900

개요

2026.03.27-[Java] Gradle 기본 개념에서 Gradle을 이루는 기본 개념에 대해서 알아보았다. 이번 글에서는 Gradle 프로젝트의 구조에 대해서 알아두려고 한다.

프로젝트 구조

gradle init 명령어를 수행하면 프로젝트는 아래와 같은 파일 구조를 가진다.

1. gradle : Wrapper 파일 등을 저장하는 Gradle 디렉터리

2. libs.versions.toml : 종속성 관리를 위한 Gradle 버전 카탈로그

3. gradlew : Gradle Wrapper 스크립트. Gradle 프로젝트는 특정 gradle 버전을 포함하고, wrapper 형태로 형상관리를 수행한다.

4. settings.gradle : 루트 프로젝트와 하위 프로젝트를 정의하는 gradle 설정 파일. 프로젝트 루트에 존재하고 유일하다.

5. build.gradle : 서브 프로젝트의 gradle 빌드 스크립트. 단일 모듈 프로젝트의 경우, settings.gradle과 같은 위치에 존재한다.

6. src : 소스 코드

Gradle Wrapper

Gradle 프로젝트에는 Wrapper가 존재하는데, Wrapper 스크립트는 선언된 gradle 버전을 호출하고 필요한 경우 미리 다운로드한다.

Wrapper 스크립트는 gradlew, gradlew.bat 파일로 사용할 수 있다. 만약 프로젝트에 파일이 포함되어 있지 않다면 gradle 프로젝트가 아니거나 Wrapper가 아직 설정되지 않은 상태라고 할 수 있다.

시스템에 설치된 gradle을 사용하지 않은 이유는 여럿이지만 가장 큰 이유는 표준화라고 할 수 있다. 특정 gradle 버전을 자동으로 다운로드하여 사용하고, gradle 버전에 따라 프로젝트를 표준화하면 다양한 사용자 환경에 동일한 gradle 버전을 제공할 수 있기 때문이다. 또한 gradle을 직접 설치하지 않아도 쉽게 빌드할 수 있는 환경을 제공해주기도 한다.

때문에 시스템에 설치된 gradle 배포판을 사용하는 gradle build와 gradle wrapper를 사용하는 ./gradlew build의 차이를 이해하고 있어야 한다.

구조

1. gradle-wrapper.jar : gradle wrapper 코드가 포함된 jar 파일로, 프로젝트에 맞는 gradle 버전이 설치되어 있지 않은 경우 해당 버전을 다운로드하고 설치하는 역할을 수행한다.

2. gradle-wrapper.properties : gradle wrapper의 구성 속성을 포함하는 파일이다. 배포 url, 유형 등이 들어있다.

3-4. gradlew : 래퍼 역할을 하는 스크립트 또는 배치 파일

참고 문서

[Gradle] Gradle - 기본 구조 알아보기

[Java] Gradle 기본 개념

비번변경 — Tue, 31 Mar 2026 11:36:33 +0900

개요

현재 개발하는 Java 애플리케이션은 Gradle 프로젝트인데 Gradle에 대한 이해도가 부족하다 보니 어떻게 설정하는지, 어떤 개념이 있는지 헤매고 있는 중이다. 이번 글에서는 기초적인 개념 위주로 훑어보려고 한다.

Gradle

프로젝트 초기화 및 빌드 자동화 도구로, 설정이나 외부 라이브러리 의존 관리를 편리하게 하는 역할을 수행한다. 개발자는 설정과 의존성 관리, 컴파일 방식 정의, 테스트, 패키징, 작업 설정 등을 위해 Gradle을 사용하게 된다.

구조 및 개념

Gradle은 5개의 핵심적인 개념을 가진다.

프로젝트

빌드 가능한 소프트웨어를 의미한다. 단일 프로젝트 빌드에는 루트 프로젝트라는 단일 프로젝트가 포함되며, 멀티 모듈 프로젝트 빌드에는 하나의 루트 프로젝트와 여러 개의 하위 프로젝트를 포함한다.

일반적으로 IntelliJ에서 기본 옵션으로 프로젝트를 생성하면 build.grade, settings.grade이라는 파일이 루트 폴더 내에 생성된다.

빌드 스크립트

브로젝트 빌드에 필요한 단계를 설명한 파일. build.grade, build.gradle.kts이라는 이름의 파일로, 프로젝트에 대한 태스크, 의존성, 플러그인 및 기타 구성을 정의한다.

settings.grade은 루트 프로젝트를 위한 스크립트이고, build.grade은 하위 프로젝트를 위한 스크립트에 해당한다.

의존성 관리

프로젝트에 필요한 외부 리소스를 선언하고 해결하기 위해 자동화된 기술이다.

태스크

코드 컴파일, 테스트 실행 과 같은 기본적인 작업 단위를 말한다. 각 프로젝트는 빌드 스크립트 또는 플러그인 내에 정의된 하나 이상의 태스크가 존재하고, 그 태스크를 따라 빌드를 수행한다. 태스크는 파일 복사, 소스 컴파일과 같은 작업 조각인 액션, 액션이 사용하거나 입력하는 값인 입력, 그리고 액션이 수정하느 파일인 출력으로 구성한다.

플러그인

코드 컴파일, 테스트와 같은 태스크를 gradle에서 실행할 수 있도록 gradle의 기본 기능을 확장하는 도구이다. 로직과 구성을 재사용할 수 있는 수단을 제공하여, 한 번 작성한 태스크를 여러 빌드에서 사용할 수 있게 한다.

빌드

gradle 빌드는 gradle 프로젝트에서 태스크를 실행하는 것이다. gradle은 빌드를 구성하고 실행할 태스크를 선택하고, 요청한 태스크와 의존성을 바탕으로 가장 작은 태스크 집합을 실행한다.

빌드 명령어는 다음과 같다.

gradle build

/gradlew build 
gradlew.bat build

참고 문서

[Gradle] Gradle - 기본 구조 알아보기

Gradle에 대해 알아보자 #1 - Gradle의 기본 개념

[Github] Github Action 트리거 스킵하기

비번변경 — Mon, 30 Mar 2026 11:04:12 +0900

개요

Github 레포지터리의 특정 브랜치에 푸시가 발생하거나 PR이 생성되었을 때 자동으로 Github Action이 트리거 되도록 설정해 두었는데, Action 수행이 필요하지 않은 단순 수정 건에도 Action이 트리거 되는 것에 불편함을 느끼곤 했다.

적당한 방법이 없나 확인해보니 Github는 Action 트리거를 건너뛰는 방법도 제공하고 있는 것을 알게 되었다. 간단하게 기록해 둔다.

방법

Action 트리거를 건너뛰는 방법은 생각보다 간단하다. 커밋 메시지나 PR 헤드에 아래 문자열을 포함시켜 주면 Action 트리거를 건너뛸 수 있다.

[skip ci]
[ci skip]
[no ci]
[skip actions]
[actions skip]

git commit -m "Update README.md [skip ci]"
git commit -m "문서 오타 수정 [no ci]"

또는 커밋 메시지에 skip-checks 트레일러를 포함시켜도 된다. 커밋 메세지 마지막에 빈 줄 두 개를 넣고 작성해야 한다.

문서 수정

skip-checks: true

이때 git이 줄 바꿈을 자동 정리하지 않도록 커밋 명령어에 --cleanup=verbatim 옵션을 포함시켜주어야 한다.

git commit --cleanup=verbatim

테스트

예로 들어 아래와 같이 레포지터리에 push 이벤트가 발생하면 트리거 되도록 구성한 워크플로우가 있다고 하자.

name: learn-github-actions
run-name: ${{ github.actor }} is learning GitHub Actions
on: [push]
jobs:
  job1:
    runs-on: ubuntu-latest
    outputs:
      output1: ${{ steps.step1.outputs.test }}
      output2: ${{ steps.step2.outputs.test }}
    steps:
      - id: step1
        run: echo "test=hello" >> "$GITHUB_OUTPUT"
      - id: step2
        run: echo "test=world" >> "$GITHUB_OUTPUT"
  job2:
    runs-on: ubuntu-latest
    needs: job1
    steps:
      - env:
          OUTPUT1: ${{needs.job1.outputs.output1}}
          OUTPUT2: ${{needs.job1.outputs.output2}}
        run: echo "$OUTPUT1 $OUTPUT2"

이 워크플로우를 구성한 레포지터리에 README.md 파일을 편집하려고 한다. 레포지터리를 설명하는 문서 편집이기 때문에 github action을 트리거할 필요는 없을 것 같다.

파일을 편집하고 메시지에 [skip actions]를 포함시켰다. 그리고 Commit changes를 클릭하면 직전 커밋과는 다르게 actions이 트리거 되지 않은 모습을 확인할 수 있다.

참고 문서

https://docs.github.com/ko/actions/how-tos/manage-workflow-runs/skip-workflow-runs

https://shanepark.tistory.com/544

[Java] regex - 정규표현식 사용 기본

비번변경 — Fri, 27 Mar 2026 11:34:36 +0900

개요

2022.08.14-[Python] re - 정규 표현식을 이용한 문자열 검색에서 Python에서의 정규표현식 관련 작업을 하는 방법을 살펴보았었다. Java에서도 당연히 정규표현식을 다루는 regex 패키지가 존재하는데, 이번 글에서는 regex에 대해서 조금 적어둔다.

regex

Java에서는 java.util.regex 패키지를 통해 정규 표현식을 다룰 수 있는데, 주로 사용하는 Pattern, Matcher 클래스를 많이 사용한다.

Pattern

문자열을 정규표현식 패턴 객체로 변환시켜 주는 역할을 담당한다. 다른 클래스와 달리 공개 생성자를 제공하지 않고, compile이라는 정적 메서드를 호출해야 한다.

// 문자열 형태의 정규표현식 문법을 정규식 패턴으로 변환
String patternString = "^[0-9]*$";
Pattern pattern = Pattern.compile(patternString); // Pattern 객체로 컴파일된 정규식은 뒤의 Matcher 클래스에서 사용된다

Pattern 객체로 컴파일된 정규식은 Matcher 클래스에서 활용한다.

또는 정규표현식 컴파일 없이 바로 matches 메서드를 사용해 검증할 수 있다. matches 메서드는 첫 매개변수에 정규표현식을, 다음 매개변수에 대상 문자열을 제공한다. 검증 문자열이 정규표현식과 일치하면 true를 그렇지 않다면 false를 반환한다.

import java.util.regex.Pattern;

public class Main {
    public static void main(String[] args) {
        // 샘플 문자열
        String txt1 = "123123";
        String txt2 = "123이것은숫자입니다00";

        boolean result = Pattern.matches("^[0-9]*$", txt1); // 첫번째 매개값은 정규표현식이고 두번째 매개값은 검증 대상 문자열
        System.out.println(result); // true

        boolean result2 = Pattern.matches("^[0-9]*$", txt2);
        System.out.println(result2); // false
    }
}

Matcher

Matcher 클래스는 문자열의 패턴을 해석하여 주어진 패턴과 일치하는지 판별하고, 반환된 결괏값을 가지고 있다. Matcher 클래슨 공개 생성자 대신 Pattern.matcher 메서드를 통해 얻을 수 있다. 즉 Patterm.compile -> Pattern.matcher 순으로 실행하는 흐름이다. pattern.matches는 단순 일치 여부만을 확인할 수 있지만. matcher는 보다 상세한 결괏값을 얻을 수 있다.

import java.util.regex.Matcher;
import java.util.regex.Pattern;

public class Main {
    public static void main(String[] args) {
        String txt = "1487안녕";
        String patternString = "^[0-9]+";

        // 1) 문자열 형태의 정규표현식 문법을 정규식 패턴으로 변환
        Pattern pattern = Pattern.compile(patternString);

        // 2) 패턴 객체로 matcher 메서드를 통해 문자열을 검사하고 필터링된 결과를 매처 객체로 반환
        Matcher matcher = pattern.matcher(txt);

        // 3) 정규식 필터링된 결과를 담은 matcher에서 메소드를 통해 결과를 출력
        System.out.println(matcher.find()); // 매칭된 결과가 있는지? : true
        System.out.println(matcher.group()); // 매칭된 부분을 반환 : 1487
    }
}

참고 문서

☕ 자바 정규식(Regular Expression) 사용법 정리

[Java] 개선된 switch/case (Java 12)

비번변경 — Thu, 26 Mar 2026 10:00:18 +0900

개요

Java를 들여다보지 않은지 어언 n년, 그간 버전이 올라가면서 switch/case 문에도 약간 변화가 있었던 모양인지 못 본 새 화살표로 case에 대한 실행 코드를 표현하고 있는 코드를 발견했다. 간략하게나마 사용법을 기재해 둔다.

switch/case

전통적인 switch/case 문의 구조는 다음과 같다.

switch (변수) {
    case 값1:
        // 실행 코드       
        break;
    case 값2:
        // 실행 코드        
        break;
    default:
        // 위의 case와 일치하는 값이 없을 때 실행
}

단순한 구조지만 여러 케이스를 묶을 때 불필요한 타이핑이 많고, break 누락에 의한 버그가 발생할 가능성이 많다. break 없이 이어갈 코드는 작성 빈도가 낮고 작성하더라고 주석으로 의도한 non-break임을 명시하게 된다.

Java에서는 이러한 불편함을 개선하기 위해 보다 간결한 문법을 도입했다.

간결한 switch/case

Java 12에서부터 switch/case문은 화살표 연산자를 사용해 간결하게 표현할 수 있게 되었다.

switch (변수) {
    case 값1 -> 실행 코드
    case 값2 -> 실행 코드
    default -> 위의 case와 일치하는 값이 없을 때 실행
}

break를 생략할 수 있고, 여러 케이스를 한 줄에 처리할 수 있다.

예로 들어, 각 달의 계절을 반환하는 switch/case문을 작성한다고 하자. 기존 코드는 다음과 같이 작성해야 했다.

switch (month) {
    case 12:
    case 1:
    case 2:
        season = "winter";
        break;
    case 3:
    case 4:
    case 5:
        season = "spring";
        break;
    case 6:
    case 7:
    case 8:
        season = "summer";
        break;
    case 9:
    case 10:
    case 11:
        season = "autumn";
        break;
    default:
        season = "unknown";
}

반면 화살표 연산자를 도입하여 표현하면 아래와 같이 정리된다.

switch (month) {
    case 12, 1, 2 -> season = "winter";
    case 3, 4, 5 -> season = "spring";
    case 6, 7, 8 -> season = "summer";
    case 9, 10, 11 -> season = "autumn";
    default -> season = "unknown";
}

코드가 늘어지지 않아 가독성이 개선된 모습을 볼 수 있다.

참고 문서

Java 14~21에서의 Switch Case

https://hianna.tistory.com/903

[Java] 텍스트 블록

비번변경 — Wed, 25 Mar 2026 10:17:45 +0900

개요

Java에서는 개행을 포함한 문자열을 선언할 때 + 연산자와 개행 문자를 함께 사용하는 문자열 조합을 활용해 선언을 해왔다.

// 문자열 조합
String html1 = "<html>\n" +
          "    <body>\n" +
          "        <p>Hello, world</p>\n" +
          "    </body>\n" +
          "</html>\n";

그러나 Java 15부터 텍스트 블록이 도입됨에 따라 보다 가독성 있는 여러 줄 문자열을 선언할 수 있게 되었다. 이번 글에서는 Java의 텍스트 블록에 대해서 적어둔다.

텍스트 블록

텍스트 블록은 큰따옴표 세 개(""")로 열고 닫을 수 있는데, """ 뒤에 바로 문자열이 올 수 없다는 특징이 있다. """ ~ """ 블록 내에는 반드시 하나 이상의 개행이 포함되어 있어야 한다.

String html = """
  <html>
      <body>
          <p>Hello, world</p>
      </body>
  </html>
  """;

문자열에 큰따옴표가 포함되어 있는 경우도 별도의 이스케이프 바로 사용할 수 있다.

String query = """
        SELECT "EMP_ID", "LAST_NAME" FROM "EMPLOYEE_TB"
        WHERE "CITY" = 'INDIANAPOLIS'
        ORDER BY "EMP_ID", "LAST_NAME";
        """;

다만 \의 경우에는 개행을 무시할 때 사용할 수 있기 때문에 \ 자체를 표현하기 위해서는 이스케이프가 필요하다.

출력을 보면 \에 의해 개행이 무시되고 \가 출력된 것을 볼 수 있다.

들여 쓰기

SQL 등을 작성할 때는 들여 쓰기가 코드의 가독성을 좌우한다. Java는 들여 쓰기를 문자열에 반영하기 위해 여러 배려를 해두었는데, 닫는 """가 그 기준 중 하나이다.

가령 닫는 큰따옴표가 각 줄의 시작위치와 동일한 경우와 그렇지 않은 경우의 출력을 비교하면 다음과 같다.

public class Main {
    public static void main(String[] args) {
        String query_1 = """
                SELECT "EMP_ID", "LAST_NAME" FROM "EMPLOYEE_TB"
                WHERE "CITY" = 'INDIANAPOLIS'
                ORDER BY "EMP_ID", "LAST_NAME";
                """;

        String query_2 = """
                SELECT "EMP_ID", "LAST_NAME" FROM "EMPLOYEE_TB"
                WHERE "CITY" = 'INDIANAPOLIS'
                ORDER BY "EMP_ID", "LAST_NAME";
            """;
        System.out.println(query_1);
        System.out.println(query_2);
    }
}

format

텍스트 블록은 원활한 포매팅을 위해 replace, format과 같은 메서드를 지원하고 있다.

// Strnig::repalce 예제
String code_1 = """
      public void print($type o) {
          System.out.println(Objects.toString(o));
      }
      """.replace("$type", type);

// String::formatted 예제
String code_2 = """
      public void print(%s o) {
          System.out.println(Objects.toString(o));
      }
      """.formatted(type);

format 메서드의 경우에는 String.format과 이름이 다르니 주의할 필요가 있다.

참고 문서

https://www.baeldung.com/java-text-blocks

https://mostadmired.tistory.com/132

[IntelliJ] Gradle 빌드하기

비번변경 — Tue, 24 Mar 2026 14:44:36 +0900

개요

IntelliJ 상에서 Java 애플리케이션을 개발하고 이제 빌드를 해야 하는데, 문서상으로는 CLI로 안내가 되어있었다. 하지만 IntelliJ 내장 JDK로 개발하고 있어 Java를 설치하라는 오류가 발생하는 문제가 있었다. 확인해 보니 IntelliJ 내에서 빌드 기능을 지원하고 있는 걸로 보여 방법을 기록해 둔다.

방법

1. 오른쪽 메뉴의 Gradle 버튼 클릭

2. Tasks 접근

3. 실행할 태스크 더블클릭

빌드를 더블클릭하면 프로젝트에 build 경로가 생기면서 libs 경로 아래에 jar 파일이 생성된다.

참고 문서

https://gist.github.com/sungkwangsong/3717edde69390238e3de836e8364ccdb

https://lucas-owner.tistory.com/21

[Java] Record

비번변경 — Mon, 23 Mar 2026 10:46:55 +0900

Record

Java 14 버전에서 도입된 클래스 타입으로 변경 불가(immuatable) 데이터 객체를 만드는 기능을 제공한다. 기존 클래스와 비슷하지만 더 간결하게 데이터 객체를 만들 수 있다.

특징

Record 클래스는 다음과 같은 특징을 가지고 있다.

- 간결성 : 간결한 코드를 작성하기 위해 도입되어, 정의한 필드를 기반으로 메서드가 자동 생성된다. 코드의 양을 줄임으로써 가독성을 확보한다.

- 메서드 자동 생성 : 필드를 기반으로 equals, hashCode, toString, getter을 자동 생성하여 반복적인 코드 작성을 피한다.

- 불변성 : 필드가 설정되면 값을 변경하지 못하여 데이터 안정성을 높인다.

- final 생략 : 필드를 불변으로 취급하기 때문에 자동으로 final 처리를 한다.

- 패턴 매칭 : 패턴 매칭을 사용해 데이터 추출 및 일치 검사에 효과적이다.

- 데이터 전달 : Record의 주된 목적은 불변 데이터를 전달하는 것으로 DTO(Data Transfer Object)를 표현하기에 적합한다.

사용 예시

예로 들어 아래와 같은 User를 표현하는 DTO가 있다고 하자.

// User.java
public final class User {
    private final Long id;
    private final String email;
    private final String name;

    public User(Long id, String email, String name) {
        this.id = id;
        this.email = email;
        this.name = name;
    }

    public Long getId() {
        return id;
    }

    public String getEmail() {
        return email;
    }

    public String getName() {
        return name;
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (!(o instanceof User user)) return false;
        return id.equals(user.id) && email.equals(user.email) && name.equals(user.name);
    }

    @Override
    public int hashCode() {
        return java.util.Objects.hash(id, email, name);
    }

    @Override
    public String toString() {
        return "User{" + "id=" + id + ", email='" + email + '\'' + ", name='" + name + '\'' + '}';
    }
}

// Main.java
public class Main {
    public static void main(String[] args) {
        User user = new User(1L, "passwd@tistorycom", "user1");
        System.out.println(user);
    }
}

이 User 클래스를 record를 활용하여 작성하면 아래와 같이 작성할 수 있다.

// User.java
public record User(
        Long id,
        String email,
        String name
) {

}

다만 getter는 getVarName 형식이 아닌 변수명으로 생성된다.

public class Main {
    public static void main(String[] args) {
        User user = new User(1L, "passwd@tistorycom", "user1");
        System.out.println(user.id());
    }
}

참고 문서

https://s7won.tistory.com/2

https://m.blog.naver.com/seek316/223341255150

[Python] unittest - 미설치 라이브러리 모킹

비번변경 — Fri, 20 Mar 2026 09:57:10 +0900

현상

unittest를 작성하다 ModuleNotFoundError: No module named 'airflow' 오류를 만났다.
테스트하려는 모듈이 airflow를 import 하고 있었는데, 현재 개발 환경에는 Airflow가 설치되어 있지 않아 발생한 문제다. 진짜 문제는 환경적인 제약사항으로 설치할 수도 없는 상황이라는 것이었다.

이런 문제를 좀 해결할 수 있는 방법이 없을까? 찾다가 적어둔다.

해결

`sys.modules`에 해당 모듈 이름을 키로, `MagicMock()`을 값으로 등록해 두면 된다.

import sys
from unittest.mock import MagicMock
 
AIRFLOW_MOCKS = [
    "airflow",
    "airflow.decorators",
    "airflow.providers.postgres.hooks.postgres",
    # ... 필요한 모듈들
]
 
for mod in AIRFLOW_MOCKS:
    sys.modules[mod] = MagicMock()

sys.modules은 이전에 2022.07.23-[Python] import - 검색 순서에서 살폈었는데, 파이썬 인터프리터가 모듈을 찾는 캐싱 저장소이다.

모듈을 찾는 순서는 다음과 같다.

1. `sys.modules` 캐시 확인 — 이미 import된 적 있으면 캐시에서 꺼낸다
2. `sys.path`에서 파일 탐색 — 설치된 패키지, 현재 디렉터리 등을 순서대로 탐색한다
3. 모듈 로드 및 캐시 저장 — 찾은 모듈을 실행하고 `sys.modules`에 저장한다

모듈을 찾는 과정에서 sys.modules에 해당 키가 있으면 파일을 찾는 시도를 하지 않는다. import 하는 과정에서 sys.modules에 저장된 값이 진짜 모듈인지 검사하지도 않는다. 그리고 sys.modules 자체는 평범한 딕셔너리이기 때문에 Mock 객체도 가질 수 있다. Mock 객체는 어떤 속성 접근이나 메서드 호출도 응답하는 객체이기 때문에 가짜 모듈 역할을 능히 수행할 수 있다.

따라서 `sys.modules["airflow"] = MagicMock()`을 설정해 두면:
- `import airflow` → `sys.modules`에서 `MagicMock` 반환 ✅
- `from airflow.decorators import dag` → `MagicMock().dag` 반환 ✅
- `hook = PostgresHook(...)` → `MagicMock()(...)` 반환 ✅

이런 식의 꼼수를 부릴 수 있다.

예시 코드

테스트 대상 모듈 (`my_dag.py`)

airflow 라이브러리를 임포트하는 코드이다.

from airflow.decorators import dag, task
from airflow.providers.postgres.hooks.postgres import PostgresHook
 
@dag
def my_pipeline():
    @task
    def extract():
        hook = PostgresHook(postgres_conn_id="my_conn")
        return hook.get_records("SELECT * FROM users")
 
    extract()

테스트 코드 (`test_my_dag.py`)

테스트 코드에서 airflow 임포트를 포함하는 my_dag 내 함수를 테스트한다.

import sys
import unittest
from unittest.mock import MagicMock
 
# 테스트 파일 최상단, import 전에 설정해야 한다
AIRFLOW_MOCKS = [
    "airflow",
    "airflow.decorators",
    "airflow.providers.postgres.hooks.postgres",
]
for mod in AIRFLOW_MOCKS:
    sys.modules[mod] = MagicMock()
 
from my_dag import my_pipeline
 
 
class TestMyPipeline(unittest.TestCase):
    def test_pipeline_runs_without_error(self):
        result = my_pipeline()
        self.assertIsNotNone(result)
 
 
if __name__ == "__main__":
    unittest.main()

주의

다만 라이브러리를 모킹할 때는 다음과 같은 주의사항이 있다.

1. 설정 순서
`sys.modules` 패치는 반드시 해당 모듈을 import 하기 전에 이루어져야 한다. 한 번 import 된 모듈은 이미 캐시 되기 때문에, 순서가 바뀌면 소용없다.

# ❌ 잘못된 순서
from my_dag import my_pipeline
sys.modules["airflow"] = MagicMock()  # 너무 늦음
 
# ✅ 올바른 순서
sys.modules["airflow"] = MagicMock()
from my_dag import my_pipeline

2. 서브모듈도 명시 필요

`sys.modules["airflow"] = MagicMock()`만 설정해도 `import airflow`는 되지만, `from airflow.decorators import dag`처럼 서브모듈을 직접 import 하는 경우엔 해당 경로도 별도로 등록해야 한다.

sys.modules["airflow"] = MagicMock()
sys.modules["airflow.decorators"] = MagicMock()  # 별도 등록 필요

3. 전역 상태 오염
`sys.modules`는 프로세스 전체에서 공유되는 전역 상태다. 파일 최상단에서 한 번 설정하면 같은 프로세스에서 실행되는 모든 테스트에 영향을 준다.
테스트 A에서 `airflow`를 MagicMock으로 등록해두면, 이후 실행되는 테스트 B에서도 실제 airflow 대신 MagicMock이 반환된다. 테스트 실행 순서에 따라 결과가 달라지는 비결정적 테스트가 될 수 있고, 테스트 간 격리가 깨진다.
또한 `my_dag` 모듈 자체도 `sys.modules`에 캐시되기 때문에, 다른 테스트에서 다시 import해도 mock이 적용된 버전이 재사용된다.
더 안전한 방법으로는 `patch.dict(sys.modules, {...})`를 데코레이터나 컨텍스트 매니저로 사용하거나, `setUp` / `tearDown`에서 패치/복구하는 방식이 있다. 이 내용은 별도 포스트에서 다룰 예정이다.

정리

`sys.modules`는 Python import 시스템의 캐시다. 이 딕셔너리를 직접 조작하면 파일시스템 탐색 없이 원하는 객체를 모듈로 반환시킬 수 있다. `MagicMock`은 어떤 속성/메서드 접근에도 응답하기 때문에 가짜 모듈 역할로 적합하다.

import airflow 실행 시:
    ↓
sys.modules에 "airflow" 키가 있는가?
    ↓ Yes                  ↓ No
그 값을 반환           파일시스템에서 탐색
(MagicMock 반환)       (없으면 ModuleNotFoundError)

다만 라이브러리 모킹은 "설치할 수 없는 라이브러리의 존재를 속이는" 것이다. 때문에 테스트하려는 대상은 Airflow 자체가 아니라 Airflow를 사용하는 내 코드의 로직일 때 사용할 수 있다.

테스트 목적	적합 여부
내 비즈니스 로직이 올바르게 동작하는가	✅
Airflow의 실제 기능이 올바르게 동작하는가	❌
DB 쿼리 결과를 검증하고 싶다	❌

참고 문서

https://stackoverflow.com/questions/63421480/how-to-mock-using-sys-modules-and-with-mock-patch-python-interference-on-static

[Python] unittest.patch - 함수 내부 의존성 대체

비번변경 — Thu, 19 Mar 2026 10:48:01 +0900

개요

2026.03.16-[Python] unittest.mock - 의존성 대체를 통해 unittest의 Mock에 대해서 알아보았다. Mock은 어떤 객체를 가짜 객체로 대체함으로써 테스트 수행 시의 외부 시스템 의존성을 낮출 수 있다. 단, 의존성을 인자로 직접 주입받는 함수에 한해서다.

def get_users(db):
    return db.query("SELECT * FROM users")

def test_get_users():
    mock_db = Mock()
    mock_db.query.return_value = [{"id": 1}]
    assert get_users(mock_db) == [{"id": 1}]

함수 내부에서 외부 시스템을 직접 참조하는 경우, 인자로 Mock을 주입할 수 없기 때문에 위 방식으로는 테스트할 수 없다. 이런 경우에 patch를 사용한다.

patch

patch는 테스트 실행 중 특정 이름에 바인딩된 객체를 Mock으로 교체해주는 역할을 한다. 예를 들어 테스트 대상 함수가 requests 라이브러리를 임포트하여 내부에서 get을 호출한다면, patch는 requests.get을 Mock 객체로 바꿔치기한다.

# mymodule.py
import requests  # mymodule.requests → requests 객체
```

`patch("mymodule.requests.get")`은 이 바인딩을 임시로 바꾼다.
```
평소:   mymodule.requests.get → 진짜 HTTP 함수
patch:  mymodule.requests.get → MagicMock()

테스트가 끝나면 원래 바인딩으로 복원된다.

일반적으로는 데코레이터로 사용하지만, 컨텍스트 매니저로도 사용할 수 있다.

# 데코레이터
@patch('mymodule.requests.get')
def test_fetch(self, mock_get):
    ...

# 컨텍스트 매니저
def test_fetch(self):
    with patch('mymodule.requests.get') as mock_get:
        ...

경로 지정

patch를 사용할 때는 경로 지정에 유의해야 한다. 흔한 실수 중 하나가 원본 객체의 경로를 지정하는 것이다. patch는 모듈의 네임스페이스에서 이름 바인딩을 교체하는 방식으로 동작하기 때문에, import된 시점을 기준으로 사용되는 쪽의 경로를 지정해야 한다.

# 잘못된 경로
@patch('requests.get')         # 원본 경로 → 효과 없음

# 올바른 경로
@patch('mymodule.requests.get')  # 사용되는 쪽의 경로

사용 예시

전달받은 URL에 GET 요청을 보낸 후 그 응답을 JSON 형태로 반환하는 함수 fetch가 정의된 mymodule이 있다고 하자.

# mymodule.py
import requests

def fetch(url):
    return requests.get(url).json()

이 함수를 그대로 테스트하면 실제 외부 서버에 요청이 나간다.

import mymodule

class MyTests(TestCase):
    def test_fetch(self):
        result = mymodule.fetch('http://example.com')
        self.assertDictEqual(result, {"ok": True})

patch를 사용해 requests.get을 Mock으로 교체한다. 대상 경로는 원본인 requests.get이 아니라 mymodule.requests.get으로 지정하고, patch된 Mock 객체를 주입받을 매개변수를 테스트 함수에 추가한다.

class MyTests(TestCase):
    @patch('mymodule.requests.get')
    def test_fetch(self, mock_req_get):
        # requests.get(url)의 반환값에서 .json()을 호출하는 구조이므로
        # return_value를 두 단계로 체이닝해서 지정한다
        mock_req_get.return_value.json.return_value = {"ok": True}
        result = mymodule.fetch('http://example.com')
        self.assertDictEqual(result, {"ok": True})

mock_req_get.return_value는 requests.get(url)의 반환값에 해당하는 Mock이고, .json.return_value는 그 반환값에서 .json()을 호출했을 때의 결과다. fetch 내부의 requests.get(url).json() 호출 구조를 그대로 따라가면 된다.

참고 문서

https://daleseo.com/python-unittest-mock-patch/

https://upright-wing.tistory.com/16

[Python] unittest - MagicMock

비번변경 — Wed, 18 Mar 2026 10:39:50 +0900

개요

2026.03.16-[Python] unittest.mock - 의존성 대체에서 mock 객체와 객체가 어떻게 사용되었는지 검증하는 방법에 대해 알아보았다. 다만 실제 사례에서는 일반 Mock이 아니라 MagicMock이라는 객체를 더 많이 사용하는 걸로 보이는데, 어떤 차이가 있는지 알아본다.

Mock

Python의 모든 객체는 특수한 목적으로 쓰이는 매직 메서드를 갖는다. 가령 __str__의 경우 객체를 문자열로 출력하기 위해 사용되는데, Mock은 매직 메서드가 자동으로 모킹 되지 않는다.

from unittest.mock import Mock, MagicMock, call


if __name__ == '__main__':
    mock = Mock()
    print(mock.__str__.return_value)

따라서 Mock 객체의 매직 메서드를 모킹하려면 새로운 Mock 객체를 생성해서 할당해주어야 하는 불편함이 있다.

from unittest.mock import Mock, MagicMock, call


if __name__ == '__main__':
    mock = Mock()
    mock.__str__ = Mock(return_value='mock')
    print(mock.__str__.return_value)

이러한 불편함을 해소한 것이 바로 MagicMock이다.

MagicMock

MagicMock은 매직 메서드를 모킹해놓은 Mock 클래스의 확장 버전이라고 할 수 있다. Mock 클래스와 달리 매직 메서드를 별도로 모킹 하지 않아도 사용에 문제가 없다.

from unittest.mock import Mock, MagicMock, call


if __name__ == '__main__':
    mock = MagicMock()
    print(mock.__str__.return_value)

참고 문서

https://daleseo.com/python-unittest-mock/

[Python] unittest.mock - 의존성 대체

비번변경 — Tue, 17 Mar 2026 11:06:22 +0900

Mock

테스트를 작성하다 보면 필연적으로 외부 서비스를 의존하는 코드를 테스트하게 된다. 그러나 테스트 환경에서는 제약사항으로 인해 실제 데이터베이스나 외부 서비스에 연동하는 것이 어려운 경우가 많다. 때문에 단위 테스트를 작성할 때는 외부에 의존하는 부분을 임의로 가짜로 대체하는 기법이 자주 사용되는데 이를 모킹(mocking)이라고 한다.

이번 글에서는 python unittest를 사용할 때 모킹하는 방법에 대해서 적어둔다.

unittest.mock

unittest.mock은 코드의 특정 부분을 mock 객체로 대체하는 기능을 제공하며, mock 객체가 어떻게 사용되었는지 검증하는데 도움을 준다. unittest가 파이썬 내장 라이브러리인 것과 동일하게 unittest.mock도 내장 라이브러리이기 때문에 별도 설치 없이 임포트 하여 사용할 수 있다.

from unittest.mock import Mock, MagicMock, call

Mock 객체 설정

mock 객체를 생성할 때는 어떻게 작동할지 지정할 수 있고, mock 객체는 자신을 상대로 어떤 작업이 발생했는지 기억한다.

- 반환값 지정

호출될 때 특정 값을 반환하도록 설정할 때는 return_value에 값을 전달하여 생성한다.

from unittest.mock import Mock, MagicMock, call

if __name__ == '__main__':
    mock = Mock(return_value="hello")
    print(mock())

- 예외 발생

예외를 발생시킬 때는 side_effect에 예외를 전달한다.

from unittest.mock import Mock, MagicMock, call


if __name__ == '__main__':
    mock = Mock(side_effect=Exception("test"))
    print(mock())

- 다 회 호출 설정

side_effect에는 예외 뿐만 아니라 함수가 여러 번 호출됐을 때의 반환값을 각각 지정할 수도 있다.

from unittest.mock import Mock, MagicMock, call


if __name__ == '__main__':
    mock = Mock(side_effect=[1, 2, 3])
    print(mock())
    print(mock())
    print(mock())

- 인자 설정

side_effect에 함수를 넘기면 mock 객체를 호출할 때 매개변수에 따라 다른 값을 반환할 수도 있다.

from unittest.mock import Mock, MagicMock, call


if __name__ == '__main__':
    mock = Mock(side_effect=lambda x: x * 10)
    print(mock(2))

- 속성

mock 객체는 속성을 가질 수도 있는데, 이 속성도 mock 객체에 해당한다. 따라서 특정 속성에 값을 할당할 수도 있고, 반환값을 지정할 수도 있다.

from unittest.mock import Mock, MagicMock, call


if __name__ == '__main__':
    mock = Mock()
    mock.attribute = 'ATTRIBUTE'
    mock.method.return_value = 'METHOD RETURN VALUE'

    print(mock.attribute)
    print(mock.method())

mock 객체의 return_value나 side_effect는 생성 이후에도 추가할 수 있다.

Mock 객체 검증

mock 객체는 작업을 검증할 수 있도록 도와주는 다양한 메서드를 제공한다.

그중 호출 여부를 검증하는 assert_callecd는 가장 일반적으로 사용되는 메서드로, mock 객체를 한 번도 호출하지 않으면 예외가 발생한다.

from unittest.mock import Mock, MagicMock, call


if __name__ == '__main__':
    mock = Mock()
    mock.assert_called()

비슷한 메서드 중 assert_called_once는 mock 객체가 한 번 호출되었는지 검증하고, assert_called_with는 호출될 때 어떤 인자가 넘어왔는지 검증한다.

from unittest.mock import Mock, MagicMock, call


if __name__ == '__main__':
    mock = Mock()
    mock(1, 2, c=3)
    mock.assert_called_once()
    mock.assert_called_with(1, 2, c=3)

call_count나 call_args 등의 속성은 mock 객체가 몇 번 호출되었는지, 어떤 인자로 호출되었는지를 기억한다.

from unittest.mock import Mock, MagicMock, call


if __name__ == '__main__':
    mock = Mock()
    mock(1, 2, c=3)
    print(mock.call_count)
    print(mock.call_args)

참고 문서

https://daleseo.com/python-unittest-mock/

https://docs.python.org/ko/3/library/unittest.html

[Python] unittest - 예외 발생 확인

비번변경 — Mon, 16 Mar 2026 10:28:29 +0900

개요

2026.03.10-[Python] unittest - 단위 테스트에서 unittest의 기본적인 사용법에 대해 알아보았다. 그런데 테스트 케이스를 작성하다 보면 로직이 정상적으로 동작하는 경우가 아니라 예외가 발생해야 하는 상황에서 예상한 예외가 발생하는지도 확인할 필요가 있다. 이번 글에서는 예외 발생 여부를 확인하는 방법을 적어둔다.

assertRaises

예외가 발생하는지 테스트를 해야 할 때는 assertRaises를 컨텍스트 매니저(with 문)과 함께 사용한다.

with self.assertRaises(Exception):
	LOGIC_CODE

assertRaises는 전달받은 예외가 발생하면 테스트를 통과하고, 다른 예외가 발생하면 오류에 해당한다. 아무 예외도 발생하지 않으면 실패인 걸로 판단한다.

예시 코드

간단하게 숫자를 0으로 나눴을 때 ZeroDivisionError가 발생하는지 확인해 보자.

import unittest
from unittest import TestCase

class MyTests(TestCase):
    def test_execpt(self):
        with self.assertRaises(ZeroDivisionError):
            1 / 0

지정한 에러가 발생하여 테스트가 통과한 것을 알 수 있다. 그리고 아예 Exception으로 지정하면 당연히 통과한다.

TypeError를 지정하면 오류가 난다.

에러를 일으키지 않으면 아래와 같은 결과가 발생한다.

참고 문서

https://docs.python.org/ko/3.14/library/unittest.html

https://daleseo.com/python-unittest-testcase/

[Python] unittest - 단위 테스트

비번변경 — Fri, 13 Mar 2026 11:28:53 +0900

개요

개발 과정에서 테스트는 필수적이다. 하지만 여태까지 테스트 코드를 작성해 본 적은 없는데, 이유는 여럿이 있겠지만 근본 원인은 잘 몰라서였다. 인터넷에서 떠도는 테스트 주도 개발이라는 게 뭔지, 그래서 어떤 함수를 테스트해야 하는지 등등……. 다만 일단 작성 방법을 알아야 할 것 같으니 Python으로 테스트 코드를 작성하도록 도와주는 unittest라는 라이브러리의 사용 방법을 조금 알아보고자 한다.

unittest

Python의 unittest는 Java JUnit, JavaScript Jest와 같은 단위 테스트 프레임워크이다. 기본적으로 내장되어 있어 바로 임포트 해서 사용할 수 있다.

import unittest

TestCase

단위 테스트는 단위 클래스에 필요한 유틸리티 메서드를 제공하는 unitest.TestCase 클래스의 자식 클래스를 구현함으로써 작성한다.

예시는 1과 2의 합이 3과 동일하면 통과하는 테스트 케이스이다.

from unittest import TestCase


class MyTests(TestCase):
    def test_one_plus_two(self):
        self.assertEqual(1 + 2, 3)

실행

테스트는 기본적으로 unittest 모듈로 python 파일을 실행하는 방식으로 실행할 수 있다.

python -m unittest TEST_FILE.py

테스트가 실패한 경우에는 왜 실패했는지 확인할 수 있다.

보다 단순하게 실행시키고 싶다면 테스트 코드 파일에 아래와 같음 main을 추가하여 일반 Python 파일 실행하듯이 실행할 수 있다.

if __main__ == '__main__':
    unittest.main()

실행

python TEST_FILE.py

assertion

unittest는 여러 유형의 assert 문을 제공하고 있다. 가장 많이 사용하는 것은 아래와 같다.

from unittest import TestCase


class MyTests(TestCase):
    def test_one_plus_two(self):
        self.assertEqual(1 + 2, 3)

    def test_other_assertions(self):
        self.assertTrue(1 == 1) # 참
        self.assertFalse(1 == 2) # 거짓
        self.assertGreater(2, 1) # >
        self.assertLess(1, 2) # <
        self.assertIn(1, [1, 2]) # 포함
        self.assertIsInstance(1, int) # 데이터 타입

참고 문서

https://daleseo.com/python-unittest-testcase/

https://wikidocs.net/16107

[Terraform] external - 외부 프로그램 연동

비번변경 — Thu, 12 Mar 2026 10:46:45 +0900

개요

Terraform 코드를 작성하면서 별도로 작성한 스크립트를 실행해야 하는 케이스가 있었다. 이런 경우 외부 프로그램을 연동할 때 사용하는 external 프로바이더를 활용할 수 있는데, 이번 글에서는 그 사용법을 확인하려고 한다.

external

terraform과 외부 프로그램 간의 인터페이스를 제공하는 특수한 프로바이더이다. 프로바이더가 없는 시스템과 연동할 때 유용하지만 정식 프로바이더만큼 강력하지는 않다는 한계점이 있다. 또한 외부 프로그램에 대한 종속성이 생기기 때문에 운영 체제에 따라 사용 가능성이 달라지거나 이식성이 저하될 수 있다.

external 프로바이더는 external 데이터소스를 제공한다. 표준 입력으로 JSON 형식의 데이터를 전달하고 표준 출력으로 JSON 형식의 데이터를 받을 수 있다.

Terraform → 외부 프로그램 실행 → JSON 결과 받기 → Terraform에서 사용

external 데이터소스를 사용할 때는 사용할 프로그램(program)을 필수로 지정해주어야 하고, 필요한 경우 프로그램 실행 시 사용할 매개변수(query)와 프로그램의 디렉터리 (working_dir)를 전달한다.

사용법

1. 프로바이더 추가

terraform {
  required_providers {
    external = {
      source = "hashicorp/external"
      version = "2.3.5"
    }
  }
}

provider "external" {
  # Configuration options
}

프로바이더 추가 코드는 생략해도 크게 문제는 없는 것 같다.

2. 외부 프로그램 작성

테라폼에서 실행할 프로그램을 작성한다. 아래는 매개변수 foo, bar를 전달받아 하나의 문자열로 연결한 결과를 반환하는 쉘 스크립트다.

#!/bin/bash

# Exit if any of the intermediate steps fail
set -e

# Extract "foo" and "baz" arguments from the input into
# FOO and BAZ shell variables.
# jq will ensure that the values are properly quoted
# and escaped for consumption by the shell.
eval "$(jq -r '@sh "FOO=\(.foo) BAZ=\(.baz)"')"

# Placeholder for whatever data-fetching logic your script implements
FOOBAZ="$FOO $BAZ"

# Safely produce a JSON object containing the result value.
# jq will ensure that the value is properly quoted
# and escaped to produce a valid JSON string.
jq -n --arg foobaz "$FOOBAZ" '{"foobaz":$foobaz}'

입출력은 다음과 같다.

3. external 데이터 소스 구성

program에 실행할 명령어와 스크립트를 전달하고, 스크립트에서 사용할 매개변수를 query로 전달한다.

data "external" "example" {
  program = ["bash", "${path.module}/example-data-source.sh"]

  query = {
    # arbitrary map from strings to strings, passed
    # to the external program as the data query.
    foo = "abc123"
    baz = "def456"
  }
}

output "foobaz" {
  value = data.external.example.result.foobaz
}

결과를 확인하기 편하도록 output으로 지정하고 terraform plan을 수행한다.

사전에 확인했던 대로 foo, baz로 전달한 문자열이 공백을 구분자로 연결된 모습을 확인할 수 있다.

참고 문서

https://registry.terraform.io/providers/hashicorp/external/latest

[Grafana] too many consecutive incorrect login attempts for user - login for user temporarily blocked

비번변경 — Wed, 11 Mar 2026 10:34:44 +0900

개요

Grafana에 로그인을 하려고 했는데 맞는 계정정보를 입력해도 로그인이 되질 않았다.

원인을 확인해 보고 현상을 해결해 본다.

원인

Grafana는 ubuntu에서 docker compose로 설치해 둔 상태다. 파일 로그는 딱히 보이지 않아 컨테이너 로그를 확인해 보니 아래와 같은 내용을 찾을 수 있었다.

logger=context userId=0 orgId=0 uname= t=2026-03-03T06:56:15.634017708Z level=info msg="Request Completed" method=POST path=/login status=401 remote_addr=100.100.100.100 time_ms=0 duration=990.695µs size=94 referer=http://100.100.100.100:3000/login handler=/login status_source=server errorReason=Unauthorized errorMessageID=password-auth.failed error="too many consecutive incorrect login attempts for user - login for user temporarily blocked"

로그인 실패 횟수가 누적되어 일시적인 로그인 차단이 발생한 것으로 보인다. 로그 상의 내용만 보면 일정 시간이 지나면 로그인이 가능해질 것 같은데, 정확히 언제부터 가능한지는 나오지 않는 것 같다. 아마 5분 정도인 듯?

해결

관리자 권한으로 비밀번호를 변경해 주면 즉시 로그인이 가능한 것 같다. 변경할 때는 기존 비밀번호로 초기화해도 괜찮다.

1. 사용자 관리 페이지 이동

메뉴 > 관리 > 사용자 및 액세스 권한 > 사용자로 접근한다.

2. 비밀번호를 초기화할 사용자 선택

3. 비밀번호 편집

편집 버튼을 클릭하면 아래와 같이 입력 폼이 표시된다. 원하는 값으로 설정하여 Save 버튼을 클릭한다.

4. 로그인 확인

정상적으로 로그인이 되는지 확인한다. 계정의 비밀번호를 변경하면 기존에 로그인되어 있던 세션이 전부 끊어지며 새로 로그인을 해야 하는 것으로 보인다.

참고 문서

https://github.com/grafana/grafana/issues/30161

[Java] generic - 2

비번변경 — Tue, 10 Mar 2026 10:29:01 +0900

개요

2026.03.03-[Java] generic - 1에서 generic이 무엇인지, 기본적인 개념 위주로 정리했다. 이번 글에서는 조금 더 세부적이고 소소한 내용을 정리한다.

타입 파라미터 할당 가능 타입

generic 할당은 Reference 타입만 가능하다. int, double과 같은 원시(Primitive) 타입 대신 Integer, Double을 사용해야 한다. 클래스로 지정하기 때문에 개체 지향 프로그래밍의 다형성 원리도 적용된다. 예로 들어 Apple, Banana라는 두 개 클래스가 Fruit이라는 클래스의 자식 클래스일 때, generic에 Fruit이라고 지정하면 Apple, Banana도 취급할 수 있다.

class Fruit { }
class Apple extends Fruit { }
class Banana extends Fruit { }

class FruitBox<T> {
    List<T> fruits = new ArrayList<>();

    public void add(T fruit) {
        fruits.add(fruit);
    }
}

public class Main {
    public static void main(String[] args) {
        FruitBox<Fruit> box = new FruitBox<>();
        
        // 제네릭 타입은 다형성 원리가 그대로 적용된다.
        box.add(new Fruit());
        box.add(new Apple());
        box.add(new Banana());
    }
}

복수 타입 파라미터

generic에는 여러 개의 타입을 지정할 수 있다. 여러 개를 지정할 때는 다이아몬드 연산자 안에 쉼표로 구분한다.

import java.util.ArrayList;
import java.util.List;

class Apple {}
class Banana {}

class FruitBox<T, U> {
    List<T> apples = new ArrayList<>();
    List<U> bananas = new ArrayList<>();

    public void add(T apple, U banana) {
        apples.add(apple);
        bananas.add(banana);
    }
}

public class Main {
    public static void main(String[] args) {
    	// 복수 제네릭 타입
        FruitBox<Apple, Banana> box = new FruitBox<>();
        box.add(new Apple(), new Banana());
        box.add(new Apple(), new Banana());
    }
}

중첩 타입 파라미터

타입 파라미터에는 generic 객체를 지정할 수도 있다.

public static void main(String[] args) {
    // LinkedList<String>을 원소로서 저장하는 ArrayList
    ArrayList<LinkedList<String>> list = new ArrayList<LinkedList<String>>();

    LinkedList<String> node1 = new LinkedList<>();
    node1.add("aa");
    node1.add("bb");

    LinkedList<String> node2 = new LinkedList<>();
    node2.add("11");
    node2.add("22");

    list.add(node1);
    list.add(node2);
    System.out.println(list);
}

타입 파라미터 네이밍

지금까지 generic을 표기할 때 <T>와 같이 표현했으나, 문법적으로 정해진 값은 없다. 다만 암묵적으로 T를 많이 사용하고 여러 generic이 필요한 경우에는 S, U 등으로 표기한다. 타입 외의 요소를 표현할 때는 암묵적으로 아래와 같인 규칙을 따른다.

타입	설명
<T>	타입(Type)
<E>	요소(Element), 예를 들어 List
<K>	키(Key), 예를 들어 Map<k, v>
<V>	리턴 값 또는 매핑된 값(Variable)
<N>	숫자(Number)
<S, U, V>	2번째, 3번째, 4번째에 선언된 타입

참고 문서

☕ 자바 제네릭(Generics) 개념 & 문법 정복하기

https://st-lab.tistory.com/153

[AWS] Aurora vs RDS

비번변경 — Mon, 9 Mar 2026 11:12:23 +0900

개요

기존에는 AWS의 데이터베이스 서비스 중 RDS를 주로 사용해왔는데, 현재는 Aurora도 사용을 하고 있다. Aurora가 보다 AWS에 친화적인 서비스라는 건 알고 있지만 다른 차이점은 알고 있지않아 정리해보려고 한다.

AWS Aurora

AWS Aurora는 데이터베이스 서비스 중 하나로 클라우드 네이티브 기반의 고성능, 고확장성 데이터베이스 서비스로 설계되어 MySQL, PostgreSQL을 제공한다. RDS와 비교하면 최대 3배의 read replicas와 MySQL 대비 5배, PostgreSQL 대비 3배의 처리량을 제공한다.

RDS가 제공하는 모든 관리 기능 뿐만 아니라 서버리스 서비스도 제공하고 있다.

Aurora는 기존의 데이터베이스 엔진을 커스트마이징해 AWS에 최적화한 게 특징으로, EBS 대시 NVMe SSD에 구축해 보다 빠른 성능 상의 이점을 갖고 있다. 또한 애플리케이션에 따라 자동을 확장되며, 6개의 데이터 복사본을 생성해 여러 위치에 배포한뒤 S3에 지속적으로 백업하는 특징을 가진다.

엔드포인트

Aurora는 4개의 엔드포인트를 가진다.

- Cluster Endpoint : Writer 인스턴스만 접근하는 엔드포인트로, failover되면 엔드포인트에 매핑되는 인스턴스가 변경된다.

- Read Endpoint : read replica를 그룹화한 엔드포인트로 라운드로빈으로 접근한다.

- Instance Endpoint : 각 인스턴스에 할당된 엔드포인트

- Custom Endpoint : Route53와 유사한 역할을 하며 사용자가 직접 엔드포인트를 생성한다.

Aurora vs RDS

Aurora와 RDS의 유지 관리는 전반적으로 유사하지만 스토리지에는 큰 차이가 있다.

Aurora는 데이터 용량이 증가할수록 클러스터 볼륨이 최대 128 TiB까지 자동으로 확장될 수 있다. 반면 RDS는 사용자가 직접 볼륨을 증설해주어야 한다. 또한 EBS를 사용하는 RDS와 달리 Aurora는 Shared Storage를 사용하며, MySQL의 경우에는 Binlog 기반의 replication이 아니라 Storage와 Page 기반의 replication을 사용한다. 즉, 스토리지 수준에서 복제가 발생한다.

Aurora는 AWS가 개발해 주기적으로 버전 업그레이드를 수행하기 때문에 AWS가 mandatory, optional을 정하는 반면, RDS는 사용자가 버전 업그레이드를 한다.

참고 문서

https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_AuroraOverview.html

https://www.cloudzero.com/blog/aurora-vs-rds/

https://www.geeksforgeeks.org/devops/aws-rds-vs-aurora/

https://norgb.tistory.com/22

[Java] generic - 1

비번변경 — Fri, 6 Mar 2026 10:04:28 +0900

개요

2026.02.25-[Java] ArrayList 등의 글에서 리스트 내 데이터 원소의 타입을 지정할 때 데이터 타입을 꺽쇠로 감싸서 지정하는데, 이는 제네릭(generic)이라는 개념이다. 뭔지 정확하게 모르고 사용을 해왔으니 이번 글에서는 generic에 대해서 조금 다뤄볼까 한다.

generic

generic은 사전적으로 '일반적인'이라는 의미를 가지고 있는데, Java에서는 하나의 값이 데이터 형식에 의존하지 않고 여러 데이터 타입을 가질 수 있도록 하는 방법을 의미한다. 다른 말로는 클래스 내에서 사용할 데이터 타입을 외부에서 지정하는 기법이라고 한다.

ArrayList<String> list = new ArrayList<>();

주로 List 등에 사용되는데, List와 같은 자료구조를 직접 구현하여 배포하려고 한다. 이 자료구조는 String, Integer, Double 등 다양한 타입을 지원하고자 한다. 이때 각 데이터 타입에 대한 클래스를 별도로 구현해야 할까? 이러한 비효율을 해소하기 위해 generic을 사용한다.

ArrayList 선언을 통해 확인할 수 있듯, generic은 컬렉션 내에서 사용할 내부 데이터 타입을 파라미터로 전달하듯 외부에서 지정한다. 조금 풀어서 말하면 타입을 변수화한 것이라고 생각할 수 있다.

장점

컴파일 시 타입 오류 방지

generic은 java 1.5에 추가된 기법으로, 그 전에는 여러 타입을 다루기 위해서는 Object를 사용했다. 이때 객체를 다시 원하는 타입으로 변환해주어야 했기 때문에 런타임에서 오류가 발생할 가능성이 많았다.

하지만 generic을 사용하면 컴파일 타임에 타입 오류를 확인할 수 있기 때문에 개발에 용이하다.

불필요한 캐스팅 방지

Object를 통해 여러 타입을 다룰 때는 요소를 가져오면서 다운캐스팅이 필요했다. 하지만 generic은 사전에 데이터 타입을 지정하고 제한하기 때문에 캐스팅에 대한 번거로움과 오버헤드를 줄일 수 있다. 뿐만 아니라 타입 검사에 들어가는 메모리도 절감하며 가독성도 챙길 수 있다.

제네릭 타입 매개변수

generic에서 데이터 타입을 지정하는 꺽쇠는 다이아몬트 연산자라고 한다. 꺽쇠 내에 식별자 기호를 지정함으로써 파라미터화하는데, 메서드가 매개변수를 받아 사용하는 것과 비슷하기 때문에 타입 매개변수, 타입 변수라고 부른다.

타입 매개변수는 generic을 이용한 클래스, 메서드를 설계할 때 사용한다. 아래는 generic을 사용한 클래스 정의 코드로, 클래스 이름 옆에 <T>로 generic을 붙여주었다.

class FruitBox<T> {
    List<T> fruits = new ArrayList<>();

    public void add(T fruit) {
        fruits.add(fruit);
    }
}

그리고 클래스 내에서 T를 클래스 필드와 메서드 매개변수의 타입으로 지정했다. 이를 인스턴스화하면 아래와 같다.

// 제네릭 타입 매개변수에 정수 타입을 할당
FruitBox<Integer> intBox = new FruitBox<>(); 

// 제네릭 타입 매개변수에 실수 타입을 할당
FruitBox<Double> intBox = new FruitBox<>();

// 다른 클래스
FruitBox<Apple> intBox = new FruitBox<Apple>();

생성 코드에서 다이아몬드 연산자 내에 타입을 지정하면 generic 클래스 선언 내에서 T로 지정된 부분이 모두 전달받은 타입으로 변환된다.

이것을 generic 타입 전파 또는 구체화라고 한다.

참고 문서

☕ 자바 제네릭(Generics) 개념 & 문법 정복하기

https://st-lab.tistory.com/153

[Python] psycopg2.execute_values - 여러 데이터 처리

비번변경 — Thu, 5 Mar 2026 17:14:06 +0900

개요

python으로 데이터베이스 작업을 수행하다 보면 여러 데이터를 한 번에 처리할 필요가 자주 발생한다. 이때 보통 executemay 등의 이름을 가진 함수를 사용하는데, postgreSQL 연동 라이브러리인 psycopg2의 경우에는 비슷한 기능을 가진 여러 함수를 제공하고 있는 것 같다. 이번 글에서는 그중 하나인 execute_values에 대해서 조금 알아본다.

execute_values

execute_values는 psycopg2 2.7버전에 추가된 함수로, 매개변수를 사용해 명령문을 실행한다.

psycopg2.extras.execute_values(cur, sql, argslist, template=None, page_size=100, fetch=False)
# cur : 커서 객체
# sql : 실행 SQL
# argslist : 쿼리에 전달할 인수
# template : 쿼리를 구성하는 arglist의 템플릿. 자리표시자 또는 명명된 자리표시자에 해당한다.
# page_size : arglist의 최대 개수. 초과 시 두 개 이상의 문장 실행.
# fetch : 쿼리 결과 반환 여부. RETURNING절이 포함된 경우 유용하다.

사용 자체는 일반 execute와 크게 다르지 않다. 아래는 테이블에 데이터를 추가하는 예시 코드이다.

import psycopg2
from psycopg2.extras import execute_values

host = 'host'
port = 5432
user = 'user'
password = 'user'
database = 'study'

# 1. 데이터 준비 (튜플의 리스트)
data = [(1, 'Alice'), (2, 'Bob'), (3, 'Charlie')]

# 2. 커넥션 및 커서 생성
with psycopg2.connect(host=host, port=port, user=user, password=password, database=database) as conn:
    cur = conn.cursor()

    # 3. execute_values 사용
    sql = "INSERT INTO users (id, name) VALUES %s"
    execute_values(cur, sql, data)

    conn.commit()

다만 동작 방식에 있어서 executemany에 차이가 있다고 한다.

executemany vs execute_values

psycopg2의 executemany는 for 반복문을 사용해 execute를 반복 실행하는 방식으로 동작한다. 때문에 대량의 데이터를 삽입할 때에는 성능 상 이점이 없다. 이러한 문제를 해소하기 위해 반복실행에 최적화된 함수로 execute_batch와 execute_values가 존재한다.

execute_batch의 경우 executemany와 비슷하지만 SQL을 하나로 묶어서 전송한다는 차이가 있다. 예시로 아래의 3개 쿼리를 실행한다고 하면 executemany는 한 줄씩 전달하지만, execute_batch는 세 줄을 한 번에 전달한다는 의미이다.

INSERT INTO simple_table (a, b, c) VALUES (1, 2, 3);
INSERT INTO simple_table (a, b, c) VALUES (10, 20, 30);
INSERT INTO simple_table (a, b, c) VALUES (100, 200, 300);

반면 execute_values는 values에 값을 여러 개로 묶어서 전달한다. 즉, 하나의 insert만 수행한다.

INSERT INTO simple_table (a, b, c) VALUES
    ((SELECT id FROM num_table WHERE number = 1), 2, 3),
    ((SELECT id FROM num_table WHERE number = 10), 20, 30),
    ((SELECT id FROM num_table WHERE number = 100), 200, 300);

execute_values가 반복도 없고, 실행 쿼리도 적기 때문에 다른 함수보다 성능 상의 이점을 갖고 있다고 할 수 있다.

참고 문서

https://www.psycopg.org/docs/extras.html#psycopg2.extras.execute_values

https://brownbears.tistory.com/567

https://int-i.github.io/python/2022-02-27/python-postgres-psycopg2-bulk-insert/

[Java] ArrayList

비번변경 — Wed, 4 Mar 2026 09:57:58 +0900

개요

이번 글에서는 Java에서 매우 흔하게 사용하고 있는 ArrayList에 대해서 정리한다.

ArrayList

ArrayList는 Array의 불편함을 해소하기 위해 나온 개념으로, 연속적인 데이터의 리스트이다.

내부적으로 Object[]을 이용하고 있으며, 인덱스를 이용해 요소에 빠르게 접근할 수 있다. 배열과 다르게 크기가 가변적(동적 할당)이지만, 배열의 크기가 가득 찰 때마다 copy 하는 방식으로 크기를 조정하기 때문에 지연이 발생할 수 있다. 데이터를 중간에 삽입하거나 삭제하는 경우에는 리스트 내 공간 조정으로 인해 요소의 위치가 앞뒤로 이동하기 때문에 동작이 느리다.

사용법

ArrayList를 사용할 때는 패키지를 import 해야 한다.

import java.util.ArrayList;

아래 내용은 기본적인 ArrayList 사용법을 나열한 것이다.

생성

ArrayList는 빈 리스트를 생성하거나, 길이를 사전에 지정하거나 다른 컬렉션으로 초기화하는 방식으로 생성할 수 있다.

// 타입설정 Integer 객체만 적재가능
ArrayList<Integer> members = new ArrayList<>();

// 초기 용량(capacity)지정
ArrayList<Integer> num3 = new ArrayList<>(10);

// 배열을 넣어 생성
ArrayList<Integer> list2 = new ArrayList<>(Arrays.asList(1,2,3));

// 다른 컬렉션으로부터 그대로 요소를 받아와 생성
ArrayList<Integer> list3 = new ArrayList<>(list2);

요소 추가

요소는 제네릭으로 명시한 타입의 데이터만 추가할 수 있다. 참고로 capacity는 공간 크기이고, size는 리스트 내 요소의 개수에 해당한다.

// 리스트의 마지막에 객체 추가
list.add(VALUE);

// 전달받은 컬렉션의 모든 객체를 저장
list.addAll(VALUES);

요소 추가 - 위치 지정

add 나 addAll 메서드에 index를 전달하여 데이터를 저장할 위치까지 지정한다.

다만 로직 상 다른 요소의 위치를 변경하기 때문에 성능이 좋진 않다. 또한 리스트의 크기를 초과하는 인덱스를 지정할 수는 없다.

// 리스트의 마지막에 객체 추가
list.add(INDEX, VALUE);

// 전달받은 컬렉션의 모든 객체를 저장
list.addAll(INDEX, VALUES);

요소 삭제

데이터를 삭제할 때는 remove나 clear 등을 사용한다. remove는 특정 위치나 특정 객체를 지정할 수 있고, removeAll을 사용하면 전달한 컬렉션과 동일한 객체를 모두 삭제한다. clear 같은 경우에는 리스트 내 모든 요소를 삭제한다.

list.remove(INDEX);

list.remove(VALUE);

list.removeAll(VALUES);

list.clear();

요소 조회

ArrayList는 리스트가 비어있는지, 객체가 리스트에 존재하는지, 어느 위치에 존재하는지 등을 확일할 수 있는 메서드를 제공한다.

// 리스트가 비었는지 확인
list.isEmpty();

// 객체의 포함 여부 확인
list.contains(VALUE);

// 객체의 위치 조회
list.indexOf(VALUE);

요소 얻기

요소를 얻을 때는 get 메서드를 사용한다.

list.get(INDEX);

참고 문서

자바 ArrayList 구조 & 사용법 정리

https://www.w3schools.com/java/java_arraylist.asp

[Java] 자바 ArrayList

[GitHub] GitHub Actions - GITHUB_STEP_SUMMARY

비번변경 — Tue, 3 Mar 2026 11:22:51 +0900

개요

GitHub Actions에는 각 Job 별 동작을 요약해서 보여줄 수 있는 GITHUB_STEP_SUMMARY을 지원한다. 사용자는 GITHUB_STEP_SUMMARY를 적절하게 사용해 동작의 진행과 결과를 간결하게 표현하고 확인할 수 있다.

GITHUB_STEP_SUMMARY

GITHUB_STEP_SUMMARY은 마크다운 형식을 사용하며 워크플로우 진행 중 리다이렉션 등을 사용해 내용을 입력한다.

echo "{markdown content}" >> $GITHUB_STEP_SUMMARY

GITHUB_STEP_SUMMARY는 steop에 대해 고유하고, job이 완료되면 모든 step에 대한 요약이 그룹화되어 페이지에 표시된다. 여러 job이 요약을 생성하는 경우에는 완료 시간을 기준으로 정렬된다.

GITHUB_STEP_SUMMARY는 파일이므로 rm을 사용해서 삭제할 수 있는데, 삭제 후에는 기존 콘텐츠에 대한 수정이 불가하니 주의할 필요가 있다.

사용 예시

간단하게 사용법을 알아보자.

- 단일 행 추가

아래 코드는 단일 행을 요약에 추가하는 예시다.

jobs:
  somethin:
    runs-on: ubuntu-latest
    steps:
      - name: summary
        run: echo "### Hello world! :rocket:" >> $GITHUB_STEP_SUMMARY

파일을 수정하고 워크플로우를 트리거하면 아래처럼 추가한 내용을 확인할 수 있다.

- 여러 줄 추가

아래는 여러 줄을 추가하는 예시이다. 일반 파일과 동일하게 리다이렉션으로 append하면 된다.

- name: Generate list using Markdown
  run: |
    echo "This is the lead in sentence for the list" >> $GITHUB_STEP_SUMMARY
    echo "" >> $GITHUB_STEP_SUMMARY # this is a blank line
    echo "- Lets add a bullet point" >> $GITHUB_STEP_SUMMARY
    echo "- Lets add a second bullet point" >> $GITHUB_STEP_SUMMARY
    echo "- How about a third one?" >> $GITHUB_STEP_SUMMARY

- job 별 SUMMARY 추가

하나의 JOB에서 추가하던 내용을 다른 JOB에서 추가하도록 변경했다.

name: test_summary
on:
  workflow_dispatch:
  
jobs:
  somethin:
    runs-on: ubuntu-latest
    steps:
      - name: summary
        run: echo "### Hello world! :rocket:" >> $GITHUB_STEP_SUMMARY
  el:
    runs-on: ubuntu-latest
    steps:
      - name: Generate list using Markdown
        run: |
          echo "This is the lead in sentence for the list" >> $GITHUB_STEP_SUMMARY
          echo "" >> $GITHUB_STEP_SUMMARY # this is a blank line
          echo "- Lets add a bullet point" >> $GITHUB_STEP_SUMMARY
          echo "- Lets add a second bullet point" >> $GITHUB_STEP_SUMMARY
          echo "- How about a third one?" >> $GITHUB_STEP_SUMMARY

이 경우에는 아래처럼 구분된 상태로 출력된다.

참고 문서

https://docs.github.com/ko/actions/reference/workflows-and-actions/workflow-commands

https://blog.outsider.ne.kr/1594

[Github] GitHub Actions - 수동 트리거 및 입력

비번변경 — Fri, 27 Feb 2026 10:43:54 +0900

개요

최근 GitHub Actions에 대한 기본 개념과 사용법에 대해서 간단히 알아보고 있는데, 주로 레포지터리에 push 이벤트가 발생했을 때 자동으로 트리거 되는 워크플로우를 다뤘다. 하지만 때로는 수동으로도 워크플로우를 트리거해야 하는 경우가 발생하곤 한다. 때문에 이번 글에서는 수동 트리거에 대해서 조금 정리해보려고 한다.

이벤트

2026.02.05-[GitHub] GitHub Actions - 변수에서 지나가듯이 언급했는데, 워크플로우를 수동으로 트리거 하고 싶을 때는 on 키워드에 workflow_dispatch를 지정한다.

on: workflow_dispatch

트리거 이벤트로 workflow_dispatch를 지정하면 워크플로우를 트리거할 수 있도록 버튼이 제공된다. 이때 어떤 브랜치를 사용할 건지 선택할 수 있다.

on: [push, workflow_dispatch]

push 이벤트와 함께 지정해 수동, 자동 혼용하는 것도 가능하다.

입력 제공

워크플로우를 수동으로 트리거할 때는 inputs를 통해 별도의 입력을 제공할 수 있다. 데이터 타입은 boolean, choice(selectBox), number, string, environment이다. 아래 예시는 tags라는 boolean 입력을 제공받도록 구성한 코드이다. 입력에는 설명, 필수 여부, 기본값 등을 함께 지정할 수 있다.

on:
  workflow_dispatch:
    inputs:
      tags:
        description: 'Test scenario tags'
        required: false
        type: boolean

예시

예시로 아래와 같은 코드로 github actions을 구성하자. 예시는 choice 형식의 logLevel, boolean 형식의 tags를 입력받아 step 내 환경 변수로 세팅하고 출력하는 코드이다.

on:
  workflow_dispatch:
    inputs:
      logLevel:
        description: 'Log level'
        required: true
        default: 'warning'
        type: choice
        options:
        - info
        - warning
        - debug
      tags:
        description: 'Test scenario tags'
        required: false
        type: boolean
jobs:
  log-the-inputs:
    runs-on: ubuntu-latest
    steps:
      - run: |
          echo "Log level: $LEVEL"
          echo "Tags: $TAGS"
        env:
          LEVEL: ${{ inputs.logLevel }}
          TAGS: ${{ inputs.tags }}

커밋 후 트리거를 시도하면 아래처럼 입력을 설정할 수 있도록 폼이 제공된다. 필수값 여부는 빨간 별로 구분하고, description으로 설정한 값이 표시되는 것으로 보인다.

원하는 값으로 설정 후 Run workflow 버튼을 누르면 설정한 값이 정상적으로 로드되어 출력되는 모습을 확인할 수 있다.

참고 문서

https://deku.posstree.com/ko/github_actions/execute-github-actions-manually/

https://docs.github.com/ko/enterprise-cloud@latest/actions/reference/workflows-and-actions/events-that-trigger-workflows#workflow_dispatch

https://docs.github.com/ko/enterprise-cloud@latest/actions/how-tos/manage-workflow-runs/manually-run-a-workflow

[GitHub] GitHub Actions - Job/Step 간 데이터 전달

비번변경 — Thu, 26 Feb 2026 10:19:37 +0900

개요

CI/CD 파이프라인을 생성하다 보면 설정 파일 등을 읽어 들여서 여러 Job, 여러 Step에서 사용하도록 구성하게 되는데 이때 필수적인 기능이 데이터 전달이다. 이번 글에서는 Step, Job 수준에서의 데이터 전달 방식에 대해서 정리해 둔다.

GITHUB_OUTPUT

Github Actions 내에서 발생한 출력은 GITHUB_OUTPUT이라는 환경 파일에 저장해 두었다가 접근하여 사용할 수 있다. 저장할 때는 접근할 때 사용할 키를 함께 지정해주어야 한다.

echo "{name}={value}" >> "$GITHUB_OUTPUT"

참조할 때는 "steps.STEP_ID.outputs.KEY" 형식으로 접근한다.

아래 예시는 SELECTED_COLOR를 설정하고 이후에 접근하는 모습을 보여준다.

      - name: Set color
        id: color-selector
        run: echo "SELECTED_COLOR=green" >> "$GITHUB_OUTPUT"
      - name: Get color
        env:
          SELECTED_COLOR: ${{ steps.color-selector.outputs.SELECTED_COLOR }}
        run: echo "The selected color is $SELECTED_COLOR"

기본적으로 하나의 job은 하나의 실행기 내에서 동작하므로 step 간 데이터는 별다른 설정 없이 GITHUB_OUTPUT을 통해 주고받을 수 있다.

Job 간 데이터 전달

반면 Job 간 데이터 전달은 Job 수준에서 output을 명시적으로 지정해주어야 한다. 이때 jobs.JOB_ID.output을 통해 어느 step의 출력을 내보낼 것인지 정의한다.

jobs:
  job1:
    runs-on: ubuntu-latest
    outputs:
      output1: ${{ steps.step1.outputs.test }}
      output2: ${{ steps.step2.outputs.test }}
    steps:
      - id: step1
        run: echo "test=hello" >> "$GITHUB_OUTPUT"
      - id: step2
        run: echo "test=world" >> "$GITHUB_OUTPUT"

이후 이 job에서 생성된 출력을 활용할 job은 jobs.JOB_ID.needs 구문을 사용해 Job 의존성을 설정하고, needs.JOB_ID.outputs.KEY 형식으로 output에 접근한다.

jobs:
  # Assume job1 is defined as above
  job2:
    runs-on: ubuntu-latest
    needs: job1
    steps:
      - env:
          OUTPUT1: ${{needs.job1.outputs.output1}}
          OUTPUT2: ${{needs.job1.outputs.output2}}
        run: echo "$OUTPUT1 $OUTPUT2"

두 Job을 그림으로보면 아래와 같은 구조가 된다.

실제로 동작시킨 결과를 보면 job1에서 설정한 output을 job2에서 읽어 들여 사용하고 있는 것을 확인할 수 있다.

참고 문서

https://docs.github.com/ko/actions/how-tos/write-workflows/choose-what-workflows-do/pass-job-outputs

https://docs.github.com/ko/actions/reference/workflows-and-actions/workflow-commands

[Terraform] Error: failed to get shared config profile, default 해결

비번변경 — Wed, 25 Feb 2026 11:24:33 +0900

개요

Github Actions 내에서 Terraform 실행 환경을 구성하고 있는데, terraform init 명령어 실행 중 아래와 같은 오류가 발생하면서 동작에 실패했다.

| - karpenter in .terraform/modules/karpenter/modules/karpenter
| ╷
| │ Error: failed to get shared config profile, default
| │
| │
| ╵

원인을 파악하고 문제를 해결해보자.

원인

이 테라폼 코드는 AWS를 대상으로 작업을 수행하는데, 인증 시 default라는 profile을 사용하도록 지정해 둔 상태이다.

그리고 로그를 보면 default 프로파일을 얻으려는 시도가 실패했음을 알리고 있다. GitHub Actions 워크플로우를 구성하면서 AWS 인증을 할 때 configure-aws-credentials 액션을 사용하도록 구성했는데, 이 액션은 명시적으로 default 프로파일을 생성하지 않고, 환경 변수를 설정하는 걸로 추측된다.

    - name: Configure AWS Credentials
      uses: aws-actions/configure-aws-credentials@v6.0.0
      with:
        aws-region: us-east-2
        role-to-assume: arn:aws:iam::123456789100:role/my-github-actions-role
        role-session-name: MySessionName

즉, GitHub Action 실행 환경 내에 사용하고자 하는 AWS default 프로파일이 없어서 발생한 문제이다.

해결

가장 간단한 해결 방법은 Terraform 코드 내에서 사용하도록 지정한 AWS 프로파일 설정을 제거하는 것이다.

하지만 코드 수정이 여의치 않다면 명령어 수행 시 Terraform을 덮어씌우는 방법이 해결책이 될 수 있다. 이 글의 경우에는 terraform init을 수행할 때 오류가 발생했고, 오류가 발생한 원인은 아래 Terraform 코드이다.

terraform {
  backend "s3" {
    bucket         = "sparrow-dw-tfstate"
    region         = "ap-northeast-2"
    key            = "tfstate/terraform.tfstate"
    profile        = "default"
  }
}

코드는 Terraform의 실행 결과 파일인 .tfstate를 AWS S3 버킷에 저장하도록 구성한 건데 default 프로파일을 사용하도록 지정되어 있다. 이 설정을 덮어쓸 때는 아래와 같이 -backend-config 옵션을 사용할 수 있다.

terraform init -backend-config="profile="

이 글의 경우에는 profile 설정을 제거해야 하므로 값을 지정하지 않도록 하면 된다.

참고 문서

https://github.com/aws-actions/configure-aws-credentials

https://developer.hashicorp.com/terraform/cli/commands/init

[Java] Stream - 사용법

비번변경 — Tue, 24 Feb 2026 10:43:04 +0900

개요

2026.02.10-[Java] Stream 개념에서 Java의 Stream 개념에 대해 알아보았다. 이번 글에서는 실제로 어떻게 사용하는지에 초점을 맞춰서 내용을 정리해 본다.

생성

Stream은 데이터 집합인 컬렉션, 다시 말해 Array, List, Set, Map 등으로부터 생성할 수 있다. 컬렉션이 제공하는 stream 메서드를 사용해 Stream을 생성한다.

List<String> list = new ArrayList<>();
list.add("Apple");
list.add("Banana");
list.add("Kiwi");

Stream<String> stream = list.stream();

또는 Stream에서 제공하는 generate, iterate 메서드 등을 사용해서 생성하는 것도 가능한다. generate는 무한한 값을 생성할 때, iterate는 이전 요소의 의존해서 다음 요소를 생성할 때 사용할 수 있다.

// Hello 문자열이 5개인 스트림
Stream<String> stream1 = Stream.generate(() -> "Hello").limit(5);

// 원소가 1부터 2배씩 커지되 값이 10 미만까지인 스트림
Stream<Integer> stream2 = Stream.iterate(1, n -> n < 10, n -> n * 2);

가공

데이터를 가공하는 역할로 filter, map, sorted, peek, dicstinct, limit 등이 존재한다.

// 필터링
integerStream.filter(n -> n % 2 == 0);

// map 변환
integerStream.map(n -> n * n);

// 정렬
integerStream.sorted();

// 중간 처리 값 확인(디버깅에 유용)
integerStream.sorted().peek(n -> System.out.println(n));

// 중복 제거
integerStream.map(n -> n % 3).distinct();

소비

결과를 생성하기 위한 최종 연산 과정이다. 일반적으로 데이터의 합계, 평균을 구하거나 다른 데이터 컬렉션 등으로 변환하는 처리가 이루어진다. 대표적인 소비 연산은 다음과 같다.

메서드	유형	설명
forEach	출력	각 요소를 순회하며 출력 등의 처리에 사용한다
reduce	소모	Stream의 요소를 줄여나가면서 연산을 수행한다. 처음 두 요소를 가지고 연산환 결과로 다음 요소와 연산하여 최종 결과값을 구한다.
findFirst	검색	특정 조건에 맞는 요소 검색. 시퀀셜 처리
findAny	검색	특정 조건에 맞는 요소 검색. 병렬 처리
anyMatch	검사	조건 만족 여부 확인
allMatch	검사	조건 만족 여부 확인
noneMatch	검사	조건 만족 여부 확인
count	통계	개수
min	통계	최소값
max	통계	최대값
sum	연산	합계
average	연산	평균
collect	수집	Stream 요소를 수집해 원하는 형태로 변환. Collector 인터페이스를 매개변수로 호출하며 Collectors 클래스에서 기정의한 메서드를 사용한다.

최종 연산 수행 후에는 더 이상 Stream으로 처리할 수 없다. 즉, 다시 데이터를 처리하기 위해서는 Stream을 새로 생성해야 한다.

참고 문서

https://www.elancer.co.kr/blog/detail/255

https://www.daleseo.com/java9-stream-iterate/

[Java] Stream 개념

비번변경 — Mon, 23 Feb 2026 10:19:22 +0900

개요

최근 기본적인 반복문과 조건문을 활용한 Java 코드를 AI에게 개선해달라 요청했더니 Stream이라는 개념을 가진 코드를 제안해주었다. 사용하고 유지보수를 하기 위해서는 관련 개념을 이해하고 있어야 할 것 같아 정리해보려고 한다.

Stream

프로그래밍 개발에서 Stream이란 '일련의 데이터 흐름'을 의미한다. 위키피디아의 경우에는 시간 상에 나타나는 일련의 데이터 요소로 정의하며 연속적인 데이터 흐름에 초점을 맞추고 있다.

Java의 Stream은 이러한 데이터 흐름을 표준화된 방법으로 쉽게 처리할 수 있도록 지원하는 클래스 집합이다. 경우에 따라, 요소의 Stream에 함수형 연산을 지원하는 클래스라 정의하기도 한다. 다시 말해 Java Stream을 이용하여 데이터를 함수형 연산을 통해 표준화된 방법으로 쉽게 가공하고 처리할 수 있다.

장점

가독성

Java Stream을 활용하면 명령형 방식이 아닌 선언적 방식으로 프로그래밍이 가능하고, 체이닝을 활용해 필터링, 매핑 정렬을 연속적으로 수행할 수 있다.

// 기존 방식
List<String> result = new ArrayList<>();
for (String userNumber : userNumbers) {
    if (userNumber.equals(targetNumber)) {
        result.add(userNumber);
    }
}

// Stream
userNumbers.stream()
           .filter(userNumber -> userNumber.equals(targetNumber))
           .collect(Collectors.toList());

예시 코드의 경우에는 코드 자체가 간략해서 크게 차이가 없지만 보다 복잡한 논리가 들어가게되면 많은 차이가 발생하게 된다.

유지보수성

복잡한 반복문과 조건문을 필연적으로 불필요하게 긴 코드를 유발하는데, 이로 인해 가독성이 현저하게 떨어지게 된다. Java Stream의 경우에는 같은 작업도 보다 간결하고 명확하게 표현할 수 있어 가독성을 확보하고 자연스럽게 유지보수성을 향상시킨다.

병렬 처리

데이터 흐름을 나눠 멀티 스레드로 병렬로 처리하고 처리 후 합치는 과정을 통해 대량의 데이터를 좀더 빠르게 처리할 수 있다. Java Stream의 경우 parallel, parallelStream이라는 연산을 추가하는 것만으로 병렬처리를 가능하게 한다.

구조와 특징

Java Stream은 데이터 처리 과정과 동일하게 '생성 -> 가공 -> 소비'의 구조로 이루어져 있다.

생성

데이터 컬렉션을 Stream으로 변환하는 과정을 통해 데이터 스트림을 생성하는 것을 의미한다. Stream을 사용해 가공하기 위해서 수행된다. 모든 데이터가 한 번에 메모리에 로드되지 않고 필요할 때만 로드하기 때문에 효율적인 메모리 사용이 가능하다.

가공

데이터 집합을 원하는 형태로 가공하는 중간 처리를 뜻하는데 필터링, 변형, 정렬 등이 해당된다. 중간 연산은 입력도 Stream이고 수행 결과도 Stream이라는 특징이 있다. 이 특징을 활용해 중간 연산을 연결함으로써 연속해서 수행할 수 있다.

소비

Stream에 대한 최종 연산을 통해 최종 목적물을 얻는 처리 과정을 의미하다. 수행 후 데이터 컬렉션이나 하나의 값을 얻을 수 있다. 결과값을 얻기 위한 1회 수행되고, 이후 Stream은 닫히게 된다. 데이터에 대한 추가 가공이 필요한 경우에느 신규 Stream을 생성하여야 한다. 즉, Stream을 일회성으로 사용한다.

Stream 처리는 모든 데이터에 대해 한 함수 실행이 끝나고 다른 함수가 수행되는 것이 아니라, 데이터가 나타난 흐름 순서대로 처리된다. 다시 말해 앞선 데이터가 먼저 처리되고 뒤의 데이터가 나중에 처리된다.

참고 문서

https://www.elancer.co.kr/blog/detail/255

[Java] HashSet

비번변경 — Fri, 13 Feb 2026 16:01:43 +0900

개요

2026.02.06-[Java] HashMap에서 HashMap에 대해서 살펴보았는데, 이번 글에서는 Set을 구현한 HashSet에 대해서 살펴본다.

HashSet

이름에서 추측할 수 있듯, HashSet은 Set 인터페이스를 구현한 클래스이다. 객체를 중복 저장할 수 없고 저장 순서를 유지하지 않는다는 Set의 성질을 그대로 이어받는다. 만약 순서를 유지해야 하거나 자동 정렬이 필요한 경우에는 LinkedHashSet, TreeSet과 같은 다른 구현 클래스를 사용하면 된다.

Set은 중복을 허용하지 않기 때문에 보통 중복을 제거하기 위해 많이 활용한다. 또한 비선형 구조로 인덱스가 존재하지 않기 때문에 값을 추가하거나 삭제할 때에는 Set에 값이 있는지 확인할 필요가 있기 때문에 List에 비해 다소 느리다.

중복 제거 방법

1. 객체를 저장하기 전 객체의 hashCode 메서드를 호출해 해시코드를 얻은 후 저장되어 있는 객체의 해시코드와 비교한다.

2. 같은 해시코드가 있다면 equals 메서드로 두 객체를 비교하여 true이면 동일한 객체로 판단하여 저장하지 않는다.

사용법

선언

인자로 키와 값 타입을 전달하며 기본생성자를 호출한다. 저장공간보다 값이 추가로 들어오면 공간을 늘리는데, 두 배씩 늘리기 때문에 저장할 데이터의 개수를 알고 있다면 초기 용량을 지정하는 것이 좋다.

import java.util.HashSet;

HashSet<Integer> set = new HashSet<Integer>();
HashSet<Integer> set = new HashSet<>();

# 초기 용량 지정
HashSet<Integer> set = new HashSet<Integer>(10);

값 추가

add 메서드를 사용해 Set에 값을 추가한다. 만약 기존재하는 값을 추가하려고 시도하면 false를 반환한다.

set.add(VALUE);

값 삭제

remove 메서드를 사용해 특정 값을 Set에서 삭제할 수 있다. 만약 없는 값을 삭제하려고 시도하면 false를 반환한다. Set 내 모든 값을 제거할 때는 clear를 사용한다.

set.remove(VALUE);

# 비우기
set.clear();

Set 크기

Set의 크기를 확인할 때는 size 메서드를 사용한다.

set.size();

값 존재 여부 확인

원하는 값이 Set 내에 존재하는지 확인하고 싶다면 contains 메서드를 사용한다. 존재하면 true를, 그렇지 않다면 false를 반환한다.

set.contains(VALUE);

순회

Set을 순회할 때는 반복자(iterator)를 활용한다. iterator 객체를 생성한 후, hasNext, next 메서드를 사용해 하나씩 값의 존재 여부를 확인하고 값을 가져올 수 있다.

HashSet<Integer> set = new HashSet<>();
Iterator iterator = set.iterator();
while (iterator.hasNext()) {
    System.out.println(iterator.next());
}

참고 문서

https://coding-factory.tistory.com/554

[Java] HashMap

비번변경 — Thu, 12 Feb 2026 14:57:54 +0900

개요

개발하고 있는 Java 애플리케이션에서 HashMap을 사용하는데, Java를 놓은지 오래 되었다보니 기본 개념만 겨우 기억하고 있다. 개발 진행에 필요한 개념을 다시 돌아보자.

HashMap

Map 인터페이스를 구현한 대표적인 Map 컬렉션이다. Map 인터페이스를 상속하고 있어 키와 값으로 구성된 Entry 객체를 저장하는 구조라는 Map의 성질를 그대로 갖고 있다. 키와 값은 모두 객체이며, 값은 중복을 허용하지만 키는 허용하지 않는다. 특히 HashMap의 경우에는 Hashing을 사용해 많은 양의 데이터를 검색하는 성능이 뛰어나다.

내부에 키와 값을 저장하는 자료 구조를 가지며, 해시 함수를 통해 키, 값이 저장되는 위치를 결정하므로 사용자는 그 위치를 알 수 없다. 또한 삽입 순서와 저장 위치와 관련도 없다.

기본 사용법

선언

import java.util.HashMap;

HashMap<String,String> map = new HashMap<String,String>();
HashMap<String,String> map = new HashMap<>();

# 초기 용량 지정
HashMap<String,String> map = new HashMap<>(10);

값 추가

pub 메서드를 사용하여 값을 추가한다. 동일 키에 값을 중복으로 지정하면 새 값으로 갱신된다.

map.put("key", "value");

값 삭제

값을 삭제할 때는 remove 함수를 사용한다. 모든 값을 삭제할 때는 clear를 사용한다.

map.remove("key");

# 모든 값 삭제
map.clear();

특정 키의 값 조회

지정한 키의 값을 조회할 때는 get을 사용한다.

map.get("key");

순회

HashMap을 순회할 때는 주로 keySet, entrySet을 사용한다. keySet은 HashMap의 키만 반환받아 사용하는 것이고, entrySet은 키와 값을 한 번에 받는다.

import java.util.Map.Entry;

public class Main {
    public static void main(String[] args) {
        HashMap<String, String> map = new HashMap<>();

        map.put("1", "사과"); //값 추가
        map.put("2", "바나나");

        for (Entry<String, String> entry : map.entrySet()) {
            System.out.println(entry.getKey() + " : " + entry.getValue());
        }

    }
}

참고 문서

https://coding-factory.tistory.com/556

https://www.w3schools.com/java/java_hashmap.asp

https://kadosholy.tistory.com/120

[GitHub] GitHub Actions - on

비번변경 — Wed, 11 Feb 2026 10:46:40 +0900

개요

GitHub Actions은 PR을 만들거나 이슈를 열거나 커밋을 푸시하는 행위가 발생할 때 트리거될 수 있는데, 이 트리거 조건은 on 키워드를 통해 설정할 수 있다. 이번 글에서는 on 키워드를 통해 Github Actions 트리거 조건을 어떻게 설정할 수 있는지 정리해두려고 한다.

on

Workflow는 on 키워드를 통해 트리거 이벤트를 정의할 수 있다. 이벤트는 하나 또는 여러 개 정의하거나 스케쥴을 설정할 수 있다. 또는 특정 파일이나 태그, 브랜치에 변경이 있을 때만 실행되도록 제한할 수도 있다.

단일 이벤트

on: push

조건 없이 push로 지정하면 어떤 브랜치든 push가 발생하면 실행하겠다는 의미이다.

여러 이벤트

이벤트를 여럿 지정할 때는 대괄호로 감싼다.

on: [push, fork]

사용 예시

on.<event_name>.types

types를 사용하면 트리거 이벤트의 유형을 정의할 수 있다.

예로 들어, issue_comment 이벤트에는 생성, 편집, 삭제 유형이 존재하는데, type을 별도로 지정하지 않고 issue_comment로만 지정하게 되면, issue_comment가 생성이 되든 삭제가 되든 Worflow가 실행된다. 하지만 type으로 유형을 지정하게 되면 지정한 유형의 이벤트가 발생한 경우에만 Worflow가 실행된다.

on:
  label:
    types:
      - created

필터링

일부 이벤트에는 Worflow 실행 시기를 보다 명확하게 지정할 수 있도록 하는 필터가 존재하는데, 바로 push 이벤트의 branches가 대표적인 예시이다.

on:
  push:
    branches:
      - main
      - 'releases/**'

branches 필터를 사용하는 임의 브랜치에 push 이벤트가 발생했을 때가 아니라, 원하는 브랜치에 push 이벤트가 발생했을 때만 workflow가 동작하도록 지정할 수 있다.

참고 문서

https://docs.github.com/ko/actions/how-tos/write-workflows/choose-when-workflows-run/trigger-a-workflow

https://docs.github.com/ko/actions/reference/workflows-and-actions/workflow-syntax#on

https://docs.github.com/ko/actions/reference/workflows-and-actions/events-that-trigger-workflows

[GitHub] GitHub Actions - Context와 Expression

비번변경 — Tue, 10 Feb 2026 10:15:58 +0900

개요

2026.02.05-[GitHub] GitHub Actions - 변수에서 GitHub Actions 내의 변수에 대해서 알아보았다. 이번 글에서는 관련해서 설명 없이 지나갔던 컨텍스트(Context) 개념과 식(Expression)에 대해서 정리해 본다.

Contexts

GitHub Actions에서 Contexts란 Workflow 실행, 변수, 실행 환경, job, step에 접근하는 방법으로, 문자열 또는 속성을 포함한 객체 일 수 있다. Contexts, 객체, 속성은 실행 조건에 의해 크게 달라지게 되며, 접근할 때는 Expression 구문을 사용한다.

${{ <context> }}

기본 환경 변수와 Context 간 차이점은 존재 범위에 있다. 기본 환경 변수는 작업을 수행하는 실행기에서만 존재하는 반면, Context는 Workflow의 모든 지점에서 사용할 수 있다. 이를 활용에 작업이 실행기로 라우팅 하기 전에 초기 처리를 수행할 수 있다. 아래 코드는 if 키워드와 컨텍스트를 사용해 단계 실행 여부를 결정하는 예시이다.

name: CI
on: push
jobs:
  prod-check:
    if: ${{ github.ref == 'refs/heads/main' }}
    runs-on: ubuntu-latest
    steps:
      - run: echo "Deploying to production server on branch $GITHUB_REF"

사용할 수 있는 컨텍스트는 굉장히 다양하니 아래 링크를 참고하면 좋을 것 같다.

문서: https://docs.github.com/en/actions/reference/workflows-and-actions/contexts

Expressions

Expressions은 Workflow에서 환경 변수를 프로그래밍적으로 설정하고 컨텍스트에 접근하는 방식이다. Expressions 은 문자열, 컨텍스트 참조, 합수 조합일 수 있는데, 일반적으로 워크플로우 파일에서 if 키워드와 함께 사용해 단계 실행 여부를 결정하는 방식으로 활용할 수 있다. Expressions을 사용할 때는 아래와 같은 형식을 통해 문자열로 처리되지 않도록 해야 한다. 예외적으로 if 절에서 식을 사용할 때는 ${{}}을 생략할 수 있다.

${{ <expression> }}

참고 문서

https://docs.github.com/ko/actions/concepts/workflows-and-actions/contexts

https://docs.github.com/ko/actions/concepts/workflows-and-actions/expressions

[GitHub] GitHub Actions - 변수

비번변경 — Mon, 9 Feb 2026 10:52:48 +0900

개요

2026.02.04-[GitHub] GitHub Actions - Workflow에서 Workflow 자체 대한 개념과 간단한 예시를 살펴보았다. 이번 글에서는 Workflow 내 변수에 대해서 살펴본다.

변수

여느 도구와 비슷하게 GitHub Actions에서의 변수도 민감하지 않은 구성 정보를 저장해 재사용하기 위한 방법을 제공한다. 주로 컴파일러 플래그, 사용자 이름, 서버 이름과 같은 데이터를 변수로 저장해 사용하며, Workflow를 실행하는 Runner에서 보간( interpollation)된다. Action, Step에서 실행되는 명령은 변수를 읽고, 생성하고, 갱신할 수 있다.

사용자는 사용자 필요에 의해 변수를 만들어서 사용하거나 GitHub 기본 설정 변수를 활용할 수 있다. 사용자 정의 변수는 크게 workflow 정의 파일 내 env 키를 사용하여 만들거나, organization, repository 수준에서 정의할 수 있다.

env

Worflow에서는 크게 최상위, Job, Step 수준에서 환경 변수를 구성하고 사용할 수 있다. 생성할 때는 env 키를 사용한다.

env: VALUE

참조할 때는 아래와 같이 참조한다.

# 최상위
env.MY_VARIABLE 

# JOB
jobs.<job_id>.env.MY_VARIABLE 

# STEP
jobs.<job_id>.steps[*].env.MY_VARIABLE

아래 예시는 각 수준에서 정의한 환경변수를 Step에서 참조하여 출력하는 코드이다.

name: Greeting on variable day

on:
  workflow_dispatch # 수동 실행 지정

env:
  DAY_OF_WEEK: Monday

jobs:
  greeting_job:
    runs-on: ubuntu-latest
    env:
      Greeting: Hello
    steps:
      - name: "Say Hello Mona it's Monday"
        run: echo "$Greeting $First_Name. Today is $DAY_OF_WEEK!"
        env:
          First_Name: Mona

on 키를 보면 workflow_dispatch로 지정되어 있는데, 이는 수동으로 실행하여 트리거하겠다는 의미이다. 때문에 레포지터리에 파일을 생성하고 트리거하면 아래와 같이 값이 잘 보간 되어 완전한 문자열이 출력되는 모습을 확인할 수 있다.

사용자 정의 변수

사용자는 레포지터리 또는 조직 수준에서 기본적인 변수나 환경 변수를 생성하여 사용할 수 있다. 생성 방법은 공식 문서에 잘 안내되어 있어서 따로 적어두진 않겠다.

문서 : https://docs.github.com/en/actions/how-tos/write-workflows/choose-what-workflows-do/use-variables#defining-configuration-variables-for-multiple-workflows

이 유형의 변수는 참조하는 방법이 조금 다른데 아래와 같은 형식으로 참조해야 한다.

${{ var.MY_VARIABLE }}

예로 들어 이 글의 경우에는 아래와 같이 TEST_VAR이라는 이름의 변수를 생성했다고 하자.

그리고 생성한 변수를 참조하기 위해 Workflow 정의 파일을 아래처럼 수정했다.

jobs:
  greeting_job:
    runs-on: ubuntu-latest
    env:
      Greeting: Hello
    steps:
      - name: "Say Hello Mona it's Monday"
        run: echo "$Greeting $First_Name. Today is $DAY_OF_WEEK!"
        env:
          First_Name: ${{ vars.TEST_VAR }} # 수정부

트리거해보면 First_Name이 기존과 달라진 모습을 확인할 수 있다.

GitHub 자체 제공 변수

GitHub에서 자체적으로 설정하고 제공하는 변수는 아무래도 GitHub 레포지터리와 관련된 정보에 해당한다. 빌드나 배포 작업을 수행하다보면 레포지터리 정보를 참조해야 하는 경우가 왕왕 있는데, 사용할 수 있는 변수는 공식 문서에 나열되어 있다.

문서 : https://docs.github.com/ko/actions/reference/workflows-and-actions/variables#default-environment-variables

참조할 때는 아래 형식을 사용한다.

$GITHUB_NAME

# 또는
${{ github.NAME }}

테스트를 위해 Workflow 정의 파일을 아래와 같이 수정했다.

jobs:
  greeting_job:
    runs-on: ubuntu-latest
    env:
      Greeting: Hello
    steps:
      - name: "Say Hello Mona it's Monday"
        # 수정부
        run: |
          echo "$Greeting $GITHUB_REPOSITORY. Today is $DAY_OF_WEEK!"
          echo "$Greeting ${{ github.repository }}. Today is $DAY_OF_WEEK!"

참고로 GITHUB_REPOSITORY는 레포지터리의 소유자와 레포지터리 이름을 확인할 수 있다.

이번엔 레포지터리 이름으로 잘 출력된 모습을 확인할 수 있다.

참고 문서

https://docs.github.com/ko/actions/concepts/workflows-and-actions/variables

[GitHub] GitHub Actions - Workflow

비번변경 — Fri, 6 Feb 2026 10:43:08 +0900

개요

2026.02.03-[GitHub] github-actions - 개념에서 GitHub Actions과 관련된 기본적인 개념에 대해서 익혀보았다. 이번 글에서는 Worflow에 초점을 두어서 살펴본다.

Workflow

Workflow는 하나 이상의 Job을 실행하는 구성 가능하고 자동화된 프로세스이다. 레포지터리 내 .github/workflows 경로에서 YAML 파일 형식으로 정의하며, 이벤트로 트리거 되거나 수동 트리거. 또는 스케쥴링에 의해 트리거 될 수 있다. 하나의 레포지터리는 여러 Workflow을 가질 수 있고, Workflow는 정의에 의해 다양한 작업을 수행할 수 있다.

Pull Request를 빌드하고 테스트한다.
릴리즈가 생성될 때마다 애플리케이션을 배포한다.
새 문제가 보고될 때마다 레이블을 추가한다.

Workflow는 다음과 같은 기본 요소가 포함되어 있어야 한다.

트리거 이벤트
하나 이상의 Job. 각 Job은 Runner에서 실행되고 하나 이상의 Step을 실행한다.
각 Step은 Action 또는 쉘 스크립트를 실행할 수 있다.

트리거

트리거는 Workflow을 실행하게 하는 이벤트다. 트리거는 다음과 같은 이벤트가 해당된다.

Workflow 레포지터리에서 발생하는 이벤트
Github 외부에서 발생해 Github repository_dispatch 이벤트를 트리거하는 이벤트
스케쥴링
수동

이러한 이벤트를 활용해 사용자는 레포지터리의 특정 브랜치에 푸식가 발생하거나 릴리즈가 생성되거나, 이슈가 열리면 실행되는 Workflow를 구성할 수 있다.

Workflow 실행을 트리거할 때는 아래의 과정이 수행된다.

레포지터리에 이벤트 발생. 이벤트는 커밋 해시나 git refs와 연결되어 있다.
Github가 레포지터리 내 .github/workflows 디렉터리에서 이벤트와 연결된 커밋 해시나 git refs와 관련된 workflow 정의 파일을 확인한다.
on: 에 설정된 값이 트리거 이벤트와 일치하는 모든 Workflow에 대해 실행이 트리거 된다.

Workflow는 이벤트와 연결된 커밋 해시나 git refs에 존재하는 workflow 정의 파일을 사용해 실행된다.

예시

예시로 공식 문서에서 제공하는 예시 Workflow를 생성해 본다.

문서 : https://docs.github.com/ko/actions/tutorials/create-an-example-workflow

테스트로 생성한 레포지터리에 파일을 생성해 보겠다. 아래 코드는 레포지터리를 pull 하고, bats 프레임워크를 설치한 뒤 bats 버전을 출력하는 예시이다.

name: learn-github-actions
run-name: ${{ github.actor }} is learning GitHub Actions
on: [push] # 이벤트
jobs:
  check-bats-version: # job 이름
    runs-on: ubuntu-latest # 실행기
    steps:
      - uses: actions/checkout@v5 # 실행 actions 지정
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm install -g bats # 실행 스크립트 지정
      - run: bats -v

예시 코드의 경우 on에 push가 지정되어 있어 푸시을 하면 바로 Worflow가 실행되는데, Actions 탭에서 확인할 수 있다.

실행 이력을 클릭하면 구성된 Job과 실행 상태를 확인 수 있다.

그리고 Job을 클릭하면 Step 단위의 실행 이력을 확인할 수 있다.

Step을 클릭하면 어떤 명령어가 실행되었는지, 무슨 출력이 발생했는지도 확인할 수 있다.

참고 문서

https://docs.github.com/ko/actions/concepts/workflows-and-actions/workflows

https://docs.github.com/ko/actions/tutorials/create-an-example-workflow

[GitHub] GitHub Actions - 개념

비번변경 — Thu, 5 Feb 2026 14:38:34 +0900

개요

기존에 업무하고 테스트하기 바빠서 GitHub Actions에 대한 개념 정리도 없이 GitHub Actions 테스트 도구인 act에 대한 글을 작성했었다. 이번 글에서는 그 공백을 좀 메꿔보고자 공식 문서를 참조해 개념 정리를 해보려고 한다.

Github Actions

GitHub Actions은 빌드, 테스트, 배포 파이프라인을 자동화할 수 있는 CI/CD 플랫폼으로, 레포지터리에서 이벤트가 발생할 때 워크플로우를 실행할 수 있도록 한다. Linux, Windows, macOS, 또는 사용자 정의 실행기에서 실행할 수 있다.

Github 버전의 gitlab cicd라고 이해하면 될 것 같다.

구성 요소

워크플로우 (Workflow)

하나 이상의 작업을 실행할 구성 가능한 자동화된 프로세스. 레포지터리 내 YAML 파일에서 정의되며, 레포지터리 이벤트로 트리거 되어 실행되거나 수동, 또는 스케줄에 의해 트리거 될 수 있다.

워크플로우는 레포지터리 내 .github/workflows 디렉터리에 정의되며 하나의 레포지터리는 여러 개의 워크플로우를 가질 수 있다. 또한 워크플로우는 다른 워크플로우를 참조할 수도 있다.

이벤트 (Event)

워크플로우 실행을 트리거하는 레포지터리 활동. PR을 만들거나 이슈를 열거나 커밋을 푸시하는 행위가 될 수 있다. 또는 일정에 따라, 수동으로 트리거할 수 있기도 하다.

작업 (Job)

동일한 실행 환경에서 실행되는 워크플로우 단계(step)의 집합. 단계는 실행 쉘 스크립트나 action으로 순서대로 실행된다. 또한 단계는 동일한 실행 환경에서 실행되기 때문에 데이터 공유가 가능하다.

작업은 기본적으로 종속성이 없으나 필요 시 종속성을 구성할 수 있다. 작업이 다른 작업에 종속되면, 대상 작업이 완료되기를 대기하게 된다.

액션 (Action)

미리 정의되어 재사용 가능한 작업 또는 코드 집합이다. 워크플로우 파일에 작성하는 반복 코드의 양을 줄일 수 있다. 일반적으로 GitHub 레포지터리 풀, 빌드 환경에 툴 세팅, CSP 인증 등의 작업 등이 필요할 때 사용한다.

실행기 (Runner)

워크플로우를 실행하는 서버. 한 번에 하나의 작업(Job)을 실행할 수 있다. Github은 기본적으로 Ubuntu Linux, Microsoft Windows, macOS 실행기를 제공한다. 필요시 사용자가 직업 실행기를 호스팅 하여 구성할 수 있다.

참고

https://docs.github.com/ko/actions

https://docs.github.com/ko/actions/get-started/understand-github-actions

[Terraform] for_each - 값 참조 시 기본값 지정

비번변경 — Wed, 4 Feb 2026 10:03:13 +0900

개요

2026.01.30-[Terraform] for_each - map, set 순회하며 리소스 생성에서 map과 같은 형식의 데이터를 순회하면서 리소스를 생성하는 방법을 알아보았는데, 간혹 순회하는 키의 값이 없는 경우도 발생하지 싶다. 보통 프로그래밍 언어에서는 이런 경우를 대비해 기본값을 설정할 수 있는 기능을 제공하는데 Terraform에도 비슷한 기능이 있는지 확인해보고자 한다.

try

Terraform에서 try 함수는 인자 표현식을 순차적으로 평가해 오류가 발생하지 않는 첫 번째 표현식의 결과를 반환한다. try는 인수를 평가할 때 발생할 수 있는 오류를 특수 함수로 구현 시점에 형태를 정확히 알 수 없는 복잡한 형태의 데이터 구조를 다룰 때 유용하다.

특히 외부 시스템에서 JSON 또는 YAML 형식의 데이터를 가져와 디코딩하는 경우, 설정 여부가 보장되지 않는 속성이 포함되어 있을 수 있다. 이 경우 try를 사용해 예측 가능한 유형을 가진 정규화된 데이터 구조를 생성해 구성의 다른 부분에서 더 편리하게 사용할 수 있다.

locals {
  example_map = { foo = "foo", bar = "bar" }
  keys        = ["foo", "bar", "baz"]
}

output "nomalize_map" {
  value = { for k in local.keys : k => try(local.example_map[k], null) }
}

lookup

lookup 함수는 주어진 키를 사용해 map에서 해당 요소의 값을 가져온다. 만약 키가 존재하지 않으면 기본값이 반환된다.

lookup(map, key, default)

try와는 다르게 map 데이터에 대해서만 사용할 수 있다.

예시)

locals {
  example_map = { foo = "foo", bar = "bar" }
  keys        = ["foo", "bar", "baz"]
}

output "nomalize_map" {
  value = { for k in local.keys : k => lookup(local.example_map, k, null) }
}

참고 문서

https://developer.hashicorp.com/terraform/language/functions/try

https://developer.hashicorp.com/terraform/language/functions/lookup

[Terraform] for_each - map, set 순회하며 리소스 생성

비번변경 — Tue, 3 Feb 2026 11:52:11 +0900

개요

2026.01.20-[Terraform] yamldecode - YAML을 HCL로 파싱하기에서 YAML 데이터를 hcl이 인식할 수 있는 형태로 파싱 했다. 이제는 이 데이터를 순회하면서 리소스를 만들기 위한 방법을 작성한다.

for_each

기본적으로 resource 블록은 하나의 인프라 객체를 생성한다. module 블록도 자식 모듈의 콘텐츠를 한 번 include 하고, action도 정의된 작업도 한 번 수행한다. for_each 블록은 이러한 블록이 유사한 형태로 여럿 필요할 때 활용할 수 있는데 resource, 모듈, map 블록에 for_each 인수가 포함되면 지정된 list, map 내 각 요소에 대해 작업을 한 번씩 호출한다.

for_each 메타 인자는 map 또는 문자열 set을 헐용하고, 각 항목에 대한 객체를 생성한다. 각 객체는 고유한 인프라와 연결되고 구성 변경 사항을 적용할 때마다 인스턴스를 생성, 갱신, 삭제한다.

사용자는 toset(), tomap()과 같은 함수를 사용해 for_each에 사용할 값을 생성할 수 있다. for_each가 반복할 값은 테라폼이 원격 리소스 작업을 수행하기 전에 알고 있어야 하기 때문에 객체 생성 시 구성이 적용된 후 알 수 있는 리소스 속성에 대한 참조를 지정하면 오류가 발생한다.

아래 예시는 tomap 함수를 통해 생성된 map을 참조해 두 개의 azurerm_resource_group 리소스를 생성한다.

resource "azurerm_resource_group" "rg" {
  for_each = tomap({
    a_group       = "eastus"
    another_group = "westus2"
  })
  name     = each.key
  location = each.value
}

아래 예시는 toset()으로 생성된 set을 사용해 4개의 aws_iam_user를 생성한다.

resource "aws_iam_user" "the-accounts" {
  for_each = toset(["Todd", "James", "Alice", "Dottie"])
  name     = each.key
}

특이한 점이 있다면 for_each는 민감 정보를 입력으로 전달하면 오류를 발생시킨다. for_each 값을 리소스 객체로 식별하고 출력하기 때문에 허용되지 않는다고 하니 참고할 필요가 있겠다.

for_each에 map이 전달된 경우, 각 개체는 키와 값을 참조할 수 있는 each.key, each.value 속성을 가진다. set이 전달되는 경우 each.key로 참조한다. 그리고 count와 마찬가지로 블록 자체는 TYPE.NAME으로 가리키는데, 각 객체는 TYPE.NAME[KEY]로 가리킨다.

사용 사례

for_each의 특징 중 하나는 for_each로 생성한 블록을 다른 블록의 for_each에 전달할 수 있다는 점이다. 이를 체인 패턴이라고 부르는데, aws 내 여러 vpc를 생성하고 각 vpc에 인터넷 게이트웨이를 생성해야 하는 경우 활용할 수 있다.

variable "vpcs" {
  type = map(object({
    cidr_block = string
  }))
}

resource "aws_vpc" "example" {
  # One VPC for each element of var.vpcs
  for_each = var.vpcs

  # each.value here is a value from var.vpcs
  cidr_block = each.value.cidr_block
}

resource "aws_internet_gateway" "example" {
  # One Internet Gateway per VPC
  for_each = aws_vpc.example

  # each.value here is a full aws_vpc object
  vpc_id = each.value.id
}

참고 문서

https://developer.hashicorp.com/terraform/language/meta-arguments/for_each

[Terraform] for - 요소 반복을 통한 값 생성

비번변경 — Mon, 2 Feb 2026 10:18:53 +0900

개요

2026.01.20-[Terraform] yamldecode - YAML을 HCL로 파싱하기에서 yamldecode로 yaml 파일을 map 형식의 데이터를 파싱 했는데, 조건에 따른 필터링 등의 작업이 필요해졌다. 확인해 보니 for 문을 사용하면 되는 것으로 보여 문법을 알아보고자 한다.

for

테라폼에서 for 문은 복합 타입을 다른 복합 타입의 데이터로 변환할 수 있게 한다. 예시로 아래 코드의 경우 var.list가 문자열 목록일 때 대문자 문자열 tuple을 생성한다. var.list의 각 요소에 대해 반복되며, 각 요소를 s로 칭하고 upper를 수행한 tuple 값을 생성한다는 의미이다.

[for s in var.list : upper(s)]

입력

for 문의 입력은 in 키워드 뒤에 위치하며 list, set, tuple, 맵, object 타입의 데이터가 올 수 있다. 아래 코드의 경우에는 k가 map의 키, v가 map의 값이 된다.

[for k, v in var.map : length(k) + length(v)]

입력이 list나 tuple인 경우에는 인덱스와 값을 대상으로 순회할 수도 있다.

[for i, v in var.list : "${i} is ${v}"]

다만 키나 인덱스는 선택적인 요소로, 만약 for 키워드 뒤에 단일 기호만 지정하면 해당 기호는 항상 값을 나타낸다.

출력

for 문은 for 문을 감싼 괄호의 유형에 따라 생성하는 결과를 결정한다. tuple을 생성하는 경우에는 대괄호를 사용하고, object를 생성하는 경우에는 중괄호를 사용한다. 또한 => 기호를 사용해 결과 표현식을 제공해주어야 한다.

{for s in var.list : s => upper(s)}

예로 들어 위의 표현식은 key가 원래 값이고 값이 대문자 값인 object를 생성한다.

{
  foo = "FOO"
  bar = "BAR"
  baz = "BAZ"
}

for은 기본적으로 tuple, object만 생성할 수 있지만 테라폼의 자동 타입 변환 규칙에 의해 list, map, set이 예상되는 위치에서 for 문에 의한 결과를 사용할 수 있다.

활용 예시

필터링

for 문으로 데이터를 만들 때는 원하는 데이터만 필터링할 수 있도록 if 절을 사용할 수 있다. 이를 활용해 하나의 데이터를 특정 기준에 따라 구분한 여러 개의 데이터로 나눌 수 있다.

[for s in var.list : upper(s) if s != ""]

정렬

for 문을 사용하면 정렬되지 않은 데이터(map, object, set)를 정렬되는 유형으로(list, tuple)로 변환할 수 있는데 이때 정렬 기준을 지정해주어야 한다. map, object의 경우 요소의 키나 속성이 기준이 될 수 있고, 문자열 set의 경우 값이 기준이 된다. 다른 타입의 set의 경우에는 임의 기준으로 정렬이 이뤄진다.

toset([for e in var.set : e.example])

참고 문서

https://developer.hashicorp.com/terraform/language/expressions/for

[Terraform] count - 리소스 반복 생성

비번변경 — Fri, 30 Jan 2026 10:27:41 +0900

개요

Terraform 코드를 작성하던 중 조건에 따라 리소스 생성 여부를 결정하고 싶다고 했더니 count 문법을 제안해 왔다. 제안은 채택하더라고 어떤 기능인지는 알고 사용해야 할 것 같아 내용을 정리한다.

count

기본적으로 리소스 블록은 하나의 인프라 개체를 구성한다. 다만 count 메타 인수를 사용하면 유사한 개체를 별도 블록으로 작성하지 않고 하나의 블록으로 작성할 수 있다. count 메타 인수는 data, ephemeral, module, resource, list에서 사용할 수 있다.

예로 들어 아래와 같은 data 블록이 있다고 하자.

data "http" "user_1" {
  url = "https://jsonplaceholder.typicode.com/users/1"
  request_headers = {
    # Authorization = ""
  }
}

이에 더해 user_2, user_3이 필요하다면 기본적으로 user_1과 비슷한 블록을 별도로 작성해야 한다.

data "http" "user_1" {
  url = "https://jsonplaceholder.typicode.com/users/1"
  request_headers = {
    # Authorization = ""
  }
}

data "http" "user_2" {
  url = "https://jsonplaceholder.typicode.com/users/2"
  request_headers = {
    # Authorization = ""
  }
}

data "http" "user_3" {
  url = "https://jsonplaceholder.typicode.com/users/3"
  request_headers = {
    # Authorization = ""
  }
}

즉, 반복이 발생하는데 data 블록에 count 메타 인수를 활용함으로써 반복 코드를 줄일 수 있다.

용법

사용법은 아주 간단하다. 반복 수행이 필요한 블록에 count 인자만 추가해주면 된다. 아래 예시는 동일한 ami, 타입의 aws ec2 인스턴스를 4개 생성하는 코드이다.

resource "aws_instance" "server" {
  count = 4 # create four similar EC2 instances

  ami           = "ami-a1b2c3d4"
  instance_type = "t2.micro"

  tags = {
    Name = "Server ${count.index}"
  }
}

count 값은 일반적으로 숫자 값을 허용한다. 다만 원격 리소스 작업을 수행하기 전에 값을 알고 있어야 하기 때문에 구성이 적용된 이후에 알 수 있는 리소스 속성은 사용할 수 없다.

count는 개별 개체를 식별하기 위해 인덱스를 사용하는데 count.index 형식으로 참조할 수 있고, 값은 0부터 시작한다. 이를 활용해 블록 자체는 TYPE.NAME / MODULE.NAME으로, 개별 리소스는 TYPE.NAME[INDEX] / MODULE.NAME[INDEX] 형식으로 가리킬 수 있다.

위에서 작성했던 예시 코드의 경우에는 같은 작업을 아래 코드로 변경할 수 있다.

data "http" "user" {
  count = 3

  url = "https://jsonplaceholder.typicode.com/users/${count.index}"
  request_headers = {
    # Authorization = ""
  }
}

사용 사례

count 메타 인수를 활용하는 몇 가지 사례에 대해서 알아보자.

여러 모듈 리소스 생성

아래 예시는 instance_names 로컬 변수를 사용해 ec2_instance 모듈읠 여러 개 생성하는 것이다. 이름은 instance_names를 활용하는데, count.index로 접근하여 활용한다.

locals { 
  instance_names = [ "web" , "api" , "batch" ] 
} 

module "ec2_instance" { 
  source   = "terraform-aws-modules/ec2-instance/aws" 
  version = "6.0.2" 
  count    = length(local . instance_names) 

  name            = local.instance_names[count.index] 
  ami             = data.aws_ami.latest_amazon_linux.id 
  instance_type   = "t2.micro" 

  depends_on = [aws_s3_bucket.example] 
}

리소스 생성 조건으로 활용

count 메타 인수는 삼항 연산자를 허용하고 있어 리소스 생성의 조건으로 활용할 수 있기도 하다.

아래 예시의 경우 creator 라는 변수가 있으면 리소스를 3개 생성하고, 그렇지 않으면 생성하지 않는다는 코드이다.

data "http" "user" {
  count = var.creator ? 3 : 0

  url = "https://jsonplaceholder.typicode.com/users/${count.index}"
  request_headers = {
    # Authorization = ""
  }
}

참고 문서

https://developer.hashicorp.com/terraform/language/meta-arguments/count

https://kimjingo.tistory.com/220

[YAML] 명시적 데이터 타입 선언

비번변경 — Thu, 29 Jan 2026 10:13:32 +0900

개요

YAML이라는 데이터 형식은 꾸준히 사용하고 있는데, 기본적인 문법만 익히고 사용하다 보니 한 번씩 모르던 문법이 튀어나오기 십상인 것 같다. 이번에는 YAML에 데이터 형식을 지정할 수 있다는 사실을 최근에 확인하여 내용을 정리한다.

데이터 타입

YAML의 데이터 타입은 크게 Scalar, List, Mapping이라는 3가지 종류가 있다.

Scalar

Scalar는 String, Integer, Boolean과 같이 한 가지 값으로 분류될 수 있는 데이터를 의미한다.

items: 30
price: 50
overwrite: true

List

YAML에서 리스트는 하이픈과 개행, 또는 대괄호와 쉼표를 사용하여 표현할 수 있다.

list:
 - first
 - second
 - third
 
# 또는
list: [ first, second, third ]

Mappings

정렬되지 않은 key-value 쌍의 시퀀스다. 아래의 경우 name과 code가 key이고 kim과 yaml이 value이다. Mappings에서 key는 유일해야 한다.

character:
 name: kim
 code: yaml
 
 # 또는
character: { name: kim, code: yaml }

YAML에서는 List와 Mapping이 결합된 형태도 많이 사용한다.

characters:
 - name: kim
   code: yaml
 - name: cho
   code: java
 - name: han
   code: python

# 또는
characters:
 - { name : kim, code: yaml}
 - { name : cho, code: java}
 - { name : han, code: python}

이 경우 보통 위의 형식으로 많이 기재하는 것 같다.

명시적 타입 선언

YAML에서 데이터 타입을 명시적으로 지정할 땐 태그(!!)를 사용한다.

key: !!datatype value

# 예시
str_items: !!str 30
bool : !!bool "true"

확인해 보면 30이라는 값에 데이터타입을 지정한 것과 지정하지 않은 것 간 차이가 존재하는 것을 확인할 수 있다.

참고 문서

[YAML] YAML이란? 기본 특징, 데이터 타입, 문법

[작업 기록] 서비스 이전 (Docker -> EKS)

비번변경 — Wed, 28 Jan 2026 23:02:04 +0900

배경

현재 운영 중인 서비스에는 Kafka 브로커의 메시지를 처리하는 ETL Handler(Consumer)가 존재한다. 초기에는 트래픽이 많지 않아 단일 EC2 인스턴스 위에 Docker 컨테이너를 띄워 운영하는 것만으로 충분했다.
하지만 서비스 규모가 커지며 문제가 발생했다. 패키지 저장소와 취약점 DB가 확대되면서 핸들러 수가 증가했고, 결국 단일 호스트의 물리적 리소스 한계에 부딪혔다. 빈번한 CPU 사용량 과다로 인스턴스가 죽는 현상이 잦아졌고, 이는 곧 단일 장애점(SPOF)이 되어 서비스 전체의 안정성을 위협했다.

간단한 해결 방법은 인스턴스 타입 변경이지만, 이는 근본적인 해결책이 되지 못했다. 때문에 보다 안정적인 운영 환경인 EKS로의 이전을 꾀하게 되었다.

목표

업무를 진행하기 전에 목표로 해야하는 부분을 먼저 점검했다.

안정성 확보 (Stability): 단일 EC2를 벗어나 EKS 환경으로 이전함으로써 SPOF를 제거하고, 리소스 부족 시 유연하게 확장 가능한 구조를 만든다.
IaC 기반 관리 (Terraform): 기존 EKS 인프라 관리 방식에 맞춰, 핸들러 서비스 또한 Terraform으로 관리되도록 한다.
배포 자동화 (CI/CD): Github Actions를 통해 PR 머지 시 빌드와 배포가 자동으로 이루어지는 프로세스를 유지하되, 더욱 고도화한다.
[추가] 비용 최적화 (Cost Efficiency): 외부 통신(NLB)을 K8s 내부 통신으로 전환하여 불필요한 네트워크 비용을 제거한다.

작업을 진행하면서 이러한 부분을 유념할 수 있도록 노력했다.

작업 내용

작업한 내용은 다음과 같다.

1. 기존 배포 프로세스 분석 및 벤치마킹

먼저 사내에 의도하는 배포 방식과 유사한 배포 프로세스가 있는지 먼저 확인하고 분석했다. 검증된 기존 아키텍처를 벤치마킹하여 시행착오를 줄이고 운영 일관성을 유지하기 위함이었다.
확인한 결과, Terraform으로 인프라(Deployment, Service)를 정의하고 GitHub Actions로 이를 실행하는 구조가 이미 잡혀 있는 서비스가 존재해서 이 구현을 기반으로 작업하기로 결정했다.

2. Terraform 코드 작성

Terraform 코드는 리소스 생성을 넘어, 운영의 안정성과 확장성을 고려했다. 구체적인 구현은 다음과 같다.

1) 리소스 격리 전략 (Isolation)

가장 먼저 고려한 것은 '안정성'이다. 핸들러 서비스는 대량의 데이터를 처리하며 리소스 사용량이 급증할 수 있다. 이 부하가 기존 웹 API 서버 등 타 서비스에 영향을 주지 않도록 물리적/논리적 격리를 적용했다.

Namespace: etl-handler 전용 네임스페이스를 생성하여 논리적으로 영역을 분리했다.
NodePool: 핸들러 전용 Karpenter 노드풀을 지정하여, 물리적으로 독립된 노드에서만 파드가 실행되도록 자원 경합을 원천 차단했다.

2) 설정 기반의 동적 생성 (Dynamic Resource Creation)

운영 효율을 위해 코드 중복을 제거했다. 운영할 핸들러가 여러 개였지만, 모두 'Kafka 메시지를 소비하는 데몬'이라는 동일한 배포 패턴을 가지고 있었다. 따라서 Deployment 리소스를 일일이 하드코딩하지 않고, GitHub 저장소에 있는 설정 파일(handlers-deploy.yml)을 읽어와 Terraform의 for_each 구문으로 반복 생성하도록 구조화했다.

3) 내부 통신을 위한 환경 변수 주입 (Cost Optimization)

이번 이전 작업에서 LB를 통한 통신을 'EKS 내부 통신'으로 전환하면 불필요한 네트워킹을 줄일 수 있을 거란 판단이 있었다. 따라서 Deployment 생성 시점에 브로커 주소를 환경 변수로 주입하도록 구성했다. 먼저 애플리케이션에서 KAFKA_BOOTSTRAP_SERVERS가 하드코딩되어 있어 이를 환경 변수로 주입할 수 있게 변경했고, 환경 변수에 외부 도메인이 아닌 EKS 내부 도메인(broker... svc.cluster.local)을 할당했다.

# (예시 코드) deployment 리소스 정의 중 일부
resource "kubernetes_deployment" "handler" {
  for_each = local.active_handlers # 설정 파일 기반 반복 생성
  
  spec {
    template {
      spec {
        # ... (중략) ...
        # [Isolation] 전용 노드풀 지정
        node_selector = { "karpenter.sh/provisioner-name" = "etl-handler" }
        
        container {
          env {
            # [Cost Optimization] 내부 DNS 주소 주입
            name  = "KAFKA_BOOTSTRAP_SERVERS"
            value = "broker.c-kafka.svc.cluster.local:9092"
          }
        }
      }
    }
  }
}

4) OS 제약 없는 하이브리드 인증 (Hybrid Authentication)

핸들러 배포에 필수적인 설정 파일이 GitHub Private 저장소에 위치해 있어, Terraform 실행 시 이를 읽어오기 위한 인증 토큰이 반드시 필요했다.

난관은 실행 환경과 보안 정책의 충돌이었다. 이 코드는 인프라 관리자의 로컬 환경(Windows)과 CI/CD 파이프라인인 GitHub Actions(Linux) 양쪽에서 모두 수행되어야 했다. 기존에는 tfvars 파일을 통해 토큰을 전달했으나, 최근 배포 프로세스가 고도화되면서 민감 정보를 파일(tfvars) 형태가 아닌 방식으로 처리하도록 정책이 변경되었다.

이러한 환경적 차이와 제약을 해소하기 위해, 실행 환경을 감지하고 인증 방식을 자동 전환하는 이원화된 인증 로직을 구현했다.

Linux (CI/CD): 환경 변수(TF_VAR_github_token)를 우선 사용.
Windows (Local): 환경 변수가 없으면 external 데이터 소스를 통해 PowerShell 스크립트를 호출하여 로컬 자격 증명을 획득.

# 1. 환경 변수(CI/CD) 또는 PowerShell(Windows)을 통한 토큰 획득
variable "github_token" {
  default = null # 값이 없으면 로컬 환경(Windows)으로 간주
}

data "external" "github-auth" {
  # github_token 변수가 없을 때만 PowerShell 스크립트 실행
  count   = var.github_token == null ? 1 : 0
  program = ["Powershell.exe", "-ExecutionPolicy", "Bypass", "-File", "./password.ps1"]
}

locals {
  # 최종 토큰: 환경변수 우선, 없으면 스크립트 결과 사용
  final_token = var.github_token != null ? var.github_token : data.external.github-auth[0].result.password
}

이로써 운영체제 제약 없이 어디서든 동일한 코드로 인프라를 제어할 수 있는 유연한 환경이 구축되었다.

3. GitHub Actions 작성

마지막 단계는 이 모든 준비 작업을 하나로 엮는 CI/CD 파이프라인 구축이다. 단순히 코드를 배포하는 스크립트가 아니라, 설정 파일과 현재 인프라 상태를 비교하여 최적의 행동을 결정하는 '상태 기반(State-based) 파이프라인'을 구현했다.

1) 목표 상태 vs 실제 상태 비교

파이프라인이 트리거 되면 먼저 설정 파일(handlers-deploy.yml)이 정의하는 '목표 상태'와 현재 클러스터의 '실제 상태(Active Pods)'를 대조한다. 이 결과에 따라 다음 세 가지 액션 중 하나가 자동으로 결정된다.

START (신규 생성): 설정은 켜져(enabled: true) 있는데 파드가 없다면, Terraform을 실행하여 리소스를 생성한다.
STOP (리소스 회수): 설정이 꺼져(enabled: false) 있는데 파드가 돌고 있다면, Terraform을 실행하여 리소스를 삭제(Destroy)한다.
REDEPLOY (재배포): 설정도 켜져 있고 파드도 정상 동작 중이라면, Terraform을 거치지 않고 kubectl rollout restart를 수행해 이미지를 최신화한다.

리소스의 생성과 삭제 같은 '무거운 작업'은 Terraform에 맡기되, 빈번하게 발생하는 단순 배포는 Kubectl로 처리하여 배포 속도와 효율을 모두 챙겼다.

2) 정교한 스케일링(Scaling)

시퀀스 특히 재배포(Redeploy) 과정에서 파드의 개수(Replicas) 변경이 동반될 경우, 가용성 확보를 위해 실행 순서를 동적으로 조정하는 로직을 심었다.

Scale Down (현재 > 목표): Scale Down → Restart
- 이유: 불필요한 파드를 먼저 정리하여 유휴 리소스를 확보한 뒤 재시작한다.
Scale Up (현재 < 목표): Restart → Scale Up
- 이유: 최신 이미지를 먼저 적용한 후 인스턴스를 늘려야 한다. 순서가 바뀌면 구버전(Buggy) 코드가 확장되는 문제가 발생할 수 있기 때문이다.

이러한 로직을 GitHub Actions 워크플로우(github-action.yml)에 녹여냄으로써, 개발자는 복잡한 쿠버네티스 명령어를 몰라도 설정 파일만 관리하면 안전하게 서비스를 배포할 수 있게 되었다.

[Airflow] Connections에 옵션 추가

비번변경 — Tue, 27 Jan 2026 10:32:22 +0900

개요

2025.08.25-[Airflow] Connections이란에서 Airflow와 외부 시스템 간의 연동을 위한 연결정보를 저장하는 Connection에 대해서 알아보았다. 평소에는 연결에 필요한 필수 정보 정도만 지정하고 사용하지만, 필요시에는 기타 추가적인 옵션도 지정할 필요가 있을 수 있다. 이번 글에서는 그런 부분에 대해 추가로 작성한다.

extra

이전 글에서 extra가 하는 역할이 무엇인가 싶었는데, 이 extra가 바로 추가적인 구성 정보를 지정하는 속성이었다. extra는 json 형식으로 지정하려는 속성의 키와 값을 넣어주면 된다.

이 연결 정보는 URI 형식으로 확인할 수도 있는데 아래와 같은 형식이다.

[
  {
    "id": "5",
    "conn_id": "test",
    "conn_type": "postgres",
    "description": "",
    "host": "127.0.0.1",
    "schema": "test",
    "login": "postgres",
    "password": "postgres",
    "port": "5432",
    "is_encrypted": "False",
    "is_extra_encrypted": "False",
    "extra_dejson": {
      "param1": "val1",
      "param2": "val2"
    },
    "get_uri": "postgres://postgres:postgres@127.0.0.1:5432/test?param1=val1&param2=val2"
  }
]

이런 점을 활용해 PostgreSQL과 같은 데이터베이스에 연결하는 경우, extra를 사용해 연결 타임아웃 등을 설정할 수 있다.

{
  "options": "-c statement_timeout=2400000 -c lock_timeout=300000 -c idle_in_transaction_session_timeout=12h"
}

CLI 등으로 지정하기

Airflow는 웹 UI가 생각보다 잘 되어 있어서 CLI를 사용할 일이 그렇게 잦지는 않은 것 같다. 하지만 Connections도 Connections.extra도 CLI나 환경 변로 관리할 수 있다는 점도 일단 기재해 둔다.

환경 변수

export AIRFLOW_CONN_MY_PROD_DATABASE='{
    "conn_type": "my-conn-type",
    "login": "my-login",
    "password": "my-password",
    "host": "my-host",
    "port": 1234,
    "schema": "my-schema",
    "extra": {
        "param1": "val1",
        "param2": "val2"
    }
}'

# 또는
export AIRFLOW_CONN_MY_PROD_DATABASE='my-conn-type://login:password@host:port/schema?param1=val1&param2=val2'

CLI

airflow connections add 'my_prod_db' \
    --conn-json '{
        "conn_type": "my-conn-type",
        "login": "my-login",
        "password": "my-password",
        "host": "my-host",
        "port": 1234,
        "schema": "my-schema",
        "extra": {
            "param1": "val1",
            "param2": "val2"
        }
    }'
    
# 또는
airflow connections add 'my_prod_db' \
    --conn-uri '<conn-type>://<login>:<password>@<host>:<port>/<schema>?param1=val1&param2=val2&...'
    
# 또는
airflow connections add 'my_prod_db' \
    --conn-type 'my-conn-type' \
    --conn-login 'login' \
    --conn-password 'password' \
    --conn-host 'host' \
    --conn-port 'port' \
    --conn-schema 'schema' \
    ...

참고 문서

https://airflow.apache.org/docs/apache-airflow/2.8.4/howto/connection.html

[Kafka] API로 커넥터 관리하기

비번변경 — Mon, 26 Jan 2026 11:05:13 +0900

개요

2025.12.29-[Kafka] debezium 이란 에서 Kafka 클러스터에 Debezium을 얹어보았는데, 실제로 커넥터를 생성하고 관리하는 방법에 대해서 정리가 좀 필요한 것 같아서 기록해 둔다.

Connectors 조회

커넥터 목록은 Kafka Connect API 엔드포인트에 GET 요청을 보내면 된다.

http://localhost:8083/connectors

아직 아무 커넥터를 만들지 않아 응답이 비어있다.

Conenctors 생성

Kafka Connect API 엔드포인트에 POST 요청을 보낸다. request body에 생성할 커넥터의 정보를 전달해야 한다.

curl -i -X POST -H "Accept:application/json" -H  "Content-Type:application/json" http://localhost:8083/connectors/ -d @register-postgres.json

Conenctors 상세 조회

특정 커넥터의 정보를 조회하고 싶을 때는 Kafka Connect API 엔드포인트에 조회할 커넥터의 이름을 붙이면 된다.

curl http://localhost:8083/connectors/CONNECTOR_NAME

커넥터를 구성하고 있는 설정 정보를 확인할 수 있다.

Conenctors 상태

특정 커넥터의 정보를 조회하고 싶을 때는 Kafka Connect API 엔드포인트에 조회할 커넥터의 이름에 status로 접근한다.

curl http://localhost:8083/connectors/CONNECTOR_NAME/status

Conenctors 중지

특정 커넥터의 동작을 중지하고 싶을 때는 pause 경로로 PUT 요청을 보낸다.

curl -X PUT http://localhost:8083/connectors/CONNECTOR_NAME/pause

요청 후 다시 상태를 확인하면 정상적으로 중지된 것을 확인할 수 있다.

Conenctors 재시작

중지한 커넥터를 재시작할 때는 resume로 PUT 요청을 보낸다.

curl -X PUT http://localhost:8083/connectors/CONNECTOR_NAME/resume

다시 RUNNING 상태로 돌아왔다.

Conenctors 삭제

커넥터를 삭제할 때는 커넥터 URL에 DELETE 요청을 보낸다.

curl -X DELETE http://localhost:8083/connectors/CONNECTOR_NAME

참고 문서

https://docs.confluent.io/kafka-connectors/debezium-postgres-source/current/overview.html