Composer 1.5, Cloud Agent, 자율 코드베이스로 가는 길 (2026 가이드)
2026년에 소프트웨어를 만드는 사람이라면, 요즘 변화가 몸으로 먼저 와닿을 거예요.
코드를 “작성하는 일” 자체가 병목이던 시대는 빠르게 지나가고 있습니다. 이제 진짜 병목은 코드 바깥에 있어요. 어디를 고쳐야 하는지 찾고, 변경이 맞는지 검증하고, 안전하게 배포하고, 그걸 지치지 않고 반복하는 것—바로 그 전 과정이죠.
Composer 1.5는 이 전환기의 한가운데를 겨냥합니다. 단순히 코드를 더 잘 뱉는 모델이 아니라, 실제 개발 업무(작성·수정·탐색·도구 활용)를 끝까지 밀어붙이도록 설계된 에이전틱(agentic) 코딩 모델 계열이에요. 성능 포지션은 Sonnet 4.5와 Opus 4.5 사이로 언급되고, 학습 방식은 대규모 RL(강화학습) 비중이 매우 높은 것으로 묘사됩니다.
하지만 더 중요한 건 “모델 이름”이 아닙니다. 이 접근이 보여주는 방향성이에요.
- 왜 “빠르고 손에 착 감기는 속도”가 모델의 핵심 기능이 되는지
- 왜 도구 사용은 붙이는 게 아니라 훈련으로 내장되어야 하는지
- 왜 Cloud Agent가 아직은 로컬보다 불편하고, 무엇이 바뀌어야 판이 뒤집히는지
- 왜 테스트가 진짜 승부처이고, DevX가 숨은 병목이 되는지
- 긴 작업을 컨텍스트 한계 밖으로 밀어내는 Self-summarization과 “참조형 기억” 전략
- Capability jump가 무엇이고, 다음 점프가 Git/GitHub와 엔지니어 역할을 어떻게 바꾸는지
“에이전틱”이 뭔데요? 그냥 더 똑똑한 코딩 챗봇 아닌가요?
많은 AI 코딩 도구는 출발점이 자동완성이었죠. 다음 줄을 예측하고, 가끔은 함수 단위로 제안해 주는 형태요. 유용합니다. 하지만 기본적으로 반응형이에요.
에이전틱 모델은 결이 달라요. “키보드”가 아니라 “일꾼”에 가깝습니다.
비유로 정리하면 이렇습니다.
- 자동완성은 똑똑한 키보드
- 에이전트는 주니어 개발자 같은 존재
- 코드베이스에서 검색하고
- 파일을 열고
- 계획을 세우고
- 변경을 만들고
- 체크를 돌리고
- 실패하면 고치고
- 끝날 때까지 반복합니다
Composer 1.5가 노리는 지점은 딱 여기예요. “답변”이 아니라 업무 흐름 자체를 실행하는 것. 특히 semantic search, grep 스타일 텍스트 검색 같은 도구를 언제, 어떻게 써야 일이 끝나는지를 몸으로 익힌 모델에 가깝습니다.
한 줄 요약(공유용): AI 코딩의 미래는 “코드 생성”이 아니라 “업무 완주”다.
Composer 1.5가 찍은 방향: 속도가 곧 개발 경험이다
재미있는 변화가 하나 있어요.
이제 속도는 “있으면 좋은 옵션”이 아니라 제품 품질 그 자체로 올라왔습니다.
목표는 “프롬프트 던져놓고 한참 뒤에 확인”하는 모델이 아니에요. Enter 치고 나서 잠깐 딴짓하러 가는 흐름이 아니라, 반응이 빠르고 몰입이 이어지는 흐름을 만드는 쪽입니다.
왜냐고요?
- 개발은 반복 작업입니다
한 번 크게 요청해서 끝나는 게 아니라, 작은 질문과 작은 수정이 30번 이어져요. 모델이 조금만 빨라져도 체감은 “몇 초 단축”이 아니라 리듬 유지로 바뀝니다. - 빠른 피드백은 행동을 바꿉니다
응답이 빠르면 더 자주 확인하고, 더 자주 검증하고, 더 실험적으로 움직이게 돼요. 결국 워크플로가 보수적이기보다 탐색적으로 변하죠.
Composer 1.5는 “가능한 한 빨리 처리한다”를 설계 목표로 둡니다. 이건 사소한 취향이 아니라, 개발 경험을 짧은 피드백 루프로 재정의하겠다는 선언에 가깝습니다.
“도구 사용”은 붙여서 되는 게 아니다: 훈련으로 몸에 박아야 한다
현장에서 자주 터지는 진실이 하나 있습니다.
모델 내부에 박혀 있지 않은 능력은, 밖에서 붙여도 제대로 안 씁니다.
도구를 연결해 주는 건 시작일 뿐이에요. 모델이 진짜로 잘 쓰려면:
- 언제 써야 하는지 판단하고
- 어떻게 호출하는지 알고
- 결과를 정확히 해석하고
- 다음 단계에 자연스럽게 반영해야 합니다
예전에는 grep 같은 기본적인 검색 도구조차도 “연결은 했는데 활용이 어설픈” 시기가 있었죠. 단순히 도구를 제공하는 것과, 그 도구를 써서 업무를 끝내는 것은 완전히 다릅니다.
대규모 코드베이스에서 semantic search가 왜 중요한가
Composer 계열의 강조점 중 하나가 semantic search입니다. 큰 레포에서는 특히 강해져요.
핵심은 “검색이 된다”가 아니라 “검색을 잘 고른다”예요.
- 약한 흐름: 검색을 수십 번 때려서 겨우 맥락을 따라감
- 강한 흐름: 1~2번의 질의로 방향을 잡고 정확히 들어감
엔터프라이즈 코드베이스에서 이 차이는 크기가 아니라 세계관 차이입니다.
“길 잃음”에서 “정확히 찌름”으로 바뀌거든요.
그리고 이런 습관은 프롬프트로 지시한다고 일관되게 나오기 어렵습니다. 반대로 RL은 “그 행동이 결국 일을 끝냈는가”로 보상하기 때문에, 도구 활용이 행동 패턴으로 고정되기 쉬워요.
recursive sub-agents: 2~3분 내로 끝내기 위한 구조
또 하나의 목표는 recursive sub-agents(재귀적 서브 에이전트) 입니다. 일을 쪼개서 여러 하위 작업을 병렬/연쇄로 굴리는 방식이죠.
그 결과로 “대부분의 질의를 2~3분 안에 해결한다”는 수준까지 지향합니다.
즉, 이건 “응답이 똑똑하다”가 아니라 시스템이 일을 굴리는 방식이 바뀐다는 의미입니다.
왜 굳이 자체 모델을 만들까? 최신 프런티어 모델 붙이면 되지 않나
2026년이면 이런 질문이 자연스럽죠.
“그냥 제일 좋은 모델 API 붙이면 되는 거 아닌가요?”
그런데 제품과 모델이 깊게 결합될수록, 답은 점점 “아니다” 쪽으로 기웁니다. 이유는 단순합니다.
필요한 기능이 모델 행동으로 내장되어야 하기 때문이에요.
- 도구를 얼마나 잘 쓰는지
- 대형 레포에서 어떻게 길을 찾는지
- 에이전트가 얼마나 오래 안정적으로 일하는지
- 긴 작업에서 기억을 어떻게 관리하는지
- 검증을 어떻게 수행하는지
이런 것들은 래퍼나 프롬프트만으로는 한계가 있고, 결국 RL로 “행동 양식”을 만들어야 한다는 주장으로 연결됩니다.
RL이 어려운 진짜 이유: 알고리즘이 아니라 인프라다
RL은 비교적 새로운 축으로 다뤄지고, 세부 알고리즘은 공개하기 어렵다는 전제가 깔립니다. 대신 진짜 난이도는 다른 데 있어요.
인프라.
대규모 RL을 하려면:
- 수백만 개 샌드박스를 동시에 돌릴 수 있고
- 수십만~수백만 환경을 오케스트레이션해야 하고
- 규모가 커지면 연간 1억(100 million)+ CPU compute 같은 숫자가 나옵니다
이 정도가 되면 “클라우드 제공자에 맡기고 우리는 앱만 만든다”는 지난 10~20년의 분업 공식이 깨집니다. 필요한 오케스트레이션을 남에게 사오는 게 아니라, 직접 설계해야 하는 영역이 됩니다.
한 줄 요약(공유용): RL은 학습 기법이 아니라, 어느 순간부터는 인프라 기업이 된다.
모델 선택과 Routing: 꿈은 단 하나의 입력창, 현실은 아직 선호 싸움
이상적인 세계는 명확합니다.
- 쉬운 요청은 빠른 모델이 처리
- 매우 어려운 요청은 똑똑한 모델이 처리
- 사용자는 모델 선택을 신경 쓰지 않음
검색 엔진처럼요. Google 쓸 때 “빠른 인덱스/느린 인덱스/중간 인덱스 중 뭐 쓰지?” 고민하지 않잖아요. 그냥 검색하죠.
그런데 지금 Routing이 왜 애매한가
현실에서 Routing은 종종 불투명하고, 그 불투명성이 사용자 혼란으로 이어집니다.
응답이 왜 느린지, 왜 갑자기 행동이 달라졌는지 이해가 안 되면 신뢰가 깨져요.
그래서 실무에서는:
- Routing을 최소화하고
- 무엇을 하는지 투명하게 보이게 하려는 방향이 강조됩니다
결국 지금은 “취향”이 꽤 큰 변수다
흥미로운 지점은, 같은 팀 안에서도 선호가 갈릴 수 있다는 거예요.
- Composer 계열을 쓰는 사람
- Opus 계열을 쓰는 사람
- Codex 계열을 쓰는 사람
그리고 완벽한 논리로 설명하기 어렵다는 솔직한 인정이 붙습니다.
다만 경향성으로는:
- Opus를 선호하는 쪽: 계획과 사고 과정을 모델과 더 많이 대화하며 다듬는 스타일
- Codex를 선호하는 쪽: “한 번에 해봐(one try)”에 가까운 실행 스타일
Cloud Agent: 다음 capability jump—단, 한 가지를 해결해야 한다
여기서 중요한 개념이 나옵니다.
사용자가 체감하는 큰 변화는 모델만 좋아져서가 아니라, 제품+모델이 결합되면서 생기는 단계적 도약(capability jump) 으로 온다는 것.
예로 언급되는 장면들:
- 큰 모델 세대 변화(“Opus 모먼트” 같은)
- 제품 경험 변화(초기 Cursor가 Copilot 위에서 만든 점프처럼)
다음 점프 후보가 Cloud Agent로 지목됩니다. 노트북 들고 다니지 않아도, 로컬 환경에 매이지 않아도 되는 형태죠.
그런데 왜 지금 Cloud Agent는 로컬보다 별로일까
현 시점에서는 Cloud Agent가 로컬보다 체감이 열세일 수 있습니다.
- 부팅이 느리고
- 설정이 오래 걸리고
- 파일 변경 파악이 어렵고
- 전반적인 사용성이 떨어지는 경우가 많아요
로컬 에이전트는 반대로:
- 빠르고
- 반응이 좋고
- 대다수 일을 “약 5분” 안에 처리하는 감각을 줍니다
Cloud의 장점은 “컴퓨터를 닫아도 돌아간다”인데, 데스크에서 일할 때는 사실 컴퓨터를 자주 닫지 않죠. 그러니 장점이 불편을 상쇄 못 합니다.
“천 줄 diff” 문제: 진짜 UX 붕괴 지점
Cloud Agent의 가장 본질적인 문제는 이 장면이에요.
프롬프트를 던져 놓고 돌아왔더니 천 줄 diff가 생겨 있다.
그런데 그게 mergeable인지, 맞는지, 안전한지 당신이 판단해야 한다.
이 구조는 이상합니다. 모델이 코드를 썼다면, 모델이 맞음을 증명할 책임도 같이 져야 해요.
그래서 전환점으로 제시되는 것이:
- 모델이 자신의 코드를 테스트하고
- “올바르게 끝났다”를 증명할 수 있을 때
- Cloud Agent 사용이 10배 단위로 증가할 수 있다
이건 UI 개선이 아니라, 제품 구조의 단계 변화입니다.
1%에서 90%로: Cloud Agent가 지배하려면 “스텝 체인지”가 필요하다
또 하나의 강력한 비유가 나옵니다.
- 지금 Cloud Agent가 쓰는 compute 비중이 대략 1%
- 미래에 Cloud Agent가 지배한다면 90% 같은 그림
1% → 90%는 감이 오시죠?
대략 1000배 성장이 필요합니다.
그런데 1000배는 버튼 위치 바꾼다고 나오지 않습니다.
작은 개선은 작은 개선일 뿐이에요.
그래서 “천 배 성장”을 만들 수 있는 후보로 자동 테스트·검증이 다시 강조됩니다.
한 줄 요약(공유용): Cloud Agent가 이기려면 “더 편한 UI”가 아니라 “검증까지 끝내는 책임”이 필요하다.
테스트가 왜 이렇게 어렵나: DevX가 숨은 병목이다
테스트 자동화라고 하면 보통 “테스트 커맨드 돌리면 되지”라고 생각하기 쉽습니다.
그런데 Cloud Agent에서의 테스트는 더 까다롭습니다.
모델이 코드를 제대로 테스트하려면 사람처럼 앱을 써야 하는 경우가 많아요.
- 서비스 여러 개 띄우고
- 의존성 맞추고
- 로그인/화면 이동을 하고
- “정상 동작”을 눈으로 확인하는 흐름까지 필요하죠
인간 DevX 팀이 있는 이유
많은 조직에는 DevX 팀이 있습니다.
- 신규 입사자가 바로 레포를 띄울 수 있게 만들고
- 온보딩을 부드럽게 하고
- “정답 경로”를 정리해 주는 역할이죠
오픈소스도 마찬가지예요. 시작하기 어렵게 만들면 아무도 안 씁니다.
문제는… 모델은 항의하지 않는다
현실엔 암묵지가 숨어 있습니다.
예를 들어:
- 첫날 서비스 B를 서비스 A보다 먼저 띄우면 전부 터진다
- 옆자리에게 물으면 “A 먼저 켜” 한마디로 해결된다
- 그리고 인간은 그걸 기억하고 다음부터 안 터진다
인간은 질문과 소통으로 복구합니다.
하지만 모델은 DevX가 망가져도 소리 없이 성능만 떨어집니다.
빨간 경고창도 없고, “DevX 좀 고쳐라”는 항의도 없어요.
그냥 결과가 애매해지고, Cloud Agent가 “별로”처럼 느껴지죠.
그래서 앞으로는:
- 모델에게 레포 사용법을 명확히 알려주고
- 서비스 부팅 순서, 정상 상태, 클릭 동선까지 문서화하는
모델 친화형 DevX가 훨씬 중요해질 수 있습니다.
서비스가 많고 복잡할수록 더더욱요.
Cloud Agent 인프라 운영이 왜 힘든가: 긴 실행이 기존 상식을 부순다
지난 10~20년 인프라는 보통 이런 전제를 가졌습니다.
- RPC는 100ms ~ 1~2초 안에 끝난다
- P50/P90 같은 지표로 건강 상태를 본다
- 입력과 출력이 명확해 관측성이 좋다
그런데 에이전트는요?
- 몇 분
- 몇 시간
- 심지어 며칠
실행 시간이 이렇게 넓게 퍼지면 분산이 너무 커져서,
“시스템이 느려진 건지” “그냥 일이 어려운 건지” 구분이 힘들어집니다.
12시간짜리 에이전트가 돌고 있는데 배포는 어떻게 하죠?
질문은 단순하지만 파괴력이 큽니다.
- 12시간 동안 실행 중인 에이전트가 있다
- 지금 서버를 교체해야 한다
- 그럼 중간 상태를 어떻게 옮기지?
이 지점에서 장기 실행 워크로드는 배포 전략과 클라이언트-서버 추상화 자체를 흔듭니다.
두 갈래의 아키텍처: 단일 바이너리 vs 워크플로 엔진
현실적으로 “그럴듯한” 두 모델이 제시됩니다.
1) 단일 바이너리 로컬 모델(Cloud Code 스타일)
클라이언트-서버 구분이 거의 없고, 로컬에서 단일 바이너리로 돈다고 생각하면 됩니다.
- 장점: 단순하다
- 단점: 작업을 외부로 분산하기 어렵고, 머신이 죽으면 신뢰성이 취약하다
2) 워크플로 엔진 기반(Temporal / Restate)
긴 작업을 안정적으로 돌리려면 워크플로 엔진이 유력한 대안이 됩니다.
- Temporal: Uber에서 출발한 워크플로 엔진으로, 매우 긴 작업을 신뢰성 있게 운영하도록 설계됨
- 중간 단계가 죽어도 다시 띄워 이어갈 수 있다는 특성이 언급됩니다
- Restate: 유사한 범주의 솔루션으로 함께 거론됨
에이전트가 중요해질수록 이런 “장기 워크로드용 신뢰성 플랫폼”이 더 늘어날 가능성이 큽니다.
에이전트를 몇 시간~며칠 돌리는 법: 핵심은 “정오 판별”이다
의외로 긴 실행 자체는 점점 자연스러워진다고 묘사됩니다.
조건만 맞으면 모델은 오래 달리는 걸 싫어하지 않아요.
조건은 두 가지입니다.
- 과제가 충분히 어렵고
- 정답/오답을 가르는 기준이 명확하다
즉, 검증이 가능하면 반복이 가능해지고, 반복이 가능하면 장시간 실행이 성립합니다.
“브라우저를 만들어라”: 3일 연속, 3,000~4,000 Commit
장기 실행 사례로 “브라우저 구축” 목표가 제시됩니다.
- 약 3일 연속 작업
- 3,000~4,000 Commit 규모의 진전
중요한 뉘앙스도 있어요. 이건 모델 혼자서 만든 결과가 아니라, 모델+하니스(harness) 의 결합 결과로 설명됩니다.
즉, 긴 작업을 성립시키는 건 모델만이 아니라 “작업을 굴리는 시스템”이에요.
컨텍스트는 한계가 있다: 그래서 기억은 “스킬”이 된다
컨텍스트 윈도우는 여전히 제한이 있습니다. 예로 200k, 혹은 1M 수준이 언급됩니다.
그런데 며칠짜리 작업을 하려면 “기억”이 필요하죠.
Self-summarization: 미래의 나에게 남기는 작업 노트
해법 중 하나가 Self-summarization입니다.
컨텍스트 한계에 닿으면 모델이 스스로 요약/문서화를 만들어
“미래의 자신”이 그걸 읽고 이어서 일하도록 만드는 방식이에요.
예전에도 프롬프트로 요약을 시킬 수는 있었죠.
하지만 문제는 인센티브입니다.
- 프롬프트에 “미래의 나에게 진짜 도움이 되는 요약을 써라”라는 보상 구조가 없다
- 그래서 요약이 그럴듯해도, 다음 단계 진행에 딱 맞게 쓰이진 않는다
도구 사용과 같은 문제예요. “grep 하라”는 지시와 “grep 결과를 다음 작업에 쓰기 좋은 형태로 만든다”는 건 다릅니다.
RL로 긴 작업을 학습시키면, 요약은 최적화 스택의 일부가 되어
다음 단계에 실제로 도움이 되는 요약을 쓰도록 압력이 걸린다고 설명됩니다.
또한 이런 Self-summarization이 엔드포인트/기능 형태로 제공될 가능성도 함께 언급됩니다(여러 플랫폼에서 비슷한 방향이 나올 수 있다는 뉘앙스 포함).
“요약은 손실이잖아요?” — 맞지만, 생각보다 치명적이지 않다
요약은 lossy(손실)입니다. 이건 사실이에요.
다만 반론은 이렇습니다.
- 인간도 손실적으로 기억한다
- 그런데도 살아간다
- 중요한 것 중심으로 남기도록 강제되는 메커니즘이 있기 때문이다
- 모든 걸 기억하면 오히려 지옥이다
뇌에서 정확히 무슨 일이 일어나는지는 모른다는 전제를 깔면서도, “중요도 기반 기억”이 가능하다는 관점이 제시됩니다.
더 강한 아이디어: 요약 + 전체 히스토리 파일 덤프 + 필요할 때 가져오기
또 다른 보완 전략이 나옵니다.
- 요약/압축을 할 때마다
- 이전 대화/작업 기록 전체를 파일로 저장해 두고
- 모델이 필요할 때 그 파일을 “가져와” 과거 상태를 조회하게 한다
이렇게 하면 컨텍스트에 다 넣지 않아도, 참조로 연결할 수 있어요.
그리고 RL은 모델이 이 참조를 효율적으로 가져오는 습관을 학습하게 만들 수 있습니다.
가장 강력한 형태는 개인의 트릭이 아니라, 하니스가 이 습관을 “제대로 쓰도록” RL로 훈련될 때 나타날 수 있다는 뉘앙스까지 포함됩니다.
한 줄 요약(공유용): 긴 에이전트 작업에서 기억의 답은 “더 큰 컨텍스트”가 아니라 “좋은 요약 + 좋은 검색/참조 습관”이다.
앞으로 12개월: “코딩이 풀렸다”는 말이 엔지니어링의 끝은 아니다
짧은 기간에 개발 관행이 확 바뀌었다는 관찰이 제시됩니다.
- 3~4월엔 손코딩이 흔했고
- 12월엔 손코딩이 급격히 줄었다
- 그래서 “코딩이 6개월 만에 풀린 것 같다”는 느낌이 든다
이건 자극적 선언이라기보다, “세상이 이렇게 바뀌고 있다”는 건조한 사실에 가깝다고 표현됩니다.
하지만 중요한 문장이 붙습니다.
- 엔지니어링이 끝난 게 아니다
- 엔지니어가 사라지는 게 아니다
- 다만 엔지니어링의 실천 방식이 바뀐다
그리고 “최상위 엔지니어일수록 손으로 코드를 거의 안 쓴다”는 관찰도 함께 제시됩니다.
반기마다 1~2번 capability jump가 반복될 수 있다
향후 전망으로는:
- 앞으로도 워크플로는 계속 변하고
- 반기마다 1~2번의 capability jump가 있을 수 있으며
- 그 다음 반기에도 또 반복될 수 있다
capability jump의 예시로는 “Opus 모먼트”가 언급됩니다.
- 모델이 코드를 쓸 수는 있는데, 줄마다 다 봐야 했던 상태 →
- 대체로 모델이 맞게 했다고 신뢰할 수 있는 상태
이 점프가 반복되면, 워크플로는 계속 적응할 수밖에 없습니다.
Cloud Agent가 터지면, 엔지니어는 “관리자”에 가까워진다
Cloud Agent가 충분히 좋아지면—특히 테스트와 검증이 모델 책임으로 넘어가면—사람의 역할은 관리자(manager) 쪽으로 기울 수 있다고 전망합니다.
여기서 말하는 관리자는 사람 관리가 아닙니다. 시스템 관리에 가깝죠.
- 목표를 잘 정의하고
- 제약을 걸고
- 자원을 배분하고
- 결과를 검토하고
- “완료”의 기준을 세우는 역할
이 과정에서 개인 기여자(IC)에게는 약할 수 있는 “매니저 감각”이 점점 단련될 수 있다는 관점이 포함됩니다.
“자율 코드베이스(self-driving codebase)” 시나리오: 예산으로 자동 유지보수하기
가장 도발적인 아이디어 중 하나가 자율 코드베이스입니다.
가정은 이렇습니다.
- 코드베이스에 하루 $100,000를 배정해 자동 개선을 수행한다
- 연간 약 $30 million 수준인데, R&D 대비 아주 크지 않을 수 있다
그리고 예산을 기능별로 배분합니다.
- 보안: 7%
- 기술 부채 정리: 12%
- 버그 탐지·수정: 25%
- 백로그 이슈 처리: 50%
- 그 외: 코드베이스가 상당 부분 스스로 관리되는 상태
이 세계에서 GitHub가 어떻게 바뀔지, Git 인프라가 어떤 모습일지는 확실치 않습니다.
다만 기술의 추진력이 사람들을 그 방향으로 밀고 갈 수 있으며, 그 결과물이 어떤 제품 형태가 될지 기대가 제시됩니다.
브라우저 빌드가 던진 충격: “조금 빠른 인간”이라는 멘탈 모델이 깨진다
에이전트를 “내가 하는 일을 조금 더 빨리 하는 존재”로 상상하는 경우가 많습니다.
RPC를 연결하고, 자동화된 호출을 좀 더 빠르게 하는 정도로요.
그런데 브라우저 빌드 같은 과제는 그 상상을 깨뜨립니다.
브라우저를 “정말 기능적으로” 만들려면:
- HTML 처리
- CSS 파싱
- 레이아웃 규칙
- 아키텍처 설계
- 렌더링 엔진으로 전달되는 구조
이 모든 걸 한꺼번에 해결해야 합니다. 숙련된 엔지니어에게도 쉽지 않죠.
그래서 에이전트 시스템이 이런 과제에서 의미 있는 진전을 만드는 모습은 “상식 밖”으로 느껴질 정도의 질적 변화로 묘사됩니다.
다만 하니스는 아직 실험 단계라는 점도 분명히 합니다.
Flat 조직, Hierarchical 조직 등 다양한 구조를 시도 중이고, 무엇이 정착할지는 확정되지 않았다는 뉘앙스가 포함됩니다.
그럼에도 방향성 하나는 명확합니다.
모델이 충분히 좋아지면, 사람이 리뷰 때문에 발목을 잡는 구조가 오히려 비효율적인 블로커가 될 수 있다는 거예요. 언젠가 “사람 리뷰 없이 모델이 Commit을 쌓는” 형태가 자연스러워질 수 있다는 관점이 제시됩니다.
지금 당장 쓸 수 있는, 꽤 현실적인 룰 하나
미래 얘기가 아무리 자극적이어도, 당장 실무는 현실이죠.
- 코드베이스가 수년간 유지될 거라면: 모든 줄을 리뷰하는 게 합리적일 수 있다
- 코드가 주말 프로젝트라면: 과도한 리뷰에 목숨 걸 필요가 없다
화려하진 않지만, 가장 정확한 기준일 때가 많습니다.
지금 엔지니어가 할 일: 겁먹지 말고, 스택을 올려라
흥분되면서도 불안한 감정, 자연스럽습니다.
“공예처럼 손으로 코드 짜는 맛”이 줄어드는 게 싫은 사람도 있고, 반대로 지루한 디버깅이 줄어들어서 더 즐거워진 사람도 많죠.
여기서 실전적인 포인트만 뽑아보면 이렇습니다.
1) “정오 판별”이 가능한 일을 만들기
긴 작업이 굴러가려면, 맞고 틀림이 측정 가능해야 합니다.
- 테스트를 결과 중심으로 설계하고
- 스모크 테스트/통합 테스트를 늘리고
- 티켓에 완료 조건을 명확히 쓰세요
에이전트는 “검증이 가능한 세계”에서 가장 강합니다.
2) DevX를 “에이전트 인프라”로 취급하기
다음 팀원이 사람이라고 가정하지 마세요. 에이전트일 수 있습니다.
- 서비스 부팅 순서 문서화
- 초기 실행 스크립트 자동화
- “정답 경로”를 고정해 주는 가이드
- 정상 동작 기준(주소, 화면, 클릭 플로우) 명시
사람은 항의하지만, 모델은 조용히 망가집니다.
3) 결과물보다 “증명”을 요구하기
Cloud Agent에서 “diff만 던지고 끝”은 끝이 아닙니다.
- 테스트 통과
- 로그로 성공 증명
- UI 플로우 트레이스(가능하다면)
- 성능 체크(필요하다면)
증거를 요구하는 순간, 책임 구조가 바뀝니다.
4) 긴 워크플로를 예상한다면 워크플로 엔진 사고방식으로
Temporal이나 Restate를 당장 도입하지 않더라도, 이런 질문을 시작하세요.
- 상태를 어떻게 저장하지?
- 중간 단계 재시도는?
- 중단 후 재개는?
- 배포 중인 작업은 어떻게 살리지?
에이전트가 길어질수록 이건 선택이 아니라 필수가 됩니다.
5) “매니저 감각”을 키우기
앞으로 잘되는 엔지니어는 반드시 “타이핑이 빠른 사람”이 아닐 수 있습니다.
- 목표 정의
- 작업 분해
- 결과 검토
- 자원(시간/compute/예산) 배분
- 완료 기준 설정
이게 점점 핵심 역량이 됩니다.
6) 공예적 코딩의 자리를 냉정하게 재배치하기
손으로 정교하게 만드는 영역은 남을 수 있습니다.
다만 어떤 영역은 줄어들 수 있다는 관점도 제시됩니다(예: kernel 같은 영역이 축소될 가능성).
대신 많은 엔지니어가 “지루한 디버깅이 줄어서 코딩이 더 즐거워졌다”는 체감도 언급됩니다. 이건 꽤 큰 변화예요.
결론: 일은 “위로” 이동한다
Composer 1.5가 흥미로운 이유는 “더 똑똑한 모델”이라서만이 아닙니다.
이 모델이 상징하는 방향이 분명하기 때문이에요.
- RL로 도구 사용을 “습관”으로 만들고
- 속도와 몰입감을 제품의 중심으로 두고
- Cloud Agent를 가능하게 하려면 테스트·증명을 붙여야 하고
- 긴 작업을 위한 신뢰성 인프라(워크플로 엔진, 재시도, 복구)를 고민해야 한다
제품 이름 하나에 올인하라는 얘기가 아닙니다. 패턴에 베팅하라는 얘기예요.
한 줄 요약(공유용): AI가 코드를 쓰는 건 이미 시작됐다. 이제 진짜 질문은 “그 코드가 맞다는 걸 누가, 어떻게 증명하느냐”다.
FAQ: 읽고 나면 꼭 나오는 질문들
1) 에이전틱 모델과 일반 AI 코딩 도구의 차이는 뭔가요?
에이전틱 모델은 단일 답변을 넘어서 검색 → 계획 → 변경 → 검증 → 반복 같은 다단계 워크플로를 실행하는 데 초점을 둡니다. 일반 도구는 뛰어나더라도 “한 번의 응답 생성” 중심인 경우가 많아요.
2) 코딩 모델에서 RL(강화학습)이 왜 그렇게 중요하죠?
RL은 그럴듯한 문장보다 일을 끝내는 행동에 보상을 줄 수 있습니다. 도구 활용, 대형 레포 탐색, 긴 작업 지속, Self-summarization 품질 같은 “행동 양식”을 고정시키는 데 강점이 있어요.
3) Cloud Agent가 아직 로컬보다 별로인 이유는 뭔가요?
부팅/설정이 느리고, 변경된 파일을 파악하기 어렵고, 무엇보다 “큰 diff를 던지고 책임을 사용자에게 넘기는” 흐름이 흔하기 때문입니다. 테스트와 증명까지 모델이 수행할 때 체감이 크게 달라집니다.
4) “천 줄 diff” 문제는 어떻게 해결하나요?
diff 자체를 결과로 보지 말고 검증 증거를 요구하세요.
테스트 통과, 로그, UI 플로우 증명 같은 산출물이 있어야 “완료”라고 판단할 수 있습니다. 동시에 DevX를 정비해 에이전트가 환경을 안정적으로 띄울 수 있게 해야 합니다.
5) 컨텍스트가 제한적인데, 에이전트가 며칠씩 일할 수 있나요?
Self-summarization과 “참조형 기억(파일 덤프 후 필요 시 가져오기)” 전략으로 가능합니다. 요약을 잘 쓰고, 필요할 때 과거 기록을 찾아오는 습관이 핵심입니다.
6) Temporal이나 Restate 같은 워크플로 엔진이 꼭 필요할까요?
작업이 짧다면 당장은 아닐 수 있습니다. 하지만 에이전트가 수시간~수일 단위로 돌기 시작하면, 재시도/복구/상태 저장/중단 후 재개 같은 문제가 필연적으로 터집니다. 그때 워크플로 엔진이 큰 힘이 됩니다.
7) AI가 만든 코드는 지금도 전부 리뷰해야 하나요?
상황에 따라 다릅니다. 현실적인 기준은 이거예요.
- 수년 유지할 코드: 지금은 전 줄 리뷰가 합리적일 수 있음
- 단기 실험/주말 프로젝트: 속도와 학습을 우선해도 됨
8) AI가 대부분 코드를 쓰면 엔지니어는 어떻게 경쟁력을 유지하나요?
코드 타이핑보다 위 단계로 올라가야 합니다. 시스템 설계, 목표 정의, 검증/신뢰성, DevX, 제품 판단이 핵심이 됩니다. “사람을 관리”하는 매니저가 아니라, 에이전트와 시스템을 관리하는 감각을 키우는 게 중요해요.
'SW > 인공지능' 카테고리의 다른 글
| 2026년 AI로 모바일 앱 만드는 법: OnSpace.ai로 iOS·Android 앱 개발부터 앱스토어 배포까지 완벽 가이드 (0) | 2026.03.30 |
|---|---|
| Blitzy(Blitz)란? 엔터프라이즈 AI 코딩 플랫폼으로 대규모 Refactoring을 PR로 받는 방법 (0) | 2026.03.28 |
| 2026년 AI 시대 소프트웨어 개발 변화 정리: 코드는 쉬워지고 ‘코드 이해력’이 핵심이 된 이유 (0) | 2026.03.25 |
| OpenClaw 24시간 자동화 세팅법: Codex와 Opus 병행으로 비용 줄이는 실전 전략 (0) | 2026.03.20 |
| 2026년 ChatGPT App Store 완전 정리: MCP 기반 interactive UI 앱 만드는 방법 (0) | 2026.03.18 |