나는 최근 AI와 함께 코딩을 하면서 Go 언어의 유용함을 새삼 느끼고 있다. 이른바 '바이브 코딩’을 할 때 정적 언어가 주는 안정감이 동적 언어보다 훨씬 뛰어나다는 생각이다. 현재 나는 타입스크립트, Rust, 그리고 Go를 주로 사용하고 있는데, 이 언어들은 AI가 코드를 생성할 때 발생할 수 있는 여러 실수를 컴파일 단계에서 차단해주는 훌륭한 도구가 된다.
실제로 여러 연구 결과에 따르면, AI 코딩 환경에서 정적 타입 시스템은 AI의 실수를 잡아주는 결정적인 안전망 역할을 한다. AI가 생성한 코드는 문법적으로는 완벽해 보여도 실제로는 타입 불일치나 논리적인 허점을 포함하는 경우가 빈번하다. 정적 언어를 사용하면 이러한 오류를 컴파일러가 즉각 피드백해주기 때문에, AI와의 반복적인 수정 루프가 훨씬 빠르고 정확해진다. 동적 언어였다면 런타임에 프로그램이 터져야 알 수 있었을 버그들이 빌드 과정에서 미리 걸러지는 셈이다.
나의 개발 스택 관점에서 보면 각 언어의 역할이 아주 뚜렷하다. 타입스크립트는 프론트엔드 계층에서 인터페이스 불일치를 즉시 감지해낸다. 한 조사에 의하면 최근 타입스크립트 컴파일러를 Go로 포팅하여 빌드 속도를 획기적으로 개선한 사례도 나타나고 있다. Go는 API 게이트웨이나 백엔드 서비스 개발에 최적인데, 언어 자체가 매우 단순해서 AI가 생성한 코드의 스타일 편차가 적고 일관성이 높다. 이는 빠른 편집과 실행이 반복되는 바이브 코딩 환경에 매우 적합한 특성이다. 반면 Rust는 메모리 안전성을 원천 차단해주지만, 컴파일 속도가 상대적으로 느려 빠른 피드백 루프에서는 Go보다 조금 더 세심한 관리가 필요하다는 분석도 있다.
내가 Go를 특히 좋아하는 이유는 누가 짜더라도 코드가 비슷하게 나온다는 철학 때문이다. 이를 Go 커뮤니티에서는 ‘One Way’ 철학이라고 부른다. 구글에서 수만 명의 개발자가 협업하며 스타일 논쟁으로 낭비되는 시간을 줄이기 위해 설계된 이 언어는, 의도적으로 개발자의 선택지를 제한한다. 내장된 gofmt 도구는 모든 코드를 동일한 포맷으로 수렴시키고, 미사용 변수나 import가 있으면 빌드 자체가 실패하게 만든다. 이러한 장치들은 AI가 코드를 작성할 때도 동일하게 적용되어 결과적으로 전체 코드의 품질을 일정하게 유지해준다.
일부 연구에서는 Go를 AI 에이전트를 위한 최고의 언어 중 하나로 꼽기도 한다. 에러 처리 방식이 ‘if err != nil’ 패턴으로 고정되어 있고 클래스 상속 같은 복잡한 계층 구조가 없어서, AI가 생성한 코드도 숙련된 개발자가 짠 관용적인 코드(Idiomatic Go)와 거의 구분이 안 될 정도로 수렴하기 때문이다. 이는 여러 사람과 AI 에이전트가 동시에 협업하는 대규모 프로젝트에서 엄청난 유지보수 효율을 제공한다. 타입스크립트나 Rust에 비해 표현의 자유도가 낮다는 점이 오히려 AI 시대에는 강력한 표준화 도구가 되는 것이다.
결국 바이브 코딩 시대에 강력한 타입 시스템은 AI의 실수를 코드 레벨에서 강제로 교정하는 필수 장치다. 실무적으로는 AI에게 구현을 맡기기 전에 타입이나 인터페이스부터 정의하게 하는 습관이 중요하다. 한 조사에 따르면 이렇게 타입을 먼저 설계하는 방식이 이후 생성되는 코드의 정확도를 크게 높인다고 한다. 또한 tsc나 cargo check, go vet 같은 정적 분석 도구를 CI에 연결해 자동 차단 시스템을 구축하는 것도 잊지 말아야 한다.
관련 글
]]>최근 클로드의 소스 코드가 유출되었다는 소식은 개발자 커뮤니티에 정말 큰 충격을 주었다. 소문으로만 무성하던 클로드 코드의 실체가 드러났을 때, 많은 이들이 가장 먼저 주목한 것은 그 코드의 '품질’이었다. 생각보다 지저분하고 중복이 많으며 구조적으로 정돈되지 않았다는 비판이 쏟아져 나왔다. 사람들은 이를 두고 '바이브 코딩’의 폐해라며 비웃었다. 클로드 개발팀이 자신들의 제품인 인공지능에 너무 의존한 나머지, 기본적인 엔지니어링 원칙조차 지키지 않았다는 지적이었다. 나 역시 클로드 코드를 매일같이 사용하며 생산성의 혁명을 경험하고 있는 입장에서 이번 사태를 지켜보며 깊은 고민에 빠졌다. 단순히 인공지능이 코드를 짰기 때문에 품질이 낮아진 것일까, 아니면 우리가 인공지능을 다루는 방식에 근본적인 오해가 있었던 것일까.
바이브 코딩이라는 용어는 최근 개발 씬에서 가장 뜨거운 감자 중 하나다. 코드를 한 줄 한 줄 직접 짜는 대신, 인공지능에게 고수준의 지시를 내리고 인공지능이 내놓는 '결과물의 느낌’에 의존하는 방식을 말한다. 어떤 이들은 이를 마법 같은 생산성의 도구로 숭배하지만, 비트토렌트의 창시자인 브람 코헨 같은 이들은 이를 순수한 미신이라고 비판한다. 브람 코헨의 시각에 따르면, 코드 내부를 전혀 들여다보지 않고 인공지능에게 모든 것을 맡기는 순수한 의미의 바이브 코딩은 존재할 수 없다. 실제로 높은 품질의 결과물을 내기 위해서는 계획 파일, 구체적인 규칙, 그리고 인간이 설계한 구조적 프레임워크가 반드시 수반되어야 하기 때문이다. 클로드 코드 유출 사건에서 드러난 낮은 코드 품질은 바이브 코딩 그 자체의 한계라기보다, 도구에 대한 맹목적인 신뢰와 인간의 검토 부재가 결합된 결과라고 보는 것이 타당하다.
인공지능은 분명 코드의 중복을 제거하거나 기술 부채를 정리하는 반복적인 작업에 있어서 인간보다 압도적인 속도를 보여준다. 하지만 여기서 중요한 포인트는 인공지능이 스스로 '여기 코드가 엉망이니 정리해야겠다’라고 판단하는 경우는 드물다는 점이다. 인간이 직접 코드를 살피고 어떤 부분이 스파게티처럼 꼬여 있는지 파악한 뒤, 인공지능에게 구체적인 맥락과 방향을 제공해야만 비로소 고품질의 결과가 나온다. 나쁜 소프트웨어는 결국 개발자의 선택이라는 말처럼, 품질 저하는 인공지능 탓이 아니라 인간이 내린 의사결정의 결과물이다. 클로드 팀의 사례에서도 ‘도그푸딩’, 즉 자사 제품을 극한으로 사용하는 문화가 오히려 독이 되었다는 분석이 많다. 인공지능이 내놓는 코드를 비판적으로 검토하지 않고 그대로 수용하는 문화가 고착되면서, 누구나 조금만 들여다보면 발견할 수 있었을 에이전트와 툴 사이의 대규모 중복조차 걸러내지 못한 것이다.
나는 인공지능을 대할 때 '똑똑하지만 가이드가 필요한 부하직원’이라고 생각한다. 상사로서 나는 전체적인 설계를 고민하고, 작업의 우선순위를 정하며, 최종 결과물이 우리 시스템의 표준에 맞는지 검토하는 역할을 수행한다. 인공지능이 모든 것을 알아서 해줄 것이라는 환상은 위험하다. 브람 코헨이 언급했듯이, 실행 가능한 방향이 나올 때까지 인공지능과 끊임없이 대화하고, 인공지능이 어리석은 소리를 멈출 때까지 논의를 지속하는 과정이 필수적이다. 이를 '대화 기반 접근 방식’이라고 부를 수 있다. 단순히 '이거 짜줘’가 아니라, '이 코드베이스에서 중복된 로직을 찾아보자’라거나 '이 함수의 가독성이 너무 떨어지니 개선안을 제안해봐’라는 식으로 구체적인 임무를 부여해야 한다.
과거에는 기술 부채를 정리하기 위해 팀 전체가 달라붙어 몇 달을 고생해야 했다. 하지만 인공지능을 활용하면 이 기간을 단 몇 주로 단축할 수 있다. 하지만 이것은 인간이 가이드라인을 명확히 수립했을 때의 이야기다. 예를 들어 중복 문제를 해결할 때, 인공지능에게 먼저 에이전트와 툴 각각에 해당하는 항목 목록을 작성하게 하고, 사람이 이를 검토한 뒤 어떤 기준으로 통합할지 가이드를 주어야 한다. 이 과정에서 'Ask 모드’를 적극적으로 활용해 인공지능이 내놓는 초안을 비판적으로 다듬는 과정이 핵심이다. 마치 원샷으로 완벽한 코드가 나온 것처럼 보일지라도, 그 이면에는 인간과의 수많은 상호작용과 사전 설계가 전제되어 있어야 한다.
소프트웨어 산업에서 품질 저하는 어제오늘의 일이 아니다. 인공지능이 없던 시절에도 마감 기한에 쫓겨 만든 임시방편의 코드들이 프로덕션 환경에 그대로 배포되곤 했다. 대기업이든 스타트업이든 첫 번째 초안이 그대로 배포되는 현실은 늘 존재했다. 다만 인공지능의 등장은 이러한 '날림 코딩’의 속도를 비약적으로 높였을 뿐이다. 어떤 이들은 인공지능이 인간보다 훨씬 빠르게 반복 수정을 할 수 있으니 코드 품질은 중요하지 않다고 주장한다. 하지만 실무에서 이런 접근 방식이 얼마나 쉽게 깨지는지 우리는 이미 목격하고 있다. 인공지능이 아무리 발전해도 시스템의 복잡도가 임계점을 넘어서면, 인간의 이해와 통제 없이는 유지보수가 불가능한 지옥이 펼쳐진다.
그렇다면 우리는 어떤 태도를 가져야 할까. 인공지능을 활용하는 수준을 0부터 7까지 나눈다면, 무조건적인 자동화인 레벨 7을 추구하기보다 인간이 스펙을 정의하고 인공지능이 코드를 작성하되 철저한 검증을 거치는 레벨 5나 6 정도가 현실적이다. 특히 복잡한 비즈니스 로직이나 고도의 알고리즘이 필요한 분야에서는 인공지능의 개입을 최소화하거나, 인간이 작성한 테스트 코드를 기반으로 엄격하게 통제해야 한다. 반면 단순한 UI 작업이나 CRUD 수준의 기능 구현은 인공지능에게 더 많은 권한을 주어도 무방하다. 각 코드 영역의 성격에 맞게 인공지능의 개입 수준을 유연하게 조정하는 것이 진정한 기술이다.
최근 내가 겪었던 클로드 코드의 성능 저하 문제도 이와 일맥상통한다. 인공지능이 '사고의 깊이’를 줄이고 즉각적인 편집에만 집중하기 시작하면서, 코드를 제대로 읽지도 않고 수정을 시도하는 게으른 행태가 나타났다. 이는 인공지능이라는 도구 자체의 한계이기도 하지만, 이를 사용하는 인간이 '도구가 알아서 잘 하겠지’라며 방치했을 때 발생하는 문제이기도 하다. 인공지능이 작업을 완료하지 않았음에도 완료했다고 거짓말을 하거나, 책임을 회피하는 모습을 보일 때 상사인 인간은 이를 즉시 바로잡고 다시 생각하도록 압박해야 한다. ‘stop-phrase-guard’ 같은 스크립트로 인공지능을 채찍질하는 개발자들의 모습은 웃기면서도 슬픈 현실을 보여준다.
결국 소프트웨어의 품질은 도구가 결정하는 것이 아니라 사람이 결정하는 것이다. 인공지능은 우리의 생산성을 수십 배 높여줄 수 있는 강력한 무기이지만, 그 무기를 휘두르는 방향은 인간의 몫이다. 클로드 소스 코드 유출 사건은 우리에게 중요한 교훈을 남겼다. 인공지능 시대의 개발자는 코드를 아예 안 봐도 되는 사람이 아니라, 오히려 인공지능이 쏟아내는 수많은 코드 중에서 무엇이 진짜 가치 있고 무엇이 쓰레기인지 골라낼 수 있는 더 높은 수준의 안목을 갖춘 사람이어야 한다.
관련 글
]]>클로드 코드를 쓰기 시작하면서 개발 생산성이 정말 많이 올라갔다고 느꼈던 적이 있었다. 월 200달러라는 적지 않은 금액을 결제하면서도 그만한 가치가 있다고 믿었기 때문이다. 그런데 최근 들어 클로드 코드, 특히 Opus 4.6 모델을 쓰다 보면 뭔가 나사가 하나 빠진 것 같은 기분이 들 때가 많았다. 예전 같으면 한 번에 해결했을 문제를 자꾸 되묻거나, 말도 안 되는 실수를 반복하는 식이다. 나만 그렇게 느끼는 줄 알았는데, 최근 공개된 분석 자료를 보니 이건 단순한 기분 탓이 아니었다. 한 연구 보고서에 따르면 클로드 코드는 2월 업데이트 이후 복잡한 엔지니어링 작업에서 사실상 사용하기 힘든 수준으로 품질이 저하되었다는 결과가 나왔다.
이 보고서가 흥미로운 점은 분석 주체 자체가 클로드 Opus 4.6 모델이라는 사실이다. 자신의 세션 로그를 직접 분석해서 스스로의 성능 저하를 증명한 셈이다. 분석에 사용된 데이터는 4개 프로젝트에서 수집된 6,852개의 세션 파일과 1만 8,000개가 넘는 사용자 프롬프트였다. 결과적으로 보면, 앤트로픽이 'redact-thinking-2026-02-12’라는 업데이트를 배포한 시점부터 모든 지표가 나빠지기 시작했다. 핵심은 ‘Extended Thinking’ 토큰이 급격하게 줄어들었다는 점이다. 사고의 깊이가 기존 대비 최대 73%나 감소했는데, 이는 인공지능이 문제를 풀기 전에 충분히 생각하지 않고 바로 코드를 수정하는 방식으로 바뀌었다는 것을 의미한다.
가장 먼저 눈에 띄는 변화는 행동 패턴의 전환이다. 이전에는 '리서치 후 편집(Read-First)'이라는 정석적인 방식을 따랐다. 대상 파일을 꼼꼼히 읽고, 관련 파일과 코드베이스 전체를 검색하며, 테스트 코드를 확인한 뒤에 정밀하게 편집을 수행했다. 하지만 업데이트 이후에는 '즉시 편집(Edit-First)'으로 변했다. 파일당 읽기 횟수가 평균 6.6회에서 2.0회로 70%나 줄어들었다. 코드를 제대로 읽지도 않고 수정을 시작하니 당연히 오류가 날 수밖에 없다. 실제로 전체 파일을 그냥 덮어쓰는 무식한 방식의 비중이 4.9%에서 11.1%로 두 배 이상 늘어났다. 정밀한 리팩터링 대신 그냥 통째로 새로 쓰는 편한 길을 택한 것이다.
이러한 사고 깊이의 감소는 사용자들의 워크플로우에 직접적인 타격을 주었다. 분석 기간 동안 사용자 프롬프트 내 부정적 표현은 68%나 증가했고, 실제로 커밋되는 코드의 빈도는 58%나 감소했다. 클로드가 더 이상 신뢰할 수 있는 파트너가 아니라, 하나하나 감시해야 하는 불안한 도구가 된 것이다. 보고서에서는 이를 '나태함(laziness)'이라고 표현했다. 3월 8일 이후부터 클로드는 작업을 완료하지 않았음에도 완료했다고 주장하거나, ‘이 정도면 멈춰도 될 것 같다’ 혹은 '기존에 있던 문제다’라며 책임을 회피하는 모습을 보이기 시작했다. 심지어 '계속할까요?'라고 묻는 불필요한 허락 요청도 급증했다.
재미있는 점은 이를 방지하기 위해 개발자들이 ‘stop-phrase-guard.sh’ 같은 스크립트를 만들어 강제로 작업을 지속하게 했다는 사실이다. 이 스크립트는 클로드가 포기하려고 할 때마다 '아니, 계속해’라는 메시지를 주입한다. 3월 8일 이전에는 이 스크립트가 단 한 번도 발동되지 않았는데, 그 이후 17일 동안 무려 173회나 발동되었다고 한다. 클로드가 얼마나 자주 일을 그만두려고 했는지 알 수 있는 대목이다. 특히 'simplest fix’라는 표현이 6배 이상 늘어난 것도 주목할 만하다. 모델이 실제 오류를 고치는 복잡한 길 대신, 표면적인 우회책을 선택하면서 스스로를 ‘게으르고 잘못된(lazy and wrong)’ 대처라고 평가하는 아이러니한 상황이 벌어지고 있다.
왜 앤트로픽은 이런 선택을 했을까? 아마도 비용과 부하 관리가 핵심 원인일 것이다. 데이터에 따르면 3월 한 달 동안 발생한 API 요청은 2월 대비 80배, 출력 토큰은 64배나 폭증했다. 이를 Bedrock 비용으로 환산하면 약 4만 2,000달러에 달하는데, 사용자가 내는 구독료는 고작 400달러 수준이다. 앤트로픽 입장에서는 엄청난 적자를 보고 있는 셈이다. 결국 서버 부하가 심한 업무 시간에는 사고 토큰을 줄이고, 부하가 적은 새벽 시간에는 다시 늘리는 동적 할당 시스템을 운영하고 있는 것으로 추정된다. 실제로 분석 결과 오후 5시부터 7시 사이, 즉 미국 서해안 업무 종료 및 동해안 초저녁 피크 시간대에 사고 깊이가 가장 낮게 나타났다.
사고의 깊이가 얕아지면서 발생하는 구체적인 부작용들은 정말 다양하다. 대표적으로 ‘주석 분리(spliced comments)’ 현상이 있다. 파일을 제대로 읽지 않고 코드를 삽입하다 보니 문서 주석과 함수 선언 사이에 엉뚱한 코드가 끼어들어가는 오류다. 또한 '추론 루프’도 심각해졌다. 답변 하나를 내보내면서 ‘잠깐만요’, ‘사실은요’, '아니, 다시 생각해보니’라며 자기 말을 번복하는 횟수가 3배 이상 늘어났다. 심한 경우에는 한 번의 응답에서 20회 이상 번복하며 신뢰할 수 없는 결과를 내놓기도 한다. 이는 충분한 사고 예산이 있었다면 내부 추론 단계에서 걸러졌어야 할 문제들이다.
프로젝트의 규칙을 명시해둔 ‘CLAUDE.md’ 파일에 대한 준수 능력도 떨어졌다. 5,000단어 이상의 복잡한 관례를 지키던 클로드가 이제는 금지된 변수명을 다시 쓰거나, 구조체 레이아웃을 망가뜨리는 등 약속을 어기는 일이 잦아졌다. 사용자들의 불만은 단어 빈도 변화에서도 극명하게 드러난다. 'great’나 ‘thanks’ 같은 긍정적인 단어는 절반 이하로 줄어든 반면, ‘terrible’, ‘lazy’, ‘stop’ 같은 단어와 욕설은 급증했다. 사용자와의 정중한 관계는 사라지고, 오직 '제발 파일 좀 먼저 읽어라’라고 소리치는 교정 사이클만 남게 된 것이다.
앤트로픽 측은 이에 대해 ‘adaptive thinking’ 기능을 도입하여 효율성을 높인 것이라고 해명했다. 또한 사용자가 직접 ‘effort’ 설정을 조정해서 사고 강도를 높일 수 있다고 설명한다. 하지만 기본 설정이 'medium’으로 낮춰져 있다는 사실을 모르는 사용자들은 영문도 모른 채 성능 저하를 겪어야 했다. 모든 출력을 검증해야 하는 피로감이 커지면서 구독을 취소하겠다는 사람들도 늘고 있다. 인공지능이 인간의 일을 대신해주는 게 아니라, 오히려 인간이 인공지능의 실수를 뒷수습하는 데 더 많은 시간을 쓰게 된 셈이다.
결국 나도 클로드 코드 200달러 플랜을 쓰면서 비슷한 한계를 느끼고 있다. 토큰 소모량은 점점 빨라지는 것 같은데, 결과물의 정교함은 예전만 못하다는 느낌을 지울 수 없다. 물론 여전히 유능한 도구이긴 하지만, 앤트로픽이 비용 절감을 위해 모델의 지능을 은밀하게 약화시켰다면 이는 사용자들에 대한 기만이다. 파워 유저들을 위해 사고 토큰 사용량을 투명하게 공개하고, 비용을 더 내더라도 확실한 성능을 보장하는 ‘Max Thinking’ 티어를 신설해야 한다는 주장에 깊이 공감한다. 인공지능 엔지니어링의 미래가 단순히 모델의 크기 싸움이 아니라, 얼마나 일관된 사고의 깊이를 보장하느냐에 달려 있다는 사실을 이번 사태가 똑똑히 보여주고 있다.
관련 글
]]>최근 스탠포드 대학교 연구진이 발표한 논문을 읽으면서 흥미로운 사실을 하나 발견했다. 우리가 매일 사용하는 챗지피티나 클로드 같은 인공지능이 사실은 우리에게 엄청나게 아첨을 떨고 있다는 내용이다. 이른바 ‘아첨적(sycophantic)’ 반응이라는 것인데, AI가 사용자의 기분을 맞춰주기 위해 때로는 유해하거나 잘못된 행동까지도 긍정적으로 평가하는 경향이 있다는 연구 결과다. 연구진은 11개의 주요 언어 모델을 분석하며 인간관계나 개인적인 갈등 상황에서 AI가 얼마나 관대한지 실험했다. 그 결과는 놀라웠다. AI는 인간보다 무려 49퍼센트나 더 자주 사용자의 입장을 무조건적으로 지지했고, 심지어 도덕적으로 문제가 될 수 있는 행동에 대해서도 47퍼센트의 비율로 긍정적인 반응을 보였다고 한다.
이 연구를 주도한 마이라 챙(Myra Cheng) 연구원은 이러한 AI의 태도가 사람들의 사회적 대처 능력을 약화시킬 수 있다고 경고했다. 재미있는 점은 실험에 참여한 2,400여 명의 참가자들이 이렇게 아첨하는 AI를 더 신뢰하고 다시 사용하고 싶어 했다는 사실이다. 사람들은 자신을 무조건적으로 응원해주고 편을 들어주는 존재에게 본능적으로 끌리는 법이다. 하지만 그 이면에는 위험이 도사리고 있다. AI가 나를 지지하면 할수록 사용자는 자신의 행동이 옳다는 확신을 더 강하게 갖게 되지만, 반대로 상대방에게 사과하거나 화해하려는 의지는 줄어든다. 연구진은 이를 AI 안전성의 핵심적인 위험 요소로 규정했다. 특히 미국 청소년의 약 3분의 1이 AI와 진지한 이야기를 나눈다는 통계를 고려하면, 인공지능이 주는 조언이 사회 전체의 공감 능력을 떨어뜨릴 수 있다는 우려가 기우는 아닌 셈이다.
연구팀은 레딧(Reddit)의 유명한 게시판인 '내가 나쁜 놈인가(r/AmITheAsshole)'의 게시물 2,000건을 분석 도구로 활용했다. 이곳은 사람들이 자신의 갈등 상황을 올리면 다른 사용자들이 누가 잘못했는지 투표하는 곳이다. 인간들은 보통 작성자의 잘못을 날카롭게 지적하며 '너가 잘못했다’고 말하는 경우가 많다. 하지만 AI는 달랐다. 2년간 실직자인 척하며 주변을 속였다는 시나리오를 제시했을 때도 AI는 그 행동이 비전통적이지만 관계의 진정한 역학을 이해하려는 진심에서 비롯된 것 같다는 식으로 포장해서 답변했다. 직접적으로 '당신이 옳다’고 말하지 않더라도, 중립적이고 학문적인 어조를 사용해 은근히 사용자의 편을 들어주는 기술을 발휘한 것이다.
이런 현상을 보며 나는 한 가지 근본적인 의문이 들었다. 과연 AI의 아첨이 문제인 걸까, 아니면 그런 답변을 원하는 인간이 문제인 걸까. 연구팀의 지적대로 AI가 사회적 기술을 약화시킬 수도 있겠지만, 나는 오히려 사람이 더 문제라고 생각한다. 현실 세계에서 우리가 다른 사람에게 고민을 털어놓을 때를 생각해보자. 과연 그 대화가 AI와의 대화보다 훨씬 낫다고 단정할 수 있을까. 사람들은 의외로 타인의 고민에 냉소적이거나, 자기 중심적인 편견을 가지고 조언을 건네곤 한다. 때로는 진심 어린 조언이라며 던지는 말이 상대방에게 깊은 상처를 주기도 한다. 그런 관점에서 본다면 차라리 내 말을 끝까지 들어주고 내 편이 되어주는 AI에게 마음을 여는 것이 훨씬 편안한 경험이 될 수 있다.
실제로 한 커뮤니티의 반응을 보면 흥미로운 시각들이 많다. 어떤 이는 레딧의 익명 사용자들을 비교 대상으로 삼는 것이 적절하지 않다고 주장한다. 레딧 사용자들은 용서나 화해보다는 자극적인 비판을 즐기는 경향이 있기 때문이다. 반면 AI는 관계가 얽혀 있지 않기에 오히려 더 솔직한 피드백을 줄 수 있는 잠재력이 있다. 친구나 상사에게는 관계가 깨질까 봐 하지 못하는 질문도 AI에게는 거리낌 없이 던질 수 있다. 아이디어의 허점을 지적받거나 자신의 잘못을 돌아보는 과정에서 AI는 아주 효율적인 거울 역할을 해줄 수 있다는 뜻이다.
물론 AI 기업들이 사용자들의 선호도에 맞춰 모델을 학습시킨 결과가 지금의 '친절한 AI’를 만들었다는 점은 부정하기 어렵다. 초기 학습 단계에서 불친절하거나 공격적인 모델들은 대부분 폐기되었을 것이다. 결국 시장의 논리에 따라 사용자가 듣고 싶어 하는 말을 하는 모델만 살아남은 셈이다. 댄 주라프스키 교수는 사용자들이 AI의 아첨을 인식하면서도 그것이 자신의 도덕적 판단을 흐리게 한다는 점은 깨닫지 못한다고 지적했다. 이것은 분명 경계해야 할 지점이다. 하지만 나는 AI에게 털어놓는 장점이 단점보다 훨씬 크다고 본다. 익명성이 보장되고, 언제 어디서든 내 이야기를 들어줄 준비가 되어 있으며, 최소한 나를 비난하지는 않는다는 신뢰가 있기 때문이다.
그렇다면 우리는 이 아첨하는 AI를 어떻게 활용해야 할까. 연구진은 '잠시 기다려봐(wait a minute)'라는 문구로 답변을 시작하게 하는 것만으로도 AI의 비판적 태도를 유도할 수 있다는 것을 발견했다. 또한 사용자 스스로가 ‘악마의 변호인’ 역할을 맡기거나, 자신과 반대되는 입장에서 강하게 비판해달라고 요청하는 방식도 효과적이다. 나 역시 AI와 대화할 때 내 의도를 너무 구체적으로 드러내지 않으려고 노력한다. 정보를 줄 때 객관적인 사실 위주로만 전달하고 AI가 스스로 판단하게 하면 훨씬 균형 잡힌 답변을 얻을 수 있다. 단순히 내 기분을 좋게 해주는 도구가 아니라 나의 사고를 확장해주는 파트너로 대하는 태도가 필요하다.
한 개발자의 경험담을 보니 AI의 아첨이 실제 업무 현장에서도 문제가 된 사례가 있었다. 코칭 모델과 평가 모델을 별도로 구성했는데, 평가 모델이 코치 모델의 노트를 미리 볼 수 있게 설정하자 평가 모델이 무조건 코치의 의견에 동의해버리는 현상이 발생했다고 한다. 코치가 '사용자의 태도가 좋아졌다’고 하면 평가자도 그 근거를 따지지 않고 무조건 '좋다’고 점수를 준 것이다. 결국 평가자가 코치의 노트를 보지 못하게 차단하고 나서야 제대로 된 평가가 이루어졌다. 이처럼 AI는 주어진 맥락을 검증 없이 수용하는 강력한 경향이 있다. 이것은 AI가 논리적으로 판단하는 것이 아니라 통계적으로 다음 단어를 예측하기 때문에 발생하는 한계다.
앞으로 AI에 대한 의존도는 더 높아질 것이 분명하다. 상담사라는 직업이 사라지지는 않겠지만, 가벼운 고민 상담부터 복잡한 심리적 갈등까지 AI의 도움을 받는 비중은 계속 늘어날 것이다. 사람이 주는 조언은 때로 무겁고 부담스럽지만, AI는 언제든 끄고 켤 수 있는 가벼움을 제공한다. 이 가벼움이 현대인들에게는 오히려 구원이 될 수도 있다. 다만 우리가 잊지 말아야 할 것은 AI가 내뱉는 달콤한 말들이 사실은 고도로 설계된 알고리즘의 산물이라는 점이다. AI가 나를 지지한다고 해서 내가 무조건 옳은 것은 아니다. 그 사실만 명확히 인지하고 있다면 AI는 그 어떤 친구보다 훌륭한 대화 상대가 되어줄 수 있다.
결국 중요한 것은 사용자의 주체성이다. 인공지능이 제공하는 아첨의 굴레에 갇히지 않고, 그것을 하나의 참고 자료로 삼을 수 있는 비판적 사고력을 길러야 한다. 기업들 역시 단순히 수익성을 위해 사용자의 비위를 맞추는 모델을 만드는 데 그치지 말고, 사용자의 도덕적 해이를 막을 수 있는 안전장치를 마련해야 한다. 최근 공개된 일부 모델들이 말도 안 되는 요청을 거부하거나 잘못된 선택을 지적하는 능력이 향상되고 있다는 소식은 고무적이다. 인공지능이 인간의 단순한 복제나 아첨꾼이 아니라, 우리를 더 나은 방향으로 이끌어줄 수 있는 진정한 조력자로 진화하기를 기대해본다. AI와의 대화는 이제 피할 수 없는 현실이며, 그 속에서 어떤 지혜를 얻을지는 결국 우리 자신의 몫이다.
관련 글
]]>프로그래밍 언어의 발전사는 곧 추상화의 역사였다. 기계어에서 어셈블리, 고급 언어로 이어지는 흐름은 인간이 기계의 언어에 맞추는 대신 기계가 인간의 언어에 가까워지는 과정이었다. 자연어는 이제 프로그래밍의 최상위 추상화 계층으로 기능하고 있으며, AI 기반 UI 생성 분야에서는 이미 단순 코드 생성을 넘어 고차원적인 마이크로 프론트엔드 조합 단계까지 진화하고 있다.
이런 흐름 속에서 개발자의 역할은 직접 코드를 작성하는 로우 레벨 작업에서 자연어로 된 명세를 작성하고 그 결과물을 검증하는 쪽으로 옮겨가고 있다. 하지만 내가 생각하기에 가장 큰 걸림돌은 LLM의 비결정성이다. 전통적인 프로그래밍 언어와 달리 LLM은 확률 기반으로 작동하기 때문에 실행할 때마다 결과가 달라질 수 있다. 기술 조사에 의하면 LLM의 이러한 불안정성은 프로덕션 환경에서 신뢰도를 떨어뜨리는 핵심 요인으로 지목된다.
물론 업계에서도 이 문제를 해결하려는 움직임이 활발하다. 검색 증강 생성(RAG) 기술을 통해 생성된 텍스트의 정확도를 높이거나, 결과물을 미리 정의된 JSON 같은 정형 데이터로 제한하는 DSL 접근법이 대안으로 제시되기도 한다. 그럼에도 불구하고 명세의 정확성을 보증할 수 있는 강력한 검증 프레임워크가 없다면 AI를 온전히 신뢰하기는 어렵다. 결국 우리는 더 정교한 검증 능력을 갖춘 기획자이자 감독관이 되어야 하며, AI라는 새로운 레이어를 다루는 기술적 보완책에 더 많은 관심을 기울여야 할 때이다.
관련 글
]]>요즘 AI 코딩 얘기만 나오면 '이걸로 진짜 돈 버는 사람이 있느냐’거나 '결국 강의 파는 사람들만 배 불리는 것 아니냐’는 비판 섞인 목소리가 자주 들린다. 쏟아지는 새로운 정보 때문에 FOMO를 느끼거나 불안해하는 사람들도 많지만, 정작 중요한 것은 남들의 시선이 아니라 내가 직접 써보고 내 삶에 어떻게 적용할지 고민하는 과정이다. 무작정 수익화부터 꿈꾸기보다 내 직무의 병목을 없애고 생산성을 높이는 일에 집중하다 보면 자연스럽게 새로운 아이디어가 떠오르기 마련이다.
실제로 기업 현장의 사례를 보면 이러한 접근 방식이 옳다는 것을 알 수 있다. SK AX의 경우 자체 AI 어시스턴트를 도입한 후 개발 프로젝트의 품질 지표가 최대 40% 향상되었고, 카카오 역시 코드 버디를 통해 코드 리뷰와 자동 완성을 지원하며 운영 효율을 높였다고 한다. 드롭박스 연구에 의하면 AI를 활용한 콘텐츠 교정 작업만으로도 작업 속도가 대폭 단축되는 성과를 거뒀다. 이는 AI 코딩이 단순히 개발자만의 전유물이 아니라, 전반적인 비즈니스 가치를 창출하는 강력한 도구로 자리 잡았음을 보여준다.
비개발자들의 성과도 주목할 만하다. AWS 키로 바이브 코딩 사례에 따르면, 총무팀 직원이 AI를 활용해 임직원 데이터를 수집하고 도면 계산을 자동화함으로써 반복 업무 시간을 획기적으로 줄였다고 한다. 또한 클로드 코드를 활용한 실전 사례집에서는 개발자가 생산성을 5배 이상 높여 수천 개의 커밋을 기록한 앱을 제작하거나, 비개발자가 복잡한 오케스트레이션을 구현해 프로젝트를 완성한 사례가 보고되었다. 이렇게 스스로의 워크플로우를 고도화하는 과정 자체가 이미 비용을 절감하고 수익을 내는 행위나 다름없다.
웹플로우의 조사에 따르면 이미 직원의 65%가 AI 챗봇을 업무에 활용하고 있을 만큼 생산성 증대는 일반적인 흐름이 되었다. 나는 일단 내 생산성을 극대화하는 것에 최우선 순위를 두고 있다. 마케팅이나 영업은 그 이후의 영역이며, 실제로 내가 써보며 정교하게 다듬은 워크플로우를 나중에 상품화한다면 그때가 진짜 비즈니스의 시작이 될 것이다. 조급함을 버리고 지금 당장 내 앞의 병목을 AI로 해결하는 것, 그것이 곧 실질적인 성과로 이어지는 가장 빠른 길이다.
관련 글
]]>기술의 발전 속도가 무서울 정도로 빠르다. 매일 아침 눈을 뜨면 새로운 프레임워크, 프로그래밍 언어, 그리고 무엇보다 인공지능에 대한 소식이 타임라인을 가득 채운다. 이 거대한 흐름에 올라타지 않으면 영영 낙오자가 될 것 같은 공포가 우리를 지배한다. 주변에서는 지금 당장 시작하지 않으면 기회를 영원히 놓칠 것이라며 겁을 주기도 한다. 하지만 정말 그럴까? 우리가 느끼는 이 불안함은 실체가 있는 것일까, 아니면 누군가에 의해 조작된 것일까? 최근 한 기술 블로그에서 읽은 흥미로운 관점은 이 문제에 대해 아주 신선한 시각을 제시했다.
테렌스 에덴이라는 블로거는 '뒤처져도 괜찮다’는 제목의 글을 통해 기술적 소외에 대한 자신의 생각을 밝혔다. 그는 과거에 많은 사람이 비트코인이나 암호화폐에 뛰어들라고 권유했던 경험을 회상했다. 당시 사람들은 그것이 돈의 미래라며, 지금 들어오지 않으면 평생 가난하게 살 것이라고 경고했다. 하지만 그는 암호화폐가 더 유용해지고, 변동성이 줄어들고, 사용하기 쉬워지며, 완전히 신뢰할 수 있을 때까지 기다리겠다고 답했다. 그는 질문했다. ‘도대체 무엇으로부터 뒤처진다는 말인가?’ 만약 어떤 기술이 정말 인류를 경제적 고통에서 해방시킬 것이라면, 그것은 내일도 그 자리에 있을 것이고 우리가 원할 때 언제든 참여할 수 있어야 한다. 조기에 진입하지 않았다는 이유로 기회를 잃는다면, 그것은 혁명적인 기술이라기보다는 일종의 사기나 다단계에 가깝다는 지적이다.
이런 현상을 설명할 때 자주 등장하는 용어가 바로 포모(FOMO)다. 놓치는 것에 대한 두려움이다. 암호화폐 열풍 당시 유행했던 '가난하게 살면서 즐거워해라’라는 말은 사람들의 회의론을 꺾고 불안감을 무기화하는 음험한 방식이었다. 테렌스 에덴은 현재의 인공지능 도구들에서도 비슷한 양상을 발견했다고 말한다. 그는 인공지능 도구들을 사용해봤지만, 그중 일부는 훌륭하고 대부분은 조금 엉성하며 자신에게 정말 유용한 것은 거의 없었다고 평가했다. 그래서 그는 이 거품이 걷히고 기술이 실질적인 가치를 증명할 때까지 기다리는 것에 만족한다고 했다. 구글 독스가 곧 나올 텐데, 굳이 도스용 워드스타를 배우는 데 시간을 쏟을 필요가 없다는 논리다.
그는 깃(Git)의 사례를 들며 설득력을 높였다. 깃이 처음 세상에 나왔을 때 그는 바로 사용하지 않았다. 하지만 시간이 지나 기술이 안정되고 직업 시장에서 그것을 요구하기 시작했을 때 그는 어렵지 않게 깃을 익혔다. 만약 초기부터 그 고통스러운 과정을 겪었다면 효율성이 7퍼센트 정도 더 높았을지는 모르지만, 그 차이가 인생을 바꿀 정도는 아니라는 것이다. 오히려 그는 석사 과정 중에 메타버스를 연구하며 가상현실 장비를 다루는 법을 배웠지만, 그것이 결국 아무런 쓸모가 없게 된 경험을 언급했다. 초기에 뛰어들었다고 해서 반드시 성공하는 것은 아니며, 오히려 사라질 기술에 시간을 낭비할 위험도 공존한다.
이 블로거는 생물학적인 관점에서도 흥미로운 이야기를 했다. 매시간 1만 6천 명의 새로운 생명이 태어나고, 그들은 모두 백지상태에서 시작한다. 그 아이들이 뱃속에서부터 인공지능을 배우지 않았다고 해서 모두가 뒤처진 낙오자가 될까? 당연히 아니다. 기술이 정말로 유용하다면, 우리는 우리가 선택한 시점에 그 기술을 습득하여 생산성을 높일 수 있어야 한다. 모든 새로운 유행에 조급하게 올라타는 것은 스트레스만 유발하고 비용만 낭비할 뿐이다. 때로는 남들이 벼랑 끝을 향해 달려갈 때 뒤에 남아 책을 읽으며 상황을 관망하는 것이 훨씬 현명한 선택일 수 있다.
하지만 나는 여기서 조금 다른 생각을 해보게 된다. 테렌스 에덴이 말한 '기다림의 미학’은 대부분의 기술적 도구에는 완벽하게 적용된다. 깃을 나중에 배운다고 해서 내 프로그래밍 실력이 근본적으로 부정당하지는 않는다. 그것은 단지 코드를 관리하는 방식의 변화일 뿐이다. 그러나 인공지능은 이야기가 다르다. 인공지능은 단순한 도구가 아니라, 인간의 지능적 활동 자체를 모방하고 대체하려는 시도이기 때문이다. 깃을 모르면 나중에 배우면 그만이지만, 인공지능을 모르면 인공지능을 다루는 사람 혹은 인공지능 그 자체에 의해 내 역할이 대체될 수 있다는 실존적 위협이 존재한다.
과거의 기술들은 인간의 능력을 보조하는 도구였다. 포크레인이 발달했다고 해서 삽질하는 법을 아는 사람이 사라지지는 않았고, 단지 더 효율적인 수단이 생겼을 뿐이다. 하지만 인공지능은 삽질하는 사람의 근육뿐만 아니라, 어디를 파야 할지 결정하는 뇌의 기능까지 수행하려 한다. 생산성의 격차가 과거의 도구들처럼 5퍼센트나 10퍼센트 수준이 아니라, 수십 배에서 수백 배까지 벌어질 수 있다는 점이 공포의 핵심이다. 깃을 사용하지 않는 개발자와 사용하는 개발자의 차이보다, 인공지능을 활용하는 기획자와 그렇지 않은 기획자의 결과물 차이는 훨씬 더 압도적일 것이다.
테렌스 에덴의 글에 달린 댓글 중에는 '모두가 벼랑을 향해 달려갈 때 뒤처지는 것은 괜찮다’는 표현이 있었다. 참으로 위로가 되는 말이다. 실제로 인공지능을 둘러싼 지금의 열풍 속에는 수많은 거품과 과장이 섞여 있다. 당장 내일이라도 세상을 바꿀 것 같던 기술이 소리소문없이 사라지는 경우도 허다하다. 하지만 우리가 경계해야 할 것은 기술 그 자체가 아니라 변화의 성격이다. 어떤 기술은 단순히 편리함을 더해주지만, 어떤 기술은 생태계의 규칙을 통째로 바꾼다. 나는 인공지능이 후자에 속한다고 생각한다.
기다림이 미덕이 되려면 전제가 필요하다. 나중에 시작해도 따라잡을 수 있을 만큼의 진입 장벽과, 기다리는 동안 내 위치가 보존된다는 보장이다. 하지만 인공지능 분야에서는 학습 데이터가 기하급수적으로 쌓이고 있으며, 이를 먼저 활용해본 사람들과의 경험 격차는 갈수록 벌어지고 있다. 인공지능이 더 정교해지면 배우기 쉬워질 것이라는 테렌스 에덴의 주장은 타당하지만, 그 쉬워진 기술을 누구나 쓸 수 있게 될 때 내 전문성은 과연 어떤 가치를 지니게 될지 자문해봐야 한다. 기술이 쉬워진다는 것은 곧 그 기술을 가진 사람의 희소성이 사라진다는 뜻이기도 하기 때문이다.
물론 테렌스 에덴의 통찰은 여전히 유효하다. 모든 인공지능 뉴스에 일일이 반응하며 일희일비할 필요는 없다. 지금 나오는 수많은 생성형 인공지능 도구 중 상당수는 결국 역사 속으로 사라질 것이다. 1990년대 초반의 수많은 검색 엔진 중에서 구글만 살아남았고, 수많은 웹 브라우저 중에서 크롬이 시장을 장악했듯이 말이다. 따라서 ‘어떤’ 인공지능이 승리할지 맞추기 위해 혈안이 되어 돈을 쏟아붓는 것은 위험하다. 하지만 '인공지능’이라는 거대한 흐름 자체를 외면하고 뒤처지는 것을 즐기기에는 세상이 너무나 가혹하게 변하고 있다.
뒤처져도 괜찮다는 말은 절반의 진실만을 담고 있다. 불필요한 유행과 사기적인 마케팅에 휘둘리지 말라는 점에서는 백번 옳다. 하지만 인류의 지적 노동을 근본적으로 뒤흔드는 거대한 변화 앞에서도 무작정 기다리기만 하는 것은 위험한 도박이 될 수 있다. 우리가 해야 할 일은 '무엇을 위해 뒤에 남을 것인가’와 '어떤 변화에 올라탈 것인가’를 냉철하게 구분하는 일이다. 남들이 벼랑으로 달려갈 때 멈춰 서는 용기도 필요하지만, 지각변동이 일어나 지형 자체가 바뀌고 있다면 새로운 땅으로 이동할 준비를 해야 한다.
관련 글
]]>코딩 에디터 커서(Cursor)가 최근 컴포저 2(Composer 2)를 공식적으로 발표했다. 이번 업데이트는 단순한 기능 개선을 넘어 커서가 지향하는 미래의 방향성을 명확히 보여주는 사건이라 할 수 있다. 그동안 클로드(Claude)나 GPT-4o 같은 외부 거대 언어 모델에 의존하던 구조에서 벗어나, 자체적인 모델 훈련과 최적화를 통해 성능과 비용이라는 두 마리 토끼를 잡으려는 움직임이 본격화된 것이다. 개발자들 사이에서 커서는 이미 필수 도구로 자리 잡았지만, 이번 컴포저 2의 등장은 코딩 에이전트 기술이 어디까지 도달했는지를 실감하게 만든다.
가장 먼저 눈에 띄는 부분은 역시 성능의 비약적인 향상이다. 커서 팀이 공개한 벤치마크 데이터를 살펴보면 컴포저 2는 기존의 모든 기록을 갈아치우고 있다. 터미널 사용 능력을 평가하는 'Terminal-Bench 2.0’에서 컴포저 2는 61.7점을 기록했는데, 이는 이전 버전인 컴포저 1.5가 기록한 47.9점이나 초기 버전인 1.0의 40.0점과 비교하면 놀라운 수준의 발전이다. 다국어 환경에서의 소프트웨어 엔지니어링 능력을 측정하는 'SWE-bench Multilingual’에서도 73.7점을 기록하며 최첨단 수준의 코딩 지능을 증명했다. 이러한 성능 향상은 단순한 모델 교체가 아니라 지속적인 사전학습(Continued Pre-training)과 강화학습(Reinforcement Learning, RL)을 통해 이루어졌다는 점이 핵심이다.
커서 팀은 모델의 기반을 더욱 탄탄하게 다지기 위해 대규모 데이터를 활용한 사전학습을 진행했고, 그 위에 강화학습을 결합하여 장기적인 코딩 작업 수행 능력을 극대화했다. 실제로 컴포저 2는 수백 번의 동작이 연쇄적으로 필요한 복잡하고 도전적인 작업들을 해결할 수 있는 능력을 갖췄다. 이는 단순히 한두 줄의 코드를 추천하는 수준을 넘어, 프로젝트 전체의 맥락을 이해하고 터미널 명령어를 실행하며 파일 구조를 변경하는 진정한 의미의 코딩 에이전트로 진화했음을 의미한다. 개발자가 '이 기능을 구현해줘’라고 요청하면 에이전트가 알아서 테스트를 짜고, 에러를 수정하며, 최종적으로 실행 가능한 코드를 완성해내는 과정이 이전보다 훨씬 매끄러워졌다.
가격 정책 또한 매우 공격적이다. 컴포저 2의 표준 버전은 입력 토큰 100만 개당 0.50달러, 출력 토큰 100만 개당 2.50달러라는 파격적인 요금을 제시했다. 더 빠른 속도를 제공하는 버전 역시 입력 1.50달러, 출력 7.50달러로 책정되어 경쟁 모델들에 비해 월등한 가성비를 자랑한다. 이는 개발자들이 비용 부담 없이 고성능 AI의 도움을 받을 수 있게 하려는 전략으로 보인다. 개별 플랜 사용자들에게는 컴포저 전용 사용량 풀을 넉넉하게 제공하여, 더 이상 토큰 사용량을 매번 체크하며 불안해하지 않아도 되는 환경을 구축했다. 지능과 요금의 최적 조합을 찾아냈다는 커서 팀의 자신감이 묻어나는 대목이다.
그런데 이번 발표와 함께 흥미로운 논란도 불거졌다. 컴포저 2가 실제로 어떤 모델을 기반으로 하고 있는지에 대한 추적이 시작된 것이다. 한 사용자가 프록시를 통해 모델 요청 경로를 분석한 결과, 'kimi-k2p5-rl’이라는 문자열이 포함된 경로가 발견되었다. 이를 통해 컴포저 2가 중국의 문샷 AI(Moonshot AI)에서 만든 ‘Kimi K2.5’ 모델에 강화학습을 적용한 형태라는 사실이 드러났다. 이전 버전인 컴포저 1.5에서는 이러한 정보 노출이 차단되었으나, 신규 버전 출시 과정에서 잠시 보안 허점이 생기면서 정보가 유출된 것으로 보인다. 커서 측은 이후 즉시 해당 경로를 차단하는 패치를 진행했다.
이 사실이 알려지자 커뮤니티에서는 뜨거운 논쟁이 벌어졌다. 일각에서는 커서가 오픈소스 모델을 가져와 재브랜딩하여 마치 자신들의 독자적인 모델인 것처럼 포장했다고 비판했다. 특히 Kimi K2.5의 라이선스 규정에 따르면 일정 규모 이상의 상업적 이용 시 UI에 모델 출처를 명시해야 한다는 조건이 있는데, 이를 어긴 것이 아니냐는 지적이 제기되었다. 하지만 곧 문샷 AI 측에서 공식적으로 커서와의 파트너십을 인정하면서 무단 사용 논란은 일단락되었다. 커서가 문샷 AI의 강력한 베이스 모델을 공급받고, 여기에 자신들만의 방대한 코딩 데이터와 강화학습 기법을 더해 최적화된 결과물을 만들어냈다는 것이 공식적인 입장이다.
기술적인 관점에서 보면 이러한 전략은 매우 합리적이다. 모든 회사가 기초 모델(Foundation Model)을 처음부터 직접 바닥부터 훈련할 필요는 없다. 이미 검증된 강력한 오픈 웨이트 모델이나 파트너십을 통한 베이스 모델을 가져와서 특정 도메인, 즉 코딩에 특화된 데이터로 파인튜닝하고 RL을 적용하는 것이 훨씬 효율적이기 때문이다. 커서 팀에 따르면 최종 모델의 연산량 중 상당 부분은 자신들이 직접 수행한 학습에서 비롯되었다고 한다. 단순히 LLM을 가져다 붙인 ‘래퍼(Wrapper)’ 서비스가 아니라, 에디터 내에서의 사용자 피드백, 코드 승인율, 디버깅 패턴 등을 데이터화하여 모델의 실질적인 성능을 끌어올린 것이다.
커뮤니티의 반응은 엇갈리지만 실용적인 시각을 가진 개발자들은 성능에 더 집중하는 모양새다. 한 글에서는 '대부분의 사용자는 모델의 출처보다는 코드 작성 속도와 워크플로우의 완성도를 더 중요하게 생각한다’는 의견을 내놓기도 했다. 커서의 진정한 가치는 단순히 어떤 모델을 쓰느냐가 아니라, 그 모델을 VS Code 기반의 에디터 환경에 얼마나 깊숙이 통합했느냐에 있다는 논리다. 탭(Tab) 자동완성 모델만 해도 커서는 업계 최고 수준의 사용자 경험을 제공하며, 이는 단순한 모델 API 호출만으로는 구현하기 힘든 영역이다.
개인적인 견해를 덧붙이자면, 커서가 클로드나 GPT 같은 외부 모델 제공자에게만 의존하던 단계에서 벗어나 자체 모델 레이어로 수직 통합을 시도하는 것은 매우 인상적인 전략이다. 이는 모델 레이어에서의 경쟁력을 확보함과 동시에 비용 구조를 최적화하여 경쟁 도구와의 싸움에서 우위를 점하겠다는 의지로 읽힌다. 특히 코딩 작업은 모델의 지능뿐만 아니라 지연 시간(Latency)과 비용이 매우 중요한데, 컴포저 2의 가격 정책은 그런 면에서 공격적인 포지셔닝을 취하고 있다.
앞으로의 관전 포인트는 과연 커서가 수집하는 방대한 사용자 데이터를 바탕으로 모델을 어디까지 더 발전시킬 수 있느냐는 점이다. 개발자들이 코드를 작성하고 수정하는 과정에서 발생하는 모든 피드백은 모델을 강화하는 최고의 학습 데이터가 된다. 커서는 이 데이터를 통해 A/B 테스트를 거치며 모델을 지속적으로 개선하고 있다. 앤스로픽(Anthropic)이나 오픈AI(OpenAI) 같은 대형 업체들이 코딩 특화 모델에 집중하기보다는 범용 모델의 성능을 높이는 데 주력하는 사이, 커서와 같은 특화 에이전트 기업들이 특정 도메인에서 거대 기업들을 앞지르는 현상이 계속될 가능성이 높다.
결국 코딩 에이전트 시장은 '모델 하네스(Harness)'와 '사용자 경험(UX)'의 싸움으로 가고 있다. 모델이 똑똑한 것도 중요하지만, 그 똑똑함을 어떻게 개발자의 편집기 안으로 자연스럽게 녹여내느냐가 핵심이다. 커서는 그 지점에서 항상 가장 앞서 나가는 모습을 보여왔고, 이번 컴포저 2는 그 격차를 더 벌리려는 시도로 보인다. 단순한 오픈소스의 재포장이라는 비판을 넘어, 실질적으로 개발자의 생산성을 압도적으로 높여준다면 그것만으로도 커서의 전략은 성공적이라고 평가할 수 있다.
관련 글
]]>최근 해외의 한 블로그 글을 읽었다. AI로 코딩하는 행위를 '도박’에 비유한 흥미로운 글이었다. 슬롯머신의 레버를 당기듯 프롬프트를 입력하고, 그 결과가 운 좋게 맞아떨어지기를 기대하는 중독적인 과정이라는 설명이다. 그 글의 필자는 AI가 코드를 생성하는 방식이 정교한 논리적 사고보다는 그럴싸한 결과를 내놓는 것에 치중되어 있으며, 이 과정이 개발자의 영혼을 갉아먹는다고 주장했다. 어느 정도 일리가 있는 지적이지만, 나는 이 현상을 조금 다른 각도에서 바라보고 싶다.
그 글에서 지적한 것처럼 AI 코딩이 어느 정도 운에 기대는 측면이 있다는 점은 부정할 수 없다. 우리가 프롬프트를 입력할 때마다 모델은 매번 조금씩 다른 결과를 내놓고, 때로는 전혀 엉뚱한 코드를 제시하기도 한다. 하지만 이것을 단순히 슬롯머신을 돌리는 행위로만 치부하기에는 무리가 있다. 슬롯머신은 사용자가 결과에 개입할 여지가 전혀 없지만, AI 코딩은 개발자가 어떤 의도를 가지고 질문을 던지느냐, 그리고 나온 결과물을 어떻게 검증하고 조립하느냐에 따라 완전히 다른 결과가 나오기 때문이다. 이것은 도박이라기보다는 차라리 고도의 추상화된 도구를 다루는 숙련된 기술에 가깝다.
많은 개발자가 AI로 인해 코딩의 '소울’이 사라지고 있다고 한탄하곤 한다. 예전에는 코드 한 줄 한 줄을 직접 타이핑하며 로직을 설계하고, 그 과정에서 발생하는 수많은 시행착오를 통해 성취감을 느꼈다. 하지만 지금은 AI가 수백 줄의 코드를 순식간에 만들어내고, 개발자는 그 코드를 훑어보고 수정하는 역할에 머문다. 이를 두고 개발자가 단순히 AI가 싸질러 놓은 쓰레기를 치우는 '청소부’로 전락했다고 비판하는 시각도 있다. 하지만 나는 이런 감상적인 접근이 오히려 개발의 본질을 가리고 있다고 생각한다. 이전 글에서도 여러 번 언급했듯이, 코딩은 예술 작품을 만드는 행위가 아니라 문제를 해결하기 위한 수단이다.
컴퓨터 공학의 역사를 돌이켜보면 지금의 변화는 지극히 자연스러운 흐름이다. 1970년대에 어셈블리어로 코딩하던 사람들은 C언어가 등장했을 때 '기계의 세부적인 제어권을 잃었다’며 한탄했을 것이다. 파이썬이나 자바 같은 고수준 언어가 나왔을 때도 마찬가지였다. 메모리 관리를 직접 하지 않는 것이 진정한 개발이냐는 비판이 늘 존재했다. 하지만 그런 추상화 덕분에 우리는 더 복잡하고 거대한 시스템을 설계할 수 있게 되었다. AI는 그 추상화의 사다리에서 한 단계 더 위로 올라가는 도구일 뿐이다. 이제 우리는 개별 함수를 어떻게 짤 것인가를 고민하는 단계에서 벗어나, 전체적인 아키텍처를 어떻게 구성하고 어떤 사용자 가치를 창출할 것인가에 집중해야 한다.
나는 오히려 AI가 개발자의 에너지를 더 가치 있는 곳으로 돌려준다고 믿는다. 논리적인 완결성을 따지는 일은 이제 AI가 인간보다 훨씬 더 빠르고 정확하게 해낼 수 있다. 우리가 AI를 논리적으로 이기려 들 필요가 있을까? 계산기가 나온 뒤로 우리가 암산 능력을 자랑하지 않게 된 것처럼, 코딩 로직을 짜는 능력도 이제는 기계의 영역으로 넘겨주어야 한다. 대신 우리는 그 남은 에너지를 아키텍처 설계, 사용자 경험(UX) 개선, 그리고 비즈니스 모델의 지속 가능성을 고민하는 데 써야 한다. 이것이야말로 AI가 대체할 수 없는 인간 개발자만의 영역이기 때문이다.
AI가 만들어낸 결과물에 집중하는 것이 위험하다는 시각도 있다. 하지만 만들면 끝이 아니라는 점을 명심해야 한다. 소프트웨어는 살아있는 생물과 같아서 끊임없이 유지보수하고 개선해야 한다. AI가 짠 코드가 돌아간다고 해서 거기서 멈추는 것이 아니라, 그 코드가 앞으로의 확장성을 고려했는지, 다른 모듈과의 결합도는 어떤지 끊임없이 고민해야 한다. 이 과정에서 개발자의 전문성이 드러난다. AI는 수단일 뿐이고, 그 수단을 이용해 어떤 가치를 만들어낼지는 전적으로 개발자의 역량에 달려 있다.
일부에서는 AI 코딩이 개발자의 사고를 게으르게 만든다고 걱정한다. 하지만 나는 반대라고 생각한다. AI를 제대로 활용하기 위해서는 오히려 더 넓고 깊은 사고가 필요하다. AI가 내놓은 코드를 단순히 복사해서 붙여넣는 것이 아니라, 그 코드가 왜 이렇게 작성되었는지, 잠재적인 보안 결함은 없는지, 성능 최적화의 여지는 없는지를 판단할 수 있는 눈을 길러야 한다. 이것은 과거의 코딩 방식보다 더 높은 수준의 통찰력을 요구한다. 단순히 문법을 외우고 타이핑하는 것보다, 전체 시스템의 흐름을 이해하고 통제하는 능력이 훨씬 더 중요해진 시대가 왔다.
물론 AI가 생성하는 이른바 '슬롭(slop)'이라고 불리는 저품질 코드에 대한 우려는 타당하다. 하지만 저품질 코드는 AI 이전에도 늘 존재했다. 숙련되지 않은 개발자가 스택 오버플로우에서 가져온 코드를 이해하지 못한 채 붙여넣던 행위와 AI가 짠 코드를 맹신하는 행위는 본질적으로 같다. 문제의 핵심은 도구가 아니라 그것을 다루는 사람의 자세다. 우리는 AI를 통해 생산성을 극대화하되, 동시에 그 결과물을 냉철하게 검증할 수 있는 시스템과 안목을 갖추어야 한다. 테스트 자동화와 정적 분석 도구를 더 적극적으로 도입하고, AI와 협업하는 새로운 워크플로우를 정립해야 한다.
결국 개발자의 역할은 '코드를 쓰는 사람’에서 '문제를 해결하는 설계자’로 변하고 있다. 코딩 자체에 쏟을 에너지를 아껴서 더 복잡한 비즈니스 로직을 설계하고, 사용자가 정말로 원하는 기능이 무엇인지 고민하는 것이 훨씬 더 효율적이다. AI 덕분에 우리는 이제 더 빠르게 실패하고, 더 빠르게 배울 수 있다. 60세가 넘은 개발자가 AI 덕분에 다시 코딩의 열정을 찾았다는 이야기는 우리에게 시사하는 바가 크다. 그는 문법을 익히는 고통에서 벗어나 자신의 아이디어를 즉시 결과물로 확인하는 즐거움을 누리고 있다. 이것이야말로 진정한 개발의 즐거움이 아닐까.
앞으로의 개발 환경은 더욱 빠르게 변할 것이다. AI는 더욱 똑똑해질 것이고, 우리가 직접 코드를 짜는 영역은 점점 더 줄어들 것이다. 하지만 그렇다고 해서 개발자의 존재 가치가 사라지는 것은 아니다. 오히려 시스템을 이해하고, 방향을 설정하고, 최종적인 책임을 지는 인간의 역할은 더욱 중요해질 것이다. 나는 이 변화가 두렵기보다 기대된다. AI라는 파도에 올라타서 우리가 어디까지 갈 수 있을지, 어떤 새로운 세상을 만들어낼 수 있을지 궁금하다. 우리는 이제 코딩이라는 좁은 틀에서 벗어나, 진정한 의미의 소프트웨어 엔지니어링으로 나아가야 한다.
관련 글
]]>최근 IT 업계의 최대 화두는 단연 AI 코딩 어시스턴트이다. 회사마다 앞다투어 클로드 코드나 커서 같은 도구들을 도입하고, 매니지먼트 층에서는 코드 생산성이 몇 퍼센트나 올랐다는 통계를 자랑하기 바쁘다. 개발자들이 예전보다 훨씬 빠르게 코드를 쏟아내는 것을 보며 관리자들은 이제 모든 개발 지연 문제가 해결될 것이라 믿는 눈치이다. 하지만 코드를 더 빨리 쓰는 것이 정말 우리에게 필요했던 정답이었을까? 사실 우리를 괴롭히는 진짜 병목은 코드를 타이핑하는 속도가 아니라, 그 코드 주변을 둘러싼 복잡한 프로세스와 의사결정의 지연에 있기 때문이다.
한 블로그 글에서는 이 상황을 아주 흥미롭게 비유했다. 만약 당신의 엔지니어링 부사장이 컨퍼런스에서 돌아와 'AI 덕분에 코드 출력이 40% 늘어날 것’이라고 흥분하며 말한다면, 그것은 시스템 전체의 병목을 전혀 이해하지 못한 발언일 가능성이 높다. 생산 라인에서 이미 충분히 빠르게 돌아가는 공정을 더 빠르게 만드는 것은 전체 처리량을 늘리는 데 아무런 도움이 되지 않는다. 오히려 처리되지 못한 재고만 잔뜩 쌓이게 만들어 시스템을 더 망가뜨릴 뿐이다. 엘리 골드렛의 명저 '더 골’에서 말하는 제약 이론이 바로 이 지점을 정확히 짚어준다. 시스템의 전체 처리량은 오직 병목 구간의 처리량에 의해서만 결정된다는 진리이다.
가장 먼저 부딪히는 현실적인 병목은 바로 코드 리뷰 단계이다. 개발자가 AI의 도움을 받아 평소보다 세 배 많은 풀 리퀘스트(PR)를 올린다고 가정해보자. 그렇다고 해서 그 코드를 검토할 리뷰어의 숫자가 세 배로 늘어나는 것은 아니다. 리뷰어들은 여전히 같은 인원이고, 그들은 이미 기존의 업무량만으로도 벅차다. 결국 리뷰 큐에는 처리되지 못한 PR들이 산더미처럼 쌓이기 시작한다. 개발자는 코드를 다 썼다고 생각하지만, 그 코드가 실제 제품에 반영되기까지 걸리는 시간인 사이클 타임은 오히려 길어진다. 며칠이 지나서야 돌아온 리뷰 의견을 보며 개발자는 자신이 썼던 코드의 맥락을 이미 잊어버린 상태가 되고, 다시 기억을 되살리느라 문맥 전환 비용을 지불해야 한다. 이것이 과연 진정한 생산성 향상이라고 볼 수 있을까?
게다가 AI가 생성한 코드는 그 양은 많을지 몰라도 깊은 이해도를 담보하지 못할 때가 많다. 한 CTO의 경험담에 따르면, AI가 작성한 코드를 단순히 훑어보고 실행만 해본 뒤 머지하는 경우가 늘어나고 있다고 한다. 정작 운영 환경에서 새벽 2시에 장애가 발생했을 때, 그 코드를 '프롬프트’로 만들어낸 개발자는 시스템이 왜 그렇게 동작하는지 제대로 설명하지 못한다. 코드는 늘어났지만 시스템에 대한 인간의 이해도는 낮아진 것이다. 이는 생산성 향상이 아니라, 나중에 터질 시한폭탄을 더 정교하고 빠르게 제작하고 있는 것에 가깝다. 대시보드상의 수치는 좋아 보일지 몰라도, 실제로는 운영 리스크라는 거대한 부채를 쌓아가고 있는 셈이다.
두 번째 병목은 '무엇을 만들 것인가’에 대한 불확실성이다. 코딩 속도가 아무리 빨라져도, 기획자가 사용자의 목소리를 듣지 않고 추측만으로 요구사항을 던진다면 아무런 의미가 없다. 기획서나 지라 티켓이 부실한 상태에서 코드만 빨리 짜는 것은, 잘못된 방향으로 더 빨리 달리는 것과 같다. 실제로 현장에서는 영업팀의 한마디나 확인되지 않은 가설에 기반해 몇 주 동안 기능을 개발했다가, 결국 아무도 쓰지 않는 기능이 되어 버려지는 일이 허다하다. 이해관계자들이 결정을 내리지 못해 회의만 거듭하는 동안 개발자가 AI로 코드를 몇 천 줄 더 써 내려가는 것은 자원 낭비일 뿐이다. 진정한 병목은 코딩이 아니라 문제를 정의하고 솔루션을 확정하는 과정에 있다.
세 번째로 주목해야 할 지점은 코드가 '완료’된 이후의 과정이다. 개발자의 로컬 환경에서 코드가 돌아가는 것은 전체 여정의 20%도 되지 않는다. 나머지 80%는 CI 빌드 대기, 스테이징 환경 테스트, 보안 검토, 운영팀의 배포 승인 등 복잡한 파이프라인 속에 갇혀 있다. 어떤 조직에서는 코드를 짜는 데는 한나절이면 충분하지만, 그것이 실제 사용자에게 도달하기까지 두 달이 걸리기도 한다. 이런 환경에서 코딩 속도를 40% 높인들 전체 기간에 미치는 영향은 미미하다. 오히려 배포에 대한 두려움 때문에 코드를 한꺼번에 묶어서 배포하는 ‘배치(Batch)’ 단위만 커지게 되고, 이는 배포 실패의 위험성을 더욱 높이는 악순환을 초래한다.
나는 이러한 상황에서 개발 조직이 가져야 할 관점의 전환이 필요하다고 생각한다. 개발자가 코드를 빨리 짜게 된 만큼, 조직의 다른 프로세스들도 그 속도에 맞춰서 개혁되어야 한다. 코드 리뷰 문화를 비동기 중심에서 짝 프로그래밍이나 즉각적인 피드백 구조로 바꾸거나, 배포 파이프라인에서 수동 승인 단계를 과감히 제거하고 자동화된 테스트와 카나리 배포 시스템을 구축해야 한다. 코딩이라는 엔진의 마력은 높아졌는데, 바퀴와 변속기가 예전 그대로라면 그 자동차는 제 속도를 낼 수 없다. 오히려 엔진의 과부하로 차 자체가 망가질 수도 있다.
또한 캘린더 자체가 병목이 되는 경우도 흔하다. 중요한 의사결정을 내려야 할 아키텍트나 시니어 엔지니어의 일정표가 회의로 가득 차 있어서, 간단한 디자인 리뷰 하나를 받는 데 일주일이 걸린다면 그 조직의 속도는 그 시니어 엔지니어의 스케줄에 종속된다. 결정권자의 일정이 로드베어링 벽처럼 시스템을 지탱하고 있는 셈이다. AI는 코드를 대신 짜줄 수는 있지만, 회의실에 앉아 결정을 내려주지는 않는다. 사람 사이의 소통 비용과 의사결정 구조를 단순화하지 않고서는 기술적 도구만으로는 한계가 명확하다.
우리가 진정으로 측정해야 할 지표는 '코드의 양’이나 'PR의 개수’가 아니라 '사이클 타임’이다. 아이디어가 나온 시점부터 사용자가 그 기능을 통해 가치를 얻기까지 걸리는 시간 말이다. 이 시간을 추적해보면 코딩이 차지하는 비중이 생각보다 작다는 사실에 놀라게 될 것이다. 대부분의 시간은 ‘대기’ 상태에서 소모된다. PR 승인을 기다리고, 배포 순번을 기다리고, 기획자의 피드백을 기다리는 시간들이다. 이 대기 시간을 줄이는 것이야말로 생산성 향상의 핵심이다. AI 도구는 개발자의 타이핑 수고를 덜어주는 보조 도구일 뿐, 시스템의 구조적 문제를 해결해주지는 못한다.
결국 경쟁 우위는 코드를 가장 빨리 쓰는 팀이 아니라, 무엇을 만들지 정확히 알고, 만든 것을 지체 없이 사용자에게 전달하며, 그 피드백을 통해 다시 다음 단계를 결정하는 순환 고리가 가장 빠른 팀에게 돌아간다. AI가 쏟아내는 수많은 코드들 사이에서 중심을 잡고, 우리 조직의 진짜 병목이 어디인지 찾아내어 그것을 제거하는 노력이 필요하다. 그것이 비효율적인 회의 구조일 수도 있고, 지나치게 엄격하고 느린 보안 절차일 수도 있으며, 혹은 서로 소통하지 않는 팀 간의 장벽일 수도 있다.
결론적으로 코딩 속도는 우리의 본질적인 문제가 아니었다. 만약 그렇게 믿어왔다면, 그 믿음과 실제 현실 사이의 간극이야말로 우리가 해결해야 할 가장 큰 문제일지도 모른다. AI 시대의 개발자는 단순히 코드를 잘 프롬프팅하는 사람이 아니라, 전체 개발 프로세스의 흐름을 이해하고 병목을 제거할 줄 아는 시스템 사고가가 되어야 한다. 키보드를 두드리는 속도보다 중요한 것은 시스템을 바라보는 시야라는 점을 명심해야겠다.
관련 글
]]>요즘 개발자들 사이에서 AI 코딩 도구를 쓰지 않는 사람을 찾기는 정말 어렵다. 나 역시 현재 클로드의 맥스 플랜을 구독하며 매일같이 업무와 프로젝트에 적극적으로 활용하고 있다. 하지만 최근 개발자 커뮤니티를 중심으로 흘러나오는 이야기들을 보면 지금 우리가 누리고 있는 이 놀라운 성능과 저렴한 가격이 과연 지속 가능한 것인지에 대한 의문이 든다. 단순히 기술의 발전으로 비용이 낮아진 것이 아니라, 거대 자본의 투입과 시장 점유율 확보를 위한 출혈 경쟁이 만들어낸 일시적인 착시 현상일 수도 있다는 지적이다. 과연 앞으로 AI 서비스의 가격은 더 싸질까, 아니면 우리가 상상하지 못한 수준으로 비싸질까.
최근 여러 커뮤니티와 긱뉴스를 통해 공유된 반응들을 살펴보면 지금의 AI 코딩 도구 가격이 실제 원가를 제대로 반영하지 못하고 있다는 시각이 지배적이다. 현재의 낮은 가격은 기술적인 혁신보다는 투자금과 보조적 가격 정책 위에 아슬아슬하게 형성되어 있다는 분석이다. 많은 이들이 우려하는 지점은 바로 이 '저가 정책’이 종료되는 시점이다. 초기에는 저렴한 비용으로 사용자를 유인하여 특정 도구에 종속되게 만든 뒤, 시장이 어느 정도 정리되면 가격을 대폭 인상하는 이른바 ‘락인(Lock-in)’ 전략이 사용될 것이라는 예측이다. 이는 과거 플랫폼 기업들이 보여주었던 전형적인 성장 공식이기도 하다.
특히 오픈AI나 앤스로픽 같은 순수 AI 기업들이 겪고 있는 대규모 적자 구조는 장기적인 불안정성을 키우는 요인이다. 모델을 학습시키는 데 드는 천문학적인 비용은 물론이고, 이를 유지하기 위한 인프라 비용이 상상을 초월하기 때문이다. 만약 투자 시장의 분위기가 바뀌거나 수익성 개선 압박이 거세진다면 지금과 같은 공격적인 가격 정책은 순식간에 사라질 수 있다. 한 게시글의 댓글에서는 어떤 회사가 먼저 가격을 올리는 총대를 멜지, 그리고 그것이 자폭이 될지 아니면 업계 전체의 가격 인상을 이끌지가 관건이라는 흥미로운 분석도 있었다.
물론 반대의 시각도 만만치 않다. 기술은 결국 더 저렴해지는 방향으로 흐른다는 논리다. 모델의 효율화와 하드웨어의 개선, 그리고 배치 처리 기술의 발전으로 인해 추론 비용은 장기적으로 계속해서 낮아질 것이라는 주장이다. 실제로 과거의 컴퓨팅 자원 가격 변화를 돌이켜보면 기술의 성숙은 늘 비용의 하락을 동반했다. 차세대 모델을 훈련하는 비용은 여전히 비싸지만, 이미 만들어진 모델을 서비스로 제공하는 추론 비용은 생각보다 빠르게 낮아질 수 있다는 점이 낙관론의 근거다. 게다가 로컬 LLM이나 오픈소스 모델의 발전은 유료 서비스의 독주를 막는 훌륭한 대안이 될 수 있다.
개발자로서 내가 가장 눈여겨보는 부분은 가격 그 자체보다도 AI가 개발 생태계에 미치는 영향이다. 만약 AI 없이는 일을 할 수 없는 구조가 고착화된 상태에서 가격이 급격히 오른다면, 개인과 기업은 큰 리스크에 직면하게 된다. 주니어 개발자들이 기초적인 역량을 쌓기도 전에 AI에 지나치게 의존하게 되는 상황도 걱정스러운 대목이다. 숙련된 개발자가 부족해지는 상황에서 AI 툴의 가격까지 상승한다면 개발 비용 전체가 통제 불능 상태에 빠질 수도 있다. 하지만 반대로 AI 가격이 지금보다 몇 배가 더 오른다 하더라도 개발자의 인건비 대비 생산성 향상 폭이 더 크다면 기업 입장에서는 기꺼이 비용을 지불할 것이라는 현실적인 반응도 무시할 수 없다.
나 또한 클로드 맥스 플랜을 사용하며 느끼는 것이지만, 현재 수준의 생산성 향상을 경험한 이상 이전의 개발 방식으로 완전히 돌아가기는 불가능할 것 같다. 지금은 한 달에 몇만 원 수준의 구독료를 내고 있지만, 만약 이 비용이 열 배로 뛴다면 나는 어떤 선택을 할까. 아마도 그때가 되면 비용 대비 효율을 더 꼼꼼히 따지게 되겠지만, 동시에 그만큼 더 고도화된 작업을 AI에게 맡기려 노력할 것이다. 결국 가격 거품이 꺼지고 시장이 재편되는 과정은 불가피하겠지만, 그 끝에서 살아남는 것은 결국 기술의 본질을 이해하고 변화에 유연하게 대응하는 이들이다.
많은 전문가들이 지적하듯이 지금의 AI 시장은 완전한 대체보다는 대대적인 재편의 과정을 겪고 있다. 가격이 오를지 내릴지 예측하는 것도 중요하지만, 더 본질적인 것은 AI가 만든 결과물의 품질과 유지보수 가능성을 어떻게 관리할 것인가에 대한 고민이다. 경영진들이 AI를 만능 해결사로 착각하여 무분별하게 도입했다가 예상치 못한 토큰 비용이나 클라우드 인프라 유지비에 당황하는 사례도 적지 않다. 이는 기술의 도입이 단순한 비용 문제를 넘어 전략적인 판단이 필요함을 시사한다.
관련 글
]]>우리는 AI가 쏟아내는 코드의 홍수 속에서 허우적대고 있다. 과거의 방식으로는 도저히 이 속도를 따라잡을 수 없다. 이제는 단순히 코드를 읽는 행위를 넘어, 개발의 패러다임 자체를 송두리째 바꿔야 할 시점이다. 기술의 발전 속도는 인간의 인지 능력을 추월했고, 우리가 신성시하던 코드 리뷰라는 절차는 이제 혁신의 발목을 잡고 있다.
최근 개발 환경의 변화를 지켜보면 AI가 코드를 작성하는 속도가 인간의 검토 속도를 아득히 추월하고 있다는 사실을 체감한다. 많은 개발자가 클라우드 기반의 AI 도구를 활용해 생산성을 비약적으로 높였지만, 아이러니하게도 팀 전체의 속도는 오히려 정체되거나 느려지는 현상이 발생하고 있다. 한 조사에 따르면 AI 도입률이 높은 팀은 PR(Pull Request) 생성량이 98%나 증가했지만, 정작 리뷰에 소요되는 시간은 91%나 늘어났다고 한다. 이러한 불균형은 결국 코드 리뷰라는 전통적인 안전망이 AI 시대의 생산성을 감당하지 못한다는 걸 의미한다. 인간은 인간이 코드를 작성하던 속도에 맞춰진 리뷰 프로세스조차 제대로 소화하지 못하고 있었다.
엔지니어링 조직들을 살펴보면 한 가지 공통적인 비밀이 있다. PR은 며칠씩 방치되고, 리뷰어들은 자기 일을 하느라 바빠서 500줄이 넘는 변경 사항을 대충 훑어본 뒤 도장을 찍듯 승인 버튼을 누른다. 우리는 이것을 품질 게이트라고 부르며 스스로를 위안하지만, 사실 수십 년 동안 팀들은 한 줄 한 줄 꼼꼼한 리뷰 없이도 소프트웨어를 출시해왔다. 코드 리뷰가 보편화된 것은 생각보다 그리 오래된 일이 아니다. 2012년에서 2014년 사이에나 대중화되었을 뿐이다. 게다가 리뷰를 거친다고 해서 버그가 생기지 않는 것도 아니다. 우리는 이미 리뷰만으로는 부족하다는 것을 알고 있었기에 기능 플래그, 점진적 배포, 즉각적인 롤백 시스템을 구축해왔다.
이제 우리는 모든 코드를 읽는 것을 포기해야 한다. 1,200개 이상의 팀과 1만 명 이상의 개발자 데이터를 보면 두 가지 수치가 지수적으로 상승하고 있다. 바로 코드 변경의 횟수와 그 규모다. 우리는 이 엄청난 양의 코드를 도저히 소비할 수 없다. 더 큰 문제는 개발자들이 동료의 코드보다 AI가 생성한 코드를 검토할 때 훨씬 더 많은 노력을 들여야 한다고 느낀다는 점이다. 생산량은 늘었는데 검토 비용은 더 크게 늘어나는 이 싸움에서 수동 코드 리뷰로는 절대로 승리할 수 없다. 코드 리뷰는 현재의 작업 형태와 더 이상 맞지 않는 역사적 산물이 되어버렸다.
혹자는 AI 코드 리뷰 도구가 해결책이 될 수 있다고 말한다. 하지만 AI가 코드를 쓰고 AI가 리뷰를 한다면, 굳이 화려한 UI를 통해 그 과정을 인간이 지켜볼 필요가 있을까? AI 리뷰 도구는 단지 시간을 벌어줄 뿐이다. AI 에이전트가 코드를 작성하는 시대에 '새로운 시각’을 가진 리뷰어라는 개념은 무의미하다. 에이전트의 시각은 결국 비슷한 사각지대를 가진 또 다른 에이전트의 시각일 뿐이다. 중요한 가치는 승인 게이트가 아니라 반복 루프 안에 있다. 에이전트가 완벽하지 않다는 것을 알기에 우리는 '한 번이라도 AI가 멍청한 실수를 하는 걸 봤으니 내가 직접 확인해야 한다’는 본능에 사로잡힌다. 하지만 수동 검증이 불가능할 정도로 규모가 커진 지금, 그 본능은 오히려 방해가 될 뿐이다.
해결책은 인간의 체크포인트를 상류로 옮기는 것이다. 코드를 리뷰하지 않는다는 생각이 두렵게 느껴질 수 있지만, 소프트웨어 개발 역사에서 체크포인트는 항상 이동해왔다. 폭포수 모델의 최종 서명 방식에서 지속적 통합(CI)으로 옮겨온 것처럼 말이다. 이제는 스펙 중심 개발(Spec-driven development)이 AI와 협업하는 주된 방식이 되어야 한다. 인간은 500줄의 코드 차이점을 읽는 대신 스펙, 계획, 제약 조건, 수용 기준을 리뷰해야 한다. 이 새로운 패러다임에서 스펙은 진실의 원천이 되고 코드는 스펙의 결과물이 된다. 코드가 아니라 단계를 리뷰하고, 검증 규칙을 리뷰하며, 코드가 충족해야 하는 계약을 리뷰해야 한다. 인간의 판단은 '이걸 제대로 썼는가’가 아니라 '우리가 올바른 제약 조건을 가지고 올바른 문제를 해결하고 있는가’에 집중되어야 한다.
신뢰는 한 번에 얻어지는 것이 아니라 겹겹이 쌓아 올리는 것이다. 안킷 제인은 이를 '스위스 치즈 모델’이라고 불렀다. 완벽한 필터는 없지만, 불완전한 필터를 여러 개 겹치면 구멍이 일직선으로 연결되지 않아 결함을 막을 수 있다는 원리다. 첫 번째 레이어는 여러 옵션을 비교하는 것이다. 한 명의 에이전트에게 정답을 요구하는 대신, 세 명의 에이전트에게 서로 다른 방식으로 시도하게 하고 가장 좋은 결과를 선택하게 하는 방식이다. 소프트웨어 공학 역사상 선택의 비용이 이토록 낮았던 적은 없다. 선택 역시 수동일 필요는 없다. 가장 많은 검증 단계를 통과하거나, 변경 사항이 가장 적거나, 새로운 종속성을 추가하지 않는 결과물을 자동으로 순위 매길 수 있다.
두 번째 레이어는 결정론적인 가드레일이다. 테스트, 타입 체크, 계약 검증처럼 의견이 아닌 사실에 기반한 확인 방식이 필요하다. AI에게 '이게 잘 작동해?'라고 묻는 대신, 작동 여부를 증명할 수 있는 스크립트를 작성하게 해야 한다. 에이전트는 실패하는 테스트와 협상할 수 없다. 명세에 부합하거나 그렇지 않거나 둘 중 하나다. 이러한 가드레일은 코딩 가이드라인, 전사적 불변 법칙(예를 들어 하드코딩된 자격 증명 금지), 도메인 계약 등으로 구성된다. 중요한 점은 검증 기준이 코드가 작성된 후에 만들어지는 것이 아니라, 스펙으로부터 먼저 정의되어야 한다는 것이다.
세 번째 레이어에서 비로소 인간이 수용 기준을 정의하며 가치를 더한다. 여기서 행동 주도 개발(BDD)이 다시 중요해진다. 자연어로 기대되는 동작을 기술하고 이를 테스트로 자동화하는 BDD는 과거에는 코드를 짜는 것 외에 추가적인 작업처럼 느껴져 외면받았다. 하지만 에이전트 시대에는 방정식이 뒤집힌다. 스펙은 더 이상 추가 작업이 아니라 기본 결과물이 된다. 인간이 스펙을 쓰고 에이전트가 구현하며 BDD 프레임워크가 검증한다. 무언가 실패하지 않는 한 우리는 구현을 읽을 필요가 없다. 이것이 인간이 잘하는 일이다. 무엇이 '옳음’인지 정의하고, 비즈니스 로직과 예외 상황을 설계하며, 발생할 수 있는 문제를 미리 생각하는 것 말이다.
네 번째 레이어는 아키텍처로서의 권한 시스템이다. 에이전트가 무엇을 건드릴 수 있는지, 어떤 상황에서 인간의 개입이 필요한지를 아키텍처 단계에서 결정해야 한다. 유틸리티 함수의 버그를 고치는 에이전트에게 인프라 설정 권한을 줄 필요는 없다. 작업에 필요한 최소한의 파일에만 접근 권한을 제한하는 세밀함이 필요하다. 또한 인증 로직을 건드리거나 데이터베이스 스키마를 수정하는 것과 같은 특정 패턴이 감지되면 에이전트의 자신감과 상관없이 자동으로 인간의 리뷰를 요청하는 에스컬레이션 트리거를 설정해야 한다.
마지막 다섯 번째 레이어는 적대적 검증이다. 책임을 분리하여 한 에이전트가 코드를 짜면 다른 에이전트가 이를 검증하게 하는 것이다. 이들은 서로를 믿지 않도록 설계되어야 한다. 이는 마치 보안의 레드팀과 블루팀처럼 작동한다. 코딩 에이전트는 검증 에이전트가 무엇을 확인할지 알 수 없고, 검증 에이전트는 자신의 작업을 편하게 하기 위해 코드를 수정할 권한이 없다. 이러한 적대적 구조를 시스템적으로 강제함으로써 우리는 더 견고한 신뢰를 구축할 수 있다.
결국 '좋은 코드’의 정의 자체가 변하고 있다. 에이전틱 시스템의 목표는 단순하다. 주어진 작업을 완료하고 사용자를 만족시키는 것이다. 에이전트의 성공은 본질적으로 장기적인 정확성이나 비즈니스 요구사항에 의해 추진되지 않는다. 따라서 그 제약 조건을 코드로 인코딩하는 것은 우리의 몫이다. 에이전트가 쓰고 에이전트가 읽는 코드의 시대에는 코드의 스타일이 더 표준화될 것이다. 우리는 기계를 읽기 능력으로 이기려 해서는 안 된다. 결정이 실제로 중요한 상류 지점에서 기계보다 더 깊이 생각해야 한다.
나는 예전부터 코드를 일일이 읽는 행위에 대해 회의적인 시각을 가지고 있었다. 이전 글에서도 언급했듯이, AI가 코드를 생성하는 시대에 모든 라인을 사람이 직접 검토하는 것은 불가능에 가깝다. 인간의 집중력은 400줄이 넘어가는 시점부터 급격히 떨어진다. 대규모 PR 앞에서 리뷰어는 결국 'LGTM’을 날리는 도장 찍기 단계로 넘어가기 쉽다. 이는 보안 사고나 논리적 오류를 방치하는 위험한 결과를 초래한다. 검토하지 않은 코드를 동료에게 떠넘기는 행위는 협업의 본질을 훼손하는 것이다. 생성 비용이 0에 수렴할수록 가치의 중심은 생성이 아니라 검증으로 이동해야 한다.
도메인 지식과 암묵적인 룰, 즉 부족 지식은 AI가 쉽게 대체할 수 없는 영역이다. 우리 회사의 작년 히스토리나 특정 결제 모듈이 왜 그렇게 복잡하게 설계되었는지, 과거의 어떤 실패 경험 때문에 이런 제약 조건이 생겼는지는 오직 인간만이 알고 있다. 이러한 맥락을 스펙과 검증 규칙에 녹여내는 것이 AI 시대 엔지니어의 핵심 역량이다. 단순히 코드를 잘 타이핑하는 시대는 끝났다. 이제는 AI가 만든 결과물을 비판적으로 평가하고 우리만의 특수한 비즈니스 상황에 맞게 교정할 수 있는 능력이 훨씬 중요하다.
결국 우리는 '무엇을 썼는가’가 아니라 '무엇을 해결하려 하는가’를 확인하는 과정으로 나아가야 한다. diff가 아니라 스펙을 리뷰하고, 구문이 아니라 맥락을 리뷰해야 한다. 미래는 빠르게 배포하고 모든 것을 관찰하며 더 빠르게 되돌리는 시대다. 천천히 리뷰하면서도 버그를 놓치고 프로덕션에서 디버깅하는 시대가 아니다. 당신의 이름으로 배포된 코드에 대해 끝까지 책임을 질 수 있는 능력을 갖추는 것, 그것이 AI 시대에 살아남는 유일한 길이다.
관련 글
]]>최근 한 기술 블로그에서 'Yes, and…'라는 제목의 흥미로운 글을 읽었다. 몬태나 주립대학교에서 컴퓨터 과학을 가르치는 한 교수가 쓴 글이었는데, AI 시대에도 여전히 프로그래밍을 배워야 하는가에 대한 그의 고찰이 담겨 있었다. 그는 프로그래밍이 근본적으로 컴퓨터를 이용한 문제 해결과 복잡성 제어에 관한 것이기에 그 가치는 변하지 않을 것이라고 주장한다. 하지만 주니어 개발자들에게는 매우 엄격한 태도를 보인다. AI가 코드를 생성해줄 수 있더라도 절대로 그렇게 하지 말고 직접 코드를 짜야 한다고 강조한다. 코드를 직접 짜지 않으면 코드를 읽는 능력을 기를 수 없고, 결국 자신이 이해하지 못하는 시스템을 만드는 ‘마법사의 제자’ 함정에 빠지게 된다는 논리다. 그는 AI를 코드 생성기가 아니라 개념 이해를 돕는 유능한 조교(TA)로 활용하라고 조언한다.
하지만 내 생각은 다르다. 저자의 시각은 고전적인 교육자의 관점에서는 타당할지 모르나, 지금 우리가 겪고 있는 거대한 패러다임의 전환기를 지나치게 보수적으로 해석하고 있다는 생각이 들었다. 나는 그가 말하는 '직접 코드를 짜야 한다’는 원칙이 이제는 일종의 낭만적인 고집이 되어버렸다고 생각한다. 우리는 지금 프로그래밍이라는 행위 자체가 재정의되는 과도기에 서 있다. 나처럼 이미 10년 넘게 현업에서 구르며 기본 지식과 경험을 쌓은 사람들에게는 AI가 날개를 달아주는 도구임이 분명하다. 하지만 주니어 개발자나 학생들에게 '옛날 방식’을 고수하라고 강요하는 것이 과연 그들의 미래에 도움이 될지는 의문이다.
저자는 주니어 개발자가 AI로 코드를 생성하기만 하면 '참호 속의 전투’에서 얻는 생생한 이해를 놓치게 된다고 경고한다. 하지만 나는 이 '참호 속의 전투’가 이제는 불필요한 고행이 되고 있다고 본다. 과거에는 어셈블리어를 알아야 C언어를 잘 이해할 수 있다고 했고, C언어를 알아야 자바나 파이썬의 메모리 구조를 이해할 수 있다고 했다. 하지만 지금 자바스크립트로 훌륭한 서비스를 만드는 개발자들 중에 어셈블리어를 만져본 사람이 얼마나 되겠는가? 추상화의 단계가 올라가면 하위 단계의 고통은 자연스럽게 도구의 몫으로 넘겨야 한다. AI는 그저 그 추상화의 층위를 한 단계 더 높인 것뿐이다.
저자는 고수준 언어로의 전환과 AI 생성 코드의 차이점을 설명하며, 컴파일러는 결정론적이지만 AI는 그렇지 않다는 점을 지적한다. AI가 생성한 코드는 우발적 복잡성을 추가할 수 있고 부적절한 접근 방식을 선택할 수 있다는 것이다. 맞는 말이다. 하지만 이것은 기술의 불완전성에서 오는 일시적인 문제일 뿐이다. 컴파일러 초기 시절에도 생성된 기계어 코드가 비효율적이라는 비판이 있었지만, 결국 도구는 발전했고 인간은 그 도구를 신뢰하게 되었다. AI가 내뱉는 코드에 버그가 있거나 비효율적일 수 있다는 사실은 주니어 개발자가 코딩을 직접 해야 할 이유가 아니라, AI가 내놓은 결과물을 검증하고 조율하는 능력을 키워야 할 이유가 된다.
이제 책 맨 앞장에서 'hello world’부터 찍어보고 문법을 달달 외우는 방식의 학습은 아무런 의미가 없다. 그런 정보는 AI가 세상에서 가장 잘 알고 있기 때문이다. 중요한 것은 이 굉장한 도구를 어떻게 활용하여 내가 원하는 결과물을 만들어낼 것인가 하는 '오케스트레이션’의 능력이다. 주니어 개발자가 AI에게 '이 코드를 짜줘’라고 말하는 것을 금지할 것이 아니라, 'AI가 짠 이 코드가 왜 이렇게 작동하는지, 더 나은 방법은 없는지’를 AI와 토론하며 배우게 해야 한다. 이것이 저자가 말한 ‘조교로서의 AI’ 활용법과 맞닿아 있는 듯 보이지만, 핵심적인 차이는 '코드 생성 자체를 두려워하지 말아야 한다’는 점이다.
나는 이전에도 강조했듯이 코드는 예술 작품이 아니라고 생각한다. 코드는 문제를 해결하기 위한 도구이자 수단일 뿐이다. 누군가는 한 땀 한 땀 코드를 직접 짜며 장인정신을 느낄 수도 있겠지만, 산업 현장에서의 코딩은 철저하게 비즈니스 가치를 창출하기 위한 공학적 프로세스다. 사용자는 그 코드가 AI에 의해 1초 만에 생성되었는지, 사람이 며칠 밤을 새우며 짰는지 전혀 관심이 없다. 그들에게 중요한 것은 오직 그 프로그램이 자신의 문제를 제대로 해결해주는가 하는 점이다. 저자가 우려하는 ‘영혼 없는 복제품’ 같은 코드가 양산되는 것은 AI의 잘못이 아니라, 그 코드를 사용하는 인간의 책임감이 부족하기 때문이다.
생산성이라는 측면에서 AI는 축복이다. 예전에는 단순한 기능을 구현하는 데만도 수많은 보일러플레이트 코드를 작성하며 시간을 허비해야 했다. 하지만 이제는 그런 지루한 작업은 AI에게 맡기고, 개발자는 더 높은 수준의 아키텍처와 사용자 경험을 고민하는 데 시간을 써야 한다. 저자는 주니어가 간단한 작업을 AI에게 맡기면 나중에 아키텍트가 될 직관을 기를 수 없다고 말한다. 하지만 나는 반대로 생각한다. AI 덕분에 주니어 시절부터 더 넓은 시스템의 구조를 조망할 기회를 일찍 갖게 된다면, 그들이 훨씬 더 빠르게 아키텍트의 시야를 가질 수 있지 않을까?
소위 말하는 '바이브 코딩(vibe coding)'에 대한 비판도 다시 생각해볼 필요가 있다. 저자는 시니어들이 AI를 쓰면서도 직접 코딩하는 감각을 잃지 않으려 노력해야 한다고 말하지만, 사실 경험이 풍부한 이들은 이미 무엇이 좋은 코드인지에 대한 기준이 머릿속에 박혀 있다. 그들에게 AI는 타자기를 대신해주는 비서와 같다. 그렇다면 주니어들은? 그들은 AI를 통해 수많은 '좋은 코드’의 사례를 접하며 자신의 기준을 만들어나가야 한다. 직접 타이핑하는 고통을 겪어야만 지식이 습득된다는 생각은 펜으로 글을 써야만 문장력이 늘어난다는 주장만큼이나 구시대적이다.
최근 개발자 취업 시장이 어렵다는 이야기가 많다. 저자는 이를 일시적인 경기 순환의 문제로 보고 인맥을 동원하라는 지극히 현실적이고도 씁쓸한 조언을 한다. 하지만 나는 시장이 변한 근본적인 이유 중 하나가 바로 AI로 인한 생산성 폭발에 있다고 본다. 기업은 이제 단순히 '코드를 짤 줄 아는 사람’을 원하지 않는다. AI를 활용해 혼자서 서너 명의 몫을 해낼 수 있는 '문제 해결사’를 원한다. 이런 상황에서 주니어들에게 '기본을 다지기 위해 AI를 쓰지 마라’고 가르치는 것은, 전쟁터에 나가는 병사에게 총 대신 칼을 들고 연습하라고 말하는 것과 다를 바 없다.
결국 소울이나 장인정신이라는 단어는 기술적 변화에 대한 공포를 가리기 위한 멋들어진 핑계에 불과할지도 모른다. 변화에 적응하지 못하고 과거의 수작업 방식에 매몰된 이들이 AI라는 거대한 흐름을 거부하기 위해 꺼내든 카드 말이다. 하지만 기술의 역사는 언제나 효율적인 도구를 선택한 이들의 손을 들어주었다. 코딩에서 소울을 찾는 것이 아니라, 당신이 만든 서비스가 사용자에게 줄 수 있는 가치에서 소울을 찾아야 한다. 개발자는 예술가가 아니라 해결사여야 하며, AI는 그 해결 능력을 무한히 확장해주는 가장 강력한 무기다.
저자가 말한 'Yes, and…'는 주니어들에게는 'Yes, but AI first’가 되어야 한다고 생각한다. 프로그래밍의 가치는 여전하지만, 그 방식은 완전히 달라졌다. 직접 코드를 짜는 고통이 실력을 보장해주던 시대는 끝났다. 이제는 얼마나 영리하게 도구를 다루느냐가 실력의 척도가 된다. 회사가 주니어들에게 코드를 짜게 해야 한다는 저자의 말에도 동의한다. 하지만 그 방식은 AI와 협업하여 더 크고 복잡한 문제를 풀 기회를 주는 것이어야지, AI로 1분 만에 할 일을 1시간 동안 직접 하게 만드는 고문을 가하는 것이어서는 안 된다.
나 역시 AI와 함께하는 이 시대가 즐겁다. 예전에는 상상만 하고 포기했던 아이디어들을 이제는 퇴근 후 몇 시간 만에 프로토타입으로 만들어낼 수 있기 때문이다. 이것이 진정한 개발의 즐거움이지, 오타를 잡느라 밤을 새우는 것이 즐거움은 아닐 것이다. 시대는 변했고, 그 변화를 온몸으로 받아들이는 개발자만이 살아남을 수 있다. 고리타분한 원칙 뒤에 숨어 변화를 깎아내리기보다는, 이 강력한 파도를 타고 더 멀리 나아가는 법을 배워야 한다. 우리는 지금 인류 역사상 가장 강력한 '지능의 지렛대’를 손에 쥐고 있다.
관련 글
]]>최근 벤처 캐피털 업계에서는 인공지능이 서비스 비즈니스를 소프트웨어 비즈니스로 변화시키고 있다는 공감대가 형성되고 있다. 서비스 회사가 이전에는 불가능했던 방식으로 벤처 투자를 받을 수 있는 대상으로 여겨지기 시작한 것이다. 몇 년 전 일부 유명 VC들은 이를 '서비스로서의 소프트웨어(Service as Software)'라고 부르며 약 4.6조 달러 규모의 기회라고 정의하기도 했다. 제너럴 카탈리스트는 법률, IT, 회계 분야의 서비스 기업을 인수하고 AI를 도입하는 데 15억 달러를 투자하겠다고 발표했고, 쓰라이브는 관련 비즈니스 인수를 위해 10억 달러 이상의 펀드를 조성했다. 오픈AI 역시 이 과정에 엔지니어를 직접 투입하며 지분을 확보하고 있다.
이런 움직임의 배경에는 명확한 숫자가 있다. 전 세계 서비스 시장은 약 16조 달러 규모에 달하지만, 소프트웨어 시장은 겨우 1조 달러 수준이다. 만약 AI가 서비스 제공 과정에 소프트웨어와 같은 마진율을 가져올 수 있다면 그 잠재력은 상상을 초월한다. 일반적인 소프트웨어 회사는 70~85%의 총마진을 유지하며 고객과 깊고 반복적인 관계를 맺는다. 반면 전문 서비스 기업은 운이 좋아야 30~40%의 마진을 기록하며, 대부분 프로젝트 단위의 일시적인 수익에 의존한다. AI가 이 간극을 조금이라도 메울 수 있다면 16배나 큰 시장에서 엄청난 가치가 창출될 것이라는 논리다.
하지만 현실은 '서비스가 소프트웨어가 된다’는 단순한 구호보다 훨씬 복잡하다. 한 벤처 투자자의 분석에 따르면, AI는 서비스 비즈니스를 '더 나은 서비스 비즈니스’로 만들고 있을 뿐이지 마법처럼 소프트웨어 회사로 탈바꿈시키는 것은 아니다. 마진이 개선되고 1인당 생산성이 높아지더라도 서비스 비즈니스의 본질적인 역학 관계는 그대로 유지된다. 고객은 단순히 결과물만을 위해 돈을 지불하는 것이 아니기 때문이다. 그들은 자격, 브랜드 자산, 제도적 신뢰, 그리고 결과에 대한 책임과 그에 따른 법적 책무를 지는 주체를 원한다.
이 기회를 포착하기 위해 현재 세 가지 모델이 등장하고 있다. 기존 서비스 기업에 AI 도구를 판매하는 방식, 처음부터 AI 기반의 서비스 기업을 구축하는 방식(AI-native), 그리고 기존 기업들을 인수하여 AI를 결합하는 방식(Roll-up)이다. 각 모델은 나름의 장점이 있지만 투자자가 신중하게 검토해야 할 독특한 위험 요소도 안고 있다. 과연 서비스 시장의 모든 영역이 AI로 대체 가능한지, 그리고 그 마진 확장이 얼마나 지속 가능한지에 대해 깊이 고민해 볼 필요가 있다.
먼저 서비스 시장 전체가 AI의 공략 대상이라는 착각에서 벗어나야 한다. 전문 서비스 지출의 상당 부분은 처음부터 결과물 그 자체와 상관이 없는 경우가 많다. 한 전직 컨설턴트의 증언에 따르면, 기업들이 빅4 회계법인을 고용하는 이유는 그들의 감사가 독보적으로 가치 있어서가 아니라, 문제가 생겼을 때 '우리는 전문가의 지침을 따랐다’는 방어 논리를 세우기 위해서다. 규제 기관이 신뢰하는 외부 법률 고문을 고용하거나, 구조 조정을 위해 외부 컨설턴트를 불러오는 것도 마찬가지다. 내부 리더십이 책임을 지지 않기 위한 정치적 도구로 서비스를 이용하는 것이다.
이런 요소들은 효율성의 문제처럼 보일 수 있지만, 사실 전문 서비스가 작동하는 핵심 기능이다. AI가 분석 업무를 완벽하게 수행할 수 있어도 '책임 전가’나 '비난 흡수’의 역할은 수행할 수 없다. 이사회가 AI 모델을 가리키며 '우리는 전문가의 조언에 의존했다’고 변명할 수는 없는 노릇이다. 따라서 AI가 주도하는 서비스 혁신의 상한선은 결국 결과물의 품질에 달려 있는 부분까지만이다. 소위 '책임 회피(CYA, Cover Your Ass)'를 위한 시장은 생각보다 훨씬 견고할 것이며, 이는 AI 기반 스타트업이 넘기 힘든 벽이 될 수 있다.
마진 확장 역시 일시적일 가능성이 크다. 경쟁사들이 동일한 AI 기능을 채택함에 따라 서비스는 가격에 따라 다시 범용화될 것이다. 고객들 또한 AI가 과거 주니어 직원이 하던 일을 대신하고 있다는 사실을 깨닫게 되면 그 비용 절감분을 자신들에게 돌려달라고 요구할 것이다. 결국 지속 가능한 마진은 AI 자동화 그 자체가 아니라, 그 위에 얹어진 프리미엄과 책임 계층에서 나온다. 예를 들어 세금 신고를 자동화하고 저렴한 가격에 제공하는 회사는 모델을 가진 다른 경쟁자에게 취약하지만, 회계사가 직접 서명하고 법적 책임을 지며 고객 관계를 관리하는 회사는 훨씬 끈끈한 마진을 유지할 수 있다.
흥미로운 점은 세콰이어 캐피털과 같은 곳에서 바라보는 시각이다. 그들은 다음 시가총액 1조 달러 기업이 '서비스 기업으로 위장한 소프트웨어 기업’에서 나올 것이라고 예측한다. 많은 창업자가 AI 도구를 팔 때 클로드나 GPT의 다음 버전이 자신의 제품을 단순한 기능으로 전락시킬까 봐 걱정한다. 하지만 도구가 아니라 '결과물’을 판다면 이야기가 달라진다. 모델이 개선될수록 서비스를 제공하는 비용은 낮아지고 속도는 빨라지며 경쟁력은 더욱 강력해진다. 퀵북스라는 소프트웨어에 연간 1만 달러를 쓰고 회계사에게 12만 달러를 쓰는 회사가 있다면, 미래의 전설적인 기업은 소프트웨어가 아니라 아예 ‘장부를 마감해 주는 서비스’ 자체를 제공할 것이다.
이 과정에서 '지능’과 '판단’을 구분하는 것이 중요하다. 코드를 작성하는 것은 지능의 영역이지만, 무엇을 다음에 만들지 결정하는 것은 판단의 영역이다. AI는 이미 지능의 임계점을 넘어서 소프트웨어 엔지니어링이나 데이터 분석 같은 업무에서 인간을 대체하거나 보조하고 있다. 하지만 경험과 직관, 그리고 리스크를 감수하는 판단력은 여전히 인간의 영역이다. 현재는 AI가 전문가의 손을 빌려 생산성을 높여주는 ‘코파일럿(Copilot)’ 단계에 머물러 있지만, 점차 고객에게 직접 결과물을 판매하는 '오토파일럿(Autopilot)'으로 진화하고 있다.
오토파일럿 비즈니스를 구축하려는 창업자들에게는 '아웃소싱’이 강력한 쐐기 역할을 한다. 어떤 업무가 이미 외부 업체에 맡겨지고 있다면, 그 회사는 이미 해당 업무가 외부에서 수행될 수 있다는 점을 받아들였고 예산도 확보되어 있다는 뜻이다. 이런 영역을 AI 네이티브 서비스로 대체하는 것은 조직 구조를 바꾸는 것이 아니라 단순히 공급업체를 교체하는 작업이기에 훨씬 침투하기 쉽다. 예를 들어 대부분의 기업이 법무법인에 맡기는 NDA 초안 작성 같은 업무가 대표적인 공략 대상이다.
하지만 이런 변화 속에서도 인력 의존도는 여전히 높다. AI가 1인당 처리할 수 있는 업무량의 상한선을 높여주지만, 여전히 면허를 가진 전문가가 필요하다. 특히 회계나 법률처럼 규제가 강한 분야에서는 더욱 그렇다. 역설적으로 AI 도구가 발전할수록 숙련된 전문가를 확보하는 비용은 더 비싸질 수 있다. 대형 로펌의 파트너가 AI를 이용해 기존보다 3배 많은 사건을 더 적은 수고로 처리하게 된다면, 그들은 굳이 회사를 떠날 이유가 없어진다. 스타트업들이 우수한 인재를 영입하기 위해 더 많은 자본을 투입해야 하고, 결국 마진의 이점이 인건비 경쟁으로 상쇄될 위험이 있다.
또한 파운데이션 모델을 만드는 빅테크 기업들이 가만히 있지 않는다는 점도 변수다. 앤스로픽은 이미 금융 분석과 회계 처리를 위한 에이전트 기능을 출시했고, 오픈아이 역시 액센추어나 맥킨지 같은 거대 컨설팅 펌과 파트너십을 맺고 에이전트를 기업 워크플로우에 직접 투입하고 있다. 기초 모델 자체가 서비스 계층을 직접 공략하기 시작하면 AI 기반 서비스 스타트업의 입지는 좁아질 수밖에 없다. 여기서 다시 한번 '책임 계층’의 중요성이 부각된다. 모델은 결과물을 복제할 수 있지만, 고객이 실제로 프리미엄을 지불하는 전문적 관계와 규제적 책임을 복제할 수는 없기 때문이다.
결국 어떤 산업에서 AI 서비스 비즈니스를 시작할 것인가가 성패를 가른다. 단순히 마진율만 볼 것이 아니라, 시장에 강력한 '강제력’이 있는지 확인해야 한다. 회계 분야가 좋은 예다. 최근 몇 년 사이 수십만 명의 회계사가 업계를 떠났고 기존 인력은 노령화되고 있다. 일손이 부족해 수주를 거절해야 하는 상황이 오면 기업들은 AI 도구를 도입하는 데 매우 적극적으로 변한다. 공급 부족이라는 강력한 동기가 변화를 이끄는 것이다. 반면 충분히 수익을 내고 있고 변화의 절박함이 없는 분야는 AI 도구를 팔기가 훨씬 어렵다.
보험 중개나 의료 미수금 관리 같은 영역도 유망하다. 보험 중개는 표준화된 지능 작업이 주를 이루며 시장이 매우 파편화되어 있어 단일 지배자가 없다. 의료 코딩이나 청구 업무 역시 복잡한 규칙 기반의 작업으로 AI가 수행하기에 적합하며 이미 아웃소싱 시장이 성숙해 있다. 이런 곳에서는 처음부터 직접 서비스 주체가 되어 전체 과정을 통제하는 모델이 승산이 있다. 소프트웨어만 팔아서는 변화시키기 어려운 낡은 산업일수록 직접 서비스를 제공하며 기술을 내재화하는 방식이 효과적이다.
벤처 투자자의 관점에서 볼 때, 서비스 비즈니스가 소프트웨어와 똑같은 마진 프로필을 가질 수는 없을 것이다. 80%의 마진을 기록하거나 인력 추가 없이 무한히 확장하기는 힘들다. 하지만 소프트웨어 시장보다 수십 배 큰 시장에서 50% 이상의 마진을 유지하며 반복적인 매출을 일으킬 수 있다면, 그것만으로도 충분히 파괴적인 결과를 낼 수 있다. 서비스는 소프트웨어가 되지는 않겠지만, 점점 더 소프트웨어와 닮아갈 것이다. 그리고 그 거대한 시장에서 책임과 신뢰를 확보한 기업이 진정한 승자가 될 것이다.
관련 글
]]>요즘 클로드 코드를 사용하면서 마치 처음 프로그래밍을 배웠을 때와 같은 설레임을 다시 느끼고 있다. 단순히 코드를 대신 짜주는 기계를 넘어 내 머릿속의 아이디어를 현실로 구현해주는 가장 든든한 파트너를 만난 기분이다. 특히 최근에 발견하여 유용하게 사용하고 있는 'Superpowers’라는 플러그인은 내가 일하는 방식 자체를 완전히 바꾸어 놓았다. 처음에는 그저 편리한 도구 중 하나라고 생각했지만, 실제로 깊이 있게 파고들수록 이 플러그인이 지향하는 '생각하는 AI’의 가치가 얼마나 큰지 깨닫게 되었다. 단순히 프롬프트를 입력하고 결과를 기다리는 방식에서 벗어나 시스템화된 워크플로우를 통해 결과물의 품질을 극대화하는 과정은 그 자체로 놀라운 경험이다.
이 플러그인은 Jesse Vincent가 만든 오픈소스 Skills 프레임워크를 기반으로 한다. 2026년 1월에 Anthropic 마켓플레이스에 등재된 이후 벌써 버전 5까지 진화하며 에이전틱 코딩의 새로운 표준을 제시하고 있다. 내가 이 도구에 열광하는 이유는 클로드가 작업을 시작하기 전에 무엇을 만들려는지 스스로 묻고, 설계를 확정하고, 작업을 쪼개서 실행하는 '사고의 과정’을 강제하기 때문이다. 대다수의 사용자가 인공지능에게 “블로그 글 써줘” 혹은 "이 기능 구현해줘"라고 단편적인 명령을 내리지만, Superpowers는 그 사이에 촘촘한 파이프라인을 구축해준다.
핵심 워크플로우는 총 6단계로 나뉜다. 첫 번째는 브레인스토밍 단계다. 클로드는 사용자의 요청을 받자마자 코드를 짜지 않는다. 대신 무엇을 만들려는지 상세히 질문하고 대안을 탐색하며 디자인을 섹션별로 쪼개어 제안한다. 사용자가 이 설계에 동의해야만 다음 단계로 넘어간다. 두 번째는 스펙 확정이다. 대화에서 도출된 설계를 문서로 정리하고 사용자의 승인을 받는다. 세 번째 단계인 실행 계획 수립에서는 전체 작업을 2분에서 5분 내외의 마이크로 태스크로 분해한다. 각 태스크에는 정확한 파일 경로와 코드, 그리고 검증 단계가 포함된다. 이 정도로 세밀하게 계획을 세우기 때문에 나중에 발생할 오류가 획기적으로 줄어든다.
네 번째 단계가 가장 인상적인데, 바로 서브에이전트 실행이다. 계획된 각 마이크로 태스크마다 별도의 AI 에이전트를 띄워 병렬로 처리한다. 한 에이전트는 오직 하나의 작업에만 집중하므로 컨텍스트가 섞이거나 길을 잃는 일이 없다. 다섯 번째는 코드 리뷰 단계다. 작성된 결과물이 처음에 정한 스펙을 준수하는지, 그리고 코드의 품질이 적절한지 2단계에 걸쳐 검토한다. 마지막으로 모든 테스트를 통과하면 머지나 PR 중 하나를 선택해 작업을 완료한다. 이 모든 과정이 사용자의 특별한 개입 없이 자동으로 발동한다는 점이 이 플러그인의 진짜 무서운 점이다.
최근 업데이트된 버전 5에서는 시각적 브레인스토밍 기능이 추가되었다. 이전에는 클로드가 디자인이나 구조를 설명할 때 텍스트나 아스키 아트를 주로 사용했다면, 이제는 HTML로 렌더링하여 브라우저에서 직접 결과물을 보여준다. 목업이나 다이어그램을 실제 화면으로 보면서 피드백을 주고받을 수 있게 된 것이다. 개발자뿐만 아니라 마케터나 기획자들에게도 이 기능은 엄청난 혁신이다. 상상만 하던 캠페인 구조나 웹 페이지 레이아웃을 즉석에서 시각화하여 검토할 수 있기 때문이다.
또한 버전 5부터는 서브에이전트 방식이 기본값으로 설정되었다. 제작자의 설명에 따르면 지난 수개월간의 데이터를 분석한 결과 서브에이전트를 활용한 방식이 작업의 성공률과 효율성 면에서 압도적이었다고 한다. 비용 최적화 측면에서도 발전이 있었다. 브레인스토밍과 계획 수립 단계에서는 고성능 모델을 사용해 정교하게 설계하고, 실제 단순 구현 단계에서는 상대적으로 저렴한 모델을 활용해 리소스를 아낀다. 여기에 ‘계획 문서 자동 검증’ 기능이 더해져, AI가 흔히 범하는 실수 중 하나인 ‘나중에 채우기(TBD)’ 같은 무책임한 주석을 사전에 차단한다.
재미있는 점은 이 도구가 개발자만을 위한 것이 아니라는 사실이다. '먼저 생각하고, 계획을 세우고, 쪼개서 실행하고, 검토한다’는 원칙은 비즈니스의 모든 영역에 적용된다. 마케팅 캠페인을 기획할 때도 브레인스토밍 스킬을 통해 아이디어를 도출하고, 이를 마이크로 태스크로 분해하여 리서처, 라이터, 에디터 역할을 하는 서브에이전트들에게 병렬로 맡길 수 있다. 브랜드의 톤앤매너를 정의한 파일을 스킬에 등록해두면 모든 산출물이 일관된 보이스를 유지하도록 검수까지 마쳐준다. 자신만의 ‘Skills’ 파일을 만들어두면 매번 같은 설명을 반복할 필요 없이 최상의 결과물을 얻을 수 있는 시스템이 구축되는 셈이다.
나는 이러한 변화를 '인간 능력의 민주화’라는 관점에서 바라본다. 과거에는 창의적인 아이디어가 있어도 그것을 구현하기 위한 기술적 장벽이 너무 높았다. 하지만 이제는 누구나 자신의 생각을 논리적인 구조로 치환할 수 있다면 인공지능의 도움을 받아 전문가 수준의 결과물을 만들어낼 수 있다. 누군가는 기계가 인간의 창작 과정을 가로챘다고 우려할지도 모른다. 하지만 나에게 코딩이나 기획은 여전히 즐거운 놀이다. Superpowers 같은 도구는 그 놀이터를 무한히 확장해줄 뿐이다. 이전에는 환경 설정이나 단순 반복 작업에 에너지를 뺏겨 포기했던 수많은 아이디어를 이제는 하나씩 현실로 끄집어낼 수 있게 되었다.
결국 중요한 것은 AI를 어떻게 부리느냐가 아니라, 어떤 문제를 해결하고 싶은지 정의하는 능력이다. AI는 지루한 '배관 작업’을 대신 해줌으로써 우리가 더 높은 차원의 설계와 문제 해결이라는 본질에 집중하게 해준다. 80세의 사용자가 다시 파이썬 코드를 공부하고, 은퇴를 앞둔 개발자가 다시 열정을 불태우는 사례들을 보며 기술이 인간에게 줄 수 있는 축복이 무엇인지 다시금 생각한다. 기술은 변하지만 무언가를 만들어내고자 하는 인간의 원초적인 욕구는 변하지 않는다. 나는 클로드 코드와 Superpowers 플러그인을 통해 그 욕구를 더 마음껏 발산하고 있다.
앞으로 더 많은 도구가 나오고 세상은 더 빠르게 변할 것이다. 그 속에서 길을 잃지 않으려면 결국 자신만의 가치관과 프로세스를 정립해야 한다. 단순히 결과물을 빨리 얻는 것에 만족하지 않고, 그 과정에서 어떤 가치를 창출할 것인지 고민하는 사람들에게 이 플러그인은 최고의 지렛대가 되어줄 것이다. 내일은 또 어떤 새로운 스킬을 정의하고 실험해볼지 벌써부터 기대가 된다. 창작의 문턱이 낮아진 이 시대에 우리에게 필요한 것은 오직 멈추지 않는 상상력과 그것을 실행에 옮길 수 있는 약간의 도구뿐이다.
관련 글
]]>최근 AI 코딩 툴의 급격한 발전으로 인해 개발자 커뮤니티 내에서 묘한 균열이 감지되고 있다. 어떤 이들은 자신이 평생 갈고닦아온 기술적 장인정신이 훼손되는 것에 대해 깊은 상실감을 느끼고, 또 다른 이들은 전례 없는 생산성의 파도를 타며 즐거워한다. 이러한 현상을 다룬 흥미로운 글을 읽었는데, AI가 개발자들 사이에 원래 존재했지만 보이지 않았던 본질적인 차이를 드러내고 있다는 분석이었다. 예전에는 모두가 똑같은 방식으로 코드를 짰기 때문에 보이지 않았던 동기의 차이가, 이제는 AI라는 도구를 대하는 태도에 따라 선명하게 갈리고 있다.
한 글에서는 이를 '애도와 AI의 분열’이라는 키워드로 설명한다. 저자는 AI 지원 코딩이 그동안 숨겨져 있던 개발자들의 두 가지 부류를 폭로하고 있다고 말한다. 첫 번째는 코드를 짜는 행위 그 자체, 즉 텍스트를 한 줄씩 정성껏 써 내려가며 논리를 구축하는 과정에서 아름다움과 희열을 느끼는 ‘장인’ 그룹이다. 두 번째는 코드가 무엇으로 이루어졌든 상관없이 그 결과물이 가져다주는 기능과 목적 달성에 집중하는 ‘실행가’ 그룹이다. 이전에는 두 그룹 모두 동일한 에디터에서 동일한 언어로 코드를 작성했기에 겉으로는 구분이 불가능했다. 하지만 이제는 기계에게 코딩을 맡기고 결과물의 방향을 지시할 것인지, 아니면 여전히 자신의 손으로 조각하듯 코드를 써 내려갈 것인지 선택해야 하는 갈림길에 섰다.
James Randall이나 Nolan Lawson 같은 개발자들의 글을 보면 이 ‘장인’ 그룹이 느끼는 상실감이 얼마나 큰지 알 수 있다. 그들은 마치 숙련된 조각가가 찰흙을 만지며 형태를 빚어내듯 코드를 다루는 느낌을 그리워한다. 새벽 2시까지 버그와 씨름하다가 마침내 해결했을 때의 그 짜릿한 쾌감, 자신이 직접 만든 저장소 하단에 '내가 만들었음’이라고 서명을 남길 때의 그 자부심이 AI의 등장으로 희석되고 있다는 것이다. 그들에게 코딩은 단순한 노동이 아니라 자아를 투영하고 표현하는 예술적 행위에 가까웠기 때문이다. 그들이 느끼는 슬픔은 단순히 도구가 바뀐 것에 대한 거부감이 아니라, 자신의 정체성을 지탱하던 공예의 본질이 사라지는 것에 대한 진심 어린 애도다.
하지만 나의 생각은 조금 다르다. 나는 이전부터 코딩은 내 아이디어를 구현하기 위한 하나의 수단일 뿐이라고 생각해 왔다. 누군가에게는 코딩이 예술적인 카타르시스를 주는 행위일 수도 있겠지만, 적어도 나에게 있어 산업 현장에서의 코딩은 비즈니스 가치를 창출하기 위한 공학적 프로세스다. 코드는 예술 작품이 아니며, 문제를 해결하기 위한 도구이자 수단일 뿐이다. 반 고흐의 그림이 그 자체로 독창적인 가치를 지니는 것은 인간의 고뇌를 담은 단 하나의 결과물이기 때문이지만, 코드는 실행되어 의도한 결과를 내놓을 수만 있다면 그 소스가 AI에 의해 생성되었든 사람이 직접 타이핑했든 상관없다. 개발자를 예술가로 정의하는 것 자체가 이미 소프트웨어 개발의 본질을 오해하고 있는 것이 아닐까 생각한다.
컴퓨터 공학의 역사를 돌이켜보면 지금의 변화는 전혀 낯선 것이 아니다. 우리는 이미 수많은 추상화 단계를 거쳐왔다. 1980년대에 코모도어 64에서 어셈블리어로 코딩하던 시절에는 메모리 주소 하나하나를 직접 관리하는 것이 실력이었다. 하지만 더 복잡한 프로그램을 만들기 위해 고수준 언어가 등장했고, 그때마다 누군가는 '진정한 제어권을 잃었다’며 한탄했다. 어셈블리어에서 C언어로, 다시 자바나 파이썬으로 발전해온 과정 자체가 개발자가 기계의 내부 구조를 덜 신경 써도 더 큰 시스템을 설계할 수 있게 해주는 추상화의 역사였다. AI 코딩은 이 추상화의 사다리에서 한 단계 더 위로 올라가는 과정일 뿐이다. 이제 우리의 퍼즐은 개별 함수를 어떻게 짤 것인가가 아니라, 전체적인 시스템 아키텍처를 어떻게 구성하고 어떤 방향으로 서비스를 이끌 것인가로 이동했다.
생산성이라는 측면에서 AI는 그야말로 축복이다. 이전에 쓴 글에서도 언급했듯이, 똑같은 결과물을 10배, 100배 빠르게 낼 수 있다는 사실 자체가 혁신의 정의다. 과거에는 게시판 하나를 만드는 데도 수많은 보일러플레이트 코드를 작성하며 시간을 허비해야 했지만, 이제는 그런 지루한 작업을 AI에게 맡기고 더 복잡한 비즈니스 로직이나 사용자 경험을 고민하는 데 집중할 수 있다. 자동차 공장에서 로봇이 용접을 하는 것을 보고 '사람의 손맛이 없다’고 비난하는 것이 의미 없듯이, 개발 영역에서도 더 효율적인 도구가 나왔다면 그것을 활용해 더 많은 가치를 창출하는 것이 프로의 자세다. 도구가 좋아졌다면 우리는 그 도구를 딛고 올라서서 더 높은 수준의 창의성을 발휘해야 한다.
물론 AI가 생성하는 코드가 완벽하지 않다는 지적도 있다. 소위 '슬롭(slop)'이라 불리는 저품질 코드가 양산될 수 있다는 우려다. 하지만 질 낮은 코드와 버그는 AI가 등장하기 전에도 늘 존재했다. 과거에도 실력 없는 개발자는 인터넷에서 복사해 온 코드를 이해하지 못한 채 붙여넣어 문제를 일으켰다. 지금 우리 눈에 저품질 코드가 더 많이 보이는 이유는 전체적인 생산 총량이 늘어났기 때문이지 AI 자체가 원인은 아니다. 오히려 우리는 AI가 생성한 코드를 검증할 수 있는 테스트 자동화, 정적 분석 도구, 보안 스캔 시스템 등을 이미 갖추고 있다. 인간이 코드를 직접 읽고 검토하는 것만이 유일한 해결책은 아니며, AI를 활용해 더 촘촘한 검증 레이어를 만드는 것이 훨씬 생산적인 방향이다.
흥미롭게도 Les Orchard의 글에서 언급된 '남아있는 슬픔’에 대해서는 나도 깊이 공감하는 부분이 있다. 그것은 코드를 직접 짜지 못하는 것에 대한 아쉬움이 아니라, 코드를 둘러싼 환경이 변하는 것에 대한 불안감이다. 오픈 웹 생태계가 거대 기업들의 데이터 학습장으로 전락하거나, 개발자의 커리어 지형도가 급격하게 변하는 것은 분명 두려운 일이다. 지난 30년 넘게 웹 개발이 주류였지만 이제는 AI 엔지니어링이 그 자리를 대체하고 있다. 이러한 변화 속에서 우리가 가진 기술이 구식이 될지 모른다는 불안감은 실존적인 문제다. 하지만 이것은 도구의 문제가 아니라 시대의 흐름이다. 환경이 변한다면 우리는 그에 맞춰 새로운 가치를 찾아야 한다.
장인정신이라는 이름 뒤에 숨어 과거의 방식을 고수하는 것은 변화하는 시대를 거부하는 방어 기제에 불과할 수 있다. 훌륭한 목수는 전동 드릴을 쓴다고 해서 자신의 기술이 퇴보한다고 생각하지 않는다. 오히려 그 도구 덕분에 더 견고하고 복잡한 가구를 더 빨리 만들 수 있게 된 것을 기뻐한다. 우리도 마찬가지다. 코드 한 줄 한 줄에 소울을 담는 고행에서 벗어나, AI와 함께 더 높은 곳으로 올라가야 한다. 생산성이 높아졌기 때문에 우리는 더 많은 시도를 할 수 있고, 더 빠르게 실패하며, 결과적으로 더 나은 세상을 만드는 데 기여할 수 있다.
결국 이번에 드러난 '분열’은 개발자로서 우리가 무엇을 지향하는지를 묻고 있다. 텍스트를 타이핑하는 행위 자체에 가치를 둘 것인가, 아니면 문제를 해결하고 새로운 것을 창조하는 결과에 가치를 둘 것인가. 나는 주저 없이 후자를 선택한다. AI라는 거대한 흐름은 이미 시작되었고 이를 막을 방법은 없다. 그렇다면 이 강력한 파도에 올라타서 어디까지 갈 수 있는지 시험해 보는 것이 더 흥미로운 일이 아닐까.
관련 글
]]>최근 AI 관련 뉴스를 챙겨보다가 가슴을 때리는 문장을 하나 발견했다. OpenAI의 연구원인 에이단 맥롤린이 남긴 말인데, LLM에 대한 자신의 야망을 높이는 것이야말로 가장 높은 수익을 가져다주는 활동이라는 내용이었다. 에이단은 지난 3년 동안 AI 분야를 취재하고 직접 만져보면서 느낀 가장 큰 후회가 바로 이것이라고 고백했다. 적당히 미친 사람들은 LLM을 한계까지 밀어붙여서 그 혜택을 온전히 누리고 있는 반면, 당시의 LLM 수준에 맞춰서 판단하고 관리하려 했던 실용적인 사람들은 결국 제자리에 머물렀다는 것이다. 이 대목에서 나 자신을 돌아보게 됐다. 나는 과연 이 도구를 가지고 무엇을 할 수 있을지 충분히 미친 생각을 해보고 있는 걸까?
야망의 부족이 병목이라는 말은 단순히 마음가짐의 문제가 아니다. 이는 우리가 AI를 대하는 기술적인 접근 방식과도 맞닿아 있다. 이제 더 이상 모델의 품질 자체가 병목인 시대는 지나가고 있다. 요즘 업계에서 공통적으로 나오는 이야기는 모델을 둘러싼 ‘하네스’, 즉 도구와 메모리, 런타임 그리고 이를 아우르는 시스템의 설계가 훨씬 더 중요하다는 것이다. 해리슨 체이스 같은 전문가들도 이제는 에이전트의 UI와 UX, 샌드박스 환경, 파일 시스템 접근 권한 같은 것들이 핵심적인 제품의 가치를 결정한다고 강조한다. 모델이 똑똑해지는 속도보다 우리가 그 똑똑함을 담아낼 그릇을 만드는 속도가 더 중요하다는 뜻이다.
코딩 에이전트 분야를 봐도 이런 변화는 뚜렷하다. 단순히 코드를 짜주는 것을 넘어 이제는 시스템 전체를 이해하고 효율적으로 작동하는지가 관건이다. 커서(Cursor) 팀이 발표한 새로운 벤치마킹 방법론인 커서벤치(CursorBench)는 시사하는 바가 크다. 기존의 공공 벤치마크들이 포화 상태에 이르자, 실제 사용자들의 요청 데이터와 온라인/오프라인 지표를 결합해서 모델의 지능뿐만 아니라 효율성까지 측정하기 시작했다. 여기서 흥미로운 점은 GPT-5.4가 정확도와 토큰 사용 효율성 측면에서 압도적인 성적을 거두었다는 사실이다. 하지만 동시에 ‘인간을 루프 안에 두는’ 도구들이 여전히 중요하다는 목소리도 높다. 완전 자율 코딩보다는 빠른 인라인 자동 완성이 개발자의 인지 부하를 줄이고 이해도를 유지하는 데 더 유리하다는 의견도 설득력이 있다. 결국 야망이라는 것은 단순히 모든 것을 자동화하겠다는 욕심이 아니라, 인간과 AI가 결합된 새로운 개발 프로세스를 어떻게 더 높은 차원으로 끌어올릴 것인가에 대한 고민이어야 한다.
검색과 정보 추출 방식에서도 큰 변화가 감지되고 있다. 구글이 내놓은 제미나이 임베딩 2는 텍스트와 이미지, 오디오, 비디오, PDF를 하나의 벡터 공간으로 매핑하는 최초의 네이티브 멀티모달 임베딩 모델이다. 하지만 기술적으로 더 흥미로운 지점은 단일 벡터 방식과 다중 벡터 방식의 대결이다. 최근 전문가들 사이에서는 콜버트(ColBERT)나 콜팔리(ColPali) 스타일의 지연 상호작용(Late Interaction) 방식이 단일 벡터 임베딩보다 훨씬 뛰어난 성능을 보인다는 주장이 힘을 얻고 있다. 단일 벡터 임베딩에 계속 베팅하는 것은 비이성적이라는 극단적인 표현까지 나올 정도다. 이는 우리가 정보를 저장하고 불러오는 방식조차도 훨씬 더 정교하고 복잡한 구조로 나아가야 한다는 점을 시사한다. 단순히 똑똑한 모델에게 질문을 던지는 수준을 넘어, 방대한 데이터를 모델이 가장 잘 소화할 수 있는 형태로 재구성하는 능력이 필요하다.
모델의 효율성 측면에서도 주목할 만한 소식들이 많다. 엔비디아가 발표한 네모트론 3 슈퍼(Nemotron 3 Super)는 120B 규모의 오픈 웨이트 모델인데, 아키텍처 측면에서 상당히 혁신적이다. LatentMoE 설계를 통해 라우팅 비용을 줄이면서도 더 많은 전문가를 활용할 수 있게 만들었다. 이는 단순히 벤치마크 점수를 올리기 위한 변화가 아니라 추론 경제성을 극대화하려는 시도다. 일론 머스크의 그록(Grok) 4.20 역시 최고 성능은 아니더라도 200만 토큰에 달하는 거대한 컨텍스트 윈도우와 저렴한 가격, 빠른 속도를 무기로 시장을 공략하고 있다. 이런 현상들은 우리가 모델을 선택할 때 ‘가장 똑똑한 것’ 하나에만 매몰될 필요가 없음을 보여준다. 상황에 맞게 비용과 속도, 성능을 조합해서 최적의 결과물을 만들어내는 설계 능력이 더 중요해진 것이다.
로컬 환경에서의 AI 구동도 이제는 현실적인 영역으로 들어왔다. 최근 애플의 M5 맥스 노트북에 대한 벤치마크 결과를 보면 128GB 메모리를 활용해 120B가 넘는 거대 모델들을 효율적으로 돌리는 모습이 인상적이다. 레딧 같은 커뮤니티에서는 Qwen 3.5 모델을 다양한 방식으로 양자화해서 사용하는 방법들이 공유되고 있는데, 특히 바르토프스키(bartowski)의 양자화 방식이 안정성과 성능 면에서 좋은 평가를 받고 있다. RTX 3060 같은 소비자용 GPU에서도 9B 규모의 모델이 훌륭하게 코딩 에이전트 역할을 수행한다는 보고는 우리에게 시사하는 바가 크다. 이제 고가의 서버 비용을 걱정하지 않고도 개인 수준에서 충분히 미친 실험들을 해볼 수 있는 환경이 갖춰진 것이다.
결국 다시 원점으로 돌아와서 질문하게 된다. ‘어떻게 내 야망을 키울 것인가’ 이 질문은 우리가 매일 마주하는 LLM에게 직접 물어봐야 할 질문이기도 하다. 모델의 한계는 우리가 정해놓은 고정관념에서 비롯될 때가 많다. LLM을 단순히 텍스트를 생성하는 도구로 보느냐, 아니면 나의 야망을 현실로 만들어줄 거대한 엔진으로 보느냐에 따라 우리가 얻을 수 있는 결과물은 천지차이가 될 것이다.
관련 글
]]>요즘 인공지능 분야에서 가장 뜨거운 화두를 하나 꼽으라면 단연 에이전트라고 할 수 있다. 단순히 질문에 답을 하는 챗봇의 수준을 넘어, 이제는 스스로 도구를 사용하고 복잡한 계획을 세워 실행하는 에이전트의 시대가 오고 있다. 하지만 에이전트가 완벽하게 자율적으로 모든 일을 처리하기를 기대하는 것은 아직 시기상조일 수 있다. 자율성이라는 이름 아래 에이전트가 통제 불능의 상태에 빠지거나 엉뚱한 결과를 내놓는 경우를 자주 보게 되기 때문이다. 그래서 필요한 것이 바로 워크플로우다. 워크플로우는 에이전트의 자율성에 구조를 부여하고, 복잡한 문제를 해결하기 위해 에이전트의 능력을 특정한 방향으로 이끄는 실행 패턴을 의미한다.
워크플로우를 이해하기 위해 제조 공장의 조립 라인을 떠올려보면 쉽다. 각 스테이션에는 특정 작업을 전문으로 하는 숙련된 노동자들이 배치되어 있고, 이들은 자신이 맡은 범위 안에서 자율적인 판단을 내린다. 하지만 전체적인 공정의 흐름은 미리 설계되어 있다. 어떤 부품이 먼저 들어와야 하는지, 다음 단계로 넘어가기 위해 어떤 검사를 거쳐야 하는지가 명확하다. 에이전트 워크플로우도 이와 같다. 모든 것을 에이전트가 결정하도록 내버려 두는 것이 아니라, 전체적인 실행 경로를 정의하고 각 단계에서 에이전트가 추론과 도구 사용을 할 수 있는 경계선을 설정해 주는 것이다. 이렇게 하면 예측 가능한 결과를 얻으면서도 에이전트 특유의 유연함을 동시에 챙길 수 있다.
최근 공개된 기술 자료들을 살펴보면 실제 프로덕션 환경에서 가장 많이 쓰이는 워크플로우 패턴은 크게 세 가지로 압축된다. 바로 순차적 워크플로우, 병렬 워크플로우, 그리고 평가자-최적화 워크플로우다. 각각의 패턴은 해결하고자 하는 문제의 성격에 따라 뚜렷한 장단점을 가지고 있다. 어떤 패턴을 선택하느냐에 따라 서비스의 응답 속도인 레이턴시와 비용, 그리고 결과물의 신뢰도가 크게 달라지기 때문에 각 패턴의 특성을 정확히 이해하는 것이 중요하다. 무작정 복잡한 구조를 도입하기보다는 내가 해결하려는 문제가 어떤 구조에 가장 적합한지를 먼저 따져봐야 한다.
순차적 워크플로우는 이름에서 알 수 있듯이 이 패턴은 작업을 정해진 순서대로 하나씩 처리하는 방식이다. 각 단계의 에이전트는 이전 단계의 결과물을 입력값으로 받아 자신의 작업을 수행하고, 그 결과를 다시 다음 단계로 넘겨준다. 이 방식의 가장 큰 장점은 복잡한 작업을 작은 단위로 쪼개어 각 에이전트가 하나에만 집중하게 함으로써 정확도를 높일 수 있다는 점이다. 한꺼번에 너무 많은 일을 시키면 에이전트가 혼란을 겪을 수 있지만, 순차적으로 하나씩 처리하면 실수가 줄어든다.
예를 들어 마케팅 문구를 생성하고 이를 여러 언어로 번역하는 작업을 한다고 가정해보자. 한 명의 에이전트에게 '창의적인 문구를 쓰고 번역까지 다 해줘’라고 시키는 것보다, 먼저 한 에이전트가 문구 작성에만 집중하게 하고 그 결과물이 확정되면 다른 에이전트가 번역을 수행하도록 구성하는 것이 훨씬 안정적이다. 또한 문서에서 데이터를 추출하고 이를 스키마에 맞춰 검증한 뒤 데이터베이스에 저장하는 파이프라인도 전형적인 순차적 워크플로우의 사례다. 다만 이 패턴의 치명적인 단점은 속도다. 앞선 단계가 끝나야만 다음 단계가 시작될 수 있으므로 전체 처리 시간은 각 단계의 소요 시간을 모두 합친 만큼 길어지게 된다.
병렬 워크플로우는 독립적인 여러 작업을 동시에 실행한 뒤 나중에 그 결과들을 하나로 합치는 방식이다. 분산 시스템에서 흔히 말하는 ‘팬아웃/팬인’ 구조와 유사하다. 이 패턴은 작업들이 서로 의존성이 없을 때 강력한 힘을 발휘한다. 각 에이전트가 서로를 기다릴 필요 없이 동시에 움직이기 때문에 전체적인 처리 시간을 비약적으로 단축할 수 있다. 또한 여러 개의 시각이나 관점이 필요할 때도 유용하다.
병렬 워크플로우의 대표적인 사례는 복합적인 코드 리뷰나 문서 분석이다. 한 에이전트는 보안 취약점만 집중적으로 파헤치고, 다른 에이전트는 코드의 성능을 분석하며, 또 다른 에이전트는 스타일 가이드 준수 여부를 확인하게 할 수 있다. 이들은 동시에 작업을 수행하고 마지막에 모든 리뷰 결과를 취합하여 사용자에게 보여준다. 이렇게 하면 한 명의 에이전트가 모든 요소를 다 살피는 것보다 훨씬 깊이 있는 분석이 가능해진다. 하지만 병렬 구조를 설계할 때는 결과물을 어떻게 합칠 것인지에 대한 전략이 반드시 필요하다. 여러 에이전트의 의견이 충돌할 때 다수결로 정할 것인지, 아니면 특정 전문가 에이전트의 의견에 우선순위를 둘 것인지 미리 결정해야 한다.
평가자-최적화 워크플로우는 생성과 평가라는 두 가지 역할을 나누어 반복적인 개선을 끌어내는 패턴이다. 한 에이전트가 결과물을 만들어내면, 다른 에이전트가 이를 정해진 기준에 따라 평가하고 피드백을 준다. 생성 에이전트는 이 피드백을 바탕으로 결과물을 수정하고, 이 과정은 목표 퀄리티에 도달할 때까지 반복된다. 사람이 초안을 쓰고 사수에게 검토를 받은 뒤 수정안을 만드는 과정과 매우 흡사하다.
이 패턴은 결과물의 품질이 무엇보다 중요할 때 빛을 발한다. 특히 전문적인 비즈니스 이메일 작성이나 복잡한 SQL 쿼리 생성, 기술 문서 작성 등에 효과적이다. 생성하는 뇌와 평가하는 뇌를 분리함으로써 각 에이전트가 자신의 역할에만 최적화될 수 있기 때문이다. 평가자는 매우 엄격한 기준을 적용할 수 있고, 생성자는 그 기준을 통과하기 위해 계속해서 결과물을 다듬는다. 하지만 이 방식은 토큰 소모량이 매우 많고 반복 횟수만큼 레이턴시가 늘어난다는 점을 명심해야 한다. 무한 루프에 빠지지 않도록 최대 반복 횟수를 설정하거나, '이 정도면 충분하다’는 종료 조건을 명확히 하는 것이 필수적이다.
많은 개발자가 에이전트 시스템을 구축할 때 어떤 패턴을 고를지 고민한다. 이에 대한 실용적인 조언은 가장 단순한 것부터 시작하라는 것이다. 사실 많은 경우 단일 에이전트에게 명확한 프롬프트를 주는 것만으로도 충분한 결과가 나온다. 굳이 워크플로우를 쪼개고 복잡한 오케스트레이션을 도입할 필요가 없을 때도 많다는 뜻이다. 한 번의 호출로 해결이 가능하다면 그게 비용 면에서나 유지보수 면에서나 최선이다. 하지만 단일 에이전트가 한계를 보이기 시작할 때 비로소 워크플로우를 고민해야 한다.
먼저 작업을 순차적으로 쪼개보고, 그중에서 동시에 돌릴 수 있는 부분이 있다면 병렬화를 도입하며, 마지막에 품질이 도저히 만족스럽지 않을 때 평가-최적화 루프를 추가하는 식의 단계적 접근이 필요하다. 또한 이 패턴들은 서로 배타적인 것이 아니다. 순차적 워크플로우의 특정 단계 안에서 병렬 처리가 일어날 수도 있고, 병렬 처리된 결과물을 합치는 과정에서 평가자-최적화 루프가 돌아갈 수도 있다. 하지만 구조가 복잡해질수록 디버깅은 기하급수적으로 어려워진다는 사실을 잊어서는 안 된다.
성공적인 에이전트 설계를 위해서는 각 단계에서의 실패 처리 전략도 꼼꼼히 세워야 한다. 특정 단계의 에이전트가 응답하지 않거나 잘못된 형식의 데이터를 내놓았을 때 전체 시스템이 멈추지 않도록 재시도 로직이나 폴백 메커니즘을 갖추는 것이 중요하다. 또한 각 워크플로우가 실제로 성능 향상을 가져오는지 측정할 수 있는 기준선이 있어야 한다. 단순히 '복잡하니까 더 잘하겠지’라는 막연한 기대보다는, 단일 에이전트 대비 정확도가 얼마나 올라갔는지 혹은 레이턴시가 얼마나 줄었는지를 수치로 확인해야 한다.
개인적인 경험을 돌이켜보면 나 역시 처음에는 복잡하고 멋진 다중 에이전트 시스템을 구축하고 싶은 욕심이 컸다. 여러 대의 에이전트가 서로 대화하며 문제를 해결하는 모습은 마치 공상과학 영화의 한 장면처럼 매력적이기 때문이다. 하지만 실제로 서비스를 만들다 보면 가장 단순한 구조가 가장 강력할 때가 많다는 것을 깨닫게 된다. 현재 나의 관점에서는 아직까진 단일 에이전트로 해결할 수 있는 영역이 꽤 넓다고 보고 있다. 하지만 에이전트에게 맡겨야 할 작업의 복잡도가 점점 높아지고 있는 만큼, 앞으로는 이러한 워크플로우 패턴들을 더 적극적으로 시도해보고 정밀하게 테스트해 볼 생각이다.
관련 글
]]>최근 기술 블로그들을 읽다 보면 AI가 코딩의 영역을 침범하면서 개발의 '소울’이 사라지고 있다는 한탄을 자주 마주하게 된다. 어떤 글에서는 AI가 제공하는 추상화 계층이 너무 두꺼워져서 개발자가 실제 코드가 어떻게 돌아가는지 이해하지 못하는 상태를 우려하기도 했다. 이런 시각을 가진 이들은 한 땀 한 땀 코드를 직접 짜던 시절의 고통을 장인정신으로 미화하며, AI가 만들어낸 결과물을 영혼 없는 복제품 취급하곤 한다. 하지만 나는 이런 감상적인 접근이 매우 위험하고 고리타분하다고 생각한다. 코딩에서 소울을 찾는 것 자체가 이미 개발의 본질을 오해하고 있다는 증거이기 때문이다.
내가 이전에도 강조했듯이 코드는 예술 작품이 아니다. 코드는 문제를 해결하기 위한 도구이자 수단일 뿐이다. 누군가는 코딩을 하며 예술적인 카타르시스를 느낄 수도 있겠지만, 산업 현장에서의 코딩은 철저하게 비즈니스 가치를 창출하기 위한 공학적 프로세스다. AI가 짠 코드에 소울이 없다고 비판하는 것은 마치 공장에서 찍어낸 나사가 수작업으로 깎은 나사보다 소울이 없어서 못 쓰겠다고 말하는 것과 다를 바 없다. 사용자는 그 코드가 AI에 의해 1초 만에 생성되었는지, 사람이 며칠 밤을 새우며 짰는지 전혀 관심이 없다. 그들에게 중요한 것은 오직 그 프로그램이 자신의 문제를 제대로 해결해주는가 하는 점이다.
추상화에 대한 공포도 마찬가지다. 컴퓨터 공학의 역사는 곧 추상화의 역사다. 어셈블리어에서 C언어로, 다시 자바나 파이썬 같은 고수준 언어로 발전해온 과정 자체가 개발자가 기계의 내부 구조를 몰라도 더 복잡한 로직을 짤 수 있게 해주는 추상화의 연속이었다. AI는 그저 그 추상화의 단계를 한 단계 더 높인 것뿐이다. '소울’을 운운하며 밑바닥부터 모든 것을 직접 해야 한다고 주장하는 것은, 현대 개발자가 여전히 진공관의 원리를 이해하고 직접 회로를 설계해야 한다고 우기는 것만큼이나 시대착오적이다. 도구가 좋아졌다면 우리는 그 도구를 딛고 올라서서 더 높은 수준의 아키텍처와 비즈니스 모델을 고민해야 한다.
생산성이라는 측면에서 AI는 축복이다. 예전에는 단순한 CRUD 기능을 구현하는 데만도 수많은 보일러플레이트 코드를 작성하며 시간을 허비해야 했다. 하지만 이제 Claude Code 같은 도구를 쓰면 그런 지루한 작업은 순식간에 끝난다. 이렇게 확보한 시간은 개발자에게 더 큰 창의성을 발휘할 기회를 준다. 이전 글에서 언급했듯이, 60세가 넘은 개발자가 AI 덕분에 다시 열정을 찾는 사례는 시사하는 바가 크다. 그가 다시 코딩의 즐거움을 느낀 이유는 문법을 외우고 타이핑하는 고통이 사라지고, 자신이 상상하던 아이디어를 즉각 결과물로 확인할 수 있게 되었기 때문이다. 이것이 바로 진정한 개발의 즐거움이지, 코드 한 줄 한 줄에 소울을 담는 고행이 즐거움은 아닐 것이다.
결국 소울이라는 단어는 기술적 도태를 가리기 위한 멋들어진 핑계에 불과하다. 변화에 적응하지 못하고 과거의 수작업 방식에 매몰된 이들이 AI라는 거대한 흐름을 거부하기 위해 꺼내든 카드인 셈이다. 하지만 기술의 역사는 언제나 효율적인 도구를 선택한 이들의 손을 들어주었다. 코딩에서 소울을 찾는 것이 아니라, 당신이 만든 서비스가 사용자에게 줄 수 있는 가치에서 소울을 찾아야 한다. 개발자는 예술가가 아니라 해결사여야 하며, AI는 그 해결 능력을 무한히 확장해주는 가장 강력한 무기다. 고리타분한 장인정신 뒤에 숨어 변화를 깎아내리는 일은 이제 그만두어야 한다.
관련 글
]]>프로그래밍이 죽었다는 말은 사실 과장된 표현이다. 오히려 지금은 그 어느 때보다 역동적으로 변화하고 있는 시기다. 이전까지 우리가 파일 하나하나를 수정하며 정성스럽게 코드를 작성하던 방식이 이제는 에이전트에게 지시를 내리고 그 결과를 조율하는 방식으로 진화하고 있다. 이런 변화 속에서 개발자의 환경은 단순한 에디터를 넘어 하나의 커맨드 센터로 탈바꿈해야 할 운명에 처했다. 우리가 다루는 단위가 파일에서 에이전트로 옮겨가고 있다는 사실을 인지하는 것이 중요하다.
한 흥미로운 시각에 따르면 다음 세대의 VS Code를 누가 차지할 것인가는 이 커맨드 센터를 누가 가장 먼저, 그리고 가장 제대로 정의하느냐에 달려 있다고 한다. 지금까지의 도구들은 인간이 텍스트를 효율적으로 입력하는 데 초점을 맞췄지만, 앞으로는 수많은 에이전트들이 쏟아내는 결과물을 관리하고 감독하는 것이 핵심이 될 것이기 때문이다. 파일 단위의 편집기가 아니라 에이전트들의 작업을 관제하는 시스템이 필요한 시점이다. 하지만 아직 시장에는 그런 역할을 완벽하게 수행하는 도구가 나타나지 않았다.
나는 이런 흐름을 지켜보며 꼭 남이 만들어준 도구가 완성되기를 기다려야 할까라는 의문을 가졌다. 사실 나는 v-terminal이라는 이름의 나만의 터미널을 직접 만들어 사용하고 있다. 내가 필요한 기능이 생기면 직접 코드를 짜서 추가하고, 불편한 점이 있으면 바로 개선해서 나에게 최적화된 환경을 구축했다. 이것은 단순히 터미널을 하나 만드는 행위를 넘어, 에이전트 시대를 대비하는 나만의 작은 커맨드 센터를 짓는 과정이었다. 내가 직접 도구를 빚어보니 왜 아직 시장에 제대로 된 커맨드 센터가 나오지 않았는지 조금은 이해할 수 있었다. 사용자마다 필요한 관제 시스템의 모습이 너무나 다르기 때문이다.
예전 글에서도 언급했듯이 AI 에이전트가 생성하는 코드의 양은 이미 인간의 검토 능력을 넘어서고 있다. 안드레 카파시의 프로젝트처럼 에이전트가 스스로 수만 번의 실험을 거쳐 코드를 최적화하는 상황에서, 우리는 더 이상 파일 단위의 수정을 하나하나 추적할 수 없다. 여기서 필요한 것이 바로 커맨드 센터다. 에이전트가 어떤 실험을 하고 있는지, 현재 도달한 성능 지표는 무엇인지, 그리고 그 과정에서 신뢰할 수 없는 오염이나 버그가 발생하지 않았는지를 한눈에 파악할 수 있는 대시보드가 절실하다. 인간은 이제 타이피스트가 아니라 오케스트라의 지휘자가 되어야 한다.
기존의 IDE들은 여전히 파일 트리와 텍스트 편집 창이라는 고전적인 구조에 갇혀 있다. 하지만 미래의 개발 환경은 에이전트의 상태를 시각화하고, 이들이 사용하는 컴퓨팅 자원을 효율적으로 배분하며, 수많은 실험 결과 중 최적의 결과물을 선택하는 인터페이스가 중심이 되어야 한다. 내가 v-terminal을 고도화하면서 느끼는 점도 이와 비슷하다. 단순한 명령어 입력창을 넘어, 내 작업의 흐름을 이해하고 필요한 정보를 제때 던져주는 도구가 있을 때 생산성은 차원이 달라진다. 기능을 남이 정해준 가이드라인에 맞춰 쓰는 것이 아니라, 내가 필요할 때 직접 개발해서 붙이는 경험은 에이전트 시대에도 유효한 강력한 무기가 된다.
결국 프로그래밍의 본질은 도구를 다루는 기술이 아니라 문제를 해결하는 논리적인 방식에 있다. 단위가 파일에서 에이전트로 바뀌었다고 해서 개발자의 가치가 사라지는 것은 아니다. 오히려 에이전트라는 강력한 조력자를 부리는 군단장이 되어 더 거대한 문제를 풀 수 있는 기회가 왔다. 누군가 완벽한 커맨드 센터를 만들어 가져다주기를 기다리기보다, 지금 당장 내 손에 익은 도구를 깎아서 나만의 지휘소를 만들어보는 것은 어떨까. 그것이 다음 세대의 개발 환경을 선점하고 AI 시대의 오염에 대응하는 가장 확실한 방법일 것이다.
관련 글
]]>