컨텍스트 예산표: 많이 넣기 전에 버릴 것 표시

2026년 5월 7일 | 바이브코딩 Tips

---

긴 컨텍스트 모델을 쓰기 시작하면 코딩 에이전트에게 더 많이 보여 주는 일이 자연스러운 기본값처럼 느껴진다. 나도 처음에는 저장소 설명, 이슈 원문, 실패 로그, 관련 문서, 예전 대화까지 한 번에 넣으면 모델이 덜 헤맬 거라고 생각했다. 그런데 실제로 굴려 보면 문제는 정보 부족만이 아니었다. 너무 많은 맥락이 같은 중요도로 들어갈 때 에이전트는 무엇을 기준으로 움직여야 하는지 자주 놓친다.

그래서 요즘 코딩 에이전트에게 일을 넘길 때는 큰 프롬프트를 쓰기 전에 작은 컨텍스트 예산표를 먼저 적는다. 이름은 거창하지만 내용은 단순하다. 지금 반드시 넣을 자료, 참고만 시킬 자료, 아직 열지 않을 자료, 아예 섞으면 안 되는 자료를 네 칸으로 나누는 것이다. 이걸 해두면 토큰을 아끼는 것보다 더 중요한 효과가 생긴다. 에이전트가 엉뚱한 과거 로그나 비슷한 파일명에 끌려가는 일이 줄어든다.

1. 컨텍스트는 양보다 권한에 가깝다

프롬프트에 어떤 파일을 넣는다는 건 단순히 정보를 제공하는 일이 아니다. 나는 그 자료를 이번 작업의 판단 근거로 써도 된다는 신호를 같이 보내는 셈이다. 예를 들어 오래된 에러 로그를 붙이면 에이전트는 그 로그를 현재 증상으로 착각할 수 있고, 예전 설계 메모를 붙이면 이미 폐기한 방향을 다시 살릴 수 있다. 그래서 컨텍스트 관리는 많이 넣는 기술보다 근거로 삼아도 되는 범위를 좁히는 기술에 더 가깝다.

특히 바이브코딩에서는 이 차이가 더 크게 보인다. 사람이 코드를 한 줄씩 지시하는 대신 에이전트가 읽고, 고치고, 테스트하고, 다시 설명하는 루프를 돈다. 이 루프 안에서는 처음 넣은 자료가 계속 관성처럼 남는다. 첫 입력에 잘못된 참고 자료가 섞이면 뒤에서 아무리 “그건 참고만 해”라고 말해도 이미 수정 방향이 기울어져 있는 경우가 많았다.

Figure 1: 작업 전에 입력 자료를 필수·참고·보류·금지 네 칸으로 나누는 컨텍스트 예산표

위 도식에서 내가 제일 자주 쓰는 칸은 사실 필수 입력보다 보류 입력과 금지/폐기 쪽이다. 필수 자료는 대개 눈에 잘 띈다. 지금 고칠 파일, 실패한 테스트, 사용자가 원하는 최종 상태는 자연스럽게 프롬프트에 들어간다. 반대로 애매한 자료는 “혹시 필요할 수도 있으니 일단 넣자”로 흘러 들어오기 쉽다. 그 애매함을 별도 칸으로 빼두면, 에이전트가 먼저 확인해야 할 질문도 같이 드러난다.

2. 내가 쓰는 네 칸

컨텍스트 예산표는 문서가 길 필요가 없다. 보통은 작업 시작 전에 3분 정도만 써도 충분하다. 핵심은 자료를 예쁘게 정리하기보다 어떤 자료가 이번 실행의 근거가 되는지를 분리하는 데 있다.

칸	내가 묻는 질문	에이전트에게 주는 방식
필수 입력	이게 없으면 작업이 틀어지는가?	처음 프롬프트에 직접 넣고, 수정 근거로 사용 허용
참고 입력	방향 이해에는 좋지만 매번 붙일 필요가 있는가?	짧은 요약만 제공하고, 원문은 요청 시 열기
보류 입력	필요 여부를 먼저 확인해야 하는가?	승격 조건을 적고, 바로 주입하지 않기
금지/폐기	비슷하지만 다른 문제를 끌고 오지는 않는가?	프롬프트에 명시적으로 제외하거나 아예 빼기

이 표를 쓰기 전에는 참고 자료와 필수 자료가 자주 섞였다. 예를 들어 “예전에 비슷한 버그가 있었다”는 말은 도움이 될 수도 있지만, 지금 버그의 원인을 바로 가리키는 근거는 아닐 수 있다. 그런 자료는 참고 입력으로 짧게 남기고, 같은 증상이 재현될 때만 원문을 열게 하는 편이 안전했다.

3. 보류 칸이 작업을 느리게 하지 않는 이유

처음에는 보류 칸을 만들면 작업이 느려질 줄 알았다. 그런데 실제로는 반대에 가까웠다. 에이전트가 한 번 잘못된 자료를 근거로 잡으면, 그 뒤에는 수정 diff를 되돌리고 설명을 다시 맞추느라 더 오래 걸린다. 보류 칸은 실행을 미루는 장치보다 근거 승격 조건을 남기는 장치에 가깝다.

예를 들어 “이전 릴리스의 migration notes”가 있다면 바로 전체를 붙이지 않는다. 대신 “새 에러가 migration 경고와 같은 함수명을 가리킬 때만 열기”라고 적어 둔다. 그러면 에이전트는 처음부터 과거 문서를 현재 정답처럼 취급하지 않고, 필요한 조건이 생겼을 때만 자료를 승격한다. 이 작은 차이가 긴 세션에서 꽤 크게 작동한다.

이 방식은 컨텍스트 압축과도 조금 다르다. 압축은 같은 자료를 더 짧게 보여 주는 기술에 가깝다. 컨텍스트 예산표는 그 전에 그 자료를 이번 판단에 참여시킬지부터 정한다. 줄여서 넣을 자료와 아예 넣지 않을 자료를 먼저 가르기 때문에, 모델이 “짧아진 노이즈”를 더 확신 있게 믿는 상황을 줄일 수 있다.

나는 이 구분을 해두면 에이전트에게 더 차갑게 지시하게 된다. “이 문서는 참고만 해”, “이 로그는 같은 status code가 재현될 때만 열어”, “이 diff는 이미 버린 방향이니 근거로 쓰지 마”처럼 자료의 등급을 같이 말하게 되기 때문이다. 말투는 단순하지만 효과는 꽤 현실적이다. 에이전트가 똑같이 많은 파일을 읽더라도, 무엇을 판단 근거로 승격할지 덜 헷갈린다.

4. 내가 실제로 붙이는 짧은 양식

나는 긴 문서 대신 아래처럼 아주 짧은 형태로 붙인다. 중요한 건 문장 완성도보다 칸의 역할이다. 특히 금지/폐기 칸은 에이전트에게 “이 자료는 참고하지 마라”는 부정 정보를 준다. 이 부정 정보가 없으면 모델은 비슷한 이름의 파일이나 예전 로그를 좋은 힌트처럼 다시 꺼내는 경우가 있다.

목표: 결제 실패 재시도 로직에서 중복 요청을 줄인다.

필수 입력:
- 현재 실패 테스트 이름 2개
- 수정 대상 파일 1개
- 기대 동작: 같은 주문 ID는 한 번만 재시도

참고 입력:
- 예전 장애 회고 요약 3줄
- API rate limit 문서 링크

보류 입력:
- migration notes 원문: 같은 함수명이 다시 나오면 열기
- 오래된 로그: 현재 테스트에서 같은 status code가 나오면 열기

금지/폐기:
- 4월 임시 패치 diff는 이미 revert됨
- sandbox 전용 mock 설정은 production 판단 근거로 쓰지 않기

이 정도만 적어도 작업 방향이 꽤 달라진다. 에이전트는 필수 입력에서 바로 시작하고, 참고 입력은 배경으로만 취급하며, 보류 입력을 무작정 근거로 쓰지 않는다. 사람 입장에서도 나중에 세션을 다시 열었을 때 왜 어떤 자료를 넣지 않았는지 기억하기 쉽다.

5. handoff와 종료 체크에도 그대로 이어지기

컨텍스트 예산표를 작업 시작에만 쓰면 절반만 쓴 것이다. 나는 종료 시점에도 같은 칸을 다시 본다. 작업 중 보류 입력이 실제로 승격됐는지, 금지/폐기 칸을 어겼는지, 참고 입력이 어느 순간 필수 근거처럼 쓰이지 않았는지를 확인한다. 이건 별도 회고라기보다 작업 전 계약과 작업 후 증거를 맞춰 보는 과정에 가깝다.

특히 다른 사람이나 다른 세션으로 넘길 때 효과가 좋다. “어떤 파일을 봤다”보다 “어떤 자료를 근거로 쓰지 않기로 했다”가 더 중요한 경우가 많기 때문이다. 다음 세션은 보류 칸을 보고 바로 이어서 판단할 수 있고, 금지/폐기 칸을 보고 같은 삽질을 반복하지 않을 수 있다.

6. 과하게 쓰지 않아도 되는 경우

물론 모든 작업에 이 표를 붙일 필요는 없다. 단일 파일 오타 수정, 포맷터 적용, 작은 문구 교체처럼 판단 여지가 거의 없는 일에는 오히려 번거롭다. 내가 이 방식을 꺼내는 기준은 세 가지다. 첫째, 관련 파일이 세 개 이상이다. 둘째, 예전 로그나 문서가 섞여 있다. 셋째, 에이전트가 한 번 잘못된 방향으로 가면 되돌림 비용이 크다.

이 세 조건 중 두 개만 걸려도 나는 예산표를 쓴다. 많이 쓰면 10줄, 적게 쓰면 4줄이면 된다. 핵심은 컨텍스트를 “많이 줄 수 있는가”가 아니라 이번 작업의 판단권을 어떤 자료에 줄 것인가를 먼저 정하는 데 있다.

7. 작은 마무리

코딩 에이전트가 좋아질수록 컨텍스트를 더 많이 넣고 싶은 유혹은 커진다. 하지만 내 경험상 긴 세션에서 품질을 가르는 건 토큰 한도보다 자료의 지위를 분리하는 습관이었다. 필수와 참고, 보류와 금지를 나눠 두면 모델이 똑똑해지는 건 아니지만, 사람이 원하지 않은 근거로 부지런해지는 일은 확실히 줄어든다.

바이브코딩을 오래 굴리려면 프롬프트를 더 멋있게 쓰는 것보다, 에이전트가 믿어도 되는 재료와 아직 믿으면 안 되는 재료를 구분하는 쪽이 먼저다. 나는 그 구분을 매번 머릿속에만 두면 자주 놓쳤고, 네 칸짜리 예산표로 밖에 꺼내 놓았을 때 비로소 다음 검증과 handoff가 편해졌다.