Claude Code를 여러 역할로 나누어 웹 제작 실무를 운영하고 있다.

역할마다 정의 파일(Definition file)이 있으며, 그곳에 "무엇을 써도 되는지"에 대한 규칙이 적혀 있다.

며칠 전, 그중 하나를 개정했다.

발신문의 주어에 관한 규칙으로, 방침 자체를 반대 방향으로 바꿨다.

개정은 10분 만에 끝났다.

그 후 3시간이 걸렸다.

개정한 규칙의 내용

원래 규칙은 다음과 같이 적혀 있었다.

AI가 설계·구현한 작업을 대표가 수동으로 한 것처럼 쓰지 말 것

이 규칙을 작성할 당시의 의도는 실태와 다른 방식의 작성을 방지하는 것이었다.

AI가 수행한 작업을 사람이 한 것처럼 쓰면 그것은 사실과 다르다.

그런데 운영하다 보니 이 규칙이 다른 방향으로 작용하기 시작했다.

AI가 수행한 작업을 쓸 때, 주어를 모호하게 만드는 방향으로 치우치게 된 것이다.

"움직여 주었다", "조사하게 했다", "다시 만들어 주었다".

모두 사실에 어긋나지는 않는다.

다만, 누가 했는지가 술어에서 잘 보이지 않게 되었다.

숨기고 있다고 할 정도는 아니다.

하지만 AI가 했다는 사실이 배경으로 물러나 있다.

우리의 운영 실태는 AI 에이전트 조직에서 업무를 돌리고 있다는 것을 공개하고 있으며, 조직 템플릿도 OSS(Open Source Software)로 배포하고 있다.

그런 상태에서 발신문만 주어를 모호하게 하는 것은 정합성이 맞지 않는다.

그래서 규칙을 반대 방향으로 다시 썼다.

AI가 수행한 작업은 AI 주체로 써도 좋다고 명시하는 방향이다.

개정 후의 규칙은 3층 구조가 되었다.

• AI가 수행한 작업(설계, 구현, 조사, 검증, 제작): AI가 주체가 되어도 좋다. 숨기지 않고 쓴다.
• 사람이 실제로 한 것(과제의 발견, 방침의 결정, 기각, 최종 판단, 승인): 사람이 주체가 되어 써도 좋다. 이것은 사실이다.
• 하지 않은 것, 가지고 있지 않은 전문성: 주체가 누구든 쓰지 않는다.

3번째 층만은 구 규칙에서 계승했다.

"AI를 숨기지 마라"와 "가지고 있지 않은 전문성을 사칭하지 마라"는 같은 규칙에 공존하고 있었지만 별개의 금지 사항이다.

전자는 철회할 수 있지만, 후자는 철회할 수 없다.

정의 파일을 고쳐도 외부의 문장은 변하지 않는다

규칙의 재작성 자체는 정의 파일의 두 곳을 편집하는 것만으로 끝났다.

관련된 2개 파일에 대한 참조 추가를 포함해도 10분의 작업이다.

문제는 그 이후였다.

이 규칙에 따라 작성된 문장들이 이미 외부에 나가 있다.

자사 사이트의 카피, 이미 공개된 기사, 게시 대기 중인 초안, 영업용 템플릿.

모두 구 규칙 아래에서 작성되었기에 정의 파일을 고쳐도 자동으로 바뀌지 않는다.

당연한 이야기처럼 들린다.

실제로 작성하기 전까지는 이 양을 가늠하지 못했다.

정리하자면, 고쳐야 할 대상은 두 가지 층으로 나뉘어 있었다.

에이전트가 읽는 규칙 본체(정의 파일)와, 그 규칙에 따라 생성되어 이미 공개되어 있는 문장이다.

이하에서는 전자를 규범층 (Normative layer), 후자를 **라이브층 (Live layer)**이라고 부른다.

규범층은 다시 쓰면 즉시 적용된다.

다음에 에이전트가 움직일 때 새로운 규칙을 읽기 때문이다.

라이브층은 다시 써도 소급 적용되지 않는다.

이미 공개된 문장은 공개된 시점의 규칙으로 고정되어 있다.

그리고 규칙을 배포하는 측이 평소에 보고 있는 것은 규범층 쪽이다.

정의 파일을 고친 시점에서 "대응했다"라고 느껴버린다.

grep으로 재고 조사하기

라이브층에 무엇이 얼마나 남아 있는지를 실제로 세어 보기로 했다.

대상을 4개의 존(Zone)으로 나누었다.

자사 사이트, 공개된 기사, 게시 대기 중인 초안, 영업용 템플릿.

검색할 단어는 구 규칙이 만들어내기 쉬운 표현들로 만들었다.

手作業|手を動か|手動で|一人で|自分の目|人の目|
代表が.{0,20}(設計|実装|制作|調査|チェック|検証)

결과는 자사 사이트에서 10곳, 공개된 기사에서 5계통, 영업 템플릿에서 3곳이었다.

여기서 손이 멈췄다.

검출된 곳을 전부 고치면 된다는 이야기가 아니었기 때문이다.

고쳐서는 안 되는 곳을 먼저 결정하기

검출 결과를 보며 깨달은 것이 있다.

똑같은 "혼자서"라는 단어라도 고쳐야 할 것과 고쳐서는 안 될 것이 섞여 있었다.

예를 들어 자사 사이트에 "독자적인 제작 체제"라는 표현이 있다.

이것은 AI를 숨기기 위해 쓴 것이 아니다.

"AI를 사용하고 있으니 싸다"라는 가격 협상의 근거를 주지 않기 위해 의도적으로 배치한 표현이다.

이를 "AI를 숨기고 있다"라고 오인하여 제거하면 다른 규칙을 망가뜨린다.

데모 사이트 카피에 나오는 "쇼와의 온기"도 검출에 걸렸지만, 이것은 가상의 점포 소개문이지 우리의 작업 주체와는 관계가 없다.

그래서 실사(実査)에 들어가기 전에 세 가지 제외 조건을 결정했다.

• 사람이 실제로 한 일(과제 발견, 방침 결정, 승인, 관찰)을 사람을 주어로 쓰고 있는 부분
• 가격 할인 협상의 근거를 차단하기 위해 배치한 표현
• 결과물 그 자체의 기능을 설명하고 있는 부분

이 세 가지 조건을 먼저 작성하지 않았다면, 기계적인 치환으로 인해 다른 규칙을 망가뜨렸을 것이다.

검색은 기계가 할 수 있지만, 제외 조건은 먼저 사람이 결정해야 한다.

이 부분이 이번에 가장 효과적이었던 설계였다.

제외 조건을 적용한 결과, 10곳의 검출 중 실제로 수정한 곳은 6곳이 되었다.

남은 4곳은 그대로 두었다.

공개된 기사를 어떻게 할 것인가

자사 사이트는 수정할 수 있었다.

판단이 필요했던 것은 공개된 기사 쪽이었다.

과거의 기사에는 "혼자서 수작업으로 하면", "내가 직접 움직이는 시간은"과 같은 표현이 남아 있다.

구 규칙(Old rule) 하에서 작성된 것이기에, 새로운 방침과는 맞지 않는다.

하지만 소급하여 다시 쓰면, 그 기사가 작성되었던 시점의 운영 실태가 사라진다.

당시에는 실제로 그 규칙으로 운영하고 있었던 것이기에, 나중에 수정하면 시계열 기록으로서 거짓이 된다.

그래서 그대로 두기로 했다.

공개된 기사는 당시의 기록으로 취급하고, 새로 작성하는 것부터 신규 방침을 적용한다.

대신, 검색 엔진을 통해 해당 기사로 사람이 유입되는 양을 관찰 항목에 넣었다.

구 톤(Old tone)의 기사에 예상치 못한 유입이 있다면, 그때 개별적으로 판단한다.

수정한 순서

작업 순서도 직접 해보며 알게 된 것이 있다.

처음에는 규범층(Normative layer)과 라이브층(Live layer)을 병행해서 수정하려 했으나, 도중에 멈췄다.

라이브층의 어느 부분을 수정할지에 대한 판단 기준이 개정된 규칙 그 자체이기 때문이다.

규범층을 먼저 확정하고, 그 기준으로 라이브층을 실사한다.

이 순서가 아니면 실사 도중에 기준이 움직이게 된다.

결과적으로 공정은 다음과 같았다.

• 정의 파일 개정 (규범층)
• 관련 파일에 참조 추가 (규범층)
• 제외 조건 확정
• grep으로 범위 리스트화 (라이브층)
• 해당 부분 수정 및 본방 반영
• 게시 대기 중인 초안 다시 쓰기

1과 2에 10분, 3부터 6까지 3시간이 걸렸다.

범위 리스트를 남기기

마지막으로 실사 결과를 파일로 남겼다.

어느 존(Zone)을 검색했는지, 무엇이 검출되었는지, 무엇을 수정하고 무엇을 그대로 두었는지, 그대로 둔 이유는 무엇인지.

이것을 적어두지 않으면 다음에 같은 일을 할 때 "지난번에 어디까지 봤는지" 알 수 없게 된다.

그대로 둔 이유가 남아 있다는 점이 특히 효과적이다.

"왜 이 부분은 수정되지 않았는가"라는 질문을 나중에 받았을 때, 어떤 제외 조건에 해당했는지 보여줄 수 있다.

이번 설계가 효과적이었던 이유

나열해 보면, 이번 작업은 세 가지 분리로 이루어져 있었다.

규범층과 라이브층의 분리.

규칙을 수정하는 것과, 규칙에 따라 작성된 것을 수정하는 것은 별개의 작업이다.

전자는 즉각적으로 효과를 발휘하고, 후자는 소급 적용하지 않는다.

검색과 판단의 분리.

어디에 있는지는 기계가 찾을 수 있지만, 수정해야 할지 말지는 사람이 결정한다.

제외 조건을 미리 결정해 두지 않으면 기계적인 치환이 다른 규칙을 망가뜨린다.

시점의 기록과 현재의 발신의 분리.

공개된 것은 당시의 기록이며, 소급하여 수정하면 기록으로서 성립되지 않는다.

수정하는 것은 현재도 살아있는 카피(Copy)만으로 충분하다.

이 세 가지는 규칙 개정 그 자체보다 범용성이 높다고 생각한다.

AI 에이전트에게 규칙을 배포하여 운용하고 있는 경우, 규범을 다시 쓰는 기회는 앞으로도 올 것이다.

그때마다 라이브층이 뒤처지게 된다.

남아 있는 문제

범위 리스트를 만들었지만, 이것이 망라(Coverage)되어 있다는 보장은 없다.

검색어는 구 규칙이 만들어내기 쉬운 표현들로 만들었기 때문에, 예상치 못한 말투는 누락될 수 있다.

또 하나, 이번에는 규범을 가진 파일이 하나뿐이었기에 실사로 끝났다.

여러 역할이 각기 다른 규칙을 가지고 있고, 그것들이 서로 참조하고 있는 상태에서 같은 일을 하면 어디까지 파급될지 예측하기 어려워진다.

이번 실사에서는 규범을 가진 것이 1개 파일뿐임을 확인하는 데도 grep이 필요했다.

"어디에 규칙이 적혀 있는지" 자체를 파악하지 못하고 있었던 셈이다.

이 부분은 시스템으로서 갖추고 싶다.

에이전트가 지시대로 움직였는지를 로그 측면에서 대조하는 이야기는 전전전 기사에, 여러 에이전트 운용으로 망가진 4곳의 설계는 지난 기사에 썼다.

Discussion