AI 코딩이 느린 진짜 이유 — 내가 통제할 수 있는 것만 모았다

신진형 · 에스엘파워 · 2026.08.20

서버(클로드·코덱스)의 추론 시간은 그들의 정책이라 제가 바꿀 수 없습니다. 하지만 “코딩이 완성되는 전체 속도”는 대부분 제 쪽에서 결정됩니다. 이 글은 그 통제 가능한 부분만 모은 것입니다. 대상 환경은 Windows PC · STM32 펌웨어 · ARM GCC이고, 효과가 큰 순서대로 적었습니다.

A. 왕복 줄이기 — 가장 큰 레버, 대부분 무료

에이전트 코딩은 “한 번 생각하고 끝”이 아닙니다. 서버 추론 ↔ 내 PC 실행을 수십 번 왕복합니다. 왕복 한 번마다 네트워크 지연 + 로컬 실행 시간이 붙습니다. 그래서 왕복 횟수를 줄이는 것이 돈 안 드는 최고의 가속입니다.

A-1. 관련 파일을 먼저 “지목”한다 (효과 큼 · 무료)

AI가 스스로 리포지토리를 뒤지게(grep·파일 탐색) 두면 왕복이 수십 번 발생합니다. 관련 파일을 미리 짚어주면 그 탐색이 통째로 사라집니다.

	지시 문장	결과
✗	“BMS 셀 밸런싱 로직 고쳐줘”	AI가 전체 프로젝트를 헤맨다
✓	“`bms_balancing.c`, `bms_config.h`, `afe_driver.c` 이 3개 파일만 본다. 셀 밸런싱 임계값 로직만 수정한다.”	탐색 왕복이 사라진다

임베디드 프로젝트는 파일이 흩어져 있어 탐색 비용이 특히 큽니다. 파일명을 아는 만큼 무조건 미리 줍니다.

A-2. “계획 먼저 → 승인 → 구현” 순서를 강제한다 (효과 큼 · 무료)

코드부터 짜게 하면, 방향이 틀렸을 때 구현 + 리뷰 전체를 다시 돌립니다. 재작업이 가장 비쌉니다. 먼저 계획(A4 반 장)을 받아 눈으로 확인한 뒤 구현을 지시하면 헛발질이 사라집니다.

“먼저 수정 계획만 알려줘. 어떤 파일의 어떤 함수를 어떻게 바꿀지 목록으로. 코드는 아직 쓰지 마.”
계획 확인 후 → “좋다. 이대로 구현해.”

A-3. 프로젝트 메모리 파일에 “고정 정보”를 박아둔다 (효과 큼 · 무료)

세션마다 AI가 “이 프로젝트 빌드는 어떻게 하지? 폴더 구조가 뭐지?”를 다시 탐색합니다. 이걸 파일 하나에 적어두면 그 반복 탐색이 영원히 사라집니다. 반복 작업에서 가장 큰 누적 절약입니다.

프로젝트 루트에 CLAUDE.md(또는 도구별 규칙 파일)를 만들고 아래를 채웁니다.

# 프로젝트: 3세대 13S4P BMS 펌웨어

## 빌드
- 명령: make -j8
- 툴체인: arm-none-eabi-gcc (경로: C:\gcc-arm\bin)
- 타깃 MCU: STM32xxxx

## 폴더 구조
- /src : 소스   /inc : 헤더   /drivers : AFE·CAN 드라이버
- 설정 상수: inc/bms_config.h  (여기만 수정, 코드에 하드코딩 금지)

## 규칙
- 통신: CAN / RS485 / BLE
- 셀 구성: 2S~23S 대응, 기본 13S4P
- 커밋 전 반드시 make 성공 확인

한 번 써두면 모든 세션이 이 파일을 먼저 읽고 시작합니다 → 매번 하던 탐색 왕복이 0으로.

A-4. 관련 변경을 한 번에 묶어서 지시한다 (효과 중간 · 무료)

“이것 고쳐” → 확인 → “저것도” → 확인… 찔끔찔끔 지시하면 매번 AI가 파일을 다시 읽습니다. 연관된 변경은 한 문장에 묶어 지시하면 재탐색이 줍니다.

A-5. “화면 출력 말고 파일로 바로 수정”을 지시한다 (효과 작음 · 무료)

AI가 코드 전체를 화면에 길게 뿌리면 그만큼 생성 토큰이 늘어 시간이 걸립니다. “설명 최소화하고 파일만 수정해”라고 하면 출력이 짧아져 응답이 빨라집니다.

B. 로컬 빌드 루프 빠르게 — Windows 임베디드 특화

AI는 내 컴퓨터가 빌드·컴파일·테스트를 끝낼 때까지 기다립니다. BMS 펌웨어처럼 컴파일이 무거우면, 서버 추론보다 로컬 컴파일 대기가 전체 시간을 지배합니다. 여기가 하드웨어·설정이 직접 효과를 내는 지점입니다.

B-1. Windows Defender에서 프로젝트·툴체인 폴더를 “제외”한다 (효과 큼 · 무료 · 오늘 5분)

컴파일할 때 수천 개의 .o(오브젝트) 파일이 순식간에 생겼다 지워집니다. Defender 실시간 검사가 그 파일 하나하나를 매번 스캔하면 빌드가 2~3배 느려집니다. 이건 임베디드 개발자들이 가장 많이 놓치는 숨은 병목입니다.

Windows 설정 → 개인정보 및 보안 → Windows 보안
바이러스 및 위협 방지 → 설정 관리 → 제외 항목 → 제외 추가
폴더 선택 → ① 프로젝트 폴더 ② ARM GCC 툴체인 폴더(예: C:\gcc-arm) ③ 빌드 출력 폴더 추가

B-2. 병렬 빌드(`-j`) + ccache로 재컴파일 생략 (효과 큼 · 무료)

기본 빌드는 파일을 하나씩 순서대로 컴파일합니다. 병렬 빌드는 CPU 코어 수만큼 동시에 돌립니다. ccache는 “안 바뀐 파일은 이전 결과 재사용”이라 두 번째 빌드부터 훨씬 빠릅니다.

make -j8

ccache는 설치 후 컴파일러 앞에 붙입니다 — CC = ccache arm-none-eabi-gcc. 그리고 매번 전체 리빌드 대신 바꾼 타깃만 증분 빌드합니다(clean을 습관적으로 하지 않습니다). STM32CubeIDE도 내부는 GNU make라 둘 다 적용됩니다. 프로젝트 설정 → C/C++ Build → Behavior에서 병렬 빌드를 체크하면 됩니다.

B-3. 디스크는 NVMe M.2, 메모리는 넉넉히 (효과 중간 · 비용 있음)

리포지토리 열기, git, 라이브러리 설치, 컴파일 — 전부 디스크를 때립니다.

디스크	체감	권장
HDD	매우 느림 (병목)	무조건 교체
SATA SSD	양호	여유되면 NVMe로
NVMe M.2	비약적으로 빠름	✔ 권장

RAM은 16GB 이상 확보해 스왑(디스크로 넘치는 것)을 막습니다. 대형 빌드·IDE 인덱싱이 메모리를 많이 씁니다.

B-4. 무겁게 반복한다면 WSL2 고려 (효과 중간 · 무료 · 중급)

ARM GCC 툴체인은 리눅스에서 더 빠른 경우가 많습니다. 다만 결정적 함정이 하나 있습니다.

C. 네트워크 — “속도”가 아니라 “지연”을 잡는다

직관과 달리, AI 코딩에서 인터넷 **대역폭(Mbps)**은 거의 의미가 없습니다. 오가는 건 몇 KB짜리 텍스트라 100Mbps든 1Gbps든 차이가 없습니다. 중요한 건 **지연(ping)**입니다.

AI가 파일 읽고·고치고·테스트하며 수십 번 왕복하는데, 매 왕복마다 ping 지연이 더해집니다. 택배를 100번 주고받는다고 하면, 트럭이 크냐(대역폭)보다 **왕복 한 번에 걸리는 시간(지연)**이 전체를 좌우합니다. 그래서 가능하면 와이파이 대신 **랜선(유선)**을 씁니다. 지연이 낮고 흔들림이 없습니다. 대역폭 요금제를 올리는 것보다 유선 연결이 더 효과적입니다.

다만 한국↔미국 서버 지연은 물리적으로 존재하고 없앨 수 없습니다(추정: 왕복당 대략 0.1~0.2초 수준). 그렇다면 답은 하나 — 왕복 자체를 줄이는 것입니다. C의 진짜 해법은 A로 돌아갑니다.

D. 모델·모드 골라 쓰기 — 일에 맞는 도구

모든 작업을 “가장 똑똑한(=가장 느린) 모델”로 돌리는 건, 못 하나 박는 데 크레인을 부르는 격입니다.

작업 성격	권장	이유
변수명 변경·주석·보일러플레이트	빠른 모델 / 사고 끄기	깊은 추론 불필요, 즉답
단순 버그 수정	중간 모델	속도·정확 균형
3세대 BMS 로직 설계·회로 검증	사고형(고성능)	실수 비용이 크므로 시간 투자 가치

쉬운 일에 사고형 모델을 쓰면 3분씩 낭비됩니다. 어려운 설계 검증에만 아껴 씁니다.

또한 대화가 길어질수록 AI가 매번 읽어야 할 맥락(컨텍스트)이 커져 첫 글자까지의 시간이 늘어납니다. 작업 하나 끝나면 새 세션을 시작해 불필요한 과거 맥락을 버립니다. 책상 위에 지난 서류를 산더미로 쌓아두고 새 일을 하면, 매번 그걸 다 헤집고 시작하는 것과 같습니다. 끝난 일은 치웁니다.

E. 컨텍스트 관리 — 짐을 가볍게

맥락을 작고 정확하게 유지할수록 서버의 준비 시간(prefill)이 짧아져 응답 시작이 빨라집니다.

무관한 폴더를 AI 시야에서 가린다 — 빌드 산출물, 라이브러리 캐시(build/, node_modules/, .o 폴더 등)를 AI가 스캔하면 시간과 맥락을 낭비합니다. .gitignore나 도구별 무시 설정으로 가려둡니다.
큰 파일은 “필요한 부분”만 준다 — 수천 줄짜리 파일 전체를 매번 넣지 말고, 관련 함수·구간만 지목합니다. 맥락이 작아야 빠르고 정확합니다.

F. 한 단계 더 — 고급 조언

위 기본기가 잡힌 뒤, 반복·규모 있는 작업에서 추가로 얻을 수 있는 것들입니다.

“정답 하나”보다 “여러 시도 후 고르기” 구조 — AI의 시간은 피로도 0에 무한 반복이 가능합니다. 사람 1명이 한 번 검토할 시간에, AI를 여러 관점으로 여러 번 돌려 교차검증시키는 편이 정답에 가깝습니다. 회로 검증·설계 리뷰처럼 실수 비용이 큰 일에 특히 유효합니다. 사람의 유한한 집중은 “최종 판단”에 쓰고, AI의 무한한 반복은 “여러 안 만들기·검증”에 쓰는 분업입니다.
자주 하는 작업은 스킬·규칙으로 자동화 — 매번 똑같이 지시하는 검사·변환·리뷰 절차는 규칙 파일이나 스킬로 만들어 둡니다. 지시를 다시 타이핑하는 왕복 자체가 사라집니다. 저희 정합성 검사·회로 검토가 이미 이 방식입니다.
빌드·테스트 캐시를 적극 활용 — ccache(B-2) 외에도, 테스트를 바뀐 모듈만 돌리도록 구성하면 AI의 검증 왕복이 짧아집니다. 전체 테스트는 커밋 직전 한 번만.
“언제 느려지는지” 관찰해 시간대를 활용 — 서버 부하는 사용자가 몰리는 시간에 커집니다(추정). 무거운 작업은 한가한 이른 아침 시간대에 돌리면 체감이 나을 수 있습니다.

병목 우선순위 한눈에 보기

투자 대비 효과 순입니다. 위에서부터 손대면 됩니다.

순위	할 일	효과	비용
1	지시를 좁혀 왕복 줄이기 (A-1)	매우 큼	무료
2	Windows Defender 폴더 제외 (B-1)	큼	무료 · 5분
3	프로젝트 메모리 파일 작성 (A-3)	큼(누적)	무료
4	계획 먼저 → 승인 → 구현 (A-2)	큼	무료
5	병렬 빌드 + ccache (B-2)	큼	무료
6	모델을 난이도에 맞게 선택 (D-1)	중간	무료
7	NVMe M.2 + RAM 16GB↑ (B-3)	중간	비용 있음
8	유선 이더넷 (C-2)	중간	거의 무료

지금 바로 할 일

오늘 안에 끝낼 수 있는, 돈 안 드는 것부터입니다.

Windows Defender 제외 항목에 프로젝트·arm-gcc·빌드 폴더 추가 — 5분 투자로 빌드가 즉시 빨라집니다. (B-1)
프로젝트 루트에 메모리 파일(CLAUDE.md) 작성 — 빌드 명령·폴더 구조·핀맵·규칙을 박아 AI의 탐색 왕복을 영구 제거합니다. (A-3)
make -j8 + ccache 적용, 빌드 폴더가 HDD면 NVMe로 이전 — 로컬 컴파일 대기를 줄입니다. (B-2·B-3)

이어지는 기록 — AI에게 코딩을 맡길 때 폭주를 막는 제동 장치는 〈하니스 엔지니어링〉, 그 하니스가 스스로 쌓는 부채 이야기는 〈하니스 부채〉, 세션을 나눠 쓰는 방법은 〈멀티세션 운용〉과 〈세션 메모리〉에 있습니다. 코드 규모가 부푸는 실제 현장 사례는 〈god 파일을 막지 못한 것〉을 참고하세요.