이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 설계 결정 이유가 코드에 남지 않아 나중에 코드를 보는 팀원이 왜 이렇게 짰는지 물어보는 일이 반복됐습니다. 아무도 먼저 나서지 않아서 제가 먼저 ADR(아키텍처 결정 기록) 1번을 직접 작성해 공유했습니다.
처음엔 귀찮아하는 반응도 있었는데, 실제로 3주 후 비슷한 의사결정 상황에서 ADR을 참고해 논의 시간이 절반으로 줄었습니다. 그때부터 팀원들이 자연스럽게 ADR을 써주기 시작했습니다.
아무도 하지 않는 일을 먼저 해보이는 것이 설득보다 강하다는 걸 그 경험에서 배웠습니다. 팀 문화는 규칙보다 본보기가 먼저 움직여야 바뀐다는 것이 지금도 제 협업 방식입니다.
인턴 때 3년 된 인증 모듈이 새 기능 추가 때마다 문제를 일으켰지만, 팀 모두가 건드리기 무서워 피하고 있었습니다. 제가 먼저 리팩터 범위와 위험도를 정리한 1페이지짜리 제안서를 작성해 팀 리뷰를 요청했습니다.
처음엔 공수가 크다고 반려됐지만, 가장 리스크가 낮은 부분 하나만 먼저 해도 되냐고 다시 제안했습니다. 허락을 받고 인증 토큰 파싱 로직만 분리해 테스트를 붙이는 작업을 2일 안에 완료했습니다. 이후 그 패턴을 참고해 팀원이 다른 부분도 정리했습니다.
주도적으로 일을 개척한다는 게 거창한 것이 아니라 작은 단위로 먼저 해보이는 것이라는 걸 그때 배웠습니다. 팀이 허락해 줄 수 있는 크기로 쪼개서 제안하는 것이 핵심이었습니다.
팀 프로젝트에서 프론트엔드 팀과 백엔드 팀이 API 명세를 슬랙으로 공유하다 보니 최신 버전을 찾기 어렵고, 변경이 생겨도 알림이 안 가는 상황이 반복됐습니다. 두 팀 모두 불편함을 느끼고 있었지만 아무도 먼저 해결하지 않았습니다.
제가 Swagger 문서를 배포 파이프라인에 연결해 코드 변경 시 자동으로 최신화되도록 설정했습니다. 프론트 팀에 링크 하나를 보내면서 이걸 기준으로 쓰자고 했습니다. 처음엔 '이게 항상 최신 버전이냐'는 의심이 있었는데, 2주 동안 실제로 항상 최신 상태를 유지하는 걸 보여주니 자연스럽게 채택됐습니다.
신뢰는 말이 아니라 실제로 작동하는 것을 보여주면서 만들어진다는 걸 배웠습니다. 주도적으로 일을 개척할 때 중요한 건 설득보다 먼저 돌아가는 것을 만드는 것이라는 기준이 그때 생겼습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 유진그룹 SW·IT 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.