개발 도구는 오픈소스여야 한다 — 492표가 던진 불편한 질문

개발자가 쓰는 도구가 블랙박스여도 괜찮을까요. 오래된 질문인데 2026년에 다시 뜨거워졌습니다. 이유는 단순합니다. AI 코딩 CLI가 터미널 안으로 들어와서, 코드를 읽고 쓰고 서버로 보내는 일까지 하고 있거든요. 예전엔 “IDE가 폐쇄적이어도 결과물은 내 것"이었는데, 지금은 그 전제부터 흔들립니다.

한 가지는 솔직히 밝혀둡니다. 이번 주제는 최근 30일 커뮤니티 데이터가 거의 잡히지 않았습니다. 그래서 이 글은 실시간 여론 중계가 못 됩니다. 이 논쟁이 왜 자꾸 되돌아오는지 뜯어보는 쪽에 가깝습니다.

왜 하필 지금 다시 불붙었나

개발 도구의 오픈소스 논쟁은 20년 넘게 이어져 왔습니다. 그런데 예전 논쟁의 핵심은 가격이었습니다. 비싼 라이선스를 왜 사냐, 무료 대안이 있는데. 대략 이런 구도였죠.

지금은 다릅니다. 쟁점이 신뢰로 옮겨갔습니다. AI 코딩 도구는 성격이 아예 다른 소프트웨어입니다. 내 코드베이스 전체를 읽습니다. 파일을 직접 고치고 셸 명령도 실행합니다. 그러면서 무언가를 밖으로 내보냅니다.

그럼 뭘 얼마나 어디로 보내는지 확인할 방법이 있느냐. 소스가 닫혀 있으면 답은 “제공사 문서를 믿는다” 하나뿐입니다. 문서가 틀렸을 수도, 조용히 바뀌었을 수도 있습니다. 애초에 빠뜨린 항목이 있어도 알 길이 없고요.

텔레메트리는 켜고 끄는 문제가 아니다

“텔레메트리 끄기” 옵션은 웬만한 도구에 다 있습니다. 설정 파일 한 줄, 환경변수 하나면 끝납니다. 그래서 문제가 해결된 것처럼 보입니다.

정작 개발자가 불편해하는 건 그게 아닙니다. 옵션이 실제로 작동하는지 검증할 수 없다는 겁니다. 오픈소스면 코드를 열어보면 끝납니다. 폐쇄 소스면 패킷을 뜨고 도메인을 쫓고 트래픽을 뜯어봐야 합니다. 그렇게 해도 확실하진 않습니다. 다음 업데이트에서 동작이 바뀌면 처음부터 다시 봐야 하니까요.

회사로 들어오면 이게 곧바로 규정 문제가 됩니다. 금융권이나 의료 쪽 개발팀은 “우리 소스코드가 외부로 나가지 않는다"를 증명해야 합니다. 벤더 문서는 증명이 아닙니다. 계약서일 뿐이죠. 그래서 AI 코딩 도구 도입을 미루는 조직이 많고, 아예 로컬에서 돌릴 수 있는 오픈소스 대안을 찾아 나섭니다.

락인의 형태가 달라졌다

예전 락인은 눈에 보였습니다. 특정 IDE에만 있는 프로젝트 파일 포맷, 그 도구에서만 돌아가는 빌드 스크립트. 불편해도 내가 뭐에 묶여 있는지는 알았습니다.

AI 도구 쪽은 알아채기가 더 어렵습니다. 우선 워크플로 락인이 있습니다. 특정 CLI의 프롬프트 방식이며 설정 구조, 에이전트 정의 포맷에 팀 전체가 손이 익습니다. 파일 하나 변환해서 옮길 수 있는 게 아닙니다. 사람 습관이니까요.

다음은 컨텍스트 락인입니다. 도구가 쌓아둔 프로젝트 이해, 메모리, 커스텀 규칙이 그 도구 안에만 있습니다. 몇 달 쓰다 보면 이게 꽤 큰 자산이 됩니다. 그런데 대부분 내보내기가 안 됩니다. 된다 해도 다른 도구가 못 읽는 포맷이고요.

마지막이 제일 현실적입니다. 가격이 언제든 바뀔 수 있다는 것. 무료로 시작해서 팀이 다 쓰게 된 다음 요금제가 개편되는 패턴, 개발자들은 이미 여러 번 봤습니다.

반대편 주장도 만만치 않다

“개발 도구는 무조건 오픈소스여야 한다"는 쪽에도 빈틈은 있습니다.

일단 오픈소스라고 안전한 게 아닙니다. 소스가 공개돼 있어도 아무도 안 읽으면 소용없습니다. 널리 쓰이는 오픈소스 패키지에 악성 코드가 몇 달씩 박혀 있다가 뒤늦게 드러난 사례가 여러 번 나왔습니다. “누군가는 봤겠지"는 검증이 아닙니다.

둘째는 지속가능성입니다. AI 도구는 모델 추론 비용이 계속 나갑니다. 서버도 사람도 있어야 합니다. 오픈소스로 풀어놓고 유지가 안 되면 손해는 결국 쓰는 쪽이 봅니다. 개발 도구 생태계에는 관리자가 지쳐 방치된 프로젝트가 널렸습니다.

셋째는 실무자의 냉정한 계산입니다. 폐쇄 소스지만 잘 만든 도구와 오픈소스지만 느리고 불안정한 도구. 뭘 고를까요. 현장에선 성능이 이깁니다. 이념보다 마감이 급하니까요.

그래서 실질적인 타협점은

요즘 분위기는 “전부 오픈소스"보다 검증 가능성쪽으로 기웁니다.

쓸 만한 기준이 몇 개 있습니다. 하나는 클라이언트만 오픈소스로 두고 모델과 서비스는 상용으로 가는 방식. 내 컴퓨터에서 도는 부분만 열려 있어도 뭐가 나가는지는 확인이 됩니다.

설정과 데이터를 옮길 수 있느냐도 큽니다. 프롬프트와 규칙, 프로젝트 컨텍스트를 표준 포맷으로 빼낼 수 있으면 락인의 절반은 풀립니다. 요즘 여러 도구가 설정 파일을 평범한 마크다운으로 두는데, 우연은 아닐 겁니다.

네트워크 동작을 문서로 밝히는 것도 방법입니다. 어떤 엔드포인트로, 어떤 조건에서, 무엇을 보내는지 적어두면 됩니다. 소스를 열지 않고도 할 수 있는 일입니다.

며칠이면 옮길 수 있나

폐쇄 소스 도구를 쓰지 말자는 얘기가 아닙니다. 뭐에 얼마나 기대고 있는지는 알고 쓰자는 얘기입니다. 지금 팀에서 쓰는 AI 코딩 도구가 내일 유료화되거나 서비스를 접는다면, 옮기는 데 며칠 걸릴까요.

그 며칠이 지금 여러분이 지고 있는 락인의 크기입니다. 한 번쯤은 세어볼 만합니다.