이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 매 스프린트 종료 시 테스트 결과 리포트를 PDF로 정리하여 슬랙에 올리는 작업을 제가 맡게 되었습니다. 처음 두 번은 수동으로 진행했는데, 서식 맞추는 데만 30분 이상 소요되었습니다. 이 과정을 자동화하면 좋겠다고 생각하여 Python으로 결과 json을 파싱해 PDF를 생성하고 슬랙 웹훅으로 전송하는 스크립트를 만들었습니다. 처음에는 인코딩 문제로 한글이 깨졌고, 슬랙 API 레이트 리밋을 몰라서 실패했습니다. 각각 폰트 경로 설정과 재시도 로직으로 이를 해결하였습니다. 이후 스프린트마다 2분 이내 자동 전송이 가능해졌고, 팀원들이 편리함을 느끼게 되었습니다. 소규모 자동화였지만 반복을 구조적으로 없앤다는 감각을 처음 익힌 프로젝트였습니다.
졸업 프로젝트에서 API 서버가 기능이 늘어날수록 라우터 파일 하나가 300줄을 넘어가기 시작했어요. 그냥 두면 나중에 유지보수가 힘들 것 같아서, 기능별로 라우터를 분리하는 리팩터링을 제안했습니다. 팀원 한 명은 "지금 동작하는데 왜 건드려"라고 했는데, 기존 구조에서 새 엔드포인트를 추가하면 어디에 넣어야 할지 매번 논의가 필요했던 문제를 들어 설득했어요. 리팩터링 후엔 각자 담당 라우터 파일만 건드리면 됐고, 병렬 개발이 훨씬 편해졌습니다. 기능이 덜 화려한 작업이라 처음엔 자신 없었는데, 구조가 팀 속도에 영향을 준다는 걸 몸으로 배웠어요. 이 경험 덕분에 작은 단위로 자동화하는 습관이 생겼고, 반복을 줄여서 팀이 더 중요한 일에 집중할 수 있게 하는 게 저한테 맞는 역할이라고 느꼈습니다.
사이드 프로젝트에서 사용자 피드백을 관리하는 구글 시트가 수백 행으로 불어나 필터링이 번거로워졌어요. 처음엔 DB와 대시보드를 만들려고 설계를 시작했는데, 실제로 필요한 게 뭔지 다시 생각해봤어요. 우리가 매주 하는 작업은 유형별로 묶어서 개수를 세는 것 뿐이었어요. 그래서 시트에서 csv를 내려받아 카테고리별 집계 결과를 출력하는 스크립트 20줄을 짰습니다. DB는 만들지 않았어요. 기능이 크게 필요하지 않다고 판단했거든요. 나중에 팀원이 "이걸로 충분했네"라고 해줬을 때 뿌듯했습니다.
과하게 설계하지 않는 것도 구조적 사고의 일부라는 걸 배웠어요. 처음엔 화려한 기능을 만들어야 기여한 것 같아서 이런 작업이 부끄러웠는데, 팀에 실질적인 도움이 됐다는 피드백을 받고 나서 단순하고 정확한 해결책을 찾는 게 더 어렵다는 걸 알게 됐어요.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 Tmap Mobility 인프라/클라우드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.