제품 분석 플랫폼 PostHog의 엔지니어들이 대규모 프로덕션 환경에서 AI 코딩 도구를 사용하며 겪은 시행착오와 해결책을 공유했습니다. 8,984개 파일, 162만 줄 규모의 실제 코드베이스에서 얻은 이 교훈들은 “처음부터 새로 만들기” 중심의 기존 AI 코딩 조언과는 전혀 다른 실전 인사이트를 제공합니다.
핵심 포인트:
- 맥락 관리의 중요성: 대규모 코드베이스에서는 전체 앱이 AI 컨텍스트 윈도우에 들어가지 않아 무엇을 포함할지 신중하게 선택해야 함. 막연한 “더 좋게 만들어줘” 식 프롬프트는 AI를 혼란스럽게 만듦
- 구체적 가드레일 설정:
.cursor/rules와claude.md같은 명세 파일로 AI에게 명확한 가이드라인 제공. PostHog는 언어별 규칙 파일, 기존 코드 참조 예시, 서브에이전트 설정 등으로 AI의 일탈 방지 - AI의 강점과 약점 파악: 자동완성과 테스트 수정에는 탁월하지만, 익숙하지 않은 언어(HogQL)나 최신 API 사용에는 취약. “열정적이지만 경험 없는 인턴”으로 생각하면 현실적인 기대치 설정 가능
대규모 코드베이스는 완전히 다른 게임이다
PostHog의 제품 엔지니어인 Paul D’Ambra는 이렇게 말합니다. “LLM이 학습한 데이터 대부분이 ‘처음부터 시작하는 법’에 관한 블로그라서, 그게 아닌 작업에는 프롬프트를 작성하는 것보다 직접 하는 게 더 쉬울 때가 많다”고요.
실제로 대규모 코드베이스에서는 몇 가지 근본적인 차이가 있습니다. 우선 앱 전체가 AI의 컨텍스트 윈도우에 들어가지 않습니다. 따라서 무엇을 포함할지 신중하게 선택해야 하죠. 또한 AI가 예상치 못한 부분까지 변경할 수 있어요. 작은 프로토타입에서는 괜찮지만 프로덕션 앱에서는 재앙이 될 수 있습니다.
그래서 PostHog는 .cursorrules 파일에 이런 규칙을 명시했습니다: “고수준 얘기는 집어치워. 수정이나 설명을 요청하면 실제 코드나 설명을 원한다고! ‘이렇게 하면 됩니다 blablabla’ 같은 건 원하지 않아.”
테스트, 린팅, 타입 체킹의 중요성도 커집니다. AI가 의도하지 않은 결과를 만들어내는 걸 막아주는 안전장치니까요.
맥락과 가드레일이 핵심이다
LLM은 비결정적이기 때문에 여러 방향으로 빗나갈 수 있습니다. PostHog가 만든 AI 설치 마법사는 기본적으로 이를 방지하는 큰 비계(scaffold)입니다. 사용자가 AI에게 직접 PostHog 설치를 요청하면 구식 패턴, 환각된 API 키, 존재하지 않는 라이브러리를 사용하게 되거든요. PostHog에 대한 맥락과 구현 가이드레일을 제공함으로써 이 모든 걸 방지합니다.
PostHog가 의존하는 구체적인 맥락과 규칙들을 살펴볼까요?
기존 코드 참조: 미리 만들어진 UI 컴포넌트, 데이터베이스 스키마, 최적화된 쿼리, 테스트 패턴, 상태 관리 구조 등을 최대한 참조하게 합니다.
문서와 소스 코드: 사용 중인 라이브러리, 프레임워크, 도구의 문서와 소스, 예제를 포함시킵니다. PostHog의 Danilo는 LLM을 “웹의 지연되고, 손실이 있고, 압축된 스냅샷”이라고 부르는데요. 그래서 가능한 한 완전한 그림을 제공해야 합니다. PostHog는 모든 문서 페이지에 “마크다운으로 복사” 버튼도 추가했어요.
.cursor/rules 파일: 언어별로 다른 규칙 파일을 만듭니다(Python, Typescript, Rust 등). 원칙, 프로젝트 구조, 의존성, 베스트 프랙티스, 네이밍 컨벤션, 로깅, 테스팅, 보안 세부사항을 포함하죠.
claude.md 및 명세 파일: .cursor/rules와 겹치는 부분도 있지만, 무엇을 하고 싶은지에 대한 명확한 명세가 훨씬 더 중요합니다. Claude가 테스트, 린팅, 빌드에 사용할 수 있는 명령어도 포함합니다. PostHog의 claude.md를 참고하세요.
Claude용 서브에이전트: 코드 리뷰, 체계적 디버깅, 테스트 작성, 프롬프트 엔지니어링 같은 특정 작업을 돕는 에이전트들입니다. 일부 팀원은 Claude와 Mergiraf를 조합해서 복잡한 머지 충돌을 해결하기도 합니다.
AI가 아닌 도구들도 여전히 중요하다
엔지니어들은 AI가 아닌 도구들로 실수와 이슈를 방지하는 체계를 구축해왔습니다. 이런 도구들은 AI와 함께 사용할 때도 똑같이(아니 더 잘) 작동하고, 이런 도구를 업그레이드하는 게 AI 도구보다 개발자 생산성에 더 큰 영향을 미치는 경우가 많습니다.
PostHog가 사용하는 도구들: Ruff, Oxlint, mypy, Prettier 등의 린팅, 포매팅, 타입 체킹 도구. Jest, Playwright, pytest 같은 테스팅 도구. Python과 Typescript 모두에서 타입 힌팅 필수. PyCharm, JetBrains 테스팅 스위트, IntelliJ 같은 IDE 도구. 스타일 가이드와 코딩 표준.
개발자들, 특히 제품 엔지니어들은 AI 이전부터 이미 이런 도구들에 의존하고 있었습니다. AI는 단지 이런 결정론적 체크와 가드레일을 더욱 중요하게 만들었을 뿐이죠.
Pragmatic Engineer의 Gergely에 따르면, Google은 “10배 더 많은 코드가 배포될 것”을 준비하고 있다고 합니다. 전 Google SRE는 이렇게 말했죠. “SRE 친구들한테 들었는데, 프로덕션에 들어가는 코드 줄 수가 10배 늘어날 거라고 준비하고 있대요.”
10배 많은 코드는 10배 많은 코드 리뷰, 배포, 기능 플래그, 소스 관리 풋프린트를 의미합니다. 그리고 조심하지 않으면 버그와 장애도 10배 늘어날 수 있습니다.
AI가 잘하는 것과 못하는 것을 파악하라
AI를 효과적으로 사용하려면 AI가 유용한 상황과 그렇지 않은 상황의 사례를 계속 쌓아가야 합니다. AI가 할 수 없다는 걸 알면서도 반복해서 요청하면 시간과 에너지를 낭비하게 되니까요.
PostHog의 Ingestion 제품 엔지니어 Nick Best는 이렇게 말합니다. “Rust를 작성하는 Claude Code는 기후 변화를 가속화하는 while 루프다.”
유용한 방법은 AI 어시스턴트를 동료처럼 의인화하는 겁니다. 어떤 사람들은 AI를 “인턴 군대”라고 부르고, Birgitta Böckeler는 “열정적이고, 고집스럽고, 박식하지만, 경험이 없고, 모를 때도 인정하지 않는” 특성을 가진 존재로 정의합니다. AI를 의인화하는 건 기본적으로 AI 시대의 러버덕킹(rubber ducking) 버전이에요.
PostHog 팀이 AI가 뛰어나다고 생각하는 부분:
- 자동완성: 모두가 탭 키를 반복해서 눌러 작업을 끝내는 걸 좋아합니다
- 테스트 추가 및 수정: 더 많은 버전의 테스트를 추가하고 고치는 것
- 러버덕킹: 깊이 있는 질문하기, 코드베이스와 맥락에 대해 더 배우기. LLM이 있으면 어떤 파일이나 함수든 이해하기 더 쉬워집니다
- 리서치: 코딩과 직접 관련은 없지만 엔지니어가 해야 하는 일. 더 이상 StackOverflow 답변을 찾으려고 구글링할 필요가 없습니다
반면 AI가 서툰 부분:
- 익숙하지 않은 언어로 코드 작성: PostHog의 내부 SQL 버전인 HogQL 같은 것
- 올바른(또는 심지어 존재하는) 메서드, 클래스, 라이브러리 사용: 이런 것들을 정기적으로 환각하고 이름을 기반으로 기능을 가정합니다(내용이 아니라)
- 최신의 베스트 프랙티스 따르기: 예를 들어 deprecated API를 자주 사용합니다
- 처음부터 테스트 작성: Paul은 “세상에 형편없는 테스트 예제가 너무 많아서 LLM도 똑같이 형편없는 테스트를 만들어낸다”고 말합니다
AI가 잘하는 것과 못하는 걸 파악하면 메타 레벨에서도 도움이 됩니다. AI가 할 수 있는 쉬운 일만 하고 정작 중요하지만 어려운 일(AI가 못하는)은 안 하는 함정에 빠지는 걸 막아주거든요.
끊임없이 실험하라
훌륭한 제품 엔지니어의 특징은 항상 실험한다는 겁니다. AI 도구에 관해서도 마찬가지죠.
PostHog 팀은 항상 새로운 도구와 접근법을 테스트하고 이야기합니다. Slack에 “Cursor”라는 단어가 들어간 메시지가 1,104개, “Claude Code”가 187개나 됩니다. 공동창업자들이 초기부터 주도했고요.
James는 열렬한 vibe coder로, (악)명 높게도 비행기 안에서 채용 게시판 프로토타입을 만들었습니다(나중에 웹사이트 팀이 완전히 다시 작성하긴 했지만요 🙈). Tim은 진짜 개발자™이고 AI 워크플로우에 대한 온건에서 날카로운 의견까지 정기적으로 기여합니다.
PostHog가 워크플로우를 개선하는 구체적인 방법:
AI 도구 예산을 월 $300으로 인상: 사람들이 Claude Max와 다른 최상위 모델을 시도할 수 있게 했습니다.
다양한 도구, 에이전트, 프레임워크 테스트: Claude Squad(작동 안 함), Git worktrees, Traycer, Relace, Robusta 등.
같은 도구로 다른 모델 시도: 어떤 모델이 무엇을 잘하는지 파악하기 위해서입니다. 예를 들어 많은 엔지니어가 Sonnet 대신 Opus로 전환하는 게 엄청나게 유익하다고 느끼고, Cursor에서 Qwen을 실험하고 있습니다.
자체 AI 엔지니어링 도구 구축 및 사용: Max AI, PostHog MCP, LLM 분석 같은 것들. Lovable이나 ElevenLabs 같은 AI 엔지니어링 최전선의 팀들과도 많이 대화합니다.
해커톤에서 AI 관련 프로젝트: 거의 모든 해커톤에 AI 관련 프로젝트가 있었습니다. 더 많은 팀원이 새로운 도구를 탐색하고 AI가 무엇을 잘하고 못하는지 이해할 기회를 제공하죠.
더 세부적인 수준에서 훌륭한 엔지니어들은 항상 다양한 프롬프트와 참조를 실험합니다. 이들의 출력을 계속 판단하면서 자신에게 맞는 이상적인 워크플로우를 만듭니다(이건 끝이 없어요).
AI를 싫어하더라도 사용해야 하는 이유
개인적으로 AI를 싫어하더라도 사용하지 않는 건 실수입니다. 두 가지 이유가 있는데, 둘 다 당신과는 무관합니다.
첫째, 경쟁사가 AI를 사용하고 있습니다. 고객들은 당신의 제품을 AI 기반 대안과 비교할 겁니다. (좋은) 경쟁사의 엔지니어들도 AI를 사용해서 당신보다 빨리 출시하려고 할 거고요. 당신의 제품과 프로세스가 AI 기반 대안보다 나은 이유를 알아야 합니다.
둘째, 사용자들은 거의 확실히 AI를 사용하고 있습니다. 그들의 워크플로우에 AI가 있어요. 일부는 당신이 만든 걸 그들의 워크플로우에 맞추려고 시도할 겁니다. 특히 개발자를 위해 만든다면, 직접 시도해보지 않고는 소프트웨어 개발에서 AI를 사용하는 완전한 경험을 이해할 수 없습니다.
두 경우 모두 AI의 능력과 한계를 아는 게 도움이 되고, 직접 경험만 한 게 없습니다. 이런 면에서 AI 코딩은 작성한 코드를 전혀 사용하지 않더라도 큰 혜택을 줄 수 있어요.
PostHog 팀의 경험담은 AI 코딩 도구가 만능이 아니라는 점을 분명히 보여줍니다. 하지만 올바른 가드레일과 명확한 이해, 지속적인 실험을 통해 실제 업무에서 생산성을 높일 수 있다는 것도 증명하죠. 큰 아키텍처 결정을 올바르게 내리고, 무엇을 만들지 파악하고, 올바른 포지셔닝과 도구를 선택하는 것은 여전히 중요합니다. AI가 있든 없든 이걸 알아내는 건 결국 당신에게 달려 있습니다.
답글 남기기