제6회 「Garmin Running Data Normalizer를 뒷받침한 AI 협업 개발」에서는,

Garmin Running Data Normalizer를 어떻게 AI와 역할 분담을 하며

개발해 왔는지 소개했습니다.

그 과정에서 보인 것은, 단순히 AI의 수를 늘린다고 해서 품질이 올라가는 것은 아니라는 점입니다.

지난번에 소개한 README의 상태 불일치, Windows에서의 tzdata 부족,

리뷰 AI에 의한 과도한 일반화는 모두

어떤 순서로 확인하고, 무엇을 정본(正本, Source of Truth)으로 판정할 것인가

라는 문제였습니다.

이 진행 방식을 매번 그 자리에서 생각한다면, 다른 프로젝트에서 동일한 문제를 반복하게 됩니다.

그래서 Garmin Running Data Normalizer에서 얻은 협업 진행 방식을

특정 프로젝트에 의존하지 않는 형태로 정리한 것이

**AI Collaboration Platform (ACP)**입니다.

이 기사에서는 ACP가 무엇을 해결하기 위한 기반인지,

어떠한 사고방식과 구성으로 설계되어 있는지 소개합니다.

AI Collaboration Platform이란

AI Collaboration Platform은 이용자와 복수의 AI 태스크(Task)가

장기 프로젝트를 협업하여 진행하기 위한 운영 기반입니다.

ACP를 사용하는 목적은 AI를 늘리는 것이 아닙니다.

장기 프로젝트에서도,

• 전제가 흔들리지 않는다
• 리뷰 결과가 묻히지 않는다
• 판단 근거를 재사용할 수 있다
• 다음 AI로 인계할 수 있다

상태를 유지하는 것입니다.

ACP에서는 방향성과 가치 판단을 담당하는 이용자를

아키텍처상의 역할명으로 Human이라고 부릅니다.

본문에서는 원칙적으로 「이용자」라고 표기합니다.

ACP는 코드 생성 도구나 특정 AI 서비스를 묶기 위한 래퍼(Wrapper)가 아닙니다.

중심에 두는 것은 다음과 같은 개발 운영입니다.

• 누가 방향성과 가치 판단을 수행하는가
• 어떤 AI가 구현을 담당하는가
• 어떤 AI가 리뷰를 하는가
• 무엇을 검증 근거(Evidence)로 남길 것인가
• 무엇을 정본으로 삼고, 누가 판단하는가
• 어떤 조건으로 다음 작업으로 진행할 것인가
• 어떤 상태로 이용자에게 판단을 반환할 것인가
• 프로젝트 고유의 지식을 어디에 둘 것인가

ACP v0.9는 특정 AI 서비스, 제품 UI, GitHub 조작,

태스크 간 통신 API를 필수 사항으로 요구하지 않습니다.

실행 환경이 바뀌더라도 동일한 정본, 경계, 검증 근거,

리뷰, 승인의 계약을 유지할 수 있다는 점을 중시하고 있습니다.

왜 전용 운영 기반이 필요했는가

AI를 사용한 개발에서는 처음에는 하나의 채팅창에

요건 정리부터 구현, 리뷰, 공개까지 모두 맡겨버리기 쉽습니다.

하지만 프로젝트가 길어지면 다음과 같은 문제가 발생합니다.

• 요건과 구현이 뒤섞인다
• 처음에 채택한 전제를 후속 공정까지 끌고 간다
• 구현한 AI가 자신의 성과를 그대로 옳다고 판단한다
• 리뷰 결과가 대화 속에 묻힌다
• 수정 이유나 검증 결과가 남지 않는다
• 공개 범위와 비공개 검증 근거가 섞인다
• 다음 AI로 인계할 때마다 전제를 다시 설명해야 한다
• 개선된 운영이 다른 프로젝트로 재사용되지 않는다

Garmin Running Data Normalizer에서도

구현만으로는 해결할 수 없는 문제가 여러 가지 있었습니다.

그것들에 공통된 것은 AI의 답변 그 자체보다도,

누가 무엇을 담당하고, 어떤 성과물을 읽고, 무엇과 대조하며,

어떤 조건으로 다음 단계로 넘어갈 것인가

를 미리 정해둘 필요가 있었다는 점입니다.

ACP는 이러한 운영을 프로젝트마다 즉흥적으로 하는 것이 아니라,

재사용 가능한 형태로 남기기 위해 만들었습니다.

ACP의 기본 모델

ACP의 기본 구조는 다음과 같습니다.

구현 태스크는 코드나 문서를 만드는 것에 그치지 않습니다.

다음 내용을 하나의 제출물로 취급합니다.

• 구현 성과물
• 테스트 결과
• 차분 (Diff)
• 품질 확인 결과
• 미결 사항
• 검증 근거

단위 리뷰 AI는 성과물 단위의 확인을 수행합니다.

그 후, 프로젝트 핵심 게이트(Core Gate)를 통과한 것만을

프로젝트 전체의 정합성을 확인하는 핵심 리뷰로 넘깁니다.

핵심 리뷰는 다음 중 하나를 반환합니다.

• PASS: 다음으로 진행 가능
• REWORK: 수정하여 재제출
• HUMAN_DECISION_REQUIRED: 이용자의 가치 판단 필요

여기서 중요한 것은 PASS가 단순한 종료 보고가 아니라,

다음 작업 패키지로 진행할 수 있는 상태를 나타낸다는 점입니다.

단, PASS가 이용자 승인의 생략을 의미하지는 않습니다.

공개, 외부 송신, 불가역적 조작, 보호 대상 자산의 이용 등,

이용자 승인이 정의되어 있는 조작은,

승인을 얻은 후에 다음 작업으로 진행합니다.

ACP의 8가지 원칙

ACP v0.9에서는 다음 8가지 원칙을 중심으로 삼고 있습니다.

1. 검증 근거를 우선한다 (Evidence First)

"작동했다", "문제가 없었다"라는 보고뿐만 아니라,

무엇을 확인했고 어떤 결과를 근거로 삼았는지를 남깁니다.

검증 근거에는 예를 들어 다음과 같은 것들이 포함됩니다.

• 테스트 결과
• 차분 (Diff)
• 실행 로그
• 품질 확인 결과
• 케이스 스터디 (Case Study)
• 리뷰 결과
• 공개 전 확인
• 릴리스 기록

AI의 자신감이나 문장의 설득력이 아니라,

나중에 확인할 수 있는 근거를 우선합니다.

2. 경계 내에서 자율한다 (Autonomous within Boundaries)

AI는 미리 정해진 경계 안에서는 자율적으로 진행할 수 있습니다.

한편으로, 다음과 같은 조작은 임의로 수행하지 않습니다.

• 공개
• 외부 송신
• 삭제
• 계약 변경
• 기능 감소
• 가치 판단
• 취소할 수 없는 조작

자유도를 무제한으로 부여하는 것이 아니라,

자유롭게 진행해도 좋은 범위를 먼저 정의합니다.

3. 멈추지 않고 보고한다 (Report, Don't Stop)

경미한 문제나 개선 후보를 발견할 때마다 정지한다면,

장기 프로젝트는 진행될 수 없습니다.

경계 내에서 안전하게 대응할 수 있는 것은,

수정, 검증, 보고까지 진행합니다.

즉시 대응하지 않는 편이 좋은 개선 사항은,

개선 후보로 기록하고 작업 자체는 계속합니다.

4. AI가 AI를 리뷰한다 (AI Reviews AI)

구현한 AI만으로 중요한 확인을 완결 짓지 않습니다.

별도의 AI 또는 별도의 태스크가,

성과물, 차분 (Diff), 검증 근거, 공개 표현을 확인합니다.

단, 리뷰 AI의 판단도 절대적이지는 않습니다.

리포지토리, 공개 계약, 테스트, 검증 결과와 대조하며,

최종적으로는 이용자가 채택 여부를 결정합니다.

리뷰 AI도 검증 근거를 제출하며,

그 리뷰 자체를 이용자가 나중에 확인할 수 있는 형태로 남깁니다.

5. 가치 판단은 이용자가 가진다 (Human Decides Values)

이용자는 다음의 판단을 담당합니다.

• 프로젝트의 목적
• 우선순위
• 허용 리스크
• 공개 범위
• 정식 채택
• 취소할 수 없는 조작
• 기존 규칙으로는 해결할 수 없는 판단

AI는 이용자를 대체하는 것이 아니라,

구현, 검증, 리뷰, 개선 후보의 정리를 담당합니다.

6. PASS를 다음 작업으로 잇는다 (PASS Starts the Next Work Package)

리뷰에서 PASS가

나오면,

그 결과를 다음 작업으로 잇습니다.

완료 보고만 하고 멈추는 것이 아니라, 다음 작업 패키지,

인수인계, 로드맵 업데이트로 나아갑니다.

이용자 승인이 필요한 조작은 그 승인을 얻은 후에 시작합니다.

7. 프로젝트 지식은 루트에 둔다 (Project Knowledge Lives in the Project Root)

프로젝트 고유의 지식은 대화에만 두지 않습니다.

프로젝트의 루트 디렉토리(Root Directory)에 다음과 같은 것들을 남깁니다.

• 목적
• 경계
• 요구사항
• 완료 조건
• 계약
• 절차서
• 검증 근거
• 읽는 순서

다른 AI나 다른 실행 환경에서도,

동일한 전제로부터 작업을 재개할 수 있는 상태를 목표로 합니다.

8. 실운영을 통해 기반을 키운다 (The Platform Evolves through Real Operation)

ACP는 처음부터 완성형을 만드는 것을 목적으로 하지 않습니다.

실제 프로젝트에서 발생한 마찰, 실패, 성공을 기록하고,

일반화할 수 있는 개선만을 기반으로 환원합니다.

프로젝트 고유의 사정을

그대로 공통 기반에 섞지 않는 것도 중요합니다.

플랫폼 표준과 프로젝트 고유 설정을 분리한다

ACP에서는 모든 프로젝트에 공통되는 운용과,

개별 프로젝트의 지식을 분리합니다.

AI Collaboration Platform
├─ 플랫폼 표준
│ ├─ 정본과 판단 권한
...

Garmin 고유의 Activity, FIT, Snapshot Accumulation,

External-safe Pack 등은 ACP 본체의 사양이 아닙니다.

그것들은 Garmin Running Data Normalizer 측의

프로젝트 고유 설정입니다.

한편으로, 다음의 운용은 다른 프로젝트에서도 재사용할 수 있습니다.

• 구현과 리뷰를 분리한다
• 검증 근거를 제출한다
• 공개 전에 이용자가 승인한다
• 프로젝트 고유의 개선을 직접 표준에 섞지 않는다
• 재사용 가능한 개선만을 기반(Base)으로 되돌린다

Repository 상에는 무엇이 놓이는가

ACP를 새로운 프로젝트에 적용할 때는,

예를 들어 다음과 같이 배치합니다.

docs/
├─ project_os/ # ACP의 플랫폼 표준
└─ project/ # 프로젝트 고유의 헌장, 경계, 완료 조건 등
...

플랫폼 헌장(Platform Charter)은 ACP 표준 측에 둡니다.

docs/project_os/governance/

프로젝트 헌장(Project Charter)은 대상 프로젝트 측에 둡니다.

docs/project/

마찬가지로, 플랫폼 전체의 경계와

개별 프로젝트의 경계도 별도 문서로 취급합니다.

새로운 프로젝트에서는 ACP의 Pack을 프로젝트 루트에 배치하고,

templates/project/

에서 다음 문서들을 작성합니다.

• 프로젝트의 배경
• 프로젝트 헌장
• 프로젝트 경계
• 요구사항
• 완료 조건
• 페이즈 시작 문서
• 읽는 순서
• 수락 확인 (Acceptance Check)

그 후, 실행 환경에 따른 어댑터(Adapter)를 설정하고,

수락 확인을 통과한 뒤에 구현을 시작합니다.

프로젝트 핵심 게이트(Project Core Gate)가 담당하는 것

프로젝트 핵심 게이트(Project Core Gate)는

AI의 명칭이 아닙니다.

리뷰로 진행하기 위해 필요한 산출물과

검증 근거의 조건 집합입니다.

구현 태스크의 산출물과

단위 리뷰의 결과 모두가 입력값이 됩니다.

예를 들어, 다음 내용이 갖춰져 있는지 확인합니다.

• 무엇을 변경했는가
• 변경 대상이 정의된 경계 내에 있는가
• 테스트 결과가 있는가
• 기존 계약(Contract)을 깨뜨리지 않았는가
• 검증 근거가 갖춰져 있는가
• 미결 사항은 무엇인가
• 이용자의 판단이 필요한 항목이 있는가

이를 통해 리뷰 측이 매번 리포지토리 전체를

다시 탐색할 필요를 줄여줍니다.

Garmin Running Data Normalizer에서 External-safe Pack을 AI에게 전달할 때,

데이터뿐만 아니라 스키마, 읽는 법, 금지 사항도 함께 전달했던 방식과 유사합니다.

구현 산출물에도 읽는 순서와 판단 재료가 필요합니다.

개선을 멈추지 않고 순환시키기

ACP는 개선을 다음과 같은 순환 구조로 다룹니다.

프로젝트 내에서 발견된 개선을

즉시 플랫폼 표준에 넣는 것은 아닙니다.

다음 조건을 확인합니다.

• 여러 프로젝트에서 재사용 가능한가
• 특정 분야의 지식에 의존하고 있지 않은가
• 검증 근거가 있는가
• 기존 원칙과 모순되지 않는가
• 도입 비용보다 운용 가치가 높은가
• 이용자가 채택하기로 판단했는가

채택된 개선만을 플랫폼 표준에 반영합니다.

보류된 개선은 프로젝트 내의 후보로 남겨둡니다.

불채택된 것은 표준에 포함하지 않습니다.

Garmin에서 일반화할 수 있었던 것

Garmin Running Data Normalizer는

ACP v0.9의 개념을 실제 OSS 개발에서 시험한 참조 구현(Reference Implementation)입니다.

다만, ACP로 일반화한 것은

Activity나 FIT의 사양 그 자체가 아닙니다.

Garmin에서 일반화할 수 있었던 것은 다음과 같은 운용 방식이었습니다.

• 구현과 리뷰를 분리한다
• 검증 근거와 함께 게이트를 통과한다
• 공개나 불가역적 조작에는 이용자 승인을 둔다
• 프로젝트 고유 지식과 플랫폼 표준을 분리한다
• 실제 운용에서 개선 후보를 추출한다
• 채택된 개선만을 기반으로 환원한다
• PASS를 다음 작업으로 연결한다

이 흐름은 Release, 수정, 문서화,

케이스 스터디, 외부 발신까지 실제로 운용했습니다.

한편, Garmin Running Data Normalizer 하나만으로

ACP가 모든 프로젝트에 유효하다는 것을 증명한 것은 아닙니다.

여러 프로젝트로의 적용, 장기 운용,

실행 환경별 차이에 대해서는 계속해서 검증이 필요합니다.

ACP는 특정 AI 서비스에 의존하지 않는다

ACP의 목적은 ChatGPT, Codex, Claude, Gemini,

Genspark의 사용법을 고정하는 것이 아닙니다.

실제로 이용하는 AI나 기능은 변합니다.

중요한 것은 AI 서비스나 실행 환경이 바뀌더라도

다음 사항을 유지하는 것입니다.

• 무엇을 정본 (Source of Truth)으로 삼을 것인가
• 어디까지 자율성을 허용할 것인가
• 무엇을 검증 근거로 남길 것인가
• 누가 리뷰할 것인가
• 어떻게 인수인계할 것인가
• 어떤 조작에 이용자 승인이 필요한가

AGENTS.md 또한 ACP에 필수적인 메커니즘은 아닙니다.

함께 포함된 실행 환경 어댑터 (Execution Environment Adapter)의 한 예일 뿐이며,
동일한 계약을 준수할 수 있는 다른 어댑터로 교체할 수 있습니다.

이러한 분리를 통해, 특정 제품의 UI나 기능이 바뀌더라도
프로젝트 운영 전체를 다시 만들지 않아도 되는 것을 목표로 합니다.

ACP가 해결하지 않는 것

ACP는 AI의 답변을 올바르게 만드는 보증이 아닙니다.
또한, 다음 사항들을 자동으로 결정하는 기반도 아닙니다.

• 프로젝트의 목적
• 무엇을 가치로 삼을 것인가
• 어디까지 공개할 것인가
• 어떤 리스크를 허용할 것인가
• 어떤 설계를 채택할 것인가
• 언제 출시할 것인가

이것들은 프로젝트 고유의 판단이며,
최종적으로는 이용자가 결정합니다.

ACP가 지원하는 것은,
그 판단에 필요한 산출물, 검증 근거, 리뷰, 경계를 갖추고,
재사용 가능한 형태로 운영하는 것입니다.

현재 위치는 v0.9 Public Baseline――성숙도는 Production Candidate

AI Collaboration Platform의 현재 공개 버전은 v0.9입니다.
v0.9는 정식으로 공개·고정한

**공개 기준판 (Public Baseline)**입니다.

한편, 성숙도로서는

**실운용 후보 (Production Candidate)**로 위치시키고 있습니다.

위치는 다음과 같습니다.

• v0.1〜v0.4: 구상 단계 (Concept)
• v0.5〜v0.8: 시작 단계 (Prototype)
• v0.9: 공개 기준판 / 실운용 후보 (Public Baseline / Production Candidate)
• v1.0: 정식 안정판 (General Availability)

v0.9는 실운용 가능한 기반으로서 공개하고 있지만,
복수 프로젝트로의 적용, 장시간 운용,
실행 환경별 차이에 대한 대응은 계속해서 검증 중입니다.

현재의 참조 구현 (Reference Implementation)은 Garmin Running Data Normalizer 1건입니다.

ACP v0.9는 GitHub에서 공개되어 있으며,
Apache License 2.0으로 이용할 수 있습니다.

요약

AI Collaboration Platform은
복수의 AI를 나열하기 위한 메커니즘이 아닙니다.

장기 프로젝트에서,

• 이용자가 목적과 가치를 결정한다
• AI가 역할을 분담한다
• 구현과 리뷰를 분리한다
• 검증 근거를 남긴다
• 리포지토리와 공개 계약에 대조한다
• PASS를 다음 작업으로 연결한다
• 이용자 승인이 필요한 조작을 분리한다
• 실운용의 개선을 기반으로 환원한다

하기 위한 운영 기반입니다.

Garmin Running Data Normalizer에서는
이러한 사고방식을 실제 OSS 개발에 적용하여,
릴리스, 문서화, 케이스 스터디,
외부 발신까지 진행했습니다.

그 경험을 통해 알게 된 것은,
AI 협업에서 중요한 것은 AI의 수가 아니라,

• 역할
• 정본 (Source of Truth)
• 경계
• 검증 근거
• 리뷰
• 승인

을 설계하는 것이었습니다.

ACP는 이것들을 특정 프로젝트의 대화나 경험 속에만 남기지 않고,
다음 프로젝트에서도 재사용할 수 있는 형태로 정리하기 위한 기반입니다.

ACP는 AI를 관리하기 위한 메커니즘이 아닙니다.
실제 프로젝트에서 얻은 운용 지견을,
검증 근거와 함께 다음 프로젝트로 전달하기 위한 기반입니다.

Garmin Running Data Normalizer는 현재도 개선을 계속하고 있으며,
앞으로도 실운용에서 얻은 지견을 Project와 AI Collaboration Platform 양쪽 모두에 반영해 나갈 것입니다.

관련 자료

Discussion