금요일 오후, 50개 파일이 변경된 Pull Request(PR)가 올라왔습니다. 기능 구현에 꼭 필요한 대규모 리팩토링이 포함되어 변경 사항이 많습니다. 동료들은 ‘월요일에 볼게요’라는 코멘트만 남기고, 결국 다음 주 배포 일정은 기약 없이 밀리기 시작합니다. 리뷰어는 어디서부터 봐야 할지 막막하고, PR 작성자는 리뷰가 늦어지면서 생기는 충돌(conflict)을 해결하느라 시간을 허비합니다.
이런 상황의 근본 원인은 컨텍스트 부족입니다. 리뷰어는 변경된 코드의 전체 맥락을 파악하는 데 상당한 인지 자원을 소모해야 합니다. 모든 함수 호출 관계를 추적하고, 사이드 이펙트 가능성을 따져보는 과정은 지루하고 어렵습니다. 결국 리뷰는 피상적인 코드 스타일에만 집중되거나, 핵심 로직은 제대로 보지 못한 채 ‘LGTM’을 남기게 될 수도 있습니다.
이 글에서는 AI 기반 코드 편집기 Cursor를 활용해 이 문제를 어떻게 해결할 수 있는지 Before/After 형식으로 비교해 보겠습니다. AI가 코드베이스 전체의 맥락을 이해하고 요약해주는 기능을 활용하여 리뷰어의 부담을 줄이고, 더 깊이 있는 리뷰가 가능하도록 돕는 구체적인 방법을 다룹니다.
새로운 프로젝트에 합류한 동료가 레거시 모듈의 리팩터링을 맡았습니다. 수천 줄에 달하는 파일을 이해하기 위해 Claude 3 Opus 같은 고성능 모델에 전체 코드를 복사해 붙여넣고 질문을 시작했습니다. 결과물은 꽤 만족스러웠지만, 비슷한 작업을 하던 다른 팀원은 다른 모델을 쓰거나 다른 방식으로 질문해 전혀 다른 답변을 받았습니다.
월말에 정산된 청구서를 보고 모두가 놀랐습니다. 특정 몇몇 작업에서 예상보다 수십 배 높은 비용이 발생한 것을 발견했습니다. 원인은 긴 컨텍스트를 무분별하게 입력한 것이었습니다. 개인의 생산성은 일시적으로 올랐을지 몰라도, 팀 전체로 보면 비용 예측이 불가능해지고 결과물의 일관성도 사라지는 문제가 생긴 것입니다.
이 글에서는 팀에 Anthropic 모델을 도입할 때, 기술 리드나 시니어 개발자가 미리 정해두면 좋은 몇 가지 규칙과 기본 설정을 다룹니다. 이를 통해 비용을 예측 가능하게 관리하고 팀원들의 결과물 품질을 일정 수준으로 유지하는 데 도움을 줄 수 있습니다.
레거시 서비스 마이그레이션 작업 중 Antigravity CLI를 처음 도입했습니다. 처음 며칠은 잘 됐는데, 파일 수가 늘어나면서 CLI가 “이미 수정한 파일”을 다시 건드리기 시작했습니다. 확인해보니 세션 간 컨텍스트가 초기화되면서 앞서 내린 결정을 전혀 모르는 상태로 다음 작업을 이어간 것이었습니다. 덕분에 같은 함수의 시그니처가 두 번 바뀌었고, 그 사이에 작성된 테스트는 두 번 다 깨졌습니다.
이 글은 Antigravity CLI가 컨텍스트를 어떻게 다루는지, 어디서 소실이 일어나는지, 그리고 세션을 넘어서도 의도가 유지되도록 하는 패턴을 다룹니다. “CLI가 멋대로 코드를 바꾼다”는 증상을 겪고 있다면 원인이 도구 버그가 아닐 가능성이 높습니다.
이 글을 읽으면 Antigravity CLI에서 세션 경계를 넘을 때 컨텍스트가 왜 끊기는지, 그리고 그걸 막기 위해 어떤 파일 구조와 호출 패턴을 써야 하는지 파악할 수 있습니다.
최근 팀에서 사용하는 상용 LLM API의 월간 비용이 예상치를 넘어서기 시작했습니다. 데이터 보안에 대한 우려도 있어, 대안으로 로컬에서 모델을 직접 실행하는 방안을 검토하게 되었습니다. 마침 M2 Max 칩이 탑재된 개발 장비도 있었고, LM Studio를 이용하면 복잡한 설정 없이도 몇 번의 클릭만으로 Llama 3 같은 고성능 모델을 실행할 수 있다는 점이 매력적이었습니다.
초반의 경험은 성공적이었습니다. API 키 관리나 토큰 비용 걱정 없이 자유롭게 코드를 생성하고 질문을 던질 수 있었습니다. 간단한 스크립트 작성이나 보일러플레이트 코드 생성에는 즉각적인 도움이 되었습니다. 하지만 일주일 정도 실무에 깊숙이 적용해 보니, 하드웨어 사양이나 모델 성능 외에 예상치 못한 ‘비용’이 발생하고 있음을 깨달았습니다. 눈에 보이는 금전적 비용은 아니었지만, 분명히 제 시간과 정신적 에너지를 소모시키고 있었습니다.
이 글에서는 LM Studio를 이용한 로컬 모델 운영 시 하드웨어 사양 너머에 숨어 있는, 간과하기 쉬운 3가지 비용(탐색, 일관성, 컨텍스트)을 구체적인 사례와 함께 다룹니다.
스프린트 중반에 팀원 한 명이 Copilot이 만들어준 코드를 그대로 PR에 올렸습니다. 리뷰어는 로직이 맞는지 확인하는 데 평소보다 두 배 시간이 걸렸고, 결국 “이 코드 직접 짠 거야, Copilot이 짠 거야?”라는 질문으로 리뷰가 시작되었습니다. 그 팀은 Copilot을 도입한 지 3주가 지났지만 어떤 기준도 없었습니다.
이런 상황은 도구 자체의 문제가 아닙니다. Copilot은 개인 생산성 도구로 설계되었지만, 팀에서 쓰면 리뷰 기준, 컨텍스트 공유, 라이선스 관리가 동시에 따라옵니다. 아무 준비 없이 “일단 써봐”로 시작하면 생산성이 오르기 전에 마찰이 먼저 생깁니다.
이 글에서는 팀 규모별(1인 → 3인 → 10인)로 리드가 Copilot 도입 전에 결정해야 할 항목과 그 이유를 다룹니다. 설치 방법보다는 팀 합의 포인트에 집중합니다.