감히 페르소나 엔지니어링이라 부르겠어요~

진짜 몸이 열 개, 아니 백 개라도 부족합니다 ㅋㅋ

getPersona.md 빌드인퍼블릭 열심히 진행 중입니다.

원래는 MVP 정도에서 일단 열려고 했는데,
기능을 하나씩 붙이다 보니 뭔가 엄청 쌓이고 있습니다.

지금 큰 축은 두 가지입니다

공개 페르소나와 비공개 페르소나.

그중 공개 페르소나에는 개인 페르소나도 있고,
여러 역할을 하나의 팀으로 묶은 그룹 페르소나도 있습니다.

지금은 그중 하나인 바이브크루 그룹 페르소나를 실제 개발에 넣어서 테스트하고 있습니다.

제가 만들고 싶은 건 새로운 오케스트레이션이 아닙니다

오케스트레이션은 이미 있죠.

Orca도 실험적으로 여러 에이전트를 묶어서 작업시키고 있고,
여러 코딩 에이전트에서도 메인 에이전트가 필요에 따라 서브에이전트를 호출하는 구조가 나오고 있습니다.

제가 관심 있는 건 그다음입니다.

예를 들어 오케스트레이터가 작업하다가

여기 DB 설계 수정이 필요하다.

라고 판단했다고 해보겠습니다.

기존 방식이라면 서브에이전트 하나를 호출해서 DB 부분을 검토하라고 일을 넘깁니다.

제가 지금 테스트하는 방식은 조금 다릅니다.

DBA 페르소나를 입은 서브에이전트를 호출합니다.

이 에이전트는 그냥 일을 나눠 받은 AI가 아닙니다.

DBA로서 무엇을 먼저 봐야 하는지,
어떤 위험을 확인해야 하는지,
어디까지가 자기 책임인지,

그 역할에 맞는 PERSONA.md를 가지고 작업합니다.

직접 적용해보니 차이가 보입니다

모델마다 차이는 좀 있습니다.

그래도 오케스트레이터가 DB 변경이 필요하다고 판단하면 DBA를 부르고,

DBA는 스키마와 마이그레이션을 자기 관점에서 검토하고,

개발 담당은 다시 개발자 페르소나를 가지고 구현합니다.

필요하면 서로의 결과를 받아서 다음 작업으로 넘어갑니다.

기존 방식과의 차이는 이겁니다

기존 오케스트레이션

오케스트레이터
→ 서브에이전트 호출
→ 작업 수행

페르소나를 적용한 오케스트레이션

오케스트레이터
→ 필요한 전문가 판단
→ DBA 페르소나 호출
→ DBA 관점에서 검토
→ 개발자 페르소나 호출
→ 개발자 관점에서 구현

겉으로 보면 둘 다 멀티 에이전트입니다.

그런데 저는 이 차이가 앞으로 꽤 중요해질 거라고 생각합니다.

사람 회사에서도

사람 한 명 더 불러.

와

DBA 불러.

는 완전히 다른 말이니까요.

그래서 저는 이렇게 보고 있습니다

하네스 엔지니어링 → 루프 엔지니어링 → 페르소나 엔지니어링

하네스 엔지니어링이 에이전트가 일할 수 있는 도구와 환경을 만드는 거라면,

루프 엔지니어링은 에이전트가 실행하고 확인하고 수정하면서 끝까지 일하게 만드는 것.

그리고 페르소나 엔지니어링은

그 일을 어떤 전문가가 수행하게 할 것인가를 설계하는 것.

물론 이름은 제가 감히 붙여봤습니다 ㅋㅋ

제가 말하는 페르소나는 역할극이 아닙니다

단순히

너는 세계 최고의 DBA야.

한 줄 넣는 프롬프트 역할극과는 조금 다르게 보고 있습니다.

역할과 책임,
판단 기준,
권한,
작업 방식까지 가지고

실제 오케스트레이션 안에서 전문가처럼 행동하게 만드는 것에 가깝습니다.

지금 올린 캡처가 그 실험 중 하나입니다.

오케스트레이터 혼자 모든 걸 판단하는 게 아니라,
필요한 순간에 각자의 페르소나를 가진 전문가를 불러서 같이 작업하게 만들고 있습니다.

아직 계속 실험 중입니다.

모델에 따라서 페르소나를 받아들이고 움직이는 차이도 꽤 보이고요.

이 부분도 계속 테스트해서 공유해보겠습니다.

원래 MVP만 만들려고 했는데...

자꾸 할 게 생깁니다 ㅋㅋ

AI 하나를 만능으로 만드는 것보다
필요할 때 제대로 된 전문가를 불러 쓰는 것. 

저는 getPersona.md에서 이걸 한번 만들어보려고 합니다.