• AI에게 어디까지 맡길 수 있는지, 어디서부터 인간의 리뷰가 필요한지는 태스크(Task)의 종류와 모델의 조합에 따라 달라진다.
• 해결책의 수가 적고, 실패해도 되돌리기 쉬운 작업일수록 맡기기 쉽다. 해결책이 무한하며 제품의 방침이나 향후 유지보수성(Maintainability)에 영향을 미치는 작업일수록, AI와 대화(Wall-hitting)하며 인간이 의사결정을 한다.
• 이 판단은 한 번 규칙화해서 끝나는 것이 아니다. 각 회사의 각 모델을 충분히 활용하여, 자신의 작업에 대한 신뢰감을 피부로 느끼는 감각으로서 갖는 것이 중요하다고 생각한다.

"AI가 어느 정도 할 수 있고, AI가 어느 정도의 리뷰를 필요로 하는가"는 숫자만으로는 측정하기 어려운 것입니다.

같은 지시라도 모델에 따라 출력의 질이나 사고의 깊이는 달라집니다. 또한, 같은 모델이라도 UI의 경미한 수정과 DB 스키마(Schema) 설계에서는 맡길 수 있는 범위가 완전히 다릅니다.

그래서 저는 AI를 사용한다면, 각 회사의 각 모델을 실제 작업에서 충분히 사용해 보며 자신만의 피부로 느끼는 감각을 가지고 있는 것이 중요하다고 생각합니다.

이것은 "이 모델은 항상 옳다"라고 믿는 것이 아닙니다. 상사가 부하 직원에게 업무를 의뢰할 때, "이 정도 수준의 지시라면 어느 정도의 아웃풋(Output)이 돌아올 것인가"를 경험을 통해 판단하는 감각에 가깝습니다. 상대에 대한 신뢰감이나 의사결정의 감각이 어느 정도 동기화되어 있는지를 태스크마다 파악해 나갑니다.

태스크를 보았을 때 제가 가장 먼저 의식하는 것은, 그 과제를 해결하는 방법을 몇 가지 상상할 수 있는가입니다.

예를 들어 "X라는 UI의 색상을 흰색에서 회색으로 변경한다"와 같은 작업입니다. 지시의 의미에 대해 다른 해석을 할 여지가 거의 없습니다.

이러한 변경은 AI에게 상당히 맡기기 쉬운 것입니다. 물론 변경 부분이나 화면을 확인하지만, 제품의 방침을 결정하기 위한 깊은 리뷰까지는 필요하지 않다고 느끼고 있습니다.

여러 가지 실현 방법이 생각되는 경우에는 AI에게 구현을 맡기기 전에 선택지와 트레이드오프(Trade-off)를 확인합니다.

이 단계에서는 AI에게 안을 내게 하는 것 자체가 유효합니다. 다만, 어떤 안을 채택할지는 기존 설계나 향후 확장성과 대조하여 판단합니다.

제품상의 해결책이 무한히 있을 수 있는 경우, 갑자기 구현을 의뢰하지는 않습니다. AI와 대화하며 애초에 무엇을 만들 것인지, 어떤 스코프(Scope)로 해결할 것인지를 결정해 나갑니다.

여기서 AI에게 기대하는 것은 최종 결정을 맡기는 것이 아닙니다. 자신의 생각을 언어화하고, 선택지를 비교하며, 놓치고 있던 논점을 끌어내 주는 것입니다.

제가 개발하고 있는, 온라인에서 보드게임 프로토타입을 작성할 수 있는 서비스 KIBAKO에서 바로 이 판단이 필요했던 적이 있습니다.

KIBAKO에는 보드게임을 만드는 제작 룸과 실제로 플레이하기 위한 플레이 룸이 있습니다. 테스트 플레이 중에 발견된 개선점을 제작 룸으로 원활하게 가져가서, 다음 테스트 플레이를 위한 제작으로 연결하고 싶다. 이것이 이번의 과제였습니다.

어려웠던 것은 "개선 메모"라는 기능을 만드는 것 자체가 아닙니다. 다음과 같은 방침을 결정해야 했다는 점입니다.

• 개선 메모는 어떤 스코프에서 가질 것인가
• 사용자는 어디에서 입력하고 어디에서 열람하는가
• 어떤 권한을 가진 참가자에게 어디까지 보여줘도 되는가
• 여러 플레이 룸을 넘나들 때 메모를 어떻게 다룰 것인가

이러한 과제는 해결책이 무한합니다. 그래서 AI와 몇 번이고 대화하며 제품 운영자로서의 방침을 결정해 나갔습니다.

최종적으로는 여러 플레이 룸과 그 바탕이 되는 제작 룸을 횡단하는 "프로젝트"에 개선 메모를 연결하기로 했습니다. 메모에는 어느 플레이 룸에서 작성되었는지도 기록합니다.

한편, 단일 플레이 룸에만 권한이 있는 참가자에게는 해당 플레이 룸에서 입력된 메모만 열람할 수 있도록 했습니다. 열람만 가능하며, 프로젝트 전체의 메모를 편집할 수 있는 것은 아닙니다.

이것이 유일한 정답이라고는 아직 생각하지 않습니다. 그럼에도 현재의 유스케이스(Use case)와 이후의 확장성을 고려하여 이 사양으로 확정하여 구현했습니다. 이러한 의사결정은 AI에게 통째로 맡기는 것이 아니라, AI와의 대화를 통해 스스로 수행하는 영역이라고 느끼고 있습니다.

해결책의 수와는 별개로 제가 신중해지는 것은 "그 변경은 불가역적인가?"라는 관점입니다.

DB 스키마 변경은 경우에 따라 되돌릴 수 없습니다. 일단 그 스키마로 운용을 시작하면 사용자의 귀중한 데이터가 쌓이기 시작하여, 나중에 크게 변경하는 것이 어려워집니다.

그렇기 때문에 DB 마이그레이션(Migration)에서는 단순히 마이그레이션 파일이 작동하는지만을 보지 않습니다.

• 사용자 데이터가 들어가기 전에 되돌릴 수 있는가
• 사용자 데이터가 들어간 후에, 어떤 데이터 이행 (Data Migration)이 필요하게 되는가
• 실패했을 경우, 어디까지 롤백 (Rollback)할 수 있는가
• 향후 기능 추가나 유지보수 (Maintenance)에 어떤 제약이 남는가

까지 고려합니다. 사용자나 시스템의 향후 방향성, 유지보수성 (Maintainability)에 미치는 영향이 클수록, 리뷰의 필요도는 높아집니다.

저는 태스크(Task)마다 AI 모델을 세세하게 교체하는 것을 잘하지 못합니다. 그래서 평소 작업을 가장 효율적으로 진행할 수 있는, 저렴한 기본 (Default) 모델을 찾아 익숙하게 사용하는 편입니다.

2026년 8월 3일 시점에는, Codex의 $100 Pro 플랜을 사용하며, 평소에는 5.6 Luna High 정도를 기본 모델로 사용하고 있습니다.

반면, 해결책이 여러 개 있는 태스크, DB 스키마 (Schema) 설계 리뷰, 프로덕트나 시스템의 향후 방향성에 큰 영향을 미치는 태스크에서는 처음부터 Terra나 Sol로 올립니다. 노력 (Effort) 또한 태스크에 따라 조정하며, 사양(Specification)이 될 Markdown 파일을 AI와 함께 만들어 나갑니다.

중요한 것은 첫 출력이 미흡했기 때문에 나중에 상위 모델로 교체하는 것이 아닙니다. 해당 태스크가 가진 불확실성이나 영향 범위를 보고, 처음부터 필요한 모델과 노력 (Effort)을 선택하는 것입니다.

AI에게 구현을 맡긴 후, 저는 코드를 처음부터 끝까지 동일한 밀도로 읽지 않습니다. 주로 AI와 구현 방침에 대한 Markdown을 함께 만들고, 그 계획에 대해 궁금한 점을 자세히 설명하게 합니다.

대화 (Wall-hitting) 과정에서, 예를 들어 다음과 같은 질문을 던집니다.

• 왜 이 데이터의 스코프 (Scope)를 이렇게 설정했는가
• 다른 설계로 했을 경우의 트레이드오프 (Trade-off)는 무엇인가
• 권한이 없는 사용자에게 무엇이 보일 가능성이 있는가
• 향후 이 기능을 확장할 때, 어느 부분이 제약이 되는가
• 실패했을 경우, 어느 상태까지 되돌릴 수 있는가

최종적으로는 사양 (Specification) Markdown 전체를 확인합니다. 처음에 해결하고자 했던 과제와 결정된 구현 방침이 일치하는지를 확인합니다.

즉, 리뷰의 대상은 코드만이 아닙니다. AI가 어떤 사고방식으로 그 코드에 도달했는지, 그리고 그 사고방식이 프로덕트의 목적과 부합하는지를 리뷰하고 있는 것입니다.

AI의 능력과 리뷰의 필요도는 모델의 스펙 표만으로는 판단할 수 없습니다.

실제로 자신의 프로덕트, 자신의 코드, 자신의 지시 방식(Prompting)으로 계속 사용해 보면서, 어느 정도의 설명이면 의도를 이해하는지, 어느 정도의 설계라면 안심하고 맡길 수 있는지를 알 필요가 있습니다.

그 체감 감각은 모델마다 다릅니다. 어떤 모델에서는 안심하고 맡길 수 있는 태스크가, 다른 모델에서는 대화 (Wall-hitting)를 더 늘리는 것이 좋을 수도 있습니다. 그렇기에 각 회사의 각 모델을 실제로 충분히 사용해 보며, 자신의 작업에 대한 신뢰감을 갖는 것이 중요합니다.

처음부터 완벽한 판단 기준을 만들 필요는 없습니다. 우선 하나의 모델을 평소에 사용하면서, 해결책의 수, 불가역성 (Irreversibility), 향후에 미치는 영향이라는 관점에서 맡긴 결과와 리뷰를 통해 발견한 것들을 조금씩 익혀 나가면 된다고 생각합니다.

• 해결책이 거의 하나이고, 실패해도 되돌리기 쉬운 작업은 AI에게 맡기기 쉽다.
• 해결책이 여러 개인 경우에는 AI에게 안을 내게 하면서, 인간이 트레이드오프 (Trade-off)를 판단한다.
• 해결책이 무수히 많고 프로덕트의 방침과 관련되는 경우에는, AI와 대화 (Wall-hitting)하며 인간이 의사결정을 한다.
• DB 스키마 변경처럼 불가역성이나 사용자 데이터에 영향이 있는 작업은 깊게 리뷰한다.
• 평소 사용하는 모델을 충분히 활용하며, 모델마다 '어느 정도 맡길 수 있는지'에 대한 체감 감각을 갖는다.

AI에게 어디까지 맡길 수 있는지는 누군가가 정한 고정된 규칙이 아닙니다. 자신의 업무에서 AI를 계속 사용해 나가면서 조금씩 다듬어가는 판단력이라고 생각합니다.