AI 업계에서는 매일 놀라운 일이 일어난다. 그런데 X를 끄고 밖으로 나가면 아주 조용하다. 아무 일도 없는 것처럼 보인다. 나는 이게 버블인지, 정말 초창기라서 그런지 자꾸 되묻게 된다.
에코체임버 안에서는 모든 것이 혁명이다. 밖에서는 아직 매출과 운영이 안 바뀐 회사가 대부분이다. 둘 다 사실일 수 있다. 초창기 기술은 원래 소수의 방에서 요란하고, 거리에서는 안 보인다. 반대로 방 안의 소음만으로 채용과 예산을 늘리면 그게 버블이다. 피드의 밀도는 현장의 밀도가 아니다.
판정 기준은 피드가 아니라 도입이다. 누가 돈을 벌었고, 어떤 운영 지표가 바뀌었는가. 그 숫자가 보이기 전에는 놀라움만으로 산업의 단계를 말하지 않는 편이 맞다. 조용한 밖을 무시하면 늦고, 요란한 안만 믿으면 과하게 산다. 채용과 예산은 피드의 흥분보다 늦게 움직여야 한다. 반대로 현장 도입이 보이는데도 피드를 꺼 둔 채로 무시하면, 초창기를 지나쳐 버린다. 둘을 같은 속도로 믿으면 안 된다. 지금이 어디인지는 둘을 같이 봐야 보인다.
]]>회사 코딩의 대부분은 창의적인 일이 아니었다. 따분한 CRUD와 스택오버플로 복붙이었다. AI가 그 일을 대신하는 것은 엔지니어를 없애는 사건이 아니라, 창의적이지 않았던 일에서 해방되는 일에 가깝다.
의사가 의료기기를 써서 치료해도, 치료한 것은 기기가 아니라 의사다. 코드를 직접 타이핑했느냐는 그만큼 중요하지 않다. 무엇을 만들지 정하고, 틀린 결과를 걸러 내는 판단이 일이다. 타이핑이 사라졌다고 직업이 사라진 것은 아니다. 사라진 것은 반복이 만드는 피로이고, 남는 것은 책임을 지는 결정이다.
남는 질문은 하나다. 우리 업무에서 AI가 대신해도 되는 반복이 어디인지 단정할 수 있는가. 그 시간을 설계와 검증에 쓰지 못하면, 해방은 그냥 빈 시간이 된다. 도구가 반복을 가져간 뒤에야, 비로소 창의적인 일이 뭔지 드러난다. 그 일을 붙잡는 사람이 엔지니어로 남는다. 대체 불안은 타이핑을 직업으로 여길 때 커진다. 수단이 바뀌었을 뿐인데 정체성이 흔들린다면, 그동안 창의적이라고 부른 일의 실체를 다시 봐야 한다.
]]>LLM을 고를 때 내가 보는 것은 지능 점수가 아니다. 이 모델의 말과 행동을 믿고 일을 맡길 수 있는가다. 사람과 일할 때와 같다. 아무리 똑똑하고 자신 있게 말해도, 신뢰가 없으면 일을 넘기지 않는다.
그래서 코드를 안 읽고 결과를 그대로 받는 태도는 이해가 안 된다. 프로토타입은 넘겨도 된다. 결제나 권한 변경처럼 한 번 틀리면 비싼 일은 다르다. 검토를 언제 줄일지는 모델이 똑똑해져서가 아니라, 실패 비용이 작아졌을 때다. 자신감 있는 문장은 증거가 아니다. 같은 실수를 반복하지 않는 기록이 증거다.
신뢰는 한 번에 생기지 않는다. 잘한 작업을 보면 위임 범위를 조금씩 늘린다. 100퍼센트 위임은 목표가 아니다. 어디에 눈을 뗄지를 정하는 것이 목표다. 똑똑함은 입사 조건이고, 신뢰는 일을 맡기는 조건이다. 후자가 없으면 전자는 그냥 말솜씨다. 팀을 운영할 때도 같다. 작은 일을 맡기고, 되돌릴 수 있는 범위에서 실수를 본 다음, 범위를 넓힌다. 모델이라고 이 순서를 건너뛸 이유는 없다.
]]>하네스가 중요하다는 말에는 동의한다. 다만 그 말이 기능을 더 넣으라는 뜻은 아니다. 나는 오히려 반대 방향으로 가고 있다. 점점 비대해지는 셸을 버리고, 내가 원하는 만큼만 확장되는 가벼운 쪽으로 돌아갔다.
기능이 많은 도구는 처음엔 똑똑해 보인다. 곧 설정이 늘고, 기본값이 흔들리고, 모델이 도구 설명서를 읽느라 일을 못한다. 나는 Pi에 확장 세 개만 얹어 쓴다. 웹 접근, 서브에이전트, 컨텍스트 보기. 그 이상이면 내가 도구를 쓰는 게 아니라 도구가 나를 부린다. 필요한 능력이 생기면 그때 붙이면 된다. 미리 모든 버튼을 달아 두면 손은 느려진다.
팀이 쓰는 에이전트도 같은 질문으로 보면 된다. 이 기능이 없어서 막히는가, 아니면 있어서 산만한가. 손에 맞는 도구는 대개 후자가 적은 쪽이다. 하네스는 근육이 아니라 뼈대다. 뼈대가 두꺼워지면 움직이기 어려워진다. 나는 기능 목록을 보고 도구를 고르지 않는다. 하루를 끝낼 때 설정 파일을 얼마나 안 열었는지를 본다. 안 연 날이 많을수록 그 하네스는 내 것이다.
]]>요즘 공개 벤치마크는 식상하고 오염된 느낌이 든다. 점수는 매일 오르는데, 내가 시키는 일에서는 그 순위가 자주 깨진다. 그래서 나는 남이 만든 표 대신, 내가 볼 수 있는 테스트를 하나 만들었다.
내가 쓰는 건 SVG와 AST를 보는 작은 시험이다. 모델에게 같은 그림을 그리게 하고, 결과물을 눈으로 비교한다. 표본은 작고, 이 테스트만으로 모델을 평가할 수는 없다. 그래도 다른 사람의 말에 휘둘리지는 않는다. 광고성 리더보드보다, 내가 내일 다시 시킬 작업에서의 결과가 의사결정에 더 가깝다. 순위표는 판매용이고, 내 테스트는 내일 쓸 도구를 고르는 용도이다.
팀에도 같은 논리가 적용된다. 공식 벤치 1등을 사는 대신, 우리 코드베이스에서 한 시간짜리 미니 벤치를 돌리는 편이 싸다. 완벽한 평가가 목적이 아니다. 휘둘리지 않을 기준 하나를 갖는 것이 목적이다. 측정하지 않으면, 결국 가장 큰 목소리의 점수를 사게 된다. 내가 만든 시험이 허술해도, 남의 시험에 내 일을 맡기는 것보다는 낫다.
]]>나는 DeepSeek V4 Flash를 메인으로 쓴다. 완벽하지 않아도 되고, 틀리면 다시 물으면 된다. 싸고 빠르다는 게 이 모델의 전부다. 그런데 같은 주에 다른 생각도 들었다. 애초에 잘못된 결정으로 시작하면 되돌리기 어렵다는 것이다.
에이전트 코딩은 반복이 많다. 싼 모델은 그 반복의 단가를 낮춘다. 한 번 틀린 구현을 세 번 고쳐도 비용이 거의 안 든다. 반대로 비싼 모델은 첫 판단의 품질을 산다. 디렉터리 구조, API 경계, 데이터 모델처럼 나중에 갈아엎기 비싼 결정은 처음부터 맞히는 편이 싸다. 실패 비용이 다른 일을 같은 모델에 맡기면, 싼 쪽은 길을 잃고 비싼 쪽은 잔돈을 태운다.
그래서 나는 이제 작업을 나눈다. 고칠 수 있는 일은 Flash에 맡기고, 되돌리기 어려운 결정은 더 똑똑한 모델에 묻는다. 팀마다 답이 다를 것이다. 중요한 건 모델 브랜드가 아니라, 어떤 실패가 비싼지를 먼저 아는 것이다. 싸고 빠른 모델은 기본값이지, 모든 결정의 기본값은 아니다. 싼 모델로 시작하되, 되돌리기 비싼 고비에서만 모델을 바꾸면 된다.
]]>Anthropic과 Google이 한동안 실망스러울 때, 나를 계속 놀라게 한 쪽은 중국 모델이었다. Kimi K3, GLM 5.3, DeepSeek V4 Flash, Qwen 3.8. 이름만 나열하면 신제품 광고처럼 들리지만, 체감은 더 단순하다. 같은 돈을 내고 같은 작업을 시켰을 때, 의외로 쓸 만한 답이 그쪽에서 더 자주 나왔다.
나는 국적 대결로 모델을 고르지 않는다. 벤치마크 1등도 거의 보지 않는다. 보는 것은 반복 작업에서 다시 시킬 수 있는가, 실패 비용이 작은가, 내 도구에 붙이기 쉬운가다. Flash는 빠르고 싸고, GLM은 가중치 공개 일정이 보이며, Kimi는 어떤 그림 테스트에서 더 비싼 모델보다 나은 결과를 내기도 했다. 반대로 유명 연구소의 신작은 가격과 서사만 크고, 실제 하루 업무에서는 느리고 까다로울 때가 있었다.
중국이 최종적으로 이기느냐는 다른 문제다. 내가 말하는 승리는 리더보드가 아니라, 개인이 매일 쓰는 스택에 먼저 들어오는 쪽이다. 사후 훈련으로 기존 모델을 끌어올리는 속도가 빠르고, 오픈 가중치와 낮은 단가가 같이 움직인다. 그 조합이 실사용자를 끌어당긴다.
모델 시장을 브랜드로 보면 미국이 더 커 보인다. 작업 목록으로 보면 이야기는 달라진다. 나는 놀라는 쪽을 쓰면 된다. 국기를 응원할 필요는 없다.
]]>에이전트를 설치했다고 내 것이 되지는 않는다. 모델과 도구는 같아도, 그 에이전트가 내 우선순위와 금기를 모르면 매번 일반론으로 돌아온다. 그래서 나는 지난 대화와 X 글을 밤에 한 번씩 읽어, 일곱 개 마크다운 파일로 압축하게 만들었다.
파일은 beliefs, values, strategy, decisions, ideas, preferences, active-focus다. 신념, 가치, 전략, 결정 로그, 아이디어, 선호, 지금 집중할 일. 이 레이어를 옵시디언에 두고, 개인 주제 대화가 시작되면 에이전트가 일반 위키보다 여기를 먼저 보게 한다. 요점은 기억을 많이 쌓는 게 아니다. 내가 이미 내린 결정을 다시 토론하지 않게 만드는 것이다.
이 구조가 쓸모 있는 순간은 모델이 바뀔 때다. Grok에서 DeepSeek로, 다시 Grok으로 옮겨도 파일만 있으면 같은 사람 이야기를 이어갈 수 있다. 반대로 파일이 없으면 매번 "당신은 어떤 사람인가요"부터 다시 시작한다. 크론이 매일 쌓는 것은 로그가 아니라, 다음에 쓸 나에 대한 짧은 계약이다.
완벽한 자서전을 만들 필요는 없다. 한 줄로도 충분하다. 무엇을 믿는지, 무엇을 안 하는지, 지금 무엇을 미루면 안 되는지. 그 세 가지가 파일에 있으면 에이전트는 조수가 아니라 내 작업 환경이 된다.
]]>개인이 DGX Spark 두 대를 사서 DeepSeek V4 Flash를 직접 서빙하겠다는 이야기를 보면, 기술적으로는 이해되고 경제적으로는 이상하다. 거의 공짜에 가까운 지능을 돌리려고 비싼 하드웨어를 사는 꼴이기 때문이다.
Flash급 모델의 가치는 똑똑함 하나보다 싼 가격, 빠른 응답, 실패했을 때 다시 물어봐도 부담이 없다는 점에 있다. 그 모델을 집이나 사무실에 GPU를 들여 돌리면 전기, 소음, 고장, 드라이버, 주말 점유율까지 같이 산다. 클라우드 API로 쓰면 그 운영을 안 해도 된다. 내가 Flash를 충분하다고 느끼는 이유는 성능이 최고여서가 아니라, 반복 작업의 단가가 낮아서다. 그 단가를 올리면서까지 하드웨어를 소유할 이유는 거의 없다.
물론 직접 서빙이 맞는 경우도 있다. 데이터를 밖으로 못 보내는 환경, 지연을 밀리초 단위로 조여야 하는 제품, 모델을 고쳐서 쓰는 연구. 그런 제약이 없는데 "내 장비로 모델을 돌린다"는 이미지만 따라가면, 지능은 싸게 사고 인프라는 비싸게 사는 역전이 된다.
나는 인퍼런스 서빙 일 자체에는 관심이 있다. 다만 개인 스택에서는 반대 방향으로 간다. 비싼 상자를 소유하는 대신, 이미 싼 지능을 필요한 만큼만 부른다. 하드웨어를 사고 싶다면 그 이유가 “거의 공짜인 모델을 돌리기 위해서”여서는 안 된다.
]]>Grok Bot 이야기가 나오자마자 가격부터 눈에 들어왔다. Grok Heavy 300달러, Cursor Ultra 200달러. 계정마다 관리형 리눅스 가상머신이 하나씩 붙고, 모델은 내가 고르는 게 아니라 자동으로 라우팅된다. 편해 보이지만, 그 편의를 사기 전에 내가 이미 가진 것과 비교해야 한다.
나는 집 iMac에 Hermes Agent를 올려 두고, 밖에서는 Tailscale로 같은 에이전트에 붙는다. Hermes 자체는 무료다. 모델은 X Premium+의 Grok과 Ollama Cloud의 DeepSeek V4 Flash를 섞어 쓴다. 클라우드까지 더해도 월 20달러 안쪽이다. Grok Bot이 제공하는 것은 “알아서 돌아가는 원격 리눅스”에 가깝고, Hermes가 제공하는 것은 “내가 파일과 크론과 스킬을 가진 작업 환경”이다. 둘은 같은 카테고리처럼 보이지만 사는 물건이 다르다.
직접 구축할 수 있는 사람은 Hermes를 쓸 것이고, 구축하지 못하는 사람은 200~300달러를 내고도 만족하지 못할 가능성이 크다. 모델 선택권이 없고, 데이터가 내 디스크가 아니라 관리형 머신에 쌓이며, 가격은 구독이 아니라 입장료에 가깝다. 에이전트가 필요해서 돈을 내는 것과, 설치가 귀찮아서 돈을 내는 것은 구분해야 한다.
나는 후자에 월 200달러를 쓰기보다, 집 컴퓨터 한 대를 에이전트 허브로 두는 쪽을 고른다. 구축 비용은 처음에만 들고, 이후에는 도구와 기록이 내 쪽에 남는다. 관리형 봇이 더 편해질 수는 있다. 그래도 지금은 그 편의의 가격이 내 사용 방식과 맞지 않는다.
]]>모델을 고를 때 "이게 정말 최고인가"부터 묻는 사람이 많다. 하지만 최고를 쫓기 시작하면 끝이 없다. 매주 새 모델이 나오고, 벤치마크 순위는 바뀌고, 커뮤니티는 "올해의 승자"를 계속 갈아치운다. 그 속에서 나는 반대로 묻는다. 진짜 필요한 건 "완벽한 AI"인가, 아니면 "충분한 AI"인가.
최근 한 달 동안 나는 DeepSeek V4 Flash를 개인용 모델로 쓰고 있다. 집에서 이 모델을 쓰다 회사에서 GPT 5.6 계열을 사용하면 체감 속도 차이가 확연하다. 훨씬 비싸고 화려한 모델이 정작 일상 작업에서는 더 느리고 답답하게 느껴진다. 가격이 비싸다고, 브랜드가 유명하다고 실제 작업 효율이 좋은 것은 아니다.
충분한 AI의 기준은 세 가지다. 첫째, 스마트한가. 대부분의 일상 작업, 코드 작성, 문서 정리에는 최상위권이 아니라 중상위권이면 충분하다. 둘째, 빠른가. 반응이 빠르면 대화 흐름이 끊기지 않고 여러 시도를 할 수 있다. 셋째, 싼가. 실패했을 때 다시 물어보면 되는데, 그뿐이다. 완벽을 위해 돈을 더 쓰기보다, 실패하더라도 “한 번 더 물어보면 되는” 비용이 훨씬 현실적이다.
모델 선택은 신앙이 아니라 실용이다. 도구는 일을 끝내는 데 도움이 되어야 한다. 완벽한 AI가 없다는 걸 인정하면, 오히려 "충분한 AI"로 된 자신만의 조합을 빨리 찾을 수 있다. 그렇게 고른 스택이 오래 쓸 수 있는 진짜 답이다.
]]>모델 평가 글을 보면 잘 알려진 벤치마크 순위만 나열하고 끝나는 경우가 많다. 그 수치에 휘둘리면 실제 내 작업에서는 실망하기 쉽다. 그래서 나는 최근 나만의 테스트를 만들기 시작했다. "테스트 코드"가 아니라, 그래픽 응답의 세밀함을 확인하는 SVG 기반 문제들이다. 다리미질하는 새, 설거지하는 너구리 같은 이미지를 모델이 얼마나 정확히 재현하는지 보는 식이다.
이런 테스트가 항상 정답은 아니다. 모델은 용도마다 강점이 다르고, 문제 설정도 편향될 수 있다. 한두 개 문제만으로 전체 성능을 판단하면 분명 오류가 날 수 있다. 그러니 이 방식은 단순한 평가 자료가 아니라 나의 관점을 지키는 장치라고 보는 게 맞다. 핵심은 명확하다. 남의 말이 아니라 내 기준으로 모델을 평가하게 된다는 것이다. 커뮤니티에서 "이 모델이 최고"라고 떠들어도, 내 테스트에서 결과가 좋지 않으면 내 선택은 달라진다.
실제로 이 방식은 유용했다. 비슷한 순위의 모델들이 내 테스트에서 서로 다른 결과를 냈고, 예상을 뒤엎는 경우도 있었다. 유명한 모델이 이긴다 해도 그 차이가 내 작업에 무의미하다면 결국 비용과 속도가 기준이 된다.
벤치마크 수치는 참고용이다. 진짜 평가는 내가 자주 하는 작업에서 시작해야 한다. 지금 쓰는 AI가 내 일을 얼마나 잘 돕는지, 그걸 정기적으로 점검하는 나만의 루틴을 만들어두면 남들의 평가에 휘둘리지 않는다. 숫자보다 실제 경험이 더 정직한 지표다.
]]>에이전트가 점점 많이 하는 일 중 하나가 시스템 설정과 도구 설치다. 그런데 "어느 AI에게 명령 설치를 맡길 것인가"라는 질문은 모델마다 답이 크게 다르다. 나는 이 차이를 "순종하는 AI"와 "생각하는 AI"로 나눠 본다.
순종하는 AI는 요청한 패키지를 그대로 설치한다. 지시문 그대로 명령어를 나열하고 실행한다. 반면 생각하는 AI는 같은 요청을 받아도 잠깐 멈춘다. 지금 내 시스템에 어떤 도구가 deprecated인지 떠올리고, 그보다 나은 대안을 제안하거나, 자주 쓰는 명령에 별칭을 만들어준다.
예를 들어 같은 리눅스 도구 교체 작업을 시켰을 때, 한 모델은 문헌에 있는 명령만 기계적으로 설치했고 다른 모델은 구식 도구를 더 나은 것으로 바꾸고 편리한 별칭까지 정리해줬다. 결과물 품질의 차이보다 중요한 것은 접근 방식이다. "시키는 대로 하는 것"과 "맥락을 이해하고 더 좋은 선택을 하는 것"은 다르다.
시스템 설치처럼 되돌리기 어려운 일일수록 생각하는 AI가 안전하다. 무조건 실행하는 AI는 명령 하나 잘못 들어가면 시스템을 망칠 수 있고, 설치 후에도 무엇이 바뀌었는지 제대로 설명하지 않으면 관리가 어렵다. 반면 맥락을 이해하는 AI는 조작 전에 위험을 짚어주고, 실행 후에는 무슨 일이 벌어졌는지 명확히 알려준다. 에이전트를 선택할 때는 "얼마나 똑똑하나"보다 "얼마나 판단하며 실행하나"를 봐야 한다. 순종은 편하지만, 책임지는 판단은 훨씬 가치 있다. 시스템을 다루는 에이전트를 도입할 계획이라면, 그 모델이 단순히 따르기만 하는지 늘 확인해보길 권한다.
]]>나는 한동안 토큰을 아끼는 데 집착했다. 프롬프트를 짧게 줄이고, 문맥을 최소화하고, 불필요한 호출을 줄이려고 애썼다. 그런데 DeepSeek V4 Flash 0731을 만나면서 이 습관이 더 이상 필요 없다는 걸 깨달았다. 지능이 거의 공짜에 가까워지고 있다. 토큰 절약은 이제 미덕이 아니라 오히려 작업 품질을 떨어뜨리는 요인이 될 수 있다.
토큰을 아끼던 시절의 논리는 단순했다. 비싼 모델을 호출할수록 비용이 커지니, 필요한 만큼만 쓰자는 것. 하지만 모델 가격이 급락하면서 이 계산이 뒤집혔다. 저비용 모델은 대량 호출을 견디고, 문맥을 넉넉히 넣어도 부담이 크지 않다. 그렇다면 아끼는 것보다 오히려 충분히 쓰는 편이 결과물 품질에 유리하다. 필요한 정보를 다 넣고, 여러 번 시도하고, 실패해도 다시 물어볼 수 있는 여유가 생긴다.
물론 무제한 사용이 무조건 좋다는 뜻은 아니다. 작업을 설계 없이 막 호출하면 시간과 품질이 낭비된다. 중요한 건 비용을 아끼는 데가 아니라, 모델을 제대로 쓰는 데 집중하는 것이다. 명확한 지시, 충분한 문맥, 검증 가능한 결과물. 이 세 가지가 갖춰지면 토큰 수는 더 이상 신경 쓸 문제가 아니다.
지능이 거의 공짜가 되는 시대에는, 아끼는 습관보다 쓰는 습관이 더 중요해진다. 나는 이제 토큰을 세지 않는다. 대신 모델이 제대로 일할 수 있는 환경을 만드는 데 집중한다. 그게 훨씬 더 나은 결과를 만든다.
]]>요즘 내 메인 모델은 Grok 4.5다. 스마트하고, 빠르고, 가격이 합리적이라는 세 조건을 모두 만족하는 지점에 있다. 그래서 다음 버전인 4.6을 기다리는 마음이 각별하다. 다만 내가 원하는 업그레이드는 단순히 "더 똑똑해지는 것"이 아니다. 속도와 비용이 그대로 유지된 채 지능만 올라가는 방향이어야 한다.
이 기준이 생긴 이유는 최근 몇 달간 모델 선택의 기준이 바뀌었기 때문이다. 벤치마크 1위 모델이 항상 실사용에서 최선은 아니었다. 에이전트 워크플로우에서는 모델을 수십 번, 수백 번 호출한다. 그때마다 응답이 느리거나 비싸면 전체 작업이 무너진다. 반대로 지능이 조금 낮아도 빠르고 싼 모델은 대량 호출에 견딘다. 그래서 나는 "가장 똑똑한 모델"보다 "매일 쓰기 좋은 모델"을 고르게 됐다.
Grok 4.5가 그 균형을 잘 잡아줬다. 4.6이 여기서 지능만 끌어올린다면, 경쟁 모델들이 따라오기 쉽지 않을 것이다. 물론 지능 향상이 속도나 비용을 해치지 않을지는 출시 전까지 알 수 없다. 그래서 나는 기대와 관찰을 함께 유지한다. 출시되면 직접 써보고, 내 작업 흐름에서 실제로 더 나은 결과를 내는지 확인할 것이다.
모델 선택은 결국 스펙표가 아니라 실사용에서 결정된다. 나는 지금 내 스택에 가장 잘 맞는 업그레이드를 기다리고 있다. 더 똑똑해지되, 지금의 속도와 비용은 그대로. 그게 내가 원하는 4.6이다.
]]>몇 년 동안 미뤄둔 외장하드 정리를 에이전트에게 맡겼다. 결과는 15분 만에 끝났다. 수년간의 미루기가 커피 한 잔 마시는 시간에 해결됐다. 핵심은 의지력이 아니라, 지루한 일을 AI에게 위임하는 구조였다.
외장하드에는 정리되지 않은 파일이 수만 개 쌓여 있었다. 언제 봐도 부담스러운 작업이라 계속 미뤘다. 그런데 Hermes Agent에게 "이 하드를 검색 가능하고 시각화된 사이트로 만들어줘"라고 지시하자, 에이전트가 파일을 스캔하고 구조를 파악해 정리된 결과물을 만들어냈다. 내가 직접 폴더를 하나하나 열어보며 분류하던 때와 비교하면 시간이 1/100도 안 걸렸다.
이 경험이 보여주는 건 단순하다. 미루기의 원인은 대부분 게으름이 아니라, 작업이 지루하고 시작하기 어렵다는 점이다. 그런 작업은 인간이 의지를 끌어올려 해내기보다, 에이전트에게 넘기는 편이 훨씬 효율적이다. 에이전트는 지루함을 느끼지 않고, 시작하는 데 에너지가 들지 않으며, 실수해도 다시 시도한다.
물론 모든 일을 위임할 수는 없다. 판단과 의사결정이 필요한 일은 여전히 내 몫이다. 하지만 "정리"처럼 규칙이 명확하고 반복적인 작업은 에이전트의 영역이다. 나는 이제 미루는 일이 생기면 "이걸 에이전트에게 맡길 수 있나"부터 생각한다. 그 질문 하나로 미루기의 상당수가 사라졌다. 진짜 해킹은 의지력이 아니라, 지루한 일을 AI에게 맡기는 것이다.
]]>한 달 전까지만 해도 나는 AI 도구를 셋이나 구독하고 있었다. Cursor, ChatGPT, Claude까지. 매달 나가는 돈이 적지 않았지만, 뭐 하나 버리기 아까웠다. 그러다 문득 생각했다. 내가 실제로 쓰는 도구가 뭔지, 진짜 비용 대비 가치를 주는 게 뭔지.
정리 기준은 단순했다. “이 도구가 내 일을 실제로 끝내주는가.” 그 기준으로 보니 답은 빨리 나왔다. Cursor는 내 작업 방식과 어긋났고, ChatGPT는 일반 대화 이상의 가치를 주지 못했다. 반면 Hermes Agent는 아침에 떠오른 아이디어를 저녁이면 실제 산출물로 만들어 주었다. 이메일 트라이지, 파일 정리, 블로그 초안, 그리고 이 글까지. SuperGrok은 X Premium+에 포함되어 있어 추가 비용 없이 메인 모델로 쓴다. 부족할 때는 OpenRouter의 DeepSeek V4 Flash를 저비용 대량 작업에 돌린다.
이 조합의 장점은 비용이 아니라 자유다. 하나의 벤더에 묶이지 않으니, 어떤 회사가 최신 모델을 내놓든 내 작업 방식은 바뀌지 않는다. 설정 파일의 모델 이름 하나만 바꾸면 된다. 에이전트를 메인으로 두고, 모델은 필요에 따라 갈아끼우는 구조. 이게 요즘 내가 생각하는 AI 스택의 본질이다.
정리해 보면, 구독을 취소하는 일은 결핍이 아니라 선택이다. 무엇을 쓰지 않을지 결정할 때 비로소 무엇을 쓸지 명확해진다. 지금 내 스택은 세 개의 도구와 무한에 가까운 사용량, 그리고 한 달에 몇 만 원의 비용이다. 그걸로 충분하다.
]]>프론티어 AI 랩의 경쟁 구도가 1년 만에 크게 바뀌었다. 2025년까지만 해도 코딩 에이전트의 기준은 Claude였다. 그런데 지금 나는 회사가 비용을 대주는 Claude Enterprise를 한 달째 열어보지 않고 있다. 단순한 취향 변화가 아니라, 모델 라인업의 전략적 실패가 만든 결과다.
Anthropic의 문제는 세 갈래로 드러난다. 첫째, Haiku가 사실상 시장에서 사라졌다. 가볍고 싸고 빠른 소형 모델은 에이전트 워크플로우에서 가장 많이 호출되는 계층인데, 이 자리를 GPT와 DeepSeek가 채웠다. 둘째, Sonnet은 가격이 오르면서 '합리적 중간 선택’이라는 포지셔닝을 잃었다. 셋째, Opus는 품질 경쟁에서 우위를 증명하지 못하면서 고집스러운 최상위 모델로만 남았다. 반면 경쟁사들은 가격을 파격적으로 내리고, 소형 모델을 에이전트에 깊게 통합하면서 실사용 점유율을 가져갔다.
이 구도는 프론티어 성능 자체보다 '비용 대비 실사용 가치’로 승부가 갈리는 시장의 신호다. 실제로 기업에서 AI 도입을 결정하는 순간은 벤치마크 점수가 아니라, 월 비용과 업무 자동화 수준이 맞물리는 지점이다. 비싼 최상위 모델 한 개보다, 싼 모델을 여러 번 호출해도 이익인 작업이 훨씬 많다.
개인적으로 내린 결론은 하나의 벤더에 얽매이지 말라는 것이다. 지금 내 스택은 Hermes Agent + Grok을 메인으로, DeepSeek V4 Flash를 저비용 대량 호출용으로 쓰고 있다. 어떤 랩이 최신 모델을 내놓든, 내가 바꿔야 하는 건 설정 파일의 모델 이름뿐이다. 프론티어 경쟁에서 누가 이기든, 도구를 교체할 수 있는 구조를 만든 쪽이 이득을 본다.
]]>엉클 밥으로 알려진 로버트 C. 마틴의 X 글이 코드 리뷰를 둘러싼 논쟁을 다시 불렀다. 그 글에 따르면 에이전트가 작성한 코드를 직접 읽기보다 테스트 커버리지, 의존성 구조, 사이클로매틱 복잡도, 모듈 크기, 뮤테이션 테스트 같은 지표로 품질을 판단해야 한다. 코딩은 AI에 맡기고 사람은 더 높은 수준에서 관리하자는 주장이다.
그 글은 정해진 범위 안에서 AI를 통제하고 품질 지표를 신뢰할 수 있다면, 인간의 코드 확인이 생산성 병목이 된다는 논리다. 효율을 위해 리뷰를 줄이자는 주장과 책임을 위해 리뷰해야 한다는 반론이 맞부딪히는 지점이다.
내가 보기에는 회사 프로젝트에서는 후자의 부담을 무시하기 어렵다. AI는 자신이 만든 수정으로 장애나 보안 사고가 나도 책임지지 않는다. 개인 프로젝트라면 전적으로 맡길 수 있지만, 회사 코드라면 내가 수정 내용을 확인하고 어떤 위험을 받아들였는지 설명할 수 있어야 한다. 다만 모든 줄을 사람이 읽으면 AI 활용의 병목을 그대로 남긴다.
확인하지 않은 채 PR만 올리는 것도 문제다. 그 몫을 다른 팀원에게 넘기는 일이고, 팀원들이 AI로 리뷰하면 생성과 검증이 모두 비슷한 자동화 결과에 의존하게 된다. 테스트 통과만으로 운영 환경의 권한 경계, 데이터 상태, 장애 복구까지 보장할 수 없다는 점도 남는다.
실무에서는 변경 위험도에 따라 검증 수준을 나누는 편이 낫다. 단순 작업은 CI와 자동 리뷰로 끝내되, 결제, 인증, 마이그레이션과 같은 핵심적은 부분에 대해서는 작성자가 핵심 흐름과 실패 경로를 직접 확인해야 한다. 커버리지와 복잡도뿐 아니라 시나리오 테스트와 보안 검사를 함께 걸고, PR에는 AI가 바꾼 이유와 남은 불확실성을 적는다. 리뷰를 없애기보다 사람이 책임질 지점을 좁히는 방향이 현실적이다.
관련 글
]]>나는 최근 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에 연결해 자동 차단 시스템을 구축하는 것도 잊지 말아야 한다.
관련 글
]]>