Hacker News 의견들

• 90년대의 ‘주간 코드 라인 수’ 지표가 다시 돌아온 느낌임
  “PR을 더 많이 한다”는 건 AI가 잘 작동한다는 증거가 아니라 단지 더 많이 머지하고 있다는 뜻임
  코드 품질, 버그, 유지보수 부담을 고려하지 않은 채 생산량만으로 성과를 판단하는 건 예전 관리자가 밀어붙이던 나쁜 지표와 다를 바 없음
  결국 우리는 나쁜 지표에 반대한 게 아니라, 측정당하는 것 자체를 싫어했던 것 같음

  • 나도 AI를 매일 쓰지만, ‘라인 수’보다는 PR 코멘트·반복·버그 최소화를 목표로 함
    코드가 단순하고 영향력 있는 결과를 내는 게 진짜 목표임
    여러 에이전트를 동시에 돌려서 서로 다른 구현을 시도하게 하고, 그중 좋은 아이디어를 합치는 식으로 실험 중임
    또, 문서와 요구사항을 모아 에이전트에게 질문을 던지고, 코드 리뷰 피드백을 일반화해 체크리스트로 만들어 다음 리뷰에 반영함
  • 글쓴이가 번아웃과 불안에 대한 블로그 글도 썼던데, 이런 생산성 집착이 그와 연결된 것 같음
    아플 정도로 일하는 건 자랑이 아니라 시스템이 잘못된 신호임
  • 글의 첫 문장에서도 “커밋은 나쁜 지표지만, 내가 가진 가장 눈에 띄는 신호”라고 인정하고 있음
  • 코드 라인 수는 개인 단위에서는 무의미하지만, 시스템 전체 규모를 추정할 때는 의미가 있음
    예를 들어 COCOMO 모델은 법정에서도 시스템 가치 추정에 사용될 정도로 신뢰받음
  • “나쁜 지표에 반대한 게 아니라 측정 자체를 싫어했다”는 말은 결국 좋은 지표란 존재하느냐의 문제임
    대부분의 개발자는 자기 자신을 수치화하고 싶지 않음
    다만 AI 옹호자들은 개선을 증명하려면 측정이 필요하다고 생각함

• LLM을 이용해 인지 부하를 줄이는 방향으로 써야 한다고 생각함
  사람은 멀티태스킹에 약하고, LLM이 그걸 보완해주지는 않음
  나는 Claude에게 구현을 대신 맡기기보다, 직접 구현 과정을 안내받는 방식으로 씀
  이렇게 하면 전체 과정을 이해하면서 세부와 큰 그림을 동시에 볼 수 있음
  반복적이고 기계적인 부분만 Claude에게 맡기면 됨

  • 나도 POC 중심 워크플로우를 씀
    LLM에게 문제를 이해하도록 질문을 던지고, 핵심 코드를 직접 작성한 뒤 나머지 구현 계획을 세우게 함
    LLM은 코드 읽기·설명·단순 작업에 강하고, 나는 문제 해결 방향을 선택하는 데 집중함
  • 이 아이디어가 너무 마음에 들어서 바로 시도해볼 예정임
    LLM이 내 대신 결정한 부분을 추적하기 위해 “가정 목록 작성”이나 “계획에 없던 결정 나열” 같은 프롬프트를 실험 중임
  • 어떤 사람은 이런 강도 높은 협업이 재미있고 몰입감 있다고 함
    Claude의 특성을 이해하면 검증 효율도 높아지고, 경험이 쌓일수록 품질 관리도 쉬워짐

• 여러 에이전트를 돌려 큰 기능을 만들면, 결국 리뷰 시간이 엄청나게 늘어나는 문제가 생김
  다른 사람(혹은 AI)의 코드를 읽는 게 직접 작성하는 것보다 어렵기 때문임
  테스트 자동화로 커버할 수도 있겠지만, 완전한 신뢰는 어려움

  • 그래서 나는 계획 단계의 엄격함을 강조함
    범위·테스트·문서 계획을 명확히 하고, 코드 리뷰 봇(Sourcery, CodeRabbit, Codescene)과 강력한 린팅 규칙을 적용함
    BDD, property testing, e2e 테스트, 코드 감사, mutation/fuzzing 테스트까지 활용함
    에이전트 코딩의 장점은 이런 품질 관리에 쓸 시간을 확보해준다는 점임
  • LLM이 불필요하게 장황하고 불필요한 수정을 많이 해서 리뷰 범위가 넓어지는 게 병목임
  • 하지만 단순 수정이나 UI 개선처럼 위험이 낮은 변경은 자동 배포도 가능함
    100 PRs a day 같은 접근으로 점진적 배포를 시도 중임
  • 나는 에이전트가 만든 코드를 그대로 배포하지 않고, 그 출력 결과만 활용함
  • 코드 리뷰는 연습으로 충분히 빨라질 수 있음
    작업을 세분화하고 테스트를 신뢰하면 AI 코드 리뷰도 가벼워짐
    테스트 케이스를 더 꼼꼼히 보고, 코드 리뷰는 빠르게 끝냄
    여러 에이전트를 병렬로 돌리진 않지만, AI 덕분에 생산성은 확실히 높아졌음

• PR 작성 과정이 단순 자동화되면 자기 검증의 기회가 사라짐
  나는 PR 설명을 쓰는 과정에서 내 코드의 이상함을 자주 발견했음
  영어로 설명하는 그 순간이 마지막 sanity check였음

• worktree 시스템 덕분에 문맥 전환이 쉬워졌지만, 동시에 정신적 피로가 커짐

  • 여러 에이전트를 병렬로 돌리는 게 실제로 속도나 정확도에 어떤 영향을 주는지 연구가 필요하다고 느낌
  • 나는 한 번에 1~2개의 작업에 집중하는 편임
    작은 단위로 나눠서 리뷰 주기를 짧게 가져가면 품질 관리가 쉬움
  • 에이전트에게 PR 생성을 맡기고, 나중에 몰아서 리뷰하는 식으로 큐를 쌓아두는 전략을 씀
  • 여러 worktree를 병렬로 돌리지만, 항상 지켜보진 않음
    그냥 내 흐름을 깨지 않고 다음 날 돌아와도 진행이 되어 있는 상태가 좋음

• Claude가 코드를 완성도 높게 작성한다는 전제에는 회의적임
  실제로는 여러 번의 피드백과 수정이 필요하고, 동시에 여러 작업을 병렬로 관리하면 오히려 비효율적임

• Claude Code는 학습용 도구로는 혁신적이지만, 코드 생성 품질은 들쭉날쭉함
  Flutter/Dart를 배우면서 Claude에게 개념을 묻는 식으로 공부했는데, 책 없이 일주일 만에 앱을 만들 수 있었음
  마치 대화형 백과사전처럼 느껴짐

  • 나도 이 용도에는 전적으로 동의함. 진짜 혁신적임
  • 많은 사람들이 이렇게 사용함
    “이 언어에서 X를 하는 관용적 방법은?” 같은 질문에 즉시 유용한 답을 줌
    다만 세상을 바꾸는 존재라기보단 아주 좋은 도구일 뿐임
  • AI는 사람을 대체하기보다 학습과 숙련을 가속화하는 방향으로 써야 함
    하지만 과도한 마케팅이 경제 전반에 부정적 영향을 주고 있음
    AI가 일자리를 대체한다는 허상 때문에 젊은 세대가 직업을 포기하는 현상도 우려됨

• “SWC로 빌드 전환 후 서버 재시작이 1초 미만으로 줄었다”는 말이 있었는데,
  SWC는 Speedy Web Compiler로, 타입 체크 없이 빠르게 트랜스파일하는 도구임
  NestJS 문서에서도 같은 것을 설명함

• LLM을 쓴다고 해서 생산성이 폭발적으로 늘었다고 자랑할 일은 아님
  모두가 같은 도구를 쓰면 기준선이 올라갈 뿐임
  게다가 AI가 생성한 대규모 코드가 제대로 리뷰되지 않으면 장기적 품질은 불확실함

  • 성과는 단순 비교가 아니라 자신의 결과물과 가치로 판단해야 함
  • 현대 컴파일러(GHC 등)를 써서 생산성이 높아졌다고 말하는 것도 같은 맥락임

• LLM이 생산성을 높여주긴 하지만, 커밋 수 그래프로 측정하는 건 무의미함
  LOC로 품질을 판단하는 것만큼 어리석음

  • 나도 Claude 덕분에 몇 달 미뤘던 기능을 며칠 만에 구현했음
    직접 코드를 작성하면서 이해하고, Claude는 작업 분해와 리뷰 파트너로서 큰 도움이 됨
  • 코드베이스 개선의 최고의 지표는 음수 LOC, 즉 불필요한 코드 삭제임
  • 경험상 가장 뛰어난 엔지니어는 코드를 줄이는 사람이었음
    복잡한 코드를 단순한 추상화로 대체하는 능력이 진짜 생산성임