AI에게 구현을 부탁했더니, 뭔가 다른 것이 돌아왔다.

AI에게 조사를 부탁했더니, 정보는 많지만 결국 무엇을 믿어야 할지 모르겠다.

AI에게 리뷰를 부탁했더니, 세세한 지적은 나오지만 프로덕트로서 정말 중요한 부분을 봐주지 않는다.

이것은 AI가 약하다기보다, 전달하고 있는 문맥(Context)이 옅기 때문인 경우가 많습니다.

최근의 AI 개발 도구는 이제 '코드 파일을 1개 생성하는 도구'가 아니게 되었습니다. Codex는 개발 라이프사이클(Development Lifecycle) 전체, PR 리뷰, 여러 파일, 터미널, 브라우저, 메모리, 스케줄 실행과 같은 방향으로 확장되고 있습니다. GitHub Copilot cloud agent도 GitHub, IDE, CLI, MCP, Slack, Jira 등 여러 입구로부터 작업을 시작할 수 있게 되었습니다. MCP는 AI 앱을 외부 도구나 데이터 소스에 연결하는 표준으로서 확산되고 있습니다.

즉, AI가 할 수 있는 일이 늘어났습니다.

하지만 할 수 있는 일이 늘어날수록, 대충 맡겼을 때 발생하는 괴리도 커집니다.

그래서 중요해지는 것이 이 기사에서 말하는 컨텍스트 패킷 (Context Packet) 입니다.

컨텍스트 패킷은 AI에게 작업을 맡기기 전에 전달하는 '작은 설계서'입니다. Issue 본문, PR 설명, AI에게 보내는 의뢰문, 운영 로그 등 어디에 두어도 상관없지만, 최소한 다음 7가지는 포함합니다.

• 목적
• 배경
• 제약 사항
• 이용 가능한 도구
• 권한 경계
• 합격 조건
• 리뷰 관점

솔직히 말해서, 이것뿐입니다.

하지만 신기하게도, 이것만으로 AI 작업의 안정감이 상당히 달라집니다.

프롬프트(Prompt)의 말투를 다듬는 것도 중요합니다. 하지만 그보다 앞서 있는 것은 「AI가 판단하기 위한 재료를 얼마나 정성스럽게 전달할 수 있는가」 입니다.

갑자기 Context Engineering이라거나 MCP, Memory 같은 말이 나오면 조금 긴장되실 겁니다.

그래서 먼저 아주 쉽게 풀어서 설명하겠습니다.

Context Engineering은 AI에게 전달할 문맥을 설계하는 것입니다. 프롬프트 엔지니어링(Prompt Engineering)이 '어떻게 말할 것인가'라면, Context Engineering은 '무엇을 전달할 것인가', '어떤 순서로 전달할 것인가', '무엇을 전달하지 않을 것인가'까지 포함합니다.

MCP는 AI가 외부 도구나 데이터에 접속하기 위한 공통 규격입니다. 대략 말하자면 AI에게 있어 USB-C 같은 것입니다. 파일, DB, 검색, 사내 도구, 디자인 도구 등에 비슷한 방식으로 쉽게 연결하기 위한 메커니즘입니다.

Memory는 AI가 이전까지의 취향, 판단, 프로젝트 지식을 기억하여 다음에 활용하는 메커니즘입니다. 다만, 무엇이든 기억시킨다고 좋은 것은 아닙니다. 오래된 정보나 잘못된 정보를 기억하면 오히려 판단이 흐려집니다.

Browser Automation은 AI가 브라우저를 보고, 클릭하고, 입력하고, 확인하는 등의 자동 조작입니다. 프론트엔드 확인이나 관리 화면 조작에는 편리하지만, 로그인, 권한, 공개, 삭제와 같은 조작이 얽히면 단번에 신중함이 필요해집니다.

여기서 중요한 것은 AI가 강해질수록 인간의 일이 줄어든다기보다, 인간이 설계하는 것이 변한다는 점입니다.

예전에는 '구현 절차'를 인간이 전부 생각했습니다.

앞으로는 AI가 움직일 수 있도록,

• 무엇이 목표인가
• 무엇을 건드려도 되는가
• 무엇을 건드리면 안 되는가
• 어떻게 되어야 성공인가
• 어디를 인간이 확인할 것인가

를 설계하는 비중이 늘어날 것입니다.

구현자에서 문맥 설계자로.

다소 거창하게 들릴 수도 있겠지만, 일상의 Issue나 PR에 적용하면 상당히 현실적인 이야기입니다.

우선 템플릿을 배치하겠습니다.

## Context Packet
### 1. 목적
무엇을 달성하고 싶은가.
...

이것을 매번 처음부터 완벽하게 쓸 필요는 없습니다.

처음에는 3분이면 충분합니다.

예를 들어, AI에게 "검색 기능을 고쳐줘"라고 말하는 대신, 이렇게 전달합니다.

## Context Packet
### 1. 목적
상품 목록 화면의 검색에서, 키워드 입력 후 결과가 0건이 되는 결함을 수정한다.
...

이 정도의 입도(Granularity)라면 AI는 상당히 움직이기 쉬워집니다.

"검색 고쳐줘"라고 하면 AI는 어디까지 바꿔도 되는지 알 수 없습니다. API를 바꿔도 되는지, UI를 바꿔도 되는지, 테스트를 추가해도 되는지, 운영 데이터에 접근해도 되는지도 모호합니다.

모호함은 AI에게 자유가 아니라 노이즈(Noise)입니다.

인간도 마찬가지죠. 배경도 제약도 없는 상태에서 "적당히 고쳐놔"라는 말을 들으면 참 난감합니다.

AI도 마찬가지입니다.

이 부분을 나누어 두면 AI 활용이 상당히 안정화됩니다.

AI에게 맡길수록 인간은 편해진다.

이것은 절반은 맞습니다.

하지만 나머지 절반은 "인간의 판단이 더 상류(Upstream)로 이동한다"입니다.

AI가 구현(Implementation)을 빠르게 한다면, 인간은 무엇을 구현해야 하는지를 정성스럽게 결정해야 합니다.

AI가 리뷰(Review)를 빠르게 한다면, 인간은 무엇을 품질이라고 부를 것인지를 결정해야 합니다.

AI가 브라우저나 MCP를 통해 외부 도구를 조작할 수 있다면, 인간은 어디까지 허용할 것인지를 결정해야 합니다.

이 부분을 대충 넘기면, AI의 속도가 그대로 사고의 속도가 됩니다.

먼저 조사입니다.

조사는 "조사해줘"라고만 하면 정보가 너무 넓게 퍼집니다. 처음에 무엇을 의사결정하고 싶은지를 전달하는 것이 요령입니다.

당신은 개발 팀의 기술 조사 담당자입니다.
다음 Context Packet을 전제로, 채택 판단에 필요한 정보만 정리해 주세요.
## 목적
...

포인트는 "정보를 모아줘"가 아니라, 판단 재료로 변환해줘라고 의뢰하는 부분입니다.

AI에게 조사를 맡길 때, 인간이 설계하는 것은 검색 키워드가 아니라 의사결정의 형태입니다.

다음은 구현입니다.

여기서는 작업 범위와 금지 사항을 명확히 합니다.

당신은 이 리포지토리(Repository)의 구현 담당자입니다.
## 목적
사용자 목록 API에 `status` 필터를 추가해 주세요.
...

이렇게까지 작성하면, AI는 "어디까지 건드려도 되는지"를 상당히 판단하기 쉬워집니다.

반대로 이곳을 작성하지 않으면, AI는 좋은 의도로 DB 스키마(Schema)를 바꾸거나, 응답 형식을 정리하거나, 인증 처리까지 리팩터링(Refactoring)해 버립니다.

악의는 없습니다.

하지만 현장에서는 곤란합니다.

그래서 컨텍스트 패킷(Context Packet)으로 좋은 변경의 범위를 미리 결정하는 것입니다.

AI 리뷰는 편리하지만, 단순히 "리뷰해줘"라고만 하면 내용이 얕아지기 쉽습니다.

리뷰에도 컨텍스트(Context)가 필요합니다.

당신은 시니어 엔지니어로서 이 PR을 리뷰해 주세요.
## 이 PR의 목적
CSV 임포트 시의 유효성 검사(Validation)를 강화하고, 에러 행을 UI에서 확인할 수 있도록 한다.
...

리뷰에서 중요한 것은 AI에게 "무엇을 중대하게 간주할 것인가"를 전달하는 것입니다.

같은 차이(Diff)라도 보안 중시 리뷰, UX 중시 리뷰, 성능 중시 리뷰에 따라 보는 지점이 달라집니다.

인간의 리뷰도 마찬가지죠.

AI 리뷰도 같습니다.

팀에서 사용한다면 Issue나 Markdown에 최소 항목이 들어있는지를 기계적으로 체크하면 편리합니다.

예를 들어, context-packet.md를 검사하는 작은 Node.js 스크립트입니다.

// validate-context-packet.js
import fs from "node:fs";
const file = process.argv[2];
...

사용법은 다음과 같습니다.

node validate-context-packet.js context-packet.md

이것만으로도 팀의 AI 의뢰 수준이 상당히 통일됩니다.

물론 제목이 있다고 해서 내용까지 반드시 좋으리라는 법은 없습니다. 하지만 최소한의 형식이 없는 의뢰를 줄이는 것만으로도 효과는 있습니다.

인간의 리뷰 전에, AI에게 전달할 문맥(Context)을 리뷰한다.

이 발상은 꽤 중요합니다.

AI에게 전달하는 문맥에는 비밀 정보나 개인 정보를 넣지 않는 것이 기본입니다.

또 하나 은근히 중요한 것이 글자 깨짐(Character encoding error) 체크입니다. 특히 자동 게시나 브라우저 붙여넣기를 포함하는 경우, 일본어(또는 한국어)가 깨져 있으면 신뢰가 순식간에 떨어집니다.

이것은 간이 체크 예시입니다.

// safety-check-markdown.js
import fs from "node:fs";
const file = process.argv[2];
...

사용법입니다.

node safety-check-markdown.js context-packet.md

이것은 완벽한 보안 도구는 아닙니다.

하지만 아무것도 없는 것보다는 훨씬 낫습니다.

AI 활용은 "빠르게 만들기" 방향으로 의식이 쏠리기 쉽지만, 실무에서는 빠르게 하기 전에, 유출하지 않고, 망가뜨리지 않고, 공개하지 않는 것이 필요합니다.

특히 MCP나 브라우저 조작을 통해 외부 도구와 연결하는 경우, AI가 접촉하는 범위는 넓어집니다. 그렇기 때문에 컨텍스트 패킷(Context Packet)에는 권한 경계(Permission Boundary)를 넣어두어야 합니다.

맡기기 전에, 가두는 것.

이 순서가 중요하다고 생각합니다.

AI 에이전트가 로컬 파일, GitHub, Slack, Jira, Notion, 브라우저, DB에 접근할 수 있게 되면 편리함은 단번에 올라갑니다.

하지만 편리함과 위험성은 대개 같은 방향으로 커집니다.

따라서 권한 경계를 표로 만들어 두는 것이 좋습니다.

이 표는 회사나 프로덕트에 따라 변경해 주세요.

중요한 것은 AI에게 "상식적으로 판단해 줘"라고 말하지 않는 것입니다.

상식은 사람마다 다릅니다. AI에게도 모호합니다.

그러니까, 먼저 표로 만듭니다.

이것이 팀에서 AI를 사용할 때의 최소한의 가드레일(Guardrail)이 됩니다.

컨텍스트 패킷은 한 번의 요청으로 끝나지 않습니다.

작업 후에 운영 로그(Operation Log)로 남기면 더욱 강력해집니다.

## AI Work Log
### 요청 내용
사용자 목록 API에 status 필터 추가.
...

이 로그가 있으면 다음 AI 요청이 쉬워집니다.

왜냐하면 과거의 판단을 매번 설명할 필요가 없기 때문입니다.

메모리(Memory)에 넣든, 문서로 남기든, 중요한 것은 "판단의 이유"를 남기는 것입니다.

코드는 보면 알 수 있는 것도 있습니다.

하지만 왜 그런 설계를 했는지, 왜 이번에는 하지 않았는지, 어떤 리스크를 허용했는지는 코드만으로는 알기 어렵습니다.

AI에게 인계해야 할 것은 코드 그 자체뿐만 아니라, 판단의 이력입니다.

여기까지 읽으면 제대로 운영해야 한다는 생각에 조금 무겁게 느껴질지도 모릅니다.

하지만 처음에는 이슈(Issue) 템플릿에 이것을 넣는 것만으로도 충분합니다.

## Context Packet
### 목적
### 배경
...

매번 전부 채우지 못해도 괜찮습니다.

빈칸이 보이는 것만으로도 "아, 이 부분이 모호하구나"라고 깨달을 수 있습니다.

이 깨달음이 큽니다.

AI에게 전달하기 전에, 인간 측의 모호함이 보이기 때문입니다.

AI 활용을 잘하는 사람은 마법의 프롬프트(Prompt)를 알고 있는 사람이 아니라는 생각이 듭니다.

오히려 AI에게 전달하기 전에,

• 목적을 언어화하기
• 제약 사항 찾기
• 금지 사항 결정하기
• 합격/불합격 조건 작성하기
• 마지막에 인간이 판단할 지점 남겨두기

이 지루한 작업을 할 수 있는 사람입니다.

지루하지만, 효과적입니다.

AI 개발의 주전장은 조금씩 변하고 있습니다.

코드를 쓰는 속도뿐만 아니라, AI가 안전하고 정확하게 팀의 의도에 따라 움직일 수 있도록 만드는 능력이 중요해지고 있습니다.

이를 위한 작은 틀이 바로 이 글에서 소개한 컨텍스트 패킷입니다.

다시 한번, 7가지 항목을 적어둡니다.

• 목적
• 배경
• 제약 사항
• 이용 가능한 도구
• 권한 경계
• 합격/불합격 조건
• 리뷰 관점

AI에게 무엇을 맡길지 생각하기 전에, AI에게 무엇을 전달할지 생각하세요.

AI에게 어디까지 시킬지 생각하기 전에, AI에게 무엇을 시키지 않을지 결정하세요.

이 순서만 지켜도 AI 개발은 상당히 현실적이 됩니다.

인간의 일은 없어진다기보다, 조금 더 상류(Upstream)로 이동합니다.

구현만을 담당하는 사람에서, 문맥을 설계하고 판단하며 평가하는 사람으로.

이것이 AI 시대의 엔지니어에게 매우 중요한 변화가 아닐까 생각합니다.

내일의 자신이나 팀이 "그때 제대로 써줘서 도움이 됐어"라고 생각할 수 있는 Context Packet을, 우선 딱 하나만 이슈에 붙여보세요.

그 정도의 작은 발걸음이면 충분합니다.