요약 (TL;DR)

• AI에게 얼마나 위임할 수 있는지, 그리고 얼마나 많은 인간의 검토 (human review)가 필요한지는 작업의 종류와 모델에 따라 달라집니다.
• 가능한 해결책이 적고 되돌리기(rollback)가 쉬운 작업은 위임하기가 더 쉽습니다. 가능한 해결책이 많거나, 제품 정책 (product-policy)에 영향을 미치거나, 장기적인 유지보수 (maintenance)에 영향을 주는 작업은 AI와 함께 인간의 의사결정이 필요합니다.
• 이것은 한 번 정의하고 잊어버릴 수 있는 것이 아닙니다. 다양한 벤더 (vendor)의 모델들을 반복적으로 사용하며, 자신의 작업에서 각 모델을 어느 정도까지 신뢰할 수 있는지에 대한 감각을 익혀야 합니다.

AI의 능력과 검토의 깊이는 직관의 문제입니다

"AI가 얼마나 할 수 있는지"와 "AI에게 얼마나 많은 검토가 필요한지"를 단 하나의 숫자로 측정하는 것은 어렵습니다.

동일한 지시사항이라도 모델에 따라 다른 결과를 낼 수 있습니다. 또한 동일한 모델이라 하더라도, 사소한 UI 변경 작업과 데이터베이스 스키마 (database schema) 설계 작업은 완전히 다른 수준의 검토를 요구합니다.

그렇기 때문에 저는 실제 업무에서 다양한 벤더의 모델들을 사용하며 그들에 대한 자신만의 직관을 쌓아야 한다고 믿습니다.

이것은 모델이 항상 옳다고 믿으라는 뜻이 아닙니다. 이는 매니저가 팀원에게 업무를 위임할 때 갖게 되는 느낌에 더 가깝습니다: "내가 이 사람에게 이 정도 수준의 상세함으로 지시를 내린다면, 어떤 결과물이 돌아올까?" 여러분은 어느 정도의 신뢰가 적절한지, 그리고 자신의 의사결정 스타일이 얼마나 일치하는지를 배우게 됩니다.

해결책의 개수를 추정하는 것부터 시작하세요

작업을 볼 때 제가 가장 먼저 고려하는 것은 해당 문제에 대해 얼마나 많은 해결책을 상상할 수 있는가입니다.

해결책이 거의 하나뿐인 작업

"UI 요소 X의 색상을 흰색에서 회색으로 변경해줘"와 같은 요청을 생각해 보십시오. 이 지시사항이 의미하는 바에는 모호함이 거의 없습니다.

이런 종류의 변경은 AI에게 위임하기 쉽습니다. 저는 여전히 영향을 받는 화면과 차이점 (diff)을 확인하지만, 깊은 제품 수준의 검토를 요구하는 경우는 드뭅니다.

세 가지 또는 네 가지 해결책이 있는 작업

여러 구현 방식 (implementation approaches)이 타당할 때, 저는 구현을 위임하기 전에 AI에게 옵션과 트레이드오프 (trade-offs)를 나열해 달라고 요청합니다.

AI는 그러한 옵션들을 생성하는 데 매우 유용합니다. 하지만 저는 기존 디자인 및 제품의 향후 예상 요구사항과 비교하여 어떤 것을 채택할지 결정합니다.

무수히 많은 해결책이 있는 작업

제품 문제를 해결하는 방법이 셀 수 없이 많을 때, 저는 곧바로 구현으로 뛰어들지 않습니다. 저는 무엇을 만들고 어떤 범위 (scope)를 선택할지 결정하기 위해 AI를 사고 파트너 (thinking partner)로 활용합니다.

여기서 저는 AI에게 최종 결정을 내리라고 요구하는 것이 아닙니다. 제 생각을 명확히 하고, 대안을 비교하며, 제가 놓쳤을지도 모르는 우려 사항들을 드러내는 데 도움을 달라고 요청하는 것입니다.

KIBAKO에서의 피드백 노트 설계

저는 보드게임 프로토타입을 제작하는 온라인 서비스인 KIBAKO를 구축하면서 이러한 종류의 의사결정을 경험했습니다.

KIBAKO에는 보드게임을 만드는 제작실 (production rooms)과 실제로 게임을 플레이하는 플레이룸 (play rooms)이 있습니다. 목표는 플레이테스트 (playtest) 중에 발견된 개선 아이디어를 제작실로 원활하게 다시 가져와 다음 작업 단계에 반영할 수 있도록 하는 것이었습니다.

어려운 점은 '개선 노트 (improvement note)' 기능을 구현하는 것이 아니었습니다. 우리는 다음과 같은 사항들을 결정해야 했습니다:

• 개선 노트의 범위 (scope)는 어디까지여야 하는가?
• 사용자는 어디에서 노트를 입력하고 읽어야 하는가?
• 어떤 참가자가 어떤 노트를 볼 수 있도록 허용해야 하는가?
• 여러 플레이룸이 동일한 프로젝트에 속해 있을 때는 어떻게 동작해야 하는가?

가능한 답변은 무수히 많았습니다. 저는 제품 정책을 결정하는 동안 AI를 사고 파트너로 여러 번 활용했습니다.

최종 디자인은 여러 플레이룸과 이를 생성하는 제작실을 아우르는 프로젝트 전체에 걸쳐 개선 노트를 저장합니다. 각 노트에는 어느 플레이룸에서 생성되었는지가 기록됩니다.

단 하나의 플레이룸에 대해서만 권한을 가진 참가자는 해당 룸에서 생성된 노트만 볼 수 있습니다. 그들은 노트를 볼 수는 있지만, 프로젝트 전체의 노트를 편집할 수는 없습니다.

이것이 유일한 정답인지는 아직 알 수 없습니다. 하지만 현재의 사용 사례(use case)와 미래의 확장성(extensibility)을 고려하여, 우리는 이 설계에 전념하고 이를 구현했습니다. 이것이 바로 제가 AI에게 맡기지 않는 종류의 제품 결정(product decision)입니다. 저는 탐색 공간을 조사하는 데 AI를 사용하고, 결정은 직접 내립니다.

변경 사항을 되돌리기 어려울 때는 리뷰의 깊이를 높이세요

가능한 해결책의 수 외에도, 저는 가역성(reversibility)에 세심한 주의를 기울입니다.

데이터베이스 스키마(Database schema) 변경은 되돌리기가 어렵거나 불가능할 수 있습니다. 사용자가 특정 스키마 하에서 가치 있는 데이터를 입력하기 시작하면, 나중에 이를 변경하는 것은 훨씬 더 어려워집니다.

그러한 이유로, 데이터베이스 마이그레이션(migration)을 검토하는 것은 단순히 마이그레이션 파일이 실행되는지 확인하는 것만이 아닙니다. 저는 또한 다음 사항들을 고려합니다:

• 사용자 데이터가 존재하기 전에 롤백(roll back)할 수 있는가?
• 사용자 데이터가 존재한 후에 어떤 데이터 마이그레이션이 필요할 것인가?
• 문제가 발생했을 때 어디까지 롤백할 수 있는가?
• 이것이 향후 기능 구현 및 유지보수에 어떤 제약 사항을 남기는가?

제품의 미래 방향성이나 유지보수성에 미치는 영향이 클수록, 리뷰는 더 깊이 있게 이루어져야 합니다.

하나의 일상적인 모델을 사용하고 비용 효율성을 최적화하세요

저는 모든 작은 작업마다 모델을 전환하는 것을 특별히 잘하지 못합니다. 그래서 저는 평소 업무에서 최고의 효율을 낼 수 있는 저렴한 기본 모델(default model)을 찾아 이를 광범위하게 사용하려고 노력합니다.

2026년 8월 3일 기준으로, 저는 Codex의 $100 Pro 플랜을 사용하고 있습니다. 저의 기본 모델은 보통 5.6 Luna High 정도입니다.

여러 가지 해결책이 있는 작업, 데이터베이스 스키마 설계 검토, 또는 제품이나 시스템의 미래 방향성에 중대한 영향을 미치는 작업의 경우, 대신 Terra나 Sol로 시작합니다. 또한 적절하게 노력의 정도를 조절하며 AI와 함께 마크다운(Markdown) 명세서를 작성합니다.

중요한 점은, 저렴한 모델로 시작했다가 첫 번째 출력물이 부실하다고 느껴질 때만 모델을 바꾸는 것이 아니라는 점입니다. 저는 먼저 작업의 불확실성과 영향력을 살펴본 다음, 처음부터 모델과 노력의 수준을 선택합니다.

저의 리뷰는 명세 마크다운(specification Markdown)에 집중됩니다

구현을 AI에게 위임한 후에는, 모든 코드 라인을 이전과 같은 강도로 읽지 않습니다. 대신 AI와 함께 마크다운 (Markdown) 형식으로 구현 계획을 작성한 다음, 제가 우려되는 부분에 대해 상세히 설명해 달라고 요청합니다.

대화 과정에서 저는 다음과 같은 질문들을 던집니다:

• 왜 이 데이터가 이러한 스코프 (scope)를 가져야 하나요?
• 다른 설계 방식의 트레이드오프 (trade-offs)는 무엇인가요?
• 관련 권한이 없는 사용자에게 어떤 부분이 노출될 수 있나요?
• 어떤 부분이 향후 확장을 제한할 수 있나요?
• 구현이 실패할 경우 어디까지 롤백 (roll back)할 수 있나요?

마지막으로, 전체 명세 마크다운 (specification Markdown)을 검토합니다. 구현 방향이 우리가 해결하고자 했던 원래의 문제와 여전히 일치하는지 확인합니다.

다시 말해, 저는 코드만을 검토하는 것이 아닙니다. AI가 어떻게 그 코드에 도달했는지, 그리고 그 추론 과정이 여전히 제품의 목적에 부합하는지를 검토합니다.

AI를 광범위하게 사용해 보아야 무엇을 위임할지 알 수 있습니다

모델 명세서 (specification sheets)만으로는 AI에게 정확히 어느 정도의 검토가 필요한지 알 수 없습니다.

자신의 제품, 코드베이스 (codebase), 그리고 지시를 내리는 방식에 맞춰 AI를 계속 사용해 보아야 합니다. 시간이 흐르면서, 당신의 의도를 이해하기 위해 AI가 어느 정도의 설명이 필요한지, 그리고 어느 수준의 설계까지 안전하게 위임할 수 있는지를 배우게 됩니다.

그러한 직관은 모델마다 다릅니다. 한 모델에게 위임하기에 안전하다고 느껴지는 작업이 다른 모델과는 더 많은 논의를 필요로 할 수도 있습니다. 이것이 바로 다양한 벤더 (vendor)의 모델들을 광범위하게 사용하고, 자신의 작업을 바탕으로 신뢰를 쌓는 것이 중요한 이유입니다.

첫날부터 완벽한 평가 기준 (rubric)을 가질 필요는 없습니다. 우선 일상적으로 사용하는 모델 하나로 시작하세요. 가능한 솔루션의 수, 가역성 (reversibility), 그리고 장기적인 영향에 주목하세요. 그런 다음 작업을 위임했을 때 어떤 일이 일어났는지, 그리고 당신의 검토를 통해 무엇을 발견했는지를 기억해 두시기 바랍니다.

결론

• 정답이 거의 하나뿐이고 롤백 (rollback)이 쉬운 작업은 위임하기가 더 쉽습니다.
• 여러 가지 해결책이 존재하는 경우, AI에게 옵션을 요청하고 인간이 트레이드오프 (trade-offs)를 결정하게 하세요.
• 해결 공간 (solution space)이 넓고 제품 정책 (product policy)이 개입되는 경우에는 AI를 사고 파트너 (thinking partner)로 삼아 결정을 내리세요.
• 데이터베이스 스키마 (database schema) 변경이 가역성 (reversibility)이나 사용자 데이터에 영향을 미치는 경우, 이를 깊이 있게 검토하세요.
• 일상적으로 사용하는 모델을 광범위하게 사용하며, 어느 정도까지 위임할 수 있는지에 대한 모델별 감각을 기르세요.

AI에게 얼마나 위임할 수 있는지는 다른 누군가가 당신을 위해 정의해 줄 수 있는 고정된 규칙이 아닙니다. 그것은 당신의 업무에 AI를 지속적으로 사용함으로써 날카롭게 다듬어 나가는 판단의 영역입니다.