이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 프로젝트 배포 직후에 특정 기능이 로컬에서는 되는데 운영에서만 안 되는 현상이 있었습니다. 로그를 보니 API URL이 로컬 주소로 박혀 있었습니다. 환경 변수 파일을 배포에 포함시키지 않은 것이 원인이었습니다. 그 일이 두 번째 발생하였기에 멘토에게 배포 체크리스트를 만들겠다고 하였습니다.
배포 전 확인 항목 7개를 정리하여 PR 템플릿에 추가하였고, 이후 같은 실수가 없어졌습니다. 개인적으로도 환경 변수 설정 검증 스크립트를 만들어 배포 전 자동 체크하도록 하였습니다. 버그가 반복될 때 사람의 주의에 기대지 말고 자동화로 막아야 한다는 것을 배웠습니다.
그 과정이 값진 배움이었습니다.
사이드 프로젝트에서 처음엔 스테이징 없이 바로 운영에 배포했어요. 그러다 폰트 파일 하나를 빠트려서 사용자 화면에 글씨가 네모로 보이는 장애가 30분간 있었어요. 그 이후에 GitHub Actions를 써서 main 브랜치에 머지되면 스테이징 서버에 자동 배포하는 파이프라인을 만들었어요. 스테이징에서 확인 후 직접 운영 배포를 승인하는 방식으로 바꿨어요. 설정에 이틀이 걸렸는데 그 이후 운영 장애는 없었어요.
장애가 나고 나서야 환경을 분리하게 된 게 아쉬웠어요. 지금은 새 프로젝트를 시작할 때 스테이징 환경부터 구성하는 습관을 들이고 있어요. 그 과정이 값진 배움이었습니다.
동아리 프로젝트에서 배포할 때마다 GitHub Actions 빌드가 8분씩 걸렸어요. 작은 기능 하나 추가해도 8분을 기다려야 했는데, 배포 중엔 다른 작업을 하지 않게 되더라고요. 로그를 보니 npm install이 매번 처음부터 실행되고 있었어요. 캐시 설정을 추가했더니 의존성이 바뀌지 않으면 캐시를 재사용해서 8분에서 2분으로 줄었어요. 도커 레이어 캐시 설정도 같이 했는데, 레이어 순서를 잘못 배치해서 처음엔 효과가 없었어요.
자주 바뀌는 레이어를 뒤에 두어야 한다는 원칙을 배웠어요. 배포 환경 개선은 직접 로그를 읽고 병목 지점을 찾는 것부터 시작해야 한다고 생각해요.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.