Devin AI 사용법: 로컬 CLI, 클라우드 에이전트, PR 리뷰를 나눠 써야 하는 이유

Devin AI는 또 하나의 AI 코딩 CLI가 아닙니다. 로컬에서 바로 고칠 일과, 클라우드에 맡겨 PR까지 받을 일을 나눠 쓰는 도구입니다. 이 구분을 못 하면 기능은 많아 보이는데 실제 워크플로는 더 복잡해집니다.

Cursor, Claude Code, GitHub Copilot에 익숙한 개발자라면 Devin을 처음 볼 때 헷갈릴 수 있습니다. 터미널에서도 돌고, 웹에서도 돌고, PR 리뷰도 하고, Slack이나 Linear 같은 업무 도구에도 붙습니다. 그래서 핵심 질문은 “Devin이 좋은가?”가 아니라 “이 작업은 Devin의 어느 부분에 맡겨야 하는가?”입니다.

 

로컬 터미널에서 시작한 코드 작업이 클라우드 작업 공간과 PR 리뷰 흐름으로 이어지는 개발 워크플로를 표현한 이미지

 

Devin은 하나의 도구가 아니라 세 가지 작업 공간에 가깝다

Devin은 로컬 CLI 에이전트, 클라우드 소프트웨어 엔지니어, PR 리뷰 도구를 하나의 흐름으로 묶으려는 개발 플랫폼입니다.

공식 Devin for Terminal 소개도 로컬에서 시작해 클라우드로 넘기는 방향을 전면에 둡니다. 이 흐름이 Devin의 성격을 가장 잘 설명합니다. 로컬 CLI만 보면 Claude Code 같은 도구처럼 보이지만, /handoff 이후 클라우드 세션이 저장소를 가져가 작업하고 PR을 만드는 지점에서 성격이 달라집니다.

크게 세 조각으로 보면 이해가 쉽습니다.

• Devin for Terminal: 내 프로젝트 폴더에서 바로 쓰는 로컬 CLI 에이전트
• Devin Cloud: 별도 클라우드 환경에서 오래 걸리는 작업을 수행하고 PR까지 만드는 에이전트
• Devin Review: GitHub PR을 구조화해 읽고, 버그 가능성과 변경 의도를 검토하는 리뷰 도구

 

여기에 Windsurf IDE, Playbooks, Scheduled Sessions, Slack, Linear, Jira, Secrets 같은 팀 기능이 붙습니다. 즉 Devin은 단순한 코드 생성기라기보다, AI 에이전트를 개발 업무 흐름 안으로 넣기 위한 도구 묶음입니다.

 

 

로컬 CLI는 빠른 수정과 맥락 확인용으로 쓰는 편이 좋다

처음에는 devin 명령으로 프로젝트 폴더 안에서 세션을 시작합니다. 공식 Essential Commands 기준으로 기본 흐름은 단순합니다.

devin
devin -- add a login page
devin -p "list all TODO comments"

 

devin은 대화형 세션을 열고, devin -- ...는 초기 프롬프트를 넣어 시작하며, devin -p는 한 번만 답을 받고 끝내는 방식입니다. 스크립트나 자동화에서 짧게 호출하고 싶다면 -p가 더 잘 맞습니다.

실제 코딩에서는 터미널만 띄워두는 것보다 IDE 안에서 쓰는 편이 낫습니다. Devin이 파일을 만들고 고칠 수 있기 때문에, 옆에서 diff와 파일 구조를 봐야 판단이 빠릅니다. Windsurf를 써도 되고, VS Code나 Cursor 안의 터미널에서 실행해도 됩니다.

파일을 직접 가리킬 때는 @가 중요합니다. 예를 들어 @index.html을 입력하면 현재 작업 폴더 안의 파일을 컨텍스트로 넣고, 그 파일을 기준으로 수정 요청을 할 수 있습니다. 이 작은 기능이 없으면 모델이 어느 파일을 말하는지 추측하게 됩니다.

이미 Cursor의 에이전트 중심 흐름이 궁금하다면 이전에 정리한 Cursor 3.0 글을 같이 보면 Devin의 방향도 더 잘 보입니다. 둘 다 개발자를 코드 작성자에서 에이전트 관제자 쪽으로 밀어 올리는 도구입니다.

 

로컬 CLI 작업, 클라우드 위임, PR 리뷰를 세 단계로 나눠 보여주는 Devin AI 워크플로 다이어그램

 

권한 모드는 생산성보다 먼저 정해야 한다

Devin for Terminal을 제대로 쓰려면 권한 모드를 대충 넘기면 안 됩니다. 모드 하나가 작업 속도와 위험도를 동시에 바꿉니다.

처음 보는 저장소라면 Normal이 낫습니다. 읽기 외 작업마다 확인을 요구하므로 느리지만, 예상 밖의 파일 수정이나 명령 실행을 막기 쉽습니다.

평소 개발 작업에는 Accept Edits가 가장 균형이 좋습니다. 파일 수정은 자동으로 받아들이되, 명령 실행이나 더 위험한 액션은 멈춰서 확인할 수 있습니다.

Bypass는 정말 좁고 안전한 작업에서만 쓰는 편이 좋습니다. 이름은 편해 보이지만, 실질적으로 이 세션의 판단을 꽤 넓게 믿겠다는 뜻입니다. 테스트 없는 대규모 리팩터링, 마이그레이션, 삭제 작업, 환경 변수나 배포 명령이 섞인 작업에는 어울리지 않습니다.

Claude Code의 Plan/Ask/Code 흐름과 비슷한 사고방식이 필요하다면 Claude Code 모드 차이 글도 참고할 만합니다. 도구 이름은 달라도 핵심은 같습니다. AI가 빨리 움직일수록, 언제 멈추게 할지 정해야 합니다.

 

 

세션 기억을 믿지 말고, 규칙 파일을 믿어야 한다

AI 코딩 도구를 쓰다 보면 “아까 말했잖아”라는 순간이 자주 옵니다. Devin도 예외가 아닙니다. 새 세션은 이전 대화를 자동으로 이어받는다고 가정하면 안 됩니다.

필요한 명령은 이 정도입니다.

devin -c
devin -r
/clear
/new
/compact

 

devin -c는 현재 디렉터리의 가장 최근 세션을 이어가고, devin -r은 최근 세션 목록에서 골라 재개합니다. /clear와 /new는 대화 기록을 비우고 새로 시작합니다. /compact는 긴 대화를 요약해 컨텍스트를 줄입니다.

여기서 중요한 판단이 있습니다. 컨텍스트가 너무 길어지면 모델은 느려지고, 놓치는 것이 늘어납니다. 그렇다고 무작정 새 세션을 열면 프로젝트 규칙까지 사라집니다. 그래서 AGENTS.md 같은 규칙 파일이 중요합니다.

공식 AGENTS.md 문서는 이 파일을 AI 에이전트를 위한 README처럼 설명합니다. 프로젝트 루트에 짧게 두고, 모델이 틀리면 비용이 커지는 규칙만 적는 편이 좋습니다.

# AGENTS.md

- Package manager: pnpm
- Framework: Next.js App Router
- Run tests with: pnpm test
- Use server actions for mutations unless there is a clear reason not to.
- Do not edit generated files.
- Keep UI copy in Korean.

 

길게 쓰는 것이 목적이 아닙니다. 매번 다시 말하기 싫은 규칙만 남겨야 합니다. Devin은 AGENTS.md뿐 아니라 기존 Claude, Cursor, Windsurf 계열 규칙 파일도 활용할 수 있으므로, 이미 운영하던 AI 코딩 규칙이 있다면 새로 시작할 필요가 줄어듭니다.

 

 

모델 선택은 “제일 똑똑한 모델” 문제가 아니다

Devin for Terminal은 /model로 모델을 바꿀 수 있습니다. 여기서 흔한 실수는 무조건 가장 강한 모델을 고르는 겁니다.

실전에서는 이렇게 나누는 편이 낫습니다.

• 단순 파일 수정, 스타일 정리, 작은 기능 추가: 빠른 SWE 계열 모델
• 여러 파일을 넘나드는 리팩터링: 더 강한 reasoning 모델
• 제품 판단, 아키텍처 설계, 오래된 코드 파악: 비용이 들더라도 강한 모델
• 대량 반복 작업: 빠른 모델로 나누고, 마지막 검수만 강한 모델

 

Cognition의 SWE-1.6 preview 글은 벤치마크 점수뿐 아니라 모델 UX, 과도한 자기검증, 반복 행동 같은 문제를 같이 이야기합니다. 이 지점이 중요합니다. 코딩 에이전트는 정답률만으로 평가하기 어렵습니다. 너무 느리거나, 확인을 너무 많이 하거나, 같은 도구를 반복 호출하면 실제 개발 흐름에서는 손해입니다.

따라서 모델 선택은 성능 경쟁이 아니라 작업 경제성의 문제입니다. 간단한 수정에 비싼 모델을 쓰면 낭비이고, 위험한 구조 변경에 빠른 모델만 쓰면 검수 비용이 커질 수 있습니다.

 

 

Subagents는 병렬화 도구이지 마법 버튼이 아니다

Subagents는 여러 작업을 동시에 돌릴 수 있게 해줍니다. 예를 들어 랜딩 페이지 A/B/C안을 만들거나, 독립적인 세 페이지를 각각 정리하거나, 서로 다른 버그 원인을 병렬로 조사할 때 유용합니다.

하지만 같은 파일을 여러 subagent가 동시에 만지게 하면 오히려 일이 늘어납니다. 최종 diff를 합치고, 충돌을 해결하고, 서로 다른 스타일을 맞추는 비용이 생기기 때문입니다.

좋은 subagent 작업은 이렇게 생겼습니다.

• A 에이전트는 인증 흐름만 조사한다
• B 에이전트는 결제 테스트 실패 원인만 찾는다
• C 에이전트는 문서와 README만 정리한다

 

나쁜 subagent 작업은 이렇게 생겼습니다.

• 다 같이 전체 코드를 더 좋게 만든다
• 각자 알아서 리팩터링한다
• 앱 전체를 예쁘게 만든다

 

AI 에이전트가 여러 개가 되면 생산성이 늘어나는 것이 아니라 조율 비용도 같이 늘어납니다. Devin을 잘 쓰려면 병렬화할 수 있는 일을 먼저 쪼개야 합니다.

/handoff는 “큰 작업”보다 “검증 가능한 작업”에 맞다

Devin의 가장 큰 차별점은 클라우드 handoff입니다. 로컬 터미널에서 작업하다가 /handoff로 클라우드 에이전트에게 넘기면, 에이전트가 별도 환경에서 계속 작업하고 PR까지 만들 수 있습니다.

여기서 많은 사람이 기준을 잘못 잡습니다. 작업이 크니까 클라우드로 넘기는 것이 아닙니다. 더 정확히는 작업이 충분히 검증 가능하니까 클라우드로 넘기는 것입니다.

핵심 기준은 간단합니다. 클라우드 handoff는 오래 걸리는 작업이 아니라, PR diff와 테스트 결과로 검증할 수 있는 작업에 써야 합니다.

 

클라우드에 맡기기 좋은 작업은 다음 조건을 갖습니다.

• GitHub 저장소가 연결되어 있다
• 실행해야 할 테스트나 검증 명령이 분명하다
• 변경 범위가 설명 가능하다
• 성공 조건이 적혀 있다
• secret, env, 외부 서비스 접근이 준비되어 있다
• 실패했을 때 PR diff로 판단할 수 있다

 

반대로 다음 작업은 handoff 전에 정리해야 합니다.

• 전체적으로 개선해줘
• 성능 좀 좋게 해줘
• 우리 서비스에 맞게 알아서 만들어줘
• 배포까지 해줘, 라고 했지만 secret과 권한이 준비되지 않은 경우
• 테스트가 없고, 성공 여부를 사람 눈으로만 봐야 하는 경우

 

클라우드 에이전트는 노트북을 닫아도 계속 일할 수 있다는 점이 강합니다. 하지만 그 강점은 지시가 선명할 때만 살아납니다. 모호한 지시를 오래 실행하게 만들면, 더 긴 시간 동안 더 애매한 PR이 만들어질 수 있습니다.

 

 

Devin Review는 생성 속도가 만든 리뷰 병목을 다룬다

AI 코딩 도구를 쓰면 코드 작성 속도는 빨라집니다. 그다음에 바로 생기는 병목은 리뷰입니다. diff가 커지고, 파일 이동과 복사, 자동 생성 코드가 섞이면 사람이 PR을 읽는 비용이 커집니다.

Devin Review는 이 문제를 겨냥합니다. GitHub PR을 더 읽기 쉬운 단위로 묶고, 복사/이동을 감지하고, 버그 가능성을 짚는 식입니다. 지원되는 PR이라면 github.com PR URL의 도메인을 devinreview.com으로 바꿔 접근하는 방식도 안내되어 있습니다.

중요한 것은 Devin Review가 사람 리뷰를 대체하지 않는다는 점입니다. 오히려 AI가 만든 diff를 사람이 더 빨리 의심하고 확인하게 해주는 보조 장치에 가깝습니다.

특히 이런 PR에서 쓸 만합니다.

• 파일 수가 많지만 변경 의도는 하나인 PR
• 코드 이동과 실제 로직 변경이 섞인 PR
• AI 에이전트가 만든 대형 diff
• 보안, 권한, 데이터 처리 변경이 포함된 PR
• 리뷰어가 전체 맥락을 빠르게 파악해야 하는 PR

 

여기서 검수 태도가 바뀝니다. AI가 만든 코드는 빨리 만들어졌으니 빨리 머지하는 대상이 아니라, 빨리 만들어졌으니 더 구조적으로 의심해야 하는 대상입니다.

 

 

팀 기능은 자동화 욕심보다 반복 작업의 안정성이 먼저다

Devin Cloud에는 Playbooks, Scheduled Sessions, Secrets, Slack, Linear, Jira 같은 기능이 붙습니다. 이 기능들은 멋있어 보이지만, 처음부터 다 켜는 방식은 추천하기 어렵습니다.

Playbook은 반복 작업용 지시서입니다. 예를 들어 매번 같은 방식으로 dependency update PR을 만들기, 특정 라이브러리를 우리 코드 스타일에 맞게 통합하기, 릴리스 전 점검하기 같은 일에 맞습니다.

Scheduled Sessions나 Automations는 정해진 조건에 따라 Devin 세션을 예약하거나 반복 실행하는 기능입니다. 여기서 중요한 것은 매일 돌린다는 사실보다 언제, 어떤 조건에서, 누가 결과를 볼 것인가입니다.

Slack이나 Linear/Jira 연동도 마찬가지입니다. Linear issue를 Devin에게 assign하면, Devin이 계획을 만들고 작업을 진행하고 상태를 옮기는 흐름을 만들 수 있습니다. 이건 꽤 강력합니다. 다만 issue가 나쁘면 결과도 나쁩니다. 사람에게도 모호한 티켓은 AI에게도 모호합니다.

MCP나 외부 도구 연결까지 넓히려면, 먼저 AI가 어떤 시스템을 어떤 권한으로 봐야 하는지 정해야 합니다. 이 배경은 MCP server 정리 글과 같이 보면 더 자연스럽습니다.

 

 

어떤 상황에서 무엇을 써야 할까

Devin을 기능 목록으로 외우면 금방 피곤해집니다. 아래 기준으로 나누는 편이 실전적입니다.

 

상황	추천하는 Devin 사용 방식	주의할 점
작은 파일 수정	Devin for Terminal	@file로 범위를 좁히기
새 기능 초안	Terminal + Accept Edits	diff를 바로 보면서 진행
긴 테스트/반복 작업	/handoff로 Cloud 위임	테스트 명령과 성공 조건을 명시
대형 PR 이해	Devin Review	사람 리뷰를 생략하지 않기
반복되는 팀 작업	Playbook	먼저 한두 번 수동으로 안정화
정기 점검	Scheduled Sessions 또는 Automations	노이즈 PR이 생기지 않게 설계
이슈 기반 작업	Linear/Jira 연동	티켓의 acceptance criteria를 구체화
채팅 기반 요청	Slack 연동	권한과 채널 노출 범위 확인

 

이 표의 핵심은 하나입니다. Devin은 일을 줄여주는 도구지만, 일을 정의해주지는 않습니다. 범위, 성공 조건, 검증 방법이 없으면 에이전트가 오래 움직일수록 불확실성도 같이 커집니다.

 

 

처음 도입한다면 이 순서가 안전하다

처음부터 Slack, Linear, Scheduled Sessions까지 한 번에 붙이지 않는 편이 좋습니다. 작은 흐름에서 성공 경험을 만든 뒤 넓히는 것이 낫습니다.

1. 로컬 프로젝트에서 devin을 실행해 작은 파일 수정부터 시도합니다.
2. Accept Edits를 기본으로 쓰고, shell command는 계속 확인합니다.
3. 프로젝트 루트에 짧은 AGENTS.md를 만듭니다.
4. @file 멘션으로 수정 범위를 좁히는 습관을 들입니다.
5. 테스트 명령이 분명한 작은 이슈 하나만 /handoff로 넘겨봅니다.
6. 생성된 PR을 직접 리뷰하고, Devin Review로 보조 검토를 붙입니다.
7. 반복 작업이 안정화된 뒤에 Playbook이나 Scheduled Sessions/Automations를 만듭니다.
8. 팀 티켓 품질이 충분해진 뒤 Slack/Linear/Jira 연동을 붙입니다.

 

이 순서의 장점은 실패가 작다는 것입니다. AI 코딩 도구는 한 번에 크게 도입할수록 실패 원인을 찾기 어렵습니다. 로컬에서 작은 성공을 만들고, 클라우드 위임으로 넓히고, 마지막에 팀 워크플로로 올리는 편이 훨씬 안전합니다.

 

 

Devin을 쓸 때 가장 많이 놓치는 실패 포인트

Devin 자체보다 프롬프트와 저장소 준비가 더 큰 병목일 때가 많습니다.

첫째, 테스트가 없으면 클라우드 위임의 가치가 크게 줄어듭니다. Devin이 PR을 만들어도 성공 여부를 자동으로 확인하기 어렵기 때문입니다.

둘째, secret과 환경 변수가 준비되지 않으면 클라우드 세션은 로컬과 다른 세계에서 헤맬 수 있습니다. Secrets 문서를 따로 확인해야 하는 이유입니다.

셋째, AGENTS.md가 너무 길면 규칙 파일이 아니라 잡음 파일이 됩니다. 모델이 매번 읽어야 하는 문서는 짧고 날카로워야 합니다.

넷째, subagents를 과하게 쓰면 병렬화보다 병합 비용이 커질 수 있습니다.

다섯째, Bypass를 생산성 기능으로만 보면 위험합니다. 저장소 범위, 명령 실행, 네트워크 접근, 삭제 작업이 섞이면 사람의 승인 지점이 필요합니다.

여섯째, Devin Review를 “리뷰 완료”로 착각하면 안 됩니다. AI 리뷰는 의심 지점을 정리해주는 도구이지, 책임을 가져가는 리뷰어가 아닙니다.

 

 

결론: Devin의 가치는 위임할 수 있는 개발 업무를 늘리는 데 있다

Devin은 코드 한 줄을 더 빨리 쓰게 해주는 도구만은 아닙니다. 더 중요한 변화는 개발자가 로컬에서 같이 작업하다가, 충분히 명확해진 일을 클라우드 에이전트에게 넘기고, PR과 리뷰 흐름으로 다시 받는 구조입니다.

그래서 Devin을 평가할 때는 “Claude Code보다 좋은가”, “Cursor보다 나은가”보다 다른 질문이 필요합니다.

• 이 작업은 로컬에서 같이 봐야 하는가?
• 클라우드에 맡겨도 될 만큼 성공 조건이 분명한가?
• PR로 결과를 검수할 수 있는가?
• 리뷰 병목을 줄이는 장치가 있는가?
• 팀의 issue, secret, test, 권한 관리가 준비되어 있는가?

 

이 질문에 답할 수 있다면 Devin은 꽤 강력한 도구가 됩니다. 반대로 답하지 못한 채 기능만 켜면, AI가 만든 더 큰 diff와 더 많은 알림만 남을 수 있습니다.

핵심은 단순합니다. 로컬에서는 빠르게 같이 보고, 클라우드에는 명확한 일을 맡기고, 리뷰에서는 더 의심스럽게 읽는 것. Devin은 이 세 가지를 하나의 흐름으로 묶으려는 도구입니다.

 

 

FAQ

 

Devin은 Claude Code나 Cursor를 대체하나요?

완전한 대체라기보다 역할이 다릅니다. Claude Code나 Cursor는 로컬·에디터 중심의 빠른 피드백에 강하고, Devin은 로컬 CLI에서 시작해 클라우드 PR 작업과 리뷰까지 이어지는 위임 흐름이 강합니다.

 

Devin Cloud에 아무 작업이나 맡겨도 되나요?

아닙니다. 테스트 명령, 변경 범위, 성공 조건, 필요한 secret과 권한이 준비된 작업이 적합합니다. 모호한 작업은 먼저 로컬 CLI나 사람의 기획 단계에서 좁힌 뒤 넘기는 편이 안전합니다.