이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
낯선 코드베이스를 분석할 때 가장 먼저 찾는 것은 진입점입니다. 웹 서버라면 라우터, CLI라면 main 함수에서 시작해 데이터가 어떻게 흐르는지를 위에서 아래로 따라가면 전체 구조가 점차 파악됩니다.
의존 관계 파악도 중요합니다. 어떤 모듈이 어디에 의존하는지를 파악하면 변경 시 영향 범위를 예측할 수 있고, 테스트가 어려운 이유도 보입니다. import 경로나 의존성 그래프 도구를 활용해 순환 의존이나 과도한 결합이 있는 지점을 먼저 확인했습니다.
분석은 작은 단위로 직접 실행해보는 것으로 검증했습니다. 이해한 흐름대로 실행될 것이라고 가정하고 테스트를 돌려보면, 예상과 다른 동작이 나올 때 이해가 틀린 지점을 빠르게 찾을 수 있었습니다.
대규모 코드베이스를 처음 맡았을 때 어디서 시작해야 할지 막막했던 경험이 있었습니다. 파일이 수백 개인데 어떤 것이 핵심인지 알 수가 없었습니다.
ctags와 IDE의 "Go to Definition" 기능을 적극 활용해, 특정 함수를 누가 호출하는지 참조 역방향 추적으로 따라가면서 핵심 흐름 경로를 조금씩 파악했습니다. grep -r로 특정 상수나 변수가 어디서 쓰이는지 전체 검색하는 것도 패턴이 됐습니다.
한계도 있었습니다. 동적 호출(콜백·이벤트 기반)은 정적 추적으로 안 잡혔고, 런타임에 직접 실행해야만 흐름이 보이는 자리가 꽤 있었습니다. 그 부분은 로그를 찍거나 디버거를 붙이면서 따로 파악했습니다.
이 경험으로 정적 분석과 동적 실행을 번갈아 써야 코드 전체 흐름이 잡힌다는 걸 배웠습니다.
레거시 코드베이스에 들어갔을 때 문서가 없고 테스트도 거의 없는 상황이었습니다. 함수 이름과 변수명만으로 의도를 파악해야 했는데, 이름이 실제 동작과 다른 경우도 있었습니다.
먼저 핵심 함수에 입출력 예시를 직접 만들어 테스트 케이스로 고정했습니다. 코드를 바꿔도 이 테스트가 통과하면 동작이 유지된다는 안전망이 생기니 분석과 수정을 동시에 진행할 수 있었습니다. 어떤 함수를 건드리면 어떤 테스트가 깨지는지 보면서 의존 범위도 자연스럽게 파악됐습니다.
이 경험으로 대규모 코드를 분석할 때 이해가 된 부분부터 테스트로 고정하면 탐색과 안전이 동시에 된다는 걸 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 올거나이즈 풀스택 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.