6개월간 코드 한 줄도 안 쓰고, 100만 줄 기여하기

안녕하세요, 채널톡 소프트웨어 엔지니어 페리입니다.

저는 지난 6개월간 직접 작성한 코드 0줄로 22개 레포지토리에서 560개 이상의 PR을 머지하고, 약 97만 줄의 코드를 수정했습니다. 동시에 최대 10개의 작업을 병렬로 진행하며, 하루에 10개 이상의 PR을 처리하기도 합니다.

이 글은 약 2개월 전 사내 타운홀에서 발표한 내용을 기반으로, 그 이후의 최신 성과까지 업데이트한 것입니다. 우리 팀의 방식이 정답은 아닐 수 있습니다. 하지만 1인 팀으로 시작해 이런 규모의 산출물을 만들어낸 경험을 공유하는 것에 의미가 있다고 생각합니다.

먼저 결론부터 말씀드리겠습니다. AI의 비결은 AI가 아니라 시스템입니다.

1. 고백

CoreAppStore팀

채널톡에는 외부 연동을 위한 앱스토어라는 기능이 있습니다. 카카오, 라인 같은 메신저부터 카페24, 쇼피파이 같은 커머스, 그리고 GitHub 등 다양한 앱이 채널톡과 상호작용하는 공간입니다. CoreAppStore팀은 앱 설치, 결제, 웹훅, OAuth, MCP 등 이 앱 생태계의 핵심 시스템을 만드는 팀입니다.

저는 2025년 8월 말에 이 팀에 합류했습니다. 약 4개월간 혼자 일했고, 2026년 1월에 리바이가 합류하면서 현재 2인 팀이 되었습니다.

직접 쓴 코드 0줄

지금까지 만든 것들을 나열하면:

• Extensions: 앱스토어의 새로운 확장 시스템

• OAuth + Calendar App: OAuth 기능 구현과 이를 활용한 캘린더 앱 개발

• MCP: MCP를 앱스토어의 앱으로 설치할 수 있는 시스템

• 퍼스트 파티 앱: EasyAdmin, WMS, 캘린들리, 스프레드시트 등 채널톡 자체 앱 개발

• App SDK + App Studio: 외부 개발자를 위한 TypeScript SDK와 앱 빌더 POC

• DDD 리팩토링: God Object 해체, 7개 도메인 + 9개 Saga 패턴 도입

• Go 컨벤션 v2: 3만 줄 이상의 코드 컨벤션 전면 변경

• CI 최적화: Go CI 10분 → 2분, Java CI 36분 → 21분

• 105K 줄 커스텀 아키텍처 테스트 프레임워크

• 지식 그래프 시스템 (Channel Knowledge)

여기서 한 가지 중요한 고백을 드리자면, 이 모든 작업에서 제가 직접 쓴 코드는 0줄입니다. 모든 코드 작업은 LLM이 수행했습니다.

2. 워크플로우 — 하나의 작업이 머지되기까지

그러면 실제로 하나의 작업을 어떻게 진행하는지 보여드리겠습니다.

Step 1. Worktree 생성

먼저 Git worktree를 생성합니다. Worktree는 같은 프로젝트에서 독립된 작업 공간을 만드는 것입니다. 각 작업이 서로 간섭하지 않도록 물리적으로 분리된 디렉토리에서 작업합니다.

Step 2. 한 줄 프롬프트

그 다음, 정말 간단한 한 줄짜리 프롬프트를 던집니다. "이 기능 만들어줘", "이 버그 고쳐줘" 정도의 간단한 지시입니다.

Step 3. AI가 스스로 계획 수립

그러면 AI가 스스로 계획을 세웁니다. 어떤 파일을 수정해야 하는지, 어떤 순서로 작업해야 하는지를 직접 분석하고 계획합니다. 이 과정에서 사람이 전달해주면 굳이 찾아보지 않을 내용까지도 디테일하게 이해하고, LLM의 컨텍스트 윈도우 속에 저장해둡니다.

Step 4. 계획 검토 및 승인

저는 이 계획을 검토합니다. 기존 코드와 일관성이 있는지, 기획 의도에 맞는지를 확인한 후 승인합니다.

Step 5. 의사결정이 필요할 때만 개입

이후 작업 중간에 AI가 의사결정이 필요한 부분을 물어보면, 그때만 개입합니다. "이 부분은 A 방식으로 할까요, B 방식으로 할까요?" 이런 질문에만 답변합니다.

Step 6. 단계별 커밋

AI는 각 단계마다 커밋을 하면서 작업을 수행합니다. 게임에서 세이브 포인트를 찍는 것처럼, 작업 내용을 중간중간 저장합니다.

Step 7. Self-review + 테스트

작업이 완료되면 몇 가지를 추가로 검토하게 시킵니다. 테스트를 돌리거나, 기획과 비교해서 빠진 것이 없는지 확인합니다.

Step 8. PR 생성 → CI → 코드 리뷰 반영

PR을 올린 후 CI가 통과하는지 확인하고, CodeRabbit(AI 리뷰어)의 피드백을 LLM이 직접 읽고 수정 계획을 세워 반영합니다. 이 과정을 CI가 깨끗해질 때까지 반복합니다.

개발자의 역할 변화

이 과정에서 저의 역할은 **"코드 작성자"에서 "의사결정자 + 시스템 설계자"**로 완전히 바뀌었습니다. 코드를 한 줄도 직접 쓰지 않지만, 모든 의사결정은 제가 합니다. 어떤 아키텍처를 선택할지, 어떤 트레이드오프를 감수할지, 기획 의도에 맞는지 — 이런 판단은 여전히 사람의 몫입니다.

3. 병렬 실행 — 동시에 10개 작업

점점 손이 남는다

LLM에게 점점 더 많은 역할을 위임하다 보니, 손이 점점 남기 시작했습니다. AI가 코드를 짜고 있는 동안 저는 할 일이 없었습니다.

그래서 병렬로 돌리기 시작했습니다.

2개에서 10개까지

처음에는 2개로 시작했습니다. 문제가 없길래 3개, 4개로 늘렸고, 현재는 최대 10개의 작업을 동시에 진행합니다. 하루에 최대 10개 이상의 PR을 처리합니다.

많은 분들이 "머릿속에 그 많은 맥락을 다 들고 있을 수 있냐"고 물으십니다. 핵심은 맥락이 제 머리에 있는 것이 아니라 LLM의 컨텍스트 윈도우 안에 있다는 것입니다. 작업 간 전환할 때 기억을 더듬을 필요가 없습니다. 각 AI 에이전트가 해당 작업의 모든 맥락을 이미 갖고 있기 때문에, 컨텍스트 스위칭 비용이 거의 0입니다.

의존성 관리

병렬로 돌리려면 작업들 간의 의존성을 해소하는 것이 중요합니다. A 작업이 끝나야 B 작업을 할 수 있는 상황을 최소화해야 합니다.

한 프로젝트 내에서도 의존성을 명확히 파악해서 순서대로 진행시켜야 하고, 그래도 병렬로 진행 가능한 태스크에는 한계가 있어서 독립적으로 진행 가능한 프로젝트를 여러 개 들고 있습니다.

LLM에게는 작은 워터폴이 애자일보다 낫다

이 과정에서 재미있는 발견이 있었습니다. LLM은 작은 워터폴을 애자일보다 잘합니다.

각 태스크를 줄 때, 명확한 스펙을 먼저 주고 한 번에 구현시키는 것(설계 → 구현 → 테스트)이 반복적으로 피드백하며 점진적으로 만드는 것보다 훨씬 효과적입니다. LLM은 "일단 이것만 해봐, 다음에 고칠게"보다 "전체 그림은 이거고, 여기서부터 여기까지 한 번에 만들어줘"를 받았을 때 더 좋은 코드를 만듭니다.

다만 프로젝트 전체를 완벽하게 설계하고 시작하라는 뜻은 아닙니다. 최소한의 컨벤션만 지키면서 일단 동작하게 만들고, 실제로 그게 잘 작동해서 코드에 남아야 한다면 그때 리팩토링합니다.

리팩토링이 달라졌다

예전에는 리팩토링이 힘든 일이었습니다. 지금은 그냥 다음 프로젝트 하면서 병렬로 돌리는 일 중 하나일 뿐입니다.

"LLM은 새로운 기능만 잘하는 거 아니냐"고 하실 수 있는데, 이 방법들을 적용하면 리팩토링도 정말 잘합니다. ch-app-store에서 3만 줄 이상을 수정하며 Go 컨벤션을 전면 교체한 사례가 있었는데, 이 과정에서 기존 기능들이 모두 에러 없이 정상 작동했습니다. 프로덕션에서 카카오 호출을 포함한 모든 외부 연동이 무사고로 돌아갔습니다. 그리고 이 리팩토링은 OAuth와 캘린더 앱 개발과 동시에 병렬로 진행되었습니다.

4. 시스템이 AI를 제어한다 — AI Native 개발 환경

핵심 메시지: 비결은 AI가 아니라 시스템이다.

이런 일련의 병렬 작업이 가능했던 건, AI가 잘못하려고 해도 이를 막는 제어장치가 있었기 때문입니다.

왜 CLAUDE.md만으로는 부족한가

많은 팀이 CLAUDE.md나 .cursorrules 같은 컨텍스트 파일에 규칙을 적어서 AI에게 전달하려고 합니다. 우리 팀도 처음에는 그랬습니다.

하지만 연구 결과와 우리의 경험 모두 같은 이야기를 합니다.

컨텍스트 파일을 열심히 작성해도 성능은 거의 개선되지 않고, 오히려 비용만 올라갑니다. 왜 그럴까요?

• 자연어의 모호성: "서브도메인 간 import를 지양해주세요"라는 지침은 "절대 하지 마"인지 "가급적이면"인지 AI가 판단할 수 없습니다

• 읽었다고 따르지는 않음: 특히 긴 컨텍스트에서 후반부의 지침은 무시될 확률이 높습니다

• 규칙 충돌: 규칙이 많아지면 서로 모순되는 경우가 생기고, AI는 어느 쪽을 따를지 임의로 결정합니다

CLAUDE.md는 부탁입니다. 시스템은 강제입니다.

결정론적 제어 메커니즘

우리가 구축한 결정론적 제어는 크게 네 가지입니다.

1. CI (지속적 통합): 아키텍처 테스트, 유닛 테스트, 통합 테스트를 CI에서 자동 실행. 위반 시 PR이 머지되지 않음

2. 포매터: 코드 스타일을 자동으로 통일. AI가 어떤 스타일로 작성하든 포매터가 일관되게 변환

3. 린터: "이 코드 이상한데?"를 자동으로 잡아주는 정적 분석 도구

4. 프리커밋 훅: 커밋 전에 자동으로 검사를 수행. 잘못된 코드가 커밋 자체가 되지 않도록 차단

이런 도구들을 통해 LLM이 코드의 어디를 참조해도 항상 일관된 컨벤션을 확인할 수 있도록, 하나의 규칙이 레포 전체에 적용되어 있습니다.

마인드셋 전환: "LLM이 못해" → "시스템을 개선하자"

이런 환경은 한 번에 갖춰지는 것이 아닙니다. 저의 경우 사고 흐름의 전환이 필요했습니다. LLM이 뭔가 실수를 하면, "아 이 작업은 아직 LLM이 못해"가 되면 안 됩니다. 어떻게 해야 다음에 같은 실수를 반복하지 않도록 시스템을 개선할지를 고민해야 합니다.

실수 → 시스템 개선: 실제 사례 5가지

시스템은 어느 날 갑자기 완성된 것이 아닙니다. 모두 실제로 문제를 겪고, "이건 LLM 탓이 아니라 시스템의 부재다"라고 사고를 전환한 순간에서 출발했습니다.

LLM이 제 의도와 다르게 커밋을 하는 것을 보고, "커밋을 막 하지 않게 규칙과 훅을 추가해야지"라고 생각했습니다. 레포에 커밋 규칙과 pre-commit 훅을 달아서 위반을 원천 차단했습니다.

PR을 올릴 때 자꾸 main 브랜치 베이스로 올리고, 제목과 설명도 제대로 작성하지 못하는 것을 보고, Claude Skill을 만들어서 PR 생성 자체를 자동화했습니다. base branch 실수가 0이 되었습니다.

채널톡의 Go 컨벤션은 어떤 로직을 어떤 곳에 위치시키는 규칙이 있는데, 이런 규칙을 프롬프트로 넣어줘도 자꾸 틀렸습니다. 그래서 커스텀 Go AST 정적 분석을 CI에 추가했습니다. 아키텍처 위반이 0개가 되었습니다.

LLM이 매번 코드를 짤 때마다 스타일이 달라지는 문제는 포매터와 프리커밋 훅을 통해 해결했습니다.

기존에 운영 중이던 다른 서비스에 영향을 주는 수정을 하는 것을 보고, 서비스 간 의존성을 그래프로 파악하는 지식 그래프 MCP 서버를 만들어 이를 예방했습니다.

이런 일련의 과정을 통해 시스템을 구축할수록 LLM의 실수가 줄어들고, 사람의 개입이 따라서 줄어들었습니다. 그리고 이 수정들은 모두 원래 프로젝트와 병렬로 진행되었습니다. 시스템 개선 자체도 AI에게 시킨 또 하나의 병렬 작업이었습니다.

5가지 사례 모두 "LLM이 못해"가 아니라 "시스템을 어떻게 바꾸지?"라는 같은 패턴의 질문에서 나왔습니다. 이 질문을 반복할 수 있었던 건 기술적 역량 때문이 아닙니다. 실수를 AI의 한계로 받아들이지 않고 시스템의 부재로 재해석하는 태도, 그리고 그 시스템 개선을 자연스러운 업무 프로세스로 녹이는 문화가 있었기 때문입니다.

이 주제에 대해서는 AI가 규칙을 "알잘딱" 지키는 백엔드 레포 만들기에서 더 깊이 다루고 있습니다.

시스템만으로는 부족하다 — 사람과 문화

여기까지 읽으면 "시스템만 잘 깔면 되는 거 아냐?"라고 생각할 수 있습니다. 하지만 시스템은 필요 조건이지 충분 조건이 아닙니다. 시스템을 깔기 전에 먼저 바뀌어야 하는 것이 있습니다. 사람의 태도와 조직의 문화입니다.

코드에 대한 소유권을 내려놓는 것. "직접 작성한 코드 0줄"이라는 고백이 가능하려면, 먼저 "내가 직접 짠 코드"에 대한 자부심을 내려놓아야 합니다. 많은 엔지니어에게 코드는 자신의 정체성이자 작품입니다. 저도 처음에는 AI가 짠 코드를 제 이름으로 올리는 것에 묘한 거부감이 있었습니다. 하지만 결국 중요한 건 코드를 누가 타이핑했느냐가 아니라, 좋은 아키텍처 결정을 내렸느냐, 시스템이 안정적으로 돌아가느냐입니다. 엔지니어의 가치는 타이핑 속도가 아니라 판단의 질에 있습니다.

실험을 허용하는 조직. 1인 팀이 "코드를 한 줄도 직접 쓰지 않겠다"는 파격적인 방식으로 일할 수 있었던 것은, 채널톡이라는 조직이 그 실험을 허용했기 때문입니다. 결과로 증명하면 되는 환경, 과정보다 임팩트를 보는 문화가 없었다면 이 시도 자체가 불가능했을 것입니다.

열린 리뷰 문화. 제가 다른 팀의 레포에 PR을 올릴 수 있었던 건, 다른 팀이 그 PR을 열린 마음으로 리뷰해줬기 때문입니다. "AI가 짠 코드니까 안 봐도 되겠지"가 아니라, 코드의 품질과 의도를 정당하게 리뷰해주셨습니다. 이런 문화가 없었다면 크로스팀 기여는 불가능했을 것입니다.

결국 AI Native 개발은 시스템 + 사람 + 문화 세 가지가 함께 갖춰져야 작동합니다. 시스템은 AI의 실수를 잡아주고, 사람은 올바른 판단을 내리고, 문화는 새로운 시도를 허용합니다.

5. 시스템 구축 — 실제로 무엇을 했는가

앞서 "시스템을 개선하자"는 마인드셋을 이야기했습니다. 그렇다면 실제로 어떤 작업을 수행했는지, 대표적인 사례들을 소개합니다.

(1) 아키텍처 규칙을 자동화할 수 있는 구조 만들기

섹션 4에서 "Go 컨벤션을 CI에서 정적 분석으로 강제했다"고 했는데, 사실 그 전에 해결해야 할 문제가 있었습니다. ch-app-store의 코드 구조 자체가 God Object — 하나의 패키지가 모든 것을 의존하는 구조였기 때문에, 규칙을 정의할 수조차 없었습니다. "어디에 무엇을 놓아야 하는지"라는 규칙을 만들려면, 먼저 "어디"가 명확하게 나뉘어 있어야 합니다.

그래서 DDD 기반으로 전체 아키텍처를 재설계했습니다. God Object를 7개 독립 도메인과 9개 Saga로 분리하고, 200개 이상의 파일에 걸쳐 있던 cross-import를 정리했습니다. 그 위에 105K 줄의 커스텀 Go AST 아키텍처 테스트 프레임워크를 구축해서, 아키텍처 위반을 CI에서 자동으로 감지하도록 만들었습니다.

구조가 정리되고 규칙이 자동화되니, AI가 리팩토링의 상당 부분을 사람의 개입 없이 자율적으로 수행할 수 있었습니다. 현재 아키텍처 위반은 0개입니다.

상세 내용: AI가 규칙을 "알잘딱" 지키는 백엔드 레포 만들기

(2) AI의 피드백 루프 병목 제거하기

CI는 AI 에이전트의 핵심 피드백 루프입니다. AI가 코드를 수정하고 PR을 올린 뒤 CI 결과를 기다리는 동안, 그 작업의 컨텍스트는 멈춰 있습니다. 10개 작업을 병렬로 돌리면 이 대기 시간이 10배로 누적됩니다. CI가 느리면 전체 시스템의 병목이 됩니다.

ch-app-store의 Go CI는 10분, ch-dropwizard의 Java CI는 36분이 걸리고 있었습니다. 둘 다 1년 넘게 방치된 기술 부채였습니다.

CI 최적화는 "수정 → push → CI 실행 → 시간 측정 → 다시 수정"이라는 반복적이고 지루한 과정입니다. 사람이 하기엔 너무 지루하지만, AI에게는 오히려 적합한 작업입니다. AI가 27회 이상의 반복 실험을 자율 수행해서, Go CI를 10분에서 2분으로(-78%), Java CI를 36분에서 21분으로(-43%) 단축했습니다. 1년간 못 고치던 기술 부채를 이틀 만에 해소한 셈입니다.

CI 최적화에 대한 상세 내용은 조만간 별도 글로 공유할 예정입니다.

(3) 코드베이스 전체의 일관성 확보하기

AI가 코드를 생성할 때, 기존 코드를 참조합니다. 그런데 기존 코드 자체가 일관적이지 않으면, AI도 일관적인 코드를 생산할 수 없습니다. 같은 레포 안에서 파일마다 스타일이 다르면, AI가 어떤 파일을 참조하느냐에 따라 결과가 달라집니다.

채널톡의 새로운 Go 컨벤션 v2가 도입되었을 때, ch-app-store의 기존 코드 3만 줄 이상을 새 컨벤션으로 전면 교체했습니다. AI가 레포의 어디를 참조해도 동일한 패턴을 학습할 수 있도록 하기 위해서입니다. 이 작업은 OAuth와 캘린더 앱 개발과 동시에 병렬로 진행되었고, 프로덕션에서 카카오 호출을 포함한 모든 외부 연동이 무사고로 돌아갔습니다.

(4) 서비스 간 의존성을 AI가 파악할 수 있게 만들기

AI가 하나의 서비스를 수정할 때, 그 수정이 다른 서비스에 어떤 영향을 주는지 파악하지 못하는 문제가 있었습니다. MSA 환경에서 서비스 간 의존성은 코드만 봐서는 알 수 없기 때문입니다.

이를 해결하기 위해 서비스 간 의존성을 그래프로 파악하는 Channel Knowledge 시스템을 구축했습니다. 20개의 MCP 도구를 통해 AI 코딩 도구가 실시간으로 아키텍처 정보를 조회할 수 있게 만들었습니다.

상세 내용: 그래프 RAG를 이용한 채널 지식 시스템 구축기

6. AI Native 레포란 무엇인가

모든 레포가 AI Native해야 하는 이유

지금까지 설명한 성과들은 결국 하나의 전제 위에 서 있습니다. 코드베이스가 AI Native하게 갖춰져 있어야 한다는 것입니다.

AI Native한 레포란 무엇일까요?

• 일관된 컨벤션이 코드 전체에 적용되어 있다

• 명확한 규칙이 테스트와 린터로 강제된다

• 자동화된 검증 시스템(CI, 포매터, 프리커밋)이 갖춰져 있다

• AI가 코드의 어디를 참조해도 동일한 패턴을 확인할 수 있다

핵심 인사이트: AI Native = 좋은 온보딩 환경

여기서 중요한 인사이트가 있습니다. AI Native 레포를 만드는 것은 새로운 팀원이 들어왔을 때 바로 기여할 수 있는 레포를 만드는 것과 지향점이 다르지 않습니다.

일관된 컨벤션, 명확한 규칙, 자동화된 검증. 사람이든 AI든, 새로 합류한 누군가가 빠르게 기여할 수 있는 환경입니다. AI를 위해 특별히 하는 것이 아니라, 좋은 엔지니어링 그 자체입니다.

크로스팀 협업의 변화

이런 환경이 갖춰지면 협업 방식도 달라집니다. 레포가 AI Native할수록 LLM이 해당 코드를 더 잘 파악하기 때문에, 다른 팀의 코드에도 자신 있게 PR을 올릴 수 있습니다. 조직 전체의 레포가 AI Native해지면, 팀 간 경계를 넘는 기여가 자연스러워집니다.

하지만 여기서도 기술만으로는 안 됩니다. 다른 팀의 코드에 PR을 올리는 것은 기술적 역량의 문제이기 이전에 문화적 합의의 문제입니다. "요청하고 기다리는" 기존 방식에서 "먼저 PR을 올리고 리뷰를 받는" 방식으로의 전환은, 기여를 환영하는 팀 문화가 전제되어야 합니다. AI Native 레포는 코드의 문제이고, AI Native 조직은 사람의 문제입니다. 둘 다 필요합니다.

7. 앞으로 — 사람과 시스템을 강화하는 시스템

현재의 한계

현재 저의 워크플로우는 사람 1명 + AI 에이전트 N개입니다. 여러 Claude Code를 띄워놓고 번갈아 가면서 명령하는 것이 제가 하는 일의 대부분입니다.

이 방식에는 명확한 한계가 있습니다.

• 사람의 프롬프트 입력과 의사결정이 병목

• 10개 이상의 작업을 동시에 관리하기 어려움

• 작업 간 조율과 우선순위 판단이 수동

hollon-ai: 사람의 판단을 더 빠르게

이 한계를 돌파하기 위해 만들고 있는 것이 hollon-ai입니다.

"홀론(Holon)"은 "전체이자 부분"이라는 개념입니다. 각 에이전트가 독립적으로 작동하면서도 전체 시스템의 일부로서 협력합니다. 전문화된 에이전트들이 태스크를 분해하고 자율적으로 수행하되, 사람은 채널톡 팀챗이나 웹 UI에서 그 결과를 실시간으로 확인하고 의사결정을 내릴 수 있습니다.

Interface (Web UI / 팀챗 봇 / CLI)    ← 사람이 결과를 확인하고 판단하는 곳
        │
Hollon AI Server (태스크 상태머신)
        │
Orchestrator (태스크 분해 + 분배)
        │
┌───────┼───────┐
│       │       │
Worker  Worker  Worker    ← 역할별 홀론, 격리 컨테이너(K8s)에서 실행
(Go)  (Frontend)(Review)
        │
Knowledge Layer (pgvector + Neo4j + Document)

hollon-ai의 핵심은 사람을 대체하는 것이 아니라, 사람의 역할을 강화하는 것입니다. 멀티 에이전트가 작업을 수행하되, 그 결과물을 사람이 채널톡 안에서, 웹사이트 안에서 빠르게 확인할 수 있습니다. Human-in-the-loop가 약해지는 것이 아니라, 오히려 더 강화된 형태입니다. 사람이 더 많은 작업에 대해 더 빠르게 판단을 내릴 수 있게 됩니다.

이것이 가능한 이유는, 지금까지 구축해온 AI Native 시스템과 문화가 있기 때문입니다. CI가 코드 품질을 보장하고, 아키텍처 테스트가 규칙을 강제하고, 지식 그래프가 의존성을 파악합니다. 이런 제어장치가 갖춰져 있으니, 멀티 에이전트의 자율성을 높여도 결과물의 안정성이 유지됩니다. AI Native한 조직과 시스템이 먼저 갖춰졌기 때문에, 멀티 에이전트 시스템이 훨씬 자연스럽게 도입될 수 있습니다.

실제로 이 시스템을 개발하면서, 시스템 스스로가 자신의 개발을 수행하게 해봤습니다. 복잡한 목표를 던져줬을 때 여러 태스크로 분해하고, 각 태스크를 사람의 개입 없이 멀티 에이전트 시스템을 통해 해결하는 것을 경험했습니다.

hollon-ai는 현재 내부에서 개발 중이며, 이번 분기 중 전사적 도입을 목표로 하고 있습니다. 결국 이것도 같은 패턴입니다. 사람과 시스템을 강화하는 시스템을 구축하는 것. 조만간 별도 글로 상세히 공유할 예정입니다.

8. 맺음말

코드는 commodity가 된다

AI 성능은 계속 좋아지고 있습니다. 코드는 점점 비용을 투입하면 찍어져 나오는 생산품이 되고 있습니다. 그렇다면 우리가 그동안 쌓아온 코드의 가치도 시간이 지날수록 하락할 것입니다.

새로운 경쟁력

앞으로의 경쟁력은 무엇일까요?

• 의사결정 속도: 더 빨리 결정하고 논의하는 능력

• AI와의 소통: AI에게 의도를 정확히 전달하고 결과를 검증하는 능력

• 시스템 구축: AI가 안정적으로 작동할 수 있는 환경을 설계하는 능력

코드를 빠르게 찍어내는 것보다, 이런 시스템을 구축하는 능력이 앞으로의 핵심 경쟁력이 될 것입니다.

엔지니어의 새로운 역할

업무의 병목은 더 이상 AI가 아니라 사람입니다. 사람이 정하는 정책, 기획, 아키텍처 결정이 중요하고, 코드는 점점 더 AI에게 비용을 투입하면 생산되는 것이 됩니다.

엔지니어는 지휘자(conductor)처럼 에이전트를 오케스트레이션하는 역할이 될 것입니다. AI의 병목을 제거하고, 효율적인 자동화 환경을 만드는 사람. 그리고 그런 변화를 받아들이고 실험할 수 있는 태도를 가진 사람. 제가 6개월간 경험한 바는, 가장 좋은 도구를 가진 팀이 이기는 것이 아니라, 좋은 시스템과 좋은 문화를 함께 갖춘 팀이 이긴다는 것입니다.

채널톡에서는 이런 도전적인 문제들 — AI와 함께 하는 새로운 개발 방식, 대규모 백엔드 리팩토링, 멀티 에이전트 자동화 시스템 구축 — 을 함께 풀어갈 엔지니어를 찾고 있습니다. 관심 있으신 분은 언제든 채널톡의 문을 두드려 주세요.