AI에게 코드 수정을 맡기면 결과는 생각보다 빨리 나온다.

코드가 나온 뒤에는 사람이 판단할 일이 남는다. 이 변경을 받아도 되는지, 테스트 실패를 어디까지 봐야 하는지, 배포 전에 무엇을 멈춰야 하는지 정해야 한다.

그래서 AI에게 일을 더 많이 맡길수록 사람이 덜 중요해지는 게 아니다.

사람이 직접 쓰던 줄이 줄어드는 대신, 무엇을 만들지, 어떤 재료를 볼지, 무엇을 통과해야 완료인지 더 정확히 남겨야 한다.

이 글에서는 그래서 좋은 프롬프트보다 검증 가능한 작업대를 먼저 본다.

Karpathy의 Software 2.0, Verifiability, MenuGen 회고를 읽을 때 내가 가져온 것도 그쪽이었다. “AI가 코드를 잘 쓴다”보다 “사람은 무엇을 책임져야 하는가”가 더 오래 남았다.

여기서는 Karpathy를 증명 도장처럼 쓰지 않는다. 맥락을 따라가기 좋은 글과 회고를 렌즈로 삼아, AI 에이전트 작업에서 검증 가능한 컨텍스트를 어떻게 남길지 본다.

현재 요청과 재사용 컨텍스트 층이 검증 지점으로 이어지는 구조.

컨텍스트 엔지니어링은 요청을 길게 쓰는 일이 아니다. 요청과 규칙, 도메인 문서, 검증 경계를 어떤 순서로 보게 할지 정한다.

먼저 남길 작업대 체크리스트

내가 이 글에서 가져가려는 산출물은 Karpathy 요약이 아니라, AI 에이전트에게 일을 맡기기 전에 확인할 작업대 체크리스트다.

  • 이번 요청의 목표가 한 문장으로 보이는가.
  • 에이전트가 봐야 할 파일, 문서, 실패 로그는 무엇인가.
  • 완료 판단에 쓸 검증 명령이나 화면 확인 기준이 있는가.
  • 삭제, 원격 반영(push), 배포(deploy)처럼 되돌리기 어려운 작업의 멈춤 조건이 있는가.

이 네 가지가 없으면 결과가 빨리 나와도 받아들일 기준이 약하다. 그래서 작업 전에 이 기준부터 보이게 만든다.

컨텍스트는 작업대다

컨텍스트 엔지니어링(context engineering)을 처음 들으면 프롬프트를 더 길고 정교하게 쓰는 일처럼 보인다. 나는 이제 조금 다르게 본다.

모델이 다음 판단을 하기 전에 책상 위에 놓을 자료를 고른다. 이번 요청, 관련 파일, 도메인 문서, 실패 로그, 검증 명령, 멈춤 조건이 그 작업대에 올라간다.

문제는 많이 올리는 것이 아니다. 오래된 로그와 최신 결정, 한 번짜리 취향과 반복 기준, 사용자의 승인과 에이전트의 추측이 한데 섞이면 작업대는 넓어도 위험해진다.

Software 2.0 렌즈로 보면 검증이 남는다

Karpathy의 Software 2.0 글에서 내가 가져온 핵심은 “사람이 모든 규칙을 직접 쓰지 않는 영역이 커진다”는 점이다. 신경망에서는 사람이 코드를 한 줄씩 쓰기보다 데이터, 모델 구조, 학습 과정이 프로그램의 큰 부분을 만든다.

AI 코딩도 비슷한 압력을 만든다. 내가 모든 줄을 직접 쓰지 않는다면, 내가 책임져야 할 것은 더 명확해진다. 앞의 체크리스트처럼 사양, 컨텍스트, 검증 기준, 멈춤 조건을 남겨야 한다.

Karpathy의 Verifiability 글은 이 지점을 더 직접적으로 건드린다. 내가 검증하는 일일수록 자동화하기 쉽다. 반대로 검증하지 못하는 일을 빠르게 맡기면, 속도는 올라가도 책임은 흐려진다.

그래서 규칙 파일에는 추상적인 가치보다 검증 가능한 문장이 더 잘 맞는다.

예를 들어 “좋은 코드를 작성한다”는 모호하다. “완료 전 npm run check와 npm run build를 실행한다”로 바꾸면 확인이 쉽다. “사용자 경험을 고려한다”는 말 대신 “새 UI는 모바일과 데스크톱에서 텍스트 겹침을 확인한다”라고 쓴다. “안전하게 작업한다”는 말은 “삭제, push, deploy는 확인 전에는 진행하지 않는다”로 구체화한다.

좋은 규칙 파일은 에이전트를 똑똑하게 만드는 문서가 아니다. 검증 가능한 작업 단위를 더 자주 보게 만드는 문서다.

Karpathy가 MenuGen을 만들며 남긴 회고도 같은 방향으로 읽힌다. 첫 프로토타입은 금방 나온다. 자연어로 만들고, 실행 결과를 보며 고치면 작동하는 데모까지는 빠르다.

하지만 첫 결과를 보고 “80% done”처럼 느껴도 실제 진척은 “closer to 20%”일 때가 있다. 배포, 환경 변수, 인증, 결제, rate limit, deprecated API, dev/prod 설정으로 들어가면 일이 전혀 달라진다.

나는 이 지점이 규칙 파일 문제와 바로 이어진다고 본다. 감각 코딩(vibe coding)은 데모를 빨리 만든다. 하지만 서비스를 책임지는 작업으로 넘어가면 다음 질문이 필요하다.

어디까지 AI에게 맡길 것인가.
어떤 변경은 사람이 먼저 판단할 것인가.
무엇을 통과해야 완료라고 부를 것인가.
되돌리기 어려운 작업은 어디서 멈출 것인가.

이 질문의 답은 대화창보다 규칙 파일에 더 잘 남는다.

규칙보다 검증 가능한 컨텍스트가 먼저다

Karpathy의 문장을 그대로 따라 쓰는 것이 목적은 아니다. 내가 가져갈 기준은 더 실무적이다.

AI에게 바로 코드부터 요구하면 결과는 빨리 나온다. 하지만 결과를 받아들일지 판단하려면 다른 재료가 필요하다. 봐야 할 파일, 통과할 명령, 사람에게 돌아올 변경, 데모와 운영의 경계가 보여야 한다.

“좋은 설계를 한다” 같은 문장은 이 작업대에서 약하다. “모바일과 데스크톱에서 텍스트 겹침을 확인한다”는 훨씬 강하다. “안전하게 작업한다”보다 “git push는 공개 경계이므로 변경 파일, remote, branch를 확인한 뒤 승인받는다”가 낫다.

컨텍스트 엔지니어링은 긴 프롬프트가 아니다

컨텍스트 엔지니어링(context engineering)은 프롬프트를 길게 쓰는 일이 아니다. 모델이 다음 판단에서 볼 자료를 설계한다.

여기서 중요한 단어는 “많이”가 아니라 “알맞게”다.

초보적인 실수는 모든 것을 한 파일에 넣는 것이다. 프로젝트 철학, 코드 스타일, 배포 절차, 보안 예외, 글쓰기 톤, 검수 기준, 장기 메모를 전부 root 규칙 파일에 넣으면 든든해 보인다. 하지만 실제 작업에서는 중요한 문장이 묻힌다.

컨텍스트 엔지니어링으로 규칙 파일을 보면 세 층으로 나누기 쉽다.

  • 최상위(root) 규칙은 모든 작업에 반복 적용되는 짧은 기준이다. 위험 작업 확인, 검증, 수정 범위처럼 매번 빠지면 안 되는 내용을 둔다.
  • 작업 분야(domain) 문서는 특정 작업 때만 필요한 기준이다. 글쓰기 가이드, UI 기준, 배포 절차처럼 작업 종류가 맞을 때만 꺼내 보는 쪽이 낫다.
  • 현재 프롬프트는 이번 요청의 목표와 예외다. “Karpathy 인용 중심 초안”이나 “파일로 저장”처럼 오늘 달라질 수 있는 조건을 둔다.

OpenAI의 Codex 문서는 AGENTS.md를 global, project, 현재 작업 경로 기준으로 instruction chain에 넣는다고 설명한다. 가까운 디렉터리의 지시가 더 구체적인 기준이 된다. Claude Code 쪽은 CLAUDE.md를 읽고, 이미 AGENTS.md를 쓰는 저장소라면 import나 symlink로 연결할 수 있다고 안내한다.

도구별 로딩 방식은 다르다. 하지만 운영 관점의 결론은 같다.

반복 기준은 저장소에 두고,
작업별 기준은 필요할 때만 보이게 하고,
이번 요청은 짧게 남긴다.
검증할 수 없는 변경은 작게 쪼개거나 멈춘다.

이게 내가 더 분명하게 잡은 기준이다. 프롬프트 엔지니어링은 모델에게 무엇을 말할지 다룬다. 컨텍스트 엔지니어링은 모델이 무엇을 보고 일하게 할지 다룬다. AI 에이전트와 저장소에서 일할 때는 후자가 점점 더 중요해진다.

내가 남긴 문장

핵심 문장을 다시 쓰면 이렇다.

AI에게 일을 더 맡길수록, 사람이 남겨야 할 컨텍스트는 더 검증 가능해야 한다.

Karpathy의 글과 회고를 렌즈로 삼아도 같은 곳에 도착한다. 사람이 모든 줄을 직접 쓰지 않는다면, 사람이 더 신경 써야 할 것은 사양, 컨텍스트, 검증, 멈춤 조건이다.

감각 코딩은 출발 속도를 올려준다. 하지만 내가 책임질 수 있는 작업으로 바꾸는 것은 첫 데모가 아니라, 그 뒤에 남긴 검증 가능한 작업대다.

시리즈 연결

참고한 원문과 문서