소프트웨어 개발에서 수동 테스트와 자동화 테스트를 통해 변경 사항이 실제로 작동함을 증명하고, 리뷰어에게 부담을 떠넘기지 말아야 한다는 주장.
URL: https://simonwillison.net/2025/Dec/18/code-proven-to-work/
2025년 12월 18일
소프트웨어 개발에서 AI 보조의 가치에 대한 모든 논쟁 속에서, 내가 계속 보게 되는 우울한 일화가 하나 있다. 어떤 종류의 LLM 도구로 힘을 얻은 주니어 엔지니어가 동료들(혹은 오픈 소스 메인테이너)에게 거대한, 테스트되지 않은 PR을 던져 넣고는 “코드 리뷰” 과정이 나머지를 처리해주길 기대하는 것이다.
이는 무례하고, 다른 사람들의 시간을 낭비하며, 솔직히 말해 소프트웨어 개발자로서의 직무 유기다.
당신의 일은 작동함이 증명된 코드를 전달하는 것이다.
소프트웨어 엔지니어로서 우리는 단지 코드를 찍어내기만 하지 않는다. 사실 요즘은 그게야말로 LLM이 할 일이라고 주장할 수도 있다. 우리는 _작동하는 코드_를 전달해야 하고, 그것이 작동한다는 _증거_도 함께 제공해야 한다. 그렇게 하지 않으면 실제 일을 리뷰어가 떠맡게 된다.
코드 한 조각이 작동함을 증명하는 데는 두 단계가 있다. 둘 다 선택 사항이 아니다.
첫 번째는 수동 테스트다. 당신이 직접 그 코드가 올바르게 동작하는 것을 보지 못했다면, 그 코드는 작동하지 않는 것이다. 만약 실제로 작동하더라도, 솔직히 그건 순전히 운일 뿐이다.
수동 테스트 능력은 반드시 개발해야 하는 진짜 기술이다. 변경 사항을 보여줄 수 있는 초기 상태로 시스템을 만들고, 변경 사항을 실행해보고, 원하는 효과가 났는지 확인하고 입증할 수 있어야 한다.
가능하다면 나는 이런 과정을 터미널 명령의 연속으로 줄이는 것을 좋아한다. 그리고 그 명령들과 출력 결과를 코드 리뷰 코멘트에 그대로 붙여 넣는다. 여기 최근 예시가 있다.
어떤 변경은 시연하기가 더 어렵다. 그래도 시연하는 건 여전히 당신의 일이다! 화면 녹화 영상을 찍어서 PR에 첨부하라. 당신이 만든 변경 사항이 실제로 작동한다는 것을 리뷰어에게 보여줘라.
모든 게 잘 되는 해피 패스를 테스트했다면, 이제 엣지 케이스를 시도해볼 수 있다. 수동 테스트는 기술이고, 무엇이 깨지는지 찾아내는 것은 그 다음 단계의 기술이다. 그리고 그게 시니어 엔지니어를 규정하는 데 도움이 된다.
변경 사항이 작동함을 증명하는 두 번째 단계는 자동화 테스트다. LLM 도구가 있는 지금은 이 작업이 훨씬 쉬워졌으므로, 이 단계를 건너뛸 변명은 전혀 없다.
당신의 기여물은 변경 사항을 해당 변경을 증명하는 자동화 테스트와 함께 묶어야 한다. 그 테스트는 구현을 되돌리면 실패해야 한다.
테스트를 작성하는 과정은 수동 테스트와 닮아 있다. 시스템을 초기의 알려진 상태로 만들고, 변경을 실행하고, 올바르게 동작했는지 단언(assert)한다. 이를 생산적으로 도와주는 테스트 하네스를 제품에 통합하는 것 또한 투자할 가치가 있는 핵심 기술이다.
자동화 테스트가 있으니 수동 테스트는 건너뛰어도 된다고 유혹에 빠지지 마라! 나 자신도 거의 매번 그렇게 했다가 곧바로 후회했다.
2025년 LLM에서 가장 중요한 트렌드는 코딩 에이전트의 폭발적인 성장이다. Claude Code나 Codex CLI 같은 도구는 작업 중인 코드를 실제로 실행해, 제대로 작동하는지 확인하고 문제를 더 반복적으로 개선할 수 있다.
이 도구들을 마스터하려면, 에이전트가 _자신의 변경이 작동함을 증명_하도록 만드는 방법도 배워야 한다.
이는 앞서 설명한 과정과 완전히 같다. 에이전트는 작업하면서 자신의 변경을 수동으로 테스트할 수 있어야 하고, 그 변경이 앞으로도 계속 작동함을 보장하는 자동화 테스트를 만들 수 있어야 한다.
로봇이기 때문에, 자동화 테스트와 수동 테스트는 사실상 같은 것이다.
하지만 체감상 약간 다르긴 하다. CLI 도구를 작업할 때 나는 보통 Claude Code에게 그 도구를 스스로 실행하는 방법을 가르쳐서 일회성 테스트를 할 수 있게 한다. 최종적으로 자동화 테스트는 Click의 CLIRunner 같은 시스템을 사용하더라도 말이다.
CSS 변경을 작업할 때는, 에이전트가 자신이 만든 변경이 원하는 효과를 냈는지 확인해야 할 경우 스크린샷을 찍도록 권하는 편이다.
자동화 테스트에 관한 좋은 소식은, 코딩 에이전트가 테스트를 작성하도록 만드는 데 거의 격려가 필요 없다는 점이다. 프로젝트에 이미 테스트가 있다면, 대부분의 에이전트는 따로 말하지 않아도 테스트 스위트를 확장한다. 또한 기존 테스트에서 패턴을 재사용하므로, 테스트 코드를 잘 정리해두고 마음에 드는 패턴들로 채워두는 것은 에이전트가 당신의 취향에 맞는 테스트 코드를 작성하도록 돕는 훌륭한 방법이다.
테스트 코드에 대한 좋은 취향을 기르는 것 역시 시니어 엔지니어를 구분하는 또 하나의 기술이다.
컴퓨터는 결코 책임을 질 수 없다. 인간인 당신이 루프 안에 들어가 그 일을 해야 한다.
누구나 LLM에 프롬프트를 던져 천 줄짜리 패치를 만들고 코드 리뷰에 올릴 수 있다. 그건 이제 가치가 없다. 가치 있는 것은 _작동함이 증명된 코드_를 기여하는 것이다.
다음에 PR을 올릴 때는, 그것이 의도대로 작동한다는 증거를 반드시 포함했는지 확인하라.
