▲

Opus 4.5는 지금까지 경험한 AI 에이전트와는 전혀 다르다

 (burkeholland.github.io)
18P by GN⁺ 2일전 | ★ favorite | 댓글 3개
  • Claude Opus 4.5는 기존 AI 코딩 에이전트와 달리, 개발자의 개입 없이도 완성도 높은 애플리케이션을 구축할 수 있는 수준의 자율적 개발 능력을 보여줌
  • 단순한 Windows 이미지 변환 유틸리티부터 영상 녹화·편집 도구, AI 기반 게시 자동화 앱, 주문 추적 및 경로 계산 앱까지 실제 동작하는 프로젝트를 단시간 내 완성함
  • Opus 4.5는 Firebase 백엔드 구성, 에러 로그 분석 및 자동 수정, GitHub Actions 배포 설정 등 복잡한 개발 작업을 스스로 처리함
  • 작성자는 코드 구조를 완전히 이해하지 못하지만, Opus 4.5가 버그를 스스로 해결하고 리팩터링 제안까지 수행함을 확인함
  • 이 경험을 통해 AI가 개발자를 완전히 대체할 수 있는 가능성이 현실화되고 있으며, AI 중심 개발 시대의 전환점임을 강조함

Opus 4.5의 등장과 기존 AI 에이전트와의 차이

  • 기존 AI 에이전트는 종종 비효율적 코드 생성과 반복적 오류 수정으로 인해 생산성이 낮았음
    • 여러 차례의 복사·붙여넣기와 오류 수정 끝에 코드베이스가 손상되는 경우가 많았음
  • Opus 4.5는 이러한 문제를 극복하고, 처음부터 대부분의 코드를 정확히 작성하며, 오류 발생 시 CLI를 통해 직접 빌드·수정을 반복함
  • 작성자는 이를 “AI 코딩의 약속이 실제로 실현된 모델”로 평가함

프로젝트 1 – Windows 이미지 변환 유틸리티

  • Opus 4.5는 Windows 탐색기 우클릭 메뉴에서 이미지 포맷 변환 기능을 가진 유틸리티를 한 번의 요청으로 완성함
    • dotnet CLI를 사용해 빌드 및 오류 수정 과정을 자동화
    • XAML 오류만 Visual Studio로 확인 후 복사해 전달
  • 배포용 웹사이트, PowerShell 설치 스크립트, GitHub Actions 자동 배포 파이프라인까지 구성
  • 로고 제작은 Figma AI를 사용했으며, Opus가 SVG 변환 및 아이콘 포맷 스크립트를 작성함

프로젝트 2 – 화면 녹화 및 편집 도구

  • LICEcap과 유사한 GIF 녹화 유틸리티를 시작으로, 영상·이미지 편집 기능까지 확장
    • 도형 추가, 자르기, 블러 처리 등 편집 기능을 몇 시간 만에 구현
  • 소스 코드는 GitHub에 공개되어 있으며, 작성자는 “몇 시간 만에 상당한 수준까지 개발”했다고 언급
  • Opus 4.5가 UI뿐 아니라 백엔드 통합 작업도 수행할 수 있음을 확인함

프로젝트 3 – AI 게시 자동화 앱

  • Facebook 페이지에 자동으로 게시물을 올리는 AI 기반 모바일 앱을 Opus 4.5로 개발
    • 사진 업로드 후 AI가 캡션 생성 및 예약 게시 수행
    • Firebase 백엔드, 인증, 스토리지, 클라우드 함수를 Opus가 CLI로 직접 구성
  • 작성자는 블라인드를 설치하는 동안 Opus가 앱을 완성했다고 설명
  • Opus는 에러 로그를 자동 분석해 수정, 관리용 대시보드까지 생성
  • 기존에 수개월 걸리던 작업을 몇 시간 내 완성함

프로젝트 4 – 주문 추적 및 경로 계산 앱

  • Gmail 주문 메일을 파싱해 일정·경로·운전 시간·세금용 주행 기록을 자동 계산
  • Opus 4.5가 Google 인증 통합 및 Firebase 연동을 한 번에 처리
  • 작성자는 “수작업으로는 고통스러운 작업을 Opus가 완벽히 수행했다”고 평가

코드 이해와 품질 문제

  • 작성자는 자신이 Swift를 모름에도 앱이 완벽히 작동함을 언급
  • Opus 4.5는 스스로 버그를 찾아 수정하며, 작성자는 코드 내부 구조를 몰라도 문제없이 개발 진행
  • 코드 품질에 대한 의문에 대해, “AI가 읽고 유지보수할 코드라면 인간 가독성은 중요하지 않다”고 서술
  • VS Code 내 AI 전용 코드 작성 프롬프트를 사용해, LLM이 이해하기 쉬운 구조 중심 코드를 생성

AI 중심 코딩 원칙

  • 프롬프트는 “AI가 작성·유지보수할 코드”를 전제로 함
    • 단순한 구조, 명확한 진입점, 최소한의 추상화, 낮은 결합도를 강조
    • 명시적 제어 흐름, 간단한 함수, 구조적 로깅, 재생성 용이성을 중시
  • 코드 리팩터링 시 Opus가 우선순위별 개선 항목(상·중·하) 을 문서로 정리
  • 보안 점검 시 API 키, 로그인 처리, 민감 데이터 저장 여부를 검토하도록 요청
    • 작성자는 보안 완전성에 대해 “약 80% 수준으로 아직 불안하다”고 언급

AI 개발 시대의 전환

  • 작성자는 “몇 시간 만에 만들 수 있는 현실에 흥분과 허무함이 공존한다”고 표현
  • 과거에는 “AI가 개발자를 대체할 수 없다”고 믿었으나, 이제는 그 가능성을 부정할 수 없다고 인정
  • 결론적으로, AI 중심 개발 환경에서 주저하지 말고 직접 만들어보라고 강조
  • 마지막으로 “API 키 관리만은 스스로 책임져야 한다”고 경고

요약: Opus 4.5는 단순한 코드 보조를 넘어, 완전한 애플리케이션을 자율적으로 설계·구현·배포할 수 있는 AI 개발자 수준의 모델로 평가됨. 작성자는 이를 통해 AI가 인간 개발자를 대체할 수 있는 현실적 가능성을 직접 체험했다고 밝힘.

▲
wegaia 1일전  [-]

Opus 4.5에게 한줄의 코드를 고치라고 했더니 그 코드 위에 있던 설정 코드 10줄 정도를 맘대로 지우는걸 보고 그걸 왜 지웠냐니까 그냥 무의미한 코드인거 같아 지웠다고..

답변달기
▲
GN⁺ 2일전  [-]
Hacker News 의견들

  • 중간 수준의 엔지니어가 맡는 일은 단순히 새 앱을 만드는 게 아니라, 확장성과 이해 가능성을 고려한 구조를 설계하는 일임
    Opus 4.5가 “앱 하나 만들어줘” 수준의 요청은 잘 처리하지만, 실제 업무처럼 기존 코드에 기능을 추가하려 하면 이상한 추상화를 쓰거나 여러 번 수정해야 원하는 품질이 나옴
    비기술자는 “작동하면 됐지”라고 생각하겠지만, 엔지니어는 그게 충분하지 않음을 앎

    • ‘올바른 방식’에는 두 가지가 있음 — 맥락에 맞는 방식과 엔지니어들이 일반화해 생각하는 방식임
      예전에 팀에서 “정답”을 두고 싸우던 기억이 있음. 결국 외부인이 와서 비즈니스 관점에서 중요한 게 뭔지 상기시켜줘야 했음
      때로는 지저분하게라도 빨리 만들어서 방향이 맞는지 검증하는 게 진짜 ‘올바른’ 방법일 때도 있음
      문제는 처음부터 과도하게 설계하거나, 반대로 관리자가 리팩터링을 막을 때 생김. 결국 균형이 핵심임
    • 이런 프로젝트를 보면, GitHub에 있는 이미지 변환기나 지뢰찾기 클론을 그냥 포크하면 될 텐데 굳이 LLM이 하는 건 저작권 제거용으로밖에 안 보임
    • 어떤 사람들은 “코드 품질은 이제 중요하지 않다”고 주장함. 오늘 테스트만 통과하면 충분하고, 내일 전체 리팩터링이 필요하면 크레딧 좀 더 써서 몇 시간 만에 다시 만들면 된다는 식임
    • 나는 Opus 4.5가 기존 코드베이스의 관용적 패턴을 잘 따라가는 걸 보고 놀랐음
      인접한 코드를 읽게 명시적으로 지시하면 훨씬 잘 작동함. 단 한두 문장만 추가해도 충분함
    • 기존 코드에 기능을 추가할 때 원하는 추상화를 직접 지시하면 점진적으로 잘 작동함
      그래도 개인적으로는 GPT‑5.2를 더 선호함

  • 많은 엔지니어들이 Claude Code 같은 LLM 에이전트의 현재 성능을 과소평가하고 있음
    우리 팀은 Claude Code로 코드 리뷰, ESLint 자동화, PR 체크리스트, 문서 동기화, 테스트 커버리지 점검까지 자동화했음
    티켓 분류도 자동으로 처리해서 엔지니어가 작업을 시작할 때 이미 절반은 끝나 있는 상태임
    예시 저장소는 claude-code-showcase에 있음
    2026년쯤이면 이게 업계의 표준 워크플로우가 될 거라 확신함

    • 프런트엔드(React, HTML, 모바일)와 저수준(OpenGL, io_uring, libev 등) 영역의 LLM 활용 경험 차이가 큼
      Opus 4.5는 JS 앱은 잘 만들지만, C++로 2003년 논문의 그림자 알고리즘을 구현하라 하면 완전히 엉망임
      Fabien Sanglard의 Doom3 BFG 스레딩 리뷰까지 먹여도 쓸모없는 코드만 나옴
      결국 “우리가 LLM을 과소평가하는 게 아니라, 아직 실용적이지 않아서 기다리고 있는 것”임
    • 많은 사람들이 초기에 AI 코딩을 시도했다가 에러와 좌절로 포기했음
      하지만 Opus 4.5는 한 단계 위임. 오류가 훨씬 적고 대부분 사소한 실수 수준임
    • 대학에서 학생들을 가르치며 Cursor, Claude Code, Codex를 실험했는데,
      AI 덕분에 2주 걸릴 프로젝트를 5시간 만에 완성했음.
      AI가 없었다면 아예 시도조차 못 했을 것임
    • AI가 만든 README에 굳이 디렉터리 구조를 적는 게 웃김. tree 명령어면 다 나오는데
    • 앞으로는 “프로그래머”라는 직업 자체가 줄어들고, 도구를 활용해 창조하는 능력이 더 중요해질 것 같음

  • Opus 4.5를 많이 써봤는데, 복잡한 코드 분석에는 탁월하지만 여전히 인간 수준의 문제 해결력은 아님
    예를 들어 그래프 레이아웃 알고리즘을 정확히 식별하지만, 그 오류를 스스로 고치지는 못함
    코드 분석과 지식 보강에는 훌륭하지만, 복합 문제 해결은 아직 무리임

    • Copilot이 토큰 절약을 위해 문맥을 잘라내는 구조라서 한계가 있음
      진짜 성능을 원하면 API를 직접 써야 하고, PR 하나에 세 자릿수 비용이 들 수도 있음
      참고: models.dev
    • Copilot이 Opus 4.5 사용 시 토큰을 3배로 계산하는데, 한 달 할당량 절반을 일주일 만에 쓴 건 놀라움
    • AI를 코드 분석 도구로만 써도 가치가 큼
      문서 생성도 인간보다 낫고, 오류율도 인간보다 낮은 편임
    • 서드파티 도구를 통해 쓰면 동작이 다름
      Claude Code 구독으로 VS Code나 Cursor에서 직접 써보길 권함

  • 휴일 동안 GPT‑5.x로 여러 프로젝트를 진행했음 —
    Swift 자동화 도구, ARM JIT 엔진 통합, 신시사이저 프로토타입 등
    GPT‑5.2와 Codex 계열은 Opus만큼 강력하며, CI 워크플로우 전체를 한 번에 구성할 정도임
    나처럼 계획을 세우고 코드를 검토하는 습관이 있는 사람에게는 생산성 배가 도구임

    • GPT‑5.2가 CLI 유틸리티의 존재나 기능을 환각(hallucination) 하는 경우가 많았음
      실제 소스코드를 뒤져봐야 오류를 확인할 수 있었음
    • Gemini 3 Pro (High) 와 Antigravity, Amp, Junie 같은 도구도 인상적이었음
      Ruby용 Ratatui 바인딩 라이브러리를 2주 만에 완성했음
      Antigravity는 여러 에이전트를 병렬로 돌려 문맥 압축과 자동 관리를 수행함
      이런 고급 툴은 무료 버전과 완전히 다른 경험을 줌
      Unix 도구와 git CLI를 함께 쓰면 문맥을 작게 유지해 효율이 극대화됨
    • LLM은 백엔드·CLI 코드엔 강하지만, HTML/CSS나 JS 프런트엔드처럼 시각적 피드백이 필요한 영역에서는 여전히 약함
      구조화된 입력·출력에는 강하고, “감각적 완성도”가 필요한 부분에서는 실패함

  • 최근 HN에서 LLM 관련 부정적 댓글이 급감한 걸 느꼈음
    하지만 대부분의 공유 프로젝트는 기술 데모 수준에서 멈춤
    맥락을 쌓는 일, 즉 사용자 요구를 이해하는 일은 여전히 인간의 몫임
    앱을 주말에 여러 개 만들 수는 있어도, 유지보수할 사람은 거의 없음

    • 부정적 댓글이 줄어든 건, 반복되는 “새 모델 1000배 향상” 논쟁에 지친 사람들 때문일 수도 있음
    • 수익화 가능한 제품을 만드는 사람들은 조용히 개발 중이라 공유를 안 하는 것일 수도 있음
    • 프로덕션 배포와 유지보수는 막대한 노력이 필요함
      Karpathy도 비슷한 경험을 공유했음 — 프로토타입은 쉬워도 배포는 어렵다는 것
      개인용 도구라면 완성도보다 문제 해결 중심으로 접근해도 충분함
    • AI를 쓰는 사람일수록 마지막 20%의 통합적 사고가 필요한 구간에서 막힘
      사고를 AI에 맡기면 스스로 생각하는 힘이 약해짐
    • 게임 개발에서도 80/20 법칙이 그대로 적용됨
      아이디어 테스트까진 빠르지만, 완성도 있는 제품까지 가는 건 여전히 인간의 인내가 필요함

  • Opus 4.5는 단순한 지식보다 자율적 문제 해결 능력이 크게 향상됨
    명확히 정의된 문제라면 거의 다 해결했고, 리버스 엔지니어링까지 수행했음
    최근엔 직접 코딩하기보다 사양을 작성하고, Opus가 실행·개선하도록 지휘하는 식으로 일함

    • 공개한 예시로는 coding-agent-benchmark와
      C64 게임 리버스 엔지니어링 프로젝트가 있음
    • “과도한 설계”를 막는 방법이 궁금함
    • 나는 Claude 웹앱을 러버덕 디버깅용으로 쓰는 게 효율적임
      Claude Code는 코드베이스 전체를 볼 수 있어 강력하지만, 쿼터 소모가 너무 빠름
      그래서 웹 버전으로 돌아왔음
    • 나도 최근 사이드 프로젝트를 거의 이런 방식으로 진행 중임

  • Opus 4.5로 Python 기반 JavaScript 인터프리터, WebAssembly 런타임, Rust 문자열 검색 루틴의 C 포팅까지 시도했음
    대부분 스마트폰에서 실험했는데 놀라운 결과였음

    • “Python으로 작성된 JS 인터프리터”가 Bellard의 MQJS 기반이라면, 그 출처를 명시해야 함
      참고: micro-javascript
    • 시각적 추론이 필요한 문제(예: 슬라임 몰드 경로 알고리즘)에서는 여전히 약함
    • “Rust 루틴을 C로 포팅해 더 빠르게 만들었다”는 결과가 궁금함
    • “JavaScript로 Python 3 인터프리터를 작성하라” 했더니 테스트까지 통과시켜서 놀랐음
    • 하지만 최근엔 큰 차이를 못 느꼈음. 모델은 정체, 대신 에이전트 프레임워크가 발전한 듯함
      예시 영상: Mastodon 링크

  • 개발자가 진짜로 고용되는 이유는 책임감임
    StackOverflow나 GitHub에서 코드를 복사하던 시절에도 도구는 있었지만,
    문제 발생 시 책임지는 건 결국 사람임

    • 요즘은 책임을 질 수 있는 사람이 가장 중요한 존재임
      신뢰할 수 있는 동료가 AI 코드에 자신의 이름을 걸 수 있다면 괜찮음
    • 하지만 업계는 책임보다 새로운 것 만드는 사람을 더 보상함
      유지보수는 소홀히 다뤄짐
    • 이제는 실시간 코드 리뷰가 기본 모드가 됨
      주말에 SaaS의 80%를 AI로 만들고 핵심만 직접 작성했음
      22년 전 작성한 언어 사양을 붙여 넣자 Opus가 3분 만에 파서와 테스트를 완성했음
      우리는 결국 채굴 산업처럼 변화에 적응해야 하는 시점에 있음
    • 그래서 나는 AI를 작성자보다는 편집자·리뷰어로 쓰는 게 더 편함
      코드는 내가 쓰고, AI는 문제 탐색과 테스트 제안을 맡음

  • Opus 4.5가 나를 도와 새로운 프로그래밍 언어를 만드는 중임
    저수준 구현까지 논의하며, 마치 페어 프로그래밍처럼 협업함
    하지만 대규모 코드베이스에서는 여전히 인간의 시스템적 통제력이 필요함
    그렇지 않으면 Opus가 사양을 바꾸거나 임시방편으로 덮어버림
    이건 만능은 아니지만, 내 인생에서 가장 생산적인 해가 될 것 같음
    동시에, 이런 기술이 보편화되면 소규모 웹 커뮤니티의 부활도 기대됨

    • 언젠가는 AI가 스스로 코드를 유지보수할지도 모르지만,
      그 전까지는 사람이 이해하기 쉬운 언어가 더 중요하다고 생각함
    • “그런 걸 만드는 게 과연 의미 있냐”는 회의적인 시선도 있음
    • “그 소설을 누가 사겠냐”는 농담 섞인 반응도 있었음

  • Opus 4.5에게 “프로젝트 전체를 개선하라”고 맡겼더니 엉뚱한 아키텍처와 수많은 버그가 생김
    테스트나 버그 탐지엔 훌륭하지만, 전체 구조 설계는 맡기면 후회함

    • 대신 “개선 아이디어를 제안하라”고 시키고, 그중 괜찮은 걸 골라 Claude에게 설명받은 뒤 구현시키는 게 효율적임
    • “무엇을 개선할지” 명확히 알고 있을 때 가장 잘 작동함
      “아무거나 개선해봐”는 최악의 프롬프트임
    • 이런 사례는 모델의 약점을 드러내는 좋은 예시임
      예전에 누군가가 에이전트에게 밤새 개선시키다 10만 줄의 쓰레기 코드를 얻은 사례도 있었음
      그래서 계획 기반 개발이 중요함
      참고: The Highest Quality Codebase
    • Opus를 포함한 대부분의 모델이 기존 코드 개선에는 약함, 새 코드 작성은 잘함
    • AI의 코드 리뷰 제안 중 90%는 쓸모없지만, 나머지 10%는 진짜 문제를 잡아줌
      무한 루프처럼 계속 수정 제안을 내놓을 수도 있을 것 같음
답변달기
▲
ioas0316 1일전  [-]

기능은 점이다. 사고한계를 벗아나지못하면 기계적도구에서 벗어날수가 없다. 개발자를 대체한다하는데 대체가능한건 기술개발자뿐이다

답변달기