소프트웨어 엔지니어링이 양봉이 되어가고 있다

게시일: 2025년 12월 30일 | 원문 작성일: 2025년 12월 29일 | 저자: joe (Bits of Logic) | 원문 보기

• • •

양봉이란 무슨 의미인가

12개의 AI 코딩 에이전트를 병렬로 돌리고 있으면, 소프트웨어 엔지니어보다 양봉가가 된 기분이 들어요.

2025년 초만 해도 AI 코딩 보조는 그냥 좀 강력한 자동완성이었어요. 탭탭탭 누르면서 제안을 받아들이고, Copilot이 문장을 완성해주고, 테스트 작성을 좀 도와주고. 그래도 코드를 쓰는 건 결국 나였죠.

2025년 말이 되니, 오후 내내 걸릴 일이 Claude한테 한 번 시키면 끝나요. 너무 간단하고, 결과물에 대한 신뢰도 쌓여서, 요즘은 항상 여러 작업을 동시에 진행해요.

양봉가는 수천 마리의 벌이 여러 벌통에서 일하는 걸 관리해요. 벌들은 꽃가루를 모으고, 다른 꽃을 수분하고, 꿀을 만들죠. 지금 이 순간 각 벌이 뭘 하는지 알고 있나요? 아니요. 신경 쓰나요? 별로요. 결국 꿀이 나오면 되는 거예요. 그게 중요한 거죠.

하지만 손 놓고 있는 건 아니에요. 벌들의 서식지를 관리하고 안전하게 유지해요. 벌들이 벌집을 짓는 구조물을 제공하죠. 프레임, 상자, 성공을 위한 조건들. 양봉가는 그냥 벌떼가 있는 들판에서 밤에 몰래 꿀을 훔쳐가는 사람이 아니에요. 양봉가는 꿀이 만들어질 수 있는 환경을 구축하는 사람이에요.

그리고 벌은 쏠 수도 있어요. 제대로 된 장비와 방법 없이는 다쳐요. 보호복, 연기 뿜는 도구, 신중한 움직임. 코드에서는 패턴, 문서, 테스트가 그 역할을 해요. 쏘임을 최소화하는 안전장치들이죠.

지금 소프트웨어 엔지니어가 된 기분이 딱 이래요.

변화의 핵심

수년간, 엔지니어의 가치는 컨텍스트를 머릿속에 갖고 있는 것과 많이 연결되어 있었어요. 시스템을 완벽하게 이해해서 살아있는 문서 같은 존재가 되는 거죠. 그 이상한 엣지 케이스가 어느 파일에 있는지 정확히 알고, 3개월 전에 왜 그런 트레이드오프를 했는지 기억하고. 그런 깊은 지식이 초능력이었어요.

Claude Code1나 Droid2(그리고 수많은 다른 도구들) 같은 도구가 생기면서, 그 컨텍스트가 더 이상 머릿속에 있을 필요가 없어졌어요. 문서에 담기면 돼요. 그리고 그 연장선으로, LLM에도 담기는 거죠.

컨텍스트를 오프로드하면, 자신의 주의력을 확장할 자유가 생겨요. 미쳐버리지 않고 여러 기능을 병렬로 작업할 수 있어요. 단일 장애점이 되는 걸 멈추고 양봉가가 되기 시작하는 거예요.

문서가 하중을 견디게 되다

제가 일했던 대부분의 회사에서, 문서와 테스트는 이론상으로만 중요했어요. 네, 아름답고 의미 있는 문서가 있으면 좋겠죠. 포괄적인 테스트 커버리지가 있으면 좋겠죠. 근데 시간도 없고, 인센티브도 없었어요. 어떤 장애가 더 나은 테스트 커버리지의 필요성을 드러내기도 했지만, 당장 문제를 고치고 다음 기능을 배포하는 게 항상 이겼죠.

이제 유용한 문서와 광범위한 코드 커버리지가 AI 에이전트의 결과물을 직접적으로 개선해요. 자동화된 테스트가 많을수록 수동 테스트는 줄어들고, 피드백 루프가 빨라져요: 더 나은 문서 작성 → 테스트 자동화 → 더 나은 코드 → 더 빠른 배포. 드디어 인센티브와 열망이 일치하게 됐어요.

2025년 초에 우리 코드베이스에는 README 하나뿐이었어요. 지금은 에이전트가 작업에 따라 참고하는 종합적인 행동 문서 세트가 있어요.

이건 이제 인간과 에이전트 모두를 위한 문서예요. 벌들이 벌집을 짓는 프레임이죠. 우리는 거대한 모놀리식 컨텍스트를 집중된 문서들로 쪼갰어요: 테스팅 패턴, 디자인 토큰, 컴포넌트 컨벤션, 아키텍처 가이드라인. 각각이 벌집 구조의 한 조각이에요.

실제로 하루가 어떻게 흘러가나

Linear3 티켓으로 된 몇 가지 기능으로 시작해요. 약간 모호할 수도 있어요:

• 사용자로서, Logic Doc에 CSV를 업로드하면 문서의 에이전트가 행마다 한 번씩 실행되길 원해요
• 사용자로서, 에이전트 실행 시 예상치 못한 출력을 일으킬 수 있는 잠재적 오류와 경고를 봐야 해요
• 사용자로서, 애플리케이션 어디서든 새 Logic Doc을 만들고 싶어요

각 기능마다 git worktree4를 만들어요. 그리고 Claude와 함께 /prd5 명령을 실행해요:

에이전트가 한 번에 하나씩 질문하고, 코드베이스 지식과 웹 검색으로 빈칸을 채워요. 이 과정에서 각 기능의 여러 UX 컨셉과 그 컨셉들의 다양한 UI 구현을 스펙으로 만들어요.

여러 디자인 방향이 담긴 PRD가 나오면, 각 git worktree에서 Droid를 띄워서 각각 구현하게 해요. 각 컨셉은 앱 컨텍스트 내의 다른 라우트로 빌드돼서, 브라우저에서 실제 데이터로 각 디자인을 바로 테스트할 수 있어요.

한 시간도 안 돼서, 여러 개의 완전히 작동하는 기능이 나와요. 각각 평가할 수 있는 여러 디자인 컨셉과 함께. 목업도 아니고 프로토타입도 아니에요. 클릭해서 돌아다닐 수 있는 진짜 작동하는 코드예요.

10개 만들어서 버리기

옛날 조언 기억나요? “하나는 버릴 계획을 세워라. 어차피 버리게 될 테니.” 뭘 모르는지 배우려고 일단 한 번 만들어보고, 그다음에 제대로 만드는 거죠. 이제 그 조언을 확장할 수 있어요.

코드 생산 비용이 이렇게 낮아지면, 10개를 만들어서 버릴 수 있어요. 3개 기능에 걸쳐서. 병렬로! 문제의 핵심에 더 빨리 도달하고, 다양한 각도에서 보고, 마찰을 찾을 수 있어요. 저비용 생산이 품질을 찾기 위한 대량 반복을 가능하게 해줘요.

각 컨셉을 테스트한 후, /design-review 명령을 실행해요:

구조화된 대화를 통해 각 접근법의 장점을 모아 최종 디자인으로 만들어요. 검증을 위해 다시 /prd. 진짜 버전을 만들러 다시 Droid로. 팀 피드백, 반복, 다듬기, 배포.

지금 내가 실제로 하는 일

내 일이 바뀌었어요. 코드 쓰는 시간은 줄고 이런 일에 더 많은 시간을 써요:

• 벌집 유지 — CLAUDE.md와 집중된 문서들을 정확하고 유용하게 유지하기
• 새 프레임 만들기 — 에이전트가 따를 수 있는 패턴과 컨벤션 만들기
• 꿀 평가하기 — 병렬 탐색 결과를 검토하고 뭐가 되는지 찾기
• 좋은 질문하기 — /prd와 /design-review 워크플로우는 결국 좋은 답에 수렴하기 위한 올바른 질문을 하는 것

깊은 지식이 이제 인코딩돼 있어요. 선택적으로 느껴졌지만 이제는 모든 코드가 그 위에 쓰이는 인프라가 된 문서 속에.

코드는 여전히 중요해요. 사용자가 상호작용하는 게 코드니까요. 하지만 더 상품화됐어요. 코드를 어떻게 쓰는가의 가치가 상류로 이동했어요: 문서, 패턴, 아키텍처, 무엇을 왜 만들지에 대한 결정들. 에이전트가 만들어내는 것을 형성하는 것들이죠.

바로 지금

흥미롭고 긴장되는 건, 다음 주에 새 모델이 나오면 이 전체 워크플로우가 구식이 되거나 적어도 크게 바뀔 수 있다는 거예요.

이렇게 일하는 건 신나요. 뭔가 놀이 같은 느낌이 있어요. 커밋 안 하고 이것저것 시도해볼 수 있어요. 매몰 비용 걱정 없이 탐색할 수 있어요. 모든 컨텍스트를 머릿속에 담고 있지 않아도 되니까 세 가지 기능을 동시에 작업할 수 있어요.

벌들이 꿀을 만들고 있어요. 우리는 벌집을 건강하게 유지하는 거예요.

• • •