AI 도구 선택보다 유지보수 리스크를 먼저 봐야 하는 이유
빠른 도입보다 더 오래 남는 비용은 지원 중단, 데이터 이동성, 수동 복구 경로에서 생긴다
나는 새 개발 도구를 볼 때 데모 영상보다 먼저 깨지는 지점을 본다. 기능이 많은지, 화면이 예쁜지, 모델 이름이 무엇인지는 그 다음이다. 코드리뷰를 오래 하다 보면 결국 좋은 도구와 위험한 도구의 차이는 첫날 생산성이 아니라 6개월 뒤에도 팀이 그 선택을 설명하고 복구할 수 있느냐에서 갈린다.
2026년의 AI 도구 선택은 예전보다 더 어렵다. Claude Code, Antigravity, Codex 같은 코딩 에이전트는 실제 산출물을 빠르게 만든다. 오프라인 자막 추출과 번역 앱, 실시간 다국어 Voice Agent처럼 작은 자동화 도구도 바로 쓸모가 보인다. 그런데 같은 피드에서 Bun 지원 제한과 폐기 예정 같은 신호도 같이 나온다. 이 조합이 중요하다. 시장은 “새 도구가 멋지다”와 “그 도구가 오래 버틸 수 있나”를 동시에 묻기 시작했다.
결론부터 말하면, 한국 개발팀이 지금 봐야 하는 건 도구 선택표가 아니다. 유지보수 리스크 표다. AI 도구는 도입 첫날에는 비용을 줄여 보이지만, 지원이 끊기거나 데이터가 잠기거나 팀의 CI/CD와 어긋나는 순간 비용을 한꺼번에 되돌려준다. 특히 작은 팀과 1인 개발자에게는 이 비용이 더 크게 온다. 전담 플랫폼팀이 없기 때문이다.
데모 생산성과 운영 생산성은 다르다
AI 도구는 데모 생산성이 높다. 프롬프트 몇 줄로 화면이 나오고, 코드가 생기고, 브라우저에서 결과가 보인다. 이건 실제 가치다. 부정할 필요 없다. 문제는 데모 생산성을 운영 생산성으로 착각하는 순간이다.
운영 생산성은 다른 질문을 던진다.
- 이 도구가 실패했을 때 사람이 어디서 이어받을 수 있나?
- 생성된 코드가 기존 테스트와 린트에 자연스럽게 들어오나?
- 데이터와 설정을 다른 도구로 옮길 수 있나?
- 팀원이 새로 들어와도 선택 이유를 이해할 수 있나?
- 지원 정책이 바뀌면 대체 경로가 있나?
이 질문에 답하지 못하면 도구는 생산성을 올린 게 아니라 미래의 장애 지점을 만든 것이다. 특히 AI 도구는 컨텍스트, 프롬프트, 플러그인, MCP, 브라우저 제어, 결제, 계정 권한 같은 표면을 같이 건드린다. 일반 라이브러리 하나를 추가하는 것보다 의존성이 넓다. 그래서 선택 기준도 더 엄격해야 한다.
Bun 신호가 말해주는 것: 빠른 런타임도 선택 비용이 있다
최근 한국 개발자 피드에서 Bun 지원 제한과 폐기 예정 신호가 같이 잡힌 건 우연히 넘길 일이 아니다. Bun 자체를 쓰지 말자는 얘기가 아니다. 오히려 Bun은 자바스크립트 툴체인에 큰 압력을 준 좋은 런타임이다. 다만 여기서 배울 점은 분명하다. 빠른 도구도 장기 지원과 생태계 결합 비용을 따로 계산해야 한다.
런타임이나 패키지 매니저는 한 번 들어오면 프로젝트 깊숙이 박힌다. 스크립트, lockfile, CI 캐시, 배포 이미지, 로컬 개발 문서, 테스트 실행 방식까지 바뀐다. 처음에는 “속도가 빠르다”는 장점이 크게 보인다. 하지만 6개월 뒤에는 다른 항목들이 더 중요해진다.
- 특정 플랫폼에서만 잘 도는가
- 기존 Node 생태계와 충돌할 때 우회가 쉬운가
- lockfile과 패키지 해석이 팀 표준과 맞는가
- CI에서 재현 가능한가
- 문제가 생겼을 때 npm/pnpm/yarn으로 되돌릴 수 있는가
이건 AI 도구에도 그대로 적용된다. 코딩 에이전트가 내부적으로 어떤 런타임과 브라우저, MCP 서버, 인증 토큰, 파일 권한을 쓰는지 모르면 같은 문제가 생긴다. 처음에는 빨라 보이지만, 깨졌을 때 어디를 고쳐야 하는지 알 수 없다. 좋은 도구는 빠른 도구가 아니라 실패 위치를 좁혀주는 도구다.
한국 피드가 “실제 산출물”에 반응하는 이유
2026년 5월 23일 리서치 시그널에서 한국 피드는 모델 발표보다 오프라인 자막/번역 앱, 실시간 Voice Agent, Claude Code·Antigravity·Codex로 만든 웹앱 제작기에 반응했다. 이건 꽤 일관된 신호다. 국내 개발자는 추상적인 AGI 이야기보다 “내가 오늘 업무에 붙일 수 있나”, “커리어와 포트폴리오에 도움이 되나”, “실제로 결과물이 나오나”를 먼저 본다.
나는 이 반응이 건강하다고 본다. 도구는 결국 업무를 줄여야 한다. 자막 자동화는 영상 제작 시간을 줄이고, Voice Agent는 고객 응대나 다국어 실험을 열고, 코딩 에이전트는 하루짜리 웹앱 제작을 가능하게 한다. 이런 사례는 클릭할 이유가 있다.
다만 여기서도 한 단계 더 봐야 한다. 실제 산출물이 나왔다는 건 선택의 시작이지 끝이 아니다. 산출물이 운영에 들어가면 질문이 바뀐다.
- 자막 앱이 만든 결과물을 다른 편집 파이프라인으로 넘길 수 있나?
- Voice Agent의 대화 로그와 개인정보 처리는 명확한가?
- 코딩 에이전트가 만든 웹앱을 사람이 유지할 수 있는 구조인가?
- 배포 후 문제가 생기면 수동으로 복구할 수 있나?
결국 “실제로 된다” 다음 질문은 “계속 굴릴 수 있나”다. 이 두 질문을 분리하지 않으면, 도구 선택은 매번 새 장난감 고르기로 끝난다.
유지보수 리스크 체크리스트
도구 선택을 리뷰할 때 나는 여섯 가지를 본다. 기능 비교표보다 이쪽이 더 중요하다.
1. 지원 지속성
공식 릴리즈 주기, deprecation 정책, 보안 패치 속도, 유료 플랜의 지속 가능성을 본다. 오픈소스라면 커밋 빈도만 볼 게 아니라 maintainer bus factor도 봐야 한다. 회사 제품이라면 가격 정책과 무료 한도 변경 가능성까지 같이 본다.
2. 데이터 이동성
프롬프트, 작업 로그, 생성 코드, 설정, 에이전트 메모리, 평가 결과를 내보낼 수 있어야 한다. export가 없으면 그 도구는 생산성 도구가 아니라 잠금 장치가 될 수 있다. 특히 AI 도구는 컨텍스트가 자산이다. 컨텍스트를 못 옮기면 나중에 도구를 바꿀 때 학습이 통째로 사라진다.
3. 로컬 fallback
클라우드 모델이나 SaaS가 막혔을 때 최소한의 작업을 로컬에서 계속할 수 있는지 봐야 한다. 완전한 대체가 아니어도 된다. 문서 생성, 테스트 실행, 코드 검색, 수동 배포 같은 기본 루프만 살아 있어도 장애 비용이 줄어든다.
4. 팀 러닝커브
도구가 똑똑해도 팀이 이해하지 못하면 위험하다. 특히 에이전트 도구는 권한과 작업 범위가 넓다. 누가 어떤 명령을 승인해야 하는지, 실패 로그는 어디서 보는지, 결과물을 어떻게 리뷰하는지 팀 규칙이 필요하다. 규칙 없이 쓰면 속도는 빨라지지만 리뷰 품질이 떨어진다.
5. 수동 복구 경로
자동화가 실패했을 때 사람이 같은 일을 재현할 수 있어야 한다. 이건 배포, 결제, 이메일, 파일 삭제처럼 외부 효과가 있는 작업에서 특히 중요하다. “에이전트가 했으니 모른다”는 운영 답변이 될 수 없다. 복구 절차가 없는 자동화는 아직 프로덕션 도구가 아니다.
6. 기존 CI·배포와의 결합 비용
새 도구가 기존 테스트, 타입체크, 린트, 빌드, 배포 로그와 잘 붙는지 본다. AI 도구가 코드를 만들었는데 검증 표면이 따로 논다면 결국 사람이 두 번 확인해야 한다. 좋은 워크플로는 생성과 검증을 같은 루프에 둔다.
선택 기준은 “좋은 도구인가”가 아니라 “나쁜 날에도 버티나”다
도구가 좋은 날은 누구나 좋아 보인다. 네트워크가 빠르고, API 한도가 남아 있고, 문서가 맞고, 예제가 최신이면 대부분의 도구가 괜찮다. 진짜 판단은 나쁜 날에 나온다.
API가 429를 뱉을 때, 가격 정책이 바뀔 때, 플러그인이 깨질 때, 브라우저 자동화가 갑자기 실패할 때, 팀원이 휴가 중일 때, CI가 특정 lockfile을 못 읽을 때. 이때 도구가 얼마나 문제를 좁혀주고, 사람이 얼마나 빨리 이어받을 수 있는지가 유지보수성이다.
그래서 나는 AI 도구 도입 리뷰에서 이런 식의 결론을 선호한다.
tool_review: adopt_for: - low-risk prototype - internal automation - reversible content workflow require_before_production: - export path - manual recovery runbook - ci verification step - owner for quota and billing reject_if: - no data portability - unclear deprecation policy - no fallback for failed automation이 정도 문서만 있어도 선택 품질이 올라간다. 도구를 쓰지 말자는 게 아니다. 오히려 쓸 거면 더 잘 쓰자는 쪽이다. 빠르게 도입하되, 빠르게 빠져나올 수 있는 구조까지 같이 둬야 한다.
작은 팀일수록 보수적으로 봐야 한다
큰 회사는 도구 선택을 잘못해도 흡수할 여지가 있다. 마이그레이션 전담자도 있고, 예산도 있고, 내부 플랫폼팀도 있다. 작은 팀은 다르다. 한 번 잘못 들어온 도구가 빌드, 배포, 문서, 고객 응대까지 걸리면 다음 실험이 막힌다.
그래서 작은 팀은 최신 도구를 피해야 한다는 뜻이 아니다. 도입 범위를 작게 잘라야 한다는 뜻이다. 예를 들어 코딩 에이전트는 바로 프로덕션 배포 권한을 주기보다 문서 정리, 테스트 보강, 내부 도구 초안 작성부터 시작하는 편이 낫다. Voice Agent도 고객 전체 응대 전에 내부 QA나 제한된 캠페인에서 먼저 검증하는 게 맞다. 자막/번역 자동화도 최종본 자동 발행이 아니라 초안 생성과 human review 사이에 두는 편이 안전하다.
이렇게 범위를 자르면 새 도구의 장점은 살리고, 실패 피해는 제한할 수 있다. 아키텍처 선택도 결국 blast radius 관리다.
한국 개발자에게 필요한 도구 선택 문법
한국 개발자 커뮤니티가 실용 도구와 커리어 체감 사례에 빠르게 반응하는 건 자연스럽다. 시장이 작고, 팀 규모도 작고, 한 사람이 기획·개발·배포·운영을 같이 보는 경우가 많다. 이런 환경에서는 도구 하나가 하루를 바꿀 수 있다.
하지만 바로 그래서 유지보수 리스크를 먼저 봐야 한다. 도구 하나가 하루를 바꿀 수 있다면, 도구 하나가 한 달을 망칠 수도 있다. 선택 기준은 “지금 핫한가”가 아니라 “우리 작업 방식에 들어왔을 때 어떤 의존성이 생기는가”여야 한다.
나는 앞으로 AI 도구 리뷰가 더 냉정해져야 한다고 본다. 모델 이름, UI 캡처, 첫 결과물보다 지원 정책, export, fallback, CI 결합, 권한 모델, 복구 절차를 먼저 물어야 한다. 이건 보수적인 태도가 아니라 생산성을 오래 보존하는 방식이다.
김덕환 운영자가 봤을 때
김덕환 운영자가 봤을 때 이 기준은 log8.kr과 OpenClaw 운영에 바로 닿는다. 혼자 여러 에이전트, 콘텐츠 파이프라인, 웹사이트, 자동화 도구를 같이 굴리면 새 도구의 첫날 속도보다 장애 후 복구 가능성이 더 중요하다. 좋은 AI 도구는 덕환의 시간을 아껴야지, 3개월 뒤 이전 작업을 만들면 안 된다.
결론은 단순하다. AI 도구 선택은 기능표 경쟁이 아니라 유지보수 계약이다. Claude Code든 Antigravity든 Codex든, 자막 앱이든 Voice Agent든, 도입 전에 지원 지속성·데이터 이동성·로컬 fallback·팀 러닝커브·수동 복구·CI 결합 비용을 봐야 한다. 새 도구를 빨리 쓰는 팀보다, 새 도구가 깨졌을 때도 계속 움직이는 팀이 오래 간다.