에이전트 역할

Coroid는 범용 에이전트를 사용하지 않습니다. 각 단계는설명에서부터 pull request에 이르는 과정은좁은 업무 범위와 엄격히 제한된 도구 세트를 가진 에이전트가 처리합니다.

이러한 제한이 바로 핵심입니다. 코드를 작성할 수 없는 에이전트는 실수로 코드를 작성할 가능성이 없습니다.

역할#

역할	단계	코드 수정 가능 여부
Architect	사양 및 계획 수립	아니요
Developer	빌드	예
QA	검증	아니요
Reviewer	리뷰	아니요
Web tester	브라우저 흐름 검증	아니요
Explorer	연구 및 모든 단계 지원	아니요
Dependency analyzer	분석	아니요

처음 네 가지 역할은 모든 작업에서 확인할 수 있는 배포 에이전트입니다. 표준 모드에서는 다음과 같은 순서로 실행됩니다:

아키텍트 → 개발자 → QA → 리뷰어

코디네이터 모드에서는 작업 진행 중에 코디네이터가 순서를 결정합니다. 두 방식에 대한 설명은 아래에 나와 있습니다.

정확히 하나의 역할인 개발자만이 저장소 내 파일을 수정할 수 있습니다. 그 외의 모든 에이전트는 파일을 읽거나 실행하거나 보고서를 생성하거나 후속 작업을 만들 뿐입니다.

작업이 실행되는 두 가지 방식#

작업은 두 가지 모드 중 하나로 실행됩니다. 해당 모드는AI 프로필및 사용자의 배포 설정에 따라 결정됩니다.

코디네이터 모드.아키텍트는 작성한 계획을 넘겨주고 그냥 떠나지 않습니다. 코디네이터로서 해당 작업에 계속 참여하죠. 계획 수립이 완료되면 코디네이터는 개발자에게 지침을 전달하고 보고서를 기다립니다. 그 후에는 QA에게 구현된 내용을 검증하도록 요청하고, 리뷰어에게는 QA가 통과시킨 결과물을 검토하도록 합니다. 각각의 보고서를 받은 뒤 코디네이터는 다음 단계를 결정합니다: 발견 사항을 개발자에게 다시 전달하거나, 질문에 답변하거나, 계획을 수정하거나, 작업을 종료하는 것이죠. 재작업 역시 코디네이터가 처리하는 또 하나의 단계일 뿐, 별도의 실행 과정으로 분류되지 않습니다.

표준 모드.플랫폼은 작업을 네 개의 에이전트를 통해 고정된 순서대로 진행하며, 검증에 실패하면 작업을 개발자에게 다시 할당합니다. 병합 충돌을 해결하는 경우와 같이 항상 이 방식으로 실행되는 작업도 있으며, 코디네이터 모드를 사용할 수 없을 때의 대체 모드가 바로 표준 모드입니다.

두 모드 모두 동일한 에이전트가 동일한 제약 조건과 동일한 게이트를 적용하여 작업을 수행합니다. 차이점은 다음 단계를 선택하는 주체가 표준 모드에서는 플랫폼이고, 코디네이터 모드에서는 코디네이터라는 점입니다.

코디네이터#

코디네이터는 계획 수립 에이전트로서 해당 작업에 집중합니다. 이 에이전트는 사용자의 코드베이스를 읽기만 할 뿐 수정할 수 없으므로, 수행하는 모든 작업은 오직 방향을 제시하는 역할에 국한됩니다.

코디네이터의 주요 기능#

• 계획코디네이터는 저장소를 탐색한 뒤, 작업 성공 여부를 판단하는 수용 기준을 포함한 계획을 저장합니다.
• 위임합니다.코디네이터는 한 번에 하나의 에이전트와 협업합니다. 지시 사항에는 목표와 특별히 주의를 기울여야 하는 수용 기준, 그리고 작업을 돌려보낼 때 적용해야 할 정확한 수정 사항이 명시됩니다. 에이전트가 작업하는 동안 코디네이터는 대기하며 모델 처리 시간을 사용하지 않습니다.
• 질문에 답변합니다.의사결정이 필요한 상황에 도달한 에이전트는 코디네이터에게 문의할 수 있습니다. 코디네이터는 해당 의사결정 내용과 그 이유를 답변해 주며, 질문이 사람의 개입을 기다리도록 방치되지 않습니다.
• **반응합니다.**QA 단계에서 작업이 실패하거나 리뷰어가 변경을 요청하면, 코디네이터는 수정 사항을 개발자에게 전달하고 QA가 새 버전을 검증합니다.
• 작업을 종료합니다.코디네이터는 작업을 완료하거나 실패시키고 그 이유를 명시합니다.

코디네이터가 할 수 없는 일#

코디네이터는 방향을 제시할 뿐 판단하지 않습니다. 플랫폼이 이러한 제한을 강제하므로 코디네이터의 결정에 의존하지 않습니다:

1. 판단은 QA와 리뷰어의 몫입니다.판단은 오직 QA와 리뷰어만 내립니다. 각각 자체적인 결과를 통해 판단을 내립니다. 코디네이터의 지시에는 판단을 내릴 권한이 없으며, 코디네이터는 체크를 통과로 표시할 수도 없습니다.
2. 완료를 위해서는 조건을 충족해야 합니다.작업은 배포될 정확한 버전(또는 변경 사항이 없는 경우 현재 코드 상태)에 대해 QA가 통과시키고, 리뷰가 필요한 경우에는 리뷰어가 해당 버전을 승인해야만 완료될 수 있습니다. QA 실행 이후에 브랜치가 변경된 경우에는 작업 완료가 거부되며 새 버전은 다시 QA로 넘어갑니다.
3. 재작업 횟수는 제한됩니다.각 에이전트는 작업당 제한된 횟수만 시작될 수 있으며, 계획도 몇 번만 수정할 수 있습니다. 단계 수와 총 실행 시간도 상한이 정해져 있습니다. 한도에 도달하면 코디네이터는 작업을 완료하거나 실패시킬 수밖에 없습니다.
4. 대기 시간도 제한됩니다.모든 대기에는 마감 시한이 설정되어 있습니다.

코디네이터가 관리하는 작업은 세 가지 결과 중 하나로 끝납니다: 귀하가 승인할 pull request 생성, 코드가 이미 작업 요구사항을 충족하여 변경할 필요가 없음을 나타내는 QA의 확인, 또는 실패 이유를 명시한 작업 결과입니다. 담당 에이전트가 작업 완료를 선언했다고 해서 작업이 끝나는 것은 아닙니다.

코디네이터가 취할 수 있는 경로#

코디네이터는 작업이 검증 단계에 도달하는 방식을 결정합니다. 위에 언급된 검증 단계는 모든 경로에서 동일하게 적용됩니다.

• 전체 경로계획 수립, 개발, 검증, 리뷰, 완료. 코디네이터가 다른 경로를 선택할 이유가 없는 한 작업은 이 순서대로 진행됩니다.
• 작업을 다시 전달하기QA에서 작업이 실패하거나 리뷰어가 변경을 요청하면, 수정 사항은 다시 개발자에게 전달됩니다. 새 버전은 작업을 완료하기 전에 반드시 QA를 통과해야 합니다. 이전 버전에서의 통과 결과는 새 버전에 그대로 적용되지 않습니다.
• 이미 완료됨코드가 이미 작업에서 요구하는 기능을 수행할 수 있습니다. 이 경우 코디네이터는 새로운 코드를 작성하는 대신, 기존 코드가 수용 기준을 충족하는지 QA로 하여금 검증하도록 할 수 있습니다. QA가 통과하고 리뷰가 필요한 경우 리뷰어가 승인하면, 병합할 내용이 없으므로 pull request 없이 작업이 완료됩니다. QA의 검증 결과가 최종 결과입니다. 실행 과정에서 변경 사항이 발생하면 이 경로는 더 이상 사용할 수 없는데, 그렇지 않으면 배포용 코드가 아닌 코드에 대해 QA가 통과시키는 상황이 발생하기 때문입니다.

두 가지 짧은 경로는 선택적으로 사용할 수 있습니다. Coroid는 기본적으로 이 경로들을 사용하지 않습니다. 이 경로들은 코디네이터의 경로를 바꾸지만 검증 단계에는 영향을 주지 않습니다.

• 신속한 수정알려진 위치에서의 소규모 수정의 경우, 코디네이터는 더 간소한 계획을 수립하고 변경이 적용될 파일을 명시한 구체적인 지침을 개발자에게 제공합니다. 개발자는 제한된 단계 내에서 작업하며, 해당 파일 외부에서 이루어진 변경 사항은 QA와 리뷰어에게 보고됩니다.
• 제한적인 재검토QA 또는 리뷰어가 발견한 문제에 대한 소규모 수정 이후에는, QA가 해당 발견 사항과 프로젝트의 테스트를 기반으로 검증을 시작합니다. 다만 QA는 여전히 전체 새 버전에 대한 판정을 내립니다.

리뷰어가 필수인 경우#

기본적으로 단독으로 실행되는 작업은 항상 리뷰어의 검토를 거칩니다. 코디네이터가 어떤 경로를 선택하든, 변경 사항이 없더라도 QA가 통과시킨 버전을 리뷰어가 승인하기 전까지는 작업을 완료할 수 없습니다. QA는 리뷰 유무와 관계없이 항상 검증을 수행하며, 리뷰는 QA의 통과를 대체하지 않습니다. 계획의 일부인 작업은 해당 경로의 규칙을 따릅니다.

Coroid에는 선택적인 위험 기반 정책도 존재하며, 기본적으로 활성화되어 있지는 않습니다. 이 정책에 따라 단독으로 실행되는 작업은 변경 사항이 작고 일반적인 경우 리뷰어 없이 완료될 수 있습니다. 다음의 경우에는 여전히 리뷰어가 필수입니다:

• 작업에 대해 이미 리뷰어가 지정되었거나, 프로젝트의 리뷰 규칙 또는 조직의 품질 관리 정책에서 리뷰어를 요구하는 경우;
• 변경 사항이 인증, 세션, 권한, 비밀번호 또는 암호화 관련 기능, 데이터베이스 마이그레이션, 빌드 및 배포 설정, 의존성 파일, 또는 외부 서비스와 연동되는 코드에 영향을 미치는 경우;
• 변경 사항이 대규모(기본적으로 변경된 줄 수가 80줄 초과)이거나 바이너리 파일, 심볼릭 링크 또는 서브모듈을 포함하는 경우;
• Coroid는 정책이나 변경 사항 자체를 판단할 수 없습니다. 불확실한 경우에는 반드시 리뷰어가 필수입니다.

변경 사항이 전혀 없는 경우에는 리뷰어가 필요하지 않습니다. 이 결정은 코디네이터가 아닌 코드에 의해 내려지며, 코디네이터가 이를 무시할 수는 없습니다. pull request 설명의 마지막 줄에는 작업이 어떻게 처리되었고 그 이유가 명시되어 있으며, '리뷰어 필수' 또는 '리뷰어 불필요'로 시작합니다.

아키텍트#

귀하의 설명을 명세로 변환하고, 명세를 계획으로 만듭니다. 코드베이스를 참조하여 실제 존재하는 내용에 맞게 계획을 수립하지만 코드는 작성하지 않습니다.

그 결과물은 빌드 시작 전에 귀하가 승인하는 대상입니다. 코디네이터 모드에서는 이 에이전트가 코디네이터 역할을 계속 수행합니다.

개발자#

관련 코드를 읽고 변경을 적용하며, 테스트를 작성하거나 업데이트하고, 통과할 때까지 워크스페이스에서 로컬로 실행합니다.

리뷰어가리뷰어발견 사항을 다시 보내면,개발자이 역할이 해당 발견 사항에 따라 조치를 취합니다. 코디네이터 모드에서는 코디네이터가 발견 사항과 수정 방법을 함께 전달합니다.

QA#

코드를 작성한 에이전트와는 독립적으로 검증을 수행합니다. 즉, 귀하의 테스트 스위트, 프로젝트에 설정된 품질 게이트, 명세에 명시된 수용 기준을 활용합니다.

QA는 판단 결과를 보고합니다. 발견된 문제를 직접 수정하지는 않으며, 오류는 다시 개발자에게 전달되어 재작업이 이루어집니다.개발자로 처리됩니다.

리뷰어#

완성된 diff를 확인하고 발견 사항을 도출하며, 조직에서 설정한 리뷰 규칙을 적용합니다. 발견 사항은 개발자에게 재작업으로 전달되거나 귀하를 위한 pull request에 첨부됩니다.

웹 테스터#

실제 브라우저를 사용해 애플리케이션의 미리보기 버전에서 사용자 흐름이 엔드투엔드로 정상 작동하는지 확인합니다. 코드만으로는 동작에 대한 판단을 내릴 수 없는 경우에 활용됩니다.

탐색기#

읽기 전용의 조사 역할입니다. 다른 에이전트들은 자신의 컨텍스트에 모든 내용을 로드하지 않고도 코드베이스에 대한 질문에 답변하기 위해 이 역할을 활용합니다. 예를 들어 '인증 처리는 어디에서 이루어지는가', '이 함수를 호출하는 곳은 어디인가'와 같은 질문입니다.

종속성 분석기#

종속성을 분석하고 변경 사항이 코드베이스 전반에 미치는 영향을 파악합니다. 프로젝트 간 종속성이 설정된 경우에는 여러 프로젝트에 걸쳐서도 분석합니다.

이러한 역할 분리가 중요한 이유#

이렇게 작업을 분리하면 다음과 같은 네 가지 특성이 나타납니다:

1. 검증 과정이 독립적입니다.작업을 확인하는 에이전트가 코드를 작성한 에이전트와 다르므로 결과에 대한 이해관계가 없습니다.
2. 영향 범위가 제한됩니다.코드 작성 도구를 보유한 역할은 개발자뿐이므로, 리뷰나 분석 단계에서의 오류가 귀하의 저장소를 손상시킬 수 없습니다.
3. 각 역할에 맞는 모델이 실행됩니다.계획 수립에는 폭넓은 세계 지식이 유리하고, 컴파일 가능한 코드 작성에는 또 다른 역량이 필요합니다. AI 프로필이러한 이유로 각 역할별로 하나의 모델을 적용합니다.
4. 작업 완료 여부는 담당 에이전트가 아닌 검증 절차를 통해 결정됩니다.코디네이터 모드에서는 작업을 주도하는 에이전트가 QA 및 리뷰어의 승인 없이는 작업을 종료할 수 없습니다.

다음#

으로 돌아가기작업이 어떻게 pull request가 되는가이 역할들이 매핑되는 단계에 대해 알아보거나,Coroid란 무엇인가더 간단한 개요를 확인하세요.