이 시리즈의 지난 포스트는 AI에게 무엇을 제공하지 말아야 하는지에 관한 것이었습니다: 프롬프트에 비밀을 노출하지 마세요.

이번 포스트는 동전의 다른 면입니다. AI를 안전하게 사용하기 시작했다면, 어떻게 사용해야 오후 내내 수정하느라 시간을 허비하게 만드는 '자신감 넘치고 그럴듯한 쓰레기'를 생성하는 대신 실제로 당신의 결과물을 배가시킬 수 있을까요?

이 도구들을 사용하여 많은 코드를 배포해 본 결과, 저의 결론은 지루하지만 핵심적인 것입니다. "AI가 도움이 되는 경우"와 "AI가 방해가 되는 경우" 사이의 격차는 거의 모델 때문이 아닙니다. 그것은 바로 당신이 제공하는 컨텍스트 (Context) 입니다. 중요한 기술은 영리한 프롬프트 (Prompt)를 작성하는 것이 아닙니다. 당연한 프롬프트가 올바른 답을 내놓을 수 있도록 컨텍스트를 엔지니어링 (Engineering) 하는 것입니다.

실패 모드: 느낌 기반의 프롬프팅 (vibes-based prompting)

대부분의 사람들이 빠져 있는 루프는 다음과 같습니다. 한 문장으로 무언가를 요청하면, 맞는 것처럼 보이는 코드가 돌아옵니다. 하지만 곧 당신이 사용하지 않는 라이브러리를 사용했거나, 당신의 컨벤션 (Convention)에 어긋나는 이름을 붙였거나, 지난주에 수정했던 버그를 다시 불러왔다는 사실을 깨닫게 됩니다. 그래서 코드를 다시 작성하게 되고, 다음 작업은 다시 제로 베이스에서 시작됩니다.

컨텍스트가 없는 AI는 당신의 코드베이스 (Codebase)를 읽어본 적도 없고 어제의 일도 기억하지 못하는 똑똑한 주니어 개발자와 같습니다. 당신은 그런 사람에게 한 줄짜리 티켓을 건네주며 바로 머지 (Merge) 가능한 PR을 기대하지는 않을 것입니다. 해결책은 더 똑똑한 주니어를 찾는 것이 아닙니다. 바로 온보딩 문서 (Onboarding doc) 입니다.

컨텍스트 엔지니어링: 프로젝트 메모리 파일

제가 하는 일 중 가장 레버리지가 높은 단 한 가지는 레포지토리 (Repo) 안에 프로젝트 메모리 파일을 유지하는 것입니다. 이는 현재 대부분의 에이전틱 도구 (Agentic tools)들이 자동으로 읽어들이는 종류의 파일입니다. 이것은 온보딩 문서와 같지만, 신입 사원과 달리 매번 완벽하게 읽어낸다는 점이 다릅니다.

여기에 들어가는 내용은 일반적인 스타일 조언이 아닙니다. 외부인은 결코 추측할 수 없는, 프로젝트 특유의 고생 끝에 얻은 정보들입니다. 이 사이트에서 가져온 몇 가지 대표적인 항목들을 요약하면 다음과 같습니다:

• 타협 불가능한 사항들 (Non-negotiables). Canonical URL은 항상 프로덕션 호스트를 가리켜야 합니다. 포스트 슬러그(post slugs)는 실제 URL과 정확히 일치해야 합니다. 하나라도 바뀌면 순위가 매겨진 페이지가 깨지기 때문입니다.
• 하드코딩하지 말고 계산할 것 (Computed, never hardcoded). 수년간의 경험을 통해 얻은 교훈은, 시작 날짜를 하나의 설정 파일에 두고 절대 어디에도 리터럴 숫자(literal number)로 직접 쓰지 않는 것입니다.
• 반나절을 허비하게 만드는 함정들 (The gotchas that cost an afternoon). CDN의 특정 엣지 설정 하나를 반드시 꺼두어야 하며, 그렇지 않으면 JavaScript가 조용히 작동을 멈춥니다. 콘텐츠 설정은 반드시 정확히 지정된 하나의 경로에 있어야 하며, 그렇지 않으면 프레임워크가 이를 거부합니다.

그 파일에 담긴 모든 줄은 한 번 발생했던 실수를 기록한 것이며, 이제는 구조적으로 그런 실수가 다시 발생하지 않도록 방지합니다. 이것이 핵심입니다. 그 파일은 _복리로 쌓이는 자산 (compounding asset)_입니다. 저장소(repo)가 어시스턴트(assistant)를 가르치기 때문에, 저는 똑같은 다섯 가지 사항을 반복해서 설명할 필요가 없으며, 첫 번째 초안의 품질은 매 세션마다 초기화되는 대신 시간이 지남에 따라 향상됩니다.

중요한 루프는 되돌아오는 피드백 루프(dotted-back edge)입니다. 모델이 반복될 가능성이 있는 방식으로 무언가를 틀렸을 때, 해결책은 단순히 이번 출력값을 수정하는 것이 아닙니다. 컨텍스트 파일(context file)에 한 줄을 추가하여 해당 유형의 실수 자체를 없애버리는 것입니다.

메타 프롬프팅 (Meta-prompting): AI에게 자신의 지침을 가리키게 하기

두 번째 습관은 AI를 자신의 설정에 사용하는 것입니다. 제가 의존하는 몇 가지 방법은 다음과 같습니다:

• 코드로부터 컨텍스트 파일을 부트스트랩(Bootstrap)하기. 모델에게 프로젝트를 읽고 메모리 파일(memory file)의 초안을 작성하도록 요청한 다음, 이를 편집하여 줄여나갑니다. 모델은 저보다 관례(conventions)를 목록화하는 속도가 더 빠르며, 최종적인 판단은 제가 내립니다.
• 먼저 작업을 재진술하게 하기. 사소하지 않은 작업에 대해서는, 실행하기 전에 자신이 무엇을 하려는지 요약해 달라고 요청합니다. 잘못된 출력의 절반은 코드가 작성되기도 전, 바로 그 재진술 단계에서 걸러집니다.
• 프롬프트를 개선해 달라고 요청하기. "내가 방금 요청한 것 중 모호한 부분이 무엇인가요?"라고 묻는 것이 원래 질문에 대한 답을 얻는 것보다 훨씬 더 유용할 때가 많습니다.

이 중 어느 것도 특정 제품에 국한되지 않습니다. 저는 작업에 따라 터미널의 에이전트형 CLI (agentic CLI), 일회성 질문 및 러버덕 디버깅 (rubber-ducking)을 위한 브라우저 채팅, 그리고 인라인 에디터 완성 (inline editor completions) 사이를 오갑니다. 도구는 몇 달마다 바뀝니다. 하지만 컨텍스트를 설계하고 암시적인 것을 명시적으로 만드는 것이라는 원칙은 변하지 않습니다.

도움이 되는 부분과 그렇지 않은 부분

경계를 솔직하게 인정하는 것이 이것이 과장된 광고 (hype)가 되지 않게 만드는 핵심입니다. 도구는 어떤 작업에는 생산성 증폭기 (force multiplier) 역할을 하지만, 나머지 작업에는 오히려 부담 (liability)이 됩니다.

AI를 활용할 부분	사람이 직접 할 부분
보일러플레이트 (Boilerplate) 및 스캐폴딩 (scaffolding)	새로운 아키텍처 결정
...

기계적인 작업 (mechanical-sweep) 행은 가설이 아닙니다. 이 사이트의 모든 페이지에서 특정 문장 부호를 제거하기 위해 수십 개의 파일을 몇 분 만에 수정했던 작업은, 바로 이러한 도구들이 만들어진 목적에 부합하는 지루하고, 명확하게 정의되었으며, 판단력이 크게 필요하지 않은 작업의 전형입니다. 사이트의 아키텍처는 그렇지 않습니다.

워크플로우 루프 (The workflow loop)

이 모든 것을 하나로 묶어주는 규율은 작고 화려하지 않습니다:

1. 작업 범위를 작게 설정하세요. "기능을 구축하라"가 아니라, 완료 정의 (definition of done)가 명확한 하나의 변경 사항으로 범위를 좁히세요.
2. 처음에 컨텍스트를 제공하세요, 또는 메모리 파일 (memory file)이 이를 수행하도록 신뢰하세요.
3. 모든 출력물을 검증하세요. 빌드를 실행하고, 프리뷰를 열고, 차이점 (diff)을 읽으세요. 4초 만에 나온 답변이라도 당신이 직접 작성한 코드와 동일한 기준을 통과해야 합니다.
4. 주니어의 PR (Pull Request)을 검토하듯 검토하세요. 왜냐นั้น 실제로 그렇기 때문입니다. 이는 비밀 유출 관련 포스트에서 언급한 것과 동일한 습관입니다. 모델이 생성한 것은 사람이 읽기 전까지 커밋 (commit), 로그 (log), 또는 PR에 포함되어서는 안 됩니다.
5. 교훈을 컨텍스트 파일에 다시 피드백하세요. 그래야 다음 초안이 더 높은 수준에서 시작될 수 있습니다.

저는 다른 곳에서 이 사이트의 전체 구축 과정에 대해 쓴 적이 있는데, 그 과정의 상당 부분이 정확히 이 루프를 통해 진행되었습니다.

보상 (The payoff)

레버리지(leverage)는 제가 입력한 프롬프트에 있었던 것이 아닙니다. 그것은 제가 유지하는 컨텍스트(context)에 있었습니다. 도구가 읽을 수 있는 곳에 컨벤션(conventions)과 흔적(scars)이 기록된, 잘 도구화된(well-instrumented) 저장소(repo)는 AI를 그럴듯한 코드를 생성하는 도구에서 실제로 적합한 결과물을 배포(ship)하는 존재로 탈바꿈시킵니다.

그리고 지난 포스트의 보안 워크플로우(secure workflow)와 이번 포스트의 고효율 워크플로우(high-output workflow)가 동일한 워크플로우라는 점에 주목하십시오. 범위를 엄격히 제한하고(scoping tightly), 비밀 정보(secrets)를 제외하며, 모든 출력물을 검토하고, 중요한 것을 기록하는 것: 그러한 규율(discipline)이 AI를 안전하면서도 사용할 가치가 있게 만듭니다.

매너 있게, 안전하게, 더 많이 배포하십시오.