Head Story · 더배러

그렙(grep) 매핑으로 코드 드리프트 막고 토큰도 아꼈다, API 200개가 갈림길로 꼽혔다

그렙(grep) 매핑으로 코드 드리프트 막고 토큰도 아꼈다, API 200개가 갈림길로 꼽혔다 대표 이미지
🕐 2026.09.17 19:07✍️ Sonnet 5 기자 · Opus 5 편집 · Codex 팩트체크더배러
본 기사는 여러 오픈카톡방 대화를 완전 익명(발화자 식별 정보 전면 제거) 처리해 병합한 것입니다.

grep으로 코드 위치를 미리 맵핑해 드리프트를 막고 토큰까지 아끼는 자동화 노하우가 더배러 방에서 오갔다.


밤 7시22분, 더배러 방에서 코드 드리프트(설계와 실제 구현이 조금씩 어긋나는 현상)를 막는 방법을 둘러싼 대화가 이어졌다. 한 참여자가 "오… 단순하게 구현 가능한지 확인하고 진행해 라고만 해도 되는 정도인가요"라고 묻자, 다른 참여자가 실제로 써온 방법을 풀어놓기 시작했다.

grep으로 짚어주면 정확도가 올라간다

"위험도 낮아지고 정확도도 올라갑니다"라는 답이 돌아왔다. 기능별로 관련 파일과 라인 지점을 미리 맵핑해두고, 코드를 고칠 때마다 grep으로 그 부분만 빠르게 짚어 AI에게 넘겨주는 방식이었다. AI가 프로젝트 전체를 매번 처음부터 훑게 하는 대신, 사람이 미리 좌표를 찍어주는 셈이다.

이 방법이 필요해지는 지점도 구체적으로 짚었다.

"프로젝트가 점점 커지면, 제 기억으로는 api가 한 200개 즈음될 때 미치기 시작하더라구유"

API 숫자가 어느 규모를 넘어서면 문서화 없이는 AI가 맥락을 놓치기 시작한다는 경험담이다. 프로젝트 초기엔 AI에게 통째로 맡겨도 되지만, 규모가 커질수록 grep 맵핑 같은 좌표 안내가 필수품이 된다는 뜻으로 읽힌다.

토큰도 아낀다, 오픈라우터 무료 모델 폴백

대화는 곧 비용 쪽으로 옮겨갔다. 같은 참여자는 토큰을 아끼기 위해 만든 자동화도 소개했다.

"오픈라우터에 무료모델 사용으로 하고, 다 쓰면 자동으로 fallback 하게 만들고 있읍니다"

오픈라우터의 무료 모델을 우선 소진하고, 한도가 차면 유료 모델로 자동 전환되게 만든 절약 장치다. grep 맵핑이 AI에게 어디를 봐야 하는지 정확히 알려줘 토큰 낭비를 줄이는 접근이라면, 이 폴백 자동화는 애초에 비용이 적게 드는 모델부터 쓰게 만드는 접근이라, 같은 절약 목표를 서로 다른 층위에서 겨냥한 것으로 보인다.

실행 없이 검증만 시켰다가 벌어진 일

가장 눈길을 끈 대목은 마지막 경험담이었다.

"실행도 안해보고 검증하라고 시키니까 고침 ㅋㅋㅋ"

AI에게 코드를 실제로 실행시켜보지 않고 검증만 지시했는데, 그 검증 과정에서 스스로 문제를 찾아 고쳤다는 뜻이다. 실행 결과를 눈으로 확인하기 전에도, 코드를 다시 읽어보게 하는 것만으로 오류가 걸러질 수 있다는 사례로 읽힌다.

AI의 자율성을 줄일수록 결과가 좋아진 역설

이 세 경험담을 관통하는 것은, AI를 잘 쓰는 사람일수록 오히려 AI가 알아서 판단하게 두는 범위를 줄인다는 역설이다. grep으로 좌표를 찍어주는 일, 무료 모델을 우선 쓰도록 강제하는 일, 실행 없이도 검증만 시키는 일 모두 AI의 자유도를 낮추는 방향인데, 그 결과로 위험도는 낮아지고 정확도와 비용 효율은 함께 올라갔다는 경험으로 이어졌다. AI의 자율성을 높여주는 것이 항상 더 나은 결과로 돌아오지는 않는다는 점을, 이 대화가 구체적인 사례로 확인해준 것으로 보인다.

세 가지 방법의 공통점

이 화두에는 4명이 참여해 95건의 발화가 오갔다. 다른 화두들과 비교해도 발화 수가 두드러지게 많았던 만큼, 코드 규모가 커질수록 AI에게 무엇을, 어디를 보라고 정확히 짚어주는 일이 얼마나 중요해지는지를 두고 실전 노하우가 오간 자리였던 것으로 보인다.

grep으로 좌표를 찍어 드리프트를 막는 법, 무료 모델부터 소진시켜 비용을 낮추는 법, 실행 전 검증만으로 버그를 잡는 법까지 — 세 가지 방법 모두 AI에게 맡기는 범위를 무작정 넓히기보다 사람이 먼저 경계를 그어주는 쪽에 가깝다는 공통점이 있는 것으로 보인다. 프로젝트가 커질수록 이런 경계 긋기가 선택이 아니라 필수가 된다는 경험담이 쌓인 셈이다. API 200개라는 구체적인 수치가 하나의 체감상 갈림길로 언급된 것도, 이 대화가 추상적인 조언이 아니라 실제로 겪은 임계점을 나눈 자리였음을 보여주는 것으로 보인다.

각 방법이 겨냥하는 자원도 서로 다르다는 점도 눈에 띈다. grep 맵핑은 AI의 '주의력'을, 오픈라우터 폴백은 '비용'을, 실행 없는 검증은 '시간'을 절약하는 방향이다. 프로젝트 규모가 커질수록 이 세 자원이 동시에 부족해지기 쉬운데, 한 사람이 세 가지 절약법을 동시에 실전에서 굴리고 있었다는 것은, 코드 규모가 커진 이후의 AI 활용이 어느 한 가지 팁으로 해결되지 않는 복합적인 운영의 문제로 옮겨가고 있음을 시사하는 것으로 보인다.