핵심 요약

  • 코드를 써본 적 없는 채용 전문가 브라이스 래트너 키슬리는 여러 AI 도구를 활용해 운동 앱 Daily Hundred를 만들고 App Store에 출시했다.
  • 브라이스는 Claude로 작업을 계획하고, Claude Code로 코드를 작성한 뒤, Terminal에서 필요한 명령을 실행하는 방식으로 진행했다.
  • 클레어 보는 Codex의 Goals를 완료 상태와 검증 방법을 정해 두고 AI가 여러 단계를 반복 수행하게 하는 기능으로 설명했다. 오류 처리와 이메일 정리 사례를 제시했다.
  • 클레어의 평가에서 Claude Opus 4.8은 새 기능 제작과 디자인에는 강점을 보였지만, 기존 코드베이스의 복잡한 수정과 수치에 근거한 전략 분석에서는 한계를 드러냈다.

코딩 경험 없이 출시한 운동 앱

인재 채용 분야에서 일해 온 브라이스 래트너 키슬리는 이전에 코드를 한 줄도 작성한 적이 없었다. 그는 주말 시간을 들여 몇 달 만에 운동 앱 Daily Hundred를 만들고 App Store 승인을 받았다. 앱에는 동물이 운동 동작을 하는 맞춤형 AI 생성 영상이 들어간다. 제작 과정에는 Replit, Claude, Gemini, Higgsfield, Kling을 활용했다.

브라이스의 작업 방식은 도구마다 역할을 나누는 것이었다. 일반 Claude와 무엇을 할지, 문제에 어떻게 접근할지 계획했다. Claude의 안내에 따라 실제 코드 작성에는 Claude Code를 사용하고, 작성된 코드를 다시 Claude에 가져가 확인했다. 이어 Claude가 알려준 내용을 Terminal에 입력해 작업을 진행했다. 브라이스는 모든 코드의 작동 원리를 완전히 이해하지 못해도 이 과정을 통해 앱을 출시할 수 있었다고 설명했다.

화면을 보여주고 요청을 다시 쓰는 반복 과정

AI가 의도를 이해하지 못할 때 브라이스는 설명을 더 구체적으로 바꾸거나, 기존 요청을 조금 고치는 대신 처음부터 새로 요청했다. 실제 화면의 스크린샷을 보내기도 했다. 원하는 모습을 직접 그리거나 자신의 시작 자세를 촬영해 시각적 참고자료로 제시한 경우도 있었다.

브라이스는 이 경험을 기술 인력의 역할 변화와도 연결했다. 그의 견해로는 작동하는 해법을 가장 빨리 찾는 데만 집중하는 것보다, 여러 도구의 쓰임을 이해하고 AI에 맡길 부분과 사람이 판단할 부분을 가리는 능력이 중요해지고 있다. 채용에서도 기존 역할을 고수하기보다 새로운 방식으로 협력할 호기심과 유연성을 중시해야 한다고 봤다.

Codex Goals가 맡은 장시간 작업

클레어 보는 Codex의 Goals를 한 번의 지시를 처리하는 일반 프롬프트와 구분했다. 예를 들어 ‘코드를 다시 써라’는 수행할 작업을 지정한다. 반면 Goal은 목표로 삼는 결과, 확인 방법, 지켜야 할 조건을 함께 정한다. AI는 그 기준에 따라 작업하고 검증한 뒤 필요하면 다음 시도를 이어간다는 설명이다. 클레어가 성공적으로 실행한 가장 긴 Goal은 5시간 45분 동안 작동했다.

클레어는 오류 추적 도구 Sentry의 기록을 Codex에 제공하고, 문제를 분류·수정한 뒤 과거 사례를 다시 실행해 확인하도록 했다. 그의 설명에 따르면 수백 건의 오류 로그를 다룬 끝에 남은 오류가 0건이었고, 흩어진 임시 수정 대신 체계적인 처리 구조를 얻었다.

이메일 정리에도 Goals를 사용했다. 모든 메일을 분류하고 불필요한 구독을 해지하도록 지시한 결과, 약 3,900개의 메일을 4시간 이내에 68개로 줄였다고 밝혔다. 남은 것은 사람의 판단이 필요한 메일이었다. 이 작업에는 약 600만 토큰이 사용됐다.

Goal을 정의하는 여섯 가지 요소

클레어가 제시한 Goal의 구성 요소는 원하는 결과, 검증 방법, 유지해야 할 조건, 사용할 도구와 파일의 범위, 다음 시도를 고르는 기준, 도움을 요청할 중단 조건이다. 완료 상태만 적는 것으로 끝내지 않고, 무엇을 확인하며 어디까지 자율적으로 진행할지를 함께 정하는 방식이다.

클레어는 이런 작업이 토큰을 적게 쓰는 방식은 아니라고 인정했다. 다만 수천 개의 메일을 직접 분류하거나 수백 건의 오류 기록을 일일이 추적하는 데 드는 시간과 비교해 효용을 평가했다.

Opus 4.8 평가에서 갈린 작업별 성능

클레어는 Claude Code와 Claude Cowork에서 Anthropic의 Opus 4.8을 코딩, 디자인, 전략 작업에 사용해 봤다. 그의 평가에서 글은 읽기 쉬웠고 지시를 잘 따랐으며, 빠른 모드를 켰을 때 반응도 경쾌했다. 새 프로젝트에서 한 번의 요청으로 기능을 만들거나 디자인 작업을 수행하는 데에도 좋은 결과를 보였다.

반면 운영 중인 코드베이스에서는 신중한 확인이 필요했다. 클레어에 따르면 브랜치를 리베이스하고 충돌을 해결하는 작업에서 수정과 재수정을 거듭했고, 경계 사례의 버그가 이어졌다. 디버깅 중 실제 데이터로 확인하지 않은 설명을 자신 있게 제시한 경험도 있었다.

전략 작업에서는 두 모델에 동일한 요청과 3개월치 사업 맥락을 제공해 비교했다. 클레어는 Opus 4.7의 결과가 실제 수치에 근거해 구조적으로 정리된 반면, Opus 4.8은 작은 데이터에 지나치게 무게를 두고 관련 정보를 찾는 데 어려움을 보였다고 평가했다. 아홉 살 아이에게 인상적인 것을 만들 아이디어를 요청한 실험에서도 작동하는 코드는 나왔지만 기대한 수준의 결과는 아니었다.

세 에피소드는 서로 다른 작업을 다룬다. 브라이스는 여러 도구와 시각 자료를 오가며 앱을 출시했고, 클레어는 자율 작업의 완료 기준을 구체화했으며, 모델 평가에서는 작업 종류에 따라 결과가 달라진다고 보고했다.