Hacker News 의견들

• 나는 AI 이전에도 존재했던 ‘vibe coding’ 이 있었다고 생각함

  • 많은 개발자들이 객체가 왜 null인지 고민하지 않고 그냥 null check를 덕지덕지 붙이는 걸 봤음
  • 이런 접근은 일부 영역에서는 쓸모 있지만, 전체 시스템이 이렇게 만들어지면 유지보수가 악몽임
  • AI 기반 vibe coding은 “왜 작동하는지 모른 채 화면에 원하는 결과만 보는” 스타일을 가속화하는 느낌임
  • 예전에 이런 회사에서 일한 적이 있는데, null check로 예외를 삼켜버려서 오류가 조용히 묻히곤 했음
    • 팀은 자신들이 똑똑하다고 자화자찬했지만, 사실은 StackOverflow 복붙 코드와 오래된 MVP 구조로 돌아가는 시스템이었음
    • 이런 환경에서는 독립적인 사고가 거의 불가능했음
    • 그래도 Claude Code 같은 도구는 잘 설계된 코드베이스 위에서는 생산성을 크게 높여줌
  • StackOverflow에서 복붙하다가 “대충 돌아가면 됐다” 수준으로 멈추는 게 바로 vibe coding임
    • AI는 그 과정을 자동화했을 뿐임
  • “보고 싶은 걸 본다”가 아니라 “아무거나 화면에 띄운다”가 더 정확한 표현임
    • 무심코 넣은 null-check는 나중에 미묘한 데이터 오류를 일으켜서 원인 추적이 매우 어려워짐
  • 나도 동의하지만, vibe coding은 StackOverflow 의존형 개발자를 더 빠르게 만들어버림
    • 스스로 문제를 해결하지 않는 개발자 유형이 더 늘어남
    • 게다가 예전보다 신뢰성은 더 낮아짐
  • AI를 쓰면서 가장 답답한 점은 언어별로 중간 수준의 코드 스타일을 그대로 따라 한다는 것임
    • 나는 “잘못된 데이터를 만들지 않으면 처리할 일도 없다”는 원칙을 따르는데, AI는 자꾸 그걸 어김
    • 타입 정의나 invariant 유지를 거의 하지 않고, 문자열과 정수로만 처리하려 함
    • 그래서 나는 tab-complete 기반으로 AI를 끊어 쓰며 구조적 오류를 직접 수정함
    • 수정 후에는 AI도 올바른 방향으로 따라오므로, IDE와 LSP 통합이 더 좋아지면 훨씬 유용해질 것 같음

• vibe coding에 대한 비판은 타당하지만, 사실 AI 이전에도 코드 품질은 형편없었음

  • 대부분의 코드는 느리게 배포되고 품질도 낮았음
  • 빠른 배포가 아이디어 검증 속도를 높인다면, 어느 정도의 오류는 감수할 만하다고 보는 사람도 있음
  • 요즘은 경영진이 “이 정도 기능에 왜 몇 달이 걸리냐”고 묻는 경우가 많아짐
  • 하지만 “사소한 기능이 오래 걸리는 이유”는 알고리즘이 아니라 인프라와 협업 구조 때문임
    • AI는 이런 근본 문제는 해결하지 못함
  • 유지보수 비용과 복잡성은 시간이 지날수록 복리처럼 쌓임
    • 단기 프로젝트에는 vibe coding이 괜찮지만, 장기 시스템에는 부적합함
  • 나는 의도적 개발자와 vibe 개발자의 균형이 중요하다고 봄
    • AI는 vibe 쪽을 과도하게 강화해서 시스템 균형을 깨뜨림
  • 코드 품질보다 중요한 건 비즈니스 문제와 기술 해법의 공동 이해임
    • 품질이 낮더라도 그 이유와 트레이드오프를 명확히 아는 게 더 중요함
  • 하지만 소프트웨어를 모르는 사람이 개발자에게 “잘못하고 있다”고 말하는 건 긍정적이라고 보기 어려움

• “AI 코드가 1.7배 더 많은 문제를 만든다”는 말은 발견된 버그 수일 뿐임

  • 실제로는 PR 리뷰가 제대로 안 되기 때문에, AI 코드의 문제도 많이 놓침
  • 코드 리뷰는 버그 찾기보다 구조 이해와 공유에 더 초점을 맞춰야 한다는 연구도 있음
  • 반대로, AI 코드가 주석이 많고 읽기 쉬워서 오히려 더 꼼꼼히 리뷰된다는 의견도 있음
    • 인간 코드에서는 “이게 뭔지 모르겠는데 지우면 깨진다”는 식의 주석이 더 많음

• 얼마 전 .NET에서 IComparable 구현을 Copilot이 제안해줘서 몇 분 절약했음

  • 그런데 변수 이름을 x와 y로 바꿔 써서 한 시간 동안 디버깅함
  • 내가 직접 썼다면 그런 실수는 없었을 것임
  • 그래도 결과적으로는 내가 쓸 코드와 거의 같았음

• 예전에도 비슷한 상황이 있었음

  • 에러 처리와 엣지 케이스를 무시하면 훨씬 빠르게 배포할 수 있었지만, 결국 버그 폭탄이 됨
  • AI는 이걸 극단으로 밀어붙이는 느낌임
  • “그럴 거면 Erlang이나 Elixir로 갈아타야 하지 않나”는 농담도 나옴

• LLM 기반 회사가 “AI가 생각보다 덜 엉터리다”고 주장하는 게 흥미로웠음

  • 하지만 Coderabbit은 LLM 코드 리뷰 회사라 오히려 “AI는 엉망이니 AI로 리뷰해야 한다”는 인센티브가 있음
  • 나도 Copilot을 리뷰 도구로 쓰는데, AI 리뷰는 거의 항상 정확해서 사람 리뷰 전에 큰 도움이 됨

• 나는 CodeRabbit을 자주 쓰는데, 여전히 false positive가 많음

  • 이미 검증된 코드인데도 “데이터 검증이 없다”고 지적하는 경우가 있음
  • 그래도 “틀렸다”고 알려주면 도구가 그걸 학습해서 수용함

• “1.7배 더 많다”와 “1.7배 증가했다”는 같은 말이 아님

  • 하지만 이런 수치 논쟁은 결국 의미 없는 싸움처럼 느껴짐

• Agentic AI coding은 도구일 뿐, 잘못 쓰면 당연히 잘못된 결과가 나옴

  • 성공적인 활용 사례로 Python의 justhtml 예시를 추천함
  • 다만 “쓸 줄 모르면 무능하다”는 식의 흑백 논리는 문제임
    • AI를 유용하다고 느끼든 아니든, 그건 단순히 경험의 차이일 뿐임

• 기사 제목의 “AI 코드가 1.7배 더 많은 문제를 만든다”는 표현은 부정확함

  • 실제로는 버그가 아니라 포맷팅·네이밍 문제까지 포함된 “문제”임
  • 버그 수치 자체는 기사에 명시되어 있지 않음