AI 개발 방식 변화 3부작 · 3부
1부: AI에게 질문만 하던 사람이 NAS에서 프로그램을 만들기 시작했다
2부: Claude Code 전성시대, 프로젝트가 폭발적으로 늘어났다
지금 가장 바꾸고 싶은 것은 모델보다 사람이 작업 사이에 끼어드는 횟수입니다. 현재 사용하거나 실험 중인 흐름이며, 완전한 무인 시스템은 아닙니다.
목표가 바뀌었다: 내가 없어도 작업이 이어지게
초기에는 문제가 생길 때마다 SSH에 접속했고, Claude Code를 사용한 뒤에도 다음 승인이나 지시를 위해 컴퓨터 앞에 있어야 할 때가 많았습니다.
“AI를 이용해 빨리 코딩하자”가 아니라 “NAS 앞에 없어도 작업이 이어지게 하자.”
스마트폰 음성이 새로운 입력점이 됐다
스마트폰은 이제 단순한 원격 화면보다 작업 목표를 전달하는 관제용 마이크에 가깝습니다.
“Briefold 전체 이미지를 다시 검사하고 확정 결함만 수정해.” 또는 “멈춘 에이전트만 이어서 진행해.”처럼 목표를 음성으로 전달합니다.
스마트폰에서 직접 코드를 고치는 대신 음성으로 목표와 제약을 전달하고 실제 작업은 NAS의 에이전트가 수행하게 하는 구조입니다.
음성 지시 뒤의 오케스트레이션
제가 만들고 있는 흐름은 다음과 같습니다.
- 스마트폰 음성으로 목표와 제약을 전달합니다.
- 대화형 AI와 Herdr 같은 오케스트레이션 계층이 작업자를 연결합니다.
- Claude Code나 Codex가 저장소를 읽고 수정합니다.
- NAS에서 테스트와 서비스 상태를 확인합니다.
- 다른 에이전트나 결정론적 게이트가 결과를 재검증합니다.
- 성공·실패·남은 문제를 스마트폰에서 확인합니다.
세션 연결과 에이전트 충돌은 남아 있지만 방향은 분명합니다. 사람은 명령 전달자가 아니라 목표와 승인 경계를 정하는 역할로 이동합니다.
여러 AI를 띄우는 것만으로는 부족했다
Claude Code와 Codex를 나누고 Herdr로 상태를 관리해 보니 에이전트 수만 늘린다고 오케스트레이션이 완성되지는 않았습니다. 완료 보고와 실제 서버 상태가 다르거나 다른 세션 빌드가 앞선 변경을 덮는 일도 있었습니다.
AI의 말을 믿는 것이 아니라 상태를 검증해야 합니다.
Blog Factory와 Social Factory가 보여 준 것
Blog Factory에서는 자동화가 커질수록 통과하지 못하면 게시하지 않는 게이트가 중요해졌고, Social Factory에서는 게시 성공과 성장 성공이 다르다는 것을 확인했습니다.
돌아보면 네 단계였다
- 0단계 — 채팅: AI에게 질문하고 답을 받았습니다.
- 1단계 — 복사·붙여넣기: AI가 코드를 만들면 제가 NAS에서 실행했습니다.
- 2단계 — 코딩 에이전트: Claude Code가 프로젝트 안에서 직접 수정하고 테스트했습니다.
- 3단계 — 오케스트레이션: Claude Code와 Codex를 나누고 스마트폰 음성까지 작업 흐름의 입구로 연결하고 있습니다.
가장 큰 변화는 모델 성능이 아니었습니다.
사람이 AI 사이에서 하던 일을 하나씩 없애 온 과정이었습니다.
다음 목표
처음에는 Python 코드를 받아 SSH에 붙여넣었습니다. 지금은 스마트폰에서 목표를 말하면 여러 에이전트가 작업하고 NAS와 별도 검증 단계가 결과를 확인합니다.
목표는 프로그램을 계속 만들고, 고치고, 검증하고, 운영할 수 있는 시스템 자체입니다.
물론 지금 단계가 영화 속 AI 비서처럼 자연스럽게 대화를 주고받는 수준은 아닙니다. 아직은 제가 스마트폰으로 음성 지시를 전달하면 작업이 시작되고, 그 결과가 돌아올 때까지 기다렸다가 다음 지시를 이어 가는 형태에 가깝습니다.
처음 AI에게 짧은 질문만 하던 시절과 비교하면, 스마트폰으로 말한 목표가 여러 에이전트와 NAS 작업으로 이어지고 결과가 돌아오는 단계까지 왔습니다.
그래서 요즘은 영화에서 보던 자비스(JARVIS) 같은 AI와 일하는 방식도 아주 먼 미래만은 아닐 수 있겠다는 느낌이 듭니다.
다음 단계의 기준은 AI가 얼마나 좋은 코드를 쓰느냐보다 얼마나 적은 사람의 개입으로 오래 안정적으로 일을 계속할 수 있느냐가 될 것 같습니다.