GTM에서 소프트웨어 엔지니어링까지: 모델보다 프로세스를 빌려오기

저는 소프트웨어 엔지니어가 아닙니다. 제 배경은 GTM (Go-To-Market)입니다. 그래서 지금은 GTM 엔지니어라고 불러야 할 것 같네요. 저는 수년간 SaaS 창업자들이 창업자 주도 실행(founder-led execution)에서 확장 가능한 성장(scalable growth)으로 나아가는 방법을 찾는 것을 도와왔습니다. 하지만 오늘날 저는 GTM을 하나의 코드 문제로 보고 있으며, 놀라울 정도로 많은 시간을 소프트웨어를 출시(shipping)하는 데 소비하고 있습니다.

• Cloudflare Workers
• 내부 도구 (Internal tools)
• 리드 스코어링 시스템 (Lead scoring systems)
• 데이터베이스를 기반으로 한 클라이언트 마이크로사이트 (Client microsites)

가장 흥미롭게 빌려온 개념은 바로 **엔지니어링 프로세스 (engineering process)**였습니다.

프로그래밍 (Programming)과 엔지니어링 (engineering)은 서로 다른 직업입니다.

모델보다 프로세스가 더 중요하다

제가 작업하는 모든 것은 Linear 이슈(issue)에서 시작됩니다.

GTM 워크플로우든, 내부 도구든, 클라이언트 기능이든 상관없이 모두 동일한 파이프라인을 거칩니다:

Backlog → Todo → In Progress → Review → Done

이슈가 준비되면, 오케스트레이터 에이전트 (orchestrator agent)가 이를 가져갑니다:

1. 한 에이전트가 이를 구축합니다.
2. 다른 에이전트가 이를 검토(review)합니다.
3. 세 번째 에이전트는 검토자가 명시적으로 승인한 경우에만 배포(deploy)합니다.

흥미로운 점은 에이전트가 세 명이라는 것이 아니라, 모든 단계가 그 근거(reasoning)를 남긴다는 것입니다. 각 인수인계(handoff)는 무엇이 변경되었고, 무엇이 테스트되었으며, 무엇이 여전히 위험해 보이는지를 설명하는 Linear의 댓글이 됩니다. 티켓 자체가 감사 추적(audit trail)이 되는 것입니다.

이것은 제가 일하는 방식을 완전히 바꾸어 놓았고, 모든 것을 작은 작업(tasks)으로 분리하도록 저를 이끌었습니다.

코드 작성 전 아이디어 검증하기

저는 Matt Pocock의 워크플로우를 거의 그대로 빌려왔습니다. 코드를 작성하기 전에 아이디어를 철저히 검증하는 것입니다. 제 시간의 20%만이 코딩에 사용되기 때문에, 이를 작동하도록 적응시켜야 했습니다.

저의 흐름은 다음과 같습니다:

1. /grill-me — 모든 가정을 반박하고, 누락된 요구사항, 엣지 케이스 (edge cases), 그리고 모순점을 찾아냅니다.
2. /to-prd — 대화를 적절한 사양서 (specification)로 변환하고, 이를 Linear의 구현 작업 **체크리스트 (checklist)**로 게시합니다.
3. Code — 에이전트 (agent)가 코드를 작성하기 시작할 때쯤이면, 에이전트는 프롬프트 (prompt)가 아닌 문서(document)를 바탕으로 작업하게 됩니다.

체크리스트 (Checklists)는 LLM (Large Language Models)에 매우 효과적입니다. 모델이 단계를 건너뛰지 못하도록 강제하기 때문입니다.

이는 아마도 모델을 교체하는 것보다 품질을 더 많이 향상시켰을 것입니다.

프론티어 모델 (Frontier Models)은 의사결정을 해야 합니다

비싼 사고 능력은 Claude Code를 위해 아껴두세요:

• 오케스트레이션 (Orchestration)
• 아키텍처 결정 (Architecture decisions)
• 코드 리뷰 (Code review)
• 비즈니스 로직 (Business logic)
• 판단력이 중요한 모든 것

그 외 모든 것은 오픈 모델 (open models)에서 실행합니다:

• 대량 데이터 보강 (Bulk enrichment)
• 분류 (Classification)
• 스크레이핑 (Scraping)
• 대량 작업 (High-volume work)

이러한 작업에는 프론티어 지능 (frontier intelligence)이 필요하지 않습니다. 처리량 (throughput)이 필요할 뿐입니다. 이러한 작업을 DeepSeek으로 옮기면서, 에이전트가 직접 동일한 탐색을 수행할 수 있게 되어 유료 검색 API를 제거할 수도 있었습니다.

컨텍스트 (Context)는 인프라입니다

저는 프롬프팅 (prompting)이 중요한 부분이라고 생각하는 것을 그만두었습니다. 대부분의 품질은 컨텍스트 (context)에서 나옵니다.

제 비즈니스에 관한 모든 중요한 정보는 리포지토리 (repository) 안에 들어 있습니다:

• CLAUDE.md — 비즈니스 규칙 (Business rules)
• 아키텍처 노트 (Architecture notes)
• 참조 문서 (Reference documentation)

모든 새로운 세션은 이 컨텍스트가 이미 로드된 상태로 시작됩니다. 가볍고 온디맨드 (on-demand) 방식으로 말이죠. 이는 제가 더 이상 제 비즈니스를 반복해서 설명할 필요가 없음을 의미합니다. 저는 새로운 팀원을 온보딩 (onboarding)하는 것과 동일한 방식으로, 핵심 컨텍스트와 그들의 시스템 (CRM, 이메일, 트랜스크립트 등)에 대한 포인터를 제공하며 에이전트를 온보딩합니다.

저의 하루 일과 구성

• GTM 작업 — 리드 소싱 (Lead sourcing), 데이터 보강 (enrichment), ICP 스코어링 (ICP scoring), 아웃바운드 시스템 (outbound systems)

• 클라이언트 소프트웨어 — 소규모 프로덕션 앱 (production apps), 리뷰 마이크로사이트 (review microsites), 내부 도구 (internal tools)

• 내부 툴링 (Internal tooling) — 저만 사용하는 도구들

• 플러밍 (Plumbing) — API, 자동화 (automations), 통합 (integrations)

이는 1년 전 제가 상상했던 AI 지원 개발의 모습과는 매우 다른 워크플로우 (workflow)입니다.

마치며

저는 여전히 제 자신을 소프트웨어 엔지니어 (software engineer)라고 생각하지 않습니다. 하지만 이제는 그것이 핵심이 아니라고 생각합니다.

저에게 가장 흥미로웠던 점은 이것이 저에게 엔지니어링 프로세스 (engineering process)에 접근할 수 있는 기회를 주었다는 것입니다. 전통적인 엔지니어링 배경이 없는 다른 사람들도 이와 유사한 지점으로 수렴하고 있는지 궁금합니다.

여러분은 소프트웨어 엔지니어링 (software engineering)의 어떤 부분들을 빌려왔나요? 대량의 작업 (high-volume work)을 위해 어떤 오픈 모델 (open models)이 여러분의 신뢰를 얻었나요? 제 추측으로는 우리 중 많은 이들이 독립적으로 동일한 운영 체제 (operating system)를 재발명하고 있는 것 같습니다.