Hacker News 의견들

• 세션을 명확하고 실행 가능한 작업 단위로 나누는 게 핵심임
  너무 세세한 지시를 주면 LLM을 쓸 이유가 없고, 반대로 “개를 위한 Facebook 앱 만들어줘”처럼 너무 광범위하면 쓸모없는 프로토타입만 나옴
  결국 성공적인 코드용 LLM 활용은 이 적정 범위를 찾는 일임

  • AI 도구를 쓸 때 가장 즐기는 부분이 바로 이 직관 형성임
    어떤 작업을 맡기면 좋은 결과가 나오는지 감을 잡고, 그에 맞게 범위를 조정하는 과정이 프로그래밍의 모듈화와 비슷한 즐거움을 줌
  • “Facebook for dogs” 예시처럼 너무 큰 요청을 줬다가 실패했음
    Lovable에서는 온보딩부터 실패를 유도하는 느낌이었고, 대신 Claude Code로 작게 쪼개서 진행하니 훨씬 성공적이었음
  • LLM을 단순히 for 문법 예시 찾는 용도로 쓰면 컨텍스트 전환을 줄일 수 있어서 편함
    초기에는 이런 단순한 코드 작성 보조로 많이 활용했음
  • 모델이 발전할수록 그 적정 범위의 상한선이 6~8주마다 올라가는 느낌임
  • 가끔 “출력을 출력해줘”라고 말했더니 정말로 print(output)만 추가하는 식으로 반응함
    자연어와 코드 사이를 오가며 작업하는 게 오히려 심리적으로 편하게 느껴짐

• 2025년은 AI 코딩 도구가 진짜로 실용 단계에 들어선 해였음
  예전엔 GPT-3 같은 초기 모델이 가능성만 보여줬고, 그로 인해 과도한 하이프와 회의론이 생겼음
  하지만 지금은 많은 개발자들이 실제 워크플로우에 AI를 통합하고 있음
  아직 회의적인 개발자라면 Mitchell의 글을 읽고 Claude Code를 직접 써보길 권함

  • 나도 같은 생각임. 10년 뒤엔 어떤 시점을 전환점으로 기억할지 궁금함
    한때는 “데이터 한계” 얘기가 많았는데, Claude Code, Sonnet 4.5, Opus 4.5가 나오면서 분위기가 완전히 바뀌었음
  • Claude Code를 Codex나 Gemini 대신 써야 할 이유가 있는지 궁금함
    두 모델은 비슷했는데, Claude는 요금제 사용량 제한이 빠르게 닳는다는 얘기 때문에 아직 안 써봤음
  • 하지만 여전히 하이프 중심의 산업 구조가 걱정임
    경영진이 속도와 양만 중시하다가 유지 불가능한 코드 더미를 양산할까 두려움

• “Don’t draw the owl” 접근법이 내 경험과도 일치함
  LLM이 점점 현실 제약에서 벗어나며 드리프트하는 게 문제였음
  그래서 채팅은 설계 논의용으로, 에이전트는 좁고 검증 가능한 diff 작업만 맡기도록 분리했음
  이 루프가 안정되자 장난감이 아니라 진짜 레버가 되었고, 실제 프로젝트 기능을 여러 번 배포했음

  • 글의 문체가 LLM을 닮았다는 지적을 받음
    요즘 이런 패턴화된 문장 구조가 사람들 사이에서도 늘고 있어서 흥미로움
  • 이런 접근이 사실 우리가 원래 소프트웨어를 짜야 했던 방식과 다르지 않다는 생각도 듦

• Opus 4.5 관련 논의가 많아져서 직접 써봤는데, 에이전트 패러다임이 확실히 유용해졌음을 느낌
  아직은 단순한 작업 위주지만 만족스러움

• LLM은 나에게 맞지 않음
  인간의 사고력과 창의성이 우리를 구분 짓는 요소인데, 이를 기계에 넘기면 스스로를 약화시킨다고 느낌
  Rails 개발자로서 Zed와 Claude Sonnet 4.x, Opus를 써봤지만, 점점 RSpec 작성 능력이 줄어드는 걸 체감했음
  결국 neovim으로 돌아가 에이전트 없이 일함
  편리함은 결국 사고력의 퇴화를 부를 수 있음
  LLM은 인간이 만든 최고의 편의 도구지만, 나는 내 기술과 사고를 유지하는 쪽을 택함

• 이번 글은 다른 프론트페이지 글보다 훨씬 실용적이고 덜 과장된 느낌임

  • 드디어 회의적인 사람도 따라 해볼 수 있는 단계별 가이드가 나왔음
    “분위기 코딩으로 OS를 만들었다” 같은 과장 대신 현실적인 접근임

• 다들 비슷한 AI 활용 여정을 겪고 있는 게 흥미로움
  여러 모델을 병행해 코드베이스의 다른 부분에 적용하고, 모델끼리 상호 검증하게 함
  여전히 git reset을 자주 하지만, 점점 더 효율적으로 피할 방법을 배우는 중임
  마치 두뇌 자동완성 시대에 살고 있는 기분임

• “에이전트는 파일 읽기, 프로그램 실행, HTTP 요청이 가능해야 한다”는 말이 있었는데,
  이건 Simon Willison이 말한 ‘치명적 삼합체’ 와 거의 같은 수준임

  • 그래서 난 절대 내 로컬 머신에서 그걸 돌리지 않을 생각임

• 에이전트에게 개선점을 계속 알려줘야 하는 게 짜증남
  매번 agent.md를 수정하며 피드백을 줘야 하는데, 스스로 학습해서 개선되면 좋겠음

  • 하지만 누군가의 개선이 다른 사람에겐 코드 스멜일 수 있음
    AGENTS.md에 몇 줄 추가하는 건 그리 큰 일도 아님
    /fix 명령을 만들어 자동으로 수정하고 문서화하게 하면 꽤 시간 절약됨
  • 난 오히려 피드백 주는 걸 즐김
    내가 엔지니어링의 주도권을 쥐고 있다는 느낌을 줌
    특히 새로운 기능 리서치와 구현을 빠르게 반복할 수 있어서 좋음

• 실제로 이런 접근이 어떻게 보이는지 궁금하다면,
  OP의 과거 블로그 글 “Non-trivial Vibing”과
  그에 대한 HN 토론을 참고할 만함