이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 때 서비스 장애가 났을 때 원인 파악이 너무 오래 걸리는 문제를 봤습니다. 로그가 남아 있긴 했지만 구조화가 안 되어 있어 특정 요청 흐름을 추적하려면 grep을 여러 번 해야 했습니다.
이후 사이드 프로젝트에서 처음부터 요청마다 `trace_id`를 부여하고 로그에 포함시키는 방식을 써봤습니다. 같은 trace_id로 검색하면 한 요청의 전체 흐름이 한눈에 보였습니다. 장애 원인을 30분 만에 찾던 것이 3분으로 줄었습니다.
알람은 처음에 에러 로그 개수로만 트리거했다가 정상 배포 때도 알람이 울려 피로도가 높아졌습니다. 이후 에러율(전체 대비 비율)로 기준을 바꾸니 오탐이 줄었습니다. 운영하기 쉬운 구조의 핵심은 추적 가능성과 의미 있는 알람이라는 걸 그 경험에서 배웠습니다.
팀 프로젝트에서 DB 접속 정보가 설정 파일에 하드코딩돼 있어서, 스테이징과 프로덕션 설정을 실수로 바꿔서 배포한 사고가 있었습니다. 스테이징 DB 주소가 프로덕션 서버에 들어가 데이터가 꼬였습니다.
환경 변수로 설정을 분리하고, 환경마다 다른 설정 파일이 자동으로 로드되도록 바꿨습니다. 배포 파이프라인에서도 환경 변수 주입 단계를 명시적으로 분리했습니다. 실수로 잘못된 설정을 넣는 것이 불가능한 구조를 만드는 것이 목표였습니다.
그 경험 이후로 운영하기 쉬운 구조는 실수가 일어나기 어려운 구조라는 기준이 생겼습니다. 규칙보다 구조로 실수를 방지하는 방향을 먼저 고민하게 됐습니다.
사이드 프로젝트에서 새 버전을 배포했는데 특정 API만 500 에러가 나기 시작했습니다. 처음엔 알아채는 데 10분이 걸렸고, 그 사이에 오류 응답이 쌓였습니다.
이후 헬스체크 엔드포인트를 만들고 배포 후 자동으로 호출해 정상 여부를 확인하는 단계를 파이프라인에 넣었습니다. 이상이 감지되면 자동으로 이전 버전으로 롤백하도록 했습니다. 처음 배포 때 헬스체크 응답이 200을 반환해도 실제 DB 연결이 안 된 경우가 있어서, 헬스체크 로직에 DB 쿼리 한 건을 포함시켰습니다.
배포 직후 5분이 장애 위험이 가장 높은 구간이라는 걸 그때 배웠습니다. 빠른 감지와 자동 롤백이 야간 배포를 두렵지 않게 만든다는 것이 지금도 제 배포 설계 기준입니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.