어느 스타트업의 잘못된 인식

링크드인에서 어느 스타트업 C레벨의 글을 보고 놀라웁기도 하고 해서 반론을 여기에 적어 본다.

이 분은 TDD를 제목에 적어 놓고 뒤에는 테스트를 적고 있다. TDD의 개념을 잘 모르는 것이다.

테스트의 개념도 잘 모르는 것 같다. 테스트는 입력과 출력 관계를 확인하는 것이다. 구현 코드가 만일 ‘철수를 학교에 보낸다’ 라면 철수가 학교에 가기까지의 다양한 시나리오를 생각해야 할 것이다. 단순히 특정 시간 뒤에 어떤 좌표에 도달해야 한다는 것… 입력과 출력의 관계는 보이지 않는다.

내가 바이브코딩을 한다면 “철수를 학교에 보내야 돼. 버스를 타고 가는 경우와 걸어서 가능 경우, 자전거를 타고 가는 경우에(입력) 언제쯤 출발해야 하는지(결과) 계산하는 코드를 만들거야. 이 시나리오에 대해 먼저 테스트케이스를 만들어 줘”

라고 LLM에 시킬 것이다.

LLM은 테스트 케이스를 만들 건데 결과물은 비개발자도 코드를 보면 알 정도로 잘 짜준다. 코드를 보고 테스트 케이스를 이해했으면 이를 기반으로 실행 코드를 만들어 달라고 LLM에 다시 부탁한다.

Codex기준으로 테스트 케이스 생성은 촘하게 만들어 주는 것 같다. 만일 테스트 케이스에 구멍이 있다면 LLM에 제시한 요구사항이 구체적이지 못한지를 봐야 한다.

위 글의 댓글들을 보니 생각보다 호응을 하는 분들이 많다. 테스트 케이스 짤 시간에 코드를 짜고 오류가 나면 수정하는게 더 낫다는 것이다. 최근에는 LLM의 등장으로 테스트 케이스 구성하기도 정말 쉬워졌다. 이제 TDD하자. 먼저 테스트 케이스를 만들어 놓으면 LLM의 헛발질이 많이 줄어들 것이다.