Opus 4.8 실전 활용: 실제 코딩 세션

• 모호한 날짜 필드에서 Opus 4.8은 잘못 추측하는 대신 멈춰서 나에게 질문을 던졌다.

• 내가 단 하나의 테스트도 실행하기 전에, 작업 도중 스스로의 off-by-one 버그를 찾아냈다.

• 1M 컨텍스트 (1M context) 덕분에 9개의 파일을 한꺼번에 유지할 수 있었고, "이게 무엇을 하는지 다시 알려줘"와 같은 반복적인 확인 과정이 전혀 없었다.

• 여전히 네이밍, 제품에 대한 취향, 그리고 무엇을 만들지 말아야 할지에 대한 결정에는 나의 도움이 필요하다.

• SWE-Bench Pro 점수는 69.2이지만, 내가 하루 종일 실제로 체감한 변화는 (잘못된 추측을 하지 않고) 절제하는 능력이었다.

나는 3일 동안 리팩터링 (refactor)을 미뤄오고 있었다. 이론적으로 어려워서가 아니라, 하나의 잘못된 가정이 오후 시간을 통째로 날려버릴 수 있는, 여러 파일을 건드려야 하고 망가뜨리기 쉬운 종류의 작업이었기 때문이다. 나는 금요일에 Opus 4.8을 실행 중인 Claude Code에게 이 작업을 맡겼다. 키보드 앞에서 어떤 일이 일어났는지, 나를 놀라게 했던 순간들, 그리고 여전히 인간의 손길이 필요한 부분들에 대해 이야기해 보려 한다.

평소라면 두려워했을 작업

작업 내용은 내 블로그 툴링 (tooling) 내부의 신디케이션 스케줄러 (syndication scheduler)였다. 기사 큐 (queue)를 읽고, 각 기사가 어떤 플랫폼으로 갈지 결정하며, 플랫폼별 게시 시간을 찍어주는 TypeScript 서비스다. 이 서비스는 유기적으로 성장해 왔다. 플랫폼 목록은 한 파일에, 시간 로직은 다른 파일에, 큐 리더 (queue reader)는 세 번째 파일에 있었으며, 얽혀 있는 헬퍼 (helpers) 함수들은 나머지 6개 파일에 흩어져 있었다. 나는 기존의 당일 게시 동작을 망가뜨리지 않으면서(이전에 타임존 버그 때문에 고통스럽게 한 번 수정한 적이 있다), 플랫폼별 지연 시간 윈도우(예: Dev.to에는 즉시 게시하고, 에디토리얼 피드에는 2시간 동안 보류)를 추가하고 싶었다.

이것이 바로 내가 두려워하는 종류의 작업이다. 알고리즘적으로 흥미로운 것이 아니라, 그저 범위가 넓을 뿐이다. 범위 내에 9개의 파일이 포함되어 있다. 실패 모드는 결코 "할 수 없다"가 아니라, "큐 리더를 수정했는데 세 파일 너머에 있는 스케줄러가 오래된 형태를 읽는다는 사실을 잊어버려서, 화요일 기사들이 조용히 배포되지 않는 상황"이다. 나는 정확히 그런 일 때문에 오후 시간을 통째로 날려버린 적이 있다.

나는 세션을 열고, 디렉토리를 지정한 뒤, 변경 사항을 세 문장으로 설명했다. 파일 목록을 나열하거나 어디에 무엇이 있는지 일일이 알려주지 않았다. 나의 솔직한 기대치는 평소와 같았다. 즉, 내가 한 줄씩 검토해야 할, 자신감 넘치고 대체로 정확한 diff (차이점)를 보여줄 것이라는 기대였다. 왜냐하면 그 '자신감'이 위험한 부분이기 때문이다. 이전 모델들은 무언가를 기꺼이 재구성한 뒤 완성된 것처럼 제시하곤 했고, 버그는 파일 사이의 이음새 속에 숨어 있었다.

하지만 이후 20분 동안의 과정은 그렇지 않았다. 모델이 가장 먼저 한 일은 코드를 작성하는 것이 아니었다. 그것은 읽는 것이었다. 그러고 나서 멈추더니, 내가 답변할 생각조차 하지 못했던 질문을 던졌다.

추측하는 대신 질문했다

질문은 scheduledAt이라는 필드에 관한 것이었다. 9개의 파일 중 2개에서 해당 필드는 "기사가 큐(queue)에 들어가는 시간"을 의미했다. 하지만 스케줄러(scheduler)가 포함된 한 파일에서는 "실제로 게시되는 시간"으로 읽히고 있었다. 이름은 같지만 의미는 두 가지였고, 내가 새로 추가하려는 지연 시간(delay window)은 두 경우 모두에 영향을 미쳤다. Opus 4.8은 이 충돌을 감지하고, 두 가지 해석을 평이한 언어로 설명한 뒤, 새로운 코드 경로에 대해 내가 어떤 의도를 가지고 있는지 확실하지 않다고 말했다. 그러고 나서 기다렸다.

모델은 하나를 선택해 막무가내로 밀어붙이지 않았다. 그러한 절제력이 이 모델의 핵심적인 변화이며, Simon Willison은 자신의 리뷰에서 이를 '기권에 의한 정직함(honesty by abstention)'이라고 강조했다. 즉, 답이 진정으로 모호할 때 자신 있게 추측하는 대신 "확실하지 않다"라고 말하는 것이다. Anthropic은 이를 수치적으로 표현하여, 이전 모델들에 비해 자신의 불확실성이나 버그를 언급하지 않고 그냥 넘어갈 확률이 약 4배 낮아졌다고 설명한다. 서류상으로는 단순한 통계일 뿐이지만, 키보드 앞에서는 의견을 형성하기 전에 문제 전체를 읽는 사람과 함께 작업하는 듯한 기분이 들었다.

이것이 왜 중요했는지 설명하겠다. 만약 모델이 "발행 시간 (publish time)"을 추측했다면, 나의 지연이 이미 밀려있는 타임스탬프 (timestamp) 위에 중첩되어, 당일 기사들이 몇 시간씩 늦게 밀려나게 되었을 것이다. Diff (차이점)가 깔끔해 보였을 것이기에 리뷰 과정에서도 이를 잡아내지 못했을 것이다. 이 버그는 큐 (queue)가 바쁜 날, 운영 환경 (production)에서만 드러난다. 단 하나의 질문을 던짐으로써, 모델은 단 한 줄의 코드도 작성되기 전에 오후 내내 고생할 만한 버그를 제거해 버렸다.

나는 다섯 단어로 답변했다. 모델은 작업을 계속했다. 나는 나의 Opus 4.7 솔로 스튜디오 워크플로우 (my Opus 4.7 solo studio workflows)에서 이전 티어의 정직함을 탐구한 적이 있지만, 이번의 절제는 훨씬 더 날카로우며 코드 작성 중이 아닌, 작성 전 단계에서 더 일찍 나타났다.

내가 테스트를 실행하기도 전에 스스로의 버그를 찾아냈다

새로운 지연 로직 (delay logic)을 작성한 지 20줄 정도 지났을 무렵, 작업 도중에 모델은 작성을 멈추고 방금 자신이 생성한 코드를 가리켰다. 바로 자신의 코드였다. 모델은 2시간 대기 시간을 위한 날짜 산술 (date arithmetic) 과정에서 날짜 경계 부분에 Off-by-one (하나 차이) 오류 위험이 있다고 말했다. 즉, 만약 기사가 23:10에 큐에 쌓인다면, 대기 시간을 더했을 때 자정을 넘길 수 있고, 그러면 다운스트림 (downstream)의 당일 체크 로직이 이를 다음 날의 기사로 판단하여 거부하게 된다는 것이다. 모델은 비교 대상을 변경된 날짜가 아닌 큐에 쌓인 날짜로 제한 (clamping)할 것을 제안했고, 계속 진행하기 전에 내 동의를 구했다.

나는 테스트를 단 하나도 실행하지 않았다. Diff (차이점)조차 아직 읽지 않은 상태였다. 모델은 자신의 작업에서 결함을 포착하고 스스로 이를 드러냈는데, 이것이 바로 "언급되지 않은 결함이 4배 적다"는 특성이 실무에서 나타나는 모습이다. 이전 모델들이라면 해당 버그를 작성하고, Diff를 완료된 것처럼 제시한 뒤, 내 테스트 스위트 (test suite)나 (더 나쁜 경우라면) 운영 환경에서 발견되도록 방치했을 것이다.

이 부분이 제 작업 리듬을 바꾸어 놓았습니다. 이전의 루프는 다음과 같았습니다: 모델이 작성하고, 저는 모든 줄을 의심스럽게 읽고, 테스트를 실행하고, 테스트가 제가 놓친 것을 잡아내면, 다시 돌아가는 방식이었습니다. 새로운 루프는 모델이 동일한 턴(turn) 내에서 자체적인 1차 검토 (first-pass review)를 수행합니다. 이것이 저의 검토를 대체하는 것은 아닙니다. 다만, 사후에야 명백해 보이는 부류의 실수들을 미리 처리함으로써, 저의 검토가 산술적인 부분 대신 의도 (intent)에 집중할 수 있도록 해줍니다. 여기서 벤치마크 (benchmarks)를 다시 나열하지는 않겠습니다. 모든 테스트에 대한 전체 사양 분석은 어제의 출시 요약 (yesterday's launch roundup)을 참조하십시오. 제가 느낀 점은 더 단순했습니다: 사후에 발생하는 놀라운 일들이 줄어들었다는 것입니다.

전체 저장소 (repo)를 머릿속에 유지함

9개의 파일. 다중 파일 리팩토링 (multi-file refactors)을 망치는 요인은 망각입니다. 파일 A를 수정하면, 세 파일 뒤에서 모델은 당신이 변경한 타입 (type)의 형태를 잊어버리고, 그래서 이전 형태를 기준으로 코드를 작성하게 됩니다. 일반적인 증상은

저는 이전에 1M 컨텍스트 윈도우(context window)가 제가 코딩하는 방식을 어떻게 바꾸는지에 대해 글을 쓴 적이 있는데, 이번 세션은 지금까지 중 가장 깔끔한 시연이었습니다. 파일을 다시 붙여넣을 필요도 없었습니다. "상기시켜 드리자면" 같은 서문도 필요 없었습니다. 세 번째 파일에서 수정한 내용과 일곱 번째 파일에서 가정한 내용 사이에 괴리도 없었습니다. 그리고 결정적으로, 긴 컨텍스트(long-context)에 대한 가격 프리미엄이 없기 때문에, 전체 리포지토리(repo)를 입력하는 비용이 파일 하나를 입력하는 비용과 토큰당 동일합니다. 저는 모델에게 보여줄 내용을 아껴가며 조절하는 것을 그만두었습니다. 그냥 모든 것을 보여주었고, 그것이 일관성이 발생하는 방식입니다. 모델에게 이미 잊어버린 상태(state)를 다시 설명하는 데 드는 왕복 과정을 줄인 것만으로도 아마 10분 정도는 아꼈을 것입니다.

여전히 저의 도움이 필요한 부분

이 기술을 과장하고 싶지는 않습니다. 해당 세션 중 세 번의 지점에서 모델은 분명히 적절한 결정권자가 아니었으며, 그렇지 않은 척하는 것은 저를 부주의하게 만들 것입니다.

명명 (Naming). 모델은 새 필드에 대해 delayWindowMs를 제안했습니다. 기능적이긴 하지만 금방 잊힐 이름입니다. 저는 이를 holdUntil로 변경했습니다. 몇 달 뒤에 제가 holdUntil을 읽으면 즉시 무엇을 하는지 알 수 있겠지만, delayWindowMs를 읽으면 다시 생각해야 할 것이기 때문입니다. 명명은 미래의 제가 코드를 어떻게 읽을지에 뿌리를 둔 취향의 문제이며, 모델은 기억하기 좋은 것이 아니라 올바른 것에 최적화됩니다.

범위 (Scope). 어느 시점에서 모델은 실패한 게시물에 대한 재시도 큐(retry queue)도 추가하겠다고 제안했습니다. 합리적인 코드였고 진심으로 유용했지만, 바로 제가 원하지 않았던 종류의 것이었습니다. 작은 것을 출시하고 유혹적인 인접 기능을 배제하는 절제력은 제가 유지해야 할 몫입니다. 모델은 당신이 허용하는 것은 기꺼이 만들어낼 것입니다. 무엇을 만들지 말지 결정하는 것이 실제 업무입니다. 저는 15개의 리포지토리를 운영하는 스튜디오를 운영하고 있으며, 그러한 절제력이 제가 제정신을 유지하는 핵심이며, 이는 모든 것을 하나의 CLAUDE.md 파일에서 실행하는 방식의 정신이기도 합니다.

제품에 대한 안목 (Product taste). 2시간 동안 편집을 보류하는 것이 과연 적절한 행동인지 여부는 코드의 문제가 아니라, 내 독자와 배포 방식에 대한 판단의 문제입니다. 모델은 어떤 규칙이든 결점 없이 구현할 수 있습니다. 하지만 그 규칙이 내 독자에게 잘못된 것인지 알려줄 수는 없습니다. 공정하게 말하자면, 이 모델이 무적은 아닙니다. Terminal-Bench 2.1에서 GPT-5.5에 뒤처지며, 마법 같은 존재도 아닙니다. 그저 언제 멈춰야 할지를 아는, 매우 유능한 조력자 (pair of hands)일 뿐입니다.

결론 (Bottom Line)

내 업무 방식에서 변한 것은 속도가 아닙니다. 물론 더 빨라지긴 했지만요. 핵심은 두려움이 사라졌다는 것입니다. 사흘 동안 미뤄왔던, 방대하고 깨지기 쉬운 다중 파일 (multi-file) 작업도 이제는 주저 없이 시작할 수 있습니다. 모델이 추측하기 전에 먼저 물어보고, 내가 발견하기 전에 스스로 산술 오류를 잡아내며, 네 개의 파일 전 단계에서 정의된 타입 (type)의 형태를 잊지 않고 전체 리포지토리 (repo)를 파악하고 있기 때문입니다. 나의 리뷰 작업은 숨겨진 버그를 찾는 것에서 의도와 명명 (naming)을 결정하는 것으로 옮겨갔으며, 이것이 바로 내가 실제로 하고 싶은 업무입니다. 5/25의 가격은 이전 티어와 동일하게 유지되었으므로 예산 측면에서 변한 것은 없으며, 오직 확신만이 변했습니다. 만약 제가 이번 세션과 같은 작업을 수행할 때 사용하는 템플릿과 훅 (hooks)을 원하신다면, Claude Blueprint에서 확인하실 수 있습니다. 당신이 계속 미뤄왔던 작업부터 시작해 보세요. 이 모델이 제값을 하는 순간은 바로 그 작업에서 나타날 것입니다.