【AI 주도 개발 1】 맡길 수 있는 구조를 만들기 — 엔지니어의 업무 재정의 - Insights | Molayo

흔한 반응: "AI에게 맡기는 건 이 부분이 불안해" → 그래서 직접 한다.

불안함을 느꼈을 때, 자신이 대신 하는 것으로는 해소되지 않습니다.

"어떻게 하면 AI에게 맡겨도 그 불안이 생기지 않을까"를 고민하여, 구조(仕組み)를 만듭니다.

"불안"이라고 한마디로 끝내지 않고, 무엇이 불안한지를 구체적(specific)으로 언어화하면 각각에 효과적인 구조가 보입니다.

흔한 불안	이를 해소하는 구조
보안 측면이 걱정됨 (취약한 코드를 작성할 것 같음, 비밀 정보를 다룰 것 같음)	비밀 정보·인증·운영 설정은 자동으로 차단되는 에스컬레이션(Escalation) 기준을 결정한다(10). 리뷰에 보안 관점을 고정적으로 포함한다(9·4)
자신이 이 프레임워크/언어에 익숙하지 않음 (나온 코드의 좋고 나쁨을 스스로 판단할 수 없음)	코드의 외형이 아니라 동작으로 검증한다: 수락 조건(7)과 테스트(5)를 통해 "충족하면 성공"임을 기계적으로 확인한다. 코드 품질 판단은 별도의 AI 리뷰에 맡긴다(9). 애초에 기술적 숙련도 면에서는 AI가 우위에 있다(10)
AI에게 이 프로젝트의 도메인 지식(Domain Knowledge)이 없음 (업무를 모르고 엉뚱한 것을 만들 것 같음)	업무 지식·용어·과거 경위를 지도(Map) 형태로 작성하여 전달한다(3). 다 적을 수 없는 사양 판단은 에스컬레이션을 통해 인간에게 오도록 한다(10)
리뷰가 누락될 것 같음 (자신이 전부 다 확인할 수 없음)	인간의 검토 전에 다중 리뷰를 배치한다(9)
요청하지 않은 것까지 해버릴 것 같음	수락 조건과 스코프 외(Out of Scope)를 사전에 명문화시킨다(7)
멋대로 중요한 판단을 내릴 것 같음	에스컬레이션 기준을 결정한다(10)

불안 하나하나는 구조로 없앨 수 있습니다. 없앤 구조는 팀의 자산이 됩니다.

자신이 대신 수행한 작업은 그 자리에서 사라집니다.

눈앞의 업무가 바쁘고 힘들다는 것은 정말 잘 알고 있습니다. 그럼에도 개선을 뒤로 미루면, 언제까지나 속도가 올라가지 않습니다.

개선에는 일시적인 속도 저하가 따릅니다. 하지만 한 번 개선을 거치면 그 이후의 속도가 올라가 금방 회복할 수 있습니다. 이것은 복리입니다. 빨리 시작할수록 리턴의 총량이 커집니다.

게다가 AI 주도 개발의 시대는:

개선 사이클 자체가 빠름 —— 구조 만들기(문서 정비, 스킬 작성, 테스트 추가)도 AI가 해준다 -
스피드업의 폭이 차원이 다름 —— 인력에 의한 개선은 수십 % 수준의 이야기였지만, AI에게 맡길 수 있는 범위가 넓어지는 개선은 배로 효과가 나타난다

"바쁘니까 개선할 수 없다"는 것은 "바쁘니까, 앞으로도 계속 바쁜 상태로 있겠다"와 같은 의미입니다.

모든 실천 사항은 두 가지 축으로 정리되어 있습니다.

어디서부터 읽어도 좋지만, 지금 느끼고 있는 "불안"에 대응하는 기사부터 읽는 것을 추천합니다.

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

Insights