컨텍스트 엔지니어링

[eunji719]

📆 일자: 26년 9월 14일

발제 의도

모델 성능이 올라갈수록 결과 품질을 가르는 건 "어떻게 물어보는가"보다
"무엇을 컨텍스트 윈도우에 넣어주는가"가 되어가고 있습니다.
컨텍스트는 넣으면 넣을수록 좋은 자원이 아니라, 예산을 나눠 써야 하는
한정 자원이라는 관점에서 이야기해보려 합니다.

🤔 오늘의 질문

1. 컨텍스트 엔지니어링은 프롬프트 엔지니어링과 무엇이 다르고, 왜 지금 이 이름으로 불리게 됐다고 보시나요?
2. 컨텍스트 윈도우가 100만 토큰까지 늘어났는데도 "많이 넣으면 오히려 성능이 떨어지는" 현상(Context Rot)은 왜 생기고, 이를 줄이기 위한 전략에는 어떤 것들이 있을까요? (압축, 요약, 서브에이전트 분리, 외부 메모리 등)
3. AI 코딩 도구를 쓰면서 "컨텍스트를 잘 줘서 성공한 경험 / 잘못 줘서 실패한 경험"이 있다면 공유해주세요. 그 경험에서 어떤 규칙을 얻으셨나요?

[k9425mino]

1. 컨텍스트 엔지니어링을 프롬프트 엔지니어링과 무엇이 다르고, 왜 지금 이 이름으로 불리게 됐다고 보시나요?

핵심적으로 말하면, 프롬프트 엔지니어링은 "무엇을 어떻게 말할 것인가"를 설계하고, 컨텍스트 엔지니어링은 "모델이 판단 순간에 무엇을 보고 있게 할 것인가"를 설계한다.

프롬프트 엔지니어링의 주요 대상은 다음과 같다.

• 지시문의 표현과 구조
• 역할, 제약 조건, 출력 형식 프롬프트
• 질문의 명확성 및 단계 구성

반면 컨텍스트 엔지니어링은 프롬프트를 포함해 더 넓은 입력 환경을 다룬다.

• 시스템·사용자 프롬프트
• 대화 이력
• 검색이나 RAG로 가져온 문서
• 도구의 설명과 실행 결과
• 사용자·조직에 관한 메모리
• 현재 작업 상태와 중간 산출물
• 무엇을 넣고, 압축하고, 제거할지에 관한 정책

예를 들어 모델이 계약서를 잘 검토하지 못한다면, 프롬프트 엔지니어링은 "법률 전문가처럼 조항별 위험을 분석하라"는 지시를 개선한다. 컨텍스트 엔지니어링은 여기에 더해 어떤 계약서 버전, 관련 법령, 회사 정책, 협상 이력, 출력 템플릿을 어느 시점에 제공할지를 설계한다.

컨텍스트 엔지니어링이 지금 부상한 이유는 세 가지이다.

첫째, 사용 사례가 한 번 묻고 한 번 답하는 모델에서 여러 단계로 일하는 에이전트로 이동했다. 에이전트는 검색하고, 파일을 읽고, 도구를 실행하며, 그 결과 다음 판단에 사용한다. 따라서 성능을 좌우하는 것이 최초의 문장 하나가 아니라 실행 과정 전체에서 형성되는 컨텍스트가 됐다. OpenAI도 에이전트 실행을 모델의 행동과 도구 실행 결과가 다음 컨텍스트로 다시 들어가는 반복 구조로 설명한다.

둘째, 컨텍스트 창이 커져도 많이 넣는 것이 곧 잘 이해시키는 것은 아니라는 사실이 분명해졌다. 불필요하거나 충돌하는 정보가 늘면 핵심을 놓칠수 있다. 그래서 이제는 컨텍스트를 저장 공간이 아니라 제한된 '주의력 예산'으로 취급하고 검색·압축·요약·메모리 관리를 설계한다. Anthropic도 컨텍스트 엔지니어링을 매 추론 시점에 가장 유용한 토큰을 선별하고 유지하는 작업으로 정의한다.

셋째, 모델이 좋아지면서 문구를 미세 조정하는 효과보다 올바른 자료와 도구를 제공하는 효과가 상대적으로 커졌다. 약한 모델에서는 주문처럼 정교한 표현이 중요했다면, 강한 모델에는 명확한 목표와 적절한 정보, 잘 설계된 도구, 깨끗한 작업 상태가 더 중요해진 것이다.

다만 두 용어의 경계가 완전히 명확한 것은 아니다. 좋은 프롬프트 엔지니어링은 원래부터 예시와 배경정보를 포함했고, 오늘날 컨텍스트 엔지니어링이라 부르는 것 중 상당수는 기존의 정보검색, 애플리케이션 설계, 상태관리, 지식관리이다. 따라서 저는 이것을 완전히 새로운 기술이라기보다 다음과 같은 관점의 확대로 본다.

프롬프트를 잘 쓰는 문제에서, 모델이 일하기 좋은 정보환경을 만드는 문제로 설계 단위가 커졌다.

그러므로 컨텍스트 엔지니어링이 프롬프트 엔지니어링을 대체한다기보다는, 프롬프트 엔지니어링을 하위 요소도구로 포함하는 상위 개념에 가깝다. 이름이 바뀐 것은 유행의 측면도 있지만, 실제 제품의 병목이 문장 작성에서 정보 선택·상태 관리·도구 설계로 이동했다는 현실도 정확히 반영한다고 본다.

2. 컨텍스트 윈도우가 100만 토끈까지 늘어났는데도 "많이 넣으면 오히려 성능이 떨어지는" 현상(Context Rot)은 왜 생기고, 이를 줄이기 위한 전략에는 어떤 것들이 있을까요? (압축, 요약, 서브에이전트 분리, 외부 메모리 등)

핵심은 "100만 토큰을 넣을 수 있다"와 "100만 토큰을 모두 정확히 활용할 수 있다"는 다르다는 점이다.

Context Rot이 생기는 이유는 다음과 같다.

• 정보 희석: 불필요한 내용이 많아질수록 중요한 정보가 ㅁ묻힌다.
• 위치 편향: 긴 문맥의 중간에 있는 정보를 'Lost int the Middle' 현상이 있다.
• 정보 충돌: 오래된 지시, 최신 상태, 잘못된 도구 결과가 함께 남으면 무엇을 우선해야 할지 혼란스러워진다.
• 추론 부담: 정보를 찾는 것보다 여러 문서의 근거를 연결하고 비교하는 일이 훨씬 어렵다.
• 훈련 한계: 최대 컨텍스트 길이는 처리 가능한 상한이지, 모든 길이에서 동일한 성능을 보장하지 않는다.

이를 줄이는 대표적인 전략은 다음과 같다.

1. 불필요한 내용 제거: 중복 문서, 오래된 상태, 완료된 도구 로그 등을 삭제한다.
2. 압축과 요약: 긴 대화나 작업 기록을 목표, 결정사항, 미해결 문제, 다음 행동 중심으로 줄인다. 단, 숫자·코드·규칙은 원문도 보존해야 한다.
3. 필요할 때만 검색: 모든 자료를 미리 넣지 않고, RAG나 검색 도구로 현재 질문과 관련된 부분만 가져온다.
4. 외부 메모리 사용: 과거 기록과 지식을 파일이나 데이터베이스에 저장하고 필요할 때 다시 불러온다. 출처·버전·작성 시점을 함께 관리해야 한다.
5. 서브에이전트 분리: 큰 작업을 독립된 하위 작업으로 나누고, 각 에이전트가 결론과 근거만 메인 에이전트에 반환하도록 한다.
6. 컨텍스트 구조화: 정책, 참고자료, 도구 결과, 실제 질문을 명확히 구분하고 정보의 우선순위를 표시한다.

결국 좋은 컨텍스트 엔지니어링은 컨텍스트를 가득 채우는 것이 아니라, 지금 필요한 정보만 작업대 위에 올려놓는 것이다.

3. AI 코딩 도구를 쓰면서 "컨텍스트를 잘 둬서 성공한 경험 / 잘못 줘서 실패한 경험"이 있다면 공유해주세요. 그 경험에서 어떤 규칙을 얻으셨나요?

엄... 암튼 있음

[eunji719]

1. 컨텍스트 엔지니어링은 프롬프트 엔지니어링과 무엇이 다르고, 왜 지금 이 이름으로 불리게 됐다고 보시나요?

프롬프트 엔지니어링은 하나의 요청 안에서 어떤 문장으로, 예시로, 순서로 지시하면 모델이 원하는 출력을 내는가에 집중한다. 언어적인 최적화 문제에 가까운 부분이다. 컨텍스트 엔지니어링은 모델이 추론 시점에 보게 되는 전체 정보 (시스템 프롬프트,대화 이력, 검색 문서, 도구 결과, 메모리, 파일) 를 하나의 예산으로 보고 무엇을 넣고 빼고 언제 요약하고 어떻게 구조화할지를 설계하는 문제이다. 에이전틱 워크플로우가 대중화 되면서, 문제의 병목이 프롬프트 문구가 아닌 긴 실행 과정에서 누적되는 컨텍스트를 어떻게 관리하는가로 옮겨갔다. 컨텍스트 윈도우가 커지면서 넣어야 하는 것과 넣을 수 있는 것 사이의 간극이 실질적인 문제가 되었고 RAG,서브 에이전트, 장기 메모리 같은 컴포넌트들이 실무 스택에 들어오면서, 이걸 통합적으로 설계하는 역할이 중요해져 컨텍스트 엔지니어링이라는 단어가 생겨났다.

2. 컨텍스트 윈도우가 100만 토큰까지 늘어났는데도 "많이 넣으면 오히려 성능이 떨어지는" 현상(Context Rot)은 왜 생기고, 이를 줄이기 위한 전략에는 어떤 것들이 있을까요? (압축, 요약, 서브에이전트 분리, 외부 메모리 등)

트랜스포머 모델이 문장 이해 시에 모든 단어를 똑같은 비중으로 보는 게 아니라 이 단어를 해석하는 데 다른 단어들이 얼마나 중요한가를 계산하여 집중하는 것을 attention이라고 하며 이러한 attention은 유한한 자원이다. 실제로 토큰이 늘어날수록 관련 정보에 대한 잡음이 많아진다. 다다익선이 아닌, 무관하거나 중복된 토큰이 늘수록 정작 중요한 부분에 대한 가중치가 희석된다. 또한 시작부와 끝부분에 비해 중간에 묻힌 정보는 놓치는 경향이 크고, 실패한 시도를 모델이 유효한 지시로 오해하여 혼란을 겪는 경우도 있다. 질문과 무관한 부분이 응답을 교묘하게 왜곡 시킬 수도 있게 되는 것이다. 따라서 컨텍스트 윈도우 크기는 수용 가능 최대치일 뿐, 최대로 채웠을 때 최적치가 아니라는 것이 핵심이다. 이를 줄이기 위해선,

1. 압축/요약: 대화가 일정 길이를 넘으면 오래된 부분을 요약해서 대체한고 세부 로그는 버린다. 다만 요약 과정에서 작은 디테일이 유실될 위험이 있어, 압축 시점과 보존해야 할 불변 정보를 구분하여 설계해야 한다.
2. 서브 에이전트로 분리: 특정 하위 작업을 별도의 서브 에이전트에 위임하고, 그 요약된 결과를 메인 컨텍스트에 반환 받는다. 메인 에이전트의 컨텍스트는 결론이 뭔지만 남고, 탐색 과정의 노이즈는 서브에이전트 안에 격리된다.
3. 외부 메모리/파일 시스템 활용: 모든 정보를 프롬프트에 넣지 말고, 가벼운 참조만 컨텍스트에 두고, 실제 필요한 순간에 도구 호출로 읽어오게 한다.
4. 구조화/우선순위 배치: 중요 지시사항은 시작이나 끝부분에 배치한다. 명확한 섹션을 구분하여 정보의 경계를 분명히 하여 에이전트가 혼동하지 않게 한다.
5. 관련성 필터링: 검색을 가져오는 과정에서 무작정 높은 순위를 가져오는 걸 늘리기 보다, 재순위화나 더 정교한 검색으로 실제 답변에 필요한 청크만 골라 넣는 게 효과적이다.
6. 도구 결과 가지치기: 에이전틱 루프에서 과거 도구 호출 결과가 오래되거나 이미 소비됐으면 컨텍스트에서 제거하거나 참조만 남긴다.

3. AI 코딩 도구를 쓰면서 "컨텍스트를 잘 줘서 성공한 경험 / 잘못 줘서 실패한 경험"이 있다면 공유해주세요. 그 경험에서 어떤 규칙을 얻으셨나요?

난 /compact를 쓰면 시간도 꽤 걸리고 뭔가 디테일적인 내용이 없어질까봐 잘 안 쓸 때가 많은데 그래서 그런지 대화 후반부쯤 가면 맛이 가는 듯한 환각상태가 많이 나타나는 것 같다. /compact를 안쓰니깐 원래 대화가 전부 누적되었을 거라고 생각했는데 실패했던 시도까지 전부 누적되어 버려서 이 디스커션을 하고 더더욱 느꼈다. 앞으로는 후반부에 무너지는 것보다는 시간을 좀만 투자하거나 세션을 초기화 하는 게 낫겠다는 생각이 들었다.

[JM-220]

1. 컨텍스트 엔지니어링은 프롬프트 엔지니어링과 무엇이 다르고, 왜 지금 이 이름으로 불리게 됐다고 보시나요?
   프롬프트 엔지니어링이란 모델의 입력 문장이나 메시지를 설계-개선하는 기술이다. 함수에 input ouput 이 있는 것처럼 llm 역시 input output 으로 동작한다. 좋은 input 을 넣으면 좋은 ouput 이 나온다. 이 전제가 프롬프트를 엔지니어링 하는 데에 의미를 부여한다.

컨텍스트 엔지니어링이란 모델에 전달되는 전체 입력 환경을 설계하는 일이다. Anthropic 은 이를 “제한된 컨텍스트 윈도우 안에 들어갈 최적의 토큰 집합을 선별하고 관리하는 일” 로 설명한다.

즉 프롬프트는 컨텍스트 안의 “지시 부분” 이고, 컨텍스트는 모델이 볼 수 있는 “전체 작업 환경”이다. 우리가 작성한 프롬프트도 결국 컨텍스트가 된다. 프롬프트와 컨텍스트 엔지니어링은 구분되는 게 아니라 컨텍스트가 더 상위개념이다.
2. 컨텍스트 윈도우가 100만 토큰까지 늘어났는데도 "많이 넣으면 오히려 성능이 떨어지는" 현상(Context Rot)은 왜 생기고, 이를 줄이기 위한 전략에는 어떤 것들이 있을까요? (압축, 요약, 서브에이전트 분리, 외부 메모리 등)
일단 첫째, 컨텍스트 윈도우가 늘어나는 것이 다음을 보장하지 않는다.

• 100만 토큰을 모두 똑같이 잘 이해한다
• 어느 위치의 정보든 정확히 찾아낸다
• 오래된 정보와 최신 정보를 잘 구분한다
• 서로 충돌하는 지시를 완벽하게 해결한다

둘째, Attention 이 많은 토큰 사이에 분산된다. Transformer 는 각 토큰이 다른 토큰을 얼마나 참고할지 관련도 기반으로 attention 으로 계산한다고 한다. 여기에 무관한 토큰들을 추가하면 관련 정보의 attention 값이 반드시 0이 되는 게 아니다. 따라서 사람처럼 주의력이 희석된다(attention dilution).

셋째, 중요한 정보가 중간에 묻히는 현상이 있다. 이를 Lost in the Middle 이라고 한다. 긴 문서의 앞부분이나 끝부분에 중요한 정보를 놓으면 성능이 상대적으로 높지만, 중간에 놓으면 잘 활용하지 못하는 현상이 관찰된다.

넷째, 오래된 대화와 도구 결과는 컨텍스트를 오염시킬 수 있다. ex) 이미 끝난 작업, 실패한 계획, 이전 버전의 테스트 결과 등.

정리하자면 가능한 한 많이 넣는 것이 아니라 현재 판단에 필요한 정보를 가장 높은 신호 대 잡음비로 넣어야 한다.

문제에 해결책이 있다. /compact, 서브에이전트 분리(결과만 받아보는, 컨텍스트가 섞이지 않음)
3. AI 코딩 도구를 쓰면서 "컨텍스트를 잘 줘서 성공한 경험 / 잘못 줘서 실패한 경험"이 있다면 공유해주세요. 그 경험에서 어떤 규칙을 얻으셨나요?
컨텍스트가 찰 수록 작업이 느려지거나 토큰 사용량이 엄청 빨라져 limit 에 걸리는 경험이 있었다. 그렇다고 매 작업마다 clear, compact 하면 귀찮기도 하고 compact 도 토큰을 사용하고 잘못된 결과도 함께 compact 하기 때문에… 무엇보다 이전 작업을 제대로 숙지하지 못하고 있으면 연관된 다른 작업을 할 때, 불편한 경우가 있다. 따라서 목표를 명확히하고, 목표를 분할하여 작업 크기를 적당히 잡고, 최대한 유의미한 토큰만 컨텍스트에 남기는 것이 좋다는 것을 알게 되었다.

[dnnals]

기본 질문

1. 컨텍스트 엔지니어링은 프롬프트 엔지니어링과 무엇이 다르고, 왜 지금 이 이름으로 불리게 됐다고 보시나요?

프롬프트 엔지니어링은 LLM에게 입력하는 프롬프트 구조를 최적화하여 원하는 답변을 유도하는 기술이고 컨텍스트 엔지니어링은 AI 답변 생성할 때 참고하는 주변 환경과 정보 전체를 설계하는 기술입니다. 컨텍스트 엔지니어링도 결국 최종 LLM에게 프롬프트 형식으로 전달되지만 매번 그 정보와 맥락을 채팅으로 주입하는 프롬프트 엔지니어링과 달리 주변 환경을 설계하여 에이전트가 도구를 이용해 자동으로 읽고 프롬프트로 주입하게 됩니다. 이는 LLM이 도구를 쥐고 단순 답변 생성이 아니라 어떤 동작을 수행할 수 있는 형태가 되면서 단순히 채팅으로 질문을 하는게 아닌 필요한 정보를 직접 읽게 해서 정보를 주입하게 될 수 있으면서 컨텍스트 엔지니어링이 등장하게 되었습니다.

2. 컨텍스트 윈도우가 100만 토큰까지 늘어났는데도 "많이 넣으면 오히려 성능이 떨어지는" 현상 (Context Rot)은 왜 생기고, 이를 줄이기 위한 전략에는 어떤 것들이 있을까요? (압축, 요약, 서브에이전트 분리, 외부 메모리 등)

Context Rot의 이유는 LLM의 구조적인 한계와 많은 정보에 따른 노이즈 증가를 이유로 들 수 있습니다. 먼저 LLM이 토큰의 맥락을 파악하는 어텐션은 메커니즘이 구조적으로 맨 앞과 맨 뒤에 있는 정보에는 집중을 잘하지만 거대한 텍스트의 중간에 있는 정보들은 놓치는 경향이 존재합니다. 그래서 정보를 줬지만 그 정보를 활용하지 못하는 경우가 존재하고, 그리고 많은 내용이 들어간다는 것은 그만큼 노이즈가 함께 늘어날 수도 있고, 그 노이즈로 인해서 실질적인 지시사항이 희석되면서 엉뚱한 대답이 나올 수 있습니다. 이를 줄이기 위한 전략으로는 관련성 높은 정보만 정제해서 주기, 핵심 조건들을 양 끝단에 배치하기, 지나간 대화와 불필요한 로그는 요약, 제거하기 등이 있습니다.

3. AI 코딩 도구를 쓰면서 "컨텍스트를 잘 줘서 성공한 경험 / 잘못 줘서 실패한 경험"이 있다면 공유해주세요. 그 경험에서 어떤 규칙을 얻으셨나요?

아직 경험이 없어서 나중에 생기면 채워서 적겠습니다

[paiwhy]

1. 컨텍스트 엔지니어링은 프롬프트 엔지니어링과 무엇이 다르고, 왜 지금 이 이름으로 불리게 됐다고 보시나요?

→ 프롬프트 엔지니어링은 지시문 문구 자체를 정교하게 다듬는 작업이고 컨텍스트 엔지니어링은 모델이 보는 컨텍스트 윈도우 전체 프롬프트, 도구 정의, RAG로 가져온 문서나 대화 또는 결과물을 설계하는 작업입니다.
에이전트 시스템이 표준이 되면서 프롬프트 문구보다 정보를 어떻게 구성하는지에 대한게 성능적인 측면을 가늠하게 되었고 기존의 정적인 텍스트의 최적화 보다는 동적 정보에대한 설계가 중요시 되기 때문에 지금의 이름으로 불리게 되었다고 생각합니다

2. 컨텍스트 윈도우가 100만 토큰까지 늘어났는데도 "많이 넣으면 오히려 성능이 떨어지는" 현상(Context Rot)은 왜 생기고, 이를 줄이기 위한 전략에는 어떤 것들이 있을까요? (압축, 요약, 서브에이전트 분리, 외부 메모리 등)

→ 컨텍스트 길이가 길어질 수록 관련된 많이 넣은 정보들은 희석되고 정확한 질문을 생각하기 보다는 오래된 정보의 토큰에게 분산이 되어 오히려 성능이 떨어지는 상황이 생깁니다
이를 줄이기 위해서는 중간마다 컨텍스트를 압축하기, 모든 정보를 컨텍스트에 넣기보다는 필요한 상황마다 필요한 정보를 조회하거나 마크다운 같은 구조화 가능한 정보들을 이용해 구조화하고 오래된 정보나 항목들을 제거하며 컨텍스트를 활용해 토큰을 절약해야합니다.

3. AI 코딩 도구를 쓰면서 "컨텍스트를 잘 줘서 성공한 경험 / 잘못 줘서 실패한 경험"이 있다면 공유해주세요. 그 경험에서 어떤 규칙을 얻으셨나요?

→ 처음 AI코드를 사용했을 당시 모든 파일 전부를 붙여 넣어서 관련 없는 부분까지 AI가 토큰을 사용하게 해 필요없는 정보를 얻게 되었던게 실패한 경험이라고 생각합니다
그 이후 컨텍스트를 보낼대마다 작업 분기를 쪼개고 그 사이사이마다 컨텍스트를 압축해 에이전트를 사용하니 내용의 정확도도 오르고 토큰도 아낄 수 있었습니다.

[9ga0]

1. 컨텍스트 엔지니어링은 프롬프트 엔지니어링과 무엇이 다르고, 왜 지금 이 이름으로 불리게 됐다고 보시나요?

프롬프트 엔지니어링은 AI에게 질문이나 지시를 어떻게 작성할지에 집중하는 방법입니다. 반면 컨텍스트 엔지니어링은 프롬프트뿐만 아니라 코드, 문서, 대화 기록, 오류 메시지처럼 AI가 참고할 전체 정보를 선택하고 관리하는 개념입니다.

최근에는 AI 모델 자체의 성능이 좋아지면서 질문을 화려하게 작성하는 것보다, 문제 해결에 필요한 정확한 정보를 제공하는 것이 더 중요해졌습니다. 또한 AI가 검색이나 코딩, 도구 사용까지 수행하면서 관리해야 할 정보의 범위도 넓어졌기 때문에 컨텍스트 엔지니어링이라는 표현이 많이 사용된다고 생각합니다.

2. 컨텍스트 윈도우가 100만 토큰까지 늘어났는데도 "많이 넣으면 오히려 성능이 떨어지는" 현상(Context Rot)은 왜 생기고, 이를 줄이기 위한 전략에는 어떤 것들이 있을까요? (압축, 요약, 서브에이전트 분리, 외부 메모리 등)

오픈북 시험에서 책을 많이 가져왔다고 무조건 문제를 잘 푸는 것은 아닙니다. 관련 없는 책이 너무 많으면 오히려 필요한 내용을 찾기 어렵습니다. 컨텍스트도 마찬가지로, 양보다 현재 문제와의 관련성이 중요합니다.
컨텍스트 윈도우가 커졌다는 것은 많은 정보를 입력할 수 있다는 뜻이지, 모든 정보를 정확하게 활용할 수 있다는 뜻은 아닙니다. 정보가 너무 많아지면 중요한 내용이 관련 없는 정보에 묻히거나, 과거의 요구사항과 현재 요구사항이 충돌할 수 있습니다. 또한 **'Lost in the Middle'**이라고 불리는 긴 컨텍스트의 중간에 있는 정보를 제대로 활용하지 못하는 현상이 할 수 있습니다. 이처럼 컨텍스트가 길어지면서 답변 품질이 낮아지는 현상을 일반적으로 **'Context Rot'**이라고 부릅니다. 결국 중요한 것은 양보다는 질입니다.

주요 해결 방법

압축: 긴 오류 로그에서 중요한 부분만 남긴다.
요약: 이전 대화를 목표, 결정 사항, 남은 작업 중심으로 정리한다.
정보 선택: 현재 문제와 관련된 코드와 문서만 제공한다.
서브에이전트 분리: 조사, 구현, 테스트 등의 작업을 나누어 처리한다.
외부 메모리: 모든 정보를 계속 넣지 않고 파일이나 DB에 저장한 뒤 필요할 때 검색한다.

3. AI 코딩 도구를 쓰면서 "컨텍스트를 잘 줘서 성공한 경험 / 잘못 줘서 실패한 경험"이 있다면 공유해주세요. 그 경험에서 어떤 규칙을 얻으셨나요?

특별히 기억나는 구체적인 사례는 없지만, AI 코딩 도구가 제가 의도한 작업과 다른 방향으로 코드를 수정한 경험은 있습니다. 당시에는 원하는 결과만 간단히 말하고, 프로젝트 구조나 수정해야 할 범위, 변경하면 안 되는 부분을 충분히 설명하지 않았습니다. 그 결과 AI가 제가 요청하지 않은 코드까지 수정하거나, 기존 구조와 다른 방식으로 기능을 구현했습니다.

이후에는 작업의 목적뿐만 아니라 수정할 파일과 범위, 유지해야 하는 기존 기능, 원하는 결과를 구체적으로 전달하려고 했습니다. 이를 통해 AI에게 컨텍스트를 줄 때는 단순히 “무엇을 만들어 달라”고 요청하는 것보다, “어디까지 수정할 수 있고 무엇은 변경하면 안 되는지”를 명확하게 알려주는 것이 중요하다는 규칙을 얻었습니다. 또한 결과가 의도와 일치하는지 직접 코드와 실행 결과를 확인해야 한다고 생각합니다.