왜 이해하지 못하는 코드를 '관리'할 수 없는가

Source: Dev.to

Context

AI 시대에 흔히 묻는 질문이 있습니다: “AI가 코드를 작성한다면 개발자는 그냥 프로덕트 매니저가 되는 건가?”

답은 아니오이며, 그 이유는 맥락 권한 원칙에 있습니다.

• 프로덕트 매니저는 주로 문제 영역(사용자 요구, 시장 적합성, 가치)를 담당합니다.
• 엔지니어는 주로 해결 영역(아키텍처, 신뢰성, 유지보수성)를 담당합니다.

PM이 시장을 이해하지 못하면 잘못된 제품을 만들게 되고, 엔지니어가 시스템을 이해하지 못하면 취약한 제품을 만들게 됩니다.

“How”에 위험이 있다

개발자가 소유권을 유지하지 않은 채 AI에 작업을 위임하면, 해결 영역을 외주화하려는 것이 됩니다. 이야기는 이렇게 변합니다: “AI가 ‘how’를 처리하고, 나는 ‘what’만 담당한다.” 하지만 how에는 외주화할 수 없는 기술적 위험이 내포되어 있습니다.

• how는 데이터베이스가 부하가 걸렸을 때 잠기는지를 결정합니다.
• how는 보안 모델이 유효한지를 결정합니다.
• how는 다음 달에 시스템을 확장할 수 있는지를 결정합니다.

엔지니어링 팀이 how를 AI에 위임하고 깊은 이해를 유지하지 않으면, 코드베이스는 부채가 됩니다. 팀이 PM이 되는 것이 아니라, 이해할 수 없는 기술 부채의 관리자가 되는 겁니다.

계약자 함정

코드를 이해하지 못해서 (또는 복잡성을 다루고 싶지 않아서) AI에 작업을 위임한다면, 당신은 계약자 역할을 하는 것입니다. AI를 복잡성에 대한 방패로 사용하는 것이죠. AI는 즉각적인 티켓을 닫는 “블랙 박스” 패치를 만들어 주지만, 그 패치가 시스템 전체에 어떤 영향을 미칠지는 예측할 수 없습니다.

이러한 행동을 반복하면 소프트웨어에 대한 정신 모델이 점점 약화됩니다. 당신은 무엇을 원하는지는 설명할 수 있지만, 왜 동작하는지 혹은 언제 실패할지를 신뢰성 있게 설명할 수 없는 “코드의 프로덕트 매니저”가 됩니다.

실제 프로덕트 매니저가 엔지니어링 팀에 구조적 완전성을 맡기는 것과 달리, 당신은 강력한 피드백 루프가 없는 모델에 의존하게 되며, 그 모델은 시스템 보장을 위한 것이 아니라 그저 그럴듯한 출력을 최적화합니다.

에이전시의 설계자

규모를 확장하기 위한 최선의 전략은 블랙 박스의 관리자가 되는 것이 아니라 에이전시의 설계자가 되는 것입니다. AI를 실행에 활용하되, 그 결과물을 당신의 정신 모델에 맞춰 철저히 감사하십시오. 구문 생성이라는 저레버 작업을 시스템 검증이라는 고레버 작업으로 교환하십시오.

이를 위해서는 소유권 보존 위임이 필요합니다. “신뢰해 주세요”라는 출력을 요구하지 마세요. 감사 로그를 요구하십시오: 행동을 고정하는 테스트, 명확한 불변 조건, 트레이드‑오프에 대한 메모, 그리고 변경을 수용하기 전에 논리적으로 검토할 수 있는 내러티브 차이점 등.

위임한다고 해서 소유권을 잃는 것이 아니라, 바라보는 것을 멈춤으로써 소유권을 잃게 됩니다.