작은일기장

[Spring-boot] i18n적용 및 동적 데이터 변경

조용한외침 — Wed, 15 Apr 2026 00:46:04 +0900

회사에서 외국 컨퍼런스에 참여를 해야 하는 상황이 생겼습니다. 미리 준비해야 하는 상황이 생겼고, 어떤 식으로 구성해야 할지 고민을 많이 했습니다.

정적인 데이터는 i18n을 활용하면 된다고 하지만 API요청에 따라 변하는 데이터(동적 데이터)는 어떤식으로 처리하면 좋을지 고민을 하게 됐습니다.

이번 글에서는 어떤 식으로 정적, 동적 데이터를 처리했는지 글을 작성하려고 합니다.

혹시라도 부정확한 정보를 전달드릴 수 있습니다. 다만 틀린 거나 부정확한 정보가 있다면 댓글을 남겨주세요.

한국어 / 영어 2개 언어를 지원하는 i18n 구현 과정을 단계별로 정리하였습니다.

1. src/main/resources 에 properties 파일을 생성합니다.

- properties 파일은 한국어와 영어를 accept-language를 기반으로 전달합니다.

- properties 파일은 response message를 변환하기 위한 파일입니다.

- properties의 예시입니다.

# messages.properties (한국어 - 기본)
# x로 표시된 것들은 직접 오류, response 등 관련 내용들을 작성하시면됩니다.
# Error Code
internal.x=서버 내부 오류가 발생했습니다.
invalid.x=잘못된 입력값입니다.
unauthorized=인증이 필요합니다.
member.x=멤버를 찾을 수 없습니다.

# Auth - Success
auth.x=회원가입이 완료되었습니다.
auth.x=로그인이 완료되었습니다.
auth.x=토큰이 재발급되었습니다.

# Auth - Validation
auth.x=사번은 필수입니다.
auth.x=사번은 100자를 초과할 수 없습니다.
auth.x=비밀번호는 필수입니다.

# messages_en.properties (영어)
# Error Code
internal.x=Internal server error occurred.
invalid.x=Invalid input value.
unauthorized=Unauthorized.
member.x=Member not found.

# Auth - Success
auth.x=Sign up has been completed.
auth.x=Login has been completed.
auth.x=Token has been reissued.

# Auth - Validation
auth.x=Employee number is required.
auth.x=Employee number cannot exceed 100 characters.
auth.x=Password is required.

- 저의 경우 파일 네이밍 규칙을 message_언어코드. properties로 설정하였습니다.

ex. messages_ja.properties (일본어)

2. Application main에 'Accept-Language' 헤더 기반 Locale 코드 추가

# Bean으로 설정한 이유는 싱글톤으로 관리하고, 어플리케이션에서 하나의 인스턴스로 필요해서 입니다.

....
@Bean
public LocaleResolver localeResolver() {
	AcceptHeaderLocaleResolver localeResolver = new AcceptHeaderLocaleResolver();
	localeResolver.setDefaultLocale(Locale.KOREAN);
	return localeResolver;
}

@Bean
public ResourceBundleMessageSource messageSource() {
	ResourceBundleMessageSource messageSource = new ResourceBundleMessageSource();
    messageSource.setUseCodeAsDefaultMessage(true);
    messageSource.setDefaultEncoding("UTF-8");
    messageSource.setBasename("messages");
    return messageSource;
}
...

- AcceptHeaderLocaleResolver는 Accept-Language 헤더에서 전달받은 'ko', 'en'을 Locale 기반으로 변경하도록 구성하였습니다.

- 이후 Locale 기반으로 response, error code 등이 전달됩니다.

3. Error Code Enum 변환

- 저의 경우 Error Code를 Enum으로 관리하고 있는 상황에서 propeties에서 공통으로 전달하도록 수정했어야 했습니다.

- HttpStatus, Error Code, Message Key(properties 파일의 키)

@Getter
@RequiredArgsConstructor
public enum ErrorCode {

    // Common
    INTERNAL_SERVER_ERROR(HttpStatus.INTERNAL_SERVER_ERROR, "C001", "internal.x"),
    INVALID_INPUT_VALUE(HttpStatus.BAD_REQUEST, "C002", "invalid.x"),
    METHOD_NOT_ALLOWED(HttpStatus.METHOD_NOT_ALLOWED, "C003", "method.x"),
    ACCESS_DENIED(HttpStatus.FORBIDDEN, "C004", "access.x"),

    // Auth
    UNAUTHORIZED(HttpStatus.UNAUTHORIZED, "A001", "unauthorized"),
    INVALID_CREDENTIALS(HttpStatus.UNAUTHORIZED, "A002", "invalid.x"),
    TOKEN_EXPIRED(HttpStatus.UNAUTHORIZED, "A003", "token.x"),
    .....

	private final HttpStatus httpStatus;
	private final String code;
	private final String message; // properties 파일의 키
}

- message가 properties 파일에 있는 키로 사용하기 때문에 각 파일마다 동일한 키를 사용해야 합니다.

4. ApiResponse에 i18n 관련 코드 추가

@Getter
@NoArgsConstructor
@AllArgsConstructor
@Builder
public class ApiResponse<T> {

    private boolean success;
    private String message;
    private T result;
    private LocalDateTime timestamp;

    /**
     * i18n 지원 성공 응답
     * - messageKey를 MessageSource에서 Locale에 맞는 메시지로 변환
     */
    public static <T> ApiResponse<T> success(String messageKey, T data,
                                              MessageSource messageSource, Locale locale) {
        String message = messageSource.getMessage(messageKey, null, messageKey, locale);
        return ApiResponse.<T>builder()
                .success(true)
                .message(message)
                .result(data)
                .timestamp(LocalDateTime.now())
                .build();
    }

    /** i18n 미사용 */
    public static <T> ApiResponse<T> success(T data) {
        return ApiResponse.<T>builder()
                .success(true)
                .message("Success")
                .result(data)
                .timestamp(LocalDateTime.now())
                .build();
    }
}

- 저의 경우 messageSource.getMessage에서 properties파일로 전달하여 response를 전달합니다.

1. 첫 번째 인자(messageKey) - 메시지 키

2. 두 번째 인자(null) - 메시지 파라미터

3. 세 번째 인자(messageKey) - 키를 못 찾았을 때 반환할 기본값

4. 네 번째 인자(locale) - 적용한 Locale

5. ErrorResponse에도 코드 추가

@Getter
@NoArgsConstructor
@AllArgsConstructor
@Builder
public class ErrorResponse {

    private String code;
    private String message;
    private int status;
    private LocalDateTime timestamp;
    private List<FieldError> errors;

    /** i18n 지원 에러 응답 (비즈니스 예외) */
    public static ErrorResponse of(ErrorCode errorCode, MessageSource messageSource, Locale locale) {
        String message = messageSource.getMessage(
                errorCode.getMessage(),  // 메시지 키
                null,
                errorCode.getMessage(),  // 키 자체를 메시지로 사용
                locale
        );
        return ErrorResponse.builder()
                .code(errorCode.getCode())
                .message(message)
                .status(errorCode.getHttpStatus().value())
                .timestamp(LocalDateTime.now())
                .errors(new ArrayList<>())
                .build();
    }

    /** i18n 지원 에러 응답 (유효성 검증 에러) */
    public static ErrorResponse of(ErrorCode errorCode, BindingResult bindingResult,
                                    MessageSource messageSource, Locale locale) {
        String message = messageSource.getMessage(
                errorCode.getMessage(), null, errorCode.getMessage(), locale
        );
        return ErrorResponse.builder()
                .code(errorCode.getCode())
                .message(message)
                .status(errorCode.getHttpStatus().value())
                .timestamp(LocalDateTime.now())
                .errors(FieldError.of(bindingResult, messageSource, locale))
                .build();
    }

    @Getter
    @NoArgsConstructor
    @AllArgsConstructor
    public static class FieldError {
        private String field;
        private String value;
        private String reason;

        /**
         * 유효성 검증 필드 에러 i18n 처리
         * - DTO의 @NotBlank(message = "{key}") 형태의 메시지를 해석
         * - {key} 패턴이면 MessageSource에서 번역, 아니면 원본 사용
         */
        public static List<FieldError> of(BindingResult bindingResult,
                                           MessageSource messageSource, Locale locale) {
            List<FieldError> errors = new ArrayList<>();

            for (org.springframework.validation.FieldError error : bindingResult.getFieldErrors()) {
                String message = error.getDefaultMessage();

                // {key} 형태인 경우 MessageSource에서 번역된 메시지 조회
                if (message != null && message.startsWith("{") && message.endsWith("}")) {
                    String key = message.substring(1, message.length() - 1);
                    message = messageSource.getMessage(
                            key, error.getArguments(), error.getDefaultMessage(), locale
                    );
                }

                errors.add(new FieldError(
                        error.getField(),
                        error.getRejectedValue() == null ? "" : error.getRejectedValue().toString(),
                        message
                ));
            }
            return errors;
        }
    }
}

- DTO에서 Error를 전달할 때도 i18n의 키를 이용할 수 있도록 구성하였습니다.

6. GlobalExceptionHandler에 Locale 주입

@Slf4j
@RestControllerAdvice
public class GlobalExceptionHandler {

    private final MessageSource messageSource;

    public GlobalExceptionHandler(MessageSource messageSource) {
        this.messageSource = messageSource;
    }

    /** 비즈니스 예외 처리 - i18n 메시지 사용 */
    @ExceptionHandler(BusinessException.class)
    protected ResponseEntity<ErrorResponse> handleBusinessException(
            BusinessException e,
            Locale locale  // Accept-Language 헤더에서 자동 해석된 Locale
    ) {
        log.warn("BusinessException: {}", e.getMessage(), e);
        ErrorCode errorCode = e.getErrorCode();
        ErrorResponse response = ErrorResponse.of(errorCode, messageSource, locale);
        return ResponseEntity.status(errorCode.getHttpStatus()).body(response);
    }

    /** @Valid 검증 실패 - 필드별 i18n 에러 메시지 */
    @ExceptionHandler(MethodArgumentNotValidException.class)
    protected ResponseEntity<ErrorResponse> handleMethodArgumentNotValidException(
            MethodArgumentNotValidException e,
            Locale locale
    ) {
        log.warn("Validation failed: {}", e.getMessage());
        ErrorResponse response = ErrorResponse.of(
                ErrorCode.INVALID_INPUT_VALUE, e.getBindingResult(), messageSource, locale
        );
        return ResponseEntity.status(ErrorCode.INVALID_INPUT_VALUE.getHttpStatus()).body(response);
    }
}

- 'Locale locale' 파라미터를 선언하기만 해도 Spring에서 자동으로 Locale을 주입해 줍니다.(main에 AcceptHeaderLocaleResolver에서 진행)

7. 각 Controller에 Locale 파리미터 추가

@Slf4j
@RestController
@RequestMapping("/api/test")
public class TestController {

    private final TestService testService;
    private final MessageSource messageSource;

    @PostMapping()
    public ResponseEntity<ApiResponse<TestResponseDto>> test(
            @Valid @RequestBody TestRequestDto request,
            Locale locale  // Accept-Language 헤더에서 자동 주입
    ) {
        TestResponseDto response = testService.test(request);

        return ResponseEntity.ok(
                ApiResponse.success("test.response.success", response, messageSource, locale)
        );
    }
...
}

8. DTO message를 key로 변경

@Getter
@NoArgsConstructor
@AllArgsConstructor
@Builder
public class TestRequestDto {

    @NotBlank(message = "{test.request.dto.invalid.number}")
    @Size(max = 100, message = "{test.request.dto.invalid.number.max}")
    private String number;

    @NotBlank(message = "{test.request.dto.invalid.name}")
    private String name;
}

- {}를 해주는 이유는 ErrorResponse에서 패턴으로 구분하기 위함입니다.

9. Locale 유틸리티 클래스 생성

public final class LocaleUtils {

    private LocaleUtils() {
        throw new UnsupportedOperationException("Utility class");
    }

    /** Locale -> 언어 코드 변환 (ko, en, jp) */
    public static String getLanguageCode(Locale locale) {
        if (locale == null) return "ko";
        String language = locale.getLanguage().toLowerCase();
        if (language.equals("ja")) return "jp"; // 일본어 코드 통일
        return language;
    }

    /** 한국어 Locale인지 확인 */
    public static boolean isKorean(Locale locale) {
        if (locale == null) return true;
        return locale.getLanguage().toLowerCase().equals("ko");
    }

    /** 지원 언어 확인 */
    public static boolean isSupportedLanguage(String languageCode) {
        if (languageCode == null) return false;
        return languageCode.equals("ko") || languageCode.equals("en") || languageCode.equals("jp");
    }
}

- 서비스 레이어에서 Locale 기반으로 분기 처리가 필요한 경우를 위한 유틸리티입니다.

10. DB 칼럼 생성

이 부분이 제일 고민이었습니다. 칼럼을 생성할지 테이블을 분리해서 추가, 수정 등을 진행할지 하지만 현재 서비스에서 테이블을 증가 시켜서 관리포인트를 늘리는것보다 필요한 데이터를 jsonb 타입으로 컬럼을 만들어서 관리하는 것이 맞다고 생각하였습니다.

어떤 방식이 꼭 정답이다고 말하기는 어렵지만 결국에는 고민하고 실행을 한 결과물이 최고의 선택이라고 믿어야 하며, 혹시라도 이후에 수정을 하거나 문제가 발생한다면, 후회보다는 한번 더 배움이 있었다고 생각하면 좋을 거 같습니다. 물론 저도 항상 후회하지만 계속 배우고 성장하려고 노력하고 있기 때문에 모두 같이 힘냈으면 합니다.

Ref.

https://sundaland.tistory.com/693

Adding internationalization into the licensing service

Spring Boot 마이크로서비스 국제화(i18n) 적용하기 1. 국제화의 필요성국제화(i18n, internationalization)는 다양한 언어와 지역 환경을 지원하는 애플리케이션을 개발하는 과정입니다. 사용자가

sundaland.tistory.com

https://velog.io/@minseojo/%EC%8A%A4%ED%94%84%EB%A7%81%EB%B6%80%ED%8A%B8-%EA%B5%AD%EC%A0%9C%ED%99%94

Spring Boot로 글로벌 서비스를 위한 다국어(국제화) 설정 1 - LocaleResolver

LocaleResovler 인터페이스, AcceptHeaderLocaleResolver 클래스, SessionLocaleResolver 클래스, CookieLocaleResolver 클래스, FixedLocaleResolver 클래스

velog.io

2~3주 스프린트로 개발 프로세스를 운영해 본 후기

조용한외침 — Sat, 7 Mar 2026 15:58:36 +0900

스프린트 기반으로 업무를 운영하면서 가장 크게 느낀 점은 팀의 업무 흐름이 훨씬 명확해졌다는 것이었습니다.

Agile 방식을 적용하기 전에는 기능 단위 혹은 요구사항이 생겼을 때 그때 그때 처리하는 방식이였습니다. 기획이 나오면 개발을 시작하고, 개발을 진행하다 보면 요구사항이 조금씩 바뀌거나 추가되는 일이 반복되습니다. 이 과정에서 작업의 우선순위가 애매해지거나 이미 진행하던 개발 방향을 수정해야 하는 상황도 종종 발생했습니다.

그래서 팀에서는 2~3주 단위 스프린트 방식으로 업무를 진행하기 시작했습니다. 처음에는 단순히 업무를 기간 단위로 나누는 것 정도로 생각했지만, 실제로 운영해보니 협업 방식 자체가 조금씩 달라지기 시작했습니다.

1. 요구사항이 훨씬 명확해졌다

스프린트를 시작하기 전에 진행하는 스프린트 플래닝 과정에서 이번 스프린트에서 진행할 작업들을 함께 정리했습니다.

이 과정에서 기획자와 개발자가 요구사항을 다시 확인하고 구현 범위를 구체적으로 정의하게 되는데, 이 단계가 생각보다 큰 효과를 만들었습니다.

이전에는 개발을 진행하다가
“이 기능이 정확히 어떤 동작을 해야 하지?”
라는 질문이 중간에 발생하는 경우가 있었습니다.

하지만 스프린트 단위로 작업을 정의하면서 개발 전에 요구사항을 충분히 정리하는 과정이 자연스럽게 만들어졌고, 그 결과 개발 도중에 발생하는 커뮤니케이션 비용이 크게 줄어들었습니다.

2. 우선순위 기반으로 일이 진행되기 시작했다

스프린트를 운영하면서 흥미로웠던 점은 기획자의 업무 방식도 함께 변화했다는 점이었습니다.

스프린트라는 기준이 생기면서 기획자는 자연스럽게 다음과 같은 판단을 하게 되었습니다.

이 기능이 이번 스프린트에 꼭 필요한가
다음 스프린트로 넘겨도 되는가
우선순위가 더 높은 기능은 무엇인가

이전에는 새로운 요구사항이 생기면 바로 개발 논의가 시작되는 경우도 있었지만, 이제는 스프린트 단위 안에서 기능의 중요도를 기준으로 판단하게 되었습니다.

덕분에 개발팀도 갑작스러운 작업 변경 없이 예측 가능한 일정 안에서 개발을 진행할 수 있게 되었습니다.

3. 2~3주 스프린트는 생각보다 적절한 사이클이었다

스프린트 기간을 정할 때도 고민이 있었습니다.

너무 짧으면 개발 흐름이 끊기고
너무 길면 피드백이 늦어질 수 있기 때문입니다.

결과적으로 2~3주 스프린트는 다음과 같은 장점이 있었습니다.

기능 단위 결과물을 비교적 빠르게 확인할 수 있다
스프린트 회고를 통해 프로세스를 계속 개선할 수 있다
팀이 일정한 개발 리듬을 유지할 수 있다

특히 스프린트가 반복되면서 팀 전체의 업무 리듬이 맞춰지는 느낌이 생겼습니다.

4. 결국 Agile의 핵심은 “같은 리듬으로 일하는 것”

이번 경험을 통해 느낀 점은 Agile이 단순히 프로세스를 도입하는 것이 아니라는 것이었습니다.

스프린트를 기준으로 업무를 운영하다 보니 팀원들이 자연스럽게

같은 목표를 바라보고
같은 일정 안에서 일하고
같은 시점에 결과물을 확인하는

구조가 만들어졌습니다.

그 결과 업무 속도도 빨라졌고, 무엇보다 서로의 요구사항과 작업 범위를 더 명확하게 이해하게 되었습니다.

완벽한 방식이라고 말할 수는 없지만, 스프린트를 통해 팀이 같은 리듬으로 협업할 수 있는 환경이 만들어졌다는 점만으로도 충분히 의미 있는 변화였습니다.

[Grafana] Slack Alert

조용한외침 — Thu, 1 Jan 2026 17:25:31 +0900

Grafana는 메트릭, 로그 등 다양한 데이터를 시각화할 수 있는 도구입니다. 시각화뿐만 아니라 알림을 통해서 현재 서버의 상황을 파악할 수 있습니다. 저는 이번에 알림 기능을 활용하여 에러 발생을 슬랙으로 확인할 수 있도록 설정하였습니다. 물론 시장에서는 DataDog, Sentry 같은 좋은 서비스들이 있지만, 스타트업이나 비용을 고려해야 한다면 Grafana로도 충분히 가능하다고 볼 수 있을 거 같습니다.

혹시라도 부정확한 정보를 전달드릴 수 있습니다. 다만 틀린 거나 부정확한 정보가 있다면 댓글을 남겨주세요.

1. Slack 채널 생성 및 웹훅 연결

- 슬랙 API(링크)에서 앱이 있으시면 생성하시고 없으시다면 만드시면 됩니다.(저는 있는 앱을 사용했습니다.)

- 앱을 선택하면 앱관련 설정들이 나옵니다.

- Incoming Webhooks를 선택합니다.

- 초록색 버튼인 reinstall to app을 선택하고 전달받을 채널을 선택합니다.

- 채널은 슬랙에서 직접 생성하시면 웹후크를 위한 채널에서 확인할 수 있습니다.

- 웹훅 설정을 하면 해당 채널에서 메시지가 나타납니다.

- 웹훅 URL을 복사합니다.(이후에 grafana에 등록이 필요합니다.)

2. Grafana 설정

- Alerting 선택 후 Add contact point를 선택하여 integration을 Slack으로 지정합니다.

- Webhook URL에 Slack에서 생성한 웹훅 URL을 입력합니다.(입력 후 우측 상단에 테스트 버튼으로 메시지가 전달이 되는지 확인해 보세요.)

- 테스트를 확인하셨다면, 알림 준비가 어느 정도 됐다고 생각하시면 됩니다.

3. Grafana 알림 정책 수정

- slack 설정으로 default policy를 변경합니다.

4. Grafana Alert rules 설정

- 왼쪽 이미지는 Loki에서 수집된 데이터를 기반으로 쿼리를 설정합니다.

- 오른쪽 이미지는 쿼리를 기반으로 설정해 주는 부분들입니다.

- B는 마지막 값을 선택하며, 여러 데이터 포인트 중 가장 최근 값을 가져옵니다.

- C는 B의 결괏값이 0보다 크면 알림을 발생시킵니다.

- 해당 설정은 에러가 1건이라도 발생하면 slack 알림으로 보낸다고 생각해 주시면 될 거 같습니다.

- Folder와 Groupt은 Alert rule을 관리하기 위한 설정입니다.

- Group은 현재 5분마다 쿼리를 실행해서 조건을 체크합니다.

- Pending period는 조건 위반하면 즉시 알림을 발송할지 지속된 상태를 보고 발송할지 설정하는 것입니다.

- Configure no data and error handling은 데이터가 없으면 No Data 상태로 되는데 이때 Error와 OK로 지정할 수 있습니다.(저의 경우 데이터가 없다면 OK로 지정해서 No data일 때 오류 알림이 오지 않도록 설정했습니다.)

- 일부러 오류를 발생하여 테스트를 해본 결과입니다.

추가)

- Summary와 Description을 수정하면 전달하는 텍스트도 변경할 수 있습니다.

- Summary와 Description으로 슬랙에 알림을 전달하려면 Contact Points에 Title과 Body에 값을 넣어주면 직접 작성한 텍스트로 전달할 수 있습니다.

쿼리를 추가해서 알림을 더 세분화할 수 있다고 생각합니다. 초기 설정과 테스트까지의 기록입니다. 각자의 서비스에 맞는 알림을 구현하는 것이 좋을 것이라고 생각합니다.

Ref.

https://pixx.tistory.com/339

[Grafana] Grafana와 Slack 연동하여 Alert 설정하기

현대 IT 환경에서 시스템의 성능과 상태를 실시간으로 모니터링하는 것은 매우 중요합니다. 그러나 문제 발생 시, 그 상황을 빠르게 파악하고 대응하는 것이 더욱 중요합니다. Grafana는 이러한

pixx.tistory.com

[EC2] Github-Action으로 EC2에 Spring-Boot 배포(Blue-Green) - 2

조용한외침 — Sun, 28 Dec 2025 22:46:30 +0900

지난번에는 AWS 설정하는 부분을 작성하였습니다.(링크)
이번에는 Github-Action과 CodeDeploy Script 관련해서 작성하려고 합니다.

혹시라도 부정확한 정보를 전달드릴 수 있습니다. 다만 틀린 거나 부정확한 정보가 있다면 댓글을 남겨주세요

1. Github-Action Work-flow 작성

- .github 폴더에 workflows 폴더 생성 및 deploy.yml 파일 생성

# 원한시는 Deploy 이름을 작성하시면 됩니다.
name: Blue-Green Deployment with CodeDeploy

on:
  push:
  # 어떤 브랜치에서 진행이 될지 입력합니다.
  # push만 있는게 아닌 PR도 있습니다.
    branches:
      - main
      - develop

env:
  AWS_REGION: ap-northeast-2
  # secrets 설정된 부분은 Github Repo 설정에서 Secrets and variables에 Repository secrets에 작성하시면 됩니다.
  S3_BUCKET: ${{ secrets.S3_DEPLOYMENT_BUCKET }}
  CODEDEPLOY_APP_NAME: ${{secrets.CODEDEPLOY_APP_NAME}}

jobs:
  build-and-deploy:
 	# Github actions의 실행 환경을 지정합니다.
    name: Build and Deploy
    runs-on: ubuntu-latest
    environment:
    # 브랜치에 따라 배포 환경을 설정합니다.
      name: ${{ github.ref == 'refs/heads/main' && 'production' || 'development' }}
    # 저장소의 코드를 확인합니다.
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

	# Spring-Boot 서버의 java version과 일치하게 설정합니다.
      - name: Set up JDK 17
        uses: actions/setup-java@v4
        with:
          java-version: '17'
          distribution: 'temurin'
          cache: 'gradle'
	# gradlew에 실행권한을 부여합니다.
      - name: Grant execute permission for gradlew
        run: chmod +x gradlew
	# 테스트 코드가 있다면 진행하는 부분입니다.
      - name: Build with Gradle
        run: ./gradlew clean build -x test
      
      # 브랜치에 따라 CodeDeploy 배포 그룹 설정합니다.
      - name: Set deployment group
        id: set-deployment-group
        run: |
          if [ "${{ github.ref }}" == "refs/heads/main" ]; then
            echo "CODEDEPLOY_DEPLOYMENT_GROUP=${{ secrets.DEPLOYMENT_GROUP_PROD }}" >> $GITHUB_ENV
          else
            echo "CODEDEPLOY_DEPLOYMENT_GROUP=${{ secrets.DEPLOYMENT_GROUP_DEV }}" >> $GITHUB_ENV
          fi

      # - name: Run tests
      #   run: ./gradlew test

	# AWS 발급받은 키로 로그인 인증하는 부분입니다.(키 발급은 보안 자격 증명에서 발급받아서 사용할 수 있습니다.)
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ${{ env.AWS_REGION }}

      - name: Login to Amazon ECR (Optional)
        if: false  # ECR 사용시 true로 변경
        id: login-ecr
        uses: aws-actions/amazon-ecr-login@v2

	# 배포 버전 태그와 환경 변수를 생성합니다.
      - name: Generate deployment tag
        run: |
          IMAGE_TAG=$(date +%Y%m%d-%H%M%S)-${GITHUB_SHA::7}
          echo "IMAGE_TAG=$IMAGE_TAG" >> $GITHUB_ENV
          echo "DEPLOYMENT_ID=$(date +%Y%m%d-%H%M%S)" >> $GITHUB_ENV

          # 환경 변수 결정 (GitHub Actions environment에 맞춤)
          if [ "${{ github.ref }}" == "refs/heads/main" ]; then
            DEPLOY_ENV="prod"
          elif [ "${{ github.ref }}" == "refs/heads/develop" ]; then
            DEPLOY_ENV="dev"
          else
            DEPLOY_ENV="dev"
          fi
          echo "DEPLOY_ENV=$DEPLOY_ENV" >> $GITHUB_ENV

	# 배포 패키지를 생성하고 압축합니다.
      - name: Create deployment package
        run: |
          # 배포에 필요한 파일들 복사
          mkdir -p deployment
          # build/libs 디렉토리 구조를 유지하여 복사
          mkdir -p deployment/build/libs
          cp build/libs/*.jar deployment/build/libs/
          cp Dockerfile.deploy deployment/Dockerfile.deploy
          cp docker-compose.blue-green.${{ env.DEPLOY_ENV }}.yml deployment/
          cp appspec.yml deployment/
          cp -r scripts deployment/
          cp -r conf deployment/

          # 스크립트 파일에 실행 권한 부여
          find deployment/scripts -name "*.sh" -type f -exec chmod +x {} \;

          # 환경변수를 .env 파일로 저장
          echo "IMAGE_TAG=${{ env.IMAGE_TAG }}" > deployment/.env.deploy
          echo "DEPLOY_ENV=${{ env.DEPLOY_ENV }}" >> deployment/.env.deploy

          # zip으로 압축
          cd deployment
          zip -r ../deployment-${{ env.DEPLOYMENT_ID }}.zip .
          cd ..

	# 배포 패키지를 S3에 업로드 합니다.
      - name: Upload to S3
        run: |
          aws s3 cp deployment-${{ env.DEPLOYMENT_ID }}.zip \
            s3://${{ env.S3_BUCKET }}/deployment-${{ env.DEPLOYMENT_ID }}.zip

	# CodeDeploy 배포를 생성하고 실행합니다.
      - name: Create CodeDeploy deployment
        id: deploy
        run: |
          DEPLOYMENT_ID=$(aws deploy create-deployment \
            --application-name ${{ env.CODEDEPLOY_APP_NAME }} \
            --deployment-group-name ${{ env.CODEDEPLOY_DEPLOYMENT_GROUP }} \
            --s3-location bucket=${{ env.S3_BUCKET }},key=deployment-${{ env.DEPLOYMENT_ID }}.zip,bundleType=zip \
            --description "Deployment from GitHub Actions - ${{ github.sha }}" \
            --query 'deploymentId' \
            --output text)

          echo "DEPLOYMENT_ID=$DEPLOYMENT_ID" >> $GITHUB_ENV
          echo "deployment_id=$DEPLOYMENT_ID" >> $GITHUB_OUTPUT

	# 배포가 완료될 때까지 대기합니다.
      - name: Wait for deployment to complete
        run: |
          echo "Waiting for deployment ${{ env.DEPLOYMENT_ID }} to complete..."
          aws deploy wait deployment-successful --deployment-id ${{ env.DEPLOYMENT_ID }}

	# 배포 상태를 조회하여 출력합니다.
      - name: Get deployment status
        if: always()
        run: |
          aws deploy get-deployment --deployment-id ${{ env.DEPLOYMENT_ID }}

Repository secrets

- Repository secrets입니다.

- secrets으로 가져오는 값은 Repository secrets에 등록이 필요합니다.

2. CodeDeploy Script 작성

폴더구조

- 저는 이미지와 같은 폴더 구조로 구성하였습니다.

- script의 진행 순서는 AWS 공식문서에 잘 작성 돼 있습니다.(링크)

2-1. before_install.sh 생성 및 코드 입력

#!/bin/bash

# ============================================
# CodeDeploy BeforeInstall Hook
# 배포 전 준비 작업
# ============================================

set -e

echo "========================================="
echo "BeforeInstall: 배포 전 준비 작업 시작"
echo "========================================="

# 배포 디렉토리 백업 및 정리
if [ -d /home/ubuntu/test ]; then
    echo "기존 배포 디렉토리 백업 중..."
    BACKUP_DIR="/home/ubuntu/backup/test-backup-$(date +%Y%m%d-%H%M%S)"
    sudo cp -r /home/ubuntu/test "$BACKUP_DIR"
    echo "백업 완료: $BACKUP_DIR"

    # 백업 개수 제한 (최대 5개 유지)
    echo "백업 개수 확인 및 정리 중..."
    BACKUP_COUNT=$(find /home/ubuntu/backup -maxdepth 1 -type d -name "test-backup-*" | wc -l)
    echo "현재 백업 개수: $BACKUP_COUNT"
    
    # 제거하지 않으면 SSD 용량 문제가 발생할 수 있습니다.
    if [ "$BACKUP_COUNT" -gt 5 ]; then
        echo "백업 개수가 5개를 초과합니다. 오래된 백업 삭제 중..."
        # 가장 오래된 백업부터 삭제 (이름의 날짜/시간 순서로 정렬)
        find /home/ubuntu/backup -maxdepth 1 -type d -name "test-backup-*" | sort | head -n -5 | while read -r old_backup; do
            echo "오래된 백업 삭제: $old_backup"
            sudo rm -rf "$old_backup"
        done
        echo "백업 정리 완료"
    fi
    
    # 기존 디렉토리 삭제 (CodeDeploy가 새 파일을 배포할 수 있도록 정리)
    echo "기존 배포 디렉토리 삭제 중..."
    sudo rm -rf /home/ubuntu/test
    echo "기존 디렉토리 삭제 완료"
fi

# 배포 디렉토리 생성
sudo mkdir -p /home/ubuntu/test
# 권한 설정
sudo chown -R ubuntu:ubuntu /home/ubuntu/test

# Docker 이미지 정리 (오래된 이미지 제거)
# 오래된 이미지를 제거하지 않으면 디스크 용량 부족 문제가 발생할 수 있습니다.
echo "오래된 Docker 이미지 정리 중..."
docker image prune -f --filter "until=72h" || true

echo "BeforeInstall 완료"

2-2. After_install.sh 생성 및 코드 입력

#!/bin/bash

# ============================================
# CodeDeploy AfterInstall Hook
# 파일 설치 후 환경 설정
# ============================================

set -e

echo "========================================="
echo "AfterInstall: 환경 설정 시작"
echo "========================================="

cd /home/ubuntu/test

# GitHub Actions에서 전달한 배포 환경 변수 로드 (.env.deploy 파일)
# 이 파일에는 IMAGE_TAG, DEPLOY_ENV 등이 포함되어 있습니다
if [ -f .env.deploy ]; then
    export $(cat .env.deploy | xargs)
    echo "배포 환경 변수 로드 완료"
    echo "  - IMAGE_TAG: ${IMAGE_TAG}"
    echo "  - DEPLOY_ENV: ${DEPLOY_ENV}"
fi

# 환경 결정 (dev 또는 prod)
# DEPLOY_ENV가 없으면 기본값으로 'dev' 사용
DEPLOY_ENV=${DEPLOY_ENV:-dev}
PARAMETER_NAME="/test/${DEPLOY_ENV}/env"

echo "환경: ${DEPLOY_ENV}"
echo "Parameter Store 경로: ${PARAMETER_NAME}"

# 환경 변수 파일을 저장할 디렉토리 생성
mkdir -p env

# Parameter Store에서 환경 변수 가져와서 .env 파일 생성
echo "Parameter Store에서 환경 변수 가져오는 중..."

# .env 파일 생성(예: env/.env.dev 또는 env/.env.prod)
ENV_FILE="env/.env.${DEPLOY_ENV}"

# 파일 초기화(기존 내용 삭제)
> "$ENV_FILE"

# AWS Systems Manager Parameter Store에서 환경 변수 전체 가져오기
# --with-decryption: SecureString 타입지정시 파라미터 복호화 필요합니다.
echo "파라미터 가져오는 중: ${PARAMETER_NAME}"
ENV_CONTENT=$(aws ssm get-parameter \
  --name "${PARAMETER_NAME}" \
  --with-decryption \
  --query 'Parameter.Value' \
  --output text \
  --region ap-northeast-2 2>&1)

AWS_EXIT_CODE=$?

# 에러 체크
if [ $AWS_EXIT_CODE -ne 0 ]; then
    echo "ERROR: Parameter Store에서 환경 변수를 가져올 수 없습니다: ${PARAMETER_NAME}"
    echo "Exit code: $AWS_EXIT_CODE"
    echo "에러 메시지: ${ENV_CONTENT}"
    exit 1
fi

# Parameter 값이 비어있는지 확인합니다.
if [ -z "$ENV_CONTENT" ] || [ "$ENV_CONTENT" == "None" ]; then
    echo "ERROR: Parameter Store 값이 비어있습니다: ${PARAMETER_NAME}"
    echo "받은 값: '${ENV_CONTENT}'"
    exit 1
fi

echo "환경 변수 파싱 중..."

# 임시 파일에 저장합니다. (while loop에서 읽기 위함)
TEMP_ENV=$(mktemp)
echo "$ENV_CONTENT" > "$TEMP_ENV"

# 환경 변수 파싱 및 .env 파일에 저장
# 환경 변수를 한 줄씩 읽어서 처리
while IFS= read -r line || [ -n "$line" ]; do
    # 주석 라인 제거 (#으로 시작하는 라인)
    if [[ "$line" =~ ^[[:space:]]*# ]]; then
        continue
    fi
    
    # 빈 라인 제거
    line_trimmed=$(echo "$line" | xargs)
    if [ -z "$line_trimmed" ]; then
        continue
    fi
    
    # KEY=VALUE 형태인지 확인
    if [[ "$line" =~ ^[[:space:]]*([A-Za-z_][A-Za-z0-9_]*)=(.*)$ ]]; then
        KEY="${BASH_REMATCH[1]}"
        VALUE="${BASH_REMATCH[2]}"
        
        # 앞뒤 공백 제거
        VALUE=$(echo "$VALUE" | sed 's/^[[:space:]]*//;s/[[:space:]]*$//')
        
        # 따옴표 제거 (있는 경우)
        VALUE=$(echo "$VALUE" | sed "s/^['\"]//;s/['\"]$//")
        
        echo "${KEY}=${VALUE}" >> "$ENV_FILE"
        echo "  ✓ ${KEY} 설정 완료"
    else
	    # KEY=VALUE 형태가 아닌 라인은 무시
        echo "  ⚠ 무시된 라인: $line"
    fi
done < "$TEMP_ENV"

# 임시 파일 삭제
rm -f "$TEMP_ENV"

# GitHub Actions에서 전달받은 IMAGE_TAG를 .env 파일에 추가
# docker-compose.yml에서 이 값을 사용하여 올바른 이미지 버전을 실행
if [ -n "$IMAGE_TAG" ]; then
    echo "IMAGE_TAG=${IMAGE_TAG}" >> "$ENV_FILE"
    echo "  ✓ IMAGE_TAG 설정 완료: ${IMAGE_TAG}"
fi

echo "환경 변수 파일 생성 완료: ${ENV_FILE}"
echo "AfterInstall 완료"

2-3. application_start.sh 생성 및 코드 입력

#!/bin/bash

# ============================================
# CodeDeploy ApplicationStart Hook
# Blue-Green 배포 실행
# ============================================
# 에러 발생시 즉시 종료
set -e 

echo "========================================="
echo "ApplicationStart: Blue-Green 배포 시작"
echo "========================================="

cd /home/ubuntu/test

# 환경 변수 로드
if [ -f .env.deploy ]; then
    export $(cat .env.deploy | xargs)
fi

# DEPLOY_ENV 확인 (기본값: dev)
DEPLOY_ENV=${DEPLOY_ENV:-dev}
echo "배포 환경: ${DEPLOY_ENV}"

# SSM에서 가져온 환경 변수 파일 로드 (ALB 환경 변수 포함)
# ENV_FILE에는 ALB ARN, ALB_TARGET_GROUP_BLUE_ARN, ALB_TARGET_GROUP_GREEN_ARN 등이 작성된 상태여야 합니다.
ENV_FILE="env/.env.${DEPLOY_ENV}"
if [ -f "$ENV_FILE" ]; then
    echo "환경 변수 파일 로드 중: ${ENV_FILE}"
    # 주석과 빈 라인 제외하고 환경 변수 로드
    export $(cat "$ENV_FILE" | grep -v '^#' | grep -v '^$' | xargs)
    echo "환경 변수 로드 완료"
else
    echo "ERROR: 환경 변수 파일이 없습니다: ${ENV_FILE}"
    echo "after_install.sh가 정상적으로 실행되었는지 확인하세요."
    exit 1
fi

# 환경 변수 확인
if [ -z "$ALB_TARGET_GROUP_BLUE_ARN" ]; then
    echo "ERROR: ALB_TARGET_GROUP_BLUE_ARN 환경 변수가 설정되지 않았습니다."
    echo "Parameter Store에 다음 형식으로 추가하세요:"
    echo "  ALB_TARGET_GROUP_BLUE_ARN=arn:aws:elasticloadbalancing:..."
    exit 1
fi

if [ -z "$ALB_TARGET_GROUP_GREEN_ARN" ]; then
    echo "ERROR: ALB_TARGET_GROUP_GREEN_ARN 환경 변수가 설정되지 않았습니다."
	echo "Parameter Store에 다음 형식으로 추가하세요:"
    echo "  ALB_TARGET_GROUP_GREEN_ARN=arn:aws:elasticloadbalancing:..."
    exit 1
fi

# ALB 리스너 또는 리스너 규칙 ARN 확인(둘 중 하나는 반드시 필요합니다.)
# 저의 경우 하나의 ALB에 LISTENER_RULE을 사용하고 있어서 ALB_LISTENER_RULE_ARN도 parameter에 작성하였습니다.
if [ -z "$ALB_LISTENER_RULE_ARN" ] && [ -z "$ALB_LISTENER_ARN" ]; then
    echo "설정 방법:"
    echo "  - 리스너 규칙 사용 시: ALB_LISTENER_RULE_ARN=arn:aws:elasticloadbalancing:..."
    echo "  - 리스너 직접 사용 시: ALB_LISTENER_ARN=arn:aws:elasticloadbalancing:..."
    exit 1
fi

# 디버깅: ALB 환경 변수 확인
echo "========================================="
echo "배포 설정 정보"
echo "========================================="
echo "배포 환경: ${DEPLOY_ENV}"
echo "이미지 태그: ${IMAGE_TAG}"
echo ""
echo "ALB 설정:"
echo "  Blue Target Group: ${ALB_TARGET_GROUP_BLUE_ARN}"
echo "  Green Target Group: ${ALB_TARGET_GROUP_GREEN_ARN}"

if [ -n "$ALB_LISTENER_RULE_ARN" ]; then
    echo "ALB_LISTENER_RULE_ARN: ${ALB_LISTENER_RULE_ARN}"
else
    echo "ALB_LISTENER_ARN: ${ALB_LISTENER_ARN}"
fi

# Blue-Green 배포 스크립트 실행 및 권한 부여
chmod +x scripts/deploy.sh
./scripts/deploy.sh

echo "ApplicationStart 완료"

- application_start.sh까지가 Deploy를 위한 준비과정이었습니다.

- application_start.sh에서 deploy.sh을 실행하여 ec2 인스턴스에서 deploy가 진행되도록 합니다.

2-4. deploy.sh 생성 및 코드 입력

#!/bin/bash

# ============================================
# Blue-Green 배포 스크립트
# ALB 타겟 그룹 자동 전환
# ============================================

set -e # 에러 발생시 즉시 종료

# 색상 정의
RED='\033[0;31m'
GREEN='\033[0;32m'
BLUE='\033[0;34m'
YELLOW='\033[1;33m'
NC='\033[0m' # No Color

# 로그 함수
log_info() {
    echo -e "${BLUE}[INFO]${NC} $1"
}

log_success() {
    echo -e "${GREEN}[SUCCESS]${NC} $1"
}

log_error() {
    echo -e "${RED}[ERROR]${NC} $1"
}

log_warning() {
    echo -e "${YELLOW}[WARNING]${NC} $1"
}

# 의존성 확인 함수 추가
check_dependencies() {
    log_info "필수 도구 확인 중..."
    
    # jq 설치 확인 (JSON 파싱에 필요)
    if ! command -v jq &> /dev/null; then
        log_error "jq가 설치되지 않았습니다."
        log_error "설치 방법: sudo apt-get install -y jq"
        exit 1
    fi
}

# 환경 변수 확인
check_env_vars() {
    log_info "환경 변수 확인 중..."

    if [ -z "$ALB_TARGET_GROUP_BLUE_ARN" ]; then
        log_error "ALB_TARGET_GROUP_BLUE_ARN 환경 변수가 설정되지 않았습니다."
        exit 1
    fi

    if [ -z "$ALB_TARGET_GROUP_GREEN_ARN" ]; then
        log_error "ALB_TARGET_GROUP_GREEN_ARN 환경 변수가 설정되지 않았습니다."
        exit 1
    fi

     # 리스너 규칙 ARN 필수
    if [ -z "$ALB_LISTENER_RULE_ARN" ]; then
        log_error "ALB_LISTENER_RULE_ARN 환경 변수가 설정되지 않았습니다."
        log_error "특정 리스너 규칙에 대해 Blue-Green 배포를 진행합니다."
        exit 1
    fi

    # ========== 추가: 환경별 Docker Compose 파일 결정 ==========
    # DEPLOY_ENV 확인 (기본값: dev)
    DEPLOY_ENV=${DEPLOY_ENV:-dev}
    log_info "배포 환경: ${DEPLOY_ENV}"

    # 환경에 따른 Docker Compose 파일 설정
    if [ "$DEPLOY_ENV" = "prod" ]; then
        DOCKER_COMPOSE_FILE="docker-compose.blue-green.prod.yml"
    else
        DOCKER_COMPOSE_FILE="docker-compose.blue-green.dev.yml"
    fi

    log_info "Docker Compose 파일: ${DOCKER_COMPOSE_FILE}"

    # Docker Compose 파일 존재 확인
    if [ ! -f "$DOCKER_COMPOSE_FILE" ]; then
        log_error "Docker Compose 파일이 존재하지 않습니다: ${DOCKER_COMPOSE_FILE}"
        exit 1
    fi

    log_success "환경 변수 확인 완료"
}

# 현재 활성 환경 감지
get_active_environment() {
    log_info "현재 활성 환경 감지 중..."

    # 전체 규칙 데이터 가져오기
    RULE_JSON=$(aws elbv2 describe-rules \
        --rule-arns "$ALB_LISTENER_RULE_ARN" \
        --output json)
    
    # Weight가 1인 타겟 그룹 찾기
	# Blue-Green 배포에서는 한 쪽이 Weight=1, 다른 쪽이 Weight=0
    CURRENT_TARGET_GROUP=$(echo "$RULE_JSON" | \
        grep -B 1 '"Weight": 1' | \
        grep '"TargetGroupArn"' | \
        sed 's/.*"TargetGroupArn": "\([^"]*\)".*/\1/')
    
    # 값 확인
    log_info "현재 규칙의 타겟 그룹 ARN: '${CURRENT_TARGET_GROUP}'"
    log_info "Blue 타겟 그룹 ARN: '${ALB_TARGET_GROUP_BLUE_ARN}'"
    log_info "Green 타겟 그룹 ARN: '${ALB_TARGET_GROUP_GREEN_ARN}'"

    # ARN 비교 (앞뒤 공백 제거)
    CURRENT_TARGET_GROUP=$(echo "$CURRENT_TARGET_GROUP" | xargs)
    ALB_TARGET_GROUP_BLUE_ARN=$(echo "$ALB_TARGET_GROUP_BLUE_ARN" | xargs)
    ALB_TARGET_GROUP_GREEN_ARN=$(echo "$ALB_TARGET_GROUP_GREEN_ARN" | xargs)

    if [ "$CURRENT_TARGET_GROUP" = "$ALB_TARGET_GROUP_BLUE_ARN" ]; then
        ACTIVE_ENV="blue"
        INACTIVE_ENV="green"
        ACTIVE_PORT=8080
        INACTIVE_PORT=8081
    elif [ "$CURRENT_TARGET_GROUP" = "$ALB_TARGET_GROUP_GREEN_ARN" ]; then
        ACTIVE_ENV="green"
        INACTIVE_ENV="blue"
        ACTIVE_PORT=8081
        INACTIVE_PORT=8080
    else
        log_error "현재 타겟 그룹이 Blue 또는 Green과 일치하지 않습니다."
        log_error "현재 타겟 그룹: '${CURRENT_TARGET_GROUP}'"
        log_error "Blue ARN: '${ALB_TARGET_GROUP_BLUE_ARN}'"
        log_error "Green ARN: '${ALB_TARGET_GROUP_GREEN_ARN}'"
        exit 1
    fi

    log_success "활성 환경: $ACTIVE_ENV (포트: $ACTIVE_PORT)"
    log_info "배포 대상 환경: $INACTIVE_ENV (포트: $INACTIVE_PORT)"
}

# Docker 이미지 빌드
build_image() {
    log_info "Docker 이미지 빌드 중..."

    IMAGE_TAG="${IMAGE_TAG:-$(date +%Y%m%d-%H%M%S)}"
    export IMAGE_TAG

    docker compose -f $DOCKER_COMPOSE_FILE build test-$INACTIVE_ENV

    log_success "이미지 빌드 완료: test:$IMAGE_TAG"
}

# 비활성 환경에 새 버전 배포
deploy_to_inactive() {
    log_info "$INACTIVE_ENV 환경에 배포 중..."

    # 기존 컨테이너 중지 및 제거
    docker compose -f $DOCKER_COMPOSE_FILE stop test-$INACTIVE_ENV || true
    docker compose -f $DOCKER_COMPOSE_FILE rm -f test-$INACTIVE_ENV || true

    # 새 컨테이너 시작
    docker compose -f $DOCKER_COMPOSE_FILE up -d test-$INACTIVE_ENV

    log_success "$INACTIVE_ENV 환경 시작 완료"
}

# 헬스체크
health_check() {
    log_info "$INACTIVE_ENV 환경 헬스체크 중..."

    MAX_RETRY=30
    RETRY_COUNT=0
    HEALTH_URL="http://localhost:$INACTIVE_PORT/actuator/health"

    while [ $RETRY_COUNT -lt $MAX_RETRY ]; do
        if curl -f -s "$HEALTH_URL" > /dev/null 2>&1; then
            log_success "헬스체크 성공"
            return 0
        fi

        RETRY_COUNT=$((RETRY_COUNT + 1))
        log_warning "헬스체크 대기 중... ($RETRY_COUNT/$MAX_RETRY)"
        sleep 10
    done

    log_error "헬스체크 실패: $INACTIVE_ENV 환경이 정상적으로 시작되지 않았습니다."
    exit 1
}

# ALB 타겟 그룹 등록 확인
check_target_health() {
    log_info "ALB 타겟 헬스 상태 확인 중..."

	# 배포할 환경의 타겟 그룹 ARN 결정
    if [ "$INACTIVE_ENV" = "blue" ]; then
        TARGET_GROUP_ARN="$ALB_TARGET_GROUP_BLUE_ARN"
    else
        TARGET_GROUP_ARN="$ALB_TARGET_GROUP_GREEN_ARN"
    fi

    # EC2 인스턴스 ID 가져오기(IMDSv2 우선, v1 폴백)
    # 토큰 발급(IMDSv2)
    TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" \
        -H "X-aws-ec2-metadata-token-ttl-seconds: 21600" \
        -s --connect-timeout 2)

    # 사용하여 인스턴스 ID 가져오기
    if [ -n "$TOKEN" ]; then
        # IMDSv2 사용
        INSTANCE_ID=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" \
            -s http://169.254.169.254/latest/meta-data/instance-id)
        log_info "IMDSv2를 사용하여 인스턴스 ID 가져옴"
    else
        # IMDSv1 fallback
        INSTANCE_ID=$(curl -s http://169.254.169.254/latest/meta-data/instance-id \
            --connect-timeout 2)
        log_info "IMDSv1을 사용하여 인스턴스 ID 가져옴"
    fi


    # 디버깅: 변수 값 확인
    log_info "인스턴스 ID: $INSTANCE_ID"
    log_info "타겟 그룹 ARN: $TARGET_GROUP_ARN"
    log_info "포트: $INACTIVE_PORT"

    # 변수 검증
    if [ -z "$INSTANCE_ID" ] || [ "$INSTANCE_ID" = "null" ]; then
        log_error "인스턴스 ID를 가져올 수 없습니다."
        log_error "IMDS가 활성화되어 있는지 확인하세요."
        exit 1
    fi
    
    if [ -z "$INACTIVE_PORT" ]; then
        log_error "포트 번호가 설정되지 않았습니다."
        exit 1
    fi

      # 대기 시간 증가: 30번 × 15초 = 최대 7.5분
      # 대기시간을 최대 7.5분으로 한 이유는 서버가 실행하고 대상그룹이 상태를 확인하는데 시간이 어느정도 소요되기 때문입니다.
      # 짧은 시간으로 설정하면 unhealthy로 인해 배포가 실패합니다.
      MAX_RETRY=30
      RETRY_COUNT=0
      SLEEP_INTERVAL=15

    log_info "타겟 헬스 체크 시작 (최대 대기: $((MAX_RETRY * SLEEP_INTERVAL))초)"

    while [ $RETRY_COUNT -lt $MAX_RETRY ]; do
        HEALTH_INFO=$(aws elbv2 describe-target-health \
            --target-group-arn "$TARGET_GROUP_ARN" \
            --targets Id="$INSTANCE_ID",Port="$INACTIVE_PORT" \
            --query 'TargetHealthDescriptions[0].{State:TargetHealth.State,Reason:TargetHealth.Reason,Description:TargetHealth.Description}' \
            --output json 2>/dev/null)

        TARGET_HEALTH=$(echo "$HEALTH_INFO" | jq -r '.State // "unknown"')
        HEALTH_REASON=$(echo "$HEALTH_INFO" | jq -r '.Reason // ""')
        HEALTH_DESC=$(echo "$HEALTH_INFO" | jq -r '.Description // ""')


        if [ "$TARGET_HEALTH" = "healthy" ]; then
            log_success "타겟 헬스 상태: healthy"
            return 0
        fi

        RETRY_COUNT=$((RETRY_COUNT + 1))
         # 상세 정보 출력
        if [ -n "$HEALTH_REASON" ]; then
            log_warning "타겟 헬스 대기 중... 상태: $TARGET_HEALTH, 사유: $HEALTH_REASON ($RETRY_COUNT/$MAX_RETRY)"
        else
            log_warning "타겟 헬스 대기 중... 현재 상태: $TARGET_HEALTH ($RETRY_COUNT/$MAX_RETRY)"
        fi

        sleep $SLEEP_INTERVAL
    done


    log_error "타겟이 healthy 상태가 되지 않았습니다."
    log_error "마지막 상태: $TARGET_HEALTH"
    if [ -n "$HEALTH_REASON" ]; then
        log_error "사유: $HEALTH_REASON - $HEALTH_DESC"
    fi
    exit 1
}

# ALB 리스너 규칙 변경 (트래픽 전환)
switch_traffic() {
    log_info "트래픽을 $INACTIVE_ENV 환경으로 전환 중..."

    if [ "$INACTIVE_ENV" = "blue" ]; then
        NEW_TARGET_GROUP_ARN="$ALB_TARGET_GROUP_BLUE_ARN"
        OLD_TARGET_GROUP_ARN="$ALB_TARGET_GROUP_GREEN_ARN"
    else
        NEW_TARGET_GROUP_ARN="$ALB_TARGET_GROUP_GREEN_ARN"
        OLD_TARGET_GROUP_ARN="$ALB_TARGET_GROUP_BLUE_ARN"
    fi

    # Weight로 타겟 그룹 변경
    # 새 타겟 그룹: Weight=1, 기존 타겟 그룹: Weight=0
    aws elbv2 modify-rule \
        --rule-arn "$ALB_LISTENER_RULE_ARN" \
        --actions Type=forward,ForwardConfig="{TargetGroups=[{TargetGroupArn=${OLD_TARGET_GROUP_ARN},Weight=0},{TargetGroupArn=${NEW_TARGET_GROUP_ARN},Weight=1}],TargetGroupStickinessConfig={Enabled=false}}"

    log_success "트래픽 전환 완료: $ACTIVE_ENV -> $INACTIVE_ENV"
}

# 이전 환경 정리 (선택사항)
cleanup_old_environment() {
    log_info "이전 환경 정리 여부 확인..."

    # 30초 대기 후 이전 환경 중지 (롤백 가능 시간 확보)
    log_info "30초 후 이전 환경($ACTIVE_ENV)을 중지합니다..."
    sleep 30

    log_info "$ACTIVE_ENV 환경 중지 중..."
    docker compose -f $DOCKER_COMPOSE_FILE stop test-$ACTIVE_ENV

    log_success "이전 환경 정리 완료"
}

# 롤백 함수
rollback() {
    log_error "배포 실패! 롤백을 시작합니다..."

    # 트래픽을 다시 이전 환경으로 전환
    if [ "$ACTIVE_ENV" = "blue" ]; then
        ROLLBACK_TARGET_GROUP_ARN="$ALB_TARGET_GROUP_BLUE_ARN"
        OTHER_TARGET_GROUP_ARN="$ALB_TARGET_GROUP_GREEN_ARN"
    else
        ROLLBACK_TARGET_GROUP_ARN="$ALB_TARGET_GROUP_GREEN_ARN"
        OTHER_TARGET_GROUP_ARN="$ALB_TARGET_GROUP_BLUE_ARN"
    fi

    # Weight를 배포 인전 환경으로 되돌립니다.
    # 새 타겟 그룹: Weight=0, 기존 타겟 그룹: Weight=1
    aws elbv2 modify-rule \
        --rule-arn "$ALB_LISTENER_RULE_ARN" \
        --actions Type=forward,ForwardConfig="{TargetGroups=[{TargetGroupArn=${OTHER_TARGET_GROUP_ARN},Weight=0},{TargetGroupArn=${ROLLBACK_TARGET_GROUP_ARN},Weight=1}],TargetGroupStickinessConfig={Enabled=false}}"

    # 실패한 컨테이너 중지
    docker compose -f $DOCKER_COMPOSE_FILE stop test-$INACTIVE_ENV

    log_success "롤백 완료"
    exit 1

}

# 메인 배포 프로세스
main() {
    log_info "========================================="
    log_info "Blue-Green 배포 시작"
    log_info "========================================="

    # 오류 발생 시 롤백
    trap rollback ERR

    # 사전 검증
	check_dependencies
    check_env_vars
    
    # 환경 분석
    get_active_environment

	# 새 버전 빌드 및 배포
	build_image
    deploy_to_inactive
	
    # 헬스체크
	health_check
    check_target_health

	# 트래픽 전환
    switch_traffic
    
    # 정리
    cleanup_old_environment

    log_success "========================================="
    log_success "배포 완료!"
    log_success "활성 환경: $INACTIVE_ENV (포트: $INACTIVE_PORT)"
    log_success "========================================="
}

# 스크립트 실행
main "$@"

- deploy.sh이 실행이 되면서 EC2 내부에서 배포가 진행이 됩니다.

- 각 함수마다 어떤 내용이 있는지 주석으로 설명을 작성하였습니다.

- check target health에서 7.5분까지 하지 않으셔도 되지만 health check가 실패한다면 시간을 너무 짧게 가져가셔 그럴 수 도 있으니 확인해보시면 될 거 같습니다.

3. docker-compose 파일 작성

services:
  # Blue 환경
  test-blue:
    build:
      context: .
      dockerfile: Dockerfile.deploy
      args:
        PROFILE: dev
    image: test:${IMAGE_TAG:-latest}
    container_name: test-blue
    env_file:
      - env/.env.dev
    environment:
      SPRING_PROFILES_ACTIVE: dev
      DB_HOST: ${DB_HOST}
      DB_PORT: ${DB_PORT}
      DB_NAME: ${DB_NAME}
      DB_SCHEMA: ${DB_SCHEMA}
      DB_USERNAME: ${DB_USER}
      DB_PASSWORD: ${DB_PASSWORD}
      SERVER_PORT: 8080
      TZ: Asia/Seoul
      DEPLOYMENT_ENV: blue
      JAVA_OPTS: >-
        -Xms512m -Xmx1024m -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/test/heapdump.hprof -Duser.timezone=Asia/Seoul -Dfile.encoding=UTF-8
    ports:
      - "8080:8080"
    restart: always
    logging:
      driver: "json-file"
      options:
        max-size: "100m"
        max-file: "10"
    healthcheck:
      test: [ "CMD", "wget", "--no-verbose", "--tries=1", "--spider", "http://localhost:8080/actuator/health" ]
      interval: 30s
      timeout: 10s
      retries: 5
      start_period: 90s
    deploy:
      resources:
        limits:
          cpus: '1.0'
          memory: 1536M
        reservations:
          cpus: '0.5'
          memory: 1024M
      restart_policy:
        condition: on-failure
        delay: 5s
        max_attempts: 3
        window: 120s

  # Green 환경
  test-green:
    build:
      context: .
      dockerfile: Dockerfile.deploy
      args:
        PROFILE: dev
    image: test:${IMAGE_TAG:-latest}
    container_name: test-green
    env_file:
      - env/.env.dev
    environment:
      SPRING_PROFILES_ACTIVE: dev
      DB_HOST: ${DB_HOST}
      DB_PORT: ${DB_PORT}
      DB_NAME: ${DB_NAME}
      DB_SCHEMA: ${DB_SCHEMA}
      DB_USERNAME: ${DB_USER}
      DB_PASSWORD: ${DB_PASSWORD}
      SERVER_PORT: 8080
      TZ: Asia/Seoul
      DEPLOYMENT_ENV: green
      JAVA_OPTS: >-
        -Xms512m -Xmx1024m -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/test/heapdump.hprof -Duser.timezone=Asia/Seoul -Dfile.encoding=UTF-8
    ports:
      - "8081:8080"
    restart: always
    logging:
      driver: "json-file"
      options:
        max-size: "100m"
        max-file: "10"
    healthcheck:
      test: [ "CMD", "wget", "--no-verbose", "--tries=1", "--spider", "http://localhost:8080/actuator/health" ]
      interval: 30s
      timeout: 10s
      retries: 5
      start_period: 90s
    deploy:
      resources:
        limits:
          cpus: '1.0'
          memory: 1536M
        reservations:
          cpus: '0.5'
          memory: 1024M
      restart_policy:
        condition: on-failure
        delay: 5s
        max_attempts: 3
        window: 120s
....

- docker compose 파일은 blue, green 서비스를 생성하는 방식으로 하였습니다.

- script에서도 실행을 할 때, blue가 active 상태인 경우 green을 실행하도록 구성하였습니다.

- 정상적으로 배포가 완료되었다면 CodeDeploy에서 확인하실 수 있습니다.

추가적으로 github-action에서 마지막 step 이후에 배포가 성공/실패/취소 여부에 따라서 슬랙에 알림이 오도록 구현하였습니다.

이 부분은 CI/CD와는 연결된 부분이 아니라서 제거하였습니다.

CI/CD를 할 때 여러 번 실패를 경험하고 조금씩 수정하면서 진행하다 보니 생각보다 걸리긴 했지만, 저도 여러번 실패학 수정하고 시도하였습니다. 그래도 성공했을 때 행복했던 느낌을 같이 가져가셨으면 합니다.

Ref.

https://develop-706.tistory.com/40

[CI/CD] Github Action 을 통한 Spring boot 배포 자동화 구축하기 !

개요배포 경험이 있는 사람들은 공감하실 것 입니다.수동으로 배포하는 과정이 얼마나 힘들고 귀찮은 과정인지를..! 저번에는 Github 과 Jenkins 를 사용해서 배포 자동화를 구축했었는데요.

develop-706.tistory.com

https://velog.io/@chae_ag/series%EB%B0%B0%ED%8F%ACSpring-Boot-GitHub-Actions-AWS-CodeDeploy%EB%A5%BC-%EC%82%AC%EC%9A%A9%ED%95%98%EC%97%AC-CICD-%EA%B5%AC%EC%B6%95%ED%95%98%EA%B8%B0

Spring Boot + GitHub Actions + AWS CodeDeploy를 사용하여 CI/CD 구축하기

velog.io

[EC2] Github-Action으로 EC2에 Spring-Boot 배포(Blue-Green) - 1

조용한외침 — Thu, 25 Dec 2025 21:26:07 +0900

Spring-Boot 서버를 EC2에 수동으로 배포를 하려면 code를 merge 한 이후에 인스턴스에서 pull 받은 후 컨테이너를 다시 재실행해야 했습니다. 이 방식의 문제점은 수동 배포를 하는 과정은 물론 서버의 중단이 발생하며, 컨테이너가 build 후 재실행하면서 어떠한 요청에도 응답을 줄 수 없는 상태가 됩니다. 사용자 및 운영적인 측면에서 큰 문제가 될 수 있다고 판단하여, CI/CD를 적용하고 서버도 Blue-Green방식으로 변경하는 과정을 경험하였고 그 과정을 작성하려고 합니다.

혹시라도 부정확한 정보를 전달드릴 수 있습니다. 다만 틀린 거나 부정확한 정보가 있다면 댓글을 남겨주세요

* 저는 SSM Parameter를 이용하고 있습니다.
* Github-Action의 Secerts을 일부분 사용하고 있으며, env는 사용하지 않습니다.

* 혹시 Github-Action의 env를 이용하신다면 그부분은 github workflow에서 수정해서 사용하시면 될 거 같습니다.

1. IAM 생성 및 EC2 인스턴스에 IAM 설정

IAM 생성

- IAM에서 역할 생성을 선택 후 사용사례에서 EC2를 선택합니다.

IAM 권한추가

- AmazonS3ReadOnlyAccess, AmazonSSMReadOnlyAccess, AWSCodeDeployRole

- 4개의 권한을 추가합니다.

- AmazonS3ReadOnlyAccess: CodeDeploy가 S3에서 배포 파일을 가져오기 위함입니다.

- AmazonSSMReadOnlyAccess: ssm parameter에 있는 env파일을 가져오기 위함입니다.

- AWSCodeDeployRole: AWS CodeDeploy agent가 EC2에서 배포 작업을 수행하기 위함입니다.

- 이름을 입력하여 IAM을 생성합니다.

- 오른쪽 이미지 처럼 권한정책을 확인할 수 있습니다.

{
	"Version": "2012-10-17",
	"Statement": [
		{   // Blue-Green 배포를 위해 리스너 규칙을 수정하고, 대상 그룹 상태를 확인하는 권한입니다.
			"Effect": "Allow",
			"Action": [
				"elasticloadbalancing:ModifyListener",
				"elasticloadbalancing:DescribeListeners",
				"elasticloadbalancing:DescribeTargetHealth",
				"elasticloadbalancing:DescribeTargetGroups"
			],
			"Resource": "*"
		},
		{
        	// CodeDeploy가 배포 대상 EC2 인스턴스 정보를 조회하기 위한 권한입니다.
			"Effect": "Allow",
			"Action": [
				"ec2:DescribeInstances"
			],
			"Resource": "*"
		},
		{
        	// SSM Parameter 환경변수를 읽어오기 위한 권한입니다.
			"Effect": "Allow",
			"Action": [
				"ssm:GetParameter",
				"ssm:GetParameters",
				"ssm:GetParametersByPath"
			],
			"Resource": [
    			// 파라미터에서 지정한 경로를 등록합니다.
				"arn:aws:ssm:ap-northeast-2:*:parameter/test/dev/*"
			]
		},
		{
        	// ssm에서 유형이 SecureString인 경우 설정하셔야 합니다.
	        // SSM SecureString 파라미터 복호화를 위한 KMS 권한입니다.
			"Effect": "Allow",
			"Action": [
				"kms:Decrypt",
				"kms:DescribeKey"
			],
			"Resource": "*",
			"Condition": {
				"StringEquals": {
					"kms:ViaService": "ssm.ap-northeast-2.amazonaws.com"
				}
			}
		},
		{
        	// CodeDeploy가 S3에서 배포 파일을 다운로드하기 위한 권한입니다.
			"Effect": "Allow",
			"Action": [
				"s3:GetObject",
				"s3:ListBucket"
			],
			"Resource": [
				"arn:aws:s3:::test-deployments",
		        "arn:aws:s3:::test-deployments/*"
			]
		}
	]
}

- 추가적으로 권한을 추가합니다.

- AWSCodeDeployRole 정책도 추가로 생성합니다.(CodeDeploy에서 사용할 예정입니다.)

- 최종적으로 2개의 역할을 생성하였습니다.

2. SSM Parameter Store에 Env 경로 설정

ssm parameter store

parameter store 예시

- 파라미터 생성을 선택 후 이름, 설명(optional), 유형을 선택합니다.

- 이름은 IAM에 등록한 경로로 해줘야 읽을 수 있습니다.(ex. /test/dev/...)

- 유형에서 보안 문자열(SecureString)을 사용하시지 않는다면 IAM에서 설정한 부분을 제거해도 됩니다.

- 데이터 형식에는 로컬에서 사용하던 env 내용을 복사해서 넣어주면 됩니다.

3. VPC Endpoint 생성

- NAT Gateway가 없으면 Private subnet으로 서버를 운영할 때 가져올 수 있는 방법이 없어서, AWS에 접근하기 위해서입니다.

- SSM Endpoint: Parameter Store에서 환경변수 파일을 가져옵니다.

- S3 Endpoint: CodeDeploy가 배포 파일을 다운로드합니다.(Gateway)

- EC2 인스턴스가 생성된 VPC로 지정해주시면 됩니다.

- SSM 지정 시 서브넷이 나오는데 EC2가 위치해 있는 서브넷을 지정해 주시면 됩니다.

- 보안그룹을 지정하는 부분에서는 인바운드 규칙에서 소스에 EC2 인스턴스의 보안그룹 id를 입력합니다.

4. ALB에 대상그룹 지정

- Blue-Green 배포를 위해서는 기존에 하나의 대상그룹에서 추가적으로 다른 포트로 대상그룹을 생성해 주고 연결해줘야 합니다.

- 저는 포트를 8080과 8085를 사용하고 있어서 2개의 대상그룹으로 생성하였습니다.

- VPC도 인스턴스가 있는 VPC로 선택합니다.

- 상태검사는 코드에서 구현하신 부분을 작성하면 됩니다.

- 생성한 대상 그룹을 ALB에 연결합니다.

- 이때 가중치는 현재 실행되고 있는 서버의 포트와 일치하는 대상그룹에 100%을 지정합니다.

- 대상그룹의 변경은 CodeDeploy에서 실행이 됩니다.

- ALB의 보안그룹에서 아웃바운드도 설정한 포트를 사용할 수 있도록 해줘야 합니다.

5. S3에 버킷 생성

- 배포 파일이 저장될 S3 버킷을 생성합니다.

- 버킷 명은 이전에 IAM에서 입력한 버킷명과 일치해야 합니다.(ex. test-deployments)

6. EC2 - IAM을 역할 지정

- 이전에 생성한 IAM을 지정합니다.

7. CodeDeploy - 애플리케이션 생성

- 애플리케이션을 생성한 후 그룹도 생성합니다.

- 배포그룹 생성 시 IAM에서 생성한 AWSCodeDeployRole을 지정합니다.

- 저는 인스턴스 2개를 사용하지 않기 때문에 인스턴스의 이름으로 지정하였습니다.

- 키에 Name을 지정하면 인스턴스 목록이 나옵니다. 이후 원하는 인스턴스를 지정합니다.

- 에이전트 구성은 인스턴스에 에이전트가 설치가 안 됐을 수 있습니다.

// 인스턴스 내부에서 명령어 입력
sudo systemctl status codedeploy-agent

- 설치가 됐다면 이미지처럼 active를 확인할 수 있습니다.(에이전트가 설치가 안 됐다면 수동으로 설치해야 합니다.)

- 배포 설정은 AllAtOnce로 지정하였습니다. 단일 인스턴스에서 Blue-Green을 사용함으로 실패하더라도 실행 중인 서버는 유지되기 때문입니다.

- AllAtOnce: 모든 인스턴스에 한 번에 배포

- HalfAtATime: 다중 인스턴스의 경우 절반씩 배포

- OneAtATime: 한 번에 하나씩만 배포

CodeDeploy Script와 Github-Action 부분은 다음 글로 작성하도록 하겠습니다.

Ref.

https://develop-706.tistory.com/40

[CI/CD] Github Action 을 통한 Spring boot 배포 자동화 구축하기 !

develop-706.tistory.com

https://velog.io/@chae_ag/series%EB%B0%B0%ED%8F%ACSpring-Boot-GitHub-Actions-AWS-CodeDeploy%EB%A5%BC-%EC%82%AC%EC%9A%A9%ED%95%98%EC%97%AC-CICD-%EA%B5%AC%EC%B6%95%ED%95%98%EA%B8%B0

Spring Boot + GitHub Actions + AWS CodeDeploy를 사용하여 CI/CD 구축하기

velog.io

[Ngrok] Ngrok을 활용한 로컬 서버 전환

조용한외침 — Mon, 22 Dec 2025 23:25:16 +0900

포트원의 웹훅을 활용하기 위해서 로컬에서 어떤 식으로 테스트할 수 있을지 찾아보게 되었습니다. 그중 Ngrok을 활용하면 테스트가 가능하다는 것을 확인하고 Ngrok의 가입부터 실행방법을 작성하려고 합니다.

혹시라도 부정확한 정보를 전달드릴 수 있습니다. 다만 틀린 거나 부정확한 정보가 있다면 댓글을 남겨주세요

1. Ngrok 공식 사이트에서 환경에 맞게 설치 진행(링크)

- 사이트대로 따라하면 쉽게 설치할 수 있습니다.

Mac에서 Ngrok 설치

2. 설치하면서 Ngrok에 회원가입을 진행합니다.

- 진행하지 않으면 token을 발급받지 못하여 외부에서 접근을 할 수 없습니다.

3. 회원가입 후 Token 확인

- 좌측 Your Authtoken을 클릭해서 토큰을 복사합니다.

4. 로컬에 토큰을 등록합니다.

- ngrok config add-authtoken '본인 토큰'

5. 현재 로컬에서 실행중인 서버의 포트를 입력합니다.

- ngrok http '실행포트'

- 저는 8083으로 실행하고 있습니다.(ex. ngrok http 8083)

- Forwarding에 URL이 있습니다. 해당 URL로 요청을 보내면 테스트를 진행할 수 있습니다.

Ref.

https://cordcat.tistory.com/105

Ngrok - 특징 및 사용법 (로컬 서버를 공개 서버로)

What is a NgrokNgrok은 로컬 개발 환경에서 인터넷을 통해 웹 애플리케이션에 안전하게 접근할 수 있도록 해주는 도구입니다. 보안 연결을 통해 인터넷에서 서버를 실행할 수 있으며, 웹 애플리케이

cordcat.tistory.com

[AWS]No space left on device @ fptr_finalize_flush - /opt/codedeploy-agent/deployment-root/ongoing-deployment/

조용한외침 — Mon, 22 Dec 2025 22:39:35 +0900

AWS Ec2를 이용 중인 상황에서 CodeDeploy로 배포를 진행하고 있습니다. 그러다 마주친 에러가 있어서 글을 남겨보려고 합니다.

혹시라도 부정확한 정보를 전달드릴 수 있습니다. 다만 틀린거나 부정확한 정보가 있다면 댓글을 남겨주세요

No space left on device는 에러에서 확인할 수 있듯이 디바이스에 남는 공간이 없다는 의미입니다.

저는 CodeDeploy를 이용해서 배포를 하려고 했으나 여유 공간이 없다는 것을 확인하였습니다.

1. 에러 확인

CodeDeploy

- 배포 실패시 이벤트에서 메시지를 확인할 수 있습니다.

- No space left on device 에러 확인

2. 인스턴스의 남은 볼륨 확인

- 인스턴스에 접근하여 df -h 로 확인이 가능합니다.

Ec2

- 실제로 확인하니 /dev/root의 size가 15G가이면 15G를 모두 사용중입니다.

- 인스턴스 생성시 볼륨을 30G까지는 무료이나 해당 인스턴스는 15G로 생성된 상태입니다.

- 30G로 볼륨을 확장하는 방법은 GUI에서 볼륨을 선택하여 추가적으로 증가시킬 수 있습니다.(볼륨 증가관련 부분 제가 참고한 블로그를 확인하시면 쉽게 따라하실 수 있습니다.)

3. 불필요한 파일 삭제

- 저의 경우는 확장은 하지않고 어떤 파일들이 문제를 발생하는지 알아서 삭제 처리하였습니다.

- 불필요한 파일들은 CI/CD를 진행하면서 기존에 배포했던 폴더를 zip파일로 backup 폴더에서 관리하도록 하면서 발생한 문제였습니다.

Ref.

https://velog.io/@yul_ee/AWS-CodeDeploy-%EB%B0%B0%ED%8F%AC%EC%8B%A4%ED%8C%A8-%EB%AC%B8%EC%A0%9C-%ED%95%B4%EA%B2%B0%ED%95%98%EA%B8%B0

[AWS] 서버 용량 부족으로 인한 CodeDeploy 배포실패 해결하기 ‍

문제 발견 '프리비' 서비스를 개발하는 과정에서 얼마전부터 계속 CodeDeploy를 이용한 배포가 실패하는 문제가 발생했다. 꽤 오래전부터 배포 실패가 계속되고 있었는데, 프론트엔드와 백엔드의

velog.io

ACM(외부에서 발급받은 도메인) - Route53 연결

조용한외침 — Fri, 19 Dec 2025 23:16:43 +0900

AWS에서 발급받은 도메인이 아닌 경우 자동으로 갱신이 되지 않고 발급받은 도메인을 직접 등록해줘야 합니다.

저는 현재 회사에서 제가 도메인을 직접 발급받지 않았지만 ALB와 연결을 하기 위해서 ACM을 설정해 주는 방법을 기록하고 작성하려고 합니다.

혹시라도 부정확한 정보를 전달드릴 수 있습니다. 다만 틀린거나 부정확한 정보가 있다면 댓글을 남겨주세요

1. AWS ACM에서 사용하는 인증서 확인

2. 등록한 인증서를 퍼블릭 인증서 요청으로 등록

3. 퍼블릭 인증서 요청에서 원하는 도메인 등록

- 도메인 등록시 특정한 하나의 도메인만 사용한다면 aaa.bbb.com으로 해도 됩니다.

- 만약, 모든 서브도메인을 사용하고 싶다면 *.bbb.com으로 등록해야 합니다.

- 내보내기는 인증서가 외부에서 필요한 경우인데 저는 ALB와 Route53에서 사용할 예정이라서 비활성화를 하였습니다.

- 검증 방법은 Route53에서 사용할 예정이며 CNAME Route53에 자동으로 생성됩니다.

4. 인증서를 등록하면 상태를 확인할 수 있습니다.

- 저는 다른 서브도메인을 사용하기 위해서 *를 사용하였습니다.

5. 발급받은 인증서를 확인합니다.

- CNAME 이름을 복사 후 Route53에서 검색을 해보면 CNAME으로 레코드가 생성된 것을 확인할 수 있습니다.

6. Route53에서 CNAME을 확인합니다.

- CNAME이 등록되는데 시간이 조금(몇 분) 소요됩니다.

7. Route53에서 AName으로 레코드를 생성합니다.

- 기존에 사용하던 ALB(로드밸런서)에 규칙으로 지정하였습니다.

8. ALB에 인증서를 등록해 주면 됩니다. 이후 ACM을 확인하면 연결된 리소스에 ALB를 확인할 수 있습니다.

Ref.

https://sw-ym.tistory.com/200

[AWS] 가비아 도메인 + ACM + ALB 연결 방법

이번 시간에는 이전에 구입한 가비아 도메인을 기반으로 ACM 인증서를 생성하고, 이를 ALB에 연결하는 과정을 진행해본다. ACM(AWS Certificate Manager)은 AWS에서 제공하는 인증서 관리 서비스로, HTTPS 통

sw-ym.tistory.com

SAM 을 이용한 AWS Lambda 배포

조용한외침 — Sun, 30 Nov 2025 23:33:11 +0900

Lambda에 배포하는 방법 중에 하나로 SAM을 이용하여 배포하는 방법이 있습니다. 오늘은 SAM으로 람다에 함수를 배포하고 관리할 수 있도록 구성했던 부분을 작성하도록 하겠습니다. (제가 진행했던 방식은 Mac에서 진행하였습니다.)

혹시라도 부정확한 정보를 전달드릴 수 있습니다. 다만 틀린 부분이 있으면 댓글을 남겨주세요.

1. SAM 설치(AWS 링크)

- 환경에 맞게 SAM을 설치합니다.

# Mac
brew tap aws/tap
brew install aws-sam-cli
sam --version # sam이 정상적으로 설치가 됐다면 버전이 나옵니다.

2. 설치 이후 명령어를 통해 SAM 관련 파일을 생성합니다.

sam init
# 이후 나타는 설정은 상황에 맞게 진행해주시면 됩니다.

템플릿 설정

- 템플릿을 지정하는 부분입니다.

- Quick Start Templates로 만들고 생성된 파일을 수정하셔도 됩니다.

- Quick Start Templates 선택 시 어떤 템플릿을 배포할 건지 지정하는 부분입니다.

- y/N 에서는 대문자로 된 부분이 엔터를 입력하면 자동으로 N으로 처리가 됩니다.

- 어떤 언어로 함수를 작성할지 지정합니다.

- 람다에 배포하기 위해서 Zip파일을 선택했습니다.(Image는 도커 이미지를 의미합니다.)

- Nodejs 선택 시 typescript로 배포를 할지를 확인합니다.

- 저는 나머지 부분에서 default로 선택하였습니다.

- 이후 제가 설정한 대로 sam 폴더가 생성되면 내부에는 원하는 설정들이 된 파일들이 생성돼 있습니다.

3. samconfig, template 파일 확인

- samconfig.toml 파일은 배포를 진행할 때 AWS에서 사용할 부분들을 지정합니다.

# 하단 URL에 접속 시 어떤 키와 값으로 작성해야 하는지 정보를 알 수 있습니다.
# https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-config.html
version = 0.1

# global.parameters는 전역에서 사용할 수 있는 영역이라고 보면 됩니다.
# 각 영역에서 stack_name을 따로 지정하지 않았다면 global.parameters를 사용합니다.
[default.global.parameters]
stack_name = "sam-app"

# build 할때 parameter 입니다.
[default.build.parameters]
cached = true # 빌드 시 변경 사항이 없다면 캐시된 결과를 재사용 합니다.
parallel = true # 함수가 여러개 있을 때 병렬로 배포합니다.

# 유효성 검증
[default.validate.parameters]
lint = true

# 배포시 사용하는 파라미터 입니다.
[default.deploy.parameters]
capabilities = "CAPABILITY_IAM" # CloudFormation이 리소스를 생성하거나 수정할 수 있도록 허용합니다.
confirm_changeset = true # CloudFormation 변경을 사용자에게 보여줍니다.
resolve_s3 = true # S3 버킷을 자동으로 생성하거나 기존의 버킷을 재사용하도록 설정합니다.

[default.package.parameters]
resolve_s3 = true # s3 버킷을 지정하지 않았다면 자동으로 버킷을 찾거나 생성합니다.(지정했다면 false로 유지)

- template.yaml 파일은 Lambda 구성을 설정합니다.

# Default로 생성된 파일입니다.
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: >
  sam-app

  Sample SAM Template for sam-app
  
# More info about Globals: https://github.com/awslabs/serverless-application-model/blob/master/docs/globals.rst
Globals:
  Function:
    Timeout: 3

Resources:
  HelloWorldFunction:
    Type: AWS::Serverless::Function # More info about Function Resource: https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md#awsserverlessfunction
    Properties:
      CodeUri: hello-world/
      Handler: app.lambdaHandler
      Runtime: nodejs22.x
      Architectures:
        - x86_64
      Events:
        HelloWorld:
          Type: Api # More info about API Event Source: https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md#api
          Properties:
            Path: /hello
            Method: get

Outputs:
  # ServerlessRestApi is an implicit API created out of Events key under Serverless::Function
  # Find out more about other implicit resources you can reference within SAM
  # https://github.com/awslabs/serverless-application-model/blob/master/docs/internals/generated_resources.rst#api
  HelloWorldApi:
    Description: "API Gateway endpoint URL for Prod stage for Hello World function"
    Value: !Sub "https://${ServerlessRestApi}.execute-api.${AWS::Region}.${AWS::URLSuffix}/Prod/hello/"
  HelloWorldFunction:
    Description: "Hello World Lambda Function ARN"
    Value: !GetAtt HelloWorldFunction.Arn
  HelloWorldFunctionIamRole:
    Description: "Implicit IAM Role created for Hello World function"
    Value: !GetAtt HelloWorldFunctionRole.Arn

- Resources 영역에 AWS에 있는 다른 서비스들은 연결하거나 Event Handler, VPC Config 등을 지정할 수 있습니다.

4. 배포 진행

# 처음 build 시에는 --guided를 필수로 입력하시고 이후에는 build만 진행하셔도 됩니다.
sam build --guided
sam deploy

- 정상적으로 deploy가 된 다면 각각의 AWS에서 확인할 실수 있습니다.

CloudFormation

lambda-applicaion

lambda-function

lambda-function-detail

Deploy 진행하다가 실패한다면???

- 실패시 Cloudformation 스택에서 failed된 스택을 삭제하고 문제가 있던 samconfig 파일을 수정하고 deploy를 진행해야 합니다.

현재는 로컬에서 명령어로 배포하는 부분을 진행하였지만, 이후에는 github-action을 이용해서 배포 자동화를 하는 부분도 작성할 수 있도록 하겠습니다.

처음에는 lambda가 불편하고 어렵다고 생각했지만 가벼운 기능들을 자주 사용하다보면 더 확장된 기능들을 사용해 볼 수 있을 것이라고 생각하고 있습니다.

Ref.

https://velog.io/@leejm_dev/AWS-SAM

AWS SAM

how to use AWS SAM with cloudformation

velog.io

모바일 카드 만들기

조용한외침 — Wed, 12 Nov 2025 00:55:30 +0900

요즘은 여러 행사들이 많이 있습니다. 결혼식, 돌잔치, 칠순, 행사 등 다양한 이벤트들이 존재합니다.

이런 이벤트에는 링크를 보내서 친구, 가족 등 사람들에게 링크를 전달하고 소식을 전하고 있습니다.

돈을 주고 요청을 하면 좋은 서비스를 이용할 수 있는지 저는 잘 모르지만 모두가 쉽게 만들고 사용할 수 있는 서비스를 만들어서 공유하고 싶다는 생각이 들었습니다.

직접 만들면 의미가 더 있을 수 도 있고 돈도 절약할 수 있다는 생각에서 시작하였습니다.

1. 스프레드 시트에 아래 값을 넣어주세요.

- A 열에 동일한 값을 넣어주시고 B열에는 보여주고 싶은 값을 넣으시면 됩니다.

groom_name - 신랑 이름
bride_name - 신부 이름
wedding_date - 결혼식 날짜
wedding_location - 결혼식 장소
invitation_title - 제목
invitation_text - 내용
groom_father_name - 신랑 아버지 이름
groom_mother_name - 신랑 어머니 이름
bride_father_name - 신부 아버지 이름
bride_mother_name - 신부 아버지 이름
groom_phone - 신랑 전화번호
bride_phone - 신부 전화번호
groom_father_phone - 신랑 아버지 전화번호
groom_mother_phone - 신부 어머니 전화번호
bride_father_phone - 신부 아버지 전화번호
bride_mother_phone - 신부 어머니 전화번호
main_background_img - 메인 이미지

2. 이미지는 구글 드라이브에 넣어주세요.

- 이미지를 업로드한 후 우측 점 3개를 누르세요.

- 공유를 클릭하세요.

- 제한됨으로 된 상태를 링크가 있는 모든 사용자로 변경하면서 모든 사용자는 뷰어로 지정해 주세요.

- 이후 링크복사를 클릭하여 이미지 링크를 복사합니다.

- 복사한 링크를 스프레드시트에 갤러리 탭에 넣어줍니다.(1번 줄은 비워두시면 됩니다.)

3. 안내사항

- 안내사항이라는 탭을 생성합니다.

- 1번 행은 비워둡니다.

- A열은 주소, 지하철, 주차장을 지정합니다.

- B열은 해당 A열에 해당하는 값을 작성합니다.

4. 코드 구성 및 배포

- Apps Script를 선택합니다.

- 4개의 파일 생성합니다.( 파일 생성은 + 버튼을 누르면 가능합니다.)

- 4개의 파일은 압축 파일을 다운로드하신 다음에 복사해서 넣으시면 되겠습니다.

압축파일.zip

0.01MB

- Code.gs 파일에는 스프레드 시트 주소를 넣어야 합니다.

- 스프레드 시트 주소는 흰색으로 가린 부분이라고 생각하시면 됩니다. 이 주소는 스프레드시트 상단 주소에서 확인하실 수 있습니다.

- 흰색으로 가린 부분의 값을 복사하여 Code.gs에 넣어줍니다.

- 모든 파일을 생성하고 코드를 넣었다면 배포 버튼을 클릭하여 새배포를 클릭합니다.

- 설명에는 원하시는 글자를 넣어준 후 배포버튼을 클릭합니다.(넣을 값이 없다면 배포 1이라고 넣으셔도 됩니다.)

- 웹앱에 URL 부분에 파란색 주소가 이제 모바일 카드 주소입니다.

- 주소를 복사해서 사용하시면 모바일 카드를 확인하실 수 있습니다.

시연 영상

설명이 어려우실 수도 있지만 혹시라도 사용하실 때 모르시는 부분이 있으시다면 댓글 남겨주시면 도움을 드릴 수 있도록 하겠습니다.
조금 씩 사용성이나 부족한 부분을 고쳐나갈 수 있도록 해보겠습니다.

불편한점이 있으시면 피드백을 주시는건 언제나 환영입니다.

감사합니다.

-25년 10월 -