속도만이 유일한 목표일 필요는 없음. 버그 수정은 별도의 준비 커밋으로 떼어 독립적으로 검토하고, 잘못된 상태를 표현할 수 있는 타입 구조를 고치며, 테스트 신뢰도가 부족하면 속성 기반 테스트·퍼징·정형 기법을 실험할 수 있음
예전에는 이런 작업을 한 커밋에 몰아넣거나 기술 부채 TODO로 남겼지만, 이제 제대로 구현하는 데 드는 한계 비용이 놀라울 만큼 낮아졌음. LLM은 개방적인 도구라서 사용자가 중시하는 가치만큼 효용을 돌려줌
다만 완성되지 못하고 운영에 도달하지 않는 프로토타입이 늘어날 위험도 있지만, 전반적으로 엄밀성을 중시하는 엔지니어링에는 큰 도움이 됨

이런 평가에 강하게 공감하면서도, 대부분의 회사에서 실제로 벌어지는 일은 다르다는 생각이 듦. LLM이 엄밀성을 높일 수 있는데도 흔히 최저 품질 MVP 경쟁에 쓰이고 있음
회사 문화의 문제일 수도 있지만 실망스러우며, 업계가 정신을 차리고 더 높은 품질의 소프트웨어를 만들기를 바람

과거 프로젝트에 에이전트를 단일 프롬프트로 투입하면 큰 노력 없이도 실제 버그를 계속 찾아냄. 인간도 허술하고 나 역시 실수하지만, LLM은 빠르면서 여러 면에서 더 우둔해 그 문제가 일찍 드러날 뿐임
실수는 누적되므로 에이전트가 무작정 코드를 바꾸게 두면 빠르게 망가지지만, 순진한 사용법이 불안정하다고 도구 자체가 쓸모없다고 보는 것도 게으른 판단임
지금은 변경할 때마다 아키텍처, 유지보수성, 신뢰성·보안 등을 포함한 전문 검토 5개를 자동 수행하고, 설계 문서 체계로 정리해 에이전트의 의사결정을 크게 개선하고 있음. 완벽하지는 않아도 순진한 방식보다는 낫고, 더 개선할 여지가 있다는 점도 새로운 도구를 다루는 재미임

여기서는 코드 생성과 검토만 다뤘을 뿐, 확률적 텍스트 분석으로 버그 패턴을 찾는 용도에 관해서는 말하지 않았음

프롬프트로 더 빨리 생성해도 검증하고 이해하는 데 시간이 더 들어, 처음부터 직접 작성하는 편이 빨랐을지 고민하게 됨. 어느 쪽이 나은지 판단하는 일 자체에도 시간과 에너지가 들며, 그 자원을 다른 곳에 쓰고 싶음
다만 PR 제출자가 소유권과 책임을 진다면 LLM 사용 여부는 중요하지 않음. 품질·정확성·일관성 기준을 충족한다면 더 빠른 방식을 택하면 되고, 책임은 인간 작성자에게 그대로 남음
개인적으로 AI는 학습하고 이해를 넓고 깊게 만드는 데 좋아하지만, 입력 시간뿐 아니라 전체 과정을 고려하면 아직 직접 코드를 작성하는 편이 더 생산적임

글이 거의 1년 전에 작성됐다는 점부터 문제임. 최근 6개월, 특히 최근 3개월 동안 최신 유료 클라우드 모델의 유용성이 크게 높아졌음
감사 업무에서 발전시킨 MFIC 원칙처럼 실패 범주 전체를 막는 통제 장치가 있는지 확인해야 함: https://gist.github.com/pmarreck/b30aa3ca69cb70a5526f8a63ab8c8d7e
기존 코드와 프로젝트 구조를 문맥에 유지하는 https://github.com/pmarreck/dirtree 및 https://github.com/pmarreck/codescan 같은 도구도 필요하며, 이는 코드베이스를 잊었거나 익숙하지 않은 인간 개발자에게도 유용함
결국 이를 제대로 활용해 이점을 얻거나, 직접 맞춤 코드를 작성하면서 버그와 보안 취약점도 만들고 더 빠른 경쟁자에게 추월당할 수 있음. Desk.com의 폐기된 백만 줄 규모 Ruby on Rails 코드베이스에 2인년을 쓴 입장에서, 기업 코드는 일시적이어서 LLM 생성 코드와 잘 맞음
Erlang 내부 구현이라면 신뢰하기 어렵겠지만 함수 단위로 작성시킨 뒤 검토할 수는 있으며, 때로는 기대보다 나을 것임. 뜨개바늘과 직조기 중 하나만 고르기보다 상황에 따라 둘 다 쓰는 편이 이상적임

내부 구현이 아니라 나 역시 기업용 코드를 다루며, LLM 사용자가 남긴 코드를 정리하는 사람임. 방금 한 말은 원문의 어느 문장도 반박하지 못하고 오히려 뒷받침함

최근 6개월이나 3개월 사이 크게 개선됐다는 말은 최소 2년째 반복되고 있음

개인적 경험과 주변의 신뢰할 만한 숙련 개발자들을 보면 LLM이 더 낫고 빠른 코딩을 반복해서 가능하게 했으므로, 과학적 증거상 도움이 될 수 없다는 글을 진지하게 받아들이기 어려움
동료 평가 논문이 없어도 이미 충분히 봤으며, METR 연구 하나가 개발자들의 생산성 향상 추정을 반박한다고 해서 기존 판단을 바꾸지는 않겠음

자신을 연구자라고 부르는 사람에게 개인적 체험만으로 충분하다는 것은 당혹스러울 만큼 낮은 증거 기준임

개인적 경험은 의사들이 손 씻기를 거부하거나 사혈을 옹호할 때도 사용했음. 그런 경험을 신뢰해 사람을 죽인 역사를 바탕으로 과학이 만들어졌음
엄밀하고 방법론적으로 타당하게, 기존의 견고한 실증 연구와 어디서 다른지 보여주면 생각을 바꿀 준비가 되어 있음. 하지만 개인적 경험이나 설명 없는 일화 열두 개로는 부족함
과학과 공학은 수십억 명의 삶을 개선했으며, 누군가 자신이 더 낫다고 믿는다는 이유로 이를 버릴 수 없음

상대를 설득할 증거를 요구했는데, 자신은 이미 확신했으니 더 필요 없다고 답하는 것은 질문에 답하지 않은 셈임
개인을 사이비 종교 신자라고 부르려는 뜻은 아니지만, 믿음에 대한 도전을 개인적으로 받아들이면서 정작 타인을 설득할 방법은 모르는 태도는 사이비 종교 집단의 소통 방식과 닮았음

코드 생성 용도의 LLM에는 아직 유보적이지만, PR 작성자가 인간인지 기계인지는 중요하지 않고 동일한 품질 기준을 적용해야 함
대부분 LLM으로 만든 PR이라도 제출자가 책임을 지고, 다른 사람이 이해하기 좋은 문맥과 크기로 나눠야 함. 코드는 여전히 소프트웨어의 최종 명세이며, 개발자가 소유하고 이해해야 한다는 사실은 바뀌지 않았음

1년 전 AI 에이전트가 실수를 많이 했다는 주장은 맞지만 지금도 그런지는 불분명하며, 지난해 11월 무렵 최전선 모델의 변곡점을 체감했음
LLM이 코드량을 늘려 검토 역량에 새로운 압박을 주는 것은 사실이지만, 엔지니어는 이에 제동을 걸고 검토량이 실제 처리 능력에 맞도록 보장해야 함

여전히 중대한 아키텍처 실수를 저지름. 공유 동작을 추출해 재사용할 수 있는 상황을 알아채지 못하고 새 코드를 추가하는 식임
더 나쁜 점은 새 코드가 대체로 작동해서 정리 없이 병합될 가능성이 크다는 것임

최전선 모델이 엄청난 양의 코드를 작성하는데도, 코드를 제거하자고 제안하는 음의 기여를 진지하게 탐구하지 않는 점이 의아함. “The Best Code is No Code At All” - Jeff Atwood처럼 추상화 계층으로 비대해진 코드베이스의 복잡성을 풀어내고 줄 삭제을 제안할 수 있다면 참신할 것임
이미 가능할 수도 있지만 아직 직접 보지는 못했음

정정하면 “The Limits Of Reviews” 절은 효율적인 최대 속도를 시간당 400줄로 제시하며, 처음 생각한 검토당 400줄이 아니었음
다만 1시간과 400줄이라는 수치가 정확히 어떤 코드 검토 논문에서 나왔는지는 여전히 궁금함. 논문명을 따로 저장하지 않았다면 다시 찾는 데 많은 시간을 쓸 필요는 없음

관련 자료를 어딘가에 보관해 두었으니 확인할 수 있음. 대부분은 시간당 100~200줄 한계를 제시하지만, 프로그래밍 언어가 지금보다 버그에 취약했던 오래된 연구가 많음
현재 여행 중이므로 며칠 뒤 다시 알려주길 바람

시간당 400줄이 의심스러워 내 업무 기록으로 계산해 봄. 최근 6개월간 변경 13만 9천 줄에 해당하는 PR 173개를 검토했음
주 40시간 중 검토 비중이 25%라면 시간당 약 540줄, 15%라면 900줄, 5%라면 2,700줄임. 실제 처리량은 시간당 500~1,000줄 정도로 추정되며, 출처가 제시되지 않은 수치와 어느 정도 가까움

AI 생성 코드라고 인간 작성 코드보다 더 많이 또는 덜 검토해야 한다는 논리를 이해하기 어려움. 승인 기준이 같으므로 동일한 수준으로 검토함