AI 구동 개발의 정밀도 향상 및 효율화를 위한 베이스 시스템 개발

Kudan에서는 SLAM 기술을 비롯한 임베디드 개발을 진행하고 있습니다. AI 기반 개발의 병목 현상을 스마트하게 해소하기 위해, 기본이 되는 시스템을 개발했습니다.

개발에서의 과제와 해결책

임베디드/SLAM 개발에서는 구현 이후 빌드, 오프라인 검증, 필요하다면 실기(實機)에서의 검증이 이어집니다. 주된 검증 내용에 따라 실제 데이터와 같은 시간, 혹은 그 이상의 시간이 소요될 수 있으므로, 대기 시간을 다른 작업에 할애할 수 있다면 효율적입니다.

AI 구동 개발을 병행 및 효율화하는 과정에서 발견한 주요 과제가 3가지 있으며, 다음과 같이 해결하기로 했습니다.

오케스트레이터

어렵거나 긴 작업의 경우, 자체 개발한 오케스트레이터를 이용해 Manager → Worker → Reviewer의 고정된 흐름을 사용합니다. 중간에 위치하는 Flybridge Coordinator는 LLM과는 별도의 시스템으로, 진행 상황 파악과 에이전트 간의 연결 역할을 수행합니다. Manager는 완료 조건과 확인 방법을 포함한 계획을 수립하고, Worker가 구현하여 검증 결과를 기록합니다. Reviewer는 커밋된 구현과 검증 결과를 확인합니다.

이러한 에이전트 분리 덕분에, Manager가 긴 빌드 로그나 구현 과정에 관여하지 않고 스레드를 짧게 유지할 수 있어 '점차 방향을 잃어간다'는 문제를 완화했습니다. 또한, 역할이 다른 각 에이전트에게 서로 다른 스킬을 설정할 수 있으므로, 필요한 지식만으로 필요한 역할을 수행합니다.

Orca의 GUI 상에서는 [M] = Manager와 같은 접두사로 이렇게 확인할 수 있습니다. 리뷰는 모델에 따라 품질이 다르기 때문에, 여러 리뷰어가 동시에 리뷰하는 것을 지원합니다.

이 오케스트레이터 구조는 사용자 편의성 측면에서도 이점이 있습니다. Flybridge를 조작하는 부(親) 에이전트 또는 각 워크 트리(work tree)의 Manager에게 문의하기만 하면 작업 진행 상황을 확인할 수 있어, Worker나 Reviewer의 긴 로그를 추적할 필요가 없습니다. 또한, 셀프 리뷰가 완료된 결과물을 받을 수 있어 수동 확인의 수고를 줄일 수 있습니다.

동작 확인 큐(Operation Confirmation Queue)

여러 워크 트리는 코드와 에이전트의 작업 공간을 분리합니다. 반면, 실기나 고부하 검증 등 워크 트리를 나누어도 동시에 사용할 수 없는 자원은 남아있습니다. Flybridge는 자원별로 선착순(FIFO) 큐를 가지고 있으며, 에이전트는 사용 전에 리스(lease)를 획득하고 작업 후에 해제합니다. 무엇을 '무거운 동작 확인'으로 할지는 LLM의 자동 판정에 맡기고 있지만, 큐 관리 자체는 시스템적으로 엄격하게 처리했습니다.

이를 통해 예를 들어 퇴근하기 전에 여러 구현을 요청해 두면, 동작 확인까지 포함하여 자동으로 완수해 줍니다.

Orca 기반 진행 상황 관리

처음에는 여러 에이전트와 수동 조작용 터미널을 한 화면에 배치하는 tmux 기반의 TUI(Text User Interface)를 만들었습니다. 1개의 창을 1개 프로젝트에 대응시키고, MCP를 통해 에이전트 간의 연계 및 상태 표시를 시도했습니다. 하지만 Orca가 기능과 디자인 면에서 세련되었기 때문에, 현재는 이를 GUI 기반으로 사용하고 있습니다.

참고로, Orca를 사용하더라도 워크 트리가 많으면 잘려 보이는 문제가 남아있습니다. Flybridge 자체 데이터베이스는 Coordinator 등을 통해 각 워크 트리의 진행 상황을 파악하고 있기 때문에, Flybridge 워크 트리를 고정(pin)해 두고 거기서 전체 진행 상황 관리를 함으로써 이 문제도 해결했습니다.

Orca 상에서 Flybridge를 설정하기

여기서는 로컬 환경에서 Flybridge를 사용하기 시작하는 절차를 소개합니다. Linux 또는 macOS를 대상으로, Orca 위에 Flybridge 조작용 에이전트를 배치하고, 거기서 대상 리포지토리의 작업을 요청하는 구성입니다. 자세한 설정이나 최신 절차는 README (English / 日本語)에도 게재되어 있습니다.

1. Orca와 개발 도구 준비하기

먼저 다음을 설치해 주세요.

• Orca를 설치한 후 앱을 실행해 둡니다.
• Python 3.11 이상, uv, Git.
• Flybridge에서 사용할 코딩 에이전트의 CLI입니다. 각 CLI의 설치와 로그인(login)을 완료하고, Orca의 터미널에서 실행할 수 있는지 확인합니다.

GitHub Project 연동을 사용하는 경우에는 gh가 필요합니다.

CLI도 필요하지만, 우선은 연동 없이 시작할 수 있습니다.

2. Flybridge를 가져와서(取得し) Orca에서 열기

터미널에서 임의의 작업 디렉토리에 Flybridge를 clone 합니다.

git clone https://github.com/LiltoneJG/flybridge.git
cd flybridge
uv sync --all-packages
...

Flybridge는 소스를 clone하여 이용합니다. 이어서, Orca에 이 flybridge 디렉토리를 추가하고, 작업용 터미널을 열어주세요. 이후의 명령어들은 이 디렉토리에서 실행합니다.

3. 사용할 에이전트와 자원(資源)을 설정하기

복사한 config/flybridge.jsonc를 편집합니다. 샘플에는 여러 종류의 에이전트나 모델이 지정되어 있으므로, 그대로 사용하지 말고 직접 활용 가능한 것에 맞게 수정해야 합니다.

먼저 확인해야 할 설정은 다음과 같습니다:

예를 들어, 모든 역할에서 동일한 에이전트를 사용하고 Reviewer를 1명으로 구성하는 방식으로도 시작할 수 있습니다. 여러 모델에 의한 리뷰는 기본 동작을 확인한 후에 늘릴 수 있습니다.

queue.resources의 이름은 에이전트가 어떤 작업에서 리스(lease)를 획득해야 할지 판단하는 데에도 사용됩니다. 작업을 의뢰할 때는

대상: /path/to/your-repository
issue: https://github.com/your-account/your-repository/issues/123
목적: issue에 기재된 불具合을 수정하는
...

issue 번호 외의 운영 규칙은 자체 SKILL.md로 정의해 두면, 프롬프트가 훨씬 단순해집니다. 취향에 따라 설정해 보세요.

# SKILL
- 모드 선택: 쉬운 버그 수정 등에서는 single 모드로 충분하지만, 어려운 경우나 난이도가 불분명한 경우에는 기본적으로 orchestrated 모드를 사용합니다.
- 자원: 무거운 빌드나 시뮬레이션 전에 heavy-verification의 리스를 획득합니다.
...

작업이 시작되면, Orca 상에 Manager, Worker, Reviewer의 워크트리와 터미널이 나타납니다. 진행 상황은 작업용 에이전트에게 문의하거나 다음 명령어로 확인할 수 있습니다.

uv run --package flybridge-cli flybridge workflow list
uv run --package flybridge-cli flybridge queue status

마지막으로

자체적인 진행 관리 시스템/오케스트레이터를 정비함으로써, 작업 환경을 개선할 수 있었습니다.

다만, 자신의 아이디어가 최선이라는 보장도 없으며, LLM 역시 매일 진화하고 있어 최적의 해답 또한 계속 변할 것입니다. 앞으로도 더 좋은 아이디어를 얻게 된다면 시도해 보고 싶습니다.

Discussion