수탁 개발이나 SES, 프리랜서 참여 그 자체를 부정하고 싶은 것은 아닙니다.

다만, AI를 도입했을 때 정보 단절이나 권한 단절이 더욱 눈에 띄게 나타나지 않을까 하는 이야기입니다.

지난번에는 AI 시대에도 히어링(Hearing) 미스는 쉽게 사라지지 않는다는 이야기를 썼습니다.

이번에는 조금 더 구현(Implementation)에 가까운 이야기입니다.

AI 에이전트(AI Agent)를 팀에서 사용할 때, 우선적으로 고려하는 대책 중 하나는 공통 규칙을 정비하는 것입니다.

예를 들어, 다음과 같은 것들이 있습니다.

• AGENTS.md
• CLAUDE.md
• Kiro의 steering file
• Copilot의 custom instructions
• 프로젝트 고유의 AI 이용 규칙
• 공통 프롬프트 (Prompt)
• 템플릿 (Template)
• 하네스 (Harness)

여기서 하네스(Harness)라는 단어는 조금 넓은 의미로 사용하고 있습니다.

AI에게 읽힐 것을 전제로 한 작업 시의 규칙, 실행 방법, 확인 방법 등을 정리하여 각 담당자가 동일하게 사용할 수 있도록 만든 것 정도의 의미입니다.

이러한 공통 규칙이나 하네스는 상당히 중요하다고 생각합니다.

하지만 실제로 해보면 그것만으로는 기대만큼 결과가 일치하지 않는 경우가 있습니다.

같은 규칙을 배포했다.

같은 전제 조건도 전달했다.

비슷한 작업을 하고 있다.

그럼에도 담당자마다 AI의 출력이 미묘하게 다르다.

구현 방침이 어긋난다.

차분(Diff)의 크기가 달라진다.

리뷰(Review)의 용이성도 달라진다.

왜 그렇게 되는 걸까요?

이번에는 "공통 규칙을 배포해도 AI의 출력이 왜 일치하지 않는가"에 대해 생각해 보겠습니다.

AI를 팀 개발에 도입할 때 가장 먼저 생각하는 것은 규칙 정비라고 생각합니다.

예를 들어, 다음과 같은 규칙입니다.

- 기존 코드를 우선한다
- 사양 변경과 관계없는 리팩토링 (Refactoring)을 하지 않는다
- 공통 컴포넌트 (Component)를 임의로 변경하지 않는다
...

이러한 규칙은 유효합니다.

AI에게 매번 같은 전제를 설명할 필요가 없어집니다.

담당자별 작업 방침도 어느 정도 맞추기 쉬워집니다.

리뷰 시에도 "이 규칙을 따르고 있는가"를 확인하기 쉬워집니다.

따라서 공통 규칙을 정비하는 것 자체는 상당히 의미가 있다고 생각합니다.

다만, 여기서 한 가지 과하게 기대했던 부분이 있었습니다.

그것은 공통 규칙을 배포하면 AI의 출력도 상당히 일치할 것이라는 기대입니다.

실제로는 그렇게 단순하지 않았습니다.

같은 규칙을 사용하고 있더라도 담당자마다 AI에게 부탁하는 방식이 다릅니다.

예를 들어, 어떤 사람은 처음에 넓게 조사를 시킵니다.

먼저 기존 코드를 읽고, 구현 방침을 3가지 안으로 제시해 주세요.
아직 변경은 하지 마세요.

다른 사람은 처음부터 구현을 부탁합니다.

이 기능을 추가해 주세요.
기존 구현에 맞춰 주세요.

또 다른 사람은 상당히 세세하게 제약을 작성합니다.

변경해도 좋은 파일은 이 3개뿐입니다.
공통 컴포넌트, API 클라이언트, 상태 관리(State Management)는 변경하지 마세요.
문제를 발견하더라도 보고만 해주세요.

어느 것이 절대적으로 옳다는 이야기는 아닙니다.

작업 내용에 따라서는 넓게 조사시키는 편이 좋을 때도 있습니다.

작은 수정이라면 바로 구현하도록 하는 편이 빠를 수도 있습니다.

영향 범위가 크다면 제약을 강화하는 편이 안전할 수도 있습니다.

다만, 부탁하는 방식이 다르면 AI의 출력도 변합니다.

같은 규칙을 읽게 하더라도 직전의 지시, 읽게 한 파일, 대화의 흐름, 담당자의 판단에 따라 AI의 움직임은 달라집니다.

이 점이 최근 상당히 중요하다고 느끼고 있습니다.

AI에게 부탁하는 방식은 단순한 조작 절차가 아니라고 생각합니다.

그 사람의 일하는 방식이 드러납니다.

설계(Design)에 대한 사고방식이 드러납니다.

신중함이 드러납니다.

두려워하는 포인트가 드러납니다.

어디까지 AI를 신뢰할지도 드러납니다.

바꾸어 말하면, AI에게 말하는 방식에는 그 사람의 정체성(Identity)이 담겨 있다고 생각합니다.

어떤 사람은 AI를 상당히 신뢰하여 크게 맡깁니다.

어떤 사람은 AI를 편리한 보조자로 취급하며 세세하게 확인하면서 진행합니다.

어떤 사람은 AI에게 설계안만 내게 하고 구현은 상당히 제어합니다.

어떤 사람은 AI의 제안을 적극적으로 받아들여 기존 코드도 개선하려고 합니다.

이는 성격의 문제라기보다 경험이나 가치관의 차이라고 생각합니다.

과거에 AI의 큰 차분(Diff)으로 고생했던 사람은 상당히 신중해집니다.

반대로 AI에게 넓게 맡겨서 성공했던 경험이 있는 사람은 크게 맡기고 싶어 합니다.

둘 다 이유가 있습니다.

그래서 "모두 이 방식으로 AI에게 부탁하세요"라고 강제하는 것은 그리 현실적이지 않다고 느끼고 있습니다.

물론 최소한의 규칙이나 금지 사항은 필요합니다.

하지만 AI와의 대화 방식을 완전히 통일하려고 하면 상당한 무리가 따릅니다.

공통 프롬프트 (Common Prompt)를 준비할 수는 있습니다.

예를 들어, 다음과 같은 템플릿입니다.

목적:
변경해도 좋은 범위:
변경해서는 안 되는 범위:
...

이것은 상당히 유효합니다.

특히 경험이 적은 멤버가 AI에게 대충 의뢰하여 의도하지 않은 큰 차분 (Diff)을 만들어 버리는 것을 방지하는 효과가 있습니다.

다만, 템플릿을 배포하더라도 그 안에 무엇을 쓸지는 사람에 따라 달라집니다.

어디까지를 변경 가능 범위로 볼 것인가.

무엇을 금지 사항으로 적을 것인가.

어떤 기존 설계 (Existing Design)를 중요하다고 판단할 것인가.

구현 전에 어디까지 조사하게 할 것인가.

여기에는 담당자의 판단이 들어갑니다.

즉, 프롬프트의 형식은 맞출 수 있어도 프롬프트의 내용까지는 완전히 맞출 수 없습니다.

그리고 그 내용의 차이가 AI 출력의 차이로 이어집니다.

여기서 말하고 싶은 것은 공통 규칙이 무의미하다는 뜻이 아닙니다.

오히려 공통 규칙은 필요합니다.

다만, 공통 규칙에 기대하는 역할을 잘못 설정하면 잘 풀리지 않는다고 생각합니다.

공통 규칙은 AI의 출력을 완전히 일치시키는 마법이 아닙니다.

그보다는 AI와 인간이 작업할 때의 최소한의 기준선을 맞추는 것입니다.

예를 들어, 다음과 같은 효과입니다.

• 멋대로 하는 대규모 리팩터링 (Refactoring)을 줄임
• 변경 범위를 의식하게 함
• 기존 설계를 우선시함
• 작업 전 확인을 촉구함
• 작업 후 설명을 통일함
• 리뷰 관점을 공유함

이것은 충분히 가치가 있습니다.

하지만 공통 규칙만으로 담당자마다의 판단이나 AI에게 말하는 방식까지 맞출 수는 없습니다.

그 전제하에 팀 설계 (Team Design)를 생각할 필요가 있습니다.

AI에게 말하는 방식을 완전히 맞추기 어렵다면, 무엇을 맞춰야 할까요?

저는 담당 경계와 결과물의 조건을 맞추는 것이 더 현실적이지 않을까 생각합니다.

예를 들어, 다음과 같은 것들입니다.

• 이 담당자가 책임지는 업무 범위
• 변경해도 좋은 코드 범위
• 변경해서는 안 되는 공통 영역
• 타 기능과의 인터페이스 (Interface)
• 데이터의 정합성 (Truth)
• 상태 전이 (State Transition)
• 수락 조건 (Acceptance Criteria)
• 리뷰 관점

즉, 'AI에게 어떻게 말할지'를 완전히 구속하는 것이 아니라, '최종적으로 만족해야 할 조건'을 맞춘다는 사고방식입니다.

AI에게 부탁하는 방식에는 개인차가 있습니다.

그 부분을 완전히 없애는 것은 어렵습니다.

하지만 담당 범위, 책무, 인터페이스, 수락 조건이 명확하다면, AI 사용법이 다소 다르더라도 결과물의 어긋남은 억제하기 쉬워집니다.

AI를 사용하는 팀 개발에서는 너무 세세한 작업 분담이 어려워질 때가 있습니다.

예를 들어, 다음과 같은 방식입니다.

A님: 화면의 입력 항목
B님: 유효성 검사 (Validation)
C님: API 호출
...

인간만으로 개발하던 시대에도 어려운 분담이지만, AI를 사용하면 더욱 어려워질 수 있습니다.

각 담당자가 AI를 사용하여 저마다 조금씩 괜찮아 보이는 방향으로 수정합니다.

그러면 입력 항목, 유효성 검사, API, 상태 관리, 공통 컴포넌트의 전제가 조금씩 어긋납니다.

게다가 각각의 차분 (Diff)만 보면 나쁘지 않을 수도 있습니다.

하지만 마지막에 합쳐보면 미묘하게 맞지 않습니다.

이것은 AI의 출력 품질이 낮다기보다, 작업 분담이 너무 세세해서 각 AI가 국소적인 문맥 (Context) 안에서 움직이고 있기 때문일지도 모릅니다.

따라서 AI를 사용한다면 담당자를 나누는 방식을 조금 바꾸는 것이 좋지 않을까 느낍니다.

세세한 부품 단위가 아니라, 조금 더 큰 업무 블록이나 책무 단위로 나눕니다.

예를 들어, 다음과 같은 방식입니다.

A님: 신청 플로우 (Flow) 전체
B님: 청구 데이터의 등록부터 확정까지
C님: 통지 설계와 통지 이력
...

이런 방식으로 나누면 담당자와 AI가 하나의 응집된 문맥을 갖기 쉬워집니다.

화면, API, 상태, 유효성 검사, 테스트를 따로따로 보는 것이 아니라, 하나의 업무 흐름으로서 생각하기 쉽습니다.

물론 크게 나눈다고 해서 모든 것이 해결되는 것은 아닙니다.

너무 큰 담당은 리뷰하기 어려워지고, 특정 인원에게 의존하는 현상 (Silo/Individualization)도 발생합니다.

다만 AI를 사용하는 경우, 너무 세세한 부품 단위로 나누면 담당자마다의 프롬프트 차이가 그대로 설계의 어긋남으로 나타나기 쉽다고 생각합니다.

그런 의미에서 AI 시대의 담당 나누기는 단순한 작업량이 아니라, 문맥의 덩어리로 생각할 필요가 있을지도 모릅니다.

여기까지 쓰면 '그럼 공통 규칙은 필요 없는 것인가'라고 보일 수도 있습니다.

그렇지 않습니다.

공통 규칙은 필요합니다.

다만 목적을 조금 바꾸어 생각할 필요가 있습니다.

공통 규칙의 목적은 모든 사람의 AI 출력을 완전히 동일하게 만드는 것이 아닙니다.

오히려 다음과 같은 목적이라고 생각합니다.

• 해서는 안 될 일을 명확히 하기
• 리뷰 불가능한 차분 (diff)을 줄이기
• AI가 망설일 때의 판단 기준을 두기
• 담당 경계를 넘어서는 변경을 방지하기
• 작업 후의 설명을 남기기
• 팀으로서 최소한의 안전성을 확보하기

즉, 공통 규칙은 '개인차를 없애는 것'이 아니라, '개인차가 있어도 망가지기 어렵게 만드는 것'입니다.

이러한 관점이 현실에 더 가깝다고 느껴집니다.

AI 에이전트 (AI Agent)를 팀 단위로 사용한다면, 공통 규칙이나 하네스 (Harness)는 상당히 중요합니다.

다만, 그것을 배포한다고 해서 모든 사람의 AI 출력이 일치할 정도로 단순하지는 않다고 생각합니다.

같은 규칙을 읽게 하더라도, 담당자마다 AI에게 부탁하는 방식은 다릅니다.

어디까지 맡길 것인가, 어디서 멈출 것인가, 어떤 파일을 읽게 할 것인가, 어떤 제안을 채택할 것인가.

그곳에는 그 사람의 업무 방식이나 설계 관점이 나타납니다.

AI에게 말하는 방식에는 그 사람의 정체성 (Identity)이 있습니다.

그리고 그것을 완전히 강제하는 것은 어렵습니다.

그렇기에 팀으로서 맞추어야 할 것을 조금 바꿀 필요가 있다고 생각합니다.

말투를 완전히 맞추는 것이 아니라, 담당 경계를 맞춘다.

프롬프트 (Prompt)를 완전히 통일하는 것이 아니라, 결과물의 수락 조건 (Acceptance Criteria)을 맞춘다.

세세한 부품 단위로 사람을 나누는 것이 아니라, 문맥을 가질 수 있는 업무 블록 (Business Block) 단위로 생각한다.

AI 시대의 팀 개발에서는 개인의 AI 활용을 억지로 균일화하기보다, 개인차가 있어도 파탄 나기 어려운 분담과 리뷰 메커니즘을 만드는 것이 더 중요할지도 모릅니다.