*이 글은 AB180 CEO 남성필 대표님이 Claude Code와 Codex를 사용하며 느낀 인사이트를 직접 정리한 수기입니다.
Claude Code나 Codex로 무언가를 만들기 시작하면, 처음에는 속도에 놀란다. 문서가 생기고, 코드가 생기고, 웹페이지가 뜨고, 자동화가 돌아간다. 비개발자 입장에서는 특히 더 강력하다. 예전 같으면 개발자에게 부탁해야 했던 일을 직접 시도할 수 있기 때문이다.
그런데 여기서 가장 위험한 착각이 생긴다.
"에이전트가 다 만들었다고 했으니, 이제 완성된 것 아닐까?"
대부분의 경우 그렇지 않다. 에이전트가 만든 것은 완성품이라기보다 초안에 가깝다. 잘 작동하는 것처럼 보이지만, 숨은 전제가 틀렸을 수 있고, 실제 환경에서는 깨질 수 있고, 내가 의도한 것과 다른 방식으로 문제를 해결했을 수도 있다.
Claude Code나 Codex는 코드를 쓰는 능력도 뛰어나지만, 그럴듯하게 추론하고 넘어가는 능력도 뛰어나다. 그래서 비개발자가 에이전트를 잘 쓰려면 "만드는 법"만큼이나 테스트하고 강하게 만드는 법을 알아야 한다.
이 글은 내가 Claude Code, Codex, 그리고 내부 마케팅 엔진을 쓰면서 배운 검증 방법을 정리한 것이다. 개발자가 아니어도 적용할 수 있는 방식으로 썼다.
처음부터 Superpowers나 우로보로스 같은 도구로 implementation plan을 잘 짜는 것은 중요하다. 무엇을 만들지, 어떤 순서로 만들지, 어떤 파일을 건드릴지 미리 정하면 결과물의 품질이 크게 올라간다.
하지만 좋은 계획이 모든 문제를 막아 주지는 않는다. 명료해 보이는 기획 안에도 놓친 조건이 많다. 예를 들어 "리스트를 만들어 줘"라고 했을 때, 에이전트가 어떤 기준으로 매칭했는지, 어떤 데이터는 제외했는지, 비슷한 이름을 같은 회사로 봤는지까지는 자동으로 안전해지지 않는다.
그래서 중요한 질문은 이것이다.
"이 작업이 끝났다는 것을 무엇으로 증명할 것인가?"
비개발자가 Claude Code를 쓸 때는 결과물을 받는 사람이 아니라, 검증 기준을 정하는 사람이 되어야 한다. 에이전트에게 "완성해 줘"라고 말하는 것보다 "이 조건을 통과해야 완성으로 보자"라고 말하는 편이 훨씬 강하다.
가장 먼저 할 일은 코드 리뷰다. Claude Code나 Codex가 어떤 작업을 끝냈다고 말해도, 그 작업이 실제로 좋은 품질이라는 뜻은 아니다. 기능은 돌아가지만 구조가 이상할 수 있고, 에러 처리가 빠졌을 수 있고, 테스트가 비어 있을 수 있다.
작업이 끝나면 이렇게 말해 보자.
가능하면 작업한 에이전트가 아니라 다른 에이전트에게 리뷰를 맡기는 것이 좋다. 같은 에이전트는 자신이 만든 전제를 그대로 믿기 쉽다. 다른 에이전트는 조금 더 독립적으로 본다.
큰 작업이라면 코드 리뷰를 한 번 더 돌릴 수도 있다. 실제로 같은 PR을 두 번째로 리뷰하면 첫 번째 리뷰에서 못 본 문제가 다시 나오는 경우가 있다. 다만 리뷰를 많이 돌린다고 무조건 좋아지는 것은 아니다. 리뷰 결과에도 할루시네이션이 섞일 수 있다. 중요한 것은 "많이 돌리기"가 아니라, 발견된 문제를 내가 읽고 판단하는 것이다.
Claude Code가 만든 것을 Codex에게 보여 주거나, Codex가 만든 것을 Claude에게 보여 주는 것도 좋은 방법이다. 서로 다른 모델은 같은 코드를 다른 방식으로 의심한다.
이때는 단순히 "괜찮아?"라고 묻지 말고, 역할을 좁혀 주는 편이 좋다.
이 방식은 특히 비개발자에게 유용하다. 내가 직접 코드를 완전히 이해하지 못해도, 독립된 두 에이전트가 서로 다른 관점으로 지적한 부분을 비교하면 위험한 부분이 더 선명해진다.
한 번 쓰고 버릴 작업이 아니라 반복적으로 쓰는 스킬이나 자동화라면, 처음부터 멀티 에이전트 구조로 설계하는 것이 좋다. 예를 들어 다음처럼 나눌 수 있다.
여기서 핵심은 Guardrail Agent다. "고객명을 추정하지 말 것", "확정적 ID가 있으면 fuzzy matching을 쓰지 말 것", "실제 발송 전에는 dry-run을 거칠 것" 같은 원칙을 미리 넣어 두면, 에이전트가 빠르게 만들다가 중요한 안전장치를 건너뛰는 일을 줄일 수 있다.
다만 refinement loop를 너무 많이 돌린다고 결과물이 무조건 좋아지지는 않는다. 개인적으로는 두세 번이면 충분한 경우가 많다. 네 번, 다섯 번 돌리면 문장이 과하게 다듬어지거나, 처음 의도가 흐려질 때도 있다.
TDD는 Test-Driven Development의 약자다. 개발자들은 보통 코드를 짜기 전에 결과물의 성공 요건을 정의하고 이에 대한 여러 테스트를 먼저 만든다는 뜻으로 쓴다. 비개발자는 이것을 조금 더 넓게 이해하면 된다.
"완성 전에 통과해야 할 시험지를 먼저 만든다."
예를 들어 이런 식이다.
이런 조건을 먼저 적어 놓고, Claude Code에게 "이 조건을 자동 테스트로 만들어라"라고 시키면 된다.
우리 내부 파이프라인도 이런 식으로 검증한다. Salesforce, BigQuery, CMS 같은 외부 시스템을 매번 실제로 호출하지 않고, 가짜 데이터와 mock을 사용해 결과 파일, 제외 규칙, dry-run 동작을 먼저 확인한다. 비개발자 관점에서 중요한 포인트는 이것이다. 진짜 시스템을 건드리지 않아도, 중요한 흐름은 가짜 데이터로 먼저 검증할 수 있다.
테스트는 보통 특정 기능을 확인한다. 반면 audit은 전체 시스템이 중요한 원칙을 계속 지키고 있는지 전수조사한다.
예를 들어 "모든 페이지에 SEO 메타데이터가 있어야 한다", "특정 route는 static rendering을 깨면 안 된다", "고객 데이터가 들어간 파일은 generated 폴더 밖으로 나가면 안 된다" 같은 규칙은 개별 기능 테스트보다 audit에 가깝다.
Airbridge Website에서도 비슷한 일이 있었다. 사람 브라우저에서는 페이지가 정상적으로 보였지만, AI crawler나 JavaScript를 실행하지 않는 크롤러가 보는 HTML에는 본문이 거의 비어 있었다. 원인은 layout 근처의 작은 구현 선택이 prerendered HTML을 비워 버린 것이었다. 일반적인 수동 QA로는 발견하기 어려운 종류의 문제였다.
이 문제를 해결한 뒤에는 단순히 코드를 고치는 데서 끝내지 않았다. prerendered HTML에 같은 문제가 다시 생기는지 검사하는 audit을 추가했다. 즉, 한 번 겪은 실수를 다음 PR에서 반복하지 못하게 만든 것이다.
비개발자도 Claude Code에게 이렇게 요청할 수 있다.
E2E는 End-to-End의 약자다. Unit test가 작은 부품을 검사한다면, E2E 테스트는 실제 사용자가 하는 일을 처음부터 끝까지 해보는 것이다. Playwright 같은 도구를 쓰면 브라우저를 열고, 버튼을 누르고, 폼을 작성하고, 제출 결과를 확인할 수 있다.
Airbridge Website에도 production이나 preview URL을 대상으로 돌리는 smoke test가 있다. 핵심 페이지가 렌더링되는지, 주요 폼이 보이는지, 일부 경우에는 의도적으로 브라우저 에러를 발생시켜 Sentry에 실제로 잡히는지도 확인한다. 기능만 보는 것이 아니라 관측 시스템까지 살아 있는지 보는 것이다. 폼 테스트도 마찬가지다. 실제 리드 폼을 테스트하려면 DB에 값이 들어가는지 확인해야 한다.
비개발자 입장에서 배울 점은 명확하다. E2E 테스트는 단순히 "화면이 뜬다"가 아니다.
모든 것을 완벽하게 테스트하기 어렵다면 smoke test라도 만들어야 한다. Smoke test는 "일단 핵심 흐름이 연기라도 안 나는지" 확인하는 최소한의 테스트다.
비개발자는 큰 자동화를 만들 때 이렇게 말하면 된다.
AI가 만든 결과물은 화면으로 보면 바로 이상한 점이 보일 때가 많다. 줄 간격이 어색하고, 버튼 텍스트가 넘치고, 링크가 안 걸려 있고, 표가 깨져 있고, 데이터가 그럴듯하지만 이상한 기준으로 정렬되어 있을 수 있다.
중요한 것은 "왜 이렇게 했는지"를 묻는 것이다.
우리도 Article Studio에서 Google Docs로 글을 뽑을 때 비슷한 문제를 겪었다. Markdown을 그대로 밀어 넣으면 표나 링크 서식이 깨질 수 있다. 그래서 문서를 만든 뒤 다시 export해서 heading, table, link, bold가 살아 있는지 확인했다.
프로덕션에 올리는 기능이라면, 잘못되었을 때 바로 되돌릴 방법을 미리 생각해야 한다. Git revert도 방법이지만, 기능이 크거나 위험하다면 feature flag, 환경 변수, remote config, DB 설정으로 끄고 켤 수 있게 만드는 편이 낫다.
다만 비개발자가 환경 변수나 DB flag를 다룰 때는 더 조심해야 한다. true와 "true"가 다를 수 있고, trailing newline 하나 때문에 secret이 깨질 수 있고, 0과 1의 의미가 반대로 쓰일 수도 있다. 그래서 이런 작업을 할 때는 에이전트에게 반드시 검증까지 시켜야 한다.
테스트가 다 통과해도, merge 후 실제 환경에서 확인하지 않으면 반쪽짜리다. 로컬에서는 통과했지만 Vercel preview에서 깨질 수 있고, preview에서는 통과했지만 production에서만 외부 스크립트나 쿠키 정책 때문에 달라질 수 있다.
비개발자는 배포 후 이렇게 요청하면 된다.
웹사이트나 내부 도구를 운영한다면 Sentry 같은 로깅 도구는 선택이 아니라 필수다. 코딩 에이전트가 아무리 잘 짠 코드라도 실제 환경은 다르다. 브라우저 버전, 확장 프로그램, 외부 스크립트, Vercel runtime, Node.js 버전, Next.js 빌드 정책이 모두 영향을 준다.
배포 후 최소 2주 정도는 에러를 계속 봐야 한다. Slack alert, Sentry issue, user report, screenshot을 함께 확인해야 한다. 에러가 없다는 말도 검증되어야 한다.
마지막으로 가장 중요한 것은 학습이다. 한 번 틀린 것은 다시 틀리지 않게 만들어야 한다. 비개발자가 에이전트를 쓸 때 가장 큰 자산은 코드가 아니라, 점점 강해지는 작업 하네스다.
어떤 문제가 생겼다면 이렇게 정리한다.
모든 것을 AGENTS.md나 Claude.md에 넣으면 안 된다. 너무 무거워지면 에이전트가 중요한 규칙을 놓친다. 정말 어기면 안 되는 것은 hard rule로 넣고, 반복 참고용 지식은 knowledge 문서로 분리한 뒤 인덱싱하는 편이 좋다.
예를 들어 "절대 main에 바로 force push하지 말 것" 같은 것은 hard rule에 가깝다. 반면 "고객 데이터 매칭에서 확정 ID가 있으면 fuzzy matching을 쓰지 말 것" 같은 것은 knowledge에 가깝다.
아래 문장들은 거의 그대로 복사해서 써도 된다.
Claude Code와 Codex는 비개발자에게 엄청난 레버리지를 준다. 하지만 레버리지가 커질수록 검증의 중요성도 커진다. 내가 만든 것이 내부에서만 쓰이는 작은 도구라면 조금의 오류를 견딜 수 있다. 하지만 웹사이트, 고객 데이터, 영업 자동화, 프로덕션 시스템으로 이어지는 순간부터는 다른 수준의 책임이 필요하다.
결국 중요한 것은 에이전트를 믿지 않는 것이 아니다. 에이전트가 더 잘 일할 수밖에 없는 구조를 만드는 것이다. 계획을 세우고, 리뷰를 시키고, 테스트를 만들고, E2E로 확인하고, audit으로 잠그고, 배포 후 모니터링하고, 실수를 룰로 남기는 것. 이 과정을 반복하면 비개발자도 꽤 강한 소프트웨어와 자동화를 만들 수 있다.
우리는 이런 방식으로 10개 이상의 내부 프로젝트들을 계속 강하게 만들고 있다. 그리고 이런 일을 함께 해 보고 싶은 사람들을 찾고 있다. 비개발자이지만 Claude Code와 Codex로 더 많은 일을 만들고, 더 나은 하네스를 설계하고, 실제 비즈니스 결과까지 연결하고 싶은 분이라면 AB180의 열린 포지션을 한 번 확인해 보면 좋겠다.
