AI 지원 소프트웨어 엔지니어링을 위한 바벨탑의 은유

AI 지원 소프트웨어 엔지니어링을 위한 바벨탑의 은유

AI 에이전트는 공유된 아키텍처 이해를 붕괴시킬 위험이 있다

AI 지원 프로그래밍은 개별 개발자가 코드베이스를 수정하는 속도를 극적으로 높여주지만, 팀이 대규모 소프트웨어 프로젝트에서 협업할 수 있게 해주는 공유된 개념적 이해, 즉 "공유 언어"를 위협합니다. 에이전트는 기능적인 코드를 생성하고 테스트를 통과할 수 있지만, 역사적으로 팀의 시스템에 대한 정신적 모델을 동기화해 왔던 필수적인 마찰(코드 리뷰 및 기술적 논의 등)을 제거합니다.

소프트웨어 프로젝트의 "공유 언어"

대규모 엔지니어링에서 주요 제약 사항은 코드 생산 속도가 아니라, 사람들이 시스템에 대한 이해를 조정하는 능력입니다. 이 공유 언어는 Python이나 English와 같은 프로그래밍 언어나 구어체가 아닙니다. 그보다는 다음과 같은 사항에 대한 집단적 이해를 의미합니다:

  • 개념적 의미: 특정 용어와 추상화가 도메인 내에서 실제로 무엇을을 나타내는지.
  • 시스템 경계: 하나의 모듈이 끝나고 다른 모듈이 시작되는 지점.
  • 불변성(Invariants): 시스템이 안정적으로 유지되기 위해 항상 참이어야 하는 규칙.
  • 소유권 및 의도: 특정 컴포넌트에 대한 책임이 누구에게 있으며, 왜 시스템이 현재의 형태로 설계되었는지.

이러한 이해는 일반적으로 "생산적인 마찰"을 통해 형성됩니다. 즉, 타인의 코드를 읽고, 명확한 질문을 던지고, 코드 리뷰 과정에서 변경 사항을 옹호하는 과정입니다. 이 마찰은 개발자의 정신적 모델이 팀의 나머지 구성원들과 일치하도록 보장합니다.

"Vibecoding"과 에이전트적 마찰의 역설

AI 에이전트는 인간의 동기화를 강제하는 마찰을 제거합니다. 이제 개발자는 영향을 받는 모듈의 소유자들과 변경 사항을 논의할 필요 없이 에이전트에게 기능을 구현하도록 요청할 수 있습니다(예: OAuth 또는 caching 추가). 에이전트는 그럴듯한 설명을 생성할 수 있고 코드가 컴파일되고 테스트를를 통과할 수 있기 때문에, 인간 개발자가 시스템의 해당 부분에 대한 공유된 정신적 모델을 획득하지 못한 채 변경 사항이 병합됩니다.

이는 공유된 아키텍처 언어가 붕괴되는 와중에도 건설이 계속되는, 즉 "탑이 계속 높아지는" 상태로 이어집니다. 시스템은 국소적으로는 타당해 보이지만 전역적으로는 일관성이 없는 변경 사항들의 집합체가 됩니다.

"일관성 없는 탑"에 대한 관점

커뮤니티 논의에서는 소프트웨어 생산 방식의 이러한 변화와 관련된 몇 가지 위험과 잠재적 완화 방안을 강조합니다:

  • 지혜의 상실: 일부는 AI가 "지혜가 없는 지능"을 가졌다고 주장합니다. 이는 AI가 해당 솔루션이 프로젝트의 장기적인 건강에 적합한지 이해하지 못한 채 국소적인 기술적 문제를 해결할 수 있음을 의미합니다.

  • "Lisp Curse"와의 유사성: 특정 언어가 개인화된 도구를 구축하기 너무 쉽게 만들어 개발자들이 범용적이고 표준화된 결과물에 협업할 인센티브를 잃게 만드는 "Lisp Curse"와 유사한 상황입니다.

  • 검토되지 않은 코드의 공포: 개발자들은 "vibecoding"(깊은 검토 없이 느낌이나 프롬프트에 의존하여 코딩하는 것)이 종종 "horror

Sources