빅테크 엔지니어가 경험한 Opus 5.5 후기

흥미로운 점은 Low/Medium 설정에서 토큰 사용량이 훨씬 적다는 거야. UI 디자인이 별로 없는 코드 관련 작업 위주로 2~3일 돌렸는데 Enterprise 계정 사용량의 3% 정도밖에 안 썼어. 잡담을 안 하고 바로 작업에 들어가니까 4.8이나 4.7처럼 여러 번 왔다 갔다 할 필요가 없더라고.

Medium 사고 과정을 아주 잘 균형 잡았다고 생각해. 작은 모델을 쓰는 것과 같은 효과를 내고 싶으면 Low 사고 과정을 쓰면 되니까. 예산 아끼려고 다른 모델을 따로 쓸 필요가 없어진 거지.

회사에서 기본적으로 무제한 사용량을 줘서 토큰은 안 세어봤어. 근데 속도가 더 놀라워. 응답이 진짜 빨라.

즐길 수 있을 때 즐겨라.

이거에 대해 할 말이 많은데, 네 말에 동의해. 코드가 변경되는 주변 상황을 신경 써야 하거든. 모델이 함수 하나 고치는 건 쉽게 시킬 수 있지만, 호출하는 쪽이 깨졌는지, null의 의미가 바뀌었는지, 호출자가 처리해야 할 예외를 잡아버렸는지 확인해야 해. 매번 이런 문제를 찾다 보면 디버깅을 두 번 하는 꼴이지. 젠장...

그게 네가 5.5에서 보는 생산성 향상을 설명하는 방식일 거야. 패치가 그런 의존성까지 고려하면 다시 보낼 이유가 줄어드니까. 구현 절반을 다시 파악할 필요 없이 diff만 따라가면 되거든.

예를 들어 비동기 버그의 경우, 취소가 실제로 작업을 멈추는지, 타임아웃이 트랜잭션을 열어두는지, 재시도가 이미 성공한 쓰기 작업을 반복할 수 있는지 확인해야 해. 회귀 테스트가 이전 코드에서 실패를 재현하고 수정 후에는 통과하길 바라지. 근데 트랜잭션이나 재시도 로직을 모킹(mock)해버리면 내가 걱정하는 부분은 테스트가 안 된 거잖아.

모델이 그런 걸 더 많이 맞히면 진짜 의미 있는 시간을 벌어주는 거야. '남는 시간'에 모델한테 똑같은 버그를 다시 설명하는 대신 다른 실패 사례를 테스트할 수 있지.

GPU 부하 때문에 몇 주 지나면 모델 성능을 너프한다는 소리를 계속 듣는데, 만약 그렇게 되면 그냥 Astra로 돌아가서 잘 되길 빌어야지.

임포스터 증후군도 나타나. 21년 차인데 AI가 우리 삶에 들어오면서 위에서 나를 어떻게 볼지 생각하면 좀 어색해져. 코드는 여전히 내 책임인데, 수정 요청했다가 리뷰에서 설명도 못 할 diff를 쳐다보고 있게 되거든. 그러고는 모델한테 왜 그런 결정을 내렸는지 설명하라고 시키고, 내가 배우는 건지 아니면 그냥 모델한테 동의하는 법만 배우는 건지 의문이 들어.

테스트가 통과해도 그게 실패를 검증한 건지, 아니면 모델이 자기 가정에 맞춰 테스트를 짠 건지 알 수 있나? 대화 기록 없이 새벽 2시에 이걸 디버깅할 수 있을까? 합리적인 엔지니어링 질문들이지만, '내가 이제 이걸 잘 못 하나?'라는 생각으로 빠지기 쉬워. 탑건 매버릭 생각나네... 드론이 인간 조종사보다 도그파이트를 더 잘하기 시작할 때 말이야.

그래서 코드를 따라갈 수 있는 게 정말 중요해. 잘못된 가정을 알아보고, 설계를 반박하고, 최종 수정안이 왜 타당한지 이해하고 싶어. 누군가 어떻게 작동하는지 물어볼 때마다 속으로 다른 사람한테 물어보길 바라는 상황이라면 생산성이 높아져도 즐기기 힘들 거야.

일단은 계속 써보겠지만, 근육 기억 없이 만드는 법을 잊어버리는 아키텍트가 되지 않으려면 어떻게 해야 할지 고민이야.