AWS CloudWatch 로깅 시스템 추가

[minibr]

관련 이슈

• close CloudWatch 로깅 시스템 구현 #44

PR 설명

• build.gradle에 logback-awslogs-appender 의존성 추가
• logback-spring.xml 설정 파일 추가
  • 로컬 개발: Active profiles에 dev 설정
  • 운영 배포: Active profiles를 prod로 설정하고 AWS 환경변수 필요 (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY)
  • 환경변수 기반 AWS 인증
• AWS /aws/linkiving/application 로그 그룹으로 중앙화 관리
• 로컬 개발 시 비용 발생 없음, 운영 배포 시에만 CloudWatch 사용

Test 결과

• dev 프로필에서 CloudWatch 전송 비활성화 확인
• prod 프로필에서 AWS 로그 그룹 생성 및 전송 성공
• 로그 레벨별 정상 출력 확인

Summary by CodeRabbit

• Chores
  • Enabled centralized log streaming to AWS CloudWatch in production to improve observability, diagnostics, and log retention.
  • Maintains existing console logging; non-production environments continue to log to console only.
  • Tuned batching and flush behavior to reduce overhead while ensuring timely log delivery.
  • No impact on application functionality or APIs; changes are operational/monitoring focused.

[minibr]

노션 logging 페이지에 application.yml 추가하였습니다!

[ckdals4600]

@minibr PR 제목 수정 및 내용에 대해서도 작동 방식이나 작업 내용에 대해 자세히 부탁드립니다!

[ckdals4600]

노션 logging 페이지에 application.yml 추가하였습니다!

해당 문서를 확인할 수 없는데 혹시 노션 링크 주실 수 있으실까요 ?

[minibr]

노션 logging 페이지에 application.yml 추가하였습니다!

해당 문서를 확인할 수 없는데 혹시 노션 링크 주실 수 있으실까요 ?

제가 잘못 기재했네요. "구현된 CloudWatch 로깅 시스템의 설정 방법을 노션에 정리해두었습니다"로 정정합니다.

[minibr]

@minibr PR 제목 수정 및 내용에 대해서도 작동 방식이나 작업 내용에 대해 자세히 부탁드립니다!

리뷰 요청에 따라 PR 설명을 이해하기 쉽게 수정했습니다.

[ckdals4600]

제가 잘못 기재했네요. "구현된 CloudWatch 로깅 시스템의 설정 방법을 노션에 정리해두었습니다"로 정정합니다.

제가 확인한 바로는, 현재 해당 설정은 환경 변수(Environment Variable)에 값을 설정한 후, 이를 통해 직접 값을 주입하는 방식으로 구성되어 있는 것 같습니다.

하지만 유지보수 측면이나 변수 값 관리(특히 개발/운영 환경 분리 등)를 고려했을 때는
application.yml에 변수 값을 명시적으로 지정하고 주입하는 방식이 더 명확하고 확장성 있는 구조라고 생각됩니다.

해당 방식으로 변경하는 것에 대해 어떻게 생각하시나요?

[minibr]

제가 잘못 기재했네요. "구현된 CloudWatch 로깅 시스템의 설정 방법을 노션에 정리해두었습니다"로 정정합니다.

제가 확인한 바로는, 현재 해당 설정은 환경 변수(Environment Variable)에 값을 설정한 후, 이를 통해 직접 값을 주입하는 방식으로 구성되어 있는 것 같습니다.

하지만 유지보수 측면이나 변수 값 관리(특히 개발/운영 환경 분리 등)를 고려했을 때는 application.yml에 변수 값을 명시적으로 지정하고 주입하는 방식이 더 명확하고 확장성 있는 구조라고 생각됩니다.

해당 방식으로 변경하는 것에 대해 어떻게 생각하시나요?

처음에는 application.yml에서 값을 관리해 제가 혼동했던 것 같습니다. 다만 보안적인 측면에서는 민감한 값을 yml에 직접 넣는 것보다 환경 변수로 코드와 설정을 분리해 관리하는 것이 더 적합하다고 생각해 변경하게 되었습니다. 특히 CloudWatch 연동용 AWS 키는 민감한 값이라 이 방식이 더 안전하다고 판단했는데, 명확다라는 의견은 저도 동의합니다. 혹시 이 부분에 대해 다른 의견이 있으실까요?

[ckdals4600]

제가 확인한 바로는, 현재 해당 설정은 환경 변수(Environment Variable)에 값을 설정한 후, 이를 통해 직접 값을 주입하는 방식으로 구성되어 있는 것 같습니다.
하지만 유지보수 측면이나 변수 값 관리(특히 개발/운영 환경 분리 등)를 고려했을 때는 application.yml에 변수 값을 명시적으로 지정하고 주입하는 방식이 더 명확하고 확장성 있는 구조라고 생각됩니다.
해당 방식으로 변경하는 것에 대해 어떻게 생각하시나요?

처음에는 application.yml에서 값을 관리해 제가 혼동했던 것 같습니다. 다만 보안적인 측면에서는 민감한 값을 yml에 직접 넣는 것보다 환경 변수로 코드와 설정을 분리해 관리하는 것이 더 적합하다고 생각해 변경하게 되었습니다. 특히 CloudWatch 연동용 AWS 키는 민감한 값이라 이 방식이 더 안전하다고 판단했는데, 명확다라는 의견은 저도 동의합니다. 혹시 이 부분에 대해 다른 의견이 있으실까요?

보안적인 측면에서 민감한 값을 application.yml에 직접 기입하기보다는 환경 변수로 분리 관리하는 것이 바람직하다는 점에 저도 전적으로 동의합니다.

다만, 현재 저희 프로젝트의 경우:

• application.yml은 외부에 직접 노출되지 않고,
• GitHub에서도 보안 설정(GitHub Security Key 등)을 통해 관리되며,
• 실제 배포 과정에서도 해당 설정 파일이 외부에 드러나는 구조가 아닌 점

을 고려했을 때, 보안적으로도 application.yml을 통한 관리가 큰 문제가 되지는 않을 것이라고 생각합니다.

따라서 관리 편의성과 명확성을 고려해 해당 값을 application.yml에 지정해두는 방안도 괜찮을 것 같습니다

[ckdals4600]

springProfile 이름만으로도 역할이 명확해서, 이 부분 주석은 제거하셔도 무방할 것 같습니다! 🙌

[minibr]

수정했습니다!

[ckdals4600]

로그 패턴을 어떤 식으로 구성하셨는지에 대한 간단한 부가 설명이 함께 추가되면 더 좋을 것 같습니다.
특히 하이라이트나 클래스/메서드/라인 정보 등 각 항목의 구성이 어떤 목적이나 기준으로 설정되었는지 알 수 있다면,
추후 로그를 해석하거나 커스터마이징할 때도 도움이 될 것 같습니다!

[minibr]

로그 패턴을 어떤 식으로 구성하셨는지에 대한 간단한 부가 설명이 함께 추가되면 더 좋을 것 같습니다. 특히 하이라이트나 클래스/메서드/라인 정보 등 각 항목의 구성이 어떤 목적이나 기준으로 설정되었는지 알 수 있다면, 추후 로그를 해석하거나 커스터마이징할 때도 도움이 될 것 같습니다!

여기서의 로그 패턴은 CloudWatch에서 로그 검색과 분석이 편하도록 대괄호로 구분된 구조화된 형태로 설정한 것 입니다. 하이라이트는 개발 시 로그 레벨 구분을 위해, 클래스/메서드/라인 정보는 문제 발생 시 코드 위치를 쉽게 파악하기 위해 포함됩니다.