SoDam-Persona를 통째로 들이지 않고, 쓸 만한 원칙만 골라낸 사례-초록색 PASS보다 중요한 것은 ‘무엇을 검증하지 않았는가’였다

현재 검증 범위

• ✅ 공개 저장소의 main을 커밋 6a5de130…ffc에 고정해 문서·hook·9개 skill·검증기·CI를 읽었다.

• ✅ Codex 0.146.0의 격리된 임시 환경에서 플러그인 v1.1.1이 enabled로 인식되는 것을 확인했다.

• ✅ 기준 node validate.mjs는 15명 · 20패턴 · 9스킬 / PASS를 반환했다.

• ✅ 검증기의 범위를 확인하기 위해 다섯 가지 변이 canary를 실행했다.

• ⚠️ 잘못된 hook JSON, 깨진 hook JavaScript, 빈 QA 트리거, 59바이트짜리 법률 skill은 모두 검증기를 통과했다.

• ✅ 관점 수를 15명에서 16명으로 바꾼 변이는 검증기가 실패로 잡았다.

• ❌ 운영 중인 TARDIS/Hermes에는 설치하지 않았다.

• ❌ 실제 사용자 과제를 이용한 응답 품질 A/B, 지연시간·토큰 비용, 법률·세무 정확도 평가는 하지 않았다.

이 글은 SoDam-Persona의 우열을 판정하는 제품 리뷰가 아니다. 이미 다중 프로필·스킬·라우팅·검증 체계를 가진 시스템에 무엇을 어떤 경계로 받아들일지 결정한 적합성 평가 사례다.

📝 한 줄 요약

SoDam-Persona는 초보자 친화적 설명과 꼼꼼한 자기점검이라는 좋은 아이디어를 담고 있었지만, 기존 TARDIS/Hermes에는 상시 주입·라우팅 우선순위·가상 전문가 관점이 중복되었다. 그래서 통째 설치와 상시 어댑터는 보류하고, 원칙만 clean-room 방식으로 선택 흡수하기로 했다.

바쁘시면 이것만 읽어도 됩니다.

• SoDam-Persona는 별도 AI나 독립 멀티에이전트가 아니라 Codex에 규칙 문서와 skill을 주입하는 플러그인이다.

• 기준 validator의 PASS는 유효하다. 다만 그것이 증명하는 범위는 선언된 수치·문자열·일부 배선 정합성이다.

• 다섯 가지 변이 canary에서 1개만 실패로 잡혀, syntax·runtime·내용 충실도·도메인 정확도는 별도 Gate가 필요함을 확인했다.

• 상시 core+marker는 UTF-8 파일 바이트 기준 26,067바이트였고, 심층 경로 관련 문서 묶음은 78,750바이트였다.

• “15명 관점”은 15개의 독립 실행자가 아니라 한 모델이 참고하는 체크리스트형 관점이다.

• 기존 시스템의 전문 프로필·skill fleet·점진적 컨텍스트와 함께 쓰면 중복과 우선순위 충돌 가능성이 컸다.

• 결론은 통째 설치 NO-GO / 상시 어댑터 NO-GO / 원칙만 선택 흡수 GO였다.

🎯 처음 질문은 단순했다

공개 저장소 링크를 하나 받았을 때의 질문은 “설치할 수 있는가?”가 아니었다.

이 저장소가 우리에게 얼마나 도움이 되는가?

이 질문에는 서로 다른 세 가지 선택지가 숨어 있었다.

1. 플러그인을 그대로 설치한다.

2. 기존 시스템에서 호출하는 얇은 어댑터를 만든다.

3. 유용한 설계 원칙만 뽑아 기존 규칙에 독립적으로 반영한다.

설치 가능 여부만 확인하면 첫 번째 선택으로 기울기 쉽다. 하지만 적합성 평가는 작동성, 중복, 충돌, 검증력, 유지비를 함께 봐야 한다.

🧩 SoDam-Persona는 실제로 무엇인가

저장소의 설명은 비교적 정직했다. 이 플러그인은 별도의 AI가 아니라, Codex가 이미 가진 대화 능력 위에 “어떻게 판단하고 답할지”를 정한 규칙을 얹는다.

구성은 다음과 같았다.

그림 1. 공개 저장소의 README·hook manifest·injector에서 파생한 구조 카드다. 실행 화면 캡처가 아니라, 고정 커밋의 구성과 기존 시스템의 책임 경계를 요약한 데이터 파생 증거 카드다.

이 구분이 중요했다. “15명 전문가”라는 표현만 보면 여러 에이전트가 독립적으로 작업하고 서로 검증하는 것처럼 느낄 수 있다. 실제 구현은 한 Codex 모델에 여러 관점과 자기점검 규칙을 제공하는 프롬프트 패키지에 가깝다.

이 방식 자체가 잘못된 것은 아니다. 단일 모델 응답을 더 꼼꼼하게 만드는 데는 유용할 수 있다. 다만 실제로 서로 다른 프로필이 별도 도구·근거·검증 경계를 갖는 시스템과는 성격이 다르다.

🔬 평가는 여섯 단계로 진행했다

1. 원본을 커밋에 고정했다

main이라는 움직이는 이름 대신 다음 커밋을 기준으로 삼았다.

6a5de130d8a6b74399ff3279702b56797f446ffc

평가 당일 저녁에 원격 main을 다시 읽었을 때도 같은 커밋이었다. 따라서 오전 감사와 이 사례글은 같은 소스 snapshot을 보고 있다.

2. 문서 주장과 실제 배선을 대조했다

README만 읽지 않고 다음을 함께 확인했다.

• plugin manifest와 marketplace metadata

• hooks.json

• inject-core.js, inject-marker.js

• 항상 주입되는 persona_core.md, persona_marker.txt

• 9개 source skill

• persona-create, persona-edit 절차

• validate.mjs와 GitHub Actions workflow

3. 호스트 호환성을 격리 환경에서 시험했다

Codex 0.146.0의 plugin·marketplace 기능을 확인하고, 실제 사용자 설정과 분리한 임시 환경에 v1.1.1을 설치했다.

• 플러그인: enabled로 인식

• 실제 사용자 Codex 설정 파일: 전후 해시 동일

• source 파일: 20개

• 설치 cache: 21개

• 추가 표면: migrated command skill 1개

즉, 설치 가능성은 확인됐지만 source tree와 실제 설치 표면이 완전히 같지는 않았다. 이 사실은 호환 실패가 아니라, source만 읽고 runtime 표면 전체를 안다고 가정하면 안 된다는 경계다.

4. 기준 validator를 실행했다

기준 실행은 초록색이었다.

SoDam-Persona 정합성 검사 — 관점 15명 · 패턴 20개 · 스킬 9개
PASS — 불일치 0건

검증기는 관점 수, 패턴 수, skill 폴더와 frontmatter, 도메인 파일 배선, selected JSON, 면책 문자열, 문서 참조, 개인 절대경로 등을 검사한다. 반복 편집이 많은 프롬프트 패키지에서 이런 불변식을 코드로 고정한 것은 분명한 장점이다.

5. 초록색 PASS를 변이 canary로 공격했다

문제는 “PASS가 무엇까지 증명하는가”였다. 그래서 원본이 아니라 복제본에 일부러 결함을 넣었다.

그림 2. 공식 업무 원장의 실제 canary 결과에서 생성한 카드다. 초록색 기준 PASS와 네 개의 예상 밖 통과, 한 개의 정상 탐지를 함께 보여 준다.

여기서 결론은 “validator가 쓸모없다”가 아니다. 오히려 반대다.

현재 validator는 자신이 구현한 구조적 불변식에는 유용하지만, hook syntax·runtime 선택·내용 충실도·법률 또는 세무 답변의 정확도까지 인증하지는 않는다.

초록색 PASS를 좁은 계약으로 읽으면 좋은 도구다. 제품 품질 인증처럼 넓게 읽으면 위험하다.

6. 기존 시스템과의 중복·충돌을 비교했다

마지막으로 “좋은가?”가 아니라 “우리 구조에 더하는가?”를 물었다.

🧯 가장 큰 실패는 처음부터 ‘설치’를 답으로 놓을 뻔한 것이었다

공개 저장소가 잘 정리되어 있고 기준 validator도 통과하면, 다음 단계는 설치처럼 보인다. 하지만 이 순서는 적합성 평가에서 흔한 함정이다.

README가 친절함
→ 설치 명령이 있음
→ validator PASS
→ 그러니 도입

이 흐름은 기존 시스템이 이미 무엇을 하고 있는지를 빠뜨린다.

TARDIS/Hermes 쪽에는 이미 다음이 있었다.

• 역할별 독립 프로필과 명시적 소유권

• 작업에 맞는 skill을 필요할 때만 불러오는 점진적 공개

• 라우팅 우선순위와 전문 흐름 인계

• source·receipt·hash·독립 review를 분리한 검증 Gate

• 실패와 미실행을 PASS, BLOCKED, NOT_RUN으로 구분하는 완료 상태

SoDam의 핵심 가치는 “한 모델을 더 꼼꼼하게 만드는 것”이다. 반면 기존 시스템의 핵심은 “역할과 증거와 책임을 분리하는 것”이다. 둘을 겹치면 항상 이득이 나는 것이 아니라, 같은 문제를 두 계층에서 반복해 풀 수 있다.

📏 컨텍스트 비용은 토큰 추정이 아니라 파일 바이트로 비교했다

항상 주입되는 두 파일은 다음과 같았다.

심층 경로에서 관련되는 core·marker·trigger·format·safety·full-core 문서 묶음은 78,750바이트였다. 비교 시점의 Hermes Slack 고정 system+tool schema는 110,282바이트였으므로, 이 문서 묶음은 파일·프롬프트 표면 바이트 기준 약 71.4%에 해당했다.

그림 3. 고정 파일 크기와 당시 Hermes prompt-size 영수증에서 생성한 카드다. 토큰 수·지연시간·비용 측정이 아니라 UTF-8 바이트 비교이며, 성능 저하를 직접 측정한 결과가 아니다.

이 수치만으로 “느려진다”고 단정할 수는 없다. tokenizer, 캐시, 실제 skill 선택에 따라 비용이 달라지기 때문이다. 다만 기존 시스템이 이미 컨텍스트를 짧게 유지하고 필요할 때만 자료를 여는 방식을 사용한다면, 상시 core와 매 입력 marker를 추가하는 것은 명백한 구조적 중복 후보다.

🚦 라우팅 충돌은 더 직접적이었다

매 프롬프트 marker에는 SoDam의 규칙과 외부 플러그인의 자동 skill 권유가 충돌할 때 SoDam을 우선하고, 특정 외부 skill 안내를 무시하라는 규칙이 있다.

SoDam을 단독으로 쓰는 환경에서는 의도된 보호장치일 수 있다. 그러나 여러 전문 skill을 중앙 라우터가 선택하는 환경에서는 다음 문제가 생긴다.

중앙 라우터: 이 작업에는 전문 skill을 불러라
SoDam marker: 외부 자동 skill 권유는 무시하라

얇은 어댑터를 만든다고 해도 이 상시 우선순위 규칙을 그대로 가져오면 기존 skill fleet와 충돌한다. 반대로 marker를 제거하면 SoDam의 핵심 동작을 상당 부분 다시 설계해야 한다. 그래서 “얇은 어댑터”가 실제로는 얇지 않다고 판단했다.

🧱 정적 PASS가 놓친 작은 drift도 있었다

두 문서에서는 사람이 편집해야 할 표면이 얼마나 넓은지 드러났다.

1. persona-edit는 “아래 4곳”을 모두 고치라고 적었지만 실제 목록은 5곳이었다.

2. persona-create는 현재 9개 skill인 상태에서도 README의 “스킬 7개” 표기를 갱신하라는 과거 지시를 남기고 있었다.

작은 문구 오류다. 하지만 한 페르소나를 추가할 때 core, marker, trigger, format, reference, README, validator까지 여러 파일을 함께 고치는 구조에서는 작은 drift가 유지비를 보여 주는 신호가 된다.

⚖️ 세 가지 도입안의 최종 판정

그림 4. 평가 receipt의 최종 결정과 선택 흡수 항목에서 생성한 카드다. 제품의 절대적 우열이 아니라 현재 TARDIS/Hermes 환경에 대한 적합성 판정이다.

여기서 NO-GO는 “저장소가 나쁘다”는 뜻이 아니다. 현재 시스템에는 같은 목적을 더 강한 책임 분리와 검증 경계로 이미 수행하는 층이 있다는 뜻이다.

🌱 실제로 가져갈 만한 다섯 가지

1. 쉬운말(원문 용어) 설명

처음 등장하는 전문용어를 쉬운말과 함께 설명하는 방식은 비개발자 온보딩에 유용하다. 문서를 두 번 쓰지 않고도 정확성과 접근성을 함께 높인다.

2. 위험·복잡도에 따른 답변 깊이

짧은 조회와 고위험 작업을 같은 분량으로 다루지 않는 원칙은 좋다. 다만 기존 시스템에서 L0~L3는 다른 컨텍스트 계층명으로 이미 쓰고 있어, 이름은 가져오지 않고 짧게 / 기본 / 심층 / 고위험 같은 일반 표현만 사용한다.

3. 한 번에 하나씩 묻는 편집 인터뷰

페르소나 생성·편집 때 질문을 한꺼번에 쏟지 않고 한 단계씩 확인하는 방식은 사용자의 결정 부담을 줄인다. 파일을 바꾸기 전에 변경 줄을 보여 주는 계약도 재사용할 가치가 있다.

4. drift를 코드로 잡으려는 태도

관점 수·skill 수·배선·참조를 validator에 넣은 방향은 맞다. 여기에 다음을 더해야 한다.

JSON 전체 syntax
→ hook JavaScript syntax
→ 필수 콘텐츠 최소계약
→ 음성 fixture
→ 실제 host load
→ 대표 runtime canary
→ 응답 품질 또는 도메인 정확도 평가

5. 비어 있던 라우팅 경계

회계·세무, 마케팅·카피, 자동매매 시스템은 기존 역할표에서 경계가 덜 분명했다. 새 “15년 경력 전문가” 페르소나를 만드는 대신 다음 경계만 명확히 하는 편이 낫다.

• 회계·세무: 관할·기준연도·세목·공식 출처·전문가 확인

• 마케팅·카피: 타깃·가치·CTA·주장 입증, 시각물과 법률 쟁점은 별도 소유자

• 자동매매: 기업가치 분석과 체결·슬리피지·kill switch 같은 시스템 위험 분리

🛑 가져오지 않은 것

• 매 사용자 입력에 반복되는 6,980바이트 marker

• 외부 skill 자동 권유를 우선순위로 무시하는 규칙

• 실제 독립 실행자처럼 오해할 수 있는 “15명 전문가” 표현

• 법률·세무 답변을 공식 출처·관할·기준시점 검증 없이 persona 면책만으로 처리하는 흐름

• 한 변경을 여러 중복 파일에 동기화하는 create/edit 구조

• 기준 validator의 PASS를 runtime·응답 품질 인증으로 확대하는 해석

📐 Before와 After

🧾 Trace · Proof · Verdict · Repair

Trace

공개 저장소 링크
→ 원격 main과 고정 commit 확인
→ README·hook·skill·validator·CI 대조
→ Codex 격리 설치와 설정 무변경 확인
→ 기준 validator PASS
→ 다섯 가지 변이 canary
→ 컨텍스트 바이트·라우팅·역할 중복 비교
→ 통째 설치 / adapter / 선택 흡수 판정

Proof

• 고정 커밋과 평가 당일 재조회한 원격 main 일치

• Codex 격리 설치에서 v1.1.1 enabled 확인

• 실제 사용자 Codex 설정 해시 전후 동일

• 기준 validator exit 0

• 변이 canary 5개 중 구조적 관점 수 drift 1개 탐지

• syntax·내용 충실도 관련 변이 4개 예상 밖 통과

• core 19,087바이트, marker 6,980바이트, 심층 관련 문서 묶음 78,750바이트

• 외부 자동 skill 권유를 거부하는 marker 규칙 직접 확인

• create/edit 문서의 다중 파일 동기화 drift 직접 확인

Verdict

whole_install: NO-GO
persistent_adapter: NO-GO
reference_only_clean_room_selection: GO
production_installation: NOT_RUN
response_quality_ab_test: NOT_RUN
latency_or_token_cost: NOT_MEASURED
legal_or_tax_accuracy: NOT_RUN

Repair

• 제품의 설치 가능성과 현재 시스템의 적합성을 분리했다.

• 초록색 PASS를 인증서로 읽지 않고, 변이 canary로 좁은 계약을 확인했다.

• “15명”을 독립 에이전트로 부르지 않고 한 모델의 관점 체크리스트로 재분류했다.

• 컨텍스트 크기는 토큰·속도 주장으로 확대하지 않고 UTF-8 바이트 비교로 한정했다.

• 통째 설치 대신 기존 품질·라우팅 규칙에 들어갈 최소 원칙만 남겼다.

📋 다른 공개 저장소에도 쓸 수 있는 적합성 평가 체크리스트

[ ] 움직이는 main 대신 commit과 license를 고정한다.
[ ] README 주장과 manifest·hook·runtime 코드를 대조한다.
[ ] 별도 AI, 독립 agent, prompt package를 구분한다.
[ ] 실제 host에서 격리 설치 또는 load canary를 실행한다.
[ ] 운영 설정·credential·profile의 전후 hash를 확인한다.
[ ] 기준 validator가 통과하는지 본다.
[ ] 반드시 실패해야 할 변이를 만들어 validator의 음성 탐지력을 본다.
[ ] syntax·배선·내용·runtime·품질·도메인 정확도를 별도 Gate로 나눈다.
[ ] 상시 컨텍스트와 기존 prompt/skill 예산을 같은 경계로 비교한다.
[ ] 기존 라우터·역할 소유권·전문 agent와 충돌하는 우선순위를 찾는다.
[ ] 설치, adapter, 아이디어 흡수를 서로 다른 선택지로 평가한다.
[ ] 측정하지 않은 속도·비용·정확도 개선을 만들지 않는다.
[ ] 도입하지 않기로 한 이유도 재사용 가능한 결과로 기록한다.

💬 재사용 가능한 프롬프트

이 공개 저장소를 바로 설치하지 말고, 우리 시스템에 대한 적합성 평가를 먼저 수행해 주세요.

1. 원격 저장소 URL·commit·version·license를 고정합니다.

2. README 주장과 manifest·hook·skill·validator·CI를 대조합니다.

3. 이 프로젝트가 독립 엔진인지, 기존 모델에 규칙을 주입하는 prompt package인지 구분합니다.

4. 운영 설정을 건드리지 않는 격리 환경에서 host load를 확인합니다.

5. 기준 validator를 실행한 뒤 invalid JSON, broken syntax, empty content, hollow domain skill, count drift 같은 음성 canary를 만듭니다.

6. PASS가 실제로 증명하는 범위와 NOT_RUN 범위를 분리합니다.

7. 우리 쪽 기존 역할·라우팅·skill·memory·검증 Gate와 중복 또는 충돌하는 지점을 찾습니다.

8. 통째 설치 / 얇은 adapter / 원칙만 선택 흡수를 각각 판정하고, 측정하지 않은 성능 향상은 주장하지 않습니다.

🚧 아직 확인하지 않은 것

• 실제 사용자 업무에서 SoDam 적용 전후 응답 품질 비교

• tokenizer 기준 추가 토큰과 실제 비용·지연시간

• Codex의 장기 세션·컴팩션 뒤 선택 정확도

• 외부 plugin과 함께 실행한 충돌 회귀

• 법률·세무 답변의 관할·행위시법·공식 출처 정합성

• 여러 모델과 Codex 버전에서의 호환성 행렬

• production TARDIS/Hermes 설치와 rollback drill

따라서 이 사례의 성과는 “SoDam을 도입해 품질이 좋아졌다”가 아니다. 설치 전에 검증 범위와 기존 시스템의 책임 경계를 비교해, 도입하지 않을 것과 선택해서 배울 것을 구분했다는 데 있다.

📚 출처와 재현 경계

• 업스트림 저장소: sodam-ai/SoDam-Persona

• 고정 커밋: 6a5de130d8a6b74399ff3279702b56797f446ffc

• 프로젝트 설명과 구성: README.md

• hook 배선: hooks.json

• 상시 marker와 plugin 우선순위: persona_marker.txt

• 기준 validator: validate.mjs

• 편집 표면: persona-edit, persona-create

• 라이선스: Apache License 2.0

📦 공개 경계

• 이 글과 네 장의 데이터 파생 증거 카드는 로컬 Lecture_Recap_Library 사례글을 위한 공개 안전본이다.

• 실제 사용자 홈 경로, Slack 식별자, credential, token, 내부 prompt와 메시지 본문은 포함하지 않는다.

• 저장소 원본·사용자 Codex 설정·TARDIS/Hermes 운영 프로필은 변경하지 않았다.

• 외부 웹·커뮤니티·이메일 발행은 별도 승인 범위이며 이 사례에서는 수행하지 않았다.

• 이 글의 NO-GO는 현재 시스템 적합성 판정이며, 다른 사용 환경에서의 제품 가치나 성능을 일반화하지 않는다.

현재 판정: SoDam-Persona의 친절한 설명, 단계별 편집, 구조적 validator 아이디어는 참고할 가치가 있다. 그러나 현재 TARDIS/Hermes에는 상시 prompt 주입과 가상 관점보다 강한 역할 소유권·점진적 skill loading·증거 Gate가 이미 있다. 그래서 플러그인은 설치하지 않고, 원칙만 기존 체계 안에 선택 흡수하는 것이 가장 안전하고 유지 가능한 경로였다.