AI를 사용해 더 나은 코드를 더 천천히 작성하기

내 직장에서는 AI로 더 빨리 움직이겠다는 꿈은 포기했음. 우리 경우에는 코딩이 병목이 아니기 때문임
그래도 코딩 에이전트가 좋은 건, 항상 되고 싶었던 엔지니어처럼 일하게 해준다는 점임
예를 들면 코드를 조금 더 밀어붙일 수 있는 제대로 된 테스트 하네스를 만들고, 생성 코드가 원본과 맞는지 검증하는 CI 단계를 추가하고, 변경 배포를 제대로 모니터링하는 일들임
예전 같으면 GitLab CI 매뉴얼을 읽고 조건을 맞추는 법과 우리 회사의 꼬인 방식을 파악해야 해서 일정상 감당 못 했을 일들인데, 이제는 가능해졌고 이게 미래라고 봄

LLM을 API를 아는 스파이크 파트너나 기계적 리팩터링 장치로 쓰면 꽤 성공적이었고, 특히 타입이 강한 언어에서 효과가 큼. 테스트 작성에도 좋지만, 그 테스트가 실제 제약력을 갖는지 확인하는 다층 절차가 있어야 함
변이 테스트가 꽤 도움이 됐고, 원문이 제안한 것처럼 여러 번의 검토도 필요함
예전에는 LLM에 훨씬 부정적이었고, 돌아보면 비합리적일 정도였지만, 대부분은 LLM이 쏟아내던 저품질 소프트웨어 때문이었음
직접 파고들어 보니 판지 프로토타이핑 도구이자 훨씬 빠른 타자수처럼 다루는 게 맞았음. 예를 들어 “이 Lean 프로젝트의 모든 정리에서 이 패턴을 찾아 저 패턴으로 바꾸고, 바로 안 되는 곳은 표시해서 남은 목록을 달라”고 하면, 내가 vim, sed, awk와 임시방편을 섞어 첫두 번 시도할 시간에 100개 넘는 정리를 청크 단위로 고쳐줌
Lean은 언어 특성과 내가 하는 작업상 “컴파일됨”과 “동작함” 사이 간격이 좁아서 특히 좋고, Rust에서도 좋은 테스트 스위트와 변이 테스트를 붙이면 비슷한 느낌을 받음
이 도구들의 긴 꼬리는 “버튼 누르면 제품 나옴”이 아니라, 좋은 엔지니어가 이를 받아들여 중요한 일에 에너지를 집중하고, 예전의 잡일 상당 부분을 기계에 위임하는 쪽이라고 봄

나도 처음에는 LLM을 매우 부정적으로 봤지만, 이제는 방해보다 도움이 되는 수준까지 좋아졌다고 생각함
예시가 흥미로운데, 예전에 JavaScript 프레임워크 팀에서 일할 때 업그레이드나 마이그레이션 같은 일을 위해 직접 코드모드를 작성했음. AST를 고치는 고된 작업이었음
요즘이라면 LLM에게 맡겨서 90%쯤은 도달할 수 있을 것 같음

이런 관점이 좋음. 도구가 유연하고 꼭 저품질 결과물을 만들 필요는 없다는 건 당연해 보이지만, 찬성하는 쪽과 거부하는 쪽 모두 이 관점을 자주 무시함
아직 LLM으로 코드 리뷰를 해보진 않았지만 할 일 목록에 넣어봐야겠음. 지금까지는 아이디어 생성, SQL이나 VimScript 도움 정도로 쓰고 코드는 직접 작성함
한 가지 위험은 코드 리뷰도 기술이라서 모델에 너무 기대면 그 능력이 퇴화할 수 있다는 점임. 다만 상업 환경에서 최고의 코드 리뷰조차 보통 “적당한 시간”과 “이 사람을 신뢰하는가”의 조합이지, 수학적 정확성에 가까운 건 아님

그 말도 맞지만, 이 작업 흐름은 오히려 내 코드 리뷰 능력을 늘려준다고 느꼈음. “버그”가 실제로 가능한지 아니면 이론적인지만 따져야 하고, 고칠 가치가 있는지, 다음 PR로 넘겨야 하는지도 판단해야 하기 때문임
복잡한 버그는 직접 끝까지 생각해보는 편인데, 1) 환각이 아직 섞여 들어오고, 2) 어차피 시스템을 종단 간으로 이해할 가치가 있기 때문임

메타 얘기지만 이 글에 붙은 플래그가 이해가 안 됨. 주제 벗어남 1개, 스팸 3개라니 이상함
첫 페이지 최상단 글도 LLM 사용에 관한 글이고, 일반 글쓰기에 대한 글이라 코딩에 초점을 둔 이 글보다 오히려 주제성이 약해 보이는데 플래그가 없는 듯함

아마 자기 홍보로 보고 스팸 플래그가 붙는 것 같음

Lobsters에서 이런 관점을 보니 신선함. 일괄적인 반AI 정서는 점점 피곤해짐. 저품질 결과물을 좋아하는 사람은 없다는 데는 모두 동의할 수 있을 것임
하지만 AI를 완전히 보이콧하고 독선적인 태도를 택한 사람들은, 더 실용적인 태도를 택한 사람들보다 미래를 받아들이기 어려울 것임
처음부터 AI는 전동 공구의 발명과 비슷하다고 말해왔음. 손 렌치로 타이어를 갈고 싶다면 괜찮지만, 임팩트 드릴이 나왔을 때 정비공들이 보이콧하진 않았음. 글 맥락상 최고의 비유는 아니지만 여전히 그렇다고 봄
문서를 읽을 때보다 AI를 쓰며 더 많이 배웠음. 문서에는 추가 맥락, 설명, 예시가 필요할 때 질문할 수 없기 때문임. “뭔가 만들어, 실수하지 마”라고 할 수도 있지만, 실제로 배우기 위해 느린 접근을 선호함

여기서 일괄적인 반AI 정서는 못 봤음. 예시를 링크해줄 수 있음?
내가 본 건 LLM으로 수백만 줄 코드를 한 번에 바꾸고, 인간 리뷰 없이 배포하는 변화에 대한 비판이었음. 구체적으로는 Bun의 Zig에서 Rust로의 포팅 스레드 같은 경우임
이 글도 그건 비판하고 있음