AI가 생성한 코드의 책임 소재는 누구에게 있는가? '느낌으로 코딩하기'의 소유권 문제

AI가 작성하고 검토하여 배포된 코드에 버그가 발생하면 어떻게 될까요? 이런 경우 누가 책임을 져야 할까요? 프롬프트를 작성한 개발자일까요? 아니면 풀 리퀘스트(pull request)를 승인한 사람일까요? 아니면 팀 전체일까요? 왜 이러한 질문들에 답할 필요가 있을까요, 아니면 이미 답을 알고 있는 걸까요?

이것들이 별로 인기 있는 질문은 아닐 것이고, 마치 남 탓하는 것처럼 보일 수도 있다는 것을 압니다. 하지만 AI가 배포한 코드에 대한 소유권 의식이 최소한 있어야 합니다. 많은 개발자들이 이것을 실제 문제로 인식하고 있으며, 이는 다루어져야 할 문제입니다. 여기서는 왜 이런 일이 발생하는지 조사하고, 어떻게 개선할 수 있을지에 대한 저의 생각을 전하고자 합니다.

품질 대 양(Quality vs Quantity)

우리가 실제로 더 나은 코드를 생산하는 것일까요, 아니면 단순히 더 많은 코드를 생산하는 것일까요? 양(Quantity)은 측정하기 쉽지만, 품질(Quality)은 그렇지 않습니다. Cursor와 같은 도구들은 AI 에이전트가 생성하고 커밋한 코드 라인 수를 지표 중 하나로 제공하는 대시보드를 제공합니다. 제 생각에 이것은 그다지 현명한 측정 기준이 아닙니다. 특히 코드 라인이 생산성의 척도라고 믿게 만드는 비기술적인 사람들에게 오해를 줄 수 있기 때문입니다.

Quality vs Quantity

AI의 전반적인 움직임은 코딩, 그리고 일부 사람들에게는 엔지니어링 자체를 소프트웨어 생산의 쉬운 단계처럼 보이게 만들었고, 주요 병목 지점은 이제 새로운 기능을 찾는 것과 궁극적으로 제품-시장 적합성(product-market fit)을 찾는 것이라고 생각하게 했습니다. 저는 제 이전 기사에서 느낌으로 코딩하기 함정 및 착각에 대해 더 자세히 썼습니다.

우리는 코드가 자산(asset)이 아니라 부채(liability)라는 점을 명심해야 합니다. 코드가 많다고 해서 기능이 더 좋다는 의미는 아닙니다. 오히려 정반대일 수 있으며, 더 많은 함정과 애플리케이션 실패의 기회를 의미할 수 있습니다.

코드가 무엇을 하는지 이해하기

코드 생성 자체는 문제가 아니라는 것을 이미 알고 있습니다. 문제는 그것을 이해하고 기존 아키텍처에 적합한지 증명하는 쪽으로 이동합니다. 자신이 한 줄도 작성하지 않았을 때 어떻게 보장할 수 있을까요?

Knowing What the Code Does

단순히 생성된 코드를 빠르게 살펴보고, 테스트를 실행한 뒤 모든 것이 괜찮기를 바라는 것만으로는 충분하지 않습니다. 먼저, 그 코드가 의도한 대로 작동하는지, 아키텍처에 맞는지, 구조화된 방식으로 작성되어 스파게티처럼 보이지 않는지를 이해해야 합니다. 둘째, 테스트에 주의를 기울여야 합니다. 생성된 테스트는 대개 코드가 이미 하는 것만을 테스트할 가능성이 높지만, 테스트는 코드가 하지 않는 것도 테스트해야 합니다. 대부분의 버그가 발생하는 지점인 엣지 케이스(edge cases)입니다. 로직에서 엣지 케이스를 확인하고 그 방향으로 테스트를 강제해야 합니다.

이것이야말로 엔지니어링이 더욱 중요해지는 부분입니다. 왜냐하면 결국 누군가가 시스템을 잘 이해해야 생성된 코드가 거기에 속하는지 아닌지를 판단할 수 있기 때문입니다. 오직 종합적인 코드 리뷰만이 구현을 검증하고, 요구사항과 완전히 일치하는지 확인하도록 도전할 수 있습니다.

시간적 압박감

AI를 둘러싼 과대광고는 마치 코드를 빠르게 생성할 수 있다면, 그것 또한 빠르게 배포되어야 한다는 기대를 만들어냈습니다. 그 결과, 코드 생성 이후의 단계들, 특히 리뷰와 엔지니어링 판단에 압력이 생겼습니다. 우리 모두가 이 과정 중 일부에 할애되는 시간이 한쪽에서 다른 쪽으로 단순히 이동했을 뿐이라는 것을 이해해야 합니다. 물론, 우리가 올바르게 일을 하고 싶다는 점을 염두에 둔다면 말입니다.

Time Pressure

이전에는 코드의 작동 방식과 아키텍처에 적합한지 여부를 이해하는 것이 코드 생성 과정 전반에 걸쳐 지속적인 작업이었습니다. 결국, 코드는 동일한 인간의 출처에서 만들어졌습니다. 코드를 작성하는 사람이 곧 그것을 구축하고 의존성 및 아키텍처 적합성을 이해하는 주체였던 것입니다.

하지만 이제 코드 생성이 AI 쪽으로 이동하면서, 이를 이해해야 할 책임은 여전히 인간에게 남아 있습니다. 인간은 여전히 코드를 읽고, 이해하고, 검증해야 합니다.

이러한 단계를 거치지 않으면 몇 주 또는 몇 달 만에 유지보수가 어렵거나 심지어 불가능한 애플리케이션을 향해 지름길을 택하게 됩니다. 적절한 평가 없이는 모든 것이 괜찮다고, 그리고 AI가 올바르게 처리했다고 착각하기 쉽고, 결국 이 문제가 터질 때까지는 그럴 수 있습니다. 그리고 그때는 이미 너무 늦을 수도 있습니다. 제가 AI 이전에도 코드에 버그가 없었다고 말하는 것은 아닙니다. 이것이 요점이 아닙니다. 하지만 적어도 코드가 무엇을 하는지에 대한 어느 정도의 이해도는 있었습니다. 현재 저는 그러한 것을 점점 더 보기 어렵게 느끼고 있습니다.

(안) 지름길 택하기

쉽게 잊기 쉬운 한 가지 측면은 구현 후 코드 수정입니다. 제가 말하는 것은 AI가

(Not) Taking Shortcuts

불필요한 작업을 제거하는 것과 수행해야 할 중요한 작업을 건너뛰는 것 사이에는 큰 차이가 있습니다. AI는 전자에 매우 능하지만, 수정이 필요하지 않거나 빠르게 처리할 수 있다는 착각을 만들어내면서 후자 역시 매우 유혹적으로 만들 수 있습니다.

나쁜 코드와 유지보수의 비용 (Cost of Bad Code & Maintenance)

최악의 코드는 대개 작동하지 않는 코드를 의미하지 않습니다. 그것은 오늘날 작동하지만 내일 비싸지는 코드를 말합니다. 초생산성(super-productivity)에 관한 모든 동화 같은 이야기는 단 하나의 보안 문제, 하나의 교착 상태(deadlock), 하나의 경쟁 조건(race condition), 하나의 데이터 유출로 인해 망가질 수 있습니다. 완벽해 보였던 것들이 악몽이 될 수 있습니다. 그 지점에서는 개발 속도가 아무리 빨랐든 상관없습니다. 잘못되었다면 말입니다. 그리고 가장 나쁜 것은 그것을 제때 알아차리지 못했다는 것입니다.

Cost of Bad Code & Maintenance

기술 부채(Technical debt)는 보통 아무도 코드를 충분히 이해하여 리팩토링(refactor)하고 정리하지 못할 때 복리처럼 쌓입니다. 무언가를 망가뜨릴까 봐 두려워하는 마음은 이해도가 낮아질수록 커집니다. 게다가 코드베이스가 성장함에 따라 미래의 변경과 잠재적 실패를 위한 표면적이 더 넓어진다는 것을 의미합니다. 결과적으로, 문제가 발생했을 때 디버깅(debug)하는 데 더 많은 시간이 필요하기 때문에 잠재적인 유지보수 비용이 증가하고 있습니다.

이 모든 것은 우리에게 하나의 결론으로 이어집니다. AI가 모든 것을 쉽게 만든 것이 아니라, 일부만 쉽게 만들었고 다른 쪽의 부담을 증가시켰다는 것입니다. 이제 우리는 더 많은 코드를 검토해야 하고, 다른 무언가가 수행한 엔지니어링(engineering)을 판단해야 하며, 코드를 승인할 때 더 신중해야 합니다. 만약 우리가 이러한 것들을 무시한다면, 장기적으로 결국 비용이 발생할 것입니다.

책임 소재 (Accountability)

문제가 발생했을 때 누가 책임을 지는가? AI는 코드를 작성하고, 검토하며, 테스트하고, 심지어 아키텍처 변경까지 제안할 수 있지만, 그 결과에 대한 소유권은 갖지 못합니다. 무엇이 병합(merged)되고 배포(shipped)되는지에 대해서는 누군가가 책임을 져야 합니다. “AI가 생성했기 때문에”라는 말은 문제가 생겼을 때 변명이 될 수 없습니다. 비록 그렇게 하기 쉬울지라도, 어떤 일이 발생했다고 해서 AI를 탓할 수는 없습니다. 그것은 논리적으로 맞지 않으며, 결국 상황을 바꾸거나 어떤 영향을 미치지도 못합니다. 왜냐하면 AI는 이런 방식으로 책임을 물을 수 있는 인간이 아니기 때문입니다.

Accountability

책임 소재는 팀 전체에 걸쳐 공유되어야 할 가능성이 높지만, 그렇다고 해서 아무도 책임이 없다는 뜻은 아닙니다. 첫 번째로 책임져야 하는 사람은 AI에게 코드를 생성하도록 지시한 사람이어야 합니다. 이는 결과적으로 같은 사람이 생성된 코드가 무엇을 하는지 완전히 이해해야 함을 의미합니다. 둘째로, 코드 검토(review) 역시 중요합니다. 풀 리퀘스트(pull request)를 승인하는 사람이 단순히 “LGTM (Looks Good To Me)”이라고 하고 모든 것이 괜찮기를 바랄 수는 없습니다. 이 사람은 AI 에이전트가 있기 전보다 더 진지하게 코드 검토에 임해야 합니다. 결국, 코드가 AI 생성 여부와 관계없이 배포되는 모든 것에 대해 팀 전체가 일종의 공유된 책임(shared responsibility)을 지니고 있기 때문입니다.

마지막으로, AI가 코드를 생성했다는 사실이 우리가 그것을 배포한다는 사실을 바꾸지는 않습니다. 그리고 만약 우리가 그것을 배포한다면, 우리는 그것을 이해하고, 검토하며, 그에 대해 책임을 져야 합니다.

모든 사진은 unsplash.com에서 가져왔습니다.