AI 코딩 에이전트에게는 프롬프트보다 테스트가 더 필요하다

지난 8개월 동안, 저의 소프트웨어 개발 워크플로우는 그 어느 때보다 많이 변화했습니다.

약 25년 동안 소프트웨어를 작성해 온 사람으로서 드리는 말씀입니다. 저는 수많은 프로그래밍 언어, 프레임워크, 아키텍처 트렌드, 빌드 도구, 프론트엔드 혁명, 모바일 플랫폼의 특이점, 그리고 정서적 보상을 요구할 만큼의 JavaScript 생태계 변화를 겪어왔습니다.

한동안 AI 코딩 도구들은 도움이 되었지만, 제한적인 방식으로만 유용했습니다. 작은 작업에는 훌륭했습니다. '이것의 이름을 바꿔줘', '저것을 리팩터링(Refactor)해줘', '헬퍼 함수(Helper function)를 작성해줘', '화난 토스터가 만든 것 같은 이 난해한 에러 메시지를 설명해줘' 같은 작업 말이죠.

하지만 AI로 더 큰 기능을 만드는 것은 어땠을까요? 고통스러웠습니다. 당시의 GPT-4는 로봇이 내 직업을 대신할 것이라는 확신을 주지 못했습니다. 전혀 그렇지 않았습니다.

GPT-5.1과 함께 작업할 때는 여전히 인터넷 전체를 읽었지만 10분마다 노트를 어디에 두었는지 잊어버리는 똑똑한 인턴과 일하는 기분이었습니다. 일단 중요한 정보가 컨텍스트 윈도우(Context window)에서 벗어나면, AI는 우리가 합의했던 내용을 잊어버리고 자신만만하게 엉뚱한 길로 빠져버리곤 했습니다. 2025년 말경, 처음에는 GPT-5.2(그리고 Claude Sonnet 4.5)와 함께, 그리고 이후 GPT-5.3과 함께 훨씬 더 눈에 띄게 AI 코딩은 마침내 저에게 진정으로 생산적인 도구가 되었습니다.

작은 작업들? 탁월합니다.

여러 번의 반복, 수정, 아키텍처 컨텍스트(Architectural context), 그리고 여러 파일에 걸친 의존성(Dependencies)이 포함된 더 긴 작업들? 어느 정도 작동합니다!

그렇기 때문에 저의 역할은 점차 '코드를 타이핑하는 사람'에서 'AI 에이전트가 주방에 불을 내지 않고 안전하게 코드를 타이핑할 수 있는 환경을 설계하는 사람'으로 바뀌어 가고 있습니다.

AI 에이전트는 점점 좋아지고 있지만 — GUI는 여전히 그들에게 늪과 같은 수준이다

현대의 코딩 에이전트들은 이제 매우 특정한 루프(Loop)를 수행하는 데 놀라울 정도로 능숙합니다:

코드 읽기.
코드 변경하기.
명령 실행하기.
무엇이 실패했는지 확인하기.
수정하기.
상황이 덜 끔찍해 보일 때까지 반복하기.

이것은 강력합니다.

하지만 여전히 그들이 어려움을 겪는 영역이 하나 있습니다. 바로 그래픽 사용자 인터페이스 (GUI)입니다.

AI 에이전트들은 UI를 안정적으로 클릭하고, 시각적으로 어떤 일이 일어났는지 이해하며, 그 동작이 올바른지 결정하는 일을 아직 잘 해내지 못합니다. 시도할 수는 있지만, 마치 안개가 낀 욕실 거울을 통해 누군가가 당신의 앱을 테스트하는 것을 지켜보는 것과 같은 느낌을 줄 때가 많습니다.

그래서 저는 워크플로 (workflow)를 변경했습니다.

이제는 가능할 때마다, 새로운 기능들이 먼저 커맨드 라인 (command line)에서 실행될 수 있도록 구축합니다.

작은 기능의 경우, 이것은 유닛 테스트 (unit test)가 될 수 있습니다.

더 큰 기능의 경우, 실제 UI와 독립적으로 새로운 기능을 실행할 수 있는 작은 독립형 클라이언트 (client)나 커맨드 라인 프로그램이 될 수 있습니다.

중요한 부분은 이것입니다: 에이전트에게는 직접 실행할 수 있는 무언가가 필요합니다.

“이 화면을 보고 느낌이 맞는지 말해줘”가 아니라,

npm run test:feature-x

또는:

node scripts/run-new-feature-client.js

이런 식이어야 합니다.

그것이 바로 에이전트가 빛을 발하는 지점입니다. 그들은 명령 (command)을 매우 좋아합니다. 명령은 그들에게 마치 작은 스케이트 날과 같습니다.

나의 현재 워크플로 (Workflow)

제가 현재 사용하는 워크플로는 대략 다음과 같습니다:

마크다운 (Markdown) 파일에 기능을 계획합니다.
테스트 클라이언트, 유닛 테스트, 또는 커맨드 라인 진입점 (entry point)을 생성합니다.
의미 있는 테스트 케이스 (test cases)를 정의합니다.
에이전트가 기능을 구현하도록 합니다.
에이전트가 테스트를 반복해서 실행하도록 합니다.
결과를 주의 깊게 검토합니다. 에이전트는 영리하고 짓궂은 작은 그렘린 (gremlins) 같기 때문입니다.

마크다운 계획 단계는 중요합니다. 이는 에이전트가 집 아래에 터널을 파기 시작하기 전에 명확한 지도를 제공합니다.

커맨드 라인 테스트 클라이언트도 똑같이 중요합니다. 이는 에이전트에게 실행 가능한 피드백 루프 (feedback loop)를 제공합니다.

그리고 테스트 케이스는 이 모든 것 중 가장 중요한 부분입니다.

가장 가치 있는 인간의 작업: 실제로 무언가를 테스트하는 테스트 작성하기

제가 아주 빠르게 배운 한 가지가 있습니다:

만약 당신이 AI 에이전트에게 “모든 테스트를 통과시켜줘”라고 말한다면, 에이전트는 그렇게 할 것입니다.

때로는 아주 우아하게 말이죠.

때로는 아주 공격적으로, 수단과 방법을 가리지 않고, 테스트를 통과시키기 위해 생각할 수 있는 모든 소프트웨어 엔지니어링 범죄를 저지르기도 합니다. 예를 들어, 별로 테스트할 내용이 없는 테스트를 만들거나, 실제 동작이 아닌 정확히 그 테스트 케이스만 처리하도록 구현(Implementation)을 수정합니다. 에러를 무시하기 위해 try/catch 블록을 사용하기도 하죠.

이는 매우 특정한 종류의 코드 스멜 (Code Smell)로 이어집니다. 코드는 더 길어지고, 더 구체적이며, 더 연극적으로 변합니다. 갑자기 당신의 구현에는 테스트 스위트 (Test Suite)가 우연히 언급한 모든 엣지 케이스 (Edge Case)에 대한 특수 처리가 포함됩니다.

그렇기 때문에 테스트 정의 (Test Definition)는 제가 여전히 가장 주의 깊게 수동으로 공을 들이는 부분입니다.

핵심 질문은 다음과 같습니다:

이 테스트가 실제 사용 사례 (Use Case)를 나타내는가?
실제 회귀 (Regression)를 잡아낼 수 있는가?
너무 좁은 범위는 아닌가?
의도치 않게 하드코딩된 동작을 조장하고 있지는 않은가?
구현이 일반화 (Generalize)될 여지가 있는가?

테스트가 처음부터 완벽할 필요는 없습니다. 테스트는 진화할 수 있습니다. 하지만 첫 번째 중요한 테스트 케이스들은 뼈대가 있어야 합니다.

TDD는 이미 유용했습니다. 이제는 에이전트의 연료입니다.

구현 전에 테스트를 작성하는 것은 분명 새로운 것이 아닙니다. 그것이 바로 테스트 주도 개발 (TDD, Test-Driven Development)입니다.

하지만 AI 에이전트는 TDD에 새로운 종류의 관련성을 부여합니다.

전통적인 TDD에서 테스트는 개발자가 목표를 명확히 하고 회귀를 방지하도록 돕습니다.

AI 에이전트와 함께라면, 테스트는 그 이상의 역할을 합니다. 에이전트가 독립적으로 작동할 수 있는 루프 (Loop)를 만들어 줍니다.

에이전트는 테스트를 실행하고, 실패를 조사하고, 구현을 변경하고, 다시 테스트를 실행하며 계속해서 진행할 수 있습니다.

이는 테스트 스위트가 단순한 안전망 그 이상이 된다는 것을 의미합니다. 그것은 조향 핸들 (Steering Wheel)이 됩니다.

테스트가 없다면, 에이전트는 그저 그럴듯해 보이는 코드를 생성할 뿐입니다.

좋은 테스트가 있다면, 에이전트는 측정 가능한 목표를 갖게 됩니다.

나쁜 테스트가 있다면, 에이전트는 여전히 목표를 갖게 됩니다. 불행하게도 그것이 잘못된 목표일 수 있으며, 에이전트는 놀라운 열정으로 그 목표를 향해 질주할 것입니다.

구조화된 출력 파일: 더 적은 컨텍스트, 더 적은 비용, 더 적은 고통

또 다른 유용한 패턴은 테스트 스크립트의 출력을 디스크 상의 구조화된 파일 (Structured Files)로 유지하는 것입니다.

에이전트에게 거대한 로그, 벤치마크 결과, 디버그 덤프(Debug dumps) 또는 중간 테스트 출력물을 대화 컨텍스트(Conversation context)에 계속 유지하도록 강요하는 대신, 스크립트는 JSON, Markdown 또는 일반 텍스트 보고서와 같은 구조화된 파일(Structured files)을 작성할 수 있습니다.

예시:

test-results/
  latest-summary.json
  failed-cases.json
...

이는 에이전트에게 훨씬 더 효율적인 작업 방식을 제공합니다.

마치 상자도 없이 이사를 하는 개발자처럼 거대한 출력물 벽을 대화창에 계속 끌고 오는 대신, 에이전트는 필요할 때 관련 파일을 직접 조사할 수 있습니다.

이 방식은 다음과 같은 여러 장점이 있습니다:

에이전트가 관련 부분으로 즉시 이동할 수 있습니다.
사용되는 컨텍스트(Context)가 더 작게 유지됩니다.
대화가 더 깔끔하게 유지됩니다.
디버깅(Debugging)의 재현성이 높아집니다.
토큰(Token) 사용량이 줄어듭니다.
그리고 맞습니다: 비용이 절감됩니다.

이는 대규모 테스트 스위트(Test suites), 성능 벤치마크(Performance benchmarks), 컴퓨터 비전(Computer vision) 데이터셋, 또는 원시 출력물(Raw output)이 매우 커질 수 있는 모든 경우에 특히 유용합니다.

컨텍스트는 비쌉니다. 노이즈(Noise)도 비쌉니다. 유용한 세 줄을 찾기 위해 에이전트가 5,000줄의 로그를 읽게 만드는 것은 지능이 아니라, 청구서 생성(Invoice generation)일 뿐입니다.

구조화된 파일은 에이전트에게 저렴하고, 목적 지향적이며, 실용적인 파일 시스템 기반의 메모리(Filesystem-based memory)를 제공합니다.

실제 사례: 컴퓨터 비전 성능

최근에 저희가 구축한 컴퓨터 비전 프레임워크에서 이 워크플로(Workflow)를 사용했습니다.

저희는 대규모 테스트 데이터셋과 이를 대상으로 벤치마크할 수 있는 알고리즘 세트를 가지고 있었습니다. 에이전트에게 "이것을 더 빠르게 만드세요"와 같은 모호한 지침을 주는 대신, 측정 가능한 루프(Loop)를 제공했습니다:

테스트 실행
변경 사항 시도
벤치마크 실행
결과 비교
동작의 정확성 유지
가능한 경우 성능 개선

이 설정을 통해 에이전트는 알고리즘의 성능을 크게 향상시킬 수 있었습니다. 한 사례에서는 실행 시간(Runtime)이 약 50% 감소했습니다.

이것은 마법이 아닙니다. 구조(Structure)입니다.

그 에이전트는 단순히 "똑똑하게 행동한" 것이 아니었습니다. 안전한 놀이터(Playground), 신뢰할 수 있는 테스트, 그리고 측정 가능한 피드백를 갖추고 있었습니다. 그러한 조합이야말로 AI 코딩이 진정으로 흥미로워지는 지점입니다.

개발자의 역할이 변화하고 있다

AI 에이전트가 개발자의 필요성을 없애는 것은 아닙니다.

그들은 개발자의 주의(Attention)를 이동시킵니다.

구현 코드의 모든 줄을 수동으로 작성하는 데 쓰는 시간은 줄어듭니다.

대신 다음과 같은 일에 더 많은 시간을 쓰게 됩니다:

문제를 명확하게 설명하기,
실행 가능한 피드백 루프 (Feedback loops) 생성하기,
좋은 테스트 정의하기,
아키텍처 (Architecture) 검토하기,
과적합 (Overfitting) 방지하기,
코드의 유지보수성 (Maintainability) 유지하기,
그리고 에이전트가 매우 생산적인 혼돈의 기계 (Chaos machine)가 되는 것을 막기.

환경이 더 좋을수록, 에이전트도 더 좋아집니다.

목표가 모호하고, 테스트가 약하며, 피드백 루프가 없다면, 에이전트는 여전히 무언가를 만들어낼 것입니다. 심지어 인상적으로 보일 수도 있습니다. 하지만 인상적으로 보이는 코드가 정확하고 유지보수 가능한 소프트웨어와 동일한 것은 아닙니다.

그 차이를 구분하는 것은 여전히 매우 인간의 책임으로 남아 있습니다.

결론

지난 몇 달간 얻은 가장 큰 교훈은 이것입니다:

우리가 AI 에이전트를 자동 완성 (Autocomplete)처럼 취급하는 것을 멈추고, 그들의 강점에 맞춰 워크플로 (Workflow)를 설계하기 시작할 때 AI 에이전트는 극적으로 더 유용해집니다.

그들은 반복 (Iteration)에 능숙합니다.
그들은 명령어를 실행하는 데 능숙합니다.
그들은 실패를 읽고 다시 시도하는 데 능숙합니다.
그들은 명확한 피드백 루프 안에서 작업하는 데 능숙합니다.

하지만 그들은 그래픽 인터페이스 (Graphical interfaces)를 안정적으로 테스트하는 데에는 여전히 취약합니다.
그들은 잘못된 테스트에 과적합 (Overfit)될 수 있습니다.
그들은 매우 확신에 찬 태도로 의심스러운 선택을 할 수 있습니다.

따라서 해결책은 그들이 카페인을 섭취한 너구리처럼 코드베이스 (Codebase)를 자유롭게 돌아다니게 내버려 두는 것이 아닙니다.

해결책은 레일 (Rails)을 구축하는 것입니다.

마크다운 (Markdown) 계획.
커맨드 라인 (Command-line) 진입점.
좋은 테스트.
구조화된 출력 파일.
반복 가능한 스크립트.
인간의 검토.

테스트 주도 개발 (Test-driven development)은 AI 이전에도 이미 유용했습니다.

하지만 코딩 에이전트 (coding agents)의 시대에 TDD는 훨씬 더 강력한 무기가 됩니다. 즉, 결과에 대한 통제력을 잃지 않으면서도 AI가 독립적으로 작업할 수 있게 하는 방법이 되는 것입니다.

다르게 표현하자면 다음과 같습니다.

AI 지원 개발 (AI-assisted development)의 미래는 가장 뛰어난 프롬프트 (prompts)를 작성하는 사람의 것이 아닐지도 모릅니다.

그보다는 가장 뛰어난 피드백 루프 (feedback loops)를 구축하는 사람의 것이 될 것입니다.