저는 로나(Rona) 챌린지를 직접 운영하고 있어요. 최근 완주자들끼리 서로의 사례를 볼 수 있는 '동료 사례 갤러리'를 기획하면서, 사내 임직원 대상으로 먼저 테스트를 마친 추천 로나 스킬 'AI 에이전트 오케스트레이션'을 실제 기획에 써봤습니다. 기획을 만드는 역할과 그 기획을 검증하는 역할을 나눠 서로 합의하게 만드는 방식인데, 두 역할이 합의를 끝낸 뒤에도 구멍이 하나 남아 있었어요. 그걸 찾아낸 건 AI가 아니라 저였습니다. 오늘은 그 한 장면만 자세히 풀어볼게요.
AI 에이전트 오케스트레이션으로 기획 짜기 — 생성 역할과 비평 역할을 나눴다
챌린지를 완주해도 다른 참가자가 어떤 걸 만들었는지 볼 방법이 없었어요. 참여자 프로필 페이지와 동료들의 공개 사례를 모아보는 갤러리를 만들기로 했는데, 공개 범위를 정하는 데 고민이 있었습니다.
참가자 작업물엔 회사 업무처럼 보안이 필요한 내용도 섞여 있다
그렇다고 전부 무조건 공개하게 만들 수는 없다
그럼 선택은 본인에게 맡겨야 하는데, 그러면 아무도 먼저 공개하지 않을 것 같다
그래서 "내가 공개해야 남의 것도 볼 수 있게" 만들면 공개할 이유가 생긴다
이렇게 "내 사례를 먼저 공개해야 남의 사례도 볼 수 있는" 규칙을 붙이기로 했습니다.
한국어 한국어 한국어 한국어 한국어 한국어 한국어 한국어
이 기획을 짤 때 추천 로나 스킬 'AI 에이전트 오케스트레이션'에서 배운 자기채점 분리 원칙을 썼어요. 쓴 AI가 자기 결과를 자기가 채점하면 검사가 그냥 통과 도장으로 변한다는 원칙인데, 한 명의 AI가 기획부터 검토까지 다 하면 딱 그렇게 되기 쉬우니까요. 그래서 초안을 만드는 생성 역할과 그 초안을 원본 코드·라우트와 대조해 검증하는 비평 역할을 아예 다른 세션으로 분리했습니다. 생성 역할이 "갤러리 열람 자격 = 공개 사례 1개 이상"이라는 초안을 냈고 비평 역할이 실제 화면 흐름과 대조해 문제없다고 판정하면서 1차 합의가 끝났어요.
참여자 프로필 + 공개 사례 갤러리 + 먼저 공개해야 볼 수 있는 열람 규칙을 기획해줘
합의는 끝났는데 — "1개만 공개해도 다 보인다고?"
AI 두 역할이 합의까지 끝낸 기획서를 받아 보고 있는데, 뭔가 걸리는 게 있었어요.
1개만 공개해도 전부 열람 가능한 건 좀 이상하지 않아? 먼저 공개해야 보는 거라며
다시 보니 맞는 지적이었습니다. 사례 하나만 공개해도 다른 사람들의 사례를 전부 무제한으로 볼 수 있다면, "준 만큼 받는다"는 취지 자체가 무너지는 거였어요. 생성 역할도 비평 역할도 "이 기준이 코드로 구현 가능한가"는 검증했지만, "이 기준이 애초에 그 취지에 맞는가"라는 정책 판단까지는 걸러내지 못한 거죠. AI 두 역할의 합의는 구조가 맞는지를 확인한 것이지, 정책이 맞는지를 확인한 게 아니었습니다.
어떻게 바꿨나 — 고정 기준을 움직이는 기준으로
열람 자격을 "공개 사례 1개 이상"이라는 고정값 대신, 공유링크 발급 + 공개 사례 수가 min(3, 완 료한 사례 수) 이상이라는 움직이는 기준으로 바꿨어요. 완주 사례가 3개보다 적은 사람은 가진 걸 다 공개해야 자격이 생기고, 3개 이상인 사람은 최소 3개를 공개해야 하는 구조입니다. 자격이 안 되는 사람에게는 화면을 그냥 막아버리는 대신, "먼저 공유하면 열려요"라고 안내하는 화면을 보여주도록 했고요.
한국어 - 스크린샷 1
이 한 줄을 바꾸느라 기획은 다시 한 번 생성 역할과 비평 역할을 거쳐 재합의됐습니다. 정책을 고친 건 사람이었지만, 그 정책을 실제 코드 구조에 맞게 다시 짜 맞추는 건 다시 AI 두 역할의 몫이었어요.
결과
항목
1차 합의 (AI만)
최종 (사람 검토 후)
열람 자격 기준
공개 사례 1개 이상 (고정)
공유링크 발급 + 공개 사례 ≥ min(3, 완료 사례 수) (동적)
기획 재합의 사이클