새로운 종이와 펜, 새로운 예술가
코드가 중간 결과물이 되면 누가 소프트웨어의 저자인가?
거의 6개월에 걸친 엔지니어링 작업에서 저는 자연어, 제품 문서, 아키텍처 제약 조건, 런타임 결과, 인수 피드백만으로 Coding Agent와 함께 아직 출시되지 않은 여러 제품을 만들었습니다. 데스크톱 앱, 브라우저 확장 프로그램, 백엔드 서비스, 데이터베이스를 아우르는 제품들입니다.
저는 코드 한 줄도 작성하지 않았고, 한 줄도 읽지 않았습니다.
그렇다고 제품을 AI에게 넘겨준 것은 아닙니다. 어떤 문제를 해결할지 결정하고, 시스템이 어떻게 작동해야 하는지 정의하고, 넘지 말아야 할 경계를 판단하고, 결과를 신뢰할 수 있는지 검증하며, 최종 소프트웨어에 대한 책임을 지는 일은 여전히 제 몫이었습니다. 달라진 것은 구현과 상호작용하는 방식뿐이었습니다.
이 경험은 한때 단순해 보였던 질문을 다시 생각하게 했습니다. 더 이상 손으로 코드를 쓰지 않더라도 작품을 정의하고, 성공 여부를 판단하며, 끝까지 책임지는 사람은 여전히 소프트웨어의 저자일까요?
이 관행은 모든 소프트웨어가 이런 방식으로 구축될 수 있다는 것을 증명하지 않습니다. 아직 출시되지 않은 이들 제품이 시장에서 성공할 것이라는 점을 증명하는 것도 아니다. 그러나 우리가 구축하는 애플리케이션 유형의 경우 코딩 에이전트 중심의 워크플로는 더 이상 단순히 프로그래밍 속도를 높이는 방법이 아닙니다. 이는 계획, 구현, 테스트, 수정 및 반복을 지속할 수 있는 엔지니어링 접근 방식이 되고 있습니다.
중요한 변화는 “AI가 코드를 작성할 수 있다”는 것이 아니다. 구현은 소프트웨어 제작에서 가장 부족한 부분 중 하나였습니다. 이제 배경으로 물러나기 시작했습니다.
구현이 더 이상 가장 부족한 부분이 아니라면 인간의 작업은 어떻게 될까요?
이것이 바로 이 에세이의 질문입니다.
AI의 경계가 움직인다
AI는 결코 고정된 용어가 아니었습니다. 사람들은 무언가를 AI라고 부르는 경향이 있지만 컴퓨터는 아직 이를 안정적으로 수행할 수 없습니다. 기능이 성숙되어 일상 제품에 적용되면 빠르게 일반 기술이 되어 AI처럼 보이지 않게 됩니다.
내 길도 이 경계를 따라왔다. 중학교와 대학교에서는 센서와 피드백 제어를 사용하여 바퀴 달린 로봇이 경로를 따르고, 장애물을 피하고, 대형을 조정하도록 하는 작업을 했습니다. 저는 대학원 시절 컴퓨터 비전을 공부하면서 새로 창업한 SenseTime에 초기 창업사원으로 합류했습니다. 저는 얼굴 생체 인식 및 산업용 비전 기술을 스마트폰, 고속철도 등 대규모 애플리케이션에 적용하는 데 도움을 주었습니다. 오늘날 범용 기반 모델과 해당 모델이 지원하는 에이전트는 다시 한 번 경계를 확장했습니다. 이러한 시스템은 더 이상 고립된 문제만을 해결하지 않습니다. 그들은 목표를 이해하고, 도구를 사용하고, 피드백에 따라 계속해서 행동하기 시작했습니다. 내 작업도 이러한 제품쪽으로 옮겨졌습니다. 돌이켜보면 동작 제어와 이미지 이해부터 전체 작업 완료에 이르기까지 기계는 더 길고 더 완전한 작업 체인을 담당하고 있습니다.
따라서 이 에세이에서 AI는 주로 범용 기반 모델에 의해 구동되는 에이전트를 지칭하며, 코딩 에이전트가 대표적인 예입니다. 그들의 발전은 더 긴 범위의 작업을 자율적으로 실행하고, 점진적인 자기 진화를 이루고, 심지어 자신의 후임자를 훈련시키는 능력까지 지향합니다.
2025년 Andrej Karpathy는 “바이브 코딩”이라는 말로 느슨한 프로그래밍 방식을 설명했습니다. AI에게 원하는 것을 말하고, 생성된 코드를 받아들이고, 오류 메시지를 다시 건네며, 심지어 코드가 존재한다는 사실조차 잊는 방식입니다. [1] 다만 이렇게까지 맡기려면 실패 비용이 낮아야 한다는 전제가 있습니다. 당시 진지한 제품을 만들 때 우리는 여전히 Cursor를 사용했습니다. 인간 개발자가 작업을 주도하고 코드에 책임을 졌으며, 에이전트는 보조 역할을 했습니다.
2026년 초까지 우리는 경계가 다시 앞으로 나아가는 것을 보았습니다. Karpathy는 나중에 새로운 작업 방식을 "에이전트 엔지니어링"이라고 불렀습니다. 개발자는 더 이상 AI를 사용하여 코드를 완성하는 것이 아니라 검토 및 품질에 대한 책임을 유지하면서 엔지니어링 작업을 수행할 때 에이전트를 구성하고 감독합니다. [2] 이름은 중요하지 않습니다. 중요한 것은 AI가 한 번에 하나씩 제안을 제공하는 것에서 제약 조건 내에서 지속적인 조치를 취하는 것으로 이동하고 있다는 것입니다.
일부 소프트웨어 제작자에게 자연어와 문서는 이미 의도를 표현하는 새로운 레이어가 되고 있습니다.
코드는 중간 산출물이 되어가고 있다
컴퓨팅의 역사는 추상화 계층을 추가한 역사이기도 합니다.
사람들은 처음으로 스위치와 패치 케이블을 사용하여 기계를 작동했습니다. 그런 다음 기계어 코드, 어셈블리 및 고급 프로그래밍 언어가 나왔습니다. 각각의 새로운 레이어는 아래의 복잡성 중 일부를 숨기고 사람들이 자신의 의도에 더 가깝게 작업할 수 있도록 해줍니다.
코딩 에이전트는 소프트웨어 개발에 새로운 추상화 계층을 추가합니다. 이는 비결정적 슈퍼컴파일러와 같습니다. 기존 컴파일러는 공식적으로 지정된 프로그램을 기계 명령어로 변환하는 반면 코딩 에이전트는 인간의 의도를 인터페이스, 데이터, 서비스 및 코드로 전개하려고 합니다.
차이점이 중요합니다. 인간의 언어는 모호합니다. 요구 사항은 불완전한 경우가 많으며 제약 조건이 충돌할 수 있습니다. 에이전트는 문장을 하나의 올바른 결과로 기계적으로 번역할 수 없습니다. 이해, 계획, 구현, 실행 및 검증을 순환해야 합니다.
자연어는 프로그래밍 언어를 대체하지 못했습니다. 더 정확하게 말하면, 자연어와 문서는 사람이 유지 관리하는 의도 계층이 되고 있으며, 코드는 에이전트가 생성하고 유지 관리하는 구현 매체 역할을 점점 더 많이 하고 있습니다.
이는 코드를 중간 아티팩트에 더 가깝게 만들지만 "중간"이 중요하지 않다는 의미는 아닙니다. 코드는 여전히 정확하고 안전하며 유지 관리가 가능해야 합니다. 사람이 한 줄씩 쓰고 읽을 필요는 없을 수도 있습니다. 대부분의 프로그래머는 컴파일러가 내놓은 기계어 코드를 검사하지 않지만 프로그램이 수행하는 작업에 대한 책임은 그대로 유지합니다.
이로 인해 우리가 명확히 해야 할 사항이 변경되었습니다.
문서는 코드에 대한 설명이었습니다. 우리 작업에서는 관계가 역전되기 시작했습니다. 문서에서 더 많은 코드가 생성되고 확인됩니다. 제품이 존재하는 이유, 시스템이 어떻게 작동해야 하는지, 어떤 경계를 넘을 수 없는지, 요구 사항을 충족하는지 보여주는 증거는 무엇인지, 이러한 것들이 일단 코드에 대한 첨부 파일로 취급되면 소프트웨어 자체의 소스가 되고 있습니다.
과거에는 이렇게 말했습니다. “말은 싸다. 코드를 보여 달라.”
이제는 이렇게 말합니다. “코드는 싸다. 문서를 보여 달라.”
코드를 직접 쓰지 않는다고 해서 표현의 정확성이 덜 중요해지는 것은 아닙니다. 오히려 더 중요해집니다. 과거에는 모호한 생각이 긴 구현 과정에서 드러나고 명확해질 시간이 있었습니다. 이제 에이전트는 그 생각을 빠르게, 작동하지만 겉보기에만 완성된 시스템으로 만들 수 있습니다. 모호함은 사라지지 않습니다. 구현 속에 묻혔다가 나중에 실패와 손실로 드러날 뿐입니다.
AI는 우리를 생각하는 일에서 면제해 주지 않습니다. 구현의 분주함 뒤에 모호한 생각을 숨기기 어렵게 만들 뿐입니다.
'종이와 펜'의 나머지 절반
2025년 Wang Jian은 AI를 인류의 '새로운 종이와 펜'에 비유했습니다. 즉, 생각 자체가 아니라 인간 사고의 확장입니다. [3] 나는 이 비유를 좋아한다.
여기에는 흥미로운 역사적 대칭이 포함되어 있습니다. 1948년에 앨런 튜링(Alan Turing)은 종이, 연필, 지우개를 가지고 일련의 규칙을 따르는 사람의 행동을 보편적인 기계의 행동으로 간주할 수 있는 상상을 했습니다. [4] 그런 다음 사람들은 종이와 연필을 사용하여 사람이 기계를 시뮬레이션하는 방법을 설명했습니다. 거의 80년이 지난 지금, 방향은 역전된 것 같습니다. 기계는 새로운 종이와 펜이 되어 사람들이 실행 가능한 세계로 의도를 펼치도록 돕습니다.
그 비유는 나에게도 대학을 생각나게 한다. 잠을 자는 것 외에도 운영 체제 설치, 환경 구성, 도구 학습, 마이크로 컨트롤러 수정, 바퀴 달린 로봇 디버깅 및 대형 조정 작업, 관심 있는 모든 데모 구축 등 소프트웨어와 하드웨어 사이를 오가며 시간의 3분의 1을 소비했을 것입니다. 나는 그 과정을 즐겼지만 마치 화가가 끊임없이 종이를 찾고, 안료를 만들고, 붓을 고치는 것처럼 창조하는 것보다 창조를 준비하는 데 더 많은 시간을 소비했습니다.
AI를 새로운 종이와 펜이라고 부르는 것이 모든 것을 할 수 있다는 의미는 아닙니다. 종이는 소설을 쓰지 않습니다. 안료는 좋은 그림을 그릴 수 없고, 카메라는 좋은 필름을 만들지 못합니다. 도구는 표현 비용을 낮추지만 표현 가치가 무엇인지 결정하지는 않습니다.
코딩 에이전트는 종이와 펜보다 훨씬 더 활동적입니다. 그들은 제한된 범위 내에서 제안을 하고, 작업을 실행하고, 선택을 합니다. 그러나 작품의 목적과 결과에 대해 책임을 질 수 있을 때까지는 더 많은 참여가 자동으로 작가가 되는 것은 아닙니다.
제가 관심을 갖는 것은 "새 종이와 펜"의 나머지 절반입니다.
새로운 종이와 펜이 있다면 어떤 예술가가 필요할까요?
소프트웨어 창작의 중심이 위로 이동하고 있다
프로그래머가 예술가라는 생각은 새로운 것이 아닙니다.
1974년 도널드 커누스(Donald Knuth)는 "예술로서의 컴퓨터 프로그래밍"에서 프로그래밍에 지식, 기술, 창의성이 필요한 이유와 그것이 어떻게 아름다운 대상을 만들어낼 수 있는지 설명했습니다. [5] 2003년 폴 그레이엄(Paul Graham)은 “해커와 화가(Hackers and Painters)”에서 해커와 화가는 모두 제작자라고 주장했습니다. 화가에게 페인트를, 건축가에게 콘크리트를 사용하는 것과 마찬가지로 소프트웨어 제작자에게 컴퓨터는 표현의 매체입니다. [6]
AI가 처음으로 프로그래머를 예술가로 만드는 것은 아닙니다. 예술이 주로 이루어지는 곳이 바뀌고 있습니다.
프로그래머의 기예는 주로 코드 안에서 드러났습니다. 기발한 알고리즘, 우아한 추상화, 최소한의 구조로 충분한 가능성을 품는 시스템이 그 예입니다. 이런 아름다움은 에이전트가 등장했다고 사라지지 않습니다.
그러나 더 많은 구현 작업이 에이전트로 이동함에 따라 인간 창조의 중심이 위로 이동합니다. 소프트웨어 기술은 작업 전체에서 점점 더 많이 표현될 것입니다. 어떤 문제를 선택해야 하는지, 누구의 삶을 이해해야 하는지, 어떤 순서를 확립해야 하는지, 어떤 가능성을 포기해야 하는지, 사용자에게 어떻게 대응해야 하는지, 작업이 어떻게 사용자의 삶에 들어가야 하는지 등이 표현될 것입니다.
제품과 경험 수준의 창조는 항상 존재해 왔습니다. 변화는 구현이 더 이상 우리의 대부분의 관심을 소비하지 않을 때 이러한 문제가 더 많은 소프트웨어 제작자의 주요 작업이 될 수 있다는 것입니다.
우아한 코드는 여전히 중요하지만, 코드는 결코 소프트웨어의 아름다움의 전부가 아닙니다. 사람과 AI가 함께 만든 소프트웨어는 단순히 실행되는 코드 덩어리가 아니라 소프트웨어의 완전한 작품으로 보아야 합니다.
이것이 바로 '신인 아티스트'가 의미하는 변화이다.
기존 전문 용어로 볼 때 이 역할은 제품 관리자와 설계자의 조합과 비슷합니다. 즉, 무엇을 만들어야 하는지, 누구를 위해 만들어야 하는지, 시스템이 어떻게 지속될 수 있는지, 경계는 어디에 있는지 묻는 것입니다. 그러나 그 제목만으로는 충분하지 않습니다. 소프트웨어 작성자에게는 취향, 공감, 절충 능력, 전체 결과에 대한 책임을 지려는 의지도 필요합니다.
여기서 '예술가'는 더 고귀한 호칭도 아니고 반드시 한 사람을 지칭하는 것도 아니다. 완전한 작품을 책임지는 작가의 역할이고, 팀이 공유할 수 있는 역할이다.
엔지니어링을 통해 작업이 안정적으로 존재할 수 있습니다. 예술은 그것이 존재하는 이유와 그것이 인간의 삶에 어떻게 들어가는지를 결정합니다.
엔지니어링은 사라지지 않으며, 책임은 아웃소싱될 수 없습니다
신인 아티스트는 좋은 아이디어를 제안한 뒤 AI가 나머지 모든 것을 끝내기를 기다리지 않는다.
종이와 펜이 널리 보급된 후에도 글쓰기에는 여전히 훈련이 필요했습니다. 카메라가 널리 보급된 후에도 사진에는 여전히 판단이 필요했습니다. 코딩 에이전트는 구현 비용을 낮추지만 복잡한 시스템의 아키텍처, 보안, 성능, 품질 또는 유지 관리를 자동으로 해결하지는 않습니다.
내가 코드를 읽지 않는다는 사실이 내가 엔지니어링 통제를 포기했다는 의미는 아닙니다. 제어 지점이 변경되었습니다. 구현을 한 줄씩 검사하는 것에서 시스템 목표, 아키텍처 원칙, 데이터 경계, 권한 모델, 테스트 표준, 관찰 가능성 및 승인 테스트 결과를 정의하는 것까지 변경되었습니다.
그렇다고 작업의 엄격함이 줄어드는 것은 아닙니다. 엄격함이 놓이는 위치가 달라질 뿐입니다. 테스트가 실제 위험을 다루는가? 런타임 결과가 시스템이 제약을 충족한다는 사실을 보여 주는가? 에이전트의 설명을 뒷받침할 증거가 있는가? 기능이 작동한다면 실제로 출시할 준비도 되었는가? AI는 이 모든 작업에 참여할 수 있지만, 증거를 신뢰할 수 있는지 최종적으로 판단하고 오판의 결과를 감당하는 주체는 사람이어야 합니다.
인프라, 안전이 중요한 시스템, 하위 수준 소프트웨어를 포함한 일부 분야에서는 계속해서 사람들이 코드 내부에서 심층적으로 작업해야 합니다. 그 어느 때보다 하위 레이어를 진정으로 이해하는 소수의 사람들이 필요할 수도 있습니다. 새로운 추상화 레이어는 그 아래 레이어를 결코 지우지 않습니다. 고급 언어는 어셈블리를 제거하지 않았으며 클라우드 컴퓨팅은 운영 체제를 제거하지 않았습니다. 새로운 레이어를 사용하면 더 많은 제작자가 무언가를 만들 때마다 모든 하위 레이어를 통과하는 것을 피할 수 있습니다.
코드를 쓰거나 읽지 않기로 한 나의 결정은 제한된 관행이지 모든 사람에게 적용되는 규칙은 아닙니다. 그 가치는 코드가 쓸모없다는 것을 증명하는 것이 아닙니다. 코드가 더 이상 사람들이 소프트웨어를 제어하는 유일한 인터페이스가 아닌 경우 작업의 어떤 부분을 여전히 전달할 수 없는지 확인하는 데 도움이 됩니다.
첫째는 심판이다. 두 번째는 책임이다.
더 강력한 도구는 더 큰 규모로 평범함을 만들어낼 수도 있습니다. 구현 비용이 저렴해지면 먼저 실제 필요를 충족하지 못하는 더 반복적이고 조잡한 소프트웨어를 얻게 될 수 있습니다. 종이와 펜은 자동으로 문학을 생산하지 않습니다. 코딩 에이전트는 소프트웨어 르네상스를 자동으로 생성하지 않습니다.
AI는 희소성을 없애지 않습니다. 희소성의 위치를 옮길 뿐입니다.
소프트웨어 생산은 주로 프로그래밍 기술, 엔지니어링 자원 및 구현 시간에 의해 제한되었습니다. 이러한 제약이 완화됨에 따라 어떤 문제가 중요한지에 대한 판단, 제품 직관, 시스템 이해, 취향, 사람에 대한 이해, 결과에 대한 책임을 지려는 의지가 상대적으로 희소해집니다.
'어떻게 만들 것인가'가 저렴해질수록 '무엇을 만들 것인가'는 더 비싸진다.
코드 작성자에서 소프트웨어 작성자로
Bret Taylor는 Arya Asemanfar의 관찰을 인용했습니다. AI가 당신을 위해 초안을 작성할 수 있지만 여전히 작성자는 당신입니다. [7] Addy Osmani는 개발자의 새로운 역할을 설계자이자 편집장으로 설명했습니다. [8]
작가는 작품을 생산하는 모든 활동을 수행할 필요는 없습니다. 건축가는 모든 벽돌을 쌓지 않으며 감독은 영화 세트의 모든 카메라를 작동하지 않습니다. 하지만 그들은 그 일이 어떻게 되어야 하는지 알아야 하고, 그 일이 성공할지 판단해야 하며, 그 일 전체에 대해 책임을 져야 합니다.
소프트웨어에서도 동일한 변화가 일어나고 있습니다.
우리는 누가 코드를 작성했는지 물어봄으로써 소프트웨어 작성자를 식별하곤 했습니다. 미래에는 저자됨이 점점 더 다양한 질문에 의존하게 될 것입니다. 누가 문제를 정의했는가? 누가 제약 조건을 설정했습니까? 누가 중요한 절충안을 만들었습니까? 작업이 완료되었다고 누가 결정했습니까? 그리고 그것이 세상에 나온 후에 일어나는 일에 대한 책임은 누구에게 있습니까?
이는 또한 소프트웨어의 경제적 단위를 변경할 수도 있습니다. 과거에는 일반적으로 소프트웨어 구축을 정당화할 만큼 충분한 사람들이 요구 사항을 공유해야 했습니다. 구현 비용이 충분히 낮아지면 팀, 가족 또는 한 사람의 특정 작업 흐름이 자체 소프트웨어를 보증할 수 있습니다. 모든 사람이 프로그래머가 될 필요는 없지만 더 많은 사람이 소프트웨어 작성자가 될 수 있습니다.
AI는 더 많은 구현 작업을 아래로 밀어내는 동시에 인간 제어 지점과 생성 중심을 하나의 추상화 계층 위로 이동합니다. 프로그래머는 더 이상 단순한 코드 작성자가 아닙니다. 점점 더 그들은 완전한 소프트웨어 작품의 저작자가 될 것입니다. 즉, "신인 아티스트"가 될 것입니다.
새 종이와 펜이 도착했어요. 그러나 새로운 르네상스가 자동으로 따라오는 것은 아닙니다. 이는 에이전트가 얼마나 많은 코드를 생성할 수 있는지가 아니라 "어떻게 만들 수 있습니까?"보다 더 어려운 질문에 답할 판단과 책임을 지려는 의지가 있는지 여부에 달려 있습니다.
창조할 가치가 있는 것은 무엇이며 사람들이 그것을 어떻게 경험하기를 원합니까?
참고자료
[1] Andrej Karpathy, “바이브 코딩”을 소개하는 X 포스트, 2025-02-02.
[2] Andrej Karpathy, "에이전트 엔지니어링"을 제안하는 X 포스트, 2026-02-04.
[3] Liu Ningxin, “Wang Jian: 혁신은 '불완전함'과 '경계 교차'에서 비롯됩니다”, 21st Century Business Herald, 2025-09-25.
[4] Alan M. Turing, “지능형 기계”, 국립 물리 연구소 보고서, 1948년.
[5] Donald E. Knuth, “예술로서의 컴퓨터 프로그래밍”, Communications of the ACM, 17(12), 1974, pp. 667–673.
[6] 폴 그레이엄, “해커와 화가”, 2003년 5월.
[7] Bret Taylor, “AI는 당신의 대필가이지만, 저자는 당신이다”, LinkedIn, 2026-02-10.
[8] Addy Osmani, Vibe Coding을 넘어서, O'Reilly Media, 2025년 8월.