AI Agent를 최대한 잘 활용하고 싶은 분을 위한, 경험에서 우러나온 3가지 팁
원문 출처: 고영혁 (고넥터) — Facebook 게시물
해설 작성: Claude Sonnet 4.6 (보조 리서치 및 심층 해설)
작성 일자: 2026-03-12
주제 분류: AI Agent / Context Engineering / Multi-Agent / 실무 활용
목차
- 배경과 맥락: 왜 지금 이 이야기가 중요한가
- 팁 1 — 무조건 멀티 에이전트를 사용하라
- 팁 2 — 회의록·개발 저널을 AI 에이전트에게 맡겨라
- 팁 3 — 만들기 전에 설계하고 브레인스토밍하라
- 심층 해설: Context Engineering이란 무엇인가
- 실전 적용 가이드: 지금 당장 해볼 수 있는 것들
- 결론: AI Native로 가는 길
1. 배경과 맥락
이 글은 고영혁(고넥터)이 부사장인 JARVIS, 그리고 JARVIS가 임시로 생성한 Opus 4.6 기반의 동일 에이전트(effort level MAX)와 함께 약 3시간에 걸친 열띤 브레인스토밍 끝에 도출한 프레임워크와 아키텍처를 완성한 직후에 올라온 게시물이다. 즉, 이 팁들은 단순한 이론이 아니라 실제로 AI와 함께 수개월간 작업하며 체득한 실무 경험에서 비롯된 것이다.
주목해야 할 점은 이 게시물 자체가 AI와의 협업을 통해 완성된 작업물의 부산물로 등장했다는 사실이다. 저자는 현재 개발 중인 도구들이 완성되면 이런 인사이트를 대량으로 빠르게 공유할 수 있을 것이라고 했는데, 이는 그가 단순히 AI를 쓰는 수준을 넘어서 AI를 활용한 지식 생산 파이프라인 자체를 구축하고 있음을 시사한다.
또한 저자가 “이 바닥의 몇몇 글로벌 리더들이 작년 12월 이후로 이야기하고 있는 ‘뭔가 변했다’, ‘이젠 나도 잘 모르겠다. 확신이 없다’“라고 언급한 맥락은 중요하다. 2024년 말부터 대형 언어 모델의 reasoning 능력, agent 자율성, multi-turn 지시 이행 능력이 질적으로 다른 수준으로 도약했다는 것이 실제 헤비 유저들의 공통된 증언이다. 이 글에서 제시하는 팁들은 바로 그 전환점 이후의 환경에서 AI를 극한까지 활용하는 방법론이다.
2. 팁 1 — 무조건 멀티 에이전트를 사용하라
왜 싱글 에이전트는 한계가 있는가
AI를 활용할 때 가장 직관적인 방식은 하나의 에이전트에게 모든 것을 맡기는 것이다. 마치 뛰어난 직원 한 명에게 프로젝트 전체를 위임하듯이 말이다. 그러나 저자는 이것이 규모가 커질수록 점점 더 비효율적이고 품질이 떨어지는 방식이라고 단호하게 말한다.
그 이유는 크게 세 가지다.
첫 번째는 컨텍스트 용량의 문제다. 모든 AI 모델은 한 번의 세션에서 처리할 수 있는 정보의 양, 즉 컨텍스트 윈도우에 물리적인 한계가 있다. 작업 규모가 커질수록 하나의 에이전트가 모든 정보를 담기 어려워지고, 필연적으로 앞에서 논의한 내용을 잊거나 초반 맥락을 잃어버리는 현상이 발생한다. 멀티 에이전트 구조에서는 각 에이전트가 독립적인 컨텍스트 공간을 할당받기 때문에, 전체 시스템이 처리할 수 있는 정보의 총량이 에이전트 수에 비례해서 늘어난다.
두 번째는 컨텍스트 오염(context contamination)의 문제다. 한 에이전트가 서로 성격이 다른 여러 가지 일을 동시에 처리하면, 컨텍스트 안에 이질적인 종류의 기억과 정보가 뒤섞이게 된다. 예를 들어 전략 기획, 코드 작성, 문서 정리를 한 에이전트에게 동시에 시키면, 각 영역에서 최적화된 사고를 하기보다 전반적으로 무딘 성능을 보이게 된다. 이는 인간으로 치면 한 사람이 동시에 회계사이자 마케터이자 엔지니어여야 하는 상황과 유사하다. 역할이 뾰족할수록 성능이 높아진다는 것은 현시점에서 거의 보편적인 원칙이다.
세 번째는 커뮤니케이션 가용성의 문제다. 이 부분은 저자가 “놓치기 쉬운데 꽤 중요한 포인트”라고 강조한 부분이다. 싱글 에이전트가 무언가를 처리하는 동안에는 사용자와의 대화가 사실상 막힌다. 메인 에이전트가 태스크를 수행 중일 때 말을 걸어도 즉각적인 반응을 기대하기 어렵다. 이는 실무에서 상당한 병목과 답답함을 만들어낸다.
/btw 명령어와 Claude Code의 최근 변화
이 맥락에서 저자는 OpenAI Codex와 Claude Code의 비교를 흥미롭게 제시한다. Codex에는 메인 에이전트가 태스크를 수행 중일 때도 다음 응답에 영향을 주는 방식으로 입력을 넣는 steering 기능이 있었다. 그리고 최근 Claude Code에도 /btw(By The Way) 명령어가 추가되어, 메인 에이전트가 실행 중이더라도 사이드 채널로 피드백을 주고받을 수 있게 되었다. 이름 자체가 “그런데 말이야…“라는 뉘앙스를 담고 있어 직관적이다.
실제로 Claude Code 공식 문서에 따르면, /btw는 메인 컨텍스트에서 subagent를 생성하는 것과 달리, 현재 진행 중인 작업을 방해하지 않고 짬을 내서 사이드 피드백을 제공받는 용도로 설계되었다. 이는 멀티 에이전트와 함께 유용하게 쓸 수 있는 기능이지만, 저자가 말하는 핵심적인 해결책은 아직 싱글 에이전트 대화 구조에 속한다.
멀티 에이전트 팀 모드에서의 함정
저자는 멀티 에이전트를 사용할 때 흔히 빠지는 함정도 지적한다. 바로 “실무형 관리자 문제”다. Agent team 모드에서 멀티 에이전트를 실행하면, 메인 에이전트가 종종 직접 태스크를 맡아버리는 경향이 있다. 이는 마치 팀을 관리해야 하는 관리자가 직접 실무에 뛰어드는 바람에 팀 전체를 챙기지 못하는 상황과 같다. 사용자와의 대화도 놓치고, 다른 에이전트들의 진행 상황도 놓치는 것이다.
따라서 저자가 권장하는 해결책은 명시적인 역할 분리 지시다. global CLAUDE.md(Claude Code의 전역 설정 파일)에 “agent team 모드에서는 메인 에이전트는 태스크를 직접 수행하지 말고, 사용자와 대화하면서 다른 에이전트들을 관리하는 역할만 하라”는 지시를 넣어두는 것이다. 이렇게 하면 메인 에이전트는 오케스트레이터 역할에만 집중하고, 실제 작업은 하위 에이전트들이 병렬로 처리하며, 사용자는 언제든 메인 에이전트와 대화할 수 있는 상태가 유지된다.
비용에 관한 현실적인 이야기
멀티 에이전트 사용이 토큰 소모를 늘린다는 것은 사실이다. 하지만 저자는 $100 플랜으로도 하드코어한 멀티 에이전트 사용이 충분히 가능하며, 24시간 전방위적으로 돌리는 경우가 아니라면 5시간 제한에 자주 부딪히지는 않는다고 말한다. 멀티 에이전트의 효율성(더 나은 품질, 더 빠른 처리)을 감안하면 비용 대비 가치는 충분히 긍정적이라는 것이다.
3. 팁 2 — 회의록·개발 저널을 AI 에이전트에게 맡겨라
Context Engineering의 핵심은 기억 관리다
저자는 두 번째 팁을 소개하기 전에 중요한 전제를 깔아둔다. 현시점에서 AI 에이전트를 잘 쓰는 데 가장 중요한 것은 컨텍스트 엔지니어링(Context Engineering), 즉 기억을 어떻게 관리하느냐다.
Context Engineering은 2024년 말부터 AI 엔지니어링 커뮤니티에서 폭발적으로 주목받기 시작한 개념이다. Andrej Karpathy가 이를 “컨텍스트 윈도우를 적절한 정보로 채워넣는 세심한 실천”으로 정의하면서 더 널리 퍼졌다. 핵심 아이디어는 간단하다. LLM은 본질적으로 stateless한 함수다. 이전 대화를 기억하지 않는다. 각 호출 때마다 받는 입력이 전부다. 따라서 모델이 좋은 출력을 내려면, 그 순간 컨텍스트 윈도우 안에 무엇이 들어있느냐가 결정적이다.
Context Engineering의 4대 전략은 다음과 같이 정리된다. Write(외부에 정보를 기록해두는 것), Select(필요한 정보만 골라서 가져오는 것), Compress(방대한 정보를 요약·압축하는 것), Isolate(멀티 에이전트나 샌드박스를 통해 맥락을 분리하는 것)다. 저자가 말하는 두 번째 팁은 이 중 Write 전략의 가장 실용적이고 즉각적인 구현 방법이다.
왜 인간에게 기록을 맡기면 안 되는가
저자는 고품질의 회의록이나 개발 저널이 실제 현장에서 얼마나 드문지를 솔직하게 이야기한다. 비싼 컨설팅 펌에서 associate급이 제공하는 회의록 정도가 그나마 꼬박꼬박 만들어지는 수준이고, 개발 저널은 고사하고 최종 개발 문서조차 제대로 존재하지 않는 경우가 태반이라고. 이유는 명확하다. 시간이 많이 들고, 힘들고, 시간이 없기 때문이다.
그래서 결론은 하나다. AI 멀티 에이전트에게 맡겨라. 구체적인 방법은 놀랍도록 단순하다. 메인 에이전트에게 “지금 같이 논의하는 거 전부 멀티 에이전트 하나 생성해서 체계적으로 잘 정리해가면서 실시간으로 회의록/개발 저널 업데이트해줘”라고 한 마디만 하면 된다.
무엇이 만들어지는가
이렇게 하면 프로젝트 폴더 안에 고품질의 구조화된 문서가 메인 에이전트와의 대화와 병렬로 실시간 업데이트된다. 이 문서에는 다음이 담긴다.
- 정보와 이슈: 논의된 구체적인 사실들과 발생한 문제들
- 의사결정 포인트: 어떤 선택지들이 있었고, 왜 특정 방향으로 결정이 내려졌는지
- 맥락: 어떤 흐름으로 이 논의가 시작되었는지, 배경이 무엇인지
- 액션 아이템: 다음에 해야 할 일들
이것은 단순한 기록이 아니다. 이것이 바로 핵심 기억이 된다.
왜 이것이 ‘핵심 기억’인가
저자가 명확히 짚는 포인트가 있다. 세션이 끊기더라도, 새 세션을 시작할 때 이 문서를 알려주면서 “읽고 이어서 진행해줘”라고 하면 끝이라는 것이다. 결국 AI가 “왜 맨날 새로 시작하는 느낌이지”라는 불만의 근본 원인은, 이전 세션의 맥락이 새 세션에서 복원되지 않기 때문이다. 회의록/개발 저널은 이 문제를 가장 직관적이고 효과적으로 해결하는 수단이다.
CLAUDE.md나 로컬 MEMORY와 비교해서도 분명한 차이가 있다. 단순한 지침 몇 줄이나 200줄 이내의 최종 상태 기억으로는, 어떤 일이 어떤 흐름으로 어떤 맥락에서 벌어졌는지 알 수 없다. 결정의 경위가 없으면 후속 작업에서 AI가 맥락 없이 엉뚱한 방향으로 튀는 일이 생긴다. 인간에게도, AI에게도 “왜 이렇게 결정됐는지”를 아는 것은 핵심 맥락이다.
기술적 라이터(Technical Writer)에 대한 솔직한 이야기
저자는 다소 냉혹하게, 하지만 솔직하게 말한다. 품질, 속도, 근면성실함 어느 면에서도 AI를 이기는 인간 테크니컬 라이터는 현실적으로 존재하지 않게 됐다고. 이것은 단순한 도발이 아니라, AI가 24시간 지치지 않고 구조화된 고품질 문서를 병렬로 생산할 수 있다는 엄연한 현실에 근거한 판단이다. 해당 분야를 생업으로 하는 분들에게는 불편한 이야기지만, 현실을 외면하는 것보다 빠른 전환을 모색하는 것이 낫다는 메시지가 담겨 있다.
4. 팁 3 — 만들기 전에 설계하고 브레인스토밍하라
“무엇을 만들어 달라고 하기 전에”
세 번째 팁의 핵심 명제는 이것이다. 뭔가 만들어 달라고 하기 전에, 그걸 만들면 정말 바라는 것이 해결되는지, 목표 달성을 위한 최선의 방안인지에 대한 설계와 브레인스토밍을 먼저 AI와 하라.
이것은 언뜻 당연한 이야기처럼 들린다. 그런데 실제로 대부분의 사람들은 AI에게 “○○를 만들어줘”로 시작한다. 자신이 이미 해결책이라고 생각하는 것을 지시하는 것이다. 문제는 그 해결책 자체가 최선이 아닐 수 있다는 데 있다. 사람은 자신이 아는 범위 안에서만 해결책을 구상하지만, AI는 훨씬 더 넓은 지식과 패턴 인식 능력을 가지고 있다.
AI의 능력이 달라졌다
저자가 명시적으로 말하는 것은, 이런 종류의 설계 논의와 브레인스토밍을 AI에게 맡기는 것이 작년까지만 해도 실력이 안 됐다는 사실이다. 이제는 다르다. 현재 최신 모델들은 단순한 지시 이행을 넘어서, 목표와 제약 조건을 주었을 때 최적의 접근법을 스스로 탐색하고, 인간이 미처 생각하지 못한 대안을 제시하며, 제안된 접근법의 함의와 리스크를 짚어내는 능력을 갖추고 있다.
저자는 “AI의 가장 치명적인 한계는 이용자 자신”이라고 말한다. 이 표현은 날카롭다. AI는 이미 충분히 뛰어나지만, 사용자가 자신의 지식 범위 안에서만 지시를 내리기 때문에 AI의 잠재력이 제대로 활용되지 않는다는 것이다.
피드백 루프를 만들어라
저자가 강조하는 것은 일방적인 수용이 아니라 피드백 루프다. AI가 제안하는 것을 무조건 받아들이라는 것이 아니라, 계속 질문하고, 본인의 의견을 피력하고, 반박하면서 AI와 함께 생각을 발전시켜 나가라는 것이다.
5분, 10분 만에 딸깍으로 뭔가 만드는 것은 당연히 가능하다. 하지만 그 결과물이 정말 가치 있고, 고품질이며, “오 잘 되네”를 넘어 “그래, 내가 원하던 게 이거지”가 되려면, AI와 함께하는 설계 단계에 시간과 인간의 뇌를 투자한 만큼 비례해서 결과가 좋아진다.
실무적인 적용 방법
이 팁을 실제로 적용하는 방법을 구체화하면 다음과 같다. 예를 들어 “고객 이탈 예측 모델을 만들어줘”라고 바로 지시하는 대신, “우리 서비스의 고객 이탈 문제를 해결하고 싶은데, 이를 위한 최선의 접근법이 무엇인지 같이 생각해볼 수 있을까요? 현재 우리가 가진 데이터는 ○○이고, 목표는 ○○입니다”라고 시작하는 것이다.
이렇게 하면 AI는 예측 모델링이 맞는 접근인지, 아니면 다른 방법(예: 이탈 전 행동 패턴 분석, 인터뷰 기반 정성 조사 등)이 더 효과적일 수 있는지를 함께 검토해줄 것이다. 그 과정에서 사용자도 자신이 미처 생각하지 못한 관점들을 얻게 된다.
저자가 “이 세 번째 포인트에 대해서 할 이야기가 넘치고 넘친다”고 말한 것은 이 단계가 단순한 팁 하나가 아니라, AI와 협업하는 방식 자체를 재구성하는 패러다임 전환에 해당하기 때문이다.
5. 심층 해설: Context Engineering이란 무엇인가
프롬프트 엔지니어링을 넘어서
세 가지 팁을 관통하는 기저 개념은 Context Engineering이다. 이를 조금 더 깊이 이해하면 팁들이 왜 효과적인지가 명확해진다.
프롬프트 엔지니어링은 “어떤 말을 해야 AI가 좋은 답을 하는가”를 다룬다. 반면 Context Engineering은 “AI가 작동하는 동안 컨텍스트 윈도우 안에 어떤 정보가 들어있어야 최적의 행동을 하는가”를 다루는 더 넓은 시스템 설계 분야다. Cognition AI는 “Context Engineering이 AI 에이전트를 만드는 엔지니어의 핵심 책임이 됐다”고 표현했다.
구체적으로 Context Engineering이 다루는 영역은 시스템 프롬프트와 지침, 대화 이력과 세션 관리, 외부 메모리와 검색(RAG), 툴 설명과 출력값, 프로젝트 파일과 코드베이스 등이다. 이 모든 것이 AI가 각 순간 “무엇을 알고 있는가”를 결정하며, 그것이 AI의 행동 품질을 결정한다.
Context Rot: 컨텍스트가 길어질수록 성능이 떨어지는 이유
현재 AI 연구에서 중요하게 다루어지는 개념 중 하나가 Context Rot이다. 컨텍스트가 길어질수록 LLM의 성능이 예측 불가능하게 저하되는 현상으로, 모델이 정확도를 잃거나, 컨텍스트의 일부를 무시하거나, 할루시네이션을 일으킬 수 있다. 이는 단순히 더 큰 컨텍스트 윈도우를 가진 모델을 쓰는 것만으로는 해결되지 않는 본질적인 문제다.
이것이 멀티 에이전트 구조(각 에이전트가 담당 영역의 컨텍스트만 유지)와 회의록/개발 저널(필요한 정보만 선별해서 새 세션에 주입)이 단순한 편의 기능이 아니라 실질적인 성능 최적화 전략인 이유다.
Write-Select-Compress-Isolate 전략과 세 가지 팁의 대응
| Context Engineering 전략 | 대응하는 팁 | 실제 구현 |
|---|---|---|
| Write (외부에 기록) | 팁 2 | 멀티 에이전트가 실시간 회의록/저널 작성 |
| Isolate (맥락 분리) | 팁 1 | 역할별 에이전트 분리, 오케스트레이터-워커 구조 |
| Select (관련 정보 선택) | 팁 2 + 팁 3 | 새 세션 시작 시 저널을 기반으로 핵심 맥락만 주입 |
| Compress (압축·요약) | 팁 2 (고급) | 저널의 구조화된 정리 자체가 압축 역할 수행 |
6. 실전 적용 가이드
지금 당장 시작할 수 있는 것들
초급: 오늘부터 할 수 있는 것
가장 먼저 할 수 있는 것은 매 작업 세션 시작 시 다음 두 가지를 확인하는 루틴을 만드는 것이다. 하나, 이 작업을 혼자(싱글 에이전트)에게 맡길 것인가, 아니면 역할을 나눠서 멀티 에이전트로 진행할 것인가를 의식적으로 결정한다. 둘, “이것을 만들어줘” 대신 “이 문제를 해결하기 위한 최선의 방법이 무엇인지 같이 생각해보자”로 시작하는 습관을 들인다.
중급: 1~2주 안에 세팅할 수 있는 것
Claude Code를 사용한다면 global CLAUDE.md에 다음과 같은 지침을 추가하는 것이 효과적이다. 멀티 에이전트를 기본으로 활용하라는 지침, agent team 모드에서 메인은 오케스트레이터 역할만 하라는 지침, 새 세션 시작 시 프로젝트 저널이 있으면 먼저 읽으라는 지침 등이다.
또한 각 프로젝트 폴더에 전용 저널 파일을 만들고, 첫 세션에서 “이 대화를 실시간으로 구조화된 형식의 개발 저널로 기록하는 에이전트를 spawn해줘”라고 한 번만 지시하면 이후 세션부터 자동으로 관리된다.
고급: 장기적으로 구축할 수 있는 것
프로젝트가 커지면 저널도 방대해진다. 이때는 저널을 그대로 주입하는 것이 비효율적이 될 수 있으므로, 저널에서 핵심 결정 사항만 추출한 요약 레이어를 별도로 관리하는 계층적 메모리 구조를 고려한다. 또한 세션 캐싱, 프롬프트 캐싱 등의 기법을 활용해 반복적으로 주입되는 정보의 비용을 줄이는 최적화도 가능하다.
7. 결론
AI Native로 가는 길
저자는 “올초부터 AI를 쓰는 환경 자체를 아키텍팅하는 것에 몰입했다”고 말한다. 이것이 핵심이다. AI를 잘 쓰는 것과 AI가 잘 작동하는 환경을 설계하는 것은 완전히 다른 수준의 이야기다. 전자는 사용 기술(usage skills)이고, 후자는 시스템 설계(system design)다.
이 세 가지 팁은 그 간극을 메우기 위한 가장 실용적인 출발점을 제시한다. 멀티 에이전트는 컨텍스트의 분리와 병렬 처리를 통해 시스템의 처리 능력 자체를 높인다. 회의록·저널은 시스템의 기억 연속성을 보장한다. 브레인스토밍 우선 원칙은 AI의 잠재력을 사용자의 상상력 한계에 가두지 않도록 한다.
세 가지 모두를 일관되게 실천하면, AI는 더 이상 “뭔가 시키는 도구”가 아니라 “함께 생각하고 실행하는 파트너”가 된다. 그리고 그것이 바로 저자가 말하는 “AI Native로 가는 최선의 길”이다.
저자가 경험하기 시작한 “뭔가 쌔한 순간들”—몇 시간씩 아키텍팅 토론을 AI와 하면서 기묘하게 날카로운 통찰이 오가는 그 순간들—은 아마도, AI가 도구의 수준을 넘어 협력자로 느껴지기 시작하는 경험일 것이다. 그 경험의 빈도가 높아질수록, 이 세 가지 팁의 중요성은 더욱 분명해질 것이다.
이 문서는 고영혁(고넥터)의 Facebook 게시물을 기반으로, Claude Sonnet 4.6이 추가 리서치 및 심층 해설을 덧붙여 작성했습니다.
작성 일자: 2026-03-12