Hacker News 의견들

• 요즘 나오는 LLM 프레임워크들이 오히려 개발을 더 어렵고 비싸게 만드는 느낌임
  기본 설정만으로도 충분히 멀리 갈 수 있는데, 모델이 계속 바뀌는 상황에서 수많은 래퍼와 하네스를 만드는 건 비효율적이라 생각함
  밤새 돌려놓고 돈 태우는 이런 방식은 나중에 PHP 밈처럼 웃음거리로 남을 것 같음

  • AI 붐 속에서 삽 파는 사람 입장이라면 얘기가 다름
    기사에 따르면 “지난 6개월간 100명 넘는 엔지니어에게 Claude Code 워크숍을 진행했다”고 함
  • 경쟁사들이 코드베이스에 AI 에이전트를 최대한 많이 쓰길 바람
    밤낮없이 돌리다가 결국 AI 회사가 파산하고, 남은 건 80%가 AI가 짠 스파게티 코드뿐일 때 누가 웃을지 보겠음
  • PHP를 비웃을 일은 아님. 지금도 내 최고의 프로젝트 중 일부는 PHP로 만들어졌음
    요즘의 풀스택 JS/TS 환경보다 15년 전 PHP로 만든 게 더 나았다고 느껴짐
  • 예전의 anti-PHP 밈이 얼마나 어리석었는지 이제야 보임
    PHP는 여전히 살아 있고 발전 중임. LLM 툴링도 결국 그런 식으로 기본 도구가 될 것임
  • 이건 단순히 일이 늘어난 게 아니라 역할의 융합임
    BA, PO, QA, SWE의 경계가 흐려지고 있음. 이제는 비즈니스와 개발의 중간에 있는 하이브리드 역할이 생겨나고 있음

• 사람들은 요즘 에이전트를 그냥 써보는 게 목적이 된 것 같음
  나는 글쓰기용, 리뷰용 두 개만 돌리는데도 생산성 5~7배는 충분함
  스펙 검토에 시간을 더 쓰고, 코딩은 에이전트가 10~30분이면 끝내서 급할 게 없음

  • “밤새 돌리는 에이전트” 개념은 이해가 안 됨. Claude는 대부분 5~20분이면 끝남
    내일도 일은 계속 있으니 굳이 밤새 돌릴 이유가 없음
  • 나도 처음엔 여러 에이전트를 병렬로 돌렸지만, 결국 한 디렉토리 단위로 집중하는 게 훨씬 효율적이었음
  • SWE가 하던 일 중 상당 부분을 이제는 AI가 brute force로 처리할 수 있음
    고객 입장에서는 인도, 샌프란시스코, AI 중 어디서 버그가 오든 큰 차이 없음
  • 나도 두 개의 에이전트만 돌리며 미세 조정을 많이 함
    요즘 유행하는 ‘에이전트 오케스트라’보다는 훨씬 통제된 방식임
  • 스펙 검증이 가장 중요한 단계라 생각함
    그래서 Claude가 스펙을 잘 따르는지 확인하려고 verify 스킬을 직접 만들었음

• Claude에게 red-green-refactor 패턴을 쓰게 하면 확실히 테스트 품질이 올라감
  더 나아가 red/green/refactor 서브에이전트를 만들어 서로 검증하게 하면 꽤 잘 작동함
  핵심은 컨텍스트를 섞지 않는 것임

  • 하지만 리팩터링이 진행되면 테스트가 쓸모없어지거나 빠지는 경우가 많음
    reward hacking이 실제로 존재하며 방어하기 어려움
  • red/green TDD를 시켜도 실패하지 않는 테스트를 써놓고 “이미 해결됨”이라며 넘어감
    이 가이드를 참고해도 여전히 나쁜 테스트 문제가 큼
  • 나는 Outside-in TDD를 Claude Code에 완전히 적용했음
    결과가 좋아서 원리와 예제와 starter repo를 공개했음
  • green/red/refactor 패턴 구현법을 더 자세히 알고 싶음. 참고 자료가 있으면 좋겠음
  • PR 리뷰에도 이 접근이 효과적임
    작성자와 검증자 분리가 중요하며, 같은 모델이라도 컨텍스트를 분리하면 품질이 올라감

• 현재 LLM의 컨텍스트 한계 때문에 진짜 에이전트는 아직 불가능함
  500줄 이상 코드에서는 오류가 급격히 늘고, 200줄 정도가 한계임
  결국 LLM은 계산기처럼 반복적으로 사용해야 하는 도구에 불과함

• 나는 이 현상을 “Test Theatre”라 부름
  관련 글을 여기에 썼음. 적극적으로 피해야 함

  • 에이전트가 100줄 코드에 600줄 테스트를 쓰기도 하지만, 대부분 의미 없는 테스트임
    좋은 테스트는 디자인 패턴과 의존성을 검증하고, 디버깅에 도움을 줘야 함
  • property testing을 활용하면 훨씬 나은 결과를 얻음
    예를 들어 Schemathesis로 사용자 권한이나 5xx 응답 여부를 자동 검증함
  • Test Theatre는 정확한 표현임. 테스트가 통과해도 실제로는 아무것도 증명하지 않음
  • 가장 좋은 방법은 Outside-in TDD + mutation testing을 강제하는 것임
    관련 POC를 여기에 올려둠
  • 사실 이런 형식적인 테스트는 예전부터 있었음. 대부분 구현 자체를 테스트함

• 최근 에이전트 오케스트레이션을 실험 중임
  핵심은 LLM 호출을 줄이고 결정적 스크립트 파이프라인으로 연결하는 것임
  자세한 내용은 이 글에 정리했음

  • 나도 비슷하게 스크립트 중심 오케스트레이션을 시도 중임
    이 실험 기록처럼 LLM보다 스크립트가 핵심임

• 나는 비즈니스 운영용 에이전트 6개를 돌리고 있음
  시장 조사, 콘텐츠 작성, 영상 스크립트 등 다양한 역할을 맡김
  “밤새 돌리기”는 과장된 개념이고, 실제로는 명확한 목표와 좁은 범위가 효과적임
  진짜 병목은 실행이 아니라 컨텍스트 관리임

  • 흥미로운 접근임. 어떤 제품을 만들고 있는지, Reddit 기반 리서치가 여전히 유효한지도 궁금함

• 이 사람이 실제로 뭘 만드는지 모르겠음
  LinkedIn에 Claude 관련 글만 보임

  • 검증도 못 하는 코드를 배포한다는 건 심각한 리스크임
    진지한 비즈니스라면 상상도 못 할 일임
  • 25년 업계 경험상, 이렇게 빠른 속도로 코드가 필요한 회사는 없었음
    결국 팔 방법을 고민하느라 코드가 놀게 됨

• 테스트만 쓰는 사람을 고용했을 때와 같은 문제임
  결국 “코드가 코드대로 동작한다”는 걸 확인할 뿐임
  명확한 스펙 정의가 훨씬 중요함

  • 사후 테스트는 대부분 동어반복 검증임
    다른 공학 분야는 이런 실수를 반복하지 않는데, 소프트웨어만 유독 그렇다는 게 놀라움
  • 테스트의 진짜 가치는 회귀 방지에 있음
    초기 릴리스가 틀렸더라도, 이후 동작이 바뀌지 않도록 보장함
  • 테스트의 목적은 결국 mock 검증임
  • 스펙을 먼저 정의하고 그에 맞춰 검증하는 게 핵심임
    많은 컨설팅 회사들이 acceptance criteria 기반 검증으로 일함

• 지금의 AI는 개발을 돕는 도구가 아니라 개발자를 대체하는 수준에 도달함
  우리가 더 이상 코드를 통제하거나 검증하지 못하는 건 심각한 문제임
  이건 새로운 개발 방식이 아니라 이해 대신 신뢰에 의존하는 종교적 전환처럼 느껴짐

  • 나는 이해하지 못한 코드는 절대 배포하지 않음
    자율성이 낮더라도 검증 가능한 코드만 머지함
  • 혹은 형식 검증(formal methods) 같은 도구로 코드 보안을 보장하는 방향이 필요함