이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 과제로 장바구니 할인 적용 모듈을 TDD로 짜봤습니다. 처음에는 테스트를 먼저 쓰는 것이 느리고 억지스럽게 느껴졌는데, 할인 조건이 10가지를 넘어가면서 의도치 않은 규칙 충돌이 생겼고, 사전에 작성한 테스트가 그 충돌을 즉시 잡아줬습니다. 테스트 없이 짰던 비슷한 모듈과 비교했을 때 버그 수정 횟수가 절반 이하였습니다. 처음 속도가 느렸지만, 요구사항이 중간에 바뀌었을 때 기존 테스트가 회귀를 막아줘서 수정 범위도 예측이 됐고 전체 개발 속도는 오히려 빨랐습니다. 이 경험으로 TDD는 느린 방법이 아니라 변경 비용을 낮추는 방법이라는 것을 직접 체감했습니다.
TDD를 처음 시도했을 때 처음에는 테스트를 먼저 쓰는 것이 익숙하지 않아서 중간에 포기하고 구현을 먼저 한 후에 테스트를 추가하는 방식으로 돌아간 경험이 있습니다. 나중에 테스트를 추가하려고 하니 이미 작성된 코드가 테스트하기 어려운 구조였고, 결과적으로 테스트 커버리지를 높이는 것 자체가 어려운 상황이 됐습니다. TDD의 Red-Green-Refactor 흐름을 작은 단위에서 반복하는 것이 처음에는 속도가 느린 것처럼 느껴지지만, 코드가 자연스럽게 테스트하기 좋은 구조로 만들어진다는 것을 나중에 비교하면서 알게 됐습니다. 이후에 다시 TDD를 적용할 때는 아주 작은 기능 하나에만 먼저 적용해서 흐름을 익히는 방식으로 시작하니 포기하지 않고 습관을 들일 수 있었습니다. TDD는 한 번에 큰 범위에 적용하려 하면 어렵고, 작은 범위에서 반복하면서 몸에 익히는 것이 중요하다는 것을 이 경험에서 배웠습니다.
TDD를 적용하면서 테스트를 먼저 작성하는 것에 집중하다 보니 테스트 코드의 품질을 소홀히 한 경험이 있습니다. 테스트가 많이 쌓이면서 어떤 테스트가 무엇을 검증하는지 이름만으로 파악하기 어렵고, 중복된 설정 코드가 여러 테스트에 흩어져 있어서 수정할 때 여러 곳을 건드려야 하는 상황이 됐습니다. 테스트 코드도 프로덕션 코드와 마찬가지로 가독성과 유지보수성을 고려해서 작성해야 한다는 것을 이 경험에서 알게 됐습니다. 테스트 이름에 어떤 조건에서 어떤 결과를 기대하는지를 명확히 담고, 반복되는 설정을 헬퍼로 분리하는 방식으로 개선하니 테스트를 수정하거나 실패 원인을 파악하는 시간이 줄었습니다. TDD는 테스트를 먼저 쓰는 것이지만, 그 테스트가 나중에도 이해 가능하고 유지보수하기 쉬운 코드여야 장기적으로 효과를 낸다는 것을 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 CJ올리브영 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.