문제 개요
오류 상황과 영향 범위 (예: 특정 코드 실행 시 발생, 특정 라이브러리 버전 호환 문제 등) 발생 배경 (예: 코드 테스트 중, 배포 중 문제 발견 등)
- 문제 배경
- 도플러 인증 방식에 대한 혼란
- 발생 배경
- 도플러에 대한 지식 부족
- 특정 상황에 대한 도플러 관련 자료가 적음
- 도커 환경에서 도플러를 이용한 인증 방식이 따로 있었으나 인지하지 못 함
- 문서에 관련 내용이 있었지만 이미지 빌드 시에 처리해야 하는 단계가 필요하다고 생각하지 못 해 넘겨버림
- 문서에서 안내한 방식이 제대로 작동하지 않음.
- 초기에 챗GPT 및 제미나이에 의존했으나 모두 잘못된 방식으로 안내함(인공지능 너무 믿지 마세요)
- 여러 시도 중 올바른 방식으로 시도했음에도 도커 생성 시 다른 문제로 실패해 올바른 방식임을 인지하지 못 함
오류 메시지 및 원인 분석
오류 코드, 오류 메시지 포함 HTTP 상태 코드, 애플리케이션 로그, 서버 로그 등 구체적인 오류 정보 정리 및 로그 메시지를 통한 분석 제공 문제 발생 원인에 대한 심층 분석
- 도플러를 제대로 적용하지 못 했을 때 오류는 심플했다.
- 백엔드 서버 컨테이너가 꺼져서 사라짐!
- 처음에는 배포 자체가 실패한 줄 알아 배포 관련 코드만 뒤지고 있었다.
- 그러나 무적의 docker ps -a와 로그를 이용해 컨테이너가 실행됐었다는 사실을 확인.
- (이 단계까지 많은 눈물과 좌절이 있었다)
- 로그를 까보면 환경변수가 전혀 들어가지 않았다는 메시지만 있었다.
- 백엔드 서버 컨테이너가 꺼져서 사라짐!
해결 및 고민 과정
처음 문제를 접했을 때 고려했던 대안들과 선택하지 않은 이유 실험적으로 적용한 방법이 실패한 사례와 그 이유 여러 해결책 중 최적의 방안을 선택한 과정
- 도플러를 적용하는 경우의 수
- 배포 환경에만 도플러 cli를 설치 및 로그인
- 자동배포 상황에서 가능하지 않은 방법이었다.
- 배포 환경에만 도플러 cli를 설치 및 액세스 토큰 사용
- 인공지능들이 제안한 방법으로, 컨테이너 생성 시 자동으로 주입된다고 했다(안 됐다)
- 백엔드 컨테이너 내부에 도플러 cli를 설치
- 액세스 토큰을 배포 환경의 환경 변수에 입력하는 방법
- 적용되지 않았다.
- 백엔드 컨테이너 생성시 -e 옵션으로 환경변수를 주입
- 이 방법은 결과적으로 방향은 맞았다. 그러나 애초에 빌드 과정에서 따로 처리가 필요했기에 실패했다.
- 액세스 토큰을 배포 환경의 환경 변수에 입력하는 방법
- 이외에 공식 도플러 컨테이너를 받아서 하는 방법도 있었으나 다행히 해결되어 거기까지 가지는 않았다.
- 배포 환경에만 도플러 cli를 설치 및 로그인
최종 해결책 및 구현
문제 해결을 위한 단계별 조치 방법과 코드 예시 (예: 특정 애노테이션 추가, 라이브러리 버전 조정, 설정 변경 등) 참고 자료 (관련 공식 문서, 개발자 커뮤니티 게시물 등)
- 결과만 말하자면 해결책은 Dockerfile에 있었다.
- Dockerfile로 빌드 시에 Doppler Cli 설치, 앱 실행 시 ENTRYPOINT를 이용해 도플러로 감싸 실행되게 하기
# Doppler CLI 설치 RUN (curl -Ls --tlsv1.2 --proto "=https" --retry 3 <https://cli.doppler.com/install.sh> || wget -t 3 -qO- <https://cli.doppler.com/install.sh>) | sh
- 그리고 위에 적은 대로 백엔드 서버 컨테이너 생성시 -e 옵션으로 환경변수를 직접 주입
ENTRYPOINT ["doppler", "run", "--"]
- Dockerfile로 빌드 시 빌드 환경 차이 때문에 Dopller Cli 설치가 잘 안 되었다.
- 그 때 당시에는 이게 맞는 방향인가 확신이 없었다.
- 하지만 됐다.
결과 및 성능 분석
개선 후 응답 속도, DB 부하 감소 수치 등 구체적인 데이터 포함 문제 해결 전/후 성능 비교 그래프나 로그 분석 내용 포함 이슈 트래킹 및 자동화 방안 추가 (내부 개발자가 반복적인 문제 해결을 효율적으로 관리할 수 있도록 가이드 제공)
- Doppler 환경변수가 주입됐다!
추가 개선점
유사한 문제를 방지하기 위한 주의할 점 (예: 애노테이션 명시 여부, 프레임워크 업데이트 주기 확인 등) 문제 해결 과정에서 배운 점 및 중요한 교훈 공유 보안 고려 사항 추가 (해결 과정에서 발생할 수 있는 보안 리스크 및 예방 조치 포함)
- 문제를 바라보는 시야를 늘려야 할 것 같다.
- 그래서 서버가 꺼진게(당시에는 배포가 안 된 줄 알았다) 배포 문제라 생각해 시간낭비를 많이 했다.
- 환경변수 주입 문제임을 인지한 후에도 배포시에 ENTRYPOINT 설정까진 생각이 미치지 않았다.
- 문서는 꼭 봐야 한다(그렇지만 좀 더 자세히 써 줘도 좋다고 생각한다).
- 당연한 말이지만 당연하기에 다시 강조해도 나쁘지 않다.
- 문서를 훑어보고 이건 내가 하려는게 아니다 단정해서 넘어가버렸는데 바로 그걸 했어야 했다.
- 역시 쓸려면 문서정도는 제대로 읽어야 하는거다 싶었다.
- 인공지능이 당당히 말했다고 사실인건 아니다.
- 이래서 그래도 개발자는 필요하다는 건가 싶기도 하다
'kkokkio - 프로젝트 > 트러블슈팅' 카테고리의 다른 글
JWT는 강제로 만료할 수 없는데 우리는 어떻게 블랙리스트를 관리하는가 (0) | 2025.06.16 |
---|---|
accessToken의 만료 여부를 어떻게 확인 할 수 있을까 (0) | 2025.06.16 |
SpringDocs에서 SwaggerConfig보다 yaml이 우선되는가? (0) | 2025.06.02 |
테스트의 코드 커버리지 리포트(with JaCoCo) (1) | 2025.06.02 |
prompt 시행착오 - 말 안 듣는 인공지능 요약시키기 (0) | 2025.06.02 |