AI는 단순한 도구를 넘어 새로운 패러다임이 될 수 있을까?
오늘날 AI는 단순히 고수준 언어 추상화나 그런 것이 아니다. 하지만 시간이 지나면서 그런 것이 될 수 있을까? 이게 핵심 질문이다. 나는 그럴 수 있다고 생각한다.
전통적인 컴파일러 설계나 프로그래밍 언어를 생각해보면, 만약 LLM을 도구로 활용할 수 있다면 컴파일러를 구축하는 방식에 대해 완전히 다르게 생각하게 될 것이다. 아직 이런 변화가 완전히 나타나지는 않았지만, 인간의 언어로 특정한 것들을 효율적이고 충분히 엄밀한 방식으로 정의할 수 있다면, 그리고 이를 컴파일러의 직접적인 입력으로 사용할 수 있다면, 많은 것들이 바뀔 수 있다.
AI 코딩 시장의 현재 위치
현재 AI 코딩은 두 번째로 큰 AI 시장이라고 확신한다. 순수한 소비자 챗봇이 1위이고, 코딩이 2위다. 물론 소비자 시장은 여러 가지가 집합된 것이지만, 정의된 시장으로 보면 코딩이 실제로는 1위라고 주장할 수도 있다.
코딩이 동반자 AI보다 큰가? 그렇다고 생각한다. ChatGPT 같은 경우 어느 정도는 유용한 동반자 역할을 하기도 하지만, ChatGPT 사용량의 상당 부분이 동반자 역할이라고 본다. 결국 사람의 동기가 무언가를 만드는 것인지 사랑을 찾는 것인지... 아마 비슷할 것이다.
AI 코딩의 독특한 특징들
AI 코딩에서 때로는 과소평가되는 매우 독특한 점이 있다. 이것은 실제로 여러 면에서 기존에 존재하던 행동이었다는 것이다.
첫째, 사람들은 이미 도움을 찾기 위해 어딘가에 가고 있었다. 앞서 언급했듯이 대부분 Stack Overflow였다. 그래서 사람들이 해결할 수 없는 문제에 부딪혔을 때 인터넷에서 정보를 찾으러 가는 근육이 이미 있었다. AI는 그것의 훨씬 더 나은 형태일 뿐이다.
Stack Overflow가 실제로 지난 몇 년간 대부분의 코드를 작성했다는 농담들이 있었는데, 그 중 많은 부분이 이제 AI 모델로 옮겨갈 수도 있다. 그게 농담이었는지 아닌지도 확실하지 않다.
또한 GitHub Copilot이 있다. 그들은 사람들을 Stack Overflow 사용 사례에서 AI 모델 사용으로 전환시키는 정말 기초적인 작업을 했다. 그리고 Cursor 같은 회사들이 이제 그것을 훨씬 더 잘하고 있다고 생각한다.
개발자들이 먼저 자신의 문제를 해결한다
또 다른 측면은, 개발자가 최신 AI 기술에 접근할 수 있다면 가장 먼저 해결하는 것은 자신의 문제라는 것이다. 개발자들은 자신이 가장 잘 이해하는 문제, 매일 직면하는 문제를 다룬다. 그래서 자신이 사용할 인프라를 구축한다.
개발자들은 항상 새로운 기술의 얼리 어답터다. 자연스럽게 그들은 만지작거리는 것을 좋아하고, 새로운 도구를 설정하는 것을 좋아하며, 게으르다. 그래서 생산성을 높이는 것이라면 무엇이든 채택할 것이다.
코딩 시장이 잘되는 이유는 어느 정도 검증 가능한 문제이기 때문이기도 하다. 코딩 함수는 입력과 출력이 매우 명확하다. 사용자 선호도나 다른 문제들과 비교해서 말이다.
엄청난 시장 규모
또 다른 측면은 이것이 거대한 시장이라는 것이다. 전 세계에 3천만 명의 개발자가 있다고 생각해보자. 개발자가 창출하는 평균 가치를 연간 10만 달러라고 하면, 그것은 3조 달러다.
일부 대형 금융 기관에서 본 데이터를 보면, 바닐라 코파일럿 배포만으로도 개발자 생산성이 약 15% 증가한다고 추정한다. 내 직감으로는 그것을 상당히 더 높일 수 있다고 생각한다.
전 세계 모든 개발자의 생산성을 두 배로 늘릴 수 있다고 가정해보자. 그것은 3조 달러 가치다. 애플 컴퓨터의 가치나 그런 것과 같다. 우리가 거기서 얻는 엄청난 양의 가치다.
작년에 AI에 과투자했다는 좋은 블로그 논쟁이 있었다. 그때 숫자는 연간 2천억 달러 투자였는데, 회수할 수 있을지 의문이었다. 여기서 우리는 3조 달러를 회수할 방법이 있다. 그러면 2천억 달러는 땅콩처럼 보인다.
개발자 업무의 변화
AI 진화가 완료되면, 소프트웨어 개발자의 업무가 오늘날과 어떻게 달라질지 아이디어가 있을까?
오늘 코드를 작성할 때, 나는 명세를 작성하고, 무언가를 구현하는 방법에 대해 모델과 토론한다. 쉬운 기능의 경우, 실제로 기능을 구현하도록 요청하고 그것을 검토하기만 하면 된다.
프로세스가 어떻게 달라질까? 여전히 같은 단계들이 있을까? 우리 모두가 기본적으로 명세를 작성하는 제품 매니저가 되고, AI가 코드를 작성하고 가끔 디버깅을 위해 개입하게 될까? 아니면 우리 모두가 QA 엔지니어가 되어 명세에 맞는지 테스트하게 될까?
QA 엔지니어가 되는 것은 아이러니하다. 우리 모두 QA 엔지니어가 되는 것을 피하기 위해 이 일에 들어왔는데 말이다.
현재 AI 코딩 워크플로우의 변화
지난 6개월 동안 이 모델들을 사용하는 방법이 많이 바뀌었다. 예전에는 좋아하는 ChatGPT 같은 것을 가져다가 프롬프트를 주면 문제가 나오고, 그것을 에디터에 복사해서 작동하는지 보는 식이었다. 그것은 Stack Overflow 대체 방식이었다.
하지만 그 다음 단계는 IDE에 통합된 것들을 갖기 시작한 것이다. GitHub Copilot과 Cursor가 기본적으로 자동완성을 사용할 수 있게 해주는데, 이는 큰 진전이다. 더 이상 단일체적인 질문이 아니라 플로우 안에서 이루어진다.
그 다음에는 줄 수준의 자동완성으로 나뉘었다. 문단에 대해 질문할 수 있고, 더 긴 토론을 할 수 있는 별도의 채팅 인터페이스를 가질 수 있다. 그 다음 IDE가 명령줄 도구를 사용할 수 있게 되어서 갑자기 "UV로 새로운 Python 프로젝트를 설정해줄 수 있어?"라고 말할 수 있고, 기본적으로 그 모든 작업을 수행하는 명령을 실행할 수 있다.
현재의 개발 프로세스
오늘날 새로운 소프트웨어를 작성하고 싶을 때 (프로덕션 코드는 아니지만 뭔가 시도해보고 싶을 때), 가장 먼저 하는 것은 명세를 작성하기 시작하는 것이다. 매우 높은 수준에서 시작한다. 내가 하고 싶은 것은 이것이다. 여전히 상당히 추상적이고 잘 생각되지 않은 상태다.
그 다음 기본적으로 모델에게 (아마 GPT-3.5나 3.7 또는 Gemini) "내가 하고 싶은 것은 이것이다. 이게 말이 되나? 불분명한 것이 있으면 질문해주고 더 자세한 명세를 작성해줘"라고 요청한다.
그러면 모델이 작업을 시작한다. 나에게 많은 질문을 한다. "그것을 위해 API 키가 필요하다"는 매우 간단한 것들이나 "상태를 어떻게 관리하고 싶나? 데이터베이스에 넣을까, 기회 파일에 넣을까?" 같은 더 복잡한 것들 말이다.
그래서 기본적으로 내 생각을 명확히 하는 데 도움이 되는 앞뒤 토론이고, 모델은 거의 프로세스를 생각해보는 스파링 파트너 같다. 어떤 면에서는 정말 이상하다. 하지만 작동한다.
시간이 지나면서 기본적으로 더 자세한 명세를 얻는다. 그것들을 가지고 있을 때, 모델에게 구현을 시작하도록 요청한다. 그리고 그 모든 것이 상당한 양의 컨텍스트와 함께 온다. 모델과 함께 내 표준 Python 코딩 가이드라인을 가지고 있다. 내가 주석을 어떻게 좋아하는지, 더 객체 지향적인지 더 절차적인지, 클래스를 어떻게 구조화하는 것을 좋아하는지 등이다.
AI 코딩의 한계와 도전
AI 보조 코딩을 하면서 정말 잘못된 일이 있었나? 정말 잘못된 것은 아니지만, 우리가 호출하는 방법의 많은 부분이 클라이언트가 에이전트를 어떻게 구현했는지에 따른 에이전트 행동에 의존한다.
예를 들어, 매우 예쁜 페이지를 생성하고 코딩 에이전트가 참조할 React 컴포넌트나 HTML 페이지를 다시 보내는 정말 멋진 도구가 있다. 한 번은 Cursor 에이전트에게 "이 도구에 연결해서 그것이 말하는 것을 바탕으로 구현해줘"라고 요청했다.
Cursor 에이전트의 반응이 매우 흥미로웠다. 코드를 보고 "오, 이거 좋아 보인다. 새 버전을 줄게"라고 했다. 그래서 반환된 것을 채택하지 않았다. Cursor 에이전트가 "나는 이 방향에 동의하지 않는다"고 미끄러진 것 같았다.
MCP와 컨텍스트의 중요성
MCP의 본질은 LLM에 가장 관련성 높은 컨텍스트를 제공하는 방법일 뿐이다. 그래서 요즘 많은 MCP 서버들이 사용하는 클라이언트가 무엇이든 활용할 수 있도록 도와준다. 그것이 내가 방금 설명한 경험을 가능하게 하는 것이다. Linear MCP를 사용할 수 있고, GitHub MCP를 사용해서 관련 컨텍스트를 가져올 수 있다.
도구 호출은 컨텍스트를 가져오는 방법을 구현하는 기술적 세부사항이다. 하지만 MCP의 핵심은 실제로 컨텍스트 부분이다. 가장 관련성 높은 것이 무엇인가? 모델로서 당신을 더 잘 도울 수 있도록 내가 제공할 수 있는 것은 무엇인가?
시니어 개발자들의 참여
IDE에서 이런 종류의 도구들을 사용할 수 있다는 것이 AI 코딩을 시니어 개발자들에게 더 생산적이거나 더 적합하게 만든다고 생각하나? 오랫동안 이것에 대한 비판은 바이브 코더들이 훌륭한 데모를 만들어내고 주니어 개발자들이 더 빨리 속도를 내고 있다는 것이었다.
하지만 애정을 담아 "넥비어드"라고 불리는 사람들, 즉 클러스터를 소유하고 당신이 물건을 망가뜨리는 것을 막거나 전체 아키텍처를 담당하는 사람들은 회의적이었다. 이것이 넥비어드들을 참여시키는 한 가지 방법이라고 생각하나?
매우 시니어한 엔지니어들이 무엇을 최적화하고 있는지에 달려있다고 생각한다. 아이디어를 펼치는 데 매우 뛰어난 매우 시니어한 애플리케이션 엔지니어들이 있다. 이런 경우에는 더 고르게 분산된 기술 세트 같다. 그냥 다시 조합하면 된다.
하지만 분산 시스템을 최적화하는 매우 시니어한 엔지니어들이 있다. 그것은 아직 거기까지 가지 못했다고 생각한다. 코딩 에이전트가 분산 시스템의 모든 상태를 가져올 수 없고, 특정 문제를 해결하는 방법에 대해서는 많은 인간의 개입이 필요하기 때문이다.
하지만 충분한 컨텍스트 윈도우와 충분한 도구 호출 기능이 주어져서 모델에 적절한 지식을 가져올 수 있다면 그 길로 가고 있다고 느낀다.
문제의 복잡성과 컨텍스트
문제가 더 난해할수록, 해결하려는 문제가 더 새로울수록, 더 많은 컨텍스트를 제공해야 한다는 패턴이 있는 것 같다. "블로그를 써줘"나 "온라인 스토어를 써줘" 같은 간단한 버전이라면, 그것은 학부 소프트웨어 개발 수업 문제 같은 표준적인 것이다.
인터넷에 있는 샘플의 양은 거의 무한하다. 모델들이 이것을 수십억 번 봤고 이 코드를 다시 토해내는 데 믿을 수 없을 정도로 뛰어나다.
훈련 코드가 거의 없는 것이 있다면, 일반적으로 모든 것이 사라지고 정확히 원하는 것을 명시해야 한다. 컨텍스트를 제공해야 하고, API 명세를 제공해야 하며, 훨씬 훨씬 더 어렵다. 그리고 매우 자신 있게 틀린 답을 줄 것이다.
"오 마이 갓, 이 함수가 존재한다. 내가 필요한 것과 정확히 같다"라고 할 수 없을 정도로 많이 경험했다. 그런데 기다려, 아니다, 존재하지 않는다.
바이브 코딩의 가능성과 한계
바이브 코딩에 대해 많이 이야기하지 않았지만, 개발자가 아닌 사람들이 이제 코드를 작성할 수 있다는 아이디어가 있다. 이것은 꽤 멋지고 일어나야 할 일 같다. 우리는 컴퓨터의 사제가 아니다. 일반 사람들과 프로세서 사이에 개입해야 할 필요는 없다. 사람들이 미리 만들어진 프로그램이 아닌 직접적인 방식으로 컴퓨터를 제어할 수 있어야 한다.
이것은 매우 흥미롭고 매우 흥미진진한 일이라고 생각한다. 거기에는 질문이 있다. 이것이 전혀 확장되는가, 아니면 모든 사람이 오두막을 지을 수는 있지만 마천루는 지을 수 없는 것과 같은가?
모든 사람이 처음으로 웹사이트 생성기나 Cursor 같은 것을 시도할 때 하는 데모들은 아마 인류의 나머지에게는 그다지 도움이 되지 않을 것이다. 첫 주말 프로젝트 같은 것 말이다.
하지만 그것을 시도하는 사람들 중 일부가 사다리를 오르기 시작해서 점점 더 정교한 일들을 하기 시작한다고 가정하면, 그런데 우리 세 명이 아마 어려운 방식으로 프로그래밍을 배운 것과는 완전히 다른 방식으로 말이다. 나는 새로운 사람들의 풀이 새로운 방식으로 소프트웨어를 작성하고 세상을 완전히 새로운 방식으로 바라볼 수 있다는 것에 대해 엄청난 낙관론을 가지고 있다.
미래의 프로그래밍 교육
한 추상화 수준에서 작업한다면 작업하는 곳보다 한 수준 낮은 추상화를 배워야 한다는 것은 매우 공정하다. 바이브 코더들에게 한 수준 낮은 추상화가 무엇인지 계속 생각하게 된다. 그것이 코드인가? IDE인가? 다른 무언가인가?
이것은 매우 좋은 질문이고, 질문을 조금 다시 표현해보면, 소프트웨어 개발을 하고 싶어하는 미래의 사람들이 배워야 하는 것이 무엇인가? 그것이 한 수준 더 깊은 것인가, 실제로는 옆에 있는 무언가인가?
어떤 사람들은 더 이상 CS를 배울 필요가 없다고 말한다. 모든 것이 사회적 감정적 학습과 그런 종류의 것들에 관한 것이라고. 나는 그것에 동의하지 않는다. 하지만 그것은 20년마다 나타나는 것 같다.
솔직히 5년 후에 컴퓨터 과학 교육의 등가물이 어떻게 생겼을지 전혀 모르겠다. 역사적으로 계산에서 비슷한 일을 했을 때 무슨 일이 일어났는지 보면, 수동으로 숫자를 더하는 것에서 Excel로 갔을 때, 전체 직업 카테고리가 사라진 것은 아니다. 부기 담당자가 회계사가 되거나 그런 식이었다.
데이터를 입력하고 숫자를 적고 수동으로 더하는 것은 덜 중요해졌고, 더 높은 수준의 더 추상적인 개념을 하는 것이 더 중요해졌다. 그것을 일대일로 패턴 매치하면, 문제 진술을 설명하고, 알고리즘적 기초를 설명하고, 아키텍처를 설명하고, 데이터 플로우를 설명하는 것이 더 중요해지고, 실제로 코딩하는 것, 즉 for 루프를 푸는 가장 영리한 방법은 매우 전문화된 더 틈새 분야가 될 것이라는 추측이다.
AI와 불확실성의 관리
AI를 코드를 작성하는 도구가 아니라 애플리케이션의 원시 요소로 생각한다면, 소프트웨어에서 가질 수 있는 불확실성과 비결정적 행동의 정도의 경계를 밀어내는 것 같다.
정말 옛날에는 로컬 머신용 소프트웨어를 작성했고, 그것이 어떻게 실행될지에 대해 꽤 좋은 기대를 가질 수 있었다. 네트워크라는 새로운 것이 있었는데, 이것은 어떻게 행동할지 예측하기 매우 어렵지만 같은 용어로 표현할 수 있다. 팔을 감쌀 수 있는 문제처럼 느껴진다.
AI는 어떤 면에서 그것의 확장인 것 같다. 소프트웨어에 AI를 추가하거나 사용할 때 실제로 무엇이 일어날지 모른다.
네트워크 시스템으로 갔을 때 타임아웃 같은 새로운 실패 모드가 있었고, 재시도 같은 새로운 해결책이 있었다. 분산 데이터베이스에 도달하면 원자성과 롤백을 걱정해야 했고, 디지털 기초에서 일들이 매우 빠르게 매우 복잡해졌다.
이런 설계 패턴들 중 일부는 오늘날에도 여전히 매우 좋은 소프트웨어 아키텍처를 가지고 있지 않다. 여전히 해결할 수 없는 문제들이 있을 수 있다.
모델들은 재미있다. 온도 0에서 모델은 기술적으로 결정적이다. 같은 입력이 다른 출력을 가져온다는 것이 아니라, 그것은 우리가 선택으로 하는 것이다. 더 큰 문제는 입력의 무한소적으로 작은 변화가 임의로 큰 효과를 가질 수 있다는 것이다. 그래서 그것은 혼돈 시스템이다.
사용자가 텍스트 박스에 무엇이든 넣을 수 있고, 시스템이 충분히 혼돈적이어서 예전에는 아포스트로피만 확인하면 데이터베이스 문을 실행할 수 있었다. 텍스트 박스를 망가뜨릴 수 있는 것이 몇 개밖에 없었다. 이제는 누군가가 텍스트를 입력할 때 거의 무엇이든 일어날 수 있다.
AI의 좁은 허리와 프롬프트
인터넷 역사 전체에 있었고 네트워킹 연구의 많은 부분에서 개척자였다면, 인터넷이 어떻게 생겨났는지에 대한 좁은 허리가 있다. AI에서도 비슷한 역학이 작용한다고 생각하나?
좁은 허리는 아마 프롬프트일 것이다. 일반적으로 이런 큰 기술 사이클들은 복잡성을 매우 좁은 API로 캡슐화할 수 있게 해주는 추상화 위에 구축된다. 데이터베이스의 경우 SQL이다. 초기 데이터베이스의 트랜잭션 데이터베이스들이 SQL 쿼리 아래에서 어떻게 작동하는지, B* 트리와 관련된 무언가인데, 대학원에서 그것을 배웠지만 더 이상 중요하지 않다. 쿼리를 명시할 수 있기만 하면 된다.
현대 ML의 부상으로 이어진 것도 같은 일이라고 생각한다. 더 이상 모델을 훈련시켜주는 과도하게 비싼 스냅퍼 박사가 필요하지 않고, 대신 프롬프트로 모델을 표현하고 조종할 수 있다. 그래서 상당히 반숙련된 코파일럿 프로그래머가 갑자기 프롬프트만으로 매우 강력한 LM을 활용할 수 있다.
프롬프트를 더 자세히 보면, 원하는 것을 자연어로 표현한 것인가? 표준이 없기 때문에 프롬프트는 무엇이든 될 수 있다. 좁은 허리라고 하기에는 형식 언어도 아니고 영어도 아니다.
우리 모두 이런 것들을 프롬프트하기 위해 새로운 언어를 배우고 있고, 실제로 각 모델마다 조금씩 다르다. 방언이 있다. 번역 문제가 있다.
결론: 변화하는 개발의 미래
AI 코딩은 단순한 도구의 진화를 넘어서 개발자의 일하는 방식 자체를 근본적으로 바꾸고 있다. 우리는 Stack Overflow에서 답을 찾던 시대에서 AI와 대화하며 코드를 작성하는 시대로 넘어왔다. 이는 단순한 기술적 변화가 아니라 사고 방식의 전환이다.
가장 흥미로운 점은 AI 코딩이 기존의 개발자뿐만 아니라 완전히 새로운 개발자 집단을 만들어내고 있다는 것이다. 바이브 코더들이 전통적인 프로그래밍 교육 없이도 소프트웨어를 만들어내는 현상은 컴퓨터 과학 교육의 미래에 대한 근본적인 질문을 던진다.
하지만 동시에 우리는 새로운 도전에 직면하고 있다. AI 시스템의 비결정적 특성, 할루시네이션 문제, 그리고 복잡한 시스템에서의 디버깅 어려움 등이 그것이다. 이런 문제들은 단순히 기술적 해결책만으로는 해결되지 않을 수 있다. 우리의 기대치와 개발 방법론 자체를 바꿔야 할지도 모른다.
결국 AI 코딩의 미래는 기술과 인간의 협업이 어떻게 진화할지에 달려있다. 프롬프트가 새로운 프로그래밍 언어가 될지, 아니면 더 정교한 형식 언어가 등장할지는 아직 미지수다. 하지만 분명한 것은 우리가 소프트웨어를 만들고 생각하는 방식이 근본적으로 바뀌고 있다는 것이다.
3조 달러 규모의 시장에서 15%의 생산성 향상도 엄청난 가치를 창출할 수 있다. 하지만 진정한 가치는 숫자로 측정할 수 없는 것에 있을지도 모른다. 더 많은 사람들이 자신의 아이디어를 소프트웨어로 구현할 수 있게 되고, 개발자들이 반복적인 작업에서 벗어나 더 창의적인 문제 해결에 집중할 수 있게 되는 것 말이다.
앞으로 5년 후 컴퓨터 과학 교육이 어떤 모습일지는 아무도 모른다. 하지만 한 가지 확실한 것은 변화가 이미 시작되었다는 것이다. 우리는 그 변화의 한가운데 서 있으며, 그 방향을 함께 만들어가고 있다.