IDE에서 터미널까지: 지능형 에이전트 엔지니어링을 위한 실용 핸드북

2026년 3월, 맷 밴 혼은 X 플랫폼에 "내가 아는 모든 클로드 코드 팁"이라는 직설적인 제목의 장문의 글을 게시했습니다. 이 글은 결국 913,000회의 조회수를 기록했고, 댓글란은 열광적인 반응으로 가득 찼습니다.

논란은 특정 명령어나 설정 매개변수 때문이 아니라, 그의 첫 발언인 "IDE를 사용하지 않는다"에서 비롯되었습니다. 그는 자신의 작업 과정을 설명하면서 그래픽 편집기를 한 번도 열어본 적이 없으며, 모든 개발은 터미널 명령줄과 plan.md라는 파일에서 이루어진다고 언급했습니다. 일부는 이를 황당하게 여겨 코드 읽기, 디버깅, 리팩토링은 어떻게 하는지 물었고, 한 선임 엔지니어는 "바로 내가 찾던 방식이다"라고 평했습니다.

두 달 후, 중국 개발자 멍 샤오는 이 방법론과 관련 커뮤니티 사례들을 모아 "지능형 에이전트 엔지니어링을 위한 실용적인 팁 완벽 가이드"라는 제목으로 발표했습니다. 이는 도구 평가가 아니라 "연구 → 계획 → 실행" 주기를 중심으로 하는 일련의 운영 원칙이며, 재현 가능하거나 논의 가능한 22가지 구체적인 기술을 기반으로 합니다.

이 글에서는 온라인에서 가장 많이 논의되는 AI 워크플로 운영 가이드 몇 가지를 모아 공통점을 찾아봅니다.

IDE를 닫으면 무엇을 잃게 되나요?

그래픽 IDE는 개발자에게 단순한 코드 편집 영역 이상의 것을 제공합니다. 구문 강조 표시를 통해 변수와 키워드를 즉시 구분할 수 있고, 실시간 오류 메시지를 통해 입력하는 동안 문제 위치를 파악할 수 있으며, 중단점 디버깅을 통해 변수 상태 변화를 한 줄씩 관찰할 수 있고, 파일 트리와 브레드크럼 탐색을 통해 대규모 프로젝트에서도 길을 잃지 않고 탐색할 수 있는 완벽한 시각적 시스템을 제공합니다. 이러한 시각적 피드백 메커니즘은 개발자가 모든 코드 줄의 상태를 확인할 필요가 있다는 기본 전제를 바탕으로 합니다.

터미널 명령줄과 마크다운 파일을 사용하는 워크플로는 이러한 시각적 보호막을 제거합니다. 남는 것은 깜빡이는 커서와 손으로 쓴 계획 문서뿐입니다. 오류를 표시하는 빨간색 물결선도, 자동 완성 팝업도, 파일 트리도 없습니다. 맷 밴 혼은 트윗에서 "IDE 없음"이라는 표현을 사용했지만, 그 진정한 의미는 모든 그래픽 도구를 거부하는 것이 아니라 개발 제어 방식을 "한 줄씩 수동으로 확인하는 방식"에서 "일괄 위임 실행"으로 바꾸는 것입니다.

클로드 코드(Claude Code)의 수석 개발자인 보리스 체르니(Boris Cherny)는 2025년 말과 2026년 초에 스레드(Threads) 및 기타 채널을 통해 클로드 코드 사용 방식을 공유했습니다. 그의 접근 방식은 CLI를 우선시하며, 모든 작업의 시작점으로 계획 모드(plan mode)를 활용합니다. 이는 IDE 사고방식과 근본적으로 다릅니다. 기존 IDE에서는 사람이 능동적으로 코드를 작성하고 AI 자동 완성 기능은 보조적인 역할만 하지만, 계획 기반 터미널 워크플로에서는 사람이 방향을 설정하고 승인하는 역할을 하며, 코드 생성 및 구현 경로는 에이전트가 자율적으로 선택합니다.

IDE를 포기한다는 것은 "코드 한 줄 한 줄을 직접 입력하는" 안정감을 잃는다는 것을 의미합니다. 언뜻 보기에는 손실처럼 느껴질 수 있지만, 대규모 프로젝트에서 잦은 컨텍스트 전환을 경험해 온 개발자들에게는 오히려 업무 부담을 덜어주는 효과도 있습니다. 더 이상 코드를 읽고, 작성하고, 문서를 검색하고, 파일을 전환하는 작업을 반복적으로 수행할 필요가 없어지기 때문입니다. 명확한 요구사항만 제시하면 나머지 실행 과정은 병렬로 작동하는 여러 작업자에게 위임할 수 있습니다.

맹샤오의 프레임워크는 요약하자면 "인간 주도의 방향 설정, 지능형 에이전트 실행"입니다. IDE 시대에는 인간이 방향 설정과 실행 세부 사항 모두를 담당하여 두 역할이 서로 얽혀 있었습니다. 새로운 워크플로는 이 두 역할을 분리하여 인간은 방향 설정만 담당하도록 합니다.

plan.md는 문서가 아니라 계약서입니다.

이 워크플로에서 가장 흔하게 사용되는 파일 이름은 plan.md입니다. 프로젝트 문서처럼 들리지만 실제 기능은 완전히 다릅니다.

프로젝트의 README 또는 개발 문서는 사람이 읽기 위한 것으로, 아키텍처 설계 결정 사항을 설명하고, 인터페이스 규칙을 기록하고, 새로운 구성원이 프로젝트를 시작하는 데 도움을 주기 위해 사용됩니다. plan.md의 주요 독자는 사람이 아니라 에이전트입니다. plan.md는 문제 정의, 해결 방법 설명, 체크박스 방식의 실행 목록이라는 세 가지 요소로 구성되어 있습니다. 멍 샤오는 트윗에서 이 관계를 매우 명확하게 설명했습니다. plan.md의 역할은 "에이전트가 게으르지 않도록 제약하는 것"입니다.

LLM은 긴 대화에서 발생하는 "컨텍스트 손상"이라는 알려진 문제를 가지고 있습니다. 대화 기록이 길어질수록 모델은 초기 목표에 대한 주의력이 자연스럽게 떨어집니다. 그 결과, 초기에 설정한 요구 사항의 경계를 잊어버리거나 특정 확인 단계를 건너뛸 수 있습니다. 커뮤니티의 "Cleanliness.skill" 프로젝트는 이러한 문제를 해결하기 위해 대화 파일을 자동으로 정리하고 영구 메모리를 업데이트하는 방법을 제공합니다. 이 프로젝트의 핵심 전제는 에이전트의 장기적인 성능이 단일 프롬프트의 품질에 달려 있는 것이 아니라 안정적인 외부 메모리 메커니즘의 존재 여부에 달려 있다는 것입니다.

`plan.md` 파일은 이러한 외부 메모리 역할을 합니다. 이 파일은 파일 시스템에 저장되며 세션이 종료되어도 사라지지 않습니다. 새로운 상담원 세션은 이전 대화의 만료된 채팅 기록에 의존하는 대신 이 파일에서 컨텍스트를 다시 불러올 수 있습니다.

Every Inc.의 Kieran Klaassen이 개발한 Compound Engineering은 이 워크플로우를 지원하는 핵심 오픈 소스 플러그인입니다. 이 플러그인은 명령줄 명령어 세트를 제공하며, /ce:plan 명령어를 사용하면 개발자의 입력을 기반으로 `plan.md` 초안 파일이 자동으로 생성됩니다. 생성 후 개발자는 이를 검토하고 수정해야 합니다. 에이전트가 기술 선택에 대해 잘못된 가정을 하거나, 모듈의 복잡성을 과소평가하거나, 비즈니스 로직을 완전히 잘못 이해할 수 있기 때문입니다. 이 단계에서 개발자의 개입은 코드 미세 조정이 아니라, 에이전트가 알지 못하는 도메인 지식을 계획 파일에 추가하고 수정된 계획을 에이전트에 다시 전달하여 실행하는 것입니다.

이 디자인은 보리스 체르니가 그의 클로드 코드 원칙에서 강조한 핵심 원칙, 즉 실행의 모든 단계에 걸쳐 인간의 판단을 분산시키는 대신 계획 및 검토 단계에 집중시키는 원칙과 밀접하게 연관되어 있습니다. 그의 말에 따르면, 모든 단계에 인간의 감독과 확인이 필요하다면, 그것은 본질적으로 수동으로 코드를 작성하는 것과 다를 바 없습니다.

효과적인 plan.md 파일은 길지 않습니다. 일반적으로 명확한 승인 기준이 포함되어 있으며, 각 기준은 체크박스에 해당합니다. 이러한 체크박스는 에이전트의 실행 기준점이자 사용자의 승인 표준 역할을 합니다. 개발자는 작업 단계가 완료되면 코드를 읽는 대신, 이러한 체크박스가 하나씩 선택되었는지 확인합니다.

요구사항의 세 가지 형태: 연구 → 계획 → 실행

이 워크플로의 핵심 프레임워크는 연구, 계획, 실행의 세 단계로 구성된 폐쇄 루프입니다. 복잡하지는 않지만, 각 단계는 도구 지원과 인력 투입 측면에서 명확한 업무 분담이 이루어져 있습니다.

연구 단계의 목표는 에이전트가 행동을 취하기 전에 정보적 우위를 확보하는 것입니다. 일반적인 방법으로는 /ce:brainstorm 명령어를 사용하거나 특정 연구 스킬 패키지를 로드하는 것이 있습니다. Matt Van Horn은 `last30days-skill`이라는 스킬을 오픈소스로 공개했는데, 이 스킬은 2026년 3월 말 기준으로 GitHub에서 10,000개 이상의 별을 받았습니다. 이 스킬은 에이전트가 Reddit, X 플랫폼, Hacker News와 같은 커뮤니티에서 지정된 주제와 관련된 콘텐츠를 지난 30일 동안 동시에 크롤링하여 구조화된 분석 요약을 출력하도록 합니다. 예를 들어 새로운 기술 스택을 사용하는 프로젝트를 시작한다고 가정해 보겠습니다. 에이전트는 사용자가 여러 브라우저 탭을 수동으로 열 필요 없이 몇 분 안에 해당 기술 스택에 대한 최신 커뮤니티 리뷰, 알려진 문제점, 권장 대안 등을 찾아낼 수 있습니다.

연구가 완료된 후의 결과물은 최종 답이 아니라 정보 입력입니다. 이 정보는 계획 단계로 들어가 plan.md 파일을 생성하는 데 필요한 자료가 됩니다.

계획 단계에서는 /ce:plan 명령어를 사용합니다. 연구 단계의 결과, 개발자의 초기 요구사항, 그리고 프로젝트의 기존 코드 컨텍스트를 기반으로 에이전트는 `plan.md` 초안을 생성합니다. Compound Engineering의 설계 철학은 계획 및 검토에 80%, 실행에 20%의 시간을 투자하는 것입니다. 이 비율은 언뜻 보기에 다소 공격적으로 보일 수 있지만, 그 논리는 간단합니다. 명확하게 작성된 계획은 구체적인 범위와 승인 기준을 제시함으로써 실행 단계에서 발생하는 재작업 비용을 최소화합니다.

계획 단계에서 개발자는 에이전트가 기술 솔루션에 대해 잘못 가정한 부분을 수정하고, 에이전트가 알지 못하는 비즈니스 제약 조건을 추가하고, 작업 분할 및 실행 순서의 세분성을 조정하고, 에이전트가 체크박스에서 쉽게 간과할 수 있는 예외 상황을 추가해야 합니다. 이러한 검토 과정 자체도 일종의 "외부 메모리 주입"이라고 할 수 있는데, 이 단계에서 사람들은 대화에서 자연스럽게 드러나기 어려운 암묵적인 지식을 계획 문서에 기록하기 때문입니다.

작업 단계에서는 /ce:work 명령어를 사용합니다. 에이전트는 `plan.md` 파일을 읽고, 작업을 하위 작업으로 분해한 후, 병렬 실행을 위해 하위 에이전트에 할당합니다. 보리스 체르니는 이러한 계획 기반 워크플로를 사용하여 한 달에 259개의 풀 리퀘스트를 생성했다는 통계를 공유한 적이 있습니다. 이 수치는 코드 품질을 보여주는 것이 아니라, 실행 단계에서 의사 결정 권한이 에이전트에 위임되면 인간의 병목 현상이 더 이상 타이핑 속도가 아니라는 것을 보여줍니다.

세 단계 사이에는 종종 간과되는 중요한 접점이 있습니다. 바로 조사 및 계획 단계를 여러 번 반복할 수 있다는 점입니다. 에이전트가 계획 단계에서 정보 부족을 발견하면 언제든지 조사 모드로 돌아가 부족한 부분을 채울 수 있습니다. 마찬가지로 작업 단계가 시작된 후 계획에서 오류가 발견되면 계획 단계로 돌아가 수정할 수 있습니다. 이러한 순환은 선형적인 폭포수 흐름이 아니라, 되돌리기와 조정이 가능한 루프입니다.

지금 바로 시도해 볼 수 있는 6가지 팁.

현재 이용 가능한 정보 중에서 다음 여섯 가지 팁은 모두 출처가 명확하고 개발자가 직접 시도해 볼 수 있을 만큼 충분한 세부 정보를 제공합니다. 이는 추상적인 원칙이 아니라 "터미널에 무엇을 입력해야 하는지", "파일에 무엇을 써야 하는지", "어떤 도구를 사용해야 하는지"와 같은 구체적인 작업입니다.

팁 1: 아이디어가 떠오르는 즉시 계획을 세우세요. 머릿속으로만 시뮬레이션하지 마세요.

맹샤오는 원문 초반에 이 점을 지적했습니다. 그의 논리는 인간의 두뇌는 검토에는 탁월하지만, 아무것도 없는 상태에서 복잡한 논리적 트리 구조를 만들어내는 데는 비효율적이라는 것입니다. 개발자들은 새로운 요구사항을 받으면 습관적으로 구현 경로를 머릿속으로 되짚어보지만, 작업 기억 용량이 제한적이기 때문에 이 과정은 매우 비효율적입니다. 올바른 접근 방식은 아이디어가 떠오르는 즉시, 비록 미흡하고 오류가 있으며 대대적인 수정이 필요하더라도, 에이전트가 초안 계획을 생성하도록 하는 것입니다. 문제가 있는 계획을 검토하는 것이 처음부터 완벽한 계획을 작성하는 것보다 훨씬 쉽기 때문입니다.

팁 2: 계획서를 직접 읽지 말고, 담당자에게 몇 문장으로 요약해 달라고 하세요.

장문의 계획 문서를 읽는 것 자체가 비용입니다. 보리스 체르니의 22가지 팁 중 하나는 자연어 명령어를 사용하여 담당자에게 요약본(TLDR, Translation Time Reference)을 제공하도록 하거나, "eli5"(5단계로 쉽게 설명) 명령어를 사용하여 계획의 핵심 내용을 가장 명확하게 설명하도록 하는 것입니다. 검토 시간이 5분이라면, 처음 3분은 담당자에게 요약을 요청하고, 나머지 2분은 위험하다고 생각되는 부분만 확인하는 데 사용하세요. 이 기법의 핵심은 "독해"까지 위임하는 것입니다. 사람들은 필요한 부분만 읽기 때문입니다.

팁 3: 다중 터미널 병렬 작동.

맷 밴 혼은 자신의 트윗에서 여러 터미널 창을 동시에 열어 각기 다른 에이전트 인스턴스가 서로 다른 하위 작업을 처리하도록 한다고 언급했습니다. 하나는 프런트엔드 페이지를 작업하고, 하나는 백엔드 API를 작성하고, 하나는 테스트를 실행하고, 또 하나는 문서를 가져오는 등의 작업을 수행합니다. 이러한 접근 방식은 기존의 단일 스레드 개발 방식을 다중 스레드 스케줄링으로 전환합니다. 하지만 단점은 통합 모니터링을 제공하는 그래픽 작업 환경 없이 각 터미널의 출력과 상태를 직접 관리해야 한다는 것입니다. 단일 IDE 창에서 전체적인 상황을 파악하는 데 익숙한 개발자라면 처음에는 "어디서 문제가 발생했는지 알 수 없다"는 불안감을 느낄 수도 있습니다.

팁 4: 복잡한 건축 관련 명령에는 키보드 입력 대신 음성 입력을 사용하세요.

맹샤오는 모놀로그와 같은 음성 입력 도구를 사용하는 것에 대해 언급했습니다. 구체적인 방법은 장황한 시스템 설계 개념을 타이핑하는 대신 그대로 말한 다음, 음성-텍스트 변환 도구를 사용하여 터미널이나 프로젝트 파일로 내용을 가져오는 것입니다. 맷 반 혼은 이를 "음성으로 채우세요(Get Voice-Pilled)"라고 부르며, 음성이 타이핑보다 복잡한 아키텍처적 사고의 일관성을 유지하는 데 더 효과적이라고 주장합니다. 음성 입력 속도가 논리적 흐름과 더 잘 맞아떨어지기 때문입니다. 그러나 중국 개발자를 대상으로 한 이 기술의 실제 효과에 대한 충분한 피드백이 아직 부족하며, 모놀로그의 중국어 음성 지원 기능에 대한 추가적인 확인이 필요합니다.

팁 5: 이메일을 통해 비동기 작업을 시작하세요.

2026년 4월, 맷 밴 혼은 트위터를 통해 구체적인 시나리오를 공유했습니다. 아이를 재우면서 에이전트메일 도구를 이용해 클로드 코드 인스턴스로 이메일을 보내 원격 코드 빌드 작업을 실행한 것입니다. 아이가 잠든 후 빌드가 완료되었고, 터미널에서 결과를 확인할 수 있었습니다. 이처럼 에이전트를 활용하면 개발자는 "컴퓨터 앞에 앉아 있어야 한다"는 물리적 제약에서 벗어나 백그라운드에서 지속적으로 작업할 수 있습니다. 단, 에이전트에 대한 신뢰도가 높아야 하며, 화면을 보지 않고도 자율적으로 실행되도록 허용해야 합니다.

팁 6: 도구 모음을 기술 시장처럼 활용하세요.

AgentSkills와 같은 프로젝트는 개발자가 모든 에이전트 기능을 처음부터 구축할 필요가 없다는 핵심 개념을 제시합니다. 파일 관리, 뉴스 모니터링, 웹 스크래핑과 같은 일반적인 기능은 이미 커뮤니티에서 유지 관리하는 스킬 패키지가 존재하며, 이를 로드할 수 있습니다. 터미널 워크플로에서 새로운 스킬을 로드하는 것은 플러그인을 설치하는 것과 거의 동일합니다. 구성 파일에 스킬 패키지의 소스와 매개변수만 지정하면 에이전트가 해당 도구의 기능을 자동으로 가져올 수 있습니다. 커뮤니티의 실천 사례로 Claude Code Video Toolkit은 CLI 환경에 비디오 콘텐츠 이해 기능을 추가합니다. 적용 시나리오는 아직 비교적 제한적이지만, 스킬 패키지를 통해 터미널 에이전트의 기능을 지속적으로 확장할 수 있음을 보여줍니다.

이 과정이 언제 역효과를 낼까요?

이 워크플로에 대한 반대가 상당합니다. 커뮤니티 논의를 바탕으로 볼 때, 문제점은 주로 세 가지 영역에 집중되어 있습니다.

첫 번째 문제는 적용 가능한 사용자 그룹의 범위입니다. 보리스 체르니의 22가지 팁은 사용자가 충분한 아키텍처 분석 능력과 신속한 제약 조건 설정 능력을 갖추고 있음을 전제로 합니다. 시스템 설계를 독립적으로 완료할 수 있는 사람들은 "에이전트가 해야 할 일과 하지 말아야 할 일"의 범위를 명확히 알고 있습니다. 하지만 여전히 IDE 오류 메시지, 코드 강조 표시, 중단점 디버깅을 통해 코드 논리를 이해하는 개발자에게 그래픽 편집기를 끄는 것은 익숙한 정보 획득 채널을 차단하는 것과 같습니다. 이는 능력의 차이가 아니라 작업 방식에서 의존하는 인지 채널의 차이입니다. 초보 개발자는 코드 한 줄씩 디버깅하면서 프로그램 실행 과정에 대한 정신적 모델을 구축하는데, 이러한 학습 과정은 터미널 워크플로에서는 대안이 없습니다.

두 번째 문제는 위험이 집중된다는 점입니다. 기존 IDE에서는 컴파일 오류, 타입 불일치, 런타임 예외 등 오류가 실행 중에 점진적으로 드러납니다. 따라서 사람이 각 단계에서 문제를 발견하고 수정할 기회가 있습니다. 하지만 계획 중심 워크플로에서는 모든 의사 결정 검토가 계획 단계의 단일 노드에 집중됩니다. 이 단계에서 사람의 검토가 충분하지 않으면 에이전트가 작업 단계에서 오류를 정확하고 효율적으로 증폭시킵니다. 결국 오류를 발견할 때쯤이면 이미 여러 파일에 잘못된 로직이 주입되었을 가능성이 높습니다.

세 번째 문제는 맷 밴 혼이 직접 "AI 정신병"이라고 부른 것으로, AI 자체의 결함이 아니라 인간의 오류를 가리킵니다. 에이전트 루프를 구축하는 행위 자체가 전략 게임에서 지속적인 최적화를 통해 얻는 긍정적 피드백 루프처럼 강렬한 지적 쾌감을 유발할 수 있다는 것입니다. 개발자들은 에이전트 워크플로 자체를 개선하는 데 몰두하여 끊임없이 새로운 기술을 시도하고, 새로운 하위 에이전트를 추가하고, 계획 구조를 최적화하면서 근본적인 질문, 즉 사용자에게 실제로 어떤 가치를 제공하고 있는지를 잊어버릴 수 있습니다. 도구가 목적이 되고 사용자의 요구는 부차적인 것으로 전락하는 것입니다.

이 세 가지 질문은 모두 동일한 결론을 가리킵니다. plan.md 기반 터미널 워크플로는 "무엇을 원하는지 명확히 알고 있는" 사용자를 위한 효율성 향상 도구이지, "무엇을 해야 할지 아직 고민 중인" 사용자를 위한 학습 도구가 아닙니다. 이 워크플로의 적용 가능성은 기술 스택 선택에 의해 제한되는 것이 아니라 사용자의 개발 단계에 따라 달라집니다. 이미 완벽한 시스템 아키텍처를 설계해 놓은 사용자라면 이 워크플로를 통해 실행 속도를 획기적으로 향상시킬 수 있습니다. 하지만 코드를 작성하면서 문제를 이해하는 단계라면 IDE의 시각적 피드백 시스템은 당분간 버리지 말아야 할 중요한 도구입니다.

현재 이 워크플로의 핵심 구성 요소에는 런타임 환경 계층의 Claude Code CLI 또는 Codex CLI, 프로세스 관리 계층의 Compound Engineering 플러그인, 그리고 스킬 확장 계층의 last30days-skill 및 agentmail과 같은 프로젝트가 포함됩니다. 이러한 구성 요소들은 모두 빠르게 개선되고 있으며, 명령 형식, 파일 규칙 및 플러그인 시스템은 변경될 수 있습니다. 따라서 이 분야에 진입하는 개발자들은 전체 워크플로가 아직 초기 구현 단계에 있고 "안정적인 툴체인"의 기준을 충족하기에는 멀었기 때문에, 직면하게 될 문제점들에 대해 커뮤니티 차원의 해결책이 아직 없을 수 있다는 점을 받아들여야 합니다. 그러나 바로 이러한 시기가 선구자들이 인지적 우위를 확보할 수 있는 절호의 기회입니다.