우선 AI에게 맡기는, 인간을 예외 처리하는 AI-default 개발 스타일

생성형 AI를 개발에 사용할 때 '어디까지 AI에게 맡겨야 하는가'라는 논의가 있습니다.

저는 처음부터 '이것은 인간만이 할 수 있다'고 선을 긋기보다는, 우선 AI에게 맡겨보는 것이 좋다고 생각합니다. 요구사항 이해, 조사, 구현, 테스트 설계, PR 작성 등 대상을 한정하지 않고 일단 시켜봅니다.

그 후에 AI만으로는 완수할 수 없었던 부분이 있다면, 왜 불가능했는지 알아봅니다. 필요하다면 인간이 그 부분만 실행하고, 얻은 지식을 Skill이나 규칙으로 되돌립니다.

이 글에서는 제가 실천하고 있는 'AI를 보조적으로 사용하는' 것이 아니라, 'AI가 작업을 기본값(default)으로 하도록 하는' 개발 스타일을 정리합니다.

흔히 볼 수 있는 AI 활용 방식은 인간이 업무를 분해하고, 그중에서 AI에게 적합한 작업만 넘겨주는 형태입니다.

인간이 업무를 이해한다
↓
AI에게 맡길 부분을 찾는다
...

저는 역순으로 생각합니다.

목표(Goal)를 AI에게 전달한다
↓
우선 AI가 전부 해보게 한다
...

즉, 'AI에게 무엇을 맡길지'를 인간이 먼저 좁게 정의하지 않습니다.

요구사항 이해, 코드 리딩, 구현, 테스트 설계, 테스트 실행, 수정, PR 작성까지, 하나의 일관된 업무로 맡깁니다.

중요한 것은 처음부터 AI의 능력을 낮게 평가하지 않는 것입니다.

AI가 작업을 완수하지 못했을 경우, 인간이 즉시 개입할 필요는 없습니다.

먼저, 다음과 같은 것들을 AI 스스로 생각하게 합니다.

• 왜 실행할 수 없는지
• 부족한 정보는 무엇인지
• 다른 툴로 대체할 수 있는지
• CLI나 API로 실행할 수 있는지
• 브라우저 조작으로 대체할 수 있는지
• 테스트나 확인 절차를 추가하면 자율적으로 진행할 수 있는지
• 다음부터 같은 문제를 피하기 위해 무엇을 남겨야 하는지

여기서의 핵심은 AI가 바로 사용할 수 있는 환경만을 대상으로 삼지 않는 것입니다.

'현재 환경에서는 불가능하다는 사실'과 'AI에게 할 수 없는 일이다'는 별개입니다. 실행 경로나 환경을 바꾸면, AI에게 맡길 수 있는 경우가 있습니다.

물론 현실적으로 AI만으로는 돌파할 수 없는 작업이 있습니다.

특히 회사 환경에서는 다음과 같은 제약이 있습니다.

• 권한 부족
• 사용 가능한 툴의 제한
• 보안상의 제약
• 사내 네트워크에서만 접근 가능한 시스템
• AI가 직접 조작할 수 없는 GUI
• 인간의 승인이 필요한 작업

이 경우, 저는 AI에게 절차를 설명하게 하고, 그 부분만 제가 직접 조작합니다.

AI
↓
실행 불가능한 부분을 특정한다
...

인간이 항상 중심에서 AI를 보조적으로 사용하는 것이 아니라, 인간을 폴백(fallback)으로 남겨두는 이미지입니다.

이 스타일을 지속하기 위해서는 '귀찮으니까 내가 하고 싶지 않다'라는 감각이 의외로 중요하다고 생각합니다.

매번 같은 절차를 실행하는 것, 긴 로그를 추적하는 것, PR 설명을 작성하는 것, 비슷한 테스트를 추가하는 등의 작업을 '내가 하는 편이 빠르다'고 끝내버리면, 그 일은 계속 인간 측에 남게 됩니다.

반면에,

이를 다음부터 AI에게 맡길 수 없을까

라고 생각하게 되면, 자동화나 Skill화의 대상이 됩니다.

귀찮다고 느끼는 것은 단순한 태만이 아니라, 인간이 반복할 필요가 없는 일을 발견하는 계기가 됩니다.

AI에게 모든 것을 맡긴다고 해서 같은 곳에서 여러 번 실패하는 것은 아닙니다.

그래서 저는 AI가 막힌 이유나 새롭게 얻은 지식을 가능한 한 Skill이나 규칙으로 되돌리려고 노력합니다.

예를 들면 다음과 같은 정보입니다.

• 이 리포지토리에 고유한 개발 절차
• 자주 틀리는 판단
• 실행 전에 확인해야 할 사항
• 테스트의 우선순위
• 브라우저 조작 절차
• 툴의 제약
• 리뷰 시 살펴봐야 할 관점

흐름은 다음과 같습니다.

AI에게 맡긴다
↓
실패한다
...

단발성 프롬프트를 개선하기보다는, AI가 일할 수 있는 환경 자체를 지속적으로 개선하는 생각입니다.

더 나아가면, 개발 환경 그 자체를 AI가 다루기 쉬운 형태로 만들고 싶다고 생각합니다.

예를 들어, GUI로만 가능한 작업을 CLI나 API에서 실행 가능하게 하거나, 테스트 결과를 기계 판정이 쉽도록 하거나, 리포지토리에 고유한 지식을 Skill로 옮기는 것입니다.

인간을 위한 절차
↓
AI가 이용할 수 있는 CLI・API・테스트・Skill로 변환
...

다만 회사의 개발 환경에서는 제 판단만으로 권한이나 툴 구성을 바꿀 수 없습니다. 따라서 현 상황에서는 AI가 실행할 수 없는 부분만 인간이 보조하는 운영 방식입니다.

이 생각은 'AI 지원 개발(AI-assisted development)'보다 'AI 기본값 개발(AI-default development)'이라고 부르는 것이 더 가깝다고 생각합니다.

AI-assisted 방식에서는 인간이 주된 작업자이고 AI가 보조 역할을 합니다.

인간 = 실행 주체
AI = 보조

반면, AI-default 방식은 그 반대입니다.

AI = 실행 주체
인간 = 목적 제시・예외 처리・최종 판단

'인간만이 할 수 있는 일이 무엇인가'를 먼저 찾는 것이 아니라, '이 작업도 AI가 수행하게 하려면 무엇이 필요한가'를 생각합니다.

그 결과로 정말 인간이 필요한 부분만 남게 됩니다.

AI에게 맡기는 범위를 넓힐수록, 그 결과를 어떻게 확인하는지가 중요해집니다.

구현을 대량으로 맡기더라도, 올바른지 여부를 매번 인간이 전부 다시 읽어봐야 한다면 자동화할 수 있는 범위에는 한계가 있습니다.

따라서 다음과 같은 기계적인 평가 수단을 늘려야 합니다.

• 단위 테스트 (Unit Test)
• E2E 테스트 (End-to-End Test)
• lint
• 타입 체크 (Type Check)
• CI (Continuous Integration)
• 차이점 확인 (Diff check)
• 기존 사양과의 비교
• 변경해서는 안 되는 범위의 규칙

AI에게 자유를 준다는 것과 무조건 신뢰한다는 것은 별개입니다.

맡기는 범위를 넓히기 위해서는 실패를 감지할 수 있는 메커니즘도 동시에 강력하게 해야 합니다.

이 스타일에는 AI의 성능과는 다른 문제가 있습니다.

회사에서는 충분한 사용 할당량(quota)이 있다면, 요구사항 이해부터 구현, 테스트, PR 작성까지 긴 태스크를 여러 번 시도할 수 있습니다. 하지만 개인 이용에서는 월 20달러 전후의 일반적인 플랜으로 같은 사용 방식을 재현하기 어려울 때가 있습니다.

무엇이든 AI에게 맡기는 스타일에서는 다음과 같은 부분에서 사용량이 늘어납니다.

• 큰 리포지토리를 여러 번 읽기
• 구현과 테스트를 반복하기
• 실패했을 경우 다른 방법을 탐색하기
• Skill 자체를 개선하기
• 긴 태스크를 끝까지 실행시키기

따라서 향후 AI 개발에서는 모델 성능뿐만 아니라, '개인이 현실적인 가격으로 충분한 시도 횟수를 확보할 수 있는가' 또한 중요해진다고 느낍니다.

AI가 똑똑하더라도, 사용량을 신경 써서 도중에 인간이 작업을 인계받는다면, AI-default 방식이 되기 어렵기 때문입니다.

자신의 AI 활용 방침은 다음 한 문장에 요약될 수 있습니다.

먼저 AI에게 맡긴다. 안 되면, 어떻게 하면 AI가 할 수 있게 될지까지 AI에게 생각하게 한다. 그래도 무리한 부분만 인간이 한다.

그리고 거기서 얻은 실패나 지견을 Skill, 규칙, 테스트로 되돌린다.

이 사이클을 반복함으로써, 인간이 담당하는 작업을 조금씩 예외(exception) 쪽으로 밀어냅니다.

AI 시대의 개발에서는 '무엇이 인간만이 할 수 있는가'를 지키는 것보다, '어떻게 하면 다음에는 AI만으로 완수할 수 있을까'를 생각하는 것이 더 중요해지는 장면이 늘어날 것이라고 생각합니다.