어느 날 밤, 하나의 채팅에 "이 PR의 차분(diff)을 작게 만들어줘", "헤드라인의 톤도 맞춰줘"라고 연달아 부탁한 적이 있었습니다. 돌아온 결과는 동작하는 코드와, 리뷰 코멘트에 섞기 어려운 긴 설명문이었습니다. 지시는 둘 다 맞는 것 같은데, 성공 조건이 두 개가 되면 출력은 어느 쪽도 어중간해집니다.

AI 코딩 에디터를 사용하기 시작하면, 처음에는 "코드를 작성해줘", "이 버그를 고쳐줘"와 같이 하나의 채팅에 무엇이든 부탁하기 쉽습니다. 그래도 동작하는 경우는 많습니다. 다만 작업이 길어질수록 품질의 변동이나, 의도하지 않은 방향으로의 이탈이 늘어납니다.

그럴 때 효과적인 것이 바로 역할(role / subagent / persona)을 나누어 사용하는 방식입니다. Cursor에서는 Custom Modes, Rules, Subagents, Agent Skills와 같은 메커니즘을 통해 "프론트엔드 전용", "리뷰 전용", "기사 집필 전용"과 같은 동작을 미리 정의할 수 있습니다. 본 기사에서는 왜 역할 분할이 품질을 높이는지, 실무에서 어떻게 설계하는지를 과도한 기대 없이 정리합니다.

• Cursor에서 "역할"을 만든다는 것은 무엇인가
• 왜 역할을 나누면 품질이 올라가는가
• 컨텍스트(Context) 혼선을 방지하는 효과
• 전문 프롬프트(Prompt)를 자산으로서 재사용할 수 있다
• 실무에서 사용할 수 있는 역할 분할의 예
• 역할 설계의 팁 (프롬프트에 적을 것)
• 개인 개발에서 팀 운영으로의 확장
• 과하게 하지 않기 위한 경계선
• 오늘부터 시도할 수 있는 최소 단계
• 요약

여기서 말하는 "역할"이란, 에이전트(Agent)에게 매번 처음부터 인격을 다시 설명하는 것이 아닙니다. 특정 작업에 최적화된 지시 세트를 이름이 붙은 상태로 재사용할 수 있는 것을 의미합니다.

Cursor 주변에서는 대략 다음과 같은 계층으로 역할을 표현할 수 있습니다 (제품의 UI 명칭이나 배치는 업데이트되기 쉬우므로 개념으로 파악해 주세요).

제품의 화면 명칭은 변하기 쉬우므로, 위 표는 개념적인 분담입니다. 역할은 모델을 바꾸는 것보다 제약 사항을 두는 위치를 나누는 것에 가깝습니다.

포인트는 모델 자체를 바꾸는 것이 아니라, 같은 모델이라도 입력의 제약과 평가 기준을 고정하는 것입니다. 역할은 "누구에게 부탁할 것인가"의 라벨인 동시에, "무엇을 하지 않을 것인가"의 가드레일(Guardrail)이기도 합니다. 만능인 한 명에게 전부 맡기는 것보다, 특기 영역이 확실한 여러 역할로 나누는 편이 출력의 판단 기준이 안정되기 쉽습니다.

품질이 올라가는 이유는 천재적인 프롬프트 마법이라기보다, 평가 축의 충돌을 줄이는 것에 있습니다.

예를 들어 "외관을 좋게 해줘", "타입 안전(Type-safe)하게 해줘", "바로 머지(Merge)할 수 있도록 작게 수정해줘"를 한꺼번에 부탁하면, 에이전트는 어떤 것을 우선해야 할지 망설이기 쉽습니다. 결과적으로,

• 스코프(Scope) 외의 리팩토링이 섞임
• UI 문구와 구현 상세가 동시에 바뀌어 차분(diff)을 읽기 어려워짐
• "동작함"과 "리뷰 가능한 차분"이 혼동됨

과 같은 일이 일어납니다.

역할을 나누면 각 채팅(또는 각 에이전트)에 단일 성공 조건을 전달할 수 있습니다. 프론트엔드 담당이라면 접근성(Accessibility)과 외관의 일관성, 백엔드 담당이라면 도메인 경계와 테스트, 리뷰어라면 수락 조건과의 대조——평가 축이 하나라면 출력의 변동이 줄어듭니다.

이는 인간의 팀과도 비슷합니다. 설계·구현·리뷰를 동시에 한 명에게 쌓는 것보다, 지금 무엇을 우선할지를 나누는 편이 그 상황에서의 판단은 안정되기 쉽습니다. AI도 마찬가지로, 역할 분할의 첫 번째 효과는 "속도"보다, 한 번의 의뢰 안에서 평가 축이 싸우지 않는 것입니다. 재작업에 관한 이야기는 다음 "자산화" 절에서 다루겠습니다.

긴 채팅의 최대 적은 정보 부족보다 정보의 혼선입니다.

같은 스레드에서 "API 설계 논의" → "CSS 미세 조정" → "이용 약관 문구" → "CI 실패 조사" 순으로 진행하면, 중간의 전제가 후속 판단을 오염시킵니다. 에이전트는 대화 이력을 재료로 사용하기 때문에, 오래된 방침이나 다른 도메인의 용어가 관계없는 답변에 섞이기 쉽습니다.

역할 분할은 이 혼선을 구조적으로 줄여줍니다.

• 구현 채팅에서는 코드와 테스트만을 다룬다 -
• 집필 채팅에서는 기사 구성과 독자 경험만을 다룬다 -
• 법무·표현 리뷰는 초안 확정 후 별도의 채팅으로 넘긴다 -
• 인프라 조사는 배포나 네트워크 전제 조건만을 공유한다 -

INTERESTIC의 개발에서도 Web Tool Lab의 구현과 블로그 원고 작성을 동일한 스레드에 올린 적이 있습니다. 그러다 보니 중간부터 코드 차분(diff)에 대한 지적 속에 '독자를 위한 착지(landing)'에 관한 이야기가 섞이면서, 두 작업 모두 어중간해졌습니다. 구현은 차분의 정확성이, 집필은 독자의 다음 액션이라는 성공 조건이 서로 다르기 때문에, 대화 이력은 그대로 오염원이 됩니다. 채팅을 분리하는 것만으로도 서로의 노이즈를 상당히 줄일 수 있습니다.

"같은 모델인데 왜 나누어야 하는가"라는 의문이 들 수도 있습니다. 답은 간단합니다. 모델 능력의 상한선보다 문맥(context)의 순도가 병목 현상이 되는 경우가 많기 때문입니다. 새로운 채팅으로 전환하는 행위 자체가 이미 역할 분할의 첫걸음입니다.

역할을 한 번 제대로 작성해 두면, 그것은 개인의 암묵지에서 재사용 가능한 자산이 됩니다.

매번 "이 리포지토리는 Laravel과 React로 구성되어 있고...", "브랜드명은 INTERESTIC이며...", "커밋은 요청받기 전까지 하지 마라..."라고 다시 쓰는 것은 시간도 걸리고 정밀도도 불안정합니다. 이를 역할(또는 Rules / Skills)로 정립해 두면 다음과 같은 효과를 얻을 수 있습니다.

• 신규 멤버나 미래의 자신이 동일한 품질로 시작할 수 있음
• 실패 패턴(과도한 리팩터링, 비밀 정보 취급 등)을 금지 사항으로 고정할 수 있음
• '좋은 리뷰'의 관점을 체크리스트화할 수 있음

특히 효과적인 것은 부정형 지시입니다. "정성스럽게 써줘"보다는 "검증되지 않은 효과를 단정하지 마라", "과도한 홍보를 하지 마라", "범위 외의 파일을 건드리지 마라"와 같은 지시가 출력의 변동성을 억제하기 더 쉽습니다. 역할 프롬프트는 이상적인 인격뿐만 아니라, 현장에서 밟았던 지뢰의 기록이기도 합니다. 잘 작동하는 지시만 남기고, 효과가 없는 미사여구는 깎아내는 반복 작업이 역할을 진정한 자산으로 만듭니다.

처음부터 방대한 역할이 필요하지는 않습니다. 다음 5가지 계통부터 시작하면 개인 개발에서도 팀 단위에서도 사용하기 쉽습니다.

frontend는 UI, 접근성(a11y), 디자인 토큰, 컴포넌트 경계를 담당합니다. 성공 조건은 "외관과 조작성이 기존 패턴을 따르며, 불필요한 장식이 늘어나지 않는 것"입니다. 구현 범위를 프론트엔드 디렉터리로 한정하면 백엔드로의 침범이 줄어듭니다. 외관에 대한 선호를 추상적으로 부탁하기보다 "기존 컴포넌트를 우선할 것"과 같이 프로젝트 고유의 금지 사항을 작성하면 재현성이 높아집니다.

backend는 도메인 계층, API, 검증(validation), 테스트를 담당합니다. "Controller에 비즈니스 로직을 담지 않는다"와 같은 아키텍처상의 제약을 역할에 명시하면 강력한 힘을 발휘합니다. 성공 조건은 "동작이 테스트로 설명 가능하며, 차분(diff)이 리뷰 가능할 것"입니다. 인증이나 데이터 변경을 다룰 때는 영향 범위를 먼저 확인하도록 하면 안전합니다.

infra는 Docker, CI, 배포, 네트워크를 담당합니다. 로컬 환경의 파괴(개발용 설정의 부주의한 덮어쓰기 등)를 금지 사항으로 넣을 가치가 매우 높은 영역입니다. 성공 조건은 "재현 절차가 남고, 명시적 지시가 있을 때까지 운영 작업을 수행하지 않는 것"입니다. 편리함보다는 돌이킬 수 없는 작업을 막는 역할로 설계할 때 제대로 기능합니다.

writer는 블로그나 문서 작성을 담당합니다. 독자, 글자 수, 헤딩(heading) 수, 선동 금지 등을 미리 고정합니다. 성공 조건은 "독자가 다음에 무엇을 시도할 수 있는지 명확하며, 미확인 사실을 단정하지 않는 것"입니다. 구현 채팅과 섞지 않는 것이 철칙입니다. 섞이게 되면 중간부터 '컴포넌트 이야기'가 본문에 섞여 들어가 독자를 위한 착지가 사라질 수 있습니다. SEO를 의식하더라도 키워드 채우기보다는 헤딩의 의도와 도입부의 명확성을 우선하는 것이 독자에게 더 잘 전달됩니다.

reviewer는 구현이나 문장의 리뷰를 담당합니다. 직접 크게 수정하기보다는 수락 조건과의 차분, 리스크, 범위 외 변경 사항을 지적하는 역할로 설정하면 효과적입니다. 성공 조건은 "지적이 검증 가능하며, 우선순위를 알 수 있는 것"입니다. 수정 역할과 리뷰 역할을 나누는 것만으로도 "만든 본인이 자신을 정당화하는" 편향을 줄일 수 있습니다.

필요에 따라 seo-expert나 legal-reviewer와 같은 전문 역할을 추가하면 "모든 것을 한 명의 에이전트에게 떠맡기지 않는" 운영이 더욱 안정화됩니다. 우선 상용하는 소수의 역할을 다듬고, 전문 역할은 필요할 때만 호출하는 정도로 충분합니다.

좋은 역할 프롬프트는 길 필요가 없습니다. 다음 항목들이 포함되어 있는지가 중요합니다.

• 목적 (Purpose): 어떤 일을 하는 역할인지 (1문장)
• 성공 조건 (Success Criteria): 완료되었다고 판단하는 기준
• 금지 사항 (Constraints): 해서는 안 되는 일
• 입력 전제 (Prerequisites): 어떤 정보가 있어야 착수할 수 있는지
• 출력 형식 (Output Format): PR 본문, 체크리스트, Markdown 등
• 에스컬레이션 (Escalation): 판단이 어려울 때 상위 역할이나 사람에게 되돌리는 조건

뼈대만 추출하면 다음의 형태로도 충분한 경우가 많습니다.

# 역할: reviewer (개념 예시)
## 목적
수락 조건과 차이점(diff)을 대조하여 검증 가능한 지적 사항을 반환한다.
...

흔히 하는 실수는 "우수하게 행동하라"라고만 쓰고 평가 축을 모호하게 만드는 것입니다. 역할 이름이 아무리 화려(fancy)해도 성공 조건이 없다면 일반적인 범용 채팅과 큰 차이가 없습니다.

또한, Rules (리포지토리 공통)와 Role (업무 단위)을 너무 섞지 않는 것도 중요합니다. 브랜드 표기나 언어 방침은 공통 Rules에, 프론트엔드 특유의 UI 원칙은 frontend 역할에 배분하면 유지보수가 쉬워집니다. 프롬프트는 한 번 쓰고 끝내는 것이 아니라, 실패를 목격할 때마다 한 줄씩 업데이트하는 운영 방식이 현실적입니다.

개인에게 효과적이었던 역할 설계는 팀에서도 동일한 구조로 확장할 수 있습니다.

• 리포지토리의 Rules를 "팀의 최소 가이드라인"으로 설정
• 리뷰 역할의 체크 관점을 PR 템플릿과 일치시킴
• 집필 역할의 톤을 브랜드 가이드와 연결
• 인프라 역할에 "명시적 지시가 없는 배포 금지"를 포함

이렇게 하면 AI 이용이 개인의 기술(technique)이 아니라, **팀의 작업 프로토콜(protocol)**이 됩니다. 새로 Cursor를 사용하기 시작한 멤버라도 "먼저 reviewer로 차이점을 확인하고, 그 후에 frontend로 수정한다"와 같이 절차를 공유할 수 있습니다.

단, 역할을 너무 많이 늘리면 발견 비용(discovery cost)이 상승합니다. 팀에서는 "상용 3~5개 역할 + 가끔 사용하는 전문 역할" 정도로 억제해야 형식화되는 것을 막기 쉽습니다. 카탈로그를 풍성하게 만드는 것보다, 매주 사용하는 역할을 연마하는 것이 더 효과적입니다. 누가 어떤 역할을 업데이트할지 정해두면 규칙의 노후화도 방지하기 쉽습니다.

역할 분할이 만능은 아닙니다. 다음 사항에 주의해야 합니다.

• 작은 수정까지 역할을 전환하면 느려짐: 오타 수정이나 1개 파일의 명확한 버그는 범용 채팅으로도 충분한 경우가 많음
• 역할 이름이 품질을 보장하지 않음: 성공 조건과 금지 사항이 본체임
• 버전 의존적인 기능명에 너무 얽매이지 말 것: UI는 변할 수 있으므로 "업무 단위의 제약"으로서 설계함
• 인간의 판단을 생략하지 말 것: 보안, 법무, 운영 환경 조작은 최종 확인 단계를 남겨둠

요컨대, 역할은 가속 장치이지 책임의 위임 대상이 아닙니다. 품질에 대한 최종 책임은 여전히 인간 측에 있습니다. 위험한 작업일수록 역할로 차단하고, 안전한 반복 작업일수록 역할로 빠르게 처리하는 것—그 구분(use case)이 중요합니다.

거창한 재설계는 필요 없습니다. 다음 순서로도 충분합니다.

• 자주 하는 업무 3가지를 작성 (예: 구현 / 리뷰 / 글쓰기)
• 각각에 대해 성공 조건과 금지 사항을 5줄 이내로 작성
• Cursor의 Mode / Subagent / Rules 중 하나로 저장
• 1주일간 실행하며, 업무 종류가 바뀌면 채팅(역할)도 변경
• 효과적이었던 금지 사항만 공통 Rules로 승격

첫 성과는 극적인 속도 향상보다는 "이상한 방향으로 진행되는 횟수가 줄었다"는 감각인 경우가 많습니다. 그것으로 충분합니다. 품질은 화려한 한 방이 아니라, 실패의 재현율을 낮춤으로써 쌓여갑니다. 성과가 좋았던 주의 끝에 역할 프롬프트에 한 줄만 추가하는 습관을 가지면 자산화가 진행됩니다.

우선은 frontend / backend / reviewer 3가지 역할로도 충분한 경우가 많습니다. 각각에 성공 조건과 금지 사항을 짧게 쓰고, 구현과 집필은 채팅을 나누어 시도해 보세요.

역할 분할의 효과는 화려하기보다 은근합니다. 평가 축이 충돌하지 않게 되고, 오래된 전제가 다음 판단으로 이어지는 것을 방지하며, 효과적이었던 금지 사항만이 다음 주로 남게 됩니다. 그 축적이 매일의 AI 코딩을 안정시킵니다.

이 기사의 원문 (INTERESTIC 블로그):