2026.5 기준 AI를 잘 쓰기위한 팁을 정리해봤다. 프로그래머가 아니더라도 이해할 수 있게 쓰려고 노력했다.

이해하기

AI의 성능

Opus 4.5까지만 해도 AI 아직 애매하다고 생각했다. Opus 4.6에서 크게 좋아졌고 AI를 활용하는 방법에 대한 연구 역시 많이 진전이 됐다.

아직도 AI가 멍청하다고 하는 사람이 있다면, 나는 아마도 그 사람이 AI를 잘 못 써서 그런 것이라고 얘기할 것이다. (사실은 속으로만 생각ㅎ)

지금(2026.5)의 AI는 굉장히 똑똑하고 빠르지만, 일머리는 하나도 없는 신입사원 같은 녀석이다. 결국 AI를 잘 쓰려면 시스템, 가이드라인 따위가 중요하다.

 

 

 

프롬프트를 이해하자

 

프롬프트는 AI에게 건네는 요청서다.

위에서 AI를 일머리 없지만 일처리는 빠른 신입사원이라고 했다.

회의를 앞둔 부장님이 AI 사원한테 다음과 같이 시킨다.

"이 문서 사람당 2부씩 인쇄해줘"

이 문장은 사람에게는 그럭저럭 통할 수 있다. 부장님이 회의 직전에 말했고, 책상 위에 문서가 있고, 회의 참석자가 몇 명인지 대충 알고 있다면 알아서 처리할 수 있기 때문이다.

 

 

하지만 AI 입장에서는 비어있는 칸이 많다. 이 문서가 어떤 문서인지, 사람이 누구인지, 몇 명인지, 흑백인지 컬러인지, 단면인지 양면인지, 바로 출력해도 되는지 전부 추측해야 한다.

AI는 어쩌면 모든 회사 사람들한테 자료를 뽑아주기 위해 문서를 수천 부 인쇄하고 있을지 모른다.

조금 더 나은 프롬프트는 이렇다.

"오늘 오후 5시 기획 회의 참석자 6명에게 나눠줄 자료야. 방금 올린 PDF를 사람당 2부씩, 총 12부, 흑백 양면으로 인쇄해줘. 실제 출력 전에 설정을 한번 요약해서 확인받아줘."

좋은 프롬프트란 AI가 멋대로 추측해야 하는 빈칸을 줄여주는 일이다.

컨텍스트를 이해하자

AI의 두뇌를 LLM이라고 할 수 있다. 그런데 LLM에게는 "기억"이란 게 없다. 그냥 사용자가 넣은 요청서를 읽고, 사용자가 좋아할 만한 답변을 내놓는 게 LLM이 하는 모든 일이다.

그래서 LLM은 메모장을 하나씩 가지고 있다. 이 메모장이 바로 컨텍스트(Context)이다.

(엄밀히 말하면 LLM이 진짜 메모장을 들고 있는 것은 아니다. 앱이나 하네스가 이전 대화, 파일, 지시문, 도구 결과를 LLM 앞에 다시 펼쳐주는 것에 가깝다. 여기서는 쉽게 설명하기 위해 메모장이라고 부르겠다.)

예를 들어 같은 프롬프트라도 컨텍스트에 따라 결과가 달라진다.

 

 

"이 문서 사람당 2부씩 인쇄해줘"

새 대화에서 이 말만 하면 AI는 거의 모든 것을 추측해야 한다. 하지만 같은 세션의 메모장에 "오늘 오후 5시 기획 회의 참석자는 6명이다", "방금 올린 PDF가 회의 자료다", "우리 회사는 회의 자료를 기본적으로 흑백 양면으로 뽑는다" 같은 내용이 들어있다면, AI는 그 정보를 바탕으로 훨씬 덜 헤맨다.

그리고 이 메모장은 세션마다 하나씩 가지고 있다. 세션이란, 챗봇과 "새 대화"할 때 그 대화 채팅 하나와 같다.

프롬프트는 이번 요청의 빈칸을 줄이고, 컨텍스트는 이미 주어진 맥락을 다시 쓰게 해준다. 하지만 매번 사용자가 이 둘을 완벽히 챙기기는 어렵다. 그래서 반복 규칙과 안전장치를 시스템 쪽에 깔아두는 하네스가 필요하다.

 

하네스를 이해하자

컨텍스트가 이미 적힌 메모장이라면, 하네스는 그 메모장에 필요한 내용을 자동으로 채우거나 위험한 행동을 막는 작업 환경이다.

대충 말해도 대참사가 일어나지 않도록 막아주는 장치라고 보면 된다.

예를 들어 회사 출력 시스템에 AI를 붙였다고 해보자. 이 시스템에 이런 규칙을 미리 넣어둘 수 있다.

  • 회의 인원 정보가 없으면 바로 출력하지 말고 먼저 물어본다.
  • 캘린더에서 곧 시작할 회의와 참석자 수를 확인해서 컨텍스트에 넣는다.
  • 50부 이상 출력하려면 사용자 확인을 받는다.
  • 실제 출력 전에 문서명, 출력 부수, 컬러 여부, 단면/양면 설정을 요약해서 보여준다.

이러면 사용자가 "문서 사람당 2부씩 인쇄해줘"라고 대충 말해도 사고가 날 가능성이 줄어든다.

프롬프트가 "이번 일을 어떻게 시킬 것인가"라면, 하네스는 "대충 시켜도 어느 정도 안전하게 굴러가게 만드는 시스템"이다.

 

 

응용하기

 

 

프롬프트

좋은 프롬프트는 친절한 요청서다

프롬프트를 잘 쓴다는 것은 말을 길게 쓰는 것이 아니다. AI가 멋대로 추측해야 하는 빈칸을 줄이는 것이다.

앞에서 프롬프트를 요청서라고 했다. 좋은 요청서는 화려한 문장이 아니라, 일을 맡은 사람이 헤매지 않게 필요한 정보를 담고 있는 문서다.

예를 들어 이렇게 말할 수 있다.

"자료 정리해줘"

이 말만 들으면 AI는 무엇을 기준으로 정리해야 하는지, 누가 읽을 자료인지, 어느 정도 깊이로 정리해야 하는지, 표로 줄지 글로 줄지 전부 추측해야 한다.

조금 더 나은 프롬프트는 이렇다.

"방금 올린 회의 자료를 팀장에게 보고할 수 있게 정리해줘. 목적은 오후 5시 기획 회의 전에 핵심 쟁점과 결정할 일을 빠르게 파악하는 것이다. 형식은 제목, 요약 5줄, 결정 필요 사항, 리스크, 확인 질문 순서로 써줘. 자료에 없는 내용은 추측하지 말고 확인 필요라고 표시해줘. 먼저 바로 작성하지 말고, 네가 이해한 정리 방향과 빠진 정보가 있는지부터 알려줘."

이 프롬프트가 좋은 이유는 길어서가 아니다. 목적, 대상, 자료, 형식, 제약, 진행 방식이 들어있기 때문이다.

먼저 방향을 맞춰라

 

특히 처음부터 결과물을 요구하지 않는 것이 중요하다. AI는 빠르기 때문에 틀린 방향으로도 아주 빠르게 달린다. 그래서 복잡한 일을 시킬 때는 바로 최종본을 쓰게 하기보다 먼저 방향을 맞추는 편이 좋다.

"바로 쓰지 말고 먼저 목차만 제안해줘."

"내 요청에서 애매한 점이 있으면 작업하기 전에 질문해줘."

"먼저 네가 이해한 목표와 작업 계획을 요약해줘."

이런 문장은 AI를 느리게 만드는 것이 아니라, 삽질을 줄이는 장치다.

무엇을 질문할지 고민인가? 걱정 마라 아래에 기똥찬 해결법을 소개해놨다. Grill-me 스킬 항목을 참고하라.

Plan mode를 쓰자

복잡한 작업은 그냥 시키지 말고 Plan mode를 쓰는 것이 좋다.

그냥 "이 문서 사람당 2부씩 인쇄해줘"라고 하면 AI는 바로 출력 설정을 잡으려 한다. 문제는 이때 문서가 확정되지 않았거나, 참석자 수가 없거나, 컬러/흑백 설정이 빠져 있어도 일단 진행하려 할 수 있다는 점이다.

Plan mode는 이 속도를 일부러 늦춘다. 바로 실행하지 않고 먼저 목표, 범위, 빠진 정보, 위험한 조건, 작업 순서를 정리하게 만든다.

 

 

예를 들어 이렇게 말할 수 있다.

"바로 인쇄하지 말고 Plan mode로 먼저 봐줘. 인쇄 전에 필요한 정보, 빠진 정보, 확인해야 할 위험한 조건을 정리해줘."

혹은 대부분 Shift+Tab을 누르면 Plan Mode로 전환이 가능하다. 이 상태에서 말하면 된다.

그러면 AI는 먼저 이런 식으로 정리한다.

  • 어떤 문서를 출력할지 확정됐는가?
  • 참석자 수가 있는가?
  • 사람당 몇 부인지 명확한가?
  • 총 출력 부수는 몇 부인가?
  • 컬러/흑백, 단면/양면 설정이 있는가?
  • 사용자 확인이 필요한 조건이 있는가?

이걸 보고 사용자는 부족한 정보를 채워줄 수 있다.

Plan mode가 좋은 이유는 AI가 더 똑똑해져서가 아니다. 틀린 방향으로 빠르게 달리기 전에 멈출 기회를 만들어주기 때문이다.

스킬

스킬은 반복되는 작업 종류를 위한 절차서다.

프롬프트가 이번 요청서라면, 스킬은 특정 업무를 맡았을 때 꺼내는 레시피에 가깝다.

예를 들어 이런 것들이다.

인쇄 업무를 자주 시킨다고 해보자. 매번 프롬프트에 "회의 자료면 참석자 수를 확인하고, 기본은 흑백 양면으로 하고, 50부 이상이면 확인받고, 출력 전에는 설정을 요약해줘"라고 쓰는 것은 귀찮다.

그럴 때 인쇄 스킬을 하나 만들어둔다.

  • 회의 자료인지 먼저 확인한다.
  • 참석자 수가 있으면 사람당 필요한 부수를 계산한다.
  • 참석자 수가 없으면 바로 출력하지 말고 질문한다.
  • 기본 출력은 흑백 양면으로 한다.
  • 50부 이상이면 사용자 확인을 받는다.
  • 출력 전에는 문서명, 부수, 컬러 여부, 단면/양면 설정을 요약한다.

이렇게 만들어두면 다음부터는 길게 설명할 필요가 없다.

"이 문서 사람당 2부씩 인쇄해줘. 인쇄 스킬 써서 처리해줘."

이렇게 툭 던지면 된다.

이런 규칙은 매번 프롬프트에 쓰기에는 길고, 모든 대화에 항상 적용하면 오히려 방해된다. 필요할 때만 꺼내 쓰게 만드는 것이 스킬이다.

 

CLAUDE.md / AGENTS.md

반대로 매번 같은 말을 프롬프트에 쓰고 있다면, 그건 스킬보다 업무 매뉴얼에 가깝다.

예를 들어 매번 "말투는 쉽게 써줘", "추측하지 말고 모르면 물어봐", "수정 전에는 계획을 먼저 말해줘", "검증 가능한 것은 확인하고 말해줘" 같은 말을 반복하고 있다면, 그건 매 요청마다 붙일 내용이 아니다.

CLAUDE.md나 AGENTS.md는 신입사원이 대화 시작 전에 무조건 읽는 업무 매뉴얼이라고 생각하면 된다. 말투, 작업 방식, 금지사항, 검증 방식처럼 항상 적용할 지시는 프롬프트에 매번 쓰기보다 이런 문서에 빼두는 편이 낫다.

프롬프트는 이번 요청을 잘 쓰는 기술이다. 반복되는 요청 방식은 스킬, CLAUDE.md, AGENTS.md 같은 매뉴얼 쪽으로 넘기는 것이 좋다.

다만 이 문서를 거대하게 만드는 것이 항상 좋은 것은 아니다. 이 이야기는 심화에서 따로 다루겠다.

 

컨텍스트

컨텍스트를 잘 쓴다는 것은 AI의 메모장을 깨끗하게 유지하는 일이다. 프롬프트를 아무리 잘 써도, 메모장에 엉뚱한 내용이 잔뜩 섞여 있으면 AI는 그걸 같이 보고 답한다.

 

한 세션에는 한 주제만 넣자

한 컨텍스트 내에서 이것저것 질문하지 않는 것이 좋다.

 

 

처음에는 별문제가 없어 보인다. 인쇄 설정을 물어보다가, 회의록을 쓰고, 업무 메일을 쓰다가, 다시 인쇄 업무로 돌아올 수도 있다. 사람은 대충 화제를 전환할 수 있지만, AI 입장에서는 이 모든 내용이 같은 메모장에 쌓인다.

그러면 나중에 "아까 말한 방식대로 해줘"라고 했을 때, 그 "아까"가 인쇄 이야기인지, 회의록 얘긴지, 업무 메일 얘기인지 흐려질 수 있다.

새로운 작업은 새 세션에서 진행하자.

 

Compact를 하자

작업이 길어지면 컨텍스트가 계속 불어난다. 처음에는 필요한 정보가 쌓이는 것처럼 보이지만, 어느 순간부터는 이미 끝난 논의, 잘못 갔다가 되돌린 방향, 중간에 버린 선택지까지 한꺼번에 섞인다.

이럴 때 AI가 갑자기 멍청해진 것처럼 보일 수 있다. 사실 모델이 갑자기 나빠졌다기보다, 앞에 쌓인 메모장이 너무 지저분해진 것이다.

Compact는 이 긴 대화를 압축해서 다시 들고 가는 기능이다. 지금까지의 대화를 그대로 계속 끌고 가는 대신, 중요한 결정과 현재 작업 상태만 요약해서 컨텍스트를 줄인다.

 

 

Compact는  /compact 명령으로 쓸 수 있다.

Compact는 컨텍스트가 망가졌을 때만 쓰는 기능은 아니다. 같은 맥락 안에서도 작업과 작업 사이에 한 번 정리해주면 좋다.

예를 들어 한 작업에서 자료를 읽고 방향을 정했다면, 다음 작업으로 넘어가기 전에 Compact를 해두는 편이 낫다. 그래야 AI가 이미 끝난 논의보다 지금부터 필요한 결정과 남은 작업에 집중한다.

Compact 전에 AI에게 이렇게 정리시킬 수는 있다.

"이 대화에서 유지해야 할 결정, 버린 선택지, 아직 남은 작업, 주의할 점만 정리해줘."

그 다음 도구가 지원하는 /compact 명령이나 버튼을 사용하면 된다.

 

Compact가 필요한 순간은 보통 이렇다.

  • 대화가 길어져서 AI가 앞뒤를 헷갈리기 시작할 때
  • 이미 끝난 논점을 AI가 계속 다시 꺼낼 때
  • 여러 번 방향을 틀어서 컨텍스트가 지저분해졌을 때
  • 같은 맥락 안에서 한 작업이 끝나고 다음 작업으로 넘어갈 때
  • 아직 같은 작업을 이어가야 하지만 새 세션으로 옮기기엔 이른 때

다만 Compact도 만능은 아니다. Compact는 긴 대화를 요약해서 계속 쌓는 방식이다. 압축이 반복되면 중요한 디테일이 빠질 수도 있고, 잘못 요약된 내용이 계속 이어질 수도 있다.

그래서 같은 맥락을 유지한 채 다음 작업으로 넘어갈 때는 Compact가 좋고, 작업의 주제 자체가 바뀌었거나 컨텍스트가 너무 망가졌다면 새 세션으로 넘어가는 편이 낫다. 이 차이는 심화의 Handoff에서 다시 다루겠다.

 

하네스

가드레일과 게이트

 

 

가드레일은 AI가 작업 중 지켜야 하는 규칙이다. 게이트는 실제 행동으로 넘어가기 전에 멈춰서 확인하게 만드는 문턱이다.

예를 들어 파일을 수정하는 작업이라면 이런 가드레일을 둘 수 있다.

  • 수정 전에 먼저 파일을 읽는다.
  • 요청받은 범위 밖의 파일은 바꾸지 않는다.
  • 사용자가 이미 수정한 내용을 덮어쓰지 않는다.
  • 수정 후에는 바뀐 파일과 검증 결과를 요약한다.

여기에 게이트를 붙이면 더 강해진다.

  • 여러 파일을 한 번에 바꾸려 하면 먼저 변경 범위를 확인받는다.
  • 삭제나 대량 변경이 있으면 바로 실행하지 않고 멈춘다.
  • 터미널에서 위험한 명령을 실행하려 하면 사용자 확인을 받는다.

이런 규칙은 프롬프트에 직접 써도 되고, 반복해서 쓴다면 CLAUDE.md, AGENTS.md, 업무별 가이드에 적어두면 된다.

실제로는 이렇게 말하면 된다.

"작업 전에 가드레일을 확인해줘. 수정할 파일을 읽었는지, 요청 범위 밖을 건드리는지, 내가 이미 바꾼 내용을 덮어쓸 위험이 있는지 봐줘."
"실행 전에 게이트를 통과하는지 확인해줘. 여러 파일 수정, 삭제, 대량 변경, 위험한 터미널 명령이 있으면 바로 실행하지 말고 나에게 먼저 확인받아."

다만 프롬프트나 가이드에 적어두는 것만으로는 완벽하지 않다. AI는 컨텍스트가 길어지거나 작업이 복잡해지면 이런 규칙도 놓칠 수 있다.

Hook으로 강제하자

 

Hook은 제품이나 회사가 제공하는 자동 실행 지점이다. Codex를 예로 들면 PreToolUse처럼 도구를 실행하기 전에 걸리는 Hook이 있다. 이런 Hook은 터미널 실행, 파일 수정 같은 특정 도구 호출 앞에 붙일 수 있다.

예를 들어 파일 쓰기 도구가 실행되기 전에 Hook을 걸 수 있다면, gate.md를 먼저 읽게 만들 수 있다.

gate.md에는 이런 내용을 적어둔다.

  • 이 파일을 먼저 읽었는가?
  • 요청받은 범위 밖을 수정하는가?
  • 삭제나 대량 변경이 포함되어 있는가?
  • 사용자가 이미 수정한 내용을 덮어쓸 위험이 있는가?
  • 하나라도 걸리면 바로 수정하지 말고 사용자에게 확인받는다.

실제로는 이렇게 요청하면 된다.

"지금 쓰는 Codex에서 파일 쓰기 도구 실행 전 Hook을 지원하는지 확인해줘. 지원한다면 gate.md를 만들고, 파일을 쓰기 전에 그 문서를 확인하게 설정해줘. 게이트에 걸리면 쓰기를 멈추고 나에게 확인받게 해줘."

터미널 실행도 같은 방식이다.

"터미널 명령 실행 전 Hook을 지원하는지 확인해줘. 삭제, 초기화, 배포 같은 위험한 명령은 바로 실행하지 말고 먼저 확인받게 해줘."

핵심은 AI가 규칙을 기억해주길 기대하지 않는 것이다. 중요한 규칙은 프롬프트나 가이드에만 두지 말고, 도구가 실행되는 순간 다시 확인되게 만들어야 한다.

 

 

 

심화

잘 명령하기

Grill-me

Grill-me는 Matt Pocock의 grill-me 스킬에서 가져온 방식이다. 이름 그대로 AI가 사용자를 몰아붙이듯 질문해서, 요청 안에 비어 있는 조건을 찾아내게 한다.

좋은 프롬프트를 쓰려면 내가 원하는 것을 알아야 한다. 그런데 실제로는 내가 뭘 원하는지 나도 잘 모르는 경우가 많다. 이럴 때 AI에게 바로 답을 쓰게 하지 말고, 먼저 나를 캐묻게 만드는 것이다.

 

그냥 위의 스킬 링크를 AI한테 던져주고 grill-me를 설치해달라고 하자. (grill-with-docs가 더 낫지만 차이를 모르겠다면 쉬운거 써라)

저걸 쓰면 AI가 보통 한 20개 내외의 질문 공세를 펼친다. 필요하면 더 요청할 수도 있다.

이 방식의 장점은 내가 놓친 빈칸이 먼저 드러난다는 것이다. AI가 그럴듯한 결과물을 바로 뽑아내는 것보다, 중요한 결정을 하나씩 묻고 확인하는 편이 나중에 덜 흔들린다.

피드백을 받자

AI에게 결과물을 만들게 했다면, 같은 AI에게 바로 "괜찮아?"라고 묻는 것은 약하다.

같은 컨텍스트 안의 AI는 지금까지의 결정과 흐름을 이미 알고 있다. 그래서 틀린 방향으로 간 부분도 "앞에서 그렇게 정했으니까" 하고 자연스럽게 받아들이기 쉽다. 사람도 자기가 쓴 문서를 자기가 보면 오타를 놓치는 것과 비슷하다.

그래서 가능하면 리뷰는 서브에이전트에게 따로 시키는 편이 좋다. 작업한 에이전트가 아니라, 결과물을 처음 보는 리뷰어 역할을 하나 더 세우는 것이다.

 

예를 들어 이렇게 시킬 수 있다.

"서브에이전트에게 이 결과물을 리뷰시켜줘. 작업 맥락을 전부 주지 말고, 결과물과 검토 기준만 넘겨줘. 리뷰어는 이 작업을 처음 보는 사람이라고 가정하고, 빠진 조건, 모순, 실행하기 어려운 부분, 검증되지 않은 가정만 찾아줘."

이때 중요한 것은 리뷰어에게 너무 많은 변명을 주지 않는 것이다. 작업 과정 전체를 다 넘기면 리뷰어도 기존 결정을 따라가게 된다. 결과물, 목표, 완료 기준 정도만 주고 냉정하게 보게 하는 편이 낫다.

서브에이전트를 지원하지 않는 도구라면 새 세션을 열어 같은 방식으로 시킬 수 있다. 핵심은 만든 쪽과 검토하는 쪽의 컨텍스트를 분리하는 것이다.

반복해서 쓰는 리뷰 방식이 있다면 이것도 스킬로 빼둘 수 있다. "초안 검토 스킬", "업무 절차 검토 스킬", "릴리스 체크 스킬"처럼 만들어두면 매번 같은 기준을 다시 설명하지 않아도 된다.

 

컨텍스트를 관리하자

Context Rot

컨텍스트는 길어질수록 썩는다.

처음에는 대화가 길어지는 것이 좋아 보인다. AI가 더 많은 배경을 알게 되고, 이전 결정을 참고할 수 있기 때문이다. 하지만 어느 순간부터는 오래된 결정, 취소한 방향, 중간에 잘못 이해한 내용, 사용자의 짜증 섞인 정정까지 전부 같이 들어간다.

이 상태에서는 CLAUDE.md, AGENTS.md, 업무별 가이드에 좋은 규칙을 적어두어도 AI가 놓칠 수 있다. 가드레일과 게이트도 마찬가지다. 컨텍스트가 길고 복잡하면 AI는 중요한 규칙보다 방금 앞에 나온 말에 끌려갈 수 있다.

Dumb zone

 

Dumb zone은 컨텍스트가 어느 정도 찬 뒤 AI가 갑자기 둔해지는 구간을 말한다. 공식 용어라기보다, 현상을 설명하기 위한 이름에 가깝다.

이 구간에 들어가면 AI는 답을 못 하는 것이 아니라 이상하게 답한다. 말은 길어지는데 핵심을 놓치고, 이미 끝난 논점을 다시 꺼내고, 방금 정한 규칙을 어긴다. 사용자는 "왜 갑자기 멍청해졌지?"라고 느낀다.

이럴 때 프롬프트를 더 세게 쓰는 것만으로는 잘 해결되지 않는다. 정정과 반박이 컨텍스트에 더 쌓이면서 상황이 더 지저분해질 수 있다.

대응은 단순하다. 같은 작업을 이어갈 수 있으면 Compact를 하고, 주제가 바뀌었거나 이미 너무 꼬였으면 Handoff로 새 세션에 넘긴다.

그럼 Dumb zone은 대체 어디서부터 어디냐? 사실 모델마다 다르고 회사마다 다를 수 있다. 나는 개인적으로 컨텍스트가 50% 이상인데 새 작업이면 compact한다. Matt Pocock은 컨텍스트 120k쯤부터 Dumb Zone이라고 보기도 한다.

Handoff

Handoff는 작업을 다른 세션으로 넘기기 위한 인수인계 문서다.

Compact와 비슷해 보이지만 목적이 다르다. Compact는 같은 세션을 계속 쓰기 위해 대화를 압축하는 기능이다. 반면 Handoff는 필요한 정보만 뽑아서 새 세션으로 가져가는 방식이다.

 

Compact가 반복되면 요약의 요약이 계속 쌓인다. 이 과정에서 중요한 디테일이 빠지거나, 잘못 요약된 내용이 계속 이어질 수 있다. Handoff는 그 누적을 끊는다. 새 세션에 필요한 목표, 결정, 현재 상태, 남은 작업, 주의할 점만 들고 간다.

예를 들어 한 세션에서 인쇄 운영 절차를 정리하다가, 중간에 인쇄와 관련된 사내 승인 절차를 따로 조사해야 할 수 있다. 이는 분명 인쇄 운영 절차와 관련이 있지만, 절차 정리와는 관련이 없다. 이럴 때 다른 세션으로 핸드오프 문서를 넘긴다. 그 뒤 그 세션에서 조사가 끝나면 그걸 다시 핸드오프로 만들어서 원래 절차 정리 세션에서 이어갈 수 있다.

다음과 같이 쓸 수 있다.

"이 작업을 새 세션에서 이어갈 수 있게 Handoff 문서를 만들어줘. 목표, 확정된 결정, 버린 선택지, 현재 상태, 남은 작업, 주의할 점만 정리해줘."

이렇게 하면 원래 세션은 한 주제에 집중하고, 새 세션은 필요한 맥락만 들고 별도 작업을 할 수 있다. 나중에 새 세션의 결과가 나오면 다시 요약해서 원래 세션에 가져오면 된다.

 

스킬로 사용하는 것을 추천한다.

2026.05.12 - [AI코딩] - Matt Pocock 신규 스킬 4종

 

작업을 관리하자

Spec 문서를 쓰자

작업이 커질수록 프롬프트 한 번으로 끝내려고 하면 위험하다. AI는 빈칸을 채우는 데 능숙하기 때문에, 요구사항이 비어 있으면 알아서 그럴듯한 결정을 만들어낸다.

그래서 큰 작업은 먼저 Spec 문서로 고정하는 편이 좋다. Spec은 거창한 기획서가 아니라, AI가 멋대로 정하면 안 되는 기준을 적어둔 문서다.

Spec에는 보통 이런 것이 들어간다.

  • 목표: 무엇을 만들거나 해결하려는가
  • 범위: 이번 작업에 포함되는 것과 제외되는 것
  • 완료 기준: 어디까지 되면 끝인가
  • 제약: 반드시 지킬 것과 하지 말아야 할 것
  • 검증 방법: 결과가 맞는지 어떻게 확인할 것인가

이 문서가 있으면 AI에게 "이 Spec을 기준으로 작업해줘"라고 말할 수 있다. 대화가 길어져도 기준점이 남고, 리뷰할 때도 결과물이 Spec을 만족하는지 확인할 수 있다.

SDD(Spec Driven Development)처럼 Spec을 먼저 쓰고 구현으로 들어가는 방식도 같은 맥락이다. SDD는 스펙을 1차 산출물로 두고, 그 스펙을 바탕으로 명확화, 계획, 작업 분할, 구현으로 내려가는 흐름이다.

핵심은 AI에게 바로 달리게 하지 말고, 먼저 기준선을 문서로 세우는 것이다. SDD 자체는 따로 정리해둔 글이 있으니 더 자세한 내용은 스펙 주도 개발 (Spec Driven Development)을 참고하면 된다.

 

HTML로 검토하라

짧은 plan이나 리뷰는 그냥 글로 봐도 된다. 문제는 길어졌을 때다.

AI가 만든 plan, 리뷰, 변경 요약이 길어지면 텍스트만으로는 중요한 부분을 놓치기 쉽다. 항목이 많아질수록 무엇이 결정됐고, 무엇이 위험하고, 무엇을 사람이 확인해야 하는지 한눈에 들어오지 않는다.

이럴 때는 HTML 보고서로 만들어달라고 하는 편이 좋다. HTML은 검토를 대신하는 것이 아니라, 사람이 빠르게 훑고 판단하기 위한 보기 방식이다.

예를 들어 이렇게 시킬 수 있다.

"이 plan을 검토용 HTML 보고서로 만들어줘. 결정된 것, 위험한 것, 사람이 확인해야 할 것, 다음 작업을 나눠서 보여줘."
"이 리뷰 결과를 HTML로 정리해줘. 파일명, 줄 번호, 근거, 수정 우선순위를 표로 볼 수 있게 해줘."

표, 섹션, 체크리스트로 나뉘어 있으면 긴 글을 처음부터 끝까지 읽는 것보다 빠르게 피드백할 수 있다. 피드백 속도가 곧 작업 속도다.

Vertical Layer

AI에게 큰 작업을 맡길 때 흔한 실수는 작업을 수평으로 나누는 것이다.

 

예를 들어 간단한 게임을 만든다고 해보자. 수평으로 나누면 이렇게 된다.

  • 전투 시스템 만들기
  • UI 만들기
  • 로그인과 저장 만들기
  • 몬스터 스폰 만들기

겉보기에는 깔끔하지만, 문제는 검증이 늦어진다는 것이다. 전투만 따로 만들고, UI만 따로 만들고, 저장만 따로 만들면 한참 뒤에야 전체가 맞물리는지 알 수 있다.

Vertical Layer는 기능별로 자르는 대신, 작지만 끝까지 이어지는 검증 단위로 자르는 것이다.

  • 로그인해서 캐릭터와 몬스터가 한 마리씩 보이는지 확인한다.
  • 캐릭터가 몬스터 한 마리를 공격하고, 결과 UI가 뜨는지 확인한다.
  • 몬스터가 자동으로 다시 나오고, 전투 결과가 저장되는지 확인한다.

이런 작은 세로 조각을 Tracer Bullet처럼 먼저 쏴보는 것이 좋다. 완성도는 낮아도 처음부터 끝까지 흐름이 이어지면, 실제로 동작하는지 바로 검증할 수 있다.

AI 작업도 마찬가지다. 큰 덩어리를 한 번에 맡기기보다, 사람이 빠르게 확인할 수 있는 세로 단위로 쪼개야 한다. 피드백 속도가 느리면 AI가 아무리 빨리 만들어도 전체 속도는 느려진다.

 

 

마무리

사실 위에 언급 한 것들은 오푸스 5.0같은 게 나오면서 다 내장될 수도 있다. 

가령 양산형 AI유튜버들이 안드레 카파시의 claude.md 스킬이 어쩌구 하지만 사실 대부분의 내용은 이미 최신의 codex나 claude가 내장하고 있다. (모르는 것을 추측해서 진행하지 마라 등)

그럼에도 불구하고, 오푸스 10.0이 나와도 AI는 우리의 생각을 추측할 수 없을 것이다. (뇌를 스캔하지 않는 이상)

결국 시간이 흘러도 남는 것은 의도를 명확히 하는 것(grill-me, 좋은 spec문서), 중간중간 검증을 하는 것(Vertical Layer)이다.

프로그래밍 용어로 소프트웨어 엔트로피 라는 개념이 있다. 이건 깨진 유리창 이론과도 비슷하다. 유리창이 깨져 있는 상태에서 AI한테 일을 시키면 깨진 유리창이 점점 늘고 작업이 산으로 간다. 

 

내가 좋아하는 Mattpocock이 강의에서 한 좋은 말이 있다.

...rate of feedback is your speed limit.

 

그러니 자주 feedback하라. 위에서 언급한 'HTML로 검토하라'는 이런 면에서 좋다. (곧 양산형 유튜버들이 엄청 언급할 것이다.) 작업 계획 리뷰부터 작업 결과물 리뷰까지 좀 길어진다 싶으면 html보고서로 생성해서 읽어라. feedback rate가 크게 증가한다.

 

프로그래머라면 https://tsyang.tistory.com/232 봐라

 

 

'AI코딩' 카테고리의 다른 글

Matt Pocock 신규 스킬 4종  (0) 2026.05.12
결국 기초가 중요하다 - Matt Pocock 강의  (0) 2026.05.06
하네스 엔지니어링  (0) 2026.04.14
2026 에이전틱 코딩 트랜드 리포트 by Anthropic  (0) 2026.03.04
스펙 주도 개발 (Spec Driven Development, SDD)  (1) 2026.03.02