작성하기는 쉽지만 신뢰하기는 어려운 기술

최근 친구가 나에게 메시지를 보냈다: IT 분야가 어디로 가고 있다고 생각하니? AI 시대 이후에 새로운 패턴이 있을까?

내 대답은 내 책상에서 진행한 두 가지 최근 업무로 시작했다. 첫 번째는 어느 오후, 내가 에이전트(agent)에게 운동 추적기 데이터와 Fitbit Air의 데이터를 Google Health API를 통해 가져와서, 내가 구축했던 트레이닝 에이전트에 병합하는 작은 UI를 만들도록 요청했을 때였다. 작동하며, 나 없이도 영원히 살아남을 것이다.

두 번째는 비슷한 시기에, 비상 의료 출동 시스템(구급차가 첫 신고부터 병원 문 앞까지 환자 상태를 보고하는 종류)의 오래된 JavaScript 라이브러리 하나를 업데이트하는 데 일주일을 보냈다. 이미 작동하고 있는 시스템이었다. 에이전트가 디버깅(debug)과 라이브러리 교체를 도와주었고, 남은 주간은 읽고, 추적하고, 테스트하며, 무엇이 고장 날지, 그리고 누가 가장 먼저 알아챌지를 물어보는 데 사용했다.

두 경우 모두 같은 도구를 썼지만, 완전히 다른 업무였다.

먼저 여기서 'AI'가 무엇을 의미하는지에 대해 이야기해야 한다. 이 단어가 많은 부정직한 일을 하기 때문이다.

Ed Zitron은 The Diary of a CEO에서 다음과 같은 점을 지적했다: 이 용어는 의도적으로 광범위하게 유지되어, 단백질 접힘(protein folding), 로보틱스, 챗봇 등이 모두 같은 범주에 놓이게 한다. 챗봇을 비판하면 누군가 AI가 암을 치료하고 있다고 상기시킨다. 매달 구독료를 내는 바로 그 챗봇은 아무것도 치료하지 못했지만, 마치 공로를 세운 것처럼 매우 기뻐한다.

따라서 이 글에서 AI란 코드를 작성하고 변경하는 LLM 에이전트를 의미한다. 그 이상도 이하도 아니다.

다시 친구 이야기로 돌아가자. 내 복잡한 답변 중간쯤에 나는 이렇게 타이핑했다: '우리는 '일회성(one-shot)' 제품과 '안정적인(stable)' 제품을 구별할 필요가 있어.' 충분히 간단하지만, IT 분야의 AI를 둘러싼 대부분의 소음, 즉 과장된 기대와 절망감 모두 사람들이 한 종류의 소프트웨어를 묘사하고 다른 종류에 대해 결론을 내리면서 발생한다.

지난 1월에 저는 AI가 전문 지식 기반의 결과물을 저렴하게 만들었다라고 주장했습니다. Steven Bartlett은 같은 팟캐스트에서 더 직설적으로 말했죠. "AI가 할 수 있다면, '위대한' 것은 가치가 없다."

이러한 저렴함은 현실입니다. 다만 두 가지 종류의 소프트웨어에 똑같이 적용되지는 않습니다.

AI는 소프트웨어를 구축하는 비용을 무너뜨렸지만, 유지하는 비용에는 거의 영향을 주지 못했습니다.

두 가지 종류의 소프트웨어

저의 운동 UI는 일회성(one-shot) 소프트웨어입니다. 수명이 짧고 영향 범위가 작죠. 프로토타입이나 목요일에 할 데모, 한 번 실행되는 마이그레이션 스크립트, 분기 동안 누군가가 필요로 하는 내부 도구 모두가 그렇습니다. 아무도 이에 대해 온콜(on call)할 준비를 하지 않습니다. 임무를 마치면 삭제되거나, 레포지토리(repo)에 조용히 썩어가지만 아무도 신경 쓰지 않습니다.

반면에 안정적인(stable) 소프트웨어는 수년 동안 실행되어 돈을 벌고, 사람들을 운송하거나, 그것을 작성한 사람보다 오래 살아남아야 하는 모든 것을 말합니다. 구급차가 어디로 가야 할지를 결정하는 디스패치 시스템(dispatch system)이 하나이고, 은행 코어(bank core), 예약 엔진(booking engine), 항공편 소프트웨어 등이 그렇습니다.

경제학적 구조가 다릅니다. 일회성 소프트웨어의 경우, 코드를 작성하는 것이 대부분의 비용을 차지하므로, 이 작성을 저렴하게 만드는 것은 모든 것을 바꿉니다. 하지만 안정적인 소프트웨어의 경우, 작성 자체가 결코 비싼 부분이 아니었습니다. 안전하게 변경하고 최악의 순간에 디버깅(debugging)하는 곳에 돈과 신경이 쓰이는 것입니다.

이러한 구분 자체는 오래된 논쟁입니다. 프로토타입 대 상용 제품(Prototype versus production)은 프레드 브룩스(Fred Brooks)의 "폐기할 계획을 세우라" (1975)부터 매니 레만(Manny Lehman)의 소프트웨어 진화 법칙(laws of software evolution) (1980)까지 수십 년 동안 논의되고 분석되어 왔습니다. 새로운 점은 폐기하는 쪽이 얼마나 저렴해졌는지입니다.

명백한 반론은 그 경계가 모호해진다는 것입니다. 프로토타입이 상업용 제품으로 승격되는 일은 늘 일어나고 있으며, 임시방편보다 영구적인 것은 없습니다(우리 대부분이 그러한 것을 물려받았으니까요).

그 말씀은 맞으며, 바로 그렇기 때문에 이 구분을 방치할 수 없는 것입니다.

누군가가 처음에 이것이 어떤 종류의 소프트웨어인지 결정해야 합니다... 그리고 그 누군가는 프로토타입이 첫 실제 사용자에게 도달했을 때도 여전히 존재해야만 합니다.

빠르고, 저렴하며, 충분히 좋은 소프트웨어

AI는 여기서 마땅한 평가를 받아야 합니다.

그 UI는 오후 만에 만들어졌습니다. AI의 영업 논리는 구축 속도가 빠르고 저렴하다는 것이며, 이러한 종류의 소프트웨어에는 사실입니다. 아이디어는 신선할 때 작동하는 데모로 구현될 수 있으며, 소규모 팀이 예전에는 더 큰 팀이 필요했던 작업을 처리할 수 있게 되었습니다.

또한 제가 기꺼이 에이전트에게 생각하게 맡기는 유일한 영역이기도 합니다. 코드가 잘못되었다면 금방 알 수 있고, 버리고 아무도 저녁 시간을 망치지 않습니다.

프로그래머들도 이전에 이런 경험을 했습니다. 1957년, 많은 어셈블리 프로그래머들은 컴파일러가 만들어준 코드는 절대 신뢰하지 않을 것이라고 맹세했습니다. 그들은 틀렸습니다. 1958년까지 IBM 기계의 절반 이상이 FORTRAN4에 의해 생성된 코드였습니다.

오늘날 에이전트가 작성한 코드를 거부하는 것은, 적어도 잘못된 답이 오후 시간을 비용으로 발생시키는 소프트웨어의 경우라면 같은 실수를 저지르는 것입니다.

하지만 안정적인(Stable) 소프트웨어는 이야기가 다릅니다. 문제는 동일한 가속기(accelerator)가 그것에 부착될 때 시작됩니다. Google의 2025 DORA 리포트5는 약 5,000명의 전문가를 대상으로 한 설문조사에서, AI 채택률이 높아질수록 더 높은 전달 처리량(delivery throughput)과 더 낮은 전달 안정성(delivery stability)을 보인다는 것을 발견했습니다.

보고서는 이를 명확히 합니다:

견고한 파이프라인(pipeline) 역시 다른 방식으로 보상을 가져다줍니다. Matt Asay는 InfoWorld에서 한 댓글을 인용하며 다음과 같이 말했습니다: “더 쉬워지는 것이 아니라, 단지 더 빨라질 뿐입니다.” 그리고 절약된 시간은 더 많은 범위(scope)에 쓰이며, 이것이 조용히 새로운 표준(new normal)이 됩니다.

안정적인 소프트웨어에는 소유주가 필요하다

Simon Willison은 코딩 에이전트(coding agents)와 관련된 글을 쓴 사람 중 가장 많은 시간을 보냈을 가능성이 높으며, 그를 좋아합니다. 그럼에도 불구하고 그는 최근 노트에서 다음과 같이 작성했습니다:

“코딩 에이전트를 사용하며 보내는 시간이 많아질수록, 이들이 소프트웨어 엔지니어링을 더욱 어렵게 만든다고 확신하게 됩니다.

우리는 이것들로 놀라운 일들을 할 수 있지만, 그 잠재력을 완전히 끌어내기 위해서는 비범한 규율과 지식이 필요합니다.”

이것이 1957년의 평행 구조가 깨지는 지점입니다. 컴파일러(Compiler)는 결정론적(deterministic)이기 때문에 신뢰를 얻었습니다. 즉, 동일한 소스 코드는 매번 동일한 출력을 내며, 사용자는 이를 검증할 수 있습니다.

LLM은 설계상 비결정론적(non-deterministic)입니다. 두 번 질문하면, 그럴듯한 답변이 두 개 나옵니다.

따라서 리뷰와 검증은 수동으로 어셈블리 코드를 확인하던 방식처럼 사라지지 않습니다. 안정적인 소프트웨어의 경우, 이것들이 가장 많은 작업량이 됩니다.

검증은 또한 누군가가 애초에 변경 사항을 이해했다는 것을 전제하며, 이는 그 작업이 에이전트에게 어떻게 전달되었는지에 달려 있습니다. 아웃소싱(outsource)할 때는 스스로 할 수 있는 작업을 맡기므로, 돌아온 결과물을 여전히 확인할 수 있습니다. 하지만 오프로드(offload)하는 것은 생각 자체를 넘겨주는 것이며, 아직 구축하지 않은 생각까지 포함합니다. 그 결과는 검증할 대상이 아무것도 남지 않게 됩니다.

배포 파이프라인은 이 둘을 구분할 수 없습니다. 왜냐하면 둘 다 동일한 풀 리퀘스트로, 동일한 녹색 테스트와 대시보드상의 동일한 속도로 끝나기 때문입니다.

최근의 통제된 연구6에서는 주니어 엔지니어들에게 생소한 라이브러리를 앞에 두었습니다. AI를 사용해 코드를 이해한 그룹은 이해도 점수에서 65% 이상을 기록했고, 코드를 완전히 위임한 그룹은 40% 미만을 기록했습니다. 이러한 격차는 퀴즈나 새벽 2시의 프로덕션 환경에서만 볼 수 있습니다.

단발성 소프트웨어에서는 아무도 신경 쓰지 않습니다. 하지만 안정적인 소프트웨어에서는 외주된 코드가 부채(debt)이며, 호출 당번인 사람이 이자를 지불합니다.

제가 디스패치 시스템을 다루던 한 주는 아웃소싱이었습니다. 에이전트가 많은 도움을 주었습니다. 그럼에도 불구하고 그 주는 하루였고, 대부분은 변경 사항을 배포하기 안전하게 만드는 부분에 할애되었습니다. 그 부분은 저의 몫이었습니다.

이것이 안정적인 소프트웨어에 대한 진정한 요구사항입니다. 모든 변경 사항에는 그것을 설명하고, 방어하고, 수정할 수 있는 사람이 필요합니다. 인간 검토만으로는 부족하며, 737 MAX의 MCAS7와 CrowdStrike의 2024년 장애8 모두 사람들에 의해 구축되고, 확인되고, 배포되었습니다. 결과물을 내놓는 것은 구조입니다. 변경 사항을 병합하는 사람은 그것이 고장 날 때도 호출을 받게 되며, 모든 검토는 '통과하는가'를 묻기 전에 '왜인가'를 묻습니다.

규제 기관들도 이를 인지하고 같은 방향으로 움직이고 있습니다. EU에서는 개정된 제품 책임 지침9이 소프트웨어(AI 포함)를 상품으로 취급하며, 2026년 12월부터 조직도 책임을 지게 됩니다.

하지만 이 모든 것을 실행할 누군가가 여전히 필요합니다. 이것이 제가 친구에게 '에이전트를 조율하는 진정한 장인'이 필요하다고 말했을 때의 의미였습니다.

코드를 생성하는 것은 이제 쉬운 부분입니다. 그래서 기술은 에이전트에게 올바한 범위, 올바한 컨텍스트, 합리적인 작업 순서를 부여하는 것, 그리고 그 이후 모든 것—테스트, 롤아웃, 라이브 상태에서 모니터링하는 것—으로 이동했습니다. 이 전체 프로세스를 마스터하는 팀들이 AI와 함께 잘할 것입니다. 코드가 얼마나 많이 나오는지만 계산하는 팀들은 대부분 다른 누군가가 소유해야 할 코드만 생산할 것입니다.

그리고 생성된 코드가 실제 운영 환경(production)에서 오류가 발생했을 때, 이를 수정하는 사람은 코드, 인프라스트럭처, 데이터, 그리고 아무도 문서화하지 않은 비즈니스 규칙을 모두 넘나들어야 합니다. 이것이 바로 다재다능한 문제 해결사(polyvalent problem solver)가 다시 필요하다고 생각하는 이유입니다. 결국 코드를 작성한 에이전트는 온콜(on call) 상태에 있지 않을 것이기 때문입니다.

2040년에도 안정적인 소프트웨어를 누가 운영할 것인가?

그러한 문제 해결사들은 어딘가에서 나와야 합니다.

누가 어떤 종류의 일을 맡는지 살펴보세요. 일회성(one-shot) 소프트웨어는 보통 주니어 개발자의 책상에 놓입니다: 내부 도구, 프로토타입, 스크립트 같은 것들입니다. 또한 아웃소싱이 효과를 발휘하고 아무도 확인하지 않는 곳이기도 합니다. 하지만 안정적인 시스템은 이미 그것들을 알고 있는 시니어들이 맡게 되며, 바로 그곳에서 무언가를 망가뜨리고 고치면서 배웁니다.

채용 데이터도 같은 방향을 가리킵니다. Brynjolfsson, Chandar 그리고 Chen이 2025년에 발표한 스탠퍼드 연구10에 따르면, AI 노출 직무(소프트웨어 개발 포함)에서 22세에서 25세 사이의 사람들의 고용률은 가장 적게 노출된 직무 대비 약 16% 감소했지만, 35세에서 49세 사이의 연령대에서는 계속 증가세를 보였습니다.

이 시기는 팬데믹 이후 채용 조정(post-pandemic hiring correction)과 겹치기 때문에 원인을 단정하기는 어렵습니다. 하지만 그 방향성은 무시하기 힘듭니다.

이 모든 것이 주니어들이 AI를 통해 배울 수 없다는 의미는 아닙니다. 사실, 증거들은 그들이 배울 수 있다고 말합니다: 이전 연구11에서 가장 경험이 적은 지원 에이전트가 AI 어시스턴트로부터 가장 많은 것을 얻어 약 34%의 생산성 향상을 보였습니다.

AI는 우리가 대부분 갖지 못했던 인내심 있는 과외 선생님이 될 수 있습니다. 단, 가르칠 실제 시스템이 존재한다는 전제하에 말입니다.

'우리 같은 나이 사람들에게는 효과가 있다'라는 말이 얼마나 듣기 불편한지 알고 있습니다. 모든 세대의 프로그래머들은 다음 도구에 대해 비슷한 말을 했고, 대부분 틀렸습니다. 제가 걱정하는 부분은 더 좁습니다.

당신은 스스로 할 수 있는 것만 안전하게 아웃소싱할 수 있으며, 제가 아는 모든 잘 아웃소싱하는 시니어들은 그 과정에서 오류를 포함하여 안정적인 작업을 직접 손으로 해보면서 배웠습니다. 만약 다음 세대가 그런 작업에 근접하지 못한다면, 10년 또는 15년 후에는 기계에 아웃소싱하려는 사람이 넘쳐나고, 그것을 아웃소싱할 수 있는 사람은 매우 적게 남을 것입니다.

그래서 친구에게 좀 더 깔끔한 답을 해줄게. AI는 우리의 일을 두 가지로 나누었어.

일회용으로 만들어진 소프트웨어, 예를 들어 내 운동 UI 같은 경우에는 우리가 이제껏 가졌던 최고의 도구야. 죄책감 없이 맡겨도 돼.

하지만 사람들이 의존하는 소프트웨어, 예를 들어 그 디스패치 시스템 같은 경우에는 기준을 높였어: 더 많은 검토(review), 더 많은 검증(verification), 그리고 아무도 손으로 작성하지 않은 것을 디버깅할 수 있는 더 많은 사람들을 필요로 하게 만들었지.

나는 지난주에 어디를 봐야 할지 알았는데, 이런 시스템을 부수고 고치는 작업을 몇 년 동안 했기 때문이야. 후배들도 누군가 여전히 그 시스템 근처에 있게 해준다면 같은 것을 배울 수 있어.

우리가 무엇을 하든 그것은 결정이고, 우리에게 달려있어.

이 글이 좋았다면, 더 많은 내용을 보려면 내 블로그를 팔로우해 줘.

Unsplash의 Fahrul Razi가 커버함