소프트웨어 분야가 수년에 걸쳐 구축해 온 높은 수준의 공학적 프레임워크가 왜 AI 코딩 에이전트를 유난히 강력하게 만들었는지, 그리고 그것이 프로그래밍이 진정한 공학 분야임을 어떻게 보여 주는지에 대한 글.
iRi 10년이 훌쩍 넘도록 태그라인을 고르기엔 너무 게으른 상태를 기념하며
2026-05-05
프로그래밍 커뮤니티의 반복되는 취미 중 하나는, 청사진과 Real Engineers를 위한 자격 제도와 계획 수립과 현장 시험과 우리가 무심하게 무시하는 온갖 훌륭한 형식적 절차를 갖춘 다른 공학 분야들처럼 우리는 진짜 공학 _TM_ 을 하지 못한다고 도덕적 우월감에 찬 자기비하를 하는 것이다. 처음부터 더 많은 계획을 세우고, 우리가 무엇을 하는지 더 조심하고, 다른 분야가 하는 온갖 것을 따라 하기만 하면, 그렇게 자주 고장 나지 않는 더 나은 소프트웨어를 만들 수 있을 것이라고 말이다.
내가 오래전부터 해 온 반론은, 그들이 우리 방식대로 하지 않는 이유는 우리 방식이 나빠서가 아니라 그들이 할 수 없기 때문이라는 것이다. 호텔을 짓는 사람이 2층짜리 호텔, 객실 114개, 아주 큰 주방, 아주 작은 운동실, 수영장 없음 같은 요구 사항을 적은 Terraform 파일에 도덕적으로 대응되는 무언가를 바탕으로 버튼 하나만 눌러 호텔을 짓고, 그 전체를 $2.82에 만들 수 있다면, 그들도 그렇게 할 것이다. 그리고 나서 걸어 들어가 둘러본 뒤 결국 수영장을 넣고 싶다거나, 한 층과 객실 52개를 더 원한다거나, 건물을 부지에 올려 보니 건물 아래에 2층짜리 주차 구조물이 필요하다는 것이 분명해졌다고 판단해서, 텍스트 파일을 조금 고치고 버튼을 눌러 첫 번째 건물을 깔끔하게 철거하고 새 사양대로 $3.17에 새 건물을 올릴 수 있다면, 그들도 그렇게 할 것이다.
그들이 이런 종류의 일을 할 수 있다면, 당연히 운영 방식도 바꿨을 것이다. 그들이 사용하는 모든 절차는 그것이 불가능하다는 사실에 대한 반응이다.
프로그래밍은 공학 분야 가운데서도 청사진이 또한 깊은 의미에서 작동하는 기계 그 자체이기도 하다는 점에서 독특하다. 완전히 100% 사실은 아니다. 예를 들어 그런 기계 하나를 클라우드에서 대규모로 배포하는 비용은 단지 코드를 손에 쥐고 있는 것보다 무시할 수 없을 정도로 더 크다. 하지만 그래도 다른 어떤 공학 분야보다도 훨씬, 훨씬 더 가깝다.
게다가 AI 이전에도 우리의 청사진은 대체로 거대한 텍스트 더미였고, 우리 자신의 도구들은 그것을 다루는 데 꽤 능숙했다. 우리 자신의 기술을 개선하는 데 우리 자신의 기술을 직접 적용할 수 있는 정도의 사치를 누리는 공학 분야는 거의 없거나 아예 없다.
그리고 나는 AI 코딩 에이전트의 성공이, 우리가 한 번에 완전히 증명해 냈다고 말하고 싶다. 우리는 공학 분야를 너무도 탄탄하게 구축해 냈기 때문에, 자기 분야 내부에서 AI를 대규모로 성공적으로 운영할 수 있게 된 최초의 분야가 되었다는 것을 말이다.
이제 텍스트 모델에는 사실상 두 종류가 있다는 것을 눈치챘는가? 범용 AI가 있고… 코딩 에이전트가 있다. 프로그래밍 세계에 사는 우리는 지금 AI의 능력에 대해 매우 왜곡된 시각을 갖게 되기 쉽다. 왜냐하면 우리 세계에서는 그것들이 엄청나게 유용하고, 그런 유용성을 다른 영역으로 확장하는 것은 훨씬 더 어렵기 때문이다. 그것들은 너무도 독보적으로 유용해서, 우리야말로 그것들을 위해 별도의 모델이 훈련되는 가장 큰 사용 사례가 되었다.
그리고 그 이유는 바로 소프트웨어 세계가 수년에 걸쳐 구축해 온 고품질 공학 프레임워크 때문이다. 우리는 단위 테스트를 갖고 있다. 통합 테스트도 있다. QA도 있다. 커버리지 테스트도 있다. 요구 사항 프로세스도 있다. 고도로 구조화된 티켓 시스템도 있다. 텍스트 기반 코드베이스에서 아주 잘 작동하는 소스 컨트롤도 있고, 여러 개발자가 소스 컨트롤 위에서 함께 작업하고 서로의 PR을 검토하며, 이런 브랜치 가운데 하나를 시험적으로 배포해 직접 테스트할 수 있게 하는 놀라울 정도로 견고한 워크플로도 있다. 주석, 구조화된 언어, 라이브러리, assertion으로서의 타입, 정확성에 대한 수학적 증명까지, 목록은 끝이 없다. 도구의 일부만 사용하는 프로젝트조차도 오늘날에는 꽤나 유능하다.
내가 1997년에 시작했을 때는 이런 것들의 상당수가 마련되어 있지 않았다. 우리는 대규모 프로젝트를 쥔 카우보이들이었다. 하지만 지금은 소스 컨트롤에 들어가는 어떤 프로젝트에 대해서도 내가 기본적인 최소 허용 공학 수준이라고 여기는 것이, 1997년의 나에게 주어져 있던 것보다 훨씬 더 많다.
이 말은 어느 종류의 승리주의를 뜻하는 것이 전혀 아니다. 우리가 이런 것들을 갖고 있다는 사실은 엔지니어 가 아니라 도메인 의 특성 때문이다. 프로그래밍 세계에서는 그것들이 가능하기 때문에 우리가 그것들을 갖고 있는 것이다. 다른 도메인도 이렇게 서로를 개선하는 메커니즘을 이만큼 배치할 수 있다면 틀림없이 그렇게 했을 것이다. 예를 들어 실제로 만들기 전에 자동차 전체를 효율, 소음 발생, 공기역학 등과 관련해 시뮬레이션하는 진보는 정말 훌륭하고, 많은 작업을 요구하며, 프로그래머에게는 없는 수학, 경험, 도메인 지식을 수반한다. 다른 모든 공학 분야도 뽐낼 수 있는 똑같이 훌륭한 것들을 갖고 있다. 문제는 인간이 아니다.
AI가 우리 분야에서 작동하는 방식을 보면 이런 것들이 중요하다는 사실을 알 수 있다. AI가 여러분을 위해 비교적 긴 작업을 수행하고 있을 때, 그것이 실제로 어떻게 일하는지 잠깐 진지하게 지켜볼 만한 가치가 있다. 그것은 나에게 범퍼 볼링; 그것이 무엇인지 보여 주는 짧은 동영상 링크를 떠올리게 한다. AI는 우리가 세워 둔 모든 범퍼를 따라 이리저리 부딪힌다. 컴파일 실패, 테스트 실패, 통합 실패, 오류 메시지, 우리가 공학 프로세스 안에 구축해 둔 모든 범퍼들 말이다. 그리고 결국 좋은 결과에 도달한다. 하지만 그 좋은 결과는 다른 무엇 못지않게 우리가 설치해 둔 견고한 공학 프로세스의 결과이기도 하다. 왜냐하면 그런 보호 장치가 없는 AI는 비교적 금방 도랑으로 굴러 떨어지기 때문이다. 범퍼를 우리만큼 쉽게, 혹은 우리만큼 많이 세울 수 없는 분야에서는 AI에게 바로 그런 일이 벌어진다.
그리고 다시 말하지만, 이것은 “프로그래머는 대단하다”는 이야기가 아니다. 우리의 도메인은 애초에 이런 범퍼들을 가질 수 있게 해 주는 성격을 띠고 있다는 이야기다.
그렇다, 인간도 그렇게 일한다. 범퍼는 원래 인간을 위해 먼저 설치되었다. 내 성과 평가에서는 종종 내가 “세부 사항 지향적”이라고 기록된다. 현실은 나는 그렇지 않고, 한 번도 그런 적이 없다는 것이다. 오히려 중요한 대부분의 면에서 나는 그 반대에 가깝다. 나는 단지 어떤 특정한 세부 사항을 한 번 고려하고 나면, 그 시점부터는 그 세부 사항이 포괄되도록 단위 테스트나 타입 같은 것에 그것을 인코딩하는 방법을 배웠을 뿐이다. 그 누적된 결과가 나를 “세부 사항 지향적”으로 보이게 만든다. 실제로는 나 역시 늘 그 범퍼들에 부딪히고 있다.
그것이 소프트웨어 세계 공학 프로세스의 품질이다.
현재 형태의 코딩 에이전트가 성공했다는 사실은, 소프트웨어 공학이 진짜 공학 분야라는 점뿐 아니라, 이 분야 내부의 특수한 국지적 관심사들 때문에 그것이 정말로 훌륭한 공학 분야라는 점을 명백히 증명한다. 우리가 그 모든 고품질 공학적 통제 장치를 갖고 있지 않았다면, 코딩 에이전트는 지금보다 훨씬, 훨씬 덜 유용했을 것이다.
이제 우리가 왜 다른 분야처럼 소프트웨어 공학을 하지 않느냐고 불평하는 일은 그만둬도 된다.
© 2026 Jeremy Bowers. Hugo와 대폭 수정된(원망은 그들이 아니라 나에게) Mainroad 테마로 생성됨.
