AI가 만든 코드베이스는 왜 무너지기 쉬운가

AI를 코드와 개발에 활용하는 것을 엔지니어링 관점에서 바라보는 것은 좌절스러운 일이 될 것 같습니다. 저는 20년 이상 소프트웨어 엔지니어로 일해왔고, 제 코드에 AI를 100% 활용하는 쪽으로 전환했습니다. 요즘 시대에 관련성을 유지하고 사업을 운영하는 거의 유일한 방법이라고 생각합니다. 누구든 저에게 반대해 주시면 좋겠습니다. 제 인생에서 처음으로 제가 옳지 않기를 바라니까요.

그렇긴 하지만, 제 경험상 엔터프라이즈와 비즈니스 코딩은 안정적이거나 견고한 코드베이스에 관한 경우가 거의 없었습니다. 우리 엔지니어들과 소수의 유능한 엔지니어링 매니저, 그리고 극소수의 디렉터들이 코드 품질이 우선이 되도록 비즈니스 이익에 맞서 싸웠지만, 항상 힘든 싸움이었고 품질과 설계에 너무 많은 시간을 쓴다는 이유로 징계를 받는 경우도 많았습니다.

정해진 주기의 릴리스는 품질 좋은 코드와는 상극입니다. 왜냐하면 시간 제한을 둘 수 없기 때문이죠.

그래서 AI는 그 연장선일 뿐입니다. 제 에이전트가 제가 생각하기에 좋은 코드를 설계하도록 노력할까요? 네, 당연히 그렇습니다! 하지만 저는 그것을 완전히 외주화했고, 에이전트가 스스로의 실수를 고칠 능력도 충분히 갖추고 있다고 생각합니다. 저는 AI의 도움으로 개인적으로나 팀으로서도 할 수 있었던 것 이상으로 훨씬 더 나아갔기 때문에, 이제는 실제 코드 라인보다는 관리와 아키텍처에 제 경험과 기술을 적용해야 한다고 믿습니다.

시간이 지나야 어떻게 될지 알 수 있을 겁니다.

Wallaahu aʿlam.

코드 품질은 문제가 아닙니다..... 문제가 될 때까지는요. 모든 사람은 일이 잘 되고 빠르게 진행되는 것처럼 보이면 행복해할 것입니다. 기존 기능을 깨뜨리지 않고는 변경할 수 없거나, 복잡한 코드베이스를 읽는 데 소모되는 토큰이 증가하는 증상을 보기 시작할 때에야 비로소 코드 품질에 관심을 갖게 될 겁니다 (지금은 사람들이 그냥 AI가 스스로의 엉망진창을 고치도록 할 것 같지만요).

이 규칙들은 너무나 사실이라서 뻔하게 들립니다. 이제 리더십에 맞서 이 규칙들을 알려야 할 때입니다.

"AI가 생성한다..."라는 기사들이 시간이 지나도 좋은 평가를 받을지 확실하지 않습니다.

제가 즉시 궁금해하는 점은 저자가 유지보수성의 차원(DRY 위반, 순환 복잡도, 불분명한 명명, 잘못 설계된 흐름 등)을 포착하기 위해 어떤 종류의 적대적 리뷰와 결정론적 게이트를 작성했느냐입니다.

오해하지 마세요. 제가 하루에 200개의 PR을 빠르게 처리하던 시절(개인 프로젝트였고, 다른 사람들에게 피해를 주지는 않았습니다)에 저는 꽤 빨리 큰 진흙 덩어리를 대충 만들었습니다. 하지만 지금 제 자산을 재생성하면서 (a) 모델은 조금 더 나아졌고 (b) 검증(정확성, 성능, 보안, 운영 비용 및 유지보수성)에 훨씬 더 많은 엄격함을 더하고 있습니다. 쉬운 문제는 아니지만, 제게는 투기적인 로켓 과학이 아니라 엔지니어링 노력처럼 느껴집니다.

많은 AI 생성 코드베이스가 실제로 더 많은 사고와 낮은 유지보수성으로 고통받는다는 점을 충분히 이해합니다. 하지만 무엇이 흔한지와 무엇이 가능한지를 구분하는 것이 중요하다고 생각합니다. 하나에 대한 해결책은 검증의 엄격함을 개선하는 것이고, 다른 하나에 대한 해결책은 형편없는 코드를 받아들이거나 LLM을 포기하는 것이기 때문입니다.

여기서는 순전히 추측이지만, 문득 떠오른 생각이 있습니다. 자동화된 프로세스가 장인을 얼마나 빨리 대체할 수 있는지에 대한 비유로 가구가 자주 사용되는 것을 봤습니다. 하지만 제 생각에는 어떤 의미에서 자동화 이후에도 장인 정신이 어떻게 계속 살아남고 번성할 수 있는지에 대한 비유일 수도 있습니다. 물론 이케아는 이선 앨런보다 훨씬 더 많은 가구를 판매하지만, 이선 앨런의 수제 가구는 품질이 훨씬 높고 프리미엄 가격에 판매됩니다.

소비자는 모든 면에서 이익을 얻습니다. 여유가 있는 사람은 고품질 수제 제품을 살 수 있고, 대다수는 저렴하게 수용 가능한 품질의 가구를 얻을 수 있습니다.

순전히 추측이지만, AI의 등장으로 소프트웨어도 이런 식으로 점진적으로 진화할지 궁금합니다. 많은 기본 작업의 경우 소비자는 AI 도구를 사용해 기본적으로 자신만의 소프트웨어를 작성할 수 있게 될 것입니다. 품질이 높지 않을 수는 있지만 적어도 저렴하고 빠르게 생산할 수 있으며, 일반 컴퓨터 사용자가 자신의 컴퓨터에서 원하는 작업을 수행할 수 있는 진입 장벽을 크게 낮출 것입니다. 한편, 성능이나 품질 경험이 중요한 특별한 요구를 충족하기 위해 적어도 부분적으로 전문가가 수제로 만든 고품질 도구를 위한 훨씬 작은 틈새 시장은 계속 번성할 것입니다. 어느 쪽이든 이 시나리오에서는 SaaS의 중요성과 위상이 서서히 줄어들 것이라고 생각합니다.

이제는 이것이 중요하지 않다고 생각합니다. 소프트웨어는 블랙박스가 되어가고 있으며, 에이전트가 작동하게 만듭니다. 원하는 작업에 대한 합리적인 사양과 약간의 감독 및 지시만 제공할 수 있다면 말이죠.

현재 에이전트는 좋은 소프트웨어 엔지니어링 원칙을 따르는 데 능숙하지 않습니다. 장황한 코드, 많은 중복, 추상화 누수, 쓸모없는 단위 테스트 등으로 일을 처리합니다.

그게 문제일까요? 장기적으로는 문제가 될 것이고, AI가 도입한 복잡성을 감당하지 못할 것이라고 생각할 수도 있습니다. 하지만 저는 별로 걱정하지 않습니다. 대부분의 소프트웨어는 그렇게 크지 않고, 에이전트는 나날이 발전하고 있습니다. 그리고 설계를 정말로 중요하게 생각한다면 에이전트에게 당신의 기준을 따르도록 지시하는 것은 그리 어렵지 않습니다.

그렇지 않았으면 좋겠고, 제 경험과 전문성을 몇 년 더 정당화할 수 있기를 바라지만, 사실은 사실입니다.

이 시점에서 이런 종류의 일반화는 매우 짜증나게 느껴집니다.

기사에 반대하지는 않지만, 일부 독자에게는 AI 이전의 손으로 작성한 코드가 취약하지 않았다는 인상을 줄 수 있습니다.

다음은 2,500만 줄의 Oracle RDBMS 코드베이스에 대한 유명한 논평입니다: https://news.ycombinator.com/item?id=18442941

수백만 줄의 모든 대기업 코드베이스는 비슷한 상태로 전락합니다. 작은 코드베이스는 깨끗한 개념적 일관성으로 시작합니다. 그런 다음 더 많은 사람이 투입되면서 필연적으로 이해할 수 없는 스파게티 코드로 쇠퇴합니다. 여러 이유가 있습니다. 나중에 합류한 개발자들이 초기 개발팀보다 코드에 덜 신경 쓰는 것, 마감 기한, 무언가를 깨뜨릴까 봐 리팩토링을 피하는 것 등입니다.

AI가 취약한 코드를 만들지 않도록 하려면, AI 이전의 손으로 작성한 코드에 적용했을 동일한 품질 게이트를 적용해 모든 것을 깨끗하게 유지해야 합니다. 대부분의 회사는 그렇게 하지 않습니다.

AI가 줄이는 것 중 하나는 호기심 많은 엔지니어들이 코드베이스를 어슬렁거리며 살펴보는 것입니다. 이는 죽은 코드, 차선의 구조 등을 찾는 좋은 방법입니다. AI를 사용하면 그 모든 것이 사라집니다.