품질로는 못 이기는 도구를 팀에 권하는 법
사내망 안에서 도는 코딩 어시스턴트 TabbyML을 팀에 권하는 20분짜리 발표를 했다. 듣는 사람들은 당연히 Copilot이나 에이전트형 도구와 비교할 거라고 예상했다. 솔직히 자동완성 품질로는 이길 수 없었다. 이 글은 그 준비 과정의 기록이다. 발표 뒤의 반응과 도입 현황은 아직 기록하지 못했다.
품질로는 못 이긴다
임베딩 편과 자동완성 편에서 Tabby를 띄우고 자동완성이 뜨게 만들었다. 그 사이에 사용자들에게 받은 건의도 있었다.
- 다음 수정 위치를 제안하는 기능(Next Edit Suggestions)이 있으면 좋겠다.
- 맥락을 잘 못 잡아서 쓸모 있는 자동완성을 받기 어렵다.
뒤에 있는 모델이 Copilot이 쓰는 모델보다 작은 건 사실이다. 같은 기준(자동완성이 얼마나 똑똑한가)으로 비교하면 진다. 그래서 비교 기준 자체를 바꿨다.
축을 바꿨다 — 결정권과 코드의 위치
발표의 핵심은 표 하나였다.
| 에이전트형 (Codex, Claude Code, opencode 등) | Copilot | TabbyML | |
|---|---|---|---|
| 일하는 단위 | 태스크를 맡기면 알아서 실행 | 코드 한 줄·한 덩어리 | 코드 한 줄·한 덩어리 |
| 사람이 판단하는 때 | 결과가 다 나온 뒤 검토 | 그 자리에서 수락·거절 | 그 자리에서 수락·거절 |
| 코드가 있는 곳 | 벤더 클라우드로 전송 | 벤더 클라우드로 전송 | 사내 서버에 머묾 |
여기서 논지 세 개를 세웠다.
- 코드를 책임질 수 있는 상태. 에이전트형은 결과를 나중에 검토하는 구조라, 검토를 대충 하면 이해하지 못한 코드가 그대로 들어온다. 자동완성은 한 줄마다 Tab이나 Esc로 그 자리에서 판단하니, 최종 결정권이 사람에게 남는다.
- 옆에서 채워 주는 도구. 맥락이 지금 파일과 커서 주변으로 한정되고 제안도 작다. 판단할 거리가 작으니 피드백이 빠르다. “대신 해 주는 도구”가 아니라 “옆에서 채워 주는 도구”다.
- 통제권이 우리에게 있다. 클라우드 도구를 쓰는 건 결국 “벤더를 얼마나 믿느냐”의 문제다. Tabby는 접근 통제와 감사를 우리 인프라 기준으로 직접 관리한다. 우리가 다루는 코드에는 세무·고객 관련 로직이 자주 섞이는데, 그게 벤더 쪽 로그나 학습에 어떻게 쓰이는지 우리가 확인할 방법은 없다.
Copilot도 형태는 자동완성이라 같은 칸에 서지 않느냐는 질문이 나올 걸 예상했다. 답은 표의 마지막 줄이다. 형태는 비슷해도 코드가 밖으로 나간다는 점에서 클라우드 쪽에 선다.
약점은 먼저 꺼낸다
질문이 나오기 전에 먼저 말하기로 한 것들이다.
- 자동완성 품질은 Copilot보다 낮다. 이걸 “코드를 밖으로 내보내지 않는 대가”로 설명했다. 품질만 보면 Copilot이 위라는 걸 인정하고 시작한다.
- 처음엔 느렸다. 초기에는 백엔드가 CPU로 추론해서 후보 하나에 1초 가까이 걸렸다. 첫 번째 걸림돌이었다는 걸 숨기지 않았다.
- 코드 인덱싱(임베딩)은 꺼져 있다. 저장소 전체를 참고하는 기능은 아직 쓸 수 없다.
- 사내 SSO를 쓸 수 없다. 지금 라이선스로는 SSO가 열리지 않는다. 대신 인스턴스를 세 개로 나눠 팀 규모를 감당하고, 계정은 초대 링크로 각자 만든다.
- 받은 건의는 로드맵에 올려 두고 그렇다고 말한다. 맥락 부족, 다음 수정 위치 제안. 이미 듣고 있다는 걸 보여 주는 쪽이 신뢰를 얻는다.
이유는 단순했다. 이런 약점은 결국 쓰다 보면 드러난다. 숨겼다가 나중에 나오면 발표 전체가 의심받는다. 먼저 꺼내면 “그걸 알고도 권한다”는 근거가 된다.
예상 질문을 연습했다
발표 전에 가상의 청중 둘을 세워 질문을 주고받는 연습을 했다. “왜 Copilot 말고 이걸 써요?”라고 묻는 주니어, 그리고 “설치 귀찮아서 안 쓸 것 같은데”라고 말하는 시니어다. 거기서 나온 질문을 표로 정리해 뒀다.
| 예상 질문 | 답의 핵심 |
|---|---|
| 속도는 Copilot 대비 어때요? | 초기에 느렸던 것부터 인정한다 |
| 자동완성이 별로라던데요? | 인정한다. “품질 대 코드 미유출”의 교환으로 설명한다 |
| 요즘은 에이전트형이 대세인데 왜 거꾸로 가요? | 코드 책임 논지 — 결정권이 사람에게 남아야 한다 |
| 그냥 Copilot이 낫지 않아요? | 품질은 Copilot이 위. 대신 우리 코드가 벤더로 나간다 |
| SSO 되나요? | 안 된다. 인스턴스 셋 + 초대 링크로 대신한다 |
| 귀찮은데 안 쓰면 안 돼요? | 설치는 팀 배포용 업데이트 사이트 하나, Node 버전만 맞추면 된다 |
가장 세게 준비한 질문 세 개 가운데 두 개는 이랬다. “품질이 낮으면 왜 써야 하냐”는 피할 수 없는 정면 질문이라 교환으로 답하고, “에이전트형이 대세인데 왜 역행하냐”는 발표의 핵심 논지로 답한다.
데모는 라이브로, 단 미리 한 번 돌려 둔다
활용 예는 셋으로 줄였다. 주석만 써 두고 기다리면 코드를 채워 주는 자동완성, 모르는 메서드를 골라 “이게 뭘 하는 거죠?”라고 묻는 설명, if 중복을 줄일 방법을 묻는 리팩토링 제안이다. 영상으로 대신하지 않고 실제 IDE에서 보여 주기로 했다.
대신 발표 직전에 자동완성을 한 번 미리 돌려 두는 걸 필수로 적어 뒀다. 백엔드가 쉬고 있다가 첫 요청을 받으면 모델을 다시 올리느라 15초 넘게 걸릴 수 있다. 자동완성 편에서 실제로 겪은 콜드 스타트다. 청중 앞에서 15초 동안 아무것도 안 뜨면 앞의 논지가 다 무너진다.
발표 자료는 React와 Reveal.js로 직접 만들었다. 슬라이드 전환 애니메이션은 전부 껐다. 대본을 슬라이드 단위로 끊어 읽기 쉽게 하려는 것이었다.
결과는 아직 적지 못했다
발표는 9월 10일에 했다. 발표 뒤의 반응, 실제로 몇 명이 쓰기 시작했는지, 후속으로 무엇을 했는지는 아직 기록으로 남기지 못했다. 알게 되면 덧붙이겠다.
마치며
진짜로 배운 것
- 이길 수 없는 축에서 싸우지 않는다. 품질 비교로는 지는 도구라면, 그 도구가 실제로 다른 지점(결정권, 코드의 위치)으로 비교 기준을 옮긴다. 단, 그 축이 진짜 차이여야 한다. 억지 축은 질문 하나에 무너진다.
- 약점은 먼저 꺼내면 근거가 되고, 나중에 들키면 흠이 된다. 품질, 속도, 꺼진 기능, 못 쓰는 SSO를 먼저 말했다.
- 데모는 실패할 수 있는 지점을 미리 없앤다. 콜드 스타트처럼 이미 겪어 본 함정은 체크리스트에 넣는다.