요즘 모두가 AI를 이용해 앱을 만들고 있습니다. 사촌은 하나를 만들었고, 매니저도 하나를 만들었습니다. 심지어 우리가 만들어야 할지에 대한 회의 중에 누군가가 하나를 만들기도 했습니다.
정말로 대단합니다. 하지만 공정한 질문이 제기됩니다. 만약 초보 개발자와 10년 경력의 엔지니어가 같은 모델을 사용하고 같은 프롬프트를 사용한다면, 실제로 무엇이 다를까요?
머릿속으로 실험을 진행해 봅시다. 두 명의 개발자, 같은 AI, 같은 요청:
"사용자 로그인이 가능한 태스크 트래커 앱을 만들어 줘."
원어민 AI 빌더인 Nia와, 프로덕션 환경에서 충분히 많은 문제를 겪어 신중해진 베테랑 엔지니어인 Sam을 소개합니다.
Day 1: 아무 차이도 없음
두 사람 모두 오후 안에 작동하는 데모를 얻습니다. 로그인 페이지, 태스크 목록, 멋진 다크 테마, 작업을 완료할 때 터지는 작은 색종이 조각들까지요. 두 사람 모두 스크린샷을 게시했고, 40개의 좋아요를 받았습니다.
만약 하루 1일차만 본다면, 경험은 중요하지 않습니다. 이것이 모든 사람이 흥분하는 부분이며, 그들이 그렇게 느끼는 것은 당연합니다. AI가 오후 만에 예전에는 일주일이 걸리던 일을 해냈기 때문입니다.
하지만 차이는 나중에 나타납니다. 소프트웨어에서 항상 그렇듯이: 무언가를 변경할 때인 두 번째 달에 말이죠.
토큰은 어디로 가는가
여기가 Nia의 3일차 모습입니다. 사용자가 태스크가 가끔 사라진다고 보고합니다.
Nia: 태스크가 가끔 사라져요, 고쳐주세요
AI: (스토리지 레이어를 재작성)
Nia: 이제 로그인이 안 돼요
...
이 메시지들 각각은 전체 대화와 커지고 있는 코드베이스의 상당 부분을 다시 컨텍스트(context)로 끌어들입니다. 모든 수정 사항은 버그가 존재하는 파일보다 더 많은 파일을 건드립니다. 일주일 후 앱은 대부분의 시간 동안 작동하지만, 아무도 그 이유를 모르고 토큰 청구서는 전화번호처럼 거대합니다.
같은 버그에 직면한 Sam의 3일차 모습:
Sam: CLAUDE.md를 읽어봐요. 편집 후 태스크가 간헐적으로 사라져요.
지금은 코드를 변경하지 마세요: 태스크가 기록되는 곳을 찾고 두 쓰기가 경쟁할 수 있는 방법을 나열해 주세요.
...
메시지 4개. 작은 차이(diff) 하나. 버그가 재발할 경우 잡아낼 테스트. Sam은 Nia보다 토큰을 더 많이 사용한 것이 아니라, 적게 사용했다. 경험이 Sam으로 하여금 마법처럼 더 나은 프롬프트를 작성하게 만든 것은 아니었다. 그것은 Sam으로 하여금 작고 검증 가능한 단계를 요청하게 만들었다.
(이 버그가 익숙해 보인다면, 이는 내가 모델 비즈니스 워크플로우를 상태 기계로(Model business workflows as state machines)에서 작성했던 것과 같은 문제이다. AI는 이러한 문제를 제거하지 않는다. 단지 더 빠르게 도달하게 할 뿐이다.)
Two loops. Prompt and pray: ask for a whole feature, run it, see something broken, say fix it, repeat. Plan, test, ship: plan, write a failing test, make one small change, read the diff, commit, then take the next step.
같은 모델, 두 개의 루프. 그중 오직 하나만이 끝난다. 대화형 다이어그램 탐색하기
측면 비교 (The side-by-side)
| Nia (초보 빌더) | Sam (경험 많은 엔지니어) |
|---|
| 첫 프롬프트 | "앱 전체를 구축해 줘" | "앱을 계획하고, 아직 코드는 작성하지 마" |
| ... | | |
| Sam의 열(column) 중 어느 것도 AI에 관한 것이 아니다. 그것은 단지 엔지니어링 그 자체이다: 작은 단계, 테스트, 버전 관리(version control), 그리고 '완료'가 무엇을 의미하는지 아는 것이다. AI는 곱셈기(multiplier)이며, 당신이 가져오는 모든 습관을 증폭시킨다. | | |
AI가 작성한 코드를 지속 가능하게 만드는 요소 (What makes AI-written code sustainable)
"지속 가능하다(Sustainable)"는 것은 하나의 질문을 위한 멋진 단어이다: 다음 달에 누군가 이 코드를 망가뜨리지 않고 변경할 수 있는가? 여기서 '누군가'에는 당신과 AI 모두가 포함된다.
답을 결정하는 네 가지 요소:
- 행동을 설명하는 테스트(Tests that describe behaviour). 테스트 스위트(test suite)는 AI가 오해할 수 없는 유일한 사양입니다. 테스트가 있으면 “이것을 리팩토링해 줘”라는 요청은 안전합니다. 테스트가 없으면, 모든 변경 사항은 AI가 자신감 있게 시도하는 도박과 같습니다.
- 작고 읽기 쉬운 Diff. 변화를 문장으로 설명할 수 없다면, 검토할 수도 없습니다. 그리고 검토되지 않은 코드가 바로 그럴듯하지만 잘못된 버그(plausible-but-wrong bugs)가 배포되는 방식입니다. 제가 가장 좋아하는 예시는 타임아웃 시 재시도하고 두 번 결제하는 환불 엔드포인트입니다. 이는 Diff 상으로는 완벽하게 올바르게 보입니다 (멱등성 키를 방지하는 방법 참고).
- 문서화된 결정 사항(Written-down decisions). 프로젝트 지침 파일(예:
CLAUDE.md, AGENTS.md, .cursorrules 등 도구가 읽는 모든 파일)에 테스트를 실행하는 방법, 아키텍처가 무엇인지, 그리고 건드리지 말아야 할 것이 무엇인지를 명시합니다. AI가 매 세션마다 코드베이스를 재발견할 필요가 없어지며, 이것이 바로 가장 큰 토큰 절약 지점입니다.
- 지루하지만 확실한 선택(Boring choices). 데이터베이스는 다섯 개가 아닌 하나만 사용합니다. AI가 반쯤 기억하는 라이브러리 대신 모두가 아는 라이브러리를 사용합니다. AI는 인기 있는 도구에 붙일 접착제 코드(glue)를 작성하는 데 매우 능숙하지만, 생소한 도구를 디버깅하는 것은 매우 서툽니다.
스킬(Skills), 플러그인 및 도구: 붙여넣기를 멈추고 장비하기 시작하라
제가 보는 가장 큰 토큰 소모처는 **붙여넣기(pasting)**입니다. 동일한 오류 로그, 동일한 문서 페이지, 동일한 “우리 프로젝트가 작동하는 방식” 단락 등을 반복적으로 붙여넣는 것입니다.
숙련된 개발자들은 대신 AI에게 **도구(tools)**를 제공합니다:
- 스킬 및 플러그인(Skills and plugins): 검토 체크리스트, 배포 프로세스 또는 감사와 같이 반복 가능한 작업을 패키징하여 매번 설명할 필요가 없게 합니다.
- MCP 서버(MCP servers): AI가 티켓을 읽거나, 스테이징 데이터베이스를 쿼리하거나, 자체적으로 배포를 확인하게 하여, 사용자가 출력을 복사 붙여넣기 할 필요가 없게 만듭니다. (저는 정확히 이 이유로 Java 서비스를 위한 MCP 서버를 만들었습니다.)
- 자신만의 스크립트(Your own scripts): 테스트 명령어, 스크린샷 스크립트, 린터(linter). AI가 이를 실행하고 자체 작업을 검사할 수 있습니다.
실제 예시: 이 사이트입니다. AI 어시스턴트를 사용하여 구축하는 동안:
- Archify는 AI가 박스를 배치하는 대신, 자체 검증(validation checks) 기능을 갖춘 다이어그램을 직접 그렸다.
- SEO 감사 스킬(claude-seo)이 구축된 사이트에 체크리스트를 실행하여 실제 버그를 발견했다:
robots.txt가 더 이상 존재하지 않는 사이트맵을 가리키고 있었다.
- 모든 시각적 변경 사항은 배포되기 전에 헤드리스 브라우저(headless browser)에서 스크린샷으로 찍혔는데, 이 과정에서 휴대폰 화면에 오버플로우되는 밈(meme)과 깨진 이미지로 렌더링된 다이어그램을 포착할 수 있었다.
- 그리고 홈페이지의 스택 섹션은 내가 마음에 들지 않는 두 가지 디자인을 거쳤다. 세 번째 시도 전에는 네 개의 스케치 중 하나의 컨셉을 고르라는 요청을 받았다. 그 아이디어가 결정적이었다.
마지막 것은 도구가 아니다. 그것은 가장 오래된 엔지니어링 습관이다: 구축하기 전에 무엇을 만들지 합의하는 것. 이것이 AI에도 통한다는 것이 밝혀졌다.
느낌대로 코딩할 때 나타나는 징후 (Signs you're vibe coding)
솔직하게 점수를 매겨보세요. 각 항목당 1점씩:
0–2점: 당신은 Sam이다. 3–5점: 개선 중이다. 6–8점: 당신은 Nia이며, 괜찮다. 모든 Sam은 Nia로 시작했다. 좋은 소식은 Sam의 항목에 있는 모든 습관은 배울 수 있다는 것이며, AI에게 단순히 고쳐달라고 요청하는 대신 설명해 달라고 요청하면 기꺼이 배우는 것을 도와줄 것이다.
플레이북 (The playbook)
내일부터 Sam처럼 일하고 싶다면, 전체 과정은 다음과 같다:
- 코드 작성 전에 계획을 세우세요.
코드가 존재하기 이전에 계획(plan)을 요청하고, 그 계획에 대해 반대 의견을 제시하세요.
- 프로젝트 지침 파일(project instructions file)을 1일차에 작성하세요: 실행 방법, 테스트 방법, 규칙 등을 명시합니다.
- 요청당 한 가지 변경 사항만, 2분 안에 검토할 수 있을 만큼 작게 만드세요.
- 중요한 것은 항상 먼저 테스트하세요: 실패하는 테스트를 작성한 다음, 수정하세요.
- 모든 디프(diff)를 읽으세요. 이해가 안 된다면 승인하기 전에 "왜?"라고 물어보세요.
- 매번 성공적인 단계(green step) 후에 커밋하여, 언제든지 되돌아갈 수 있도록 하세요.
- 붙여넣지 말고 장비시키세요: AI가 실행할 수 있는 기술, 플러그인, MCP 서버 및 스크립트 등을 준비하세요.
- 막혔을 때는 수정(fix)이 아니라 진단(diagnosis)을 요청하세요. "왜 이것이 실패하는지 설명해 달라"는 것이 다섯 번의 재작성보다 비용이 적게 듭니다.
핵심 요약 (Takeaways)
- 1일차에는 AI가 모두를 평등하게 만듭니다. 하지만 30일차에는 습관이 차이를 만듭니다.
- 숙련된 개발자는 종종 더 적은 토큰을 사용하는데, 이는 작은 단계, 테스트, 저장된 컨텍스트가 "고치기" 루프보다 효율적이기 때문입니다.
- 지속 가능한 AI 작성 코드는 테스트, 작은 디프(diff), 문서화된 결정, 그리고 지루한 선택을 포함합니다.
- AI에게 복사 붙여넣기 대신 도구를 제공하세요.
- 경험은 더 이상 타이핑 속도가 빠르다는 것을 의미하지 않습니다. 무엇을 요청해야 하는지, 그리고 답변이 언제 틀렸는지를 아는 것입니다.
원문 출판: ayushwing.com.
