흔히 하는 행동: AI에게 시켜봤다 → 결과물이 별로였다 → "역시 안 되네"라며 직접 수정해서 완료.

AI의 출력이 좋지 않을 때, 직접 수습하지 말고 실패를 지적하여 어떻게 개선할 수 있을지 고민하게 만들어야 합니다.

• 무엇이 잘못되었는지 구체적으로 전달한다 ("틀렸다"가 아니라 "◯◯의 고려가 빠져 있다", "이 안건에서는 △△가 전제다")
• 왜 그렇게 되었는지 생각하게 한다 —— 정보가 부족했는지, 지시가 모호했는지, 참조해야 할 문서가 없었는지
• 원인이 "정보 부족"이라면 정보를 추가한다 (코드의 지도). "매번 같은 실수"라면 절차를 고정한다 (스킬화)

이 루프를 돌리면, 대부분의 일은 잘 풀리게 됩니다. 가능성은 상당히 높습니다.

직접 수습해 버리면, 언제까지나 속도가 올라가지 않기 때문입니다.

수습하는 것은 언뜻 빨라 보입니다. 오늘의 태스크는 빨리 끝납니다. 하지만 내일도 똑같은 곳에서 수습하게 될 것입니다. 1년 후에도 말이죠.

반면, 개선에 임하게 하면 그 실패는 두 번 다시 일어나지 않습니다. 이 차이는 복리로 벌어집니다.

"직접 수습하지 않고, 잘 풀리는 방법을 생각하여 작업자를 개선한다" —— 이는 인간 멤버 육성에서도 유효한, 예전부터 있던 접근 방식입니다. 하고 있는 일 자체가 새로운 것은 아닙니다.

다른 점은 투자 대비 효과 (ROI) 입니다.

개선 속도가 빠르다 —— 인간의 성장은 월·년 단위. AI는 문서나 스킬을 수정하면 그 순간부터 거동이 변한다 -
한 번 배우면 잊지 않는다 —— 인간은 잊어버리고, 이동도 퇴직도 한다. 시스템(仕組み)으로 정착시킨 개선은 사라지지 않는다 -
비용이 훨씬 적다 —— 연수도 OJT의 동행도 필요 없다. 개선을 위한 실제 작업조차 AI에게 시킬 수 있다

즉 "키운다"라는 동일한 투자가, 인간을 상대로 할 때보다 회수가 빠르고, 효과가 크며, 밑천이 작다. 사람을 키우는 가치가 떨어진 것이 아니라, 동일한 육성 스킬을 AI에게 향했을 때의 리턴이 차원이 다르게 크다는 뜻입니다.

그럼에도 잘 되지 않는 일은 있습니다. 그때 생각해야 할 것은 "AI에게는 무리다"가 아니라, "정말로 할 수 없는 것인가"입니다.

• 전제가 되는 정보가 AI가 볼 수 있는 곳에 있는가?
• 절차를 분할한다면? 중간에 확인 포인트를 끼워 넣는다면?
• 실패하고 있는 지점은 전체 중 어디인가? 그 부분만 인간이 판단 포인트로 남기고, 나머지는 맡길 수 없는가?

그 검토에야말로 개선 비용을 투입해야 합니다. 100% 맡길 수 없더라도, 80%를 맡기고 20%만 인간이 보는 형태로 만들 수 있다면, 그것은 큰 전진입니다.

팀 내에서 "이것은 AI에게 무리였다"라는 이야기가 나온다면, 그것은 개선 아이디어의 보물창고입니다. "정말로?"라는 질문으로 대화를 시작해 보세요.

이 기사는 이데아라이브(Idealive) 사내의 "AI 주도 개발의 사고방식" 문서(전 12편)를 시리즈로 공개하고 있는 것입니다.