이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
기술 부채와 혁신 사이의 균형 문제는 팀 프로젝트에서 처음으로 직접 경험했습니다. 기능 개발 속도에 집중하다 보니 테스트 코드와 문서가 쌓이지 않은 구간이 생겼고, 이후 새 기능을 추가할 때마다 예상치 못한 버그가 나오는 악순환이 시작됐습니다. 부채 목록을 가시화하는 것부터 시작했는데, 어디에 얼마나 부채가 있는지 팀 전체가 공유하지 않으면 우선순위를 잡기 어렵기 때문입니다.
스프린트마다 부채 해소 시간을 일정 비율로 배정하는 방식을 도입했고, 새 기능과 부채 해소를 번갈아 배치하니 전체적인 개발 속도가 안정됐습니다. 완전히 깨끗한 코드베이스를 목표로 삼으면 오히려 아무것도 진행이 안 되는 경우가 생깁니다. 트레이드오프는 당장 감수할 수 있는 부채인지를 팀이 명시적으로 합의하는 것이 핵심이라고 생각합니다. 기술 부채는 없애는 것이 아니라 관리하는 것이라는 결을 이 경험에서 얻었습니다.
기술 부채를 관리할 때 어디서부터 시작해야 할지 처음에는 막막했습니다. 부채가 여러 곳에 분산되어 있어서 모두 고치려 하면 끝이 없는 결이었습니다. git log로 어떤 파일이 가장 자주 변경되는지를 확인했더니 특정 모듈 2개가 전체 커밋의 40%를 차지하고 있었습니다. 그 모듈에 버그도 집중돼 있었고, 변경할 때마다 예상치 못한 영향이 생기는 것도 그 모듈이었습니다. 이 Hot Spot에 집중해서 먼저 테스트 코드를 보강하고 구조를 정리했더니, 전체 버그 발생 빈도가 눈에 띄게 줄었습니다. 기술 부채는 균등하게 쌓이지 않는다는 것을 이 경험에서 배웠습니다. 가장 자주 건드리는 곳이 가장 많은 비용을 만드는 결이어서, Hot Spot 파악이 부채 관리의 첫 번째 결이라고 생각합니다.
팀 프로젝트에서 기존 API를 새 아키텍처로 전환하면서 모든 것을 한 번에 바꾸려다 실패한 경험이 있습니다. 전환 도중 기존 기능이 깨지고 롤백도 쉽지 않은 상황이 생겼습니다. 이후에는 기존 시스템을 그대로 두고 새 아키텍처를 나란히 구축한 뒤 엔드포인트를 하나씩 전환하는 방식으로 바꿨습니다. 새 엔드포인트가 안정화되면 기존 것을 비활성화하는 순서로 진행했고, 이 방식이 Strangler Fig 패턴과 같다는 것을 나중에 알았습니다.
전환 중에도 서비스가 정상 동작했고, 문제가 생겨도 기존 경로로 빠르게 복귀할 수 있었습니다. 혁신과 안정성이 상충하는 것이 아니라 전환 방식을 얼마나 점진적으로 설계하느냐에 달린 결이라는 것을 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 와이즐리컴퍼니 솔루션 아키텍트 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.