완벽한 AI보다 충분한 AI를 고르는 것이 더 현명한 이유
모델을 고를 때 "이게 정말 최고인가"부터 묻는 사람이 많다. 하지만 최고를 쫓기 시작하면 끝이 없다. 매주 새 모델이 나오고, 벤치마크 순위는 바뀌고, 커뮤니티는 "올해의 승자"를 계속 갈아치운다. 그 속에서 나는 반대로 묻는다. 진짜 필요한 건 "완벽한 AI"인가, 아니면 "충분한 AI"인가.
완벽한 AI보다 충분한 AI를 고르는 것이 더 현명한 이유
모델을 고를 때 "이게 정말 최고인가"부터 묻는 사람이 많다. 하지만 최고를 쫓기 시작하면 끝이 없다. 매주 새 모델이 나오고, 벤치마크 순위는 바뀌고, 커뮤니티는 "올해의 승자"를 계속 갈아치운다. 그 속에서 나는 반대로 묻는다. 진짜 필요한 건 "완벽한 AI"인가, 아니면 "충분한 AI"인가.
남들의 평가에 휘둘리지 않고 나만의 AI 테스트를 만드는 법
모델 평가 글을 보면 잘 알려진 벤치마크 순위만 나열하고 끝나는 경우가 많다. 그 수치에 휘둘리면 실제 내 작업에서는 실망하기 쉽다. 그래서 나는 최근 나만의 테스트를 만들기 시작했다. "테스트 코드"가 아니라, 그래픽 응답의 세밀함을 확인하는 SVG 기반 문제들이다. 다리미질하는 새, 설거지하는 너구리 같은 이미지를 모델이 얼마나 정확히 재현하는지 보는 식이다.
에이전트가 점점 많이 하는 일 중 하나가 시스템 설정과 도구 설치다. 그런데 "어느 AI에게 명령 설치를 맡길 것인가"라는 질문은 모델마다 답이 크게 다르다. 나는 이 차이를 "순종하는 AI"와 "생각하는 AI"로 나눠 본다.
나는 한동안 토큰을 아끼는 데 집착했다. 프롬프트를 짧게 줄이고, 문맥을 최소화하고, 불필요한 호출을 줄이려고 애썼다. 그런데 DeepSeek V4 Flash 0731을 만나면서 이 습관이 더 이상 필요 없다는 걸 깨달았다. 지능이 거의 공짜에 가까워지고 있다. 토큰 절약은 이제 미덕이 아니라 오히려 작업 품질을 떨어뜨리는 요인이 될 수 있다.
Grok 4.6을 기다리는 이유: 더 똑똑해지되, 속도와 비용은 그대로
요즘 내 메인 모델은 Grok 4.5다. 스마트하고, 빠르고, 가격이 합리적이라는 세 조건을 모두 만족하는 지점에 있다. 그래서 다음 버전인 4.6을 기다리는 마음이 각별하다. 다만 내가 원하는 업그레이드는 단순히 "더 똑똑해지는 것"이 아니다. 속도와 비용이 그대로 유지된 채 지능만 올라가는 방향이어야 한다.
미루던 외장하드 정리, 에이전트에게 15분 만에 끝냈다
몇 년 동안 미뤄둔 외장하드 정리를 에이전트에게 맡겼다. 결과는 15분 만에 끝났다. 수년간의 미루기가 커피 한 잔 마시는 시간에 해결됐다. 핵심은 의지력이 아니라, 지루한 일을 AI에게 위임하는 구조였다.
한 달 전까지만 해도 나는 AI 도구를 셋이나 구독하고 있었다. Cursor, ChatGPT, Claude까지. 매달 나가는 돈이 적지 않았지만, 뭐 하나 버리기 아까웠다. 그러다 문득 생각했다. 내가 실제로 쓰는 도구가 뭔지, 진짜 비용 대비 가치를 주는 게 뭔지.
프론티어 AI 랩의 경쟁 구도가 1년 만에 크게 바뀌었다. 2025년까지만 해도 코딩 에이전트의 기준은 Claude였다. 그런데 지금 나는 회사가 비용을 대주는 Claude Enterprise를 한 달째 열어보지 않고 있다. 단순한 취향 변화가 아니라, 모델 라인업의 전략적 실패가 만든 결과다.
엉클 밥으로 알려진 로버트 C. 마틴의 X 글이 코드 리뷰를 둘러싼 논쟁을 다시 불렀다. 그 글에 따르면 에이전트가 작성한 코드를 직접 읽기보다 테스트 커버리지, 의존성 구조, 사이클로매틱 복잡도, 모듈 크기, 뮤테이션 테스트 같은 지표로 품질을 판단해야 한다. 코딩은 AI에 맡기고 사람은 더 높은 수준에서 관리하자는 주장이다.
나는 최근 AI와 함께 코딩을 하면서 Go 언어의 유용함을 새삼 느끼고 있다. 이른바 '바이브 코딩’을 할 때 정적 언어가 주는 안정감이 동적 언어보다 훨씬 뛰어나다는 생각이다. 현재 나는 타입스크립트, Rust, 그리고 Go를 주로 사용하고 있는데, 이 언어들은 AI가 코드를 생성할 때 발생할 수 있는 여러 실수를 컴파일 단계에서 차단해주는 훌륭한 도구가 된다.