이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인하우스 도구 유지보수에서 가장 중요하게 생각하는 것은 왜 이렇게 만들었는지의 맥락을 보존하는 것입니다. 팀에서 직접 만든 도구는 외부 문서가 없어, 만든 사람이 떠나면 코드를 이해하기 어려워지는 경우가 많습니다. 인턴 기간에 팀 내부 스크립트를 인수받았는데, 어떤 상황에서 이 로직이 필요한지가 코드에 전혀 남아있지 않아 수정 범위를 판단하기 어려웠습니다.
왜 이 선택을 했는지를 별도 문서로 남기는 방식이 효과적이라는 것을 그 경험에서 배웠습니다. 사용자 피드백 채널을 만드는 것도 중요한데, 도구를 실제로 쓰는 사람이 불편하다고 느끼는 것이 유지보수 우선순위의 기준이 됩니다. 기능 추가보다 기존 기능이 계속 동작하는지 확인하는 회귀 테스트 루틴을 먼저 갖추는 것이 유지보수 비용을 줄였습니다. 인하우스툴 유지보수는 맥락을 보존해야 다음 사람이 올바르게 고칠 수 있다는 결을 배웠습니다.
인하우스 도구 유지보수에서 두 번째로 중요하게 생각하는 것은 변경이 기존 기능을 망가뜨리지 않는다는 확신을 주는 구조입니다. 외부 라이브러리와 달리 인하우스 도구는 테스트가 없는 경우가 많아, 작은 수정이 예상치 못한 곳에서 문제를 일으키는 경험을 했습니다. 팀 내 스크립트를 수정하면서 기존 동작을 보장하는 회귀 테스트를 먼저 작성하고 나서야 안심하고 리팩터링할 수 있었습니다. 테스트가 없는 코드를 넘겨받았을 때는 수정 전 현재 동작을 기록하는 스냅샷 테스트부터 추가하는 방식을 택했습니다.
리팩터링 후 테스트가 통과하면 기존 사용자 경험은 그대로 유지된다는 신뢰가 생겼고, 이후 수정이 훨씬 빠르게 진행됐습니다. 인하우스 도구 유지보수는 테스트 없이 수정하는 것이 더 빠른 게 아니라, 테스트를 먼저 갖춰야 이후 수정이 빨라진다는 것을 직접 경험으로 확인한 자리였습니다.
인하우스 도구 유지보수를 담당하면서 내가 추가한 맥락 문서도 결국 낡아간다는 한계를 인정하게 됐습니다. 처음에는 코드 변경마다 이유를 꼼꼼히 기록했는데, 시간이 지나자 문서가 코드와 어긋나기 시작했습니다. 코드는 바뀌었는데 문서가 따라오지 못하는 상황이 생기면서, 오래된 문서가 오히려 혼란을 줄 수 있다는 것을 경험했습니다. 결국 문서보다 코드 자체를 읽기 쉽게 만드는 쪽에 더 집중하는 방향으로 바꿨습니다. 함수 이름과 변수 이름이 의도를 담고 있으면 코드가 자체 문서 역할을 했고, 별도 문서가 필요한 상황은 줄었습니다.
유지보수 중 가장 어려운 것은 어디까지 문서화할지 판단하는 것이라는 것을 이때 배웠습니다. 지금은 왜 이렇게 했는가가 코드에서 드러나지 않는 결정만 기록하고, 자명한 내용은 코드 가독성으로 대신하는 방식을 택하고 있습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 111퍼센트 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.