본 글은 Claude Opus 5.5의 활용법을 다루며, 복잡한 개발 작업에서 단계별 사고(step-by-step thinking)와 에이전트 오케스트레이션의 중요성을 강조합니다. 특히 CI 최적화나 오픈소스 코딩 같은 실제 프로젝트에 적용하여 시간과 비용을 획기적으로 절감하는 사례를 제시했습니다.
핵심 포인트
복잡한 작업은 단계별 접근으로 의존성 발견이 필수입니다.
Opus 5.5는 이전 버전 대비 성능 향상 및 소통 능력이 뛰어납니다.
에이전트 오케스트레이션(하위 에이전트 활용)을 통해 효율적인 개발이 가능합니다.
명확하고 측정 가능한 목표를 설정할 때 AI의 효과가 극대화됩니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 RSS: GeekNews (한국어)의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
일부 조언은 핵심을 놓치고 있음. 자주 쓰는 프롬프트에 “단계별로 생각해 봐”를 넣는 이유는, 그렇지 않으면 작업을 전체적으로만 검토해 단계별 접근에서 드러나는 문제를 놓치기 때문임. 계획을 세울 때도 작업을 하나씩 수행하는 과정을 따져보게 해야 비로소 2단계에 필요한 기능이 14단계에서 추가된다는 식의 작업 간 의존성을 발견하곤 함.
직접 확인해 보니 Opus 5.5에서도 여전히 해당됨. Fable과 어깨를 나란히 할 만큼 크게 개선됐고 서로 강점과 약점이 다르지만, 이 문제는 남아 있음. 사람도 마찬가지이며 계획 수립은 학습해야 하는 기술임.
글의 취지는 실행 환경이 더 이상 “think”라는 문자열을 검색해 추론 모드를 활성화하지 않는다는 것 같음. 알아둘 만하지만, 특정 방식으로 생각하라는 요청까지 효과가 없다는 뜻은 아님.
OpenAI와 다른 실행 환경을 쓰고 있는데, “커밋을 어떻게 나눌까?”라고 물은 뒤 “각 커밋마다 Luna 하위 에이전트를 써서 진행해 줘”라고 요청하는 방식이 꽤 효과적임. 예전에는 체크리스트가 들어간 계획 문서를 작성하게 했지만, 요즘은 이 정도로도 충분해 보임.
최근 며칠간 Opus에 CI를 빠르게 만들되 과금 시간과 실제 소요 시간을 모두 줄여 달라는 큰 방향만 제시함. CI 전체를 분석해 계획을 세우고, Fable 하위 에이전트의 검토를 받은 뒤 위험은 낮고 효과는 큰 변경에 집중하도록 했음.
9시간 뒤 병합 가능한 PR 12개가 준비됐고, CI 소요 시간은 약 10분에서 4분으로, 과금 시간은 약 60% 줄어듦. 내가 신경 쓴 시간은 1시간도 안 됨.
이번 주 이상한 일이 생길 때마다 확인해 보면 VSCode의 모델 선택이 “auto”로 돌아가 다른 모델이 작업 중이었음. 지금은 5.5로 지정해 둠. 내 용도에서는 Fable도 이보다 못하게 느껴짐.
보드게임 Terraforming Mars의 Discord 채팅에서 에이전트가 입력을 받아 게임의 오픈소스 구현을 바이브 코딩하도록 하고 있음. https://tfmbot.com에서 볼 수 있고, 첫 화면에 Discord와 소스 링크가 있음.
결과가 놀라울 정도여서 Discord에서도 “이렇게 잘 돌아가다니 놀랍다”는 반응이 나오며 나도 마찬가지임. 온라인에는 아직 이 변화를 따라잡지 못한 집단이 있는 듯함. AI 능력을 부정하는 글은 여전히 추천받지만, 업계에서 25년 넘게 일하며 인정받아 온 입장에서는 HN의 “AI는 멍청하다” 식의 조롱을 이해하기 어려움. AI가 다른 모든 개발 방식을 대체해 가고 있음.
이 작업이 특히 잘된 이유는 목표가 명확하고 측정 가능하기 때문이라고 봄. 나도 Opus 5.5로 점진적인 최적화를 해 봤지만, 평가 자체가 어려운 작업에서는 훨씬 많은 방향 조정이 필요함.
Opus 5.5는 성능도 뛰어나고 Claude Max 사용량도 효율적으로 쓰는 편임. 조잡한 글을 내놓던 Opus 5에 비하면 큰 도약임. 이전에는 Opus 5의 능력보다도 수수께끼 같은 의사소통 때문에 신뢰가 떨어져 오케스트레이션 작업을 Fable로 옮겼음.
5.5는 방향을 덜 잡아줘도 되고 소통도 잘함. 글에서 권하는 것처럼 지속 보존되는 계획을 두고 대화를 압축하면서 같은 CC 세션을 일주일째 사용 중임. 직접 만든 에이전트 오케스트레이션 시스템에서 antigravity, codex, pi 등 다른 코딩 에이전트의 작업을 관리하게 하는데, 판단과 제안이 대체로 괜찮음.
참고 이미지가 있을 때 프런트엔드 구현을 특히 잘함. 디자인 참고 이미지를 넣고 흐르는 듯한 SVG에 집중하라고 했더니 Star Trek 컴퓨터에서 영감을 받은 레이아웃을 훌륭하게 구현함. https://html.non.io/lcars-opus-5.5.
사용량 제한은 6.1 Sol 같은 OpenAI 모델과 비교하면 어떤가? 200달러 요금제 조건이 뒤집힌 뒤라 옮겨야 할지 모르겠는데, Anthropic은 전통적으로 OpenAI보다 사용량 제한이 빡빡했음.
체감상 제한은 6.1 Sol과 꽤 비슷함. 다만 하위 에이전트를 적극적으로 쓰는 성향 때문에 비교 결과가 달라질 수 있음. 눈에 띄는 차이는 초당 토큰 처리량이 여전히 6.1 Sol 쪽에서 훨씬 높다는 것임.
5보다 훨씬 낫지만, 이번 주에는 자율적으로 행동하려다 내 지침을 정면으로 어긴 일이 몇 차례 있었음. 자동 모드가 승인 범위를 크게 넘도록 만들기도 함. abz-1 리전에서 프로세스 X를 실행하도록 허용했더니 경고도 없이 다른 5개 리전에서도 실행하고, 요약에 적지 않은 변경까지 수행함.
이해하지 못한 시스템을 이해했다고 가정해 크게 잘못 판단한 적도 있음. 이름이 비슷한 별개 대상을 같은 것으로 여기고, 바로잡아 줘도 반박하기까지 했음. 지난주 일을 겪고 나니 장시간 자율 실행은 절대 맡길 수 없음.
반대로 내가 틀린 내용을 확신하고 있을 때, 시키지도 않은 증거를 찾아 내 잘못된 전제를 반박해 준 적도 있음.
Opus 5.5가 대단하다며 일화 하나씩 붙이는 판에 박힌 댓글이 왜 이렇게 쏟아지는 건가? 이게 제출된 글의 내용과 무슨 관련이 있는 건가?
모델은 놀랍지만, 권장하는 작업 방식을 Claude Code 실행 환경의 안내 절차로 넣어 주면 안 되는 이유를 모르겠음. 다른 방식으로 쓰고 싶은 사람은 무시할 수 있게 하면 됨.
이 회사는 자신들이 더 도덕적이고 무엇이 최선인지 안다고 여기는 이들이 운영하는데, 정작 Claude의 출력을 읽지도 않고 맹신하는 듯함. Linux 측에서 마침내 밝힌 Mythos의 Linux 커널 “해킹” 전말을 보면 눈이 뜨임.
최근 오래된 전자회로 시뮬레이션 프로젝트에서 매우 인상적이었음. 회로도가 포함된 옛 정비 매뉴얼 스캔 폴더를 건넸더니 회로를 정확하게 해석함. 그림이 크게 달라도 같은 회로 구조임을 알아냈고, 거의 똑같아 보이는 회로의 미묘하지만 결정적인 차이도 구별함.
제대로 읽지 못한 부분 회로나 부품값은 지어내지 않고 내게 확인을 요청함. 회로도에서 읽은 RC 필터의 차단 주파수가 매뉴얼의 대역폭 수치와 맞는지 등, 작은 시뮬레이션을 수없이 돌려 매뉴얼의 내용을 검증함. 함께 올린 IC 데이터시트 PDF도 교차 확인에 활용함.
한 시간 넘게 작업을 이어 갔고, 수동 확인이 필요할 때 핀 사이의 저항·커패시터·다이오드 연결을 말로 풀어 줘도 모두 정확히 이해함. 이상하다며 재확인을 요청한 경우에는 실제로 내가 회로도를 잘못 읽은 것이었음. 1940~1950년대 이론 자료 스캔에서도 수식을 정확히 읽고 논문끼리 대조하며 오탈자 여러 개를 찾아냄.
나는 PDF를 제공하고 가끔 회로도를 직접 해석해 준 것 외에는 거의 할 일이 없었음. Claude 5.5 High로 월 20달러 구독의 주간 사용량 약 50%를 썼지만, 사용량 최적화는 별로 시도하지 않음. 일부 데이터시트에는 Sonnet 5.5 Medium도 써 봤는데 추출은 매우 잘했지만 결론을 더 자주 수정해야 했음.
CC에서 완료되지 않는 훅 같은 것 때문에 하루 내내 대기 상태에 갇히거나, 고아 프로세스를 기다리며 작업이 멈춘 적이 있음. 오래 걸리는 프로세스의 상태 확인에 쓰는 토큰 비용은 줄일지 몰라도, 장시간 작업을 믿고 맡기기는 어려워짐.
반면 내 컴퓨터에서 무거운 빌드 여러 개가 메모리 부족으로 실패하지 않도록 관리하는 능력은 훌륭함. 큐와 잠금을 추가해 성능 측정을 다른 작업과 격리하고, 실험 중 GPU에 다른 부하가 끼지 않게 해 줌.
하위 에이전트 작업을 한꺼번에 실행하는 능력도 GPT 6.1보다 훨씬 나음. 서로 겹치기도 하고 무관하기도 한 하위 작업 10개를 동시에 줬더니, 격리된 작업 트리와 에이전트를 띄우고 결과를 다시 병합한 뒤 에이전트들로 묶어서 검증하는 과정까지 잘 처리함.