AI 페어 프로그래밍(AI Pair Programming)으로 사이드 프로젝트 구축하기: Sharebox를 통해 배운 교훈

Sharebox는 단순한 불만에서 시작되었습니다. 단순히 누군가에게 영화 링크를 보내고 싶을 뿐인데 Plex나 Jellyfin은 너무 과하다는 생각이었습니다. 이 프로젝트는 AI를 상시 페어 프로그래머(Pair Programmer)로 두고 며칠간의 집중적인 작업 끝에 형태를 갖추게 되었습니다. 이는 단순히 분위기에 휩쓸려 코딩하는 '바이브 코딩(vibe coding)'도, 맹목적인 위임도 아닙니다. 그 중간 어디쯤에 있으며, 두 방식과는 상당히 다릅니다.

이러한 작업 방식에 대해 제가 배운 점은 여러분이 흔히 읽는 내용과는 다릅니다.

해결책: 세 가지 모드. 그대로 작동하는 파일(MP4/H.264, CPU 사용량 0)을 위한 Native 모드. 재인코딩 없이 컨테이너만 변경(MKV → MP4, 최소한의 CPU 사용)하는 Remux 모드. 그 외 모든 경우를 위한 Transcode 모드(ffmpeg 사용, 높은 CPU 사용).

AI는 ffprobe를 통한 코덱 감지 코드를 빠르게 생성했습니다. 문서를 읽는 데 하루가 걸렸을 작업이 단 두 시간 만에 끝났습니다. 세 가지 모드 사이의 결정 로직은 제가 직접 작성했습니다. 케이스를 혼동하는 AI의 모든 제안에 이의를 제기한 끝에 말이죠.

FPM 워커를 위한 파일 잠금 (File-locking)

PHP-FPM은 병렬 워커(parallel workers)를 생성합니다. 브라우저가 두 개의 탭을 열거나 iOS 플레이어가 병렬 범위 요청(parallel range requests)을 보낼 때, 여러 워커가 동시에 동일한 ffmpeg 프로세스를 시작할 수 있습니다. 그 결과: CPU 사용량 800%, 출력 파일 손상.

저는 문제를 설명했습니다. AI는 Redis 뮤텍스(mutex)를 제안했습니다. 저는 거절했습니다. Redis는 의존성(dependency)이므로, 우리는 의존성 없는 상태를 유지해야 합니다. AI는 파일 잠금(file lock)을 제안했습니다. 우리는 함께 이를 구현했습니다: 세그먼트당 하나의 .lock 파일, LOCK_EX | LOCK_NB를 사용하는 flock(), 그리고 30초 이내에 잠금을 획득하지 못할 경우의 타임아웃 설정.

이 과정에서 페어 프로그래밍이 효과적이었던 이유는 동시성(concurrency) 문제가 바로 AI가 탁월한 능력을 발휘하는 영역이기 때문입니다. 이는 이미 알려져 있고 문서화된 패턴이며 검증된 해결책이 존재합니다. 저의 역할은 솔루션을 프로젝트의 규칙 내로 제한하는 것이었습니다.

자막 캐싱 (Subtitle caching)

ffmpeg를 사용하여 2시간 분량의 MKV 파일에서 자막을 추출하는 데는 15~20초가 소요됩니다. 재생 시점에서는 용납할 수 없는 시간입니다. 해결책은 첫 접근 시 백그라운드에서 추출하고, 이후에는 디스크 캐시(disk cache)를 사용하는 것이었습니다.

AI가 캐시 메커니즘을 작성했습니다. 그러다 버그를 발견했습니다. 브라우저가 (추출 중인 동안의) 빈 HTTP 응답을 캐싱하고 있었고, 추출이 완료된 후의 후속 요청들도 빈 값을 반환하고 있었습니다. AI는 Cache-Control: no-cache 헤더를 제안했습니다. 정답이었습니다. 최종적인 이득은 후속 재생 시 20초의 지연 시간(latency)을 제거한 것이었습니다.

아무도 말하지 않는 한계

AI 페어 프로그래밍에는 사각지대가 있습니다. 명백한 버그가 아닙니다. AI는 종종 저보다 더 빠르게 그런 버그들을 고칩니다. 바로 구조적인 사각지대입니다.

프로젝트 컨텍스트(Project context)가 유지되지 않습니다. 매 세션마다 AI는 처음부터 다시 시작합니다. 당신이 인증 시스템을 추가하지 않기로 결정했다는 사실을 알지 못합니다. 배포 환경이 3유로짜리 VPS에 맞춰져야 한다는 점도 모릅니다. AI는 JWT, 리프레시 토큰(refresh tokens), 세션을 위한 Redis 등을 제안할 것입니다. 매번 제약 사항을 다시 설명하거나, 잘 관리된 CLAUDE.md 파일을 사용해야 합니다.

범위 관리(Scope discipline)를 유지하지 못합니다. 이것은 가장 교묘한 문제입니다. AI는 "~도 추가할 수 있습니다..."라는 문구를 자주 사용합니다. 알림 시스템, 전체 REST API, 플레이리스트 시스템 같은 것들 말이죠. 각각의 제안은 개별적으로 보면 합리적입니다. 하지만 이들이 모이면 단순한 도구를 복잡성의 괴물로 만들어 버립니다. 이런 방식으로 일할 때는 정기적으로 거절하는 것 자체가 하나의 기술입니다.

너무 쉽게 동의합니다. 당신이 결함이 있는 접근 방식을 제안하면, AI는 그것을 깔끔하게 구현해 버립니다. 인간 파트너라면 "잠깐만요, 정말 확실한가요?"라고 말했을 것입니다. AI는 기본적으로 "여기 구현 결과입니다"라고 말합니다. 당신의 선택에 이의를 제기해 달라고 명시적으로 요청해야 합니다.

효과적인 패턴

Sharebox에서 여러 차례 세션을 진행한 결과, 가장 좋은 결과를 만들어내는 패턴은 다음과 같습니다:

위임이 아닌 페어 리뷰(Pair review)를 하세요. "스트리밍 함수를 작성해 줘"라고 하면 작동은 하지만 프로젝트의 제약 사항을 존중하지 않는 결과물이 나옵니다. 반면 "내 구현 방식은 이래, 무엇이 문제일까?"라고 물으면 유용한 결과물을 얻을 수 있습니다.

해결책이 아닌 문제를 설명하세요. "여러 요청이 동시에 들어올 때 FPM 워커에서 동시성(concurrency) 문제가 발생해"라고 말하는 것이 "뮤텍스(mutex)를 구현해 줘"라고 하는 것보다 훨씬 낫습니다. 후자의 방식은 일반적인 답변을 내놓습니다. 전자의 방식은 컨텍스트에 대해 진정한 사고를 유도합니다.

첫 번째 솔루션을 절대 그대로 받아들이지 마세요. 그것이 나쁘기 때문이 아닙니다. 종종 정답일 때도 있습니다. 하지만 AI가 고려하지 못한 제약 사항이 거의 항상 존재하기 때문입니다. "대안은 무엇인가요?" 그리고 "이 접근 방식의 한계는 무엇인가요?"라고 체계적으로 질문하는 것은 유용한 무언가를 찾아내는 방법입니다.

git 제어권을 유지하세요. 모든 커밋(commit)은 하나의 결정입니다. AI는 커밋하지 않습니다 — 당신이 합니다. 이러한 최소한의 마찰은 건강한 습관입니다. 이는 당신이 맹목적으로 병합(merge)하기보다 저장소(repo)에 무엇이 들어가는지 읽도록 강제합니다.

git 로그가 드러내는 것

Sharebox의 최근 커밋(commit) 내역은 흥미로운 점을 보여줍니다. 최신 커밋들은 거의 모두 기능(feature)이 아니라 수정(correction)과 강화(hardening) 작업입니다.

인젝션(injection)을 방지하기 위해 Content-Disposition 내의 파일 이름을 정제(sanitising)하는 작업. 브라우저 감지가 초기화 전에 호출되는 iOS 호이스팅(hoisting) 버그 수정. 브라우저 캐싱으로 인한 자막 캐시 포이즈닝(cache poisoning) 수정. 병렬 요청(parallel requests)으로 인해 생성된 중복 ffmpeg 프로세스 수정.

이것이 며칠에 걸쳐 구축된 프로젝트에서 AI 페어 프로그래밍(AI pair programming)의 현실입니다. 반복 속도(iteration speed)는 실재합니다. 빠르게 첫 번째 작동 가능한 상태에 도달합니다. 그 후에는 통합(consolidation) 작업이 시작되는데, 이 단계에서 AI는 빌드(build) 단계만큼 유용하지 않습니다. 타이밍 버그(timing bugs), 레이스 컨디션(race conditions), 브라우저 에지 케이스(edge cases): AI는 해결책을 제안하지만, 실제 문제를 진단하는 데에는 AI가 대신해 줄 수 없는 세심한 로그 읽기가 필요한 경우가 많습니다.

리팩터링(refactoring) 또한 눈에 띕니다. 1,000줄 이상의 JS/CSS가 별도의 파일로 추출되었습니다. 그 정리 작업은 제가 원했던 것이었습니다. AI는 이를 잘 수행했지만, AI에게 그것은 필요하지 않았습니다. AI는 불평 없이 동일한 파일에 계속해서 코드를 추가했을 것입니다.

결론

Sharebox는 작동합니다. NAS에서 실행되며, 영화를 서빙하고, 자막을 처리하며, 병렬 요청을 견뎌냅니다. 혼자 했다면 걸렸을 시간의 아주 일부분밖에 걸리지 않았습니다.

AI 페어 프로그래밍이 변화시킨 것은 이미 알려진 문제들에 대한 반복 속도(iteration speed)입니다. 비디오 스트리밍, 동시성 처리(concurrency handling), 코덱 감지(codec detection): AI가 빠르게 작동할 수 있는 문서화된 영역들입니다. 변화시키지 못한 것: 범위 결정(scope decisions), 아키텍처(architecture), 과잉 엔지니어링(over-engineer)을 하지 않는 규율. 그러한 결정은 여전히 인간의 영역이며, 결과물의 품질에 직접적인 영향을 미칩니다.

진정한 이점은 "AI가 나를 위해 코드를 작성해 준다"가 아닙니다. 그것은 "대부분의 패턴을 알고, 지치지 않으며, 내가 검증한 것을 구현할 수 있는 페어(pair)가 24시간 내내 대기하고 있다"는 것입니다. 이것은 차원이 다른 이야기이며, 그 자체만으로도 이미 엄청난 가치가 있습니다.