표준을 강제하지 말고 seed를 주라 — 자기진화 구조와 조직 확산

사내 표준 도구를 정하고 배포하면 대개 쓰이지 않는다. 이 사실은 널리 관찰되는데도 원인 진단은 늘 같은 자리에 머문다 — 교육이 부족했다, 홍보가 약했다, 도구가 아직 덜 익었다. 그런데 이 시리즈가 다룬 자료의 마지막 장은 다른 답을 내놓는다. 개인이 일하는 방식과 팀이 일하는 방식이 애초에 일치하지 않는다.

이 글은 두 가지를 붙인다. 하나는 하네스가 스스로 나아지는 구조 — 사람의 승인과 반려가 학습 신호가 되고, 그 신호가 스킬과 메모리를 갱신하는 루프. 다른 하나는 그 구조를 조직에 퍼뜨릴 때의 형태 — 표준이 아니라 seed와 fork. 앞 편이 다섯 부품을 열었다면 이 글은 그 부품이 시간에 따라 변하고 사람 사이로 퍼지는 방식을 본다.

마지막으로 세 달치 자료를 스무 개 명제로 종합하고, 90일 로드맵으로 닫는다. 시리즈 전체의 출발점은 첫 편에 있다.

이 글은 2026년 1월부터 3월까지의 자료를 정리한 것이다. 등장하는 사례·수치는 모두 원 자료의 것이다.

용어 정리

앞 편들의 용어표에서 이 글이 쓰는 행만 추리고, 진화 구조 용어를 더했다.

고정된 워크플로우의 한계

먼저 무엇이 문제인지부터다. 기존 구조의 한계로 지목된 것은 둘이다 — 고정된 워크플로우 구조, 그리고 피드백 루프로 인한 수정 반영이 제한적이라는 것. 두 번째가 첫 번째의 결과다. 흐름이 코드에 박혀 있으면 운영에서 배운 것이 돌아올 자리가 없다.

돌아올 자리를 만든 첫 형태가 배경 상시 동작 에이전트다.

도식의 화살표에는 두 개의 라벨이 붙어 있었다 — Learn preferences over time, Run agent tests. 사람의 승인 행위가 두 방향으로 갈라진다는 뜻이다.

승인은 결과물을 내보내는 동작이면서 동시에 학습 신호이고 테스트 케이스다.

사람이 "이 초안 괜찮다"고 누르는 순간 세 가지가 동시에 일어난다. 메일이 나가고, 선호가 메모리에 쌓이고, 그 사례가 회귀 테스트 자산이 된다. 조직 관점에서 이것이 갖는 함의는 승인·반려 로그를 수집 대상으로 설계해야 한다는 것이다. 대부분의 승인 워크플로는 결재 기록만 남기고 판단 근거를 버리는데, 버려지는 그 부분이 여기서는 자산이다.

같은 원리를 스킬로 확장하면 이렇게 된다.

두 도식의 차이는 피드백이 무엇을 고치느냐에 있다. 앞 도식에서 피드백은 메모리만 갱신했다. 이 도식에서는 Update Skill과 Update Memory 두 갈래로 갈린다 — 절차 자체가 바뀌는 경로가 하나 더 생긴 것이다. 메모리는 "무엇을 기억할 것인가"이고 스킬은 "어떻게 할 것인가"라, 후자가 갱신되면 다음 실행의 동작 방식이 달라진다.

Self-evolving 하는 좋은 기틀이 마련됐고, 조직 차원의 맞춤형 시스템과 개인화된 시스템에 그대로 적용할 수 있다.

다만 자료가 함께 제시한 그래프를 봐야 한다. 가로축이 수정 횟수, 세로축이 성능인데 곡선이 톱니 모양으로 오르내리면서 전체적으로만 우상향한다. 개별 수정은 성능을 떨어뜨리기도 한다는 뜻이다. 자동 개선 루프를 켤 때 단일 변경의 효과로 판정하면 안 되고 누적 추세로 봐야 하며, 그러려면 판정 주기와 롤백 경로가 먼저 있어야 한다.

팀을 위해 만들었는데 틀렸다

발표의 마지막 장은 발표자가 그날 팀에 보낸 메시지 전문이었다. 이 시리즈에서 조직 관점으로 가장 값진 대목이다.

시간 날 때마다 하네스를 본격적으로 만들어 본 게 1주일이 조금 넘은 것 같습니다. 그동안 여러 배포판의 플러그인을 활용하는 데만 집중하다가 "이제는 만들어 봐야겠다"고 결심해서 만든 지 일주일입니다.

처음에는 팀원을 위해서 유용한 플러그인을 만들어야겠다는 생각이었습니다. 하지만 점점 만들면 만들수록 제 생각이 틀렸다는 것을 깨달았습니다. 하네스는 결국 "나의 일을 줄여주는 역할"이 1번이라는 것을요.

"내가 일하는 방식"과 "팀이 일하는 방식"은 일치하지 않습니다. 그렇기 때문에 Team Harness는 이상적인 목표이나 현실과는 괴리가 발생합니다. 그래서 여러분들은 개인의 하네스를 구축해야 합니다. 팀을 위해서가 아닌 개인이 일을 덜 하는 방향으로요.

물론 우리는 겹치는 일이 많기 때문에 Team Harness가 이를 매우 많이 지원해 나갈 수 있습니다. 그럼에도 우리의 일은 100% 공통 분모로 엮일 수 없기에, 결국 개인만의 하네스가 필요합니다.

하지만 우리는 모두가 여유로운 상황이 아니기 때문에 팀 차원의 하네스를 동료 한 분이 먼저 만들어 주셨습니다. 이 seed를 시작으로 여러 fork를 통해 나만의 것으로 만들어 나가시길 바랍니다. 저도 힘을 보태기 위해 제게 맞춘 하네스를 공유드립니다. 아직 버그도 있고 수정해 나갈 부분이 있지만, 건물을 세우기 위한 토지 작업 정도는 해 놓은 수준입니다. 코드는 자유롭게 복사해도 좋고, fork 해도 좋고, 직접 기여하셔도 좋습니다.

이 메시지가 뒤집은 통념은 "좋은 도구를 만들어 배포하면 팀이 쓴다"는 것이다.

실패 원인은 도구의 완성도가 아니라 전제에 있다. 개인의 작업 방식이 팀 평균과 일치하지 않기 때문에, 팀 평균에 맞춘 도구는 누구에게도 딱 맞지 않는다. 올바른 형태는 팀이 seed를 제공하고 개인이 fork해 진화시키는 구조다 — 표준화가 아니라 분기 가능한 공통 기반이 답이다. 이 결론이 실무적으로 값을 하는 이유는 팀 리드가 할 일을 바꾸기 때문이다. "무엇을 표준으로 정할 것인가"가 아니라 "어디까지가 공통 분모인가"를 묻게 되고, 후자는 만들기 전이 아니라 몇 달 써 본 뒤에야 답할 수 있다.

이 구조는 다음 시리즈에서 거버넌스 문제로 다시 나온다. 공통 자산과 개인 자산에 같은 승인 절차를 걸면 둘 중 하나가 죽는다는 논지이며, 여기서 나온 seed·fork가 그 논지의 전제다.

세 달을 관통하는 흐름

한 장의 연표

둘째 편의 연표와 같은 축이지만 마지막 마디가 하나 더 붙었다. Self-evolving이 level 4가 아니라 "다음"으로 표기된 것이 이 도식의 절제다. 자기진화가 자율성 등급을 올리는 것이 아니라 같은 등급 안에서 시스템이 나아지는 것이라는 뜻이다.

세 자료의 역할 분담

세 행이 이 시리즈의 다섯 편에 그대로 대응한다 — 1월이 첫 편, 2월이 둘째·셋째 편, 3월이 넷째 편과 이 글이다. 청중 열이 다르다는 것이 분할의 근거이기도 하다. 엔지니어용 자료와 경영진용 자료를 한 글에 섞으면 양쪽 다 읽지 않는다.

여섯 명제

여섯이 하나의 사슬이다. 각 마디가 앞 마디의 결과이며, 마지막 두 마디가 이 글의 주제다.

스무 개 명제와 그 한계

네 번째 열이 이 표의 존재 이유다. 앞 세 열만 있으면 주장 목록이지만 반대 논거가 붙으면 인용 가능한 형태가 된다.

스무 행 중 한계 열에 "단일 사례" 또는 "예측이지 실측 아님"이 붙은 것이 다섯이다(1·2·5·13·14). 이 다섯은 조건을 떼어 내면 주장이 과장된 형태로 남는다. 나머지 열다섯은 구조에 대한 진술이라 수치 조건이 없는 대신, 조직 조건에 따라 성립 여부가 갈린다.

90일 로드맵

첫 구간의 검증 지표가 "기준선의 존재 여부"라는 점이 이 표의 설계다.

0~30일에는 개선을 요구하지 않는다. 측정만 있으면 통과다. 대부분의 AI 도입이 실패하는 이유가 여기 있는데, 착수 전 값을 재지 않으면 나중에 무엇이 좋아졌는지 말할 수 없고, 말할 수 없으면 다음 예산이 나오지 않는다. 90일 계획에서 가장 중요한 결정은 60일과 90일에 무엇을 할지가 아니라 30일에 아무것도 만들지 않겠다는 결정이다.

세 번째 구간의 마지막 항목 — 팀 하네스를 seed로 공개하고 fork를 장려한다 — 이 이 글의 결론이 로드맵에 박힌 자리다. 표준으로 배포하면 90일 차에 채택률을 보고해야 하지만, seed로 공개하면 fork 수를 보고하면 된다. 지표가 달라지면 행동이 달라진다.

여기까지가 2026년 상반기다. 컨텍스트를 파일로 밀어내는 구조가 자리를 잡았고, 조직은 역할을 세 층으로 다시 나눴고, 하네스는 피드백으로 스스로 갱신되기 시작했으며, 확산의 형태는 표준이 아니라 seed와 fork로 정리됐다.

그런데 이 서사에는 아직 검증되지 않은 전제가 하나 있다. 하네스를 잘 만들면 성능이 좋아진다는 전제다. 정말 그런가 — 모델을 고정한 채 하네스만 바꿔서 얼마나 달라지는지, 그리고 진화 루프를 켰을 때 누가 언제 검토할 것인지. 다음 시리즈에서 Agent = Model + Harness라는 등식과 그것을 뒷받침하는 벤치마크 실증, 그리고 자율성과 거버넌스가 왜 한 쌍인지를 본다.

에이전트가 개발조직 구조를 어떻게 바꾸는지, 팀 생산성을 무엇부터 재야 하는지는 운영 Q&A에 결론부터 정리돼 있다.