AI가 내 테스트 코드를 작성하게 한 6개월: 좋아진 점과 나빠진 점

지난 1월, 저는 Claude Code와 사랑에 빠진 이야기에 대해 글을 썼습니다. 그 포스트는 일종의 신혼여행 단계였습니다. 두 시간을 아껴준 첫 디버깅(debugging) 세션, 내 컨벤션(conventions)에 실제로 부합했던 첫 생성 테스트, 그리고 무언가 근본적인 것이 변화했다는 느낌 말이죠.

이 글은 6개월이 지난 시점의 포스트입니다. 아무도 쓰지 않는 종류의 글이죠. 왜냐하면 "복잡하다"라는 말은 "이것이 모든 것을 바꾼다"라는 말만큼 클릭을 유도하지 못하기 때문입니다.

요약하자면 이렇습니다: 저는 이제 테스트 코드를 거의 직접 작성하지 않으며, 산출물은 배가 되었고, 그렇지 않았다면 만들 시간이 없었을 도구들을 출시했습니다. 하지만 동시에 저는 제가 작성하지 않은 코드의 전업 코드 리뷰어(code reviewer)가 되었고, 제가 주의를 기울이지 않을 때 AI가 조용히 제 컨벤션에서 벗어나는 것을 목격했으며, 시작했을 때보다 이 분야에서 더 뒤처져 있다는 느낌을 받기도 합니다.

두 측면 모두 사실입니다. 지난 6개월이 실제로 어떠했는지 보여드리겠습니다.

좋아진 점

솔직한 답변은 이렇습니다: 예상했던 것보다 더 많이, 하지만 예상치 못한 부분에서 좋아졌습니다.

나의 테스트 워크플로우(workflow)가 파이프라인(pipeline)이 되다

6개월 전, 새로운 기능에 대한 테스트를 작성한다는 것은 Jira 티켓을 읽고, 구현 사항을 살펴보고, 수동 테스트 계획을 작성한 다음, 이를 자동화로 변환하는 것을 의미했습니다. 각 단계는 수동으로 이루어졌고, 각 단계마다 컨텍스트 스위칭(context switch)이 발생했습니다.

이제는 하나의 체인이 되었으며, AI가 그 대부분을 실행합니다:

Claude Code가 Jira 티켓과 실제 애플리케이션 코드를 모두 읽은 다음, 마크다운(markdown) 형식으로 수동 테스트 계획 초안을 작성합니다.
거기서부터 API 테스트 계획 초안을 작성하며, 이는 Postman 컬렉션(collection)으로 변환됩니다.
제가 두 가지를 모두 검토하고(그리고 실제로 실행하고) 나면, 검토된 계획을 신뢰할 수 있는 단일 출처(source of truth)로 사용하여 Cypress 시나리오를 생성합니다.

그 목록에서 중요한 단어는 **검토(reviewed)**와 **실행(run)**입니다. 저는 단순히 계획을 읽고 고개를 끄덕이기만 하지 않습니다. 애플리케이션을 대상으로 수동 테스트 계획을 직접 실행합니다. Postman 컬렉션(collection)을 실행하고 실제 응답이 돌아오는 것을 지켜봅니다. 이 두 가지가 실제 시스템을 통해 검증된 후에야 비로소 Cypress 스펙(specs)을 위한 소스(source)가 됩니다. AI가 초안을 작성하고, 현실이 검증하며, 그 다음 자동화가 이를 확정합니다.

이것이 중요한 이유는, 한 번도 실행되지 않은 테스트 계획은 그저 그럴싸하게 들리는 문서일 뿐이며, "그럴싸하게 들리는 것"은 바로 AI가 가장 잘 만들어내는 결과물이기 때문입니다. 모든 것을 먼저 실행하는 것은, 읽기에는 괜찮아 보이지만 실제 애플리케이션과 접촉했을 때 살아남지 못하는 가정(assumptions)들을 잡아내는 방법입니다. 이 규율을 건너뛰면 상황은 빠르게 잘못됩니다 (이에 대해서는 나중에 더 자세히 다루겠습니다).

결과적으로, 티켓에서 계획으로, 계획에서 컬렉션으로, 컬렉션에서 스펙으로 이어지는 지루한 번역 작업은 더 이상 제 업무가 아닙니다. 하지만 무엇을 테스트할지 결정하는 일은 여전히 제 몫입니다. 그 부분은 중요성이 줄어든 것이 아니라 오히려 더 커졌습니다.

저는 테스트뿐만 아니라 도구도 출시했습니다

이 부분은 제가 예상하지 못했던 지점입니다. AI가 확보해 준 시간은 단순히 더 많은 테스트를 만드는 데 쓰이지 않았습니다. 수년 동안 제 "언젠가" 리스트에 들어있던 것들을 만드는 데 사용되었습니다.

PostmanToCypressConverter. Postman 컬렉션을 입력받아 Cypress 스펙을 생성하는 Node CLI 도구입니다:

node index.js --input fixtures/sample.collection.json --output output/

출력 예시:

Wrote to /output
  Converted: 4 folders → 4 files
  Requests processed: 11
...

처음에는 CLI로 시작했지만, UI로 확장되었습니다. /convert 엔드포인트를 가진 작은 Express 서버, 이를 호출하는 버튼, 생성된 스펙을 보기 위한 구문 강조(syntax highlighting), 그리고 결과물을 zip 파일로 다운로드하는 기능까지 갖추게 되었습니다. 예전에는 "여유 시간"을 쪼개 한 스프린트(sprint) 내내 매달려야 했던 종류의 내부 도구를 이제는 몇 번의 저녁 시간만으로 만들 수 있게 되었습니다.

플래키니스 대시보드 (Flakiness dashboard). 우리는 여러 테스트 저장소(repository)와 다양한 배포 환경(deployment environments)에 걸쳐 GitHub Actions를 통해 모든 것을 실행합니다. 이 대시보드는 설정 가능한 시간 범위 내의 실행 데이터를 가져옵니다. 여기에는 당시 어떤 애플리케이션 브랜치(branch)가 배포되었는지를 포함하여 모든 실행, 모든 환경, 그리고 통과(pass)/실패(fail)/대기(pending)/건너뜀(skipped) 횟수와 실제 실패 사례가 포함됩니다. 모든 데이터는 NDJSON 파일에 저장되며, 두 번째 명령어가 이를 바탕으로 플래키니스 보고서(flakiness report)를 생성합니다. 모든 단계에서 가드(guards)와 에러 핸들링(error handling)을 적용했는데, 그 자체로 불안정한(flaky) 플래키니스 도구라면 너무나 아이러니할 것이기 때문입니다.

이 도구는 우리가 테스트 안정성에 대해 이야기하는 방식을 바꾸어 놓았습니다. 이전에는 "이 테스트는 플래키(flaky)하다"라는 것이 하나의 느낌이었다면, 이제는 배포 브랜치가 연결된 하나의 숫자가 되었습니다.

Claude Code를 위한 사내 플러그인 마켓플레이스. 개발자 중 한 명과 함께 내부 Claude Code 플러그인 마켓플레이스를 구축했습니다. 명명 규칙(naming convention)을 보면 각 플러그인이 누구를 위한 것인지 알 수 있습니다. 역할 접두사(role prefix) 뒤에 작업 내용이 붙는 방식이며, 예를 들어 qa-generate-tests, dev-review-pr, product-draft-ticket과 같은 식입니다. 현재 12개가 넘는 플러그인을 보유하고 있으며, 회사 내 모든 사람이 사용할 수 있습니다. 제가 스스로 찾아낸 워크플로(workflows)는 더 이상 저만의 것이 아니라 인프라(infrastructure)가 되었습니다.

에이전트 기반 유지보수 작업 (Agentic maintenance work). 가장 최근의 실험은 저장소당 하나의 에이전트를 실행하는 npm audit 스윕(sweep) 워크플로입니다. 각 에이전트는 main 브랜치로 전환하고, 최신 변경 사항을 가져온(pull) 뒤, npm audit과 npm audit fix를 실행합니다. 자동 수정이 불가능할 경우 대안적인 해결책을 찾아내고, 커밋(commit) 및 푸시(push)한 후 구조화된 설명(요약, 이유, 변경 사항)이 포함된 PR(Pull Request)을 생성합니다. 그런 다음 자동 PR 리뷰가 들어오기를 기다렸다가, 코멘트를 읽고 이를 해결하거나 해당 발견이 오탐(false positive)인 이유를 명시하며 해결됨으로 표시합니다.

모든 저장소에 걸친 의존성 위생(Dependency hygiene)은 "모두가 피하는 귀찮은 일"에서 제가 다른 일을 하는 동안 자동으로 실행되는 무언가로 변했습니다.

하필이면 슬라이드 덱(Slide decks)까지

작지만 실제적인 사례로, 여러 서비스에 걸친 테스트 상태를 보고하는 슬라이드 덱(Slide decks)을 만드는 데 예전에는 서식 지정만으로 반나절을 허비하곤 했습니다. 이제는 상태를 설명하면 Claude가 덱을 만들고, 저는 수정만 합니다. 아무도 예전 방식을 그리워하지 않습니다.

나빠진 점

이제는 하이프(Hype) 게시물들이 건너뛰는 나머지 절반에 대해 이야기하겠습니다.

코드는 덜 작성하고, 리뷰는 훨씬, 훨씬 더 많이 하게 됩니다

이것이 가장 큰 변화이며, 저는 이에 대해 정확히 말하고 싶습니다: 코드를 리뷰하는 것은 작성하는 것보다 더 어렵습니다. 코드를 직접 작성할 때는 진행하면서 정신적 모델(Mental model)을 구축합니다. 하지만 AI가 생성한 코드를 리뷰할 때는, 본인이 직접 생각하며 만들지 않았던 무언가에 대한 정신적 모델을 재구성해야 하며, 그 과정은 AI가 생성하는 속도, 즉 당신이 직접 작성할 때보다 훨씬 빠른 속도에 맞춰 이루어져야 합니다.

대부분의 날, 제 직함은

더 기술적인 표현은 없습니다. 대부분의 세션에서 Claude Code는 절제되어 있습니다. 하지만 가끔(보통 긴 세션의 막바지이거나 작업이 약간 모호할 때) 중심을 잃습니다. 한 시간 전까지만 해도 준수하던 프로젝트 컨벤션 (Project Conventions)을 따르지 않기 시작합니다. 아무도 건드려 달라고 하지 않은 것을 리팩터링 (Refactoring) 합니다. 이미 존재하는 것과 중복되는 헬퍼 (Helper) 함수를 새로 만들어냅니다.

제가 주의를 기울이고 있다면, 이는 "잠깐, 이 폴더의 나머지 부분은 어떻게 되어 있는지 확인해 봐"라는 메시지와 2분의 시간을 소모하는 것으로 끝납니다. 하지만 제가 주의를 기울이지 않는다면, 오염된 PR (Pull Request)과 정리 세션이라는 대가를 치러야 합니다. 도구가 6개월 동안 나빠진 것이 아닙니다. 그것이 얼마나 많은 감독을 필요로 하는지에 대한 제 이해가 더 솔직해진 것입니다.

그리고 비단 제 에이전트 (Agent)만의 문제가 아닙니다. 감사 스윕 (Audit sweep) 워크플로우에는 모든 PR을 확인하는 AI 리뷰어가 있으며, 그 리뷰 코멘트 중 상당수는 노이즈 (Noise)입니다. 즉, 심각하게 들리지만 우리 컨텍스트 (Context)에는 단순히 틀린 결과물들입니다. 그래서 이제 워크플로우의 일부는 AI가 다른 AI의 리뷰를 읽고 그것이 왜 오탐 (False positive)인지 설명하는 것이 되었으며, 저는 심판 역할을 합니다. 이것은 1년 전에는 쓸 수 없었을 문장이며, 이에 대해 제가 어떻게 느끼는지 여전히 확신할 수 없습니다.

매일 AI와 함께 일하지만 여전히 뒤처진다고 느낀다

이것은 도구에 관한 것이라기보다 저에 관한 것이지만, 보편적인 현상이라고 의심되기에 공개적으로 말해봅니다.

저는 매일 AI를 사용합니다. 에이전틱 워크플로우 (Agentic workflows)를 구축합니다. 플러그인 마켓플레이스를 관리합니다. 어떤 합리적인 기준으로 봐도 저는 이 분야에 깊숙이 들어와 있습니다. 그런데도 저는 이 분야가 제가 따라잡을 수 있는 속도보다 더 빠르게 움직이고 있다고 여전히 느낍니다. 새로운 모델, 새로운 기능, 새로운 패턴: 몇 주마다 제가 만든 무언가를 만드는 더 나은 방법이 등장합니다.

6개월 전에는 매일 AI와 함께 일하면 제가 흐름의 앞서 나간다고 느낄 줄 알았습니다. 하지만 그것은 주로 흐름이 얼마나 빠르게 움직이고 있는지를 더 잘 깨닫게 해줄 뿐이었습니다. 만약 당신이 뒤처진다고 느낀다면, 앞서 나가는 것처럼 보이는 사람들을 포함해 모두가 그렇게 느끼고 있다는 뜻입니다.

이 모든 것을 하나로 묶는 것

6개월이 지난 후, 제가 계속해서 되돌아오게 되는 결론은 다음과 같습니다:

AI는 이미 존재하는 것을 증폭시킬 뿐이다.

만약 당신에게 탄탄한 엔지니어링 판단력 (Engineering judgment)이 있다면, AI는 당신의 결과물을 배가시킵니다. 하지만 그렇지 않다면, AI는 당신이 검토할 수 있는 속도보다 더 빠르게 당신의 문제들을 배가시킵니다. 이러한 환경에서 훌륭한 엔지니어링 기술은 덜 중요해지는 것이 아닙니다. 오히려 더 중요해집니다. 병목 현상이 "이것을 작성할 수 있는가"에서 "이것이 맞는지 판단할 수 있는가"로 이동했기 때문입니다.

당신은 깔끔하고, 관용적(Idiomatic)이며, 확신에 찬 코드를 보고 그것이 실제로 의도한 대로 작동하는지, 그리고 의도한 "방식"대로 작동하는지를 알 수 있어야 합니다. 이 기술은 오직 당신의 언어, 프레임워크, 그리고 도구들을 제대로 이해하는 데서만 나옵니다. 만약 당신이 제대로 이해하지 못하는 스택에서 코드를 생성하기 위해 AI를 사용하고 있다면, 당신은 시간을 아끼고 있는 것이 아닙니다. 당신은 미래의 자신을 담보로 대출을 받고 있는 것이며, 그 이자율은 매우 가혹합니다.

이런 분들은 이런 방식으로 일하면 안 됩니다

저는 항상 솔직해 왔기에, 이 부분에 대해서도 솔직하게 말씀드리고 싶습니다.

만약 당신이 커리어 초기 단계에 있고, 그럴듯해 보이지만 틀린 코드를 식별할 수 있는 판단력을 아직 갖추지 못했다면, AI가 생성한 테스트에 올인하는 것은 위험합니다. 제가 매일 의지하는 검토 (Review) 기술은 수년간 직접 테스트를 작성하고, 무언가를 망가뜨리고, 그 결과를 디버깅(Debugging)하며 쌓아온 것입니다. 검토만으로는 그런 판단력을 얻을 수 없습니다. 먼저 그 자격을 갖추어야 합니다. 학습을 위해 AI를 사용하세요. AI에게 설명을 요구하고, 접근 방식을 비교하며, 당신의 이해도를 시험해 보라고 하세요. 하지만 직접 작성하는 것도 계속해야 합니다.

그리고 만약 당신의 팀에 제대로 된 검토 규율 (Review discipline)이 없다면, 생성된 코드는 누구도 정직하게 확인할 수 없는 속도로 코드베이스 (Codebase)에 흘러 들어갈 것입니다. 문제는 그 양(Volume)입니다. AI는 세심한 검토의 필요성을 없애는 것이 아니라, 모든 리스크를 그곳으로 집중시킵니다.

결론

6개월이 지난 지금, 저는 예전으로 돌아가지 않을 것입니다. 파이프라인, 도구, 시장: AI 이전의 워크플로 (Workflow)에는 이 중 어느 것도 존재하지 않았으며, 이 모든 것들이 우리 팀을 측정 가능한 수준으로 더 낫게 만들어 주고 있습니다.

하지만 업무의 형태가 변했습니다. 저는 테스트를 작성하는 사람에서, 무엇을 테스트할지 설계하고 구축된 결과물을 검증하는 사람으로 변했습니다. 타이핑은 줄어들고, 판단(Judgment)은 늘어났습니다. 이 변화 속에서 번창할 엔지니어는 프롬프트(Prompt)를 가장 잘 작성하는 사람이 아닙니다. 그들은 자신감 넘치고 잘 정돈된 코드의 벽을 보고, 단순한 느낌(Vibes)이 아닌 경험을 바탕으로 그것이 실제로 맞는지 알아챌 수 있는 사람들입니다.

그 기술은 언제나 훌륭한 엔지니어와 그 외의 사람들을 구분 짓는 요소였습니다. AI는 단지 그 기술이 없는 것에 대한 대가를 더 높게 치르게 만들었을 뿐입니다.