최근의 AI 개발에서는 자주 이런 이야기를 듣습니다.

"AI에게 너무 세세하게 지시하지 않는 것이 좋다"

"목적만 전달하고 나머지는 AI에게 맡기는 것이 좋다"

"AI 에이전트(AI Agent)에게는 자율적으로 생각하게 하는 것이 좋다"

이러한 사고방식은 상당히 이해가 갑니다.

실제로 AI에게 너무 세세한 절차를 지정하면, AI의 제안 능력을 제한해 버리는 경우가 있습니다.

목적을 전달하고 폭넓게 맡기는 편이 생각보다 더 좋은 해결책을 내놓기도 합니다.

하지만 이것이 항상 옳은 것은 아니라고 생각합니다.

특히 팀 개발(Team Development)에서 기존 코드에 변경을 가하는 경우에는 주의가 필요합니다.

먼저, AI에게 세세하게 지시하지 않는 것이 좋은 상황이 있습니다.

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

• 새로운 기능의 아이디어 도출
• 구현 방침의 비교
• 프로토타입(Prototype) 작성
• 라이브러리(Library) 선정
• UI 안 검토
• 아키텍처(Architecture) 안 도출

이런 상황에서는 AI에게 폭넓게 생각하게 하는 것이 좋을 때가 있습니다.

인간이 처음부터 세세한 절차를 너무 많이 정해버리면, AI의 제안이 좁아집니다.

스스로는 생각하지 못했던 설계나 다른 구현 방침을 얻기 위해서는, 어느 정도 자유롭게 생각하게 하는 것이 유효합니다.

즉, 탐색(Exploration) 단계에서는 AI의 자율성을 활용할 가치가 있습니다.

반면, 기존의 팀 개발에 코드를 넣는 단계에서는 이야기가 달라집니다.

기존 코드에는 이미 설계가 있습니다.

명명 규칙(Naming Convention)이 있습니다.

책임 분담(Responsibility)이 있습니다.

다른 멤버의 작업이 있습니다.

리뷰(Review)의 사정이 있습니다.

릴리스(Release)의 사정이 있습니다.

이 상태에서 AI에게 자유롭게 구현하게 하면, 차이(Diff)가 너무 커지는 경우가 있습니다.

AI가 좋다고 생각해서 공통화하거나, 파일을 분할하거나, 상태 관리(State Management)를 바꾸기도 합니다.

그 자체는 좋은 제안일지도 모릅니다.

하지만 지금 그 변경을 섞어야 하는지는 별개의 문제입니다.

팀의 기존 코드에 넣는 단계에서는 AI에게 제약(Constraint)을 주는 것이 안전합니다.

여기서 중요한 것은 "세세하게 지시하지 않는 것"과 "제약을 주지 않는 것"은 다르다는 점입니다.

세세하게 지시하지 않는다는 것은 AI에게 구현 절차를 모두 지정하지 않는다는 의미입니다.

반면, 제약을 주지 않는다는 것은 변경 범위나 금지 사항도 전달하지 않는다는 의미입니다.

이것은 나누어서 생각해야 합니다.

예를 들어, 다음과 같은 의뢰는 좋은 균형이라고 생각합니다.

목적: 사용자 목록 화면에 부서 검색을 추가하고 싶습니다.
구현 방법은 기존 코드를 읽고 제안해 주세요.
단, 다음의 제약은 지켜주세요.
...

이것은 AI에게 세세한 절차까지는 지정하지 않았습니다.

하지만 팀 개발상의 제약은 명확히 하고 있습니다.

이 균형이 중요하다고 생각합니다.

AI에게 맡겨야 할 일은 많이 있습니다.

• 구현 안 작성
• 유사 코드 조사
• 테스트 케이스(Test Case) 도출
• 차이(Diff) 리뷰
• 리팩토링(Refactoring) 안 제안
• 에러 원인 조사
• 문서 작성

반면, 팀 개발에서는 너무 맡기면 위험한 것도 있습니다.

• 기존 설계의 변경
• 공통 컴포넌트(Common Component)의 책임 변경
• 상태 관리 방식의 변경
• API 클라이언트 구성의 변경
• 파일 구성의 대폭 변경
• 사양 변경과 리팩토링의 혼재

이러한 것들은 AI가 단독으로 판단하는 것보다 팀에서 합의하는 것이 좋습니다.

AI에게 맡길 범위와 인간이 쥐고 있을 범위를 나눌 필요가 있습니다.

AI에 대한 지시는 단계(Phase)에 따라 바꾸는 것이 좋다고 생각합니다.

이 단계에서는 AI에게 폭넓게 생각하게 합니다.

이 기능을 구현하는 방법을 여러 안으로 내주세요.
기존 설계에 대한 영향, 구현 비용, 향후 확장성 관점에서 비교해 주세요.

이 단계에서는 기존 코드와의 정합성을 확인하게 합니다.

기존 구현을 확인하고, 이 프로젝트의 설계에 따른 구현 방침을 제안해 주세요.
기존 패턴에서 벗어나는 경우에는 이유를 설명해 주세요.

이 단계에서는 변경 범위를 제한합니다.

합의된 방침에 따라 구현해 주세요.
변경 대상 파일은 다음과 같이 한정해 주세요.
목적 외의 리팩토링은 수행하지 마세요.

이 단계에서는 차이(Diff)를 확인하게 합니다.

이번 차이를 확인하고, 목적 외의 변경, 불필요한 리팩토링, 기존 책임의 변경이 없는지 확인해 주세요.

이와 같이 AI에게 자유롭게 생각하게 하는 상황과 제약을 거는 상황을 나누는 것이 현실적입니다.

AI는 자유도가 높을수록 다양한 제안을 해줍니다.

이것은 강점입니다.

하지만 팀 개발에서는 자유도가 너무 높으면 차이를 제어하기 어려워집니다.

즉, AI 시대의 팀 개발에서는 AI의 자유도를 관리해야 합니다.

자유롭게 생각하게 해야 할 상황에서는 자유롭게 생각하게 한다.

기존 코드에 삽입하는 상황에서는 제약 사항을 명확히 한다.

이것이 중요합니다.

"AI에게는 세세하게 지시하지 않는 편이 좋다"라는 생각은 틀린 것이 아닙니다.

탐색이나 프로토타입 (Prototype) 단계에서는 AI에게 폭넓게 맡김으로써 좋은 제안이 나올 수 있습니다.

하지만 팀 개발에서 기존 코드에 변경을 가하는 단계에서는 제약이 필요합니다.

중요한 것은 세세한 구현 절차를 모두 지정하는 것이 아닙니다.

변경 범위, 금지 사항, 기존 설계와의 정합성, 리뷰 용이성을 명확히 하는 것입니다.

AI에게 자유롭게 생각하게 하는 상황과 제약을 거는 상황을 나누는 것.

이것이 AI 에이전트 (AI Agent) 시대의 팀 개발에서는 필요할 것이라고 생각합니다.

다음 회차에서는 스티어링 파일 (Steering file)만으로는 부족한 이유와, AI의 편차를 구조적으로 흡수하는 방법에 대해 생각해보겠습니다.

이후 연재 예정 목록입니다.

• 제1회: 같은 AI를 사용하고 있는데, 왜 코드가 제각각인가
• 제2회: AI가 작성한 "동작하는 코드"가 팀 개발에서는 위험한 이유
• 제3회: AI에게 맡겼더니 컨플릭트 (Conflict) 투성이가 된 이야기
• 제4회: AI에게 "이 파일 외에는 건드리지 마"라고 말하는 것은 옳은가
• 제5회: AI 시대의 PR (Pull Request)은 왜 무거워지기 쉬운가
• 제6회: AI에게는 세세하게 지시하지 않는 편이 좋다,는 팀 개발에서도 통용되는가
• 제7회: 스티어링 파일만으로는 부족하다. AI의 편차를 구조로 흡수하기
• 제8회: AI 시대의 베테랑은 코드를 쓰는 사람에서 구조를 만드는 사람으로