Hacker News 의견들

• 최근 내 취미 프로젝트에 “vector search 추가”만 요청했는데, Opus가 manticore를 설정하고, 임베딩 모델을 가져오고, 기존 키워드 인덱스를 마이그레이션하는 도구를 만들고, 프론트엔드까지 구성해줬음
  트윗 한 줄짜리 프롬프트였는데 15분 만에 완성되었고, 나는 그동안 Kirby Air Riders를 하고 있었음
  다만 이 과정을 통해 vector search 구축에 대해 아무것도 배우지 못했다는 점이 아쉬웠음. 결국 기능 자체가 목적이었고, 학습은 부차적인 일이었음
  • 굳이 오래 걸리는 방식으로 만드는 게 더 효과적인 학습법이라고 생각하지 않음
    4시간을 들여 직접 만들기보다, 에이전트가 15분 만에 만들어주는 동안 다른 일을 하고, 이후 30분 정도 코드를 읽고 수정하며 질문하는 게 훨씬 효율적임
    집중된 30분의 학습이 4시간의 시행착오보다 더 나을 수도 있음
  • 하지만 그렇게 하면 결국 유지보수 불가능한 거대한 코드 덩어리가 생김
    AI도 어느 순간 코드의 구조를 잃어버리고, 결국 Opus에 종속된 고객이 되어버림
  • Opus나 Anthropic은 확실히 최고 수준이지만, 사용할 때마다 지적 패스트푸드처럼 느껴짐
    예전엔 음악 들으며 Scala로 문제를 푸는 과정이 즐거웠는데, 이제는 너무 쉽게 결과만 얻는 게 오히려 허무함을 줌
  • “기능을 원했지, 만드는 법을 배우고 싶진 않았다”는 말에 완전히 공감함
    나도 거래 모델을 만들 때 차트를 직접 배우기보단 LLM이 코드를 대신 써주길 원함
    덕분에 사소한 API 처리에 시간을 낭비하지 않고, 진짜 의사결정이 필요한 부분에만 집중할 수 있음
  • 그 vector search 코드, 혹시 공유 가능한지 궁금함
• “긴 작업(long task) ” 개념을 직접 겪기 전엔 잘 몰랐음
  Python HTML5 파서를 JavaScript로 포팅하면서 Codex CLI를 9,200개의 html5lib-tests에 돌려봤는데, 4시간 넘게 루프를 돌며 문제를 해결하는 걸 보는 게 인상적이었음
  관련 글은 여기에 정리했음
  • METR의 “4시간 작업”은 AI가 실제로 4시간 걸린다는 뜻이 아니라, 인간이 4시간 걸릴 난이도를 의미함
    Opus 4.5는 이런 수준의 작업을 50% 신뢰도로 수행할 수 있다는 뜻이며, 실제 실행 시간은 훨씬 짧음
    앞으로 8시간, 40시간 같은 기준을 넘기면 더 흥미로워질 것임
  • 이 지표는 AI의 실제 속도가 아니라 인간 기준 난이도를 측정하는 것임
    벤치마크는 빠르게 깨지만, 실제 업무 자동화는 여전히 어렵다는 점을 잘 보여줌
  • METR의 “human hours equivalent”는 ‘어떤 인간’을 기준으로 하느냐가 중요함
    jq나 PyPI 생태계, TypeScript 주석 등에 익숙한 사람이라면 훨씬 빨리 끝낼 수도 있음
    결국 AI의 매력은 이런 전문가 수준의 도움을 즉시 받을 수 있다는 점임
  • 그런데 Codex나 Claude code로 긴 작업을 돌리면 권한 요청이 너무 자주 뜨고, 중간에 멈추는 경우가 많음
    대부분의 모델이 “다음 단계로 넘어가자”고 말하며 스스로 중단함
  • GPT5.2는 특히 사용자 입력을 과도하게 요구해서, 2분 이상 연속 작업을 시키기가 어려움
    혹시 이 문제를 해결한 방법이 있는지 궁금함
• 모델에 대한 평가는 조심스럽지만, Opus 4.5와 Sonnet 4.5의 차이는 확실히 느껴졌음
  예전보다 가격 차이도 줄어서 실사용 가치가 높아졌고, Haiku 4.5도 reasoning을 켜면 꽤 쓸 만함
  작은 도구나 단일 페이지 편집에는 특히 적합함
• 소프트웨어 학습은 탐색(exploration) 과 활용(exploitation) 두 단계로 나뉜다고 생각함
  LLM 덕분에 이 두 단계가 자연스럽게 결합됨
  예를 들어 AnimeJS 애니메이션을 만들 때, CCAgent가 코드를 작성하는 과정을 보며 배우고, 이후 직접 구조화하고 리팩터링함
  이렇게 하면 시간 절약과 창의적 통제를 동시에 얻을 수 있음
• Opus는 GPT 5.1보다 큰 도약처럼 보이지만, 80% 신뢰도 기준에서는 여전히 GPT 5.1이 우세함
  즉, 짧은 작업엔 GPT 5.1, 긴 작업엔 Opus가 더 적합함
  • 50% 성공률로는 비싼 토큰 낭비가 크지만, 내년쯤엔 오픈소스 모델도 이 수준에 도달할 것이라 기대함
• METR의 핵심은 ‘인간 등가 시간’ 을 기준으로 복잡도를 측정한다는 점임
  50% 성공률로 4시간짜리 작업을 맡기면 사실상 도박에 가깝고, 실패 시 디버깅까지 하면 손실이 큼
  그래서 30분 단위로 인간 검토 체크포인트를 두는 게 좋다고 생각함
  다만 AI가 중간에 막혔을 때 스스로 복구할 수 있는 능력도 중요함
  • 하지만 30분 동안 AI가 만들어내는 결과물이 너무 많아서 검토가 악몽 수준임
    겉보기엔 멀쩡하지만, 나중에야 드러나는 미묘한 버그가 많음
    그래서 중요한 작업에는 아직 에이전트를 쓰지 않음, 오히려 일의 즐거움을 빼앗기 때문임
  • 4시간을 허비했다고 해도, 그 시간 동안 다른 일을 했다면 손해는 아님
    절반의 확률로 결과를 얻는다면, 시간 대비 효율적인 베팅일 수도 있음
  • 실패해도 실제로 잃는 건 AI가 작업한 몇 분뿐이라, 프로토타입 탐색용으로는 훌륭함
    여러 시도를 빠르게 해볼 수 있고, 실패에서도 배움이 있음
• 95%나 99% 신뢰도 기준의 그래프도 필요함
  그래야 LLM이 여전히 인간이 쉽게 하는 일에서 왜 자주 실패하는지를 더 명확히 볼 수 있음
• 성능 최적화는 AI의 실질적 지능을 측정하기 좋은 벤치마크라고 생각함
  결과를 수치로 검증할 수 있고, 코드가 짧을수록 좋으며, 단순한 조합이 아닌 시스템적 사고가 필요함
  지금까지는 Gemini Pro 3가 SIMD 코드 최적화에서 가장 뛰어났음
• 50% 성공률의 문제는 재시도 시 확률이 급격히 떨어진다는 점임
  4시간짜리 작업을 여러 번 반복하면 성공 확률이 6.25%까지 떨어짐
  • 다만 “운이 나쁘다”기보단, 한 번 실패한 작업은 다음 시도에서 성공 확률이 달라질 수도 있음
    작업 성격에 따라 다름