이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
앱을 처음 출시했을 때는 기능 완성도보다 빠른 사용자 피드백 수집을 우선했습니다. MVP 범위를 핵심 3개 기능으로 좁히고 2주 만에 첫 배포를 냈고, 이후 사용자 인터뷰와 Amplitude 이벤트 데이터를 보며 다음 스프린트 우선순위를 조율했습니다.
출시 후 유지보수 단계에서 가장 신경 쓴 것은 배포 자동화였습니다. 초기에는 수동 배포였는데 릴리즈마다 실수가 생겼고, GitHub Actions를 연결해 테스트 통과 후 자동 빌드·배포되도록 파이프라인을 구성했습니다.
버그 추적은 Sentry로 런타임 오류를 수집했고, 우선순위를 영향 사용자 수 기준으로 정렬해 처리했습니다. 단발 오류보다 반복 발생하는 패턴에 집중하니 실제 사용자 경험 개선이 더 빨리 이뤄졌습니다.
앱 출시 후 유지보수 단계에서 가장 예상 밖의 배움은 기능을 삭제하는 것이 추가보다 어렵다는 것이었습니다. 초기에 실험적으로 넣은 기능들이 일부 사용자에게 의존하게 되면 내리기가 어려워졌습니다. 피처 플래그 없이 바로 배포했던 기능을 제거하려고 하니 어떤 사용자가 얼마나 쓰는지 데이터가 없어서 결정이 어려웠습니다. 이후에는 신규 기능은 사용량 이벤트를 먼저 심고 일정 기간 데이터를 모은 뒤 유지 여부를 결정하는 방식으로 바꿨습니다. 유지보수에서 가장 오래 남은 교훈은 출시가 끝이 아니라 시작이라는 것입니다.
운영 중인 코드는 살아있는 결이어서, 작은 변경이 예상치 못한 곳에 영향을 주는 경험이 반복됐습니다. 앱의 생애주기를 처음부터 끝까지 겪어보니 설계 결정이 유지보수 비용을 얼마나 결정하는지를 실감했습니다.
앱 유지보수 단계에서 어떤 기능을 먼저 개선할지 판단하는 기준이 처음에는 불명확했습니다. 개발자 감각으로 중요하다고 생각한 기능과 사용자가 실제로 많이 쓰는 기능이 달랐습니다. Amplitude로 이벤트를 추적했더니 출시 전에 가장 공들인 기능의 이용률이 낮고, 비교적 단순하게 만든 기능이 핵심 경로로 쓰이고 있다는 것을 알게 됐습니다. 이 데이터를 기반으로 낮은 이용률 기능보다 핵심 경로 기능의 성능을 먼저 개선했고, 사용자 잔존율이 올라갔습니다. 유지보수는 코드 관리가 아니라 사용자 행동 이해에서 시작하는 결이라는 것을 이 경험에서 배웠습니다.
데이터 없이 우선순위를 정하면 열심히 했지만 의미 없는 작업에 시간을 쓰는 결이 생깁니다. 지금도 새 기능을 만들 때 어떤 지표로 성공을 정의할지를 먼저 설정하는 습관이 남았습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 세나클소프트 SW·IT 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.