Claude와 Codex는 남기고 문서 작업은 로컬 AI로 옮긴 스타트업

개발자가 코딩 에이전트에 서비스 버그 수정을 맡깁니다. 에이전트는 먼저 원래 티켓을 찾고, 제품 관련 결정 몇 가지를 확인하고, 어떤 요구사항이 현재 적용되는지 파악해야 합니다. 패치 이후에는 디자이너나 고객 지원 담당자도 볼 수 있도록 남은 일을 티켓으로 정리해야 합니다. 코드 수정은 전체 업무의 일부지만, 모든 단계가 같은 유료 모델에 몰릴 수 있습니다.

직원 40명 미만의 소프트웨어 회사 Grayhat Developers는 2026년 11월 5일 사전 논문에서 이런 업무를 나눈 경험을 설명했습니다. 개발 업무에 자체 호스팅 모델을 써 봤지만 상용 코딩 에이전트를 교체하니 일부 저장소 작업이 더 느려지거나 어려워졌습니다. 복잡한 변경에는 기존 에이전트를 유지하고, 문서 검색과 준비, 티켓 동기화의 일부는 로컬 서비스로 옮겼습니다.

다른 소규모 팀에는 무엇을 먼저 옮길지가 중요합니다. Grayhat의 사례에는 구체적인 출발점, 살펴볼 만한 비용 추정, 모델 품질을 알아보기도 전에 시험을 좌초시킬 수 있는 초기 설정 문제가 나옵니다.

버그 수정은 코드를 건드리기 전에 맥락을 찾는 비용부터 듭니다

Grayhat은 문서에 Outline, 업무 추적에 Plane, 조직 정보에 ERPNext를 사용했습니다. 이미 사무실 컴퓨터 한 대에 이 서비스를 설치했고 Authentik으로 인증을 연결했습니다. Model Context Protocol(MCP) 커넥터도 같은 컴퓨터에서 실행했습니다. 모델 추론은 두 번째 컴퓨터가 맡았습니다. 이렇게 분리하면 모델이 다른 장비에서 연산 자원을 쓰는 동안 문서와 티켓 시스템은 평소처럼 동작할 수 있습니다.

논문에 나온 절차에는 사람이 넘겨주는 단계가 있습니다. 팀원이 내부 모델을 써서 위키나 이슈 추적기의 자료를 찾고 요약합니다. 관련 부분을 저장소 파일에 넣어 코딩 에이전트에 전달할 수 있습니다. 저장소 작업을 마친 팀원이 다음 단계를 내부 비서로 가져와 티켓 초안을 만들고 추적기로 보낼 수 있습니다. 논문은 에이전트 간 직접 통신을 후속 과제로 제시합니다. 지금도 사람은 경계에서 정보를 보고 외부로 넘겨도 되는지 판단할 수 있습니다.

Grayhat 작업 흐름에서 담당자가 바뀌는 지점. 11월 5일 사례를 바탕으로 Telli.sh가 제작했습니다.

고객이 내보내기 결과에 중복 행이 있다고 신고했다고 합시다. 원래 신고에는 비공개 계정 참조값과 버그와 무관한 전사문이 있습니다. 로컬 비서는 현재 내보내기 규칙, 서비스 담당자, 이전 우회 방법을 찾을 수 있습니다. 엔지니어는 가상 예시와 예상 행 수를 넣은 작업 설명을 작성합니다. 코딩 에이전트는 재현에 필요한 정보를 얻습니다. 무엇을 보낼지 사람이 선택하므로 민감한 자료는 내부 시스템에 남습니다.

내부 초안에는 원본 링크를 붙여 둡니다. 요구사항이 충돌할 때 검토자는 제안된 규칙이 최근 결정에서 왔는지 오래된 우회 방법에서 왔는지 확인할 수 있습니다. 로컬에서 만든 요약이라도 출처가 빠지면 해결하려던 문제를 다른 형태로 되풀이합니다. 다음 담당자가 어느 설명을 믿어야 할지 다시 알아봐야 합니다.

기존에 구입한 용량 중 얼마나 옮길 수 있는지 추정했습니다

저자들은 상용 AI의 월간 기준 비용이 약 325달러였다고 보고합니다. Claude 일곱 자리 약 175달러, Codex 구독 일곱 건 140달러, 크레딧 10달러를 합한 금액입니다. 서비스 전체에서 기록된 토큰이 259억 3,000만 개 이상이었다고도 보고합니다. 논문은 이 토큰이 325달러에 해당하는 청구 기간의 것인지 밝히지 않습니다. 두 숫자를 나눠 토큰 가격을 계산하기보다 각각이 측정하는 항목을 구분해야 합니다.

Grayhat 팀은 맥락 전달, 문서 작업, 프로젝트 조율이 상용 AI 업무의 3040%라고 추정했습니다. 저자들은 로컬 시스템이 그 항목의 약 90%를 맡을 수 있다고 보았습니다. 범위를 곱하면 전체 상용 업무량의 2736%입니다. 325달러의 같은 비율로 환산하면 월 약 88~117달러입니다. 11월 5일 사례 연구의 업무량과 비용 환산 추정치이며, 논문에서는 도입 전후 청구액을 통제해 비교하지 않았습니다.

Grayhat은 업무 비중을 추정하고 비용으로 환산했습니다. Telli.sh 자체 제작.

사용자 단위로 과금한다면 이 차이가 중요합니다. 개발자 일곱 명이 복잡한 작업에 여전히 구독이 필요하면 사용량이 줄어도 다음 청구서는 그대로일 수 있습니다. 패치를 더 처리할 여유, 사용량 한도 부담 감소, 추가 결제 감소로 이점이 나타날 수 있습니다. 요청 단위 과금이라면 더 일찍 차이를 볼 수 있지만, 반복 호출과 대기 시간이 예상 절감액을 줄일 수 있습니다. 새 GPU를 사고 장비를 유지할 사람에게 비용을 지급한다면 그것도 비교에 넣어야 합니다.

검토할 수 있는 분모를 고르세요. 작성한 티켓 수는 세기 쉽지만 프로젝트 책임자가 처음부터 다시 쓴 티켓은 절감의 증거가 되기 어렵습니다. 승인된 작업 설명과 티켓을 세고, 작업의 의미를 바꾼 수정 사항을 기록합니다. 검토자가 수용할 만한 결과를 일관되게 식별한 뒤 작성에 드는 수고를 측정합니다.

두 번째 화면에서는 설정을 맡는 사람이 바뀌었습니다

첫 배포는 LobeHub를 사용했습니다. 엔지니어는 자기 화면을 조직 내부 도구에 연결하는 지침을 받았습니다. 저자에 따르면 시연은 괜찮았지만 일상적인 사용으로 이어지지 않았습니다. 어떤 커넥터를 선택하고 어디에 있으며 어떻게 인증하는지 알아야 했습니다. 선택할 일이 늘어날수록 첫 번째 유용한 답을 얻기가 어려워졌습니다.

Grayhat의 두 번째 화면에서는 업무 도구를 중앙에서 설정했습니다. Saad Ahmed Bazaz, Talha Amjad, Abdurrehman Subhani, Sohaib Ahmed Bazaz, Abdullah Aamir의 논문 「Create Your Own Work Stack」 그림 2. CC BY 4.0.

팀은 중앙에서 설정한 LibreChat으로 바꿨습니다. 사용자는 준비된 도구를 보고 접근할 때 인증할 수 있었습니다. 저자들은 첫 버전에 관한 구조화된 인터뷰 11건에서 설정과 온보딩에 대한 의견 8건을 셌습니다. 두 번째 버전에서는 정형화되지 않은 Discord 피드백으로 같은 범주의 의견 3건이 나왔습니다. 수집 방식이 다른 두 숫자입니다. 초기 설정의 문제를 파악하는 데 도움이 되지만 도입이 얼마나 늘었거나 몇 명이 더는 문제를 겪지 않았는지 보여주지는 않습니다.

첫 세션은 가장 작은 실제 업무를 중심으로 설계합니다. 이슈의 승인 기준을 찾는 프로젝트 책임자는 추적기가 연결됐는지, 어떤 계정이 활성인지 볼 수 있어야 합니다. 티켓 세 개를 만들려는 엔지니어는 게시 전 초안을 검토할 수 있어야 합니다. 자기 일을 찾기 전에 커넥터 설정부터 가르치면 도구의 쓸모보다 사용자의 인내심을 측정하게 됩니다.

중앙 설정에는 새 책임이 생깁니다. 승인된 커넥터 목록을 유지하고 인증 정보를 교체하고 권한 변경 담당자를 설명할 사람이 필요합니다. 중앙 배포에서는 한 사람의 잘못된 설정이 모두의 문제가 될 수 있습니다. 장점은 반복되는 설정 문제를 한 번 고쳐 서비스 사용자 모두에게 같은 해결책을 적용할 수 있다는 점입니다.

결과의 담당자가 분명한 일을 로컬 시스템에 맡깁니다

이슈 분류는 실용적인 첫 후보입니다. 내부 비서는 중복 신고를 묶고 원본 티켓 링크를 포함한 요약을 제안할 수 있습니다. 프로젝트 책임자는 두 신고가 실제로 중복인지, 합친 설명에서 조건이 빠지지 않았는지 결정합니다. 비서는 분류 이유를 담은 댓글 초안을 작성할 수 있습니다. 변경에 담당자가 명확하므로 사람이 어떤 일이 일어났는지 알 수 있습니다.

문서 유지보수는 또 다른 일입니다. 제품 설정이 한 화면에서 다른 화면으로 옮겨졌다고 합시다. 비서는 오래된 도움말을 찾고 어느 에디션에 해당하는지 정리하고 수정안을 작성할 수 있습니다. 편집자는 현재 메뉴 위치를 확인해 올바른 변경을 게시합니다. 어려운 부분이 최신 내부 문서에 접근하고 각 글의 적용 범위를 유지하는 일이라면 더 강한 외부 모델이 보태는 가치는 작습니다.

복잡한 코딩은 반대 사례입니다. 데이터베이스 마이그레이션은 기존 데이터 계약을 살피고 여러 서비스를 바꾸고 되돌리는 절차까지 검증해야 할 수 있습니다. Grayhat은 시험한 로컬 환경이 큰 저장소 작업에서 어려움을 겪었다고 보고했습니다. 넓은 문맥과 빠른 추론이 필요할 때 특히 그랬습니다. 연구는 그 팀의 장비와 모델, 경험을 설명합니다. 범위를 늘리기 전에 자기 팀의 업무로 로컬 실행을 시험해 볼 근거가 됩니다.

단순 형식 작업과 민감한 데이터가 섞이면 전달 경로를 제한합니다. 원본 도구를 내부에서 실행하더라도 초안을 네트워크 밖에 보내면 정보가 드러날 수 있습니다. 외부 인수인계가 필요하면 목적지를 승인하고 그곳에 필요한 최소 자료만 만듭니다. 승인되지 않은 내부 결과는 사내 검토 대기열에 둡니다. 시간 초과가 나면 뜻밖의 외부 전송 대신 화면에 오류를 표시합니다.

짧은 시험으로 유용한 작업과 운영 수고를 구분합니다

1. 결과물 세 가지를 정합니다. 출처가 연결된 티켓 설명, 문서 수정, 이슈 초안을 고릅니다. 각 결과를 누가 승인하고 어떤 증거가 필요한지 한 문장으로 적습니다. 놓치기 쉬운 실수를 포함해 실패한 예와 성공한 예를 함께 남깁니다.
2. 현재 절차를 측정합니다. 평소처럼 일하는 한 주 동안 완료 수, 내용이 달라진 수정 수, 자료를 찾는 시간을 기록합니다. 가능하면 작업별로 상용 모델 사용량을 기록합니다. 해당 작업이 빠지면 실제로 구독 자리나 초과 요금이 줄어드는지 확인합니다. 애초에 하지 않게 된 작업도 따로 기록합니다.
3. 사내 도구 하나를 연결합니다. 프로젝트를 지정해 읽기 권한부터 줍니다. 권한 있는 직원은 알려진 이슈를 볼 수 있고 프로젝트 밖 사람은 볼 수 없는지 확인합니다. 이미 해당 업무를 하는 소수만 참여시키고 도구가 실패하면 사람이 끝낼 방법을 둡니다.
4. 쓰기 전에 초안을 비교합니다. 같은 검토자가 같은 기준으로 승인하거나 반려하게 합니다. 엉뚱한 이슈 링크, 오래된 사실, 근거 없는 결론을 기록합니다. 실제 이슈 추적기를 수정할 권한을 주기 전에 미리보기, 승인, 보존되는 기록을 마련합니다.
5. 실제로 옮겨간 일을 확인합니다. 승인 결과, 검토 시간, 실제 사용, 청구액을 비교합니다. 장비 유지보수, 중단, 커넥터 변경 시간도 더합니다. 이용자에게 직접 제공한 설정 지원도 포함합니다. 전문가가 한 사람마다 10분씩 도와야 동작한다면 그 역시 초기 도입 비용입니다.

이미 개발자용 로컬 모델을 운영한다면 평소 트래픽이 있는 상태에서 시험하세요. 여러 사람이 동시에 작업하면 대기열이 생깁니다. 한 요청을 빨리 처리하는 서비스도 세 사람을 기다리게 할 수 있습니다. 시간에 민감한 작업은 진행 상태를 보여주고 평소의 수동 방식으로 돌아갈 수 있게 합니다. 시험을 실제로 쓰면서 어떤 일이 잘 맞는지 알아갈 수 있습니다.

Grayhat 부록은 비교할 만한 규모를 알려줍니다. 업무 도구를 돌린 장비는 시스템 메모리 16GB였고, 별도 추론 장비에는 메모리 32GB와 VRAM 16GB의 RTX 4080이 있었습니다. 운영 과정에서 네트워크 모니터링, 예약 실행, 무정전 전원 장치를 추가했다고 보고합니다. 모델이 답을 생성하는 비용에 더해, 동료가 의존하는 서비스를 운영할 때 드는 예산을 가늠하는 자료입니다.

다음 한 시간의 AI 작업을 어디에 맡길지 정합니다

이 사례에서 가져갈 수 있는 방법은 자료 준비와 전문적인 추론을 나누고 각 인수인계의 담당자를 두는 것입니다. 자주 반복하고 팀이 이미 검토할 줄 아는 결과물을 만드는 일부터 시작합니다. 그 결과를 승인하는 데 필요한 일을 측정한 뒤 로컬 경로에 다음 작업을 맡길지 결정합니다. Grayhat 사례는 여전히 필요한 코딩 도구를 쓰면서도 이 판단을 하는 방법을 보여줍니다.

출처

• 2026년 11월 5일 Grayhat Developers 사전 논문
• 업무량 추정, 인프라, 그림 2를 포함한 전체 논문
• 그림 2 원본 이미지
• 논문 그림의 CC BY 4.0 라이선스

---

업무를 넘기는 과정에서 나눈 대화를 검색할 수 있게 정리하려면 Telli.sh 계정을 만들어 보세요.