클로드 5 페이블 체험기, 인공지능을 조종하는 게 아니라 의뢰하는 느낌이 됐다

• 클로드 5 페이블은 저자 기준으로 "또 좀 좋아졌네" 수준이 아니라, 일하는 방식 자체가 바뀌었다는 느낌을 준 모델임

  • 저자는 미토스급 인공지능 모델 중 처음 공개되는 클로드 5 페이블을 조기 체험함
  • 보안 분야 영향이 많이 논의됐지만, 페이블은 가드레일 때문에 사이버보안 작업에는 사실상 쓰기 어렵다고 함
  • 대신 게임 제작, 연구, 데이터 분석, 복잡한 코딩 프로젝트에서 기존 공개 모델보다 확실히 큰 점프를 보였다고 평가함

• 가벼운 예시로는 게임을 만들게 했는데, 여기서도 꽤 이상한 수준의 결과가 나옴

  • 저자는 클로드 코드에서 애매한 프롬프트 하나를 던지고, 이후 "더 좋게 만들어봐" 같은 짧은 피드백만 몇 번 줬음
  • 페이블은 외부 이미지 생성 없이 수학적으로만 아트와 3차원 오브젝트를 만들어 게임을 구성함
  • 동전 뒤집기판 발라트로풍 게임, 자의식 있는 스네이크 게임, 깊은 곳으로 내려가는 게임 같은 결과물이 나옴

• 진짜 인상적인 건 등시선 지도(isochrone map) 프로젝트였음. 이건 기존 모델들이 제대로 못 하던 유형임

  • 등시선 지도는 특정 도시에서 주어진 시간 안에 어디까지 갈 수 있는지를 보여주는 지도임
  • 항공편, 공항 이동 시간, 기차, 도보, 자동차, 국가별 도로 속도 같은 변수가 얽혀 있어서 단순 코딩 문제가 아님
  • 저자는 "실제 데이터 기반으로 여러 도시를 고를 수 있는 아름다운 등시선 지도를 만들어달라"는 식의 야심 찬 지시를 넣음

• 페이블은 이 작업을 혼자 몇 시간 동안 굴리면서, 여러 하위 인공지능을 띄워 조사와 구현을 병렬로 진행함

  • 저자 관찰에 따르면 대부분 더 저렴한 클로드 소넷 계열로 보이는 보조 모델들을 호출해 여행 시간 조사를 맡김
  • 최종적으로 2200개 이상의 구체적 항공편, 고속철도 일정, 여러 논문에서 가져온 국가별 도로 속도 데이터를 수집함
  • 보조 에이전트가 조사하는 동안 본체는 코딩을 시작했고, 이후 추가 에이전트와 테스트를 띄워 코드 검증까지 진행함

• 결과물은 완벽하진 않았지만, 기존 모델과 비교하면 작업 범위가 확실히 달랐음

  • 처음 결과물은 1881년 원조 등시선 지도 스타일을 닮은 동작 가능한 지도였음
  • 다만 그린란드 같은 원격 지역은 정확한 이동 시간이 아니라 추정치가 많이 들어가 있었음
  • 저자가 실제 원격 공항과 지역까지 이동 시간을 구하라고 고치자, 페이블은 서로 검증하는 적대적 에이전트 그룹을 띄워 핏케언섬 선박 운항, 오타와에서 그리스 피오르드까지 가는 경로 같은 디테일까지 찾아냄

• 저자가 더 크게 놀란 프로젝트는 연구용 소프트웨어 콩코드(Concord)였음

  • 저자는 사람이 작성한 지저분한 응답을 분류하고, 인간 연구자 판단과 인공지능 판단을 통계적으로 보정하는 문제를 페이블에게 맡김
  • 페이블은 먼저 19쪽짜리 복잡한 설계 문서를 만들고, 그다음 실제 구현에 들어감
  • 전체 작업 시간은 9시간 30분이었고, 여러 데이터셋을 받아 인간·인공지능 응답을 보정한 뒤 복잡한 분석을 수행하는 소프트웨어가 나옴

• 물론 만능은 아님. 비용과 가드레일, 특유의 이상한 문체, 블랙박스 문제가 그대로 따라옴

  • 페이블은 오퍼스보다 2배 비싸고, 토큰을 엄청난 속도로 태운다고 함
  • 다만 저렴한 모델에 일을 위임하는 구조 덕분에 실제 비용은 어느 정도 줄어들 수 있음
  • 보안 문제 냄새만 나도 가드레일이 작동해 더 약한 클로드 4.8 오퍼스로 내려가는 일이 잦았다고 함
  • 생성한 소프트웨어와 진행 보고서에는 여전히 클로드 특유의 문체 흔적이 남아 있었음

• 가장 큰 변화는 사용자의 역할임. 저자는 이제 모델을 조종한다기보다 일을 발주하는 느낌에 가깝다고 말함

  • 과거엔 프롬프트를 넣고 결과를 조금씩 끌고 가는 감각이었다면, 페이블은 지시를 받고 자체적으로 조사·작성·검증 스튜디오를 차리는 쪽에 가까움
  • 사용자는 세부 의사결정이 어떻게 이뤄지는지 거의 보지 못하고, 중간에 관여할 기회도 많지 않음
  • 수백 개의 작은 판단을 모델이 알아서 해버리기 때문에, 결과는 좋아도 과정은 더 불투명해짐

• 개발자에게 이 글이 중요한 이유는 단순히 코딩 생산성이 올라간다는 얘기가 아니라서임
  • 복잡한 내부 도구, 연구용 소프트웨어, 수익성이 낮아 아무도 만들지 않던 작은 전문 도구들이 모델 발주만으로 튀어나올 수 있음
  • 반대로 그 결과물을 검수하고 버그를 잡고 책임질 사람은 여전히 필요함
  • 저자가 오히려 미래에 코더가 더 필요할 수 있다고 본 이유도 여기에 있음. 소프트웨어 사용처가 폭발하면 검수와 통합의 일도 같이 늘어남

---

기술 맥락

• 페이블이 보여준 선택은 단일 응답 생성이 아니라 장시간 에이전트형 워크플로예요. 왜 이게 중요하냐면 복잡한 작업은 한 번에 답을 쓰는 것보다 조사, 설계, 구현, 검증을 나누는 쪽이 훨씬 현실적인 구조거든요.

• 등시선 지도 사례에서 모델은 항공편, 철도, 도로 속도 같은 서로 다른 데이터 소스를 동시에 모았어요. 이건 단순히 코드를 생성한 게 아니라, 데이터 수집과 판단이 많은 제품 개발 과정을 흉내 낸 거예요. 그래서 사용자는 "어떤 라이브러리를 쓸까"보다 "최종 결과가 믿을 만한가"를 더 많이 보게 돼요.

• 콩코드 사례가 흥미로운 이유는 시장성이 애매한 전문 도구를 만들었다는 점이에요. 연구자에게는 필요하지만 제품 회사가 돈을 벌기 어려운 소프트웨어가 많거든요. 모델이 이런 틈새 도구를 몇 시간 동안 만들어내면, 개발 수요 자체가 넓어질 수 있어요.

• 대신 비용과 검증 문제가 같이 커져요. 9시간 넘게 토큰을 태우는 모델은 결과가 멋져도 운영비가 만만치 않고, 내부에서 어떤 판단을 했는지 다 따라가기도 어려워요. 그래서 앞으로 개발자의 일은 코드를 직접 치는 것만큼이나, 모델 산출물을 테스트하고 책임질 수 있는 형태로 만드는 쪽으로 이동할 가능성이 커요.