번역글: 빌드냐 바이냐, 비용만의 문제가 아니다

이 글은 Claude Fable 5.1 을 이용해 번역되었으며, 이후 퇴고를 거쳤습니다.

원문: Dave Thomas, Pragmatic Programmers Newsletter — “The Build or Buy Decision Isn’t Just About Cost”

AI 는 ‘만들 것인가, 살 것인가’ 라는 해묵은 질문의 지형을 어떻게 바꿀까요? AI 가 주는 힘에 푹 빠진 개발자들을 저는 자주 만납니다. “생각만 하면 Claude 가 써 주는데, 이제 와서 뭘 사거나 가져다 쓸 이유가 있나요?”

어쩌면 그렇게 단순하지 않을지도 모릅니다.

(옮긴이 주: 원문에는 Google Gemini 가 만든 삽화가 한 장 실려 있는데, 이 번역에서는 생략했습니다. 그림은 이렇습니다. 「스타 트렉: 넥스트 제너레이션」 의 피카드 선장이 엔터프라이즈호의 리플리케이터 앞에 서서 늘 하던 대로 “Earl Grey, Hot!” 을 외칩니다. 리플리케이터는 말만 하면 음식이든 물건이든 그 자리에서 만들어 내는 장치입니다. 그 옆에서 실크해트에 지팡이를 든 빅토리아 시대 상인풍의 신사가 식은땀을 흘리며 당황한 얼굴로 그 장면을 보고 있습니다. 본문에 비추어 읽으면, 리플리케이터는 “생각만 하면 Claude 가 써 준다” 는 AI 이고, 차를 사다 팔거나 물건을 만들어 팔던 신사는 몇 년에 걸쳐 솔루션을 다듬어 온 제3자, 즉 ‘사 오는’ 쪽의 공급자입니다. 원하는 것이 즉석에서 나오는 세상에서 자기 장사가 필요 없어지는 게 아닌가 하는 공급자의 불안을 익살스럽게 그린 셈인데, 글의 요지는 그 불안이 꼭 맞는 것은 아니라는 쪽입니다. 리플리케이터가 찍어 낸 홍차가 늘 제대로 나올지는 알 수 없고, 수십 년 동안 차를 다뤄 온 상인은 어떤 찻잎이 어떤 물에서 쓴맛을 내는지까지 알고 있으니까요. 이 해석은 옮긴이의 것이며 원문에는 그림에 대한 설명이 없습니다.)

첫째, 어떤 제3자가 몇 년에 걸쳐 솔루션을 만들어 왔다면, 그들과 그들의 고객들은 수많은 어두운 구석과 특수한 경우를 이미 맞닥뜨렸을 가능성이 큽니다. 실제 사용자들에게 소프트웨어를 실전 검증받아야만 배울 수 있는 종류의 것들이지요. 직접 만든 버전에는 ‘천 번의 칼질로 죽는’ 일¹이 고스란히 기다리고 있습니다.

둘째, 이제 그 새 소프트웨어 전부를 유지보수할 책임이 여러분에게 있습니다. 핵심 업무 코드에 쓰는 편이 더 나았을 기술 부채를 떠안은 셈입니다.

셋째, 앞의 둘과 이어지는 이야기인데, 여러분은 프로세스에 의심 을 들여왔습니다. 이것은 AI 를 쓰면서 더 커지는 문제입니다. 직접 만든 무언가가 동작하지 않을 때, 마음 한구석에서는 Claude 가 밤새 돌면서 만들어 낸 10만 줄의 코드 어딘가에 지금 이 문제를 일으키는 버그가 있는 건 아닌지 궁금해하게 됩니다. 물론 서드파티 코드에서도 같은 일이 벌어질 수 있지만, 여러분이 그 문제를 처음 맞닥뜨리는 사람일 확률은 훨씬 낮습니다. (그리고 물론 직접 쓴 코드에서도 같은 일이 벌어질 수 있지만, 그때는 어느 어두운 구석을 들춰 봐야 할지 훨씬 잘 알고 있습니다.)

넷째, AI 의 지원에 관한 한 여러분은 황무지에 남겨질 가능성이 꽤 큽니다. 기존의 프레임워크·라이브러리·제품은 모두 잘 알려진 것들입니다. AI 는 그것들을 쓰는 방대한 코드와 그것들을 다룬 글에서 끌어올 수 있습니다. 여러분이 만들어 낸 코드는요? 그렇지 않습니다. 물론 AI 가 소스를 읽을 수는 있지만, 기존 솔루션에 딸려 오는 관용구와 우회책과 예제는 거기에 없습니다.

기성복보다 맞춤복을 고르고 싶은 유혹은 늘 있습니다. 하지만 그 결정의 전체 비용을 긴 안목으로 따져 보십시오. AI 가 그 결정을 더 분명하게 만들어 주지는 않습니다.

여러분이 제공하는 가치를 만들어 내는 코드를 쓰십시오. 나머지는 가져다 쓰십시오.