솔직히 말하겠습니다. 당신의 Devin (for Terminal) 사용법은 틀렸습니다

도발적인 제목이라 죄송합니다. 하지만, Devin for Terminal (devin CLI)을 사용하기 시작한 많은 분이 "우수한 AI에게 대충 다 맡겨버렸다가, 쏟아져 나오는 방대한 차분(diff)에 지쳐버리는" 동일한 벽에 부딪힙니다. 저도 그랬습니다.

여기서 의식을 바꿀 필요가 있습니다. Devin은 **"3분이면 기억을 잃는, 매우 우수하지만 문맥(context)을 갖지 못한 신입 사원"**이라고 생각하십시오. 능력은 높습니다. 하지만 이쪽에서 문맥과 단계(step)를 설계해 주지 않으면, 아무렇지도 않게 엉뚱한 방향으로 달려갑니다.

이 기사에서는 흔히 발생하는 **7가지 "잘못된 사용법"**과 그 교정 방법을 제시합니다. 모든 내용은 실제 기기(devin 2026.5.x)와 공식 문서에서 확인된 기능으로만 구성되어 있습니다.

가장 먼저 저지르기 쉬운 실수는, 프로젝트의 규칙을 작성하는 Rules에 이것저것 너무 많이 집어넣는 것입니다. "코딩 규약", "디렉토리 구성", "과거의 모든 트러블 슈팅"…….

그 마음은 이해하지만, Rules는 **매번 읽히는 고정 비용(fixed cost)**입니다. 내용이 불어날수록 노이즈가 늘어나고, 정작 중요한 지시사항이 묻혀버립니다.

교정 방법: Rules는 최소한으로. 절차는 Skills로 분리한다.

Rules… "항상 지켜줬으면 하는 소수의 원칙"만 -
Skills… "특정 작업을 할 때만 호출하는 절차서" (SKILL.md)

"릴리스 절차", "특정 API 호출 방법"과 같이 가끔씩만 사용하는 지식은 상시 읽게 하는 Rules가 아니라 Skills에 둡니다. 이렇게 하면 필요한 때에만 문맥에 포함되므로, 평소의 대화가 가벼워집니다.

제 Rules도 어느샌가 과거의 트러블 대응 메모로 비대해져 있었습니다. 절반 정도를 Skills로 옮겼더니 평소의 응답이 눈에 띄게 솔직해졌습니다. 이것이 제가 이 재검토를 권장하는 가장 큰 이유입니다.

자세한 내용은 별도 기사 「Rules·Skills·Plugins로 프로젝트의 규칙을 학습시키기」에서 심도 있게 다루고 있습니다.

"이 버그 고쳐주고, 하는 김에 테스트도 짜고, 리팩토링도 하고, 문서도 업데이트해 줘" —— 마음은 이해합니다. 하지만 이것은 인간 신입 사원에게 시켜도 에러가 날 방식의 부탁입니다.

문맥이 뒤섞이고, AI의 주의력이 분산되며, 리뷰하기 어려운 거대한 차분(diff)이 돌아옵니다.

교정 방법: Subagents로 책임을 나눈다.

Devin for Terminal은 Subagents (.devin/agents/<profile>/AGENT.md)를 통해 역할이 다른 에이전트를 정의할 수 있습니다.

"구현 담당", "리뷰 담당", "조사 담당"을 나누면 각 에이전트의 문맥이 깔끔하게 유지됩니다. 하나의 대화에 모든 것을 짊어지게 하지 마십시오. 이것만으로도 결과가 안정됩니다.

실제 작성법은 「Subagents 실전: reviewer와 researcher 작성하기」를 참조하십시오.

Devin은 대화가 길어지면 문맥을 요약 압축하는 **컴팩션 (Compaction)**을 수행합니다. 이를 수동으로 실행하는 것이 /compact입니다.

여기서 흔히 하는 실수는, 구현이 절정에 달했을 때 "무거워진 것 같으니까"라며 /compact를 입력해 버리는 것입니다. 요약 과정에서 바로 지금 필요한 세세한 문맥이 깎여 나가고, AI가 "어라, 내가 뭘 하고 있었지?" 상태가 됩니다.

교정 방법: 압축은 "구분 지점"에서만. 상태는 /context로 확인한다.

/context … 현재 컨텍스트 사용량을 확인한다 -
/compact … 압축을 강제한다 (태스크의 전환점에서) -
/clear (/new) … 대화 이력을 지우고 새로운 세션을 시작

구현 도중이 아니라, 한 태스크가 끝나는 구분 지점에서 /compact 또는 /clear를 수행하십시오. 그리고 "무엇을·왜·어떻게 진행할 것인가"라는 계획은 대화의 기억에 의존하지 말고 파일로 남기십시오. AI의 단기 기억을 신뢰하지 않는 것이 철칙입니다.

사실 저도 리팩토링의 절정 단계에서 무심코 /compact를 입력한 적이 있습니다. 직전까지 쥐고 있던 "어떤 파일을 어떻게 고칠 것인가"에 대한 세부 사항이 요약 과정에서 날아가 버렸고, Devin이 갑자기 엉뚱한 변경을 시작하는 것을 보고 아찔했습니다. 그 이후로 압축은 태스크의 전환점에서만 한다고 결심했습니다.

편리하다고 해서 사용할지 안 할지도 모르는 MCP 서버를 닥치는 대로 연결하고 있지는 않습니까? MCP는 연결할수록 도구 정의가 문맥을 잡아먹고, AI의 선택지를 불필요하게 늘립니다.

교정 방법: 필요한 것만. 불필요한 것은 disable로 차단한다.

Devin for Terminal은 MCP 서버를 **삭제하지 않고 무효화(disable)**할 수 있습니다.

커맨드	내용
devin mcp list	설정된 서버 목록
devin mcp disable <name>	삭제하지 않고 무효화
devin mcp enable <name>	무효화된 것을 활성화

"평소에는 최소 구성으로. GitHub 조작을 하는 날에만 enable 한다" —— 이 정도로 범위를 좁혀서 운용하는 편이 AI의 정밀도와 체감 성능을 높여줍니다. 채우는 것은 쉽지만, 덜어내는 것은 용기가 필요합니다.

가장 뿌리 깊은 문제는 이것입니다. "적당히 괜찮은 인증 기능을 만들어줘"라며 설계 자체를 통째로 던지는 것입니다. 돌아오는 결과물은 "그럴싸해 보이는 무언가"일 뿐이며, 결국 다시 작업해야 합니다.

AI는 구현은 빠르지만, 당신의 프로덕트가 가진 의도나 제약 사항은 알지 못합니다. 설계는 문맥을 가장 잘 파악하고 있는 인간이 쥐고 있어야 하는 영역입니다.

교정 방법: /plan・/ask를 통해 "합의한 후 구현"한다.

Devin for Terminal에는 코드를 작성하지 않는 **읽기 전용 모드 (read-only mode)**가 있습니다.

모드	역할	코드 작성 여부
/ask <질문>	기존 코드 이해 및 질문 (one-shot)	작성하지 않음
/plan	구현 전 계획 및 설계 (읽기 전용)	작성하지 않음 (제안만 수행)
/normal	일반적인 구현	작성함

/ask로 현황을 이해하고, /plan으로 방침을 세우게 한 뒤, 인간이 그 방침에 합의한 후에 /normal로 구현을 진행하세요. "통째로 맡겨서 폭주하게 만드는 것"이 아니라 "방침만 확정하고 구현은 맡기는 것". 이 거리감이 사고를 줄여줍니다.

저도 처음에는 "알아서 잘 해줘"라며 통째로 맡겼지만, 돌아오는 것은 아쉬운 수준의 별개 결과물뿐이었고 결국 제가 직접 다시 써야 했습니다. /plan으로 방침을 먼저 내놓게 하는 습관을 들인 이후, 재작업이 눈에 띄게 줄어드는 것을 실감하고 있습니다.

이 진행 방식에 대해서는 "갑자기 쓰게 하지 마세요: /plan・/ask로 안전하게 진행하기"에서 자세히 다루고 있습니다.

AI가 작성한 코드를 제대로 읽지도 않고 머지(merge)하고 있지는 않나요? "돌아가니까 됐어"라는 태도를 유지하면, 아무도 이해하지 못하는 코드베이스가 조용히 자라나게 됩니다.

교정 방법: diff를 작게 유지하고, 리뷰를 시스템화한다.

• diff를 작게: 실수 ②에서 언급한 것처럼 태스크를 분할하면 리뷰하기 쉬운 단위가 됩니다.
• 전담 리뷰어: 실수 ②의 reviewer Subagent에게 1차 리뷰를 맡기고, 인간은 요점만 확인합니다.
• 위험한 조작은 Hooks로 기계적으로 차단: PreToolUse 훅을 통해 rm -rf나 push --force를 자동으로 차단합니다.

AI에게 맡길수록 인간의 리뷰 책임은 오히려 무거워집니다. 이 부분을 시스템으로 뒷받침하는 것이 안전하고 빠르게 회전시키는 비결입니다.

Hooks 설계에 대해서는 "Hooks로 '위험한 커맨드'를 자동으로 차단하기"를 참조하세요.

아침부터 밤까지, 하나의 세션에서 이것저것 다 하는 것. 이것도 전형적인 안티 패턴(anti-pattern)입니다. 이전 태스크의 문맥이 계속 남아 있어, AI가 과거의 내용에 휘말려 정밀도가 떨어지게 됩니다.

교정 방법: 태스크 완료 시 세션을 전환한다.

조작	용도
/clear (/new)	히스토리를 지우고 새 세션 시작
devin -c / --continue	직전 세션을 재개 (계속 진행하고 싶을 때만)
devin -r <ID> / --resume	특정 세션을 재개
/fork [step]	원본을 더럽히지 않고 분기하여 다른 안을 시도

기본은 "1태스크 = 1세션"입니다. 끝나면 /clear를 하세요. 계속 작업이 필요할 때만 -c 또는 -r로 돌아옵니다. "이건 도박인데" 싶은 구현을 하기 전에는 /fork로 분기하여, 실패하더라도 원래의 대화를 무사하게 보존하세요.

저 역시 아침에 시작한 세션을 저녁까지 끌고 가다가, 상관없는 이전 태스크 이야기를 다시 꺼내는 바람에 곤혹스러웠던 적이 여러 번 있습니다. 지금은 태스크 하나가 끝날 때마다 /clear로 기계적으로 끊어주고 있는데, 그런 식의 "끌려감" 현상이 거의 사라졌습니다.

그리고 다시 한번 강조하지만, 문맥은 세션이 아니라 파일에 남겨야 합니다. 세션은 일회용으로, 지식은 리포지토리(repository)에 두는 것입니다.

세션 조작에 대한 상세 내용은 "대화를 되돌리거나 분기하여 시행착오 겪기"에 정리해 두었습니다.

#	잘못된 사용법	해결 방법
①	Rules를 너무 많이 포함함	최소한으로 유지. 절차는 Skills로
②	하나의 지시(instruction)에 여러 태스크 포함	Subagents로 책임 분리
③	구현 도중에 /compact 사용	구분점으로만 사용. /context로 모니터링하고, 계획은 파일로
④	MCP를 전부 다 활성화함	필요한 만큼만. devin mcp disable로 비활성화
⑤	설계까지 통째로 맡김	/plan · /ask로 합의한 후 구현
⑥	리뷰를 생략함	diff를 작게 유지 + reviewer Subagent + Hooks
⑦	동일 세션을 장기간 사용	/clear로 전환, /fork로 분기, 문맥은 파일로

모든 것에 공통되는 것은, "코드를 쓰게 하는 도구"에서 "태스크를 위임하는 상대"로의 인식 전환입니다. Devin은 우수하지만, 문맥을 갖지 못한 신입 사원이기도 합니다. 절차와 가드레일 (guardrail)을 설계해 준다면, 그 능력은 단번에 살아납니다.

"전부 맡기기"를 그만두고, "방침은 잡고 · 구현은 맡기고 · 검증은 시스템으로". 이것만으로도 Devin과의 개발 경험은 완전히 달라집니다. 신경 쓰이는 실수부터 하나씩, 가지고 계신 devin으로 직접 고쳐보시기 바랍니다.