코드는 더 싸졌다

“LLM은 복잡성을 두려워하지 못한다”는 표현은 과장에 가깝다고 봄
실패 양상 자체는 실제로 있음. 지시를 넓게 주면 LLM은 계층을 추가하고, 추상화를 만들어내고, 문제에 비해 과한 코드를 자주 냄. 하지만 그 행동은 관찰하기 쉽고, 리뷰하기 쉽고, 의외로 방향을 틀기도 쉬움. AGENTS/CLAUDE.md 파일로 원하는 소프트웨어 스타일을 맞추면 됨
가장 작은 변경을 요구하고, 무엇을 지울 수 있는지 묻고, 그 추상화가 제값을 하는지 물어보면 됨. 불변조건, 결합 지점, 인지 부담도 물어보고, 영리함을 제거하는 2차 패스를 요청하면 대체로 그 압력을 따라감. 프롬프트에 넣어두면 처음부터 피하게 만들 수 있음
위험은 LLM이 복잡성을 절대 존중하지 못한다는 데 있지 않고, 주변 프로세스가 보상하는 코드 형태를 기꺼이 만들어낸다는 데 있음. 양을 보상하는 팀은 양을 받고, 단순성을 보상하는 팀은 대체로 그것도 받을 수 있음
요즘 모델은 대부분의 인간보다 낫고 앞으로 더 좋아질 것임. 코드가 좋지 않으면 AI 연구소에 피드백으로 압박해야 함. 예를 들어 GPT 계열은 좋은 문서 작성에는 형편없다고 봄

맞기도 하고 아니기도 함. 핵심은 능력이라기보다 훈련 방식과 목표에 가까워 보임. 지금 유행하는 건 “프로젝트 전체를 바이브 코딩했다”는 식이고, LLM은 처음부터 만드는 것에 비해 기존 코드를 바꾸는 데 매우 약함. 훈련 방식 때문일 가능성이 크고, 통계적 편향도 있어 보임. 크고 복잡한 코드베이스의 코드가 작고 단순한 프로젝트보다 훨씬 많으니 학습에서 더 큰 비중을 차지했을 것임
그래서 “불가능하다”는 표현은 최선이 아닐 수 있지만, 기본값으로는 복잡성 쪽으로 기우는 여러 편향이 있다고 봄
또 무언가를 하지 않는 것보다 무언가를 하는 쪽의 편향도 있음. 좋은 프로그래머는 특정 요청을 던지는 관리자보다 훨씬 많은 맥락을 쓰고, 대안을 제시하기도 함. LLM도 가능은 하겠지만, 현재 LLM은 “계획 중 질문하기”나 반복 감지 코드가 있어도 올바른 질문을 던지는 데 능숙하지 않음. 그런 학습 데이터도 흔하지 않을 가능성이 큼
어떤 면에서 프롬프트 엔지니어링은 이 문제 묶음을 둘러싼 끔찍한 해킹에 가까움

그 표현에 완전히 동의하는지는 모르겠지만, 분명 뭔가는 있음. 한편으로는 단일 대상 Makefile이면 충분한데도 거대한 CMake 프로젝트를 기본으로 만들어내는 식의 “흔한 복잡성”을 본 적이 있음
다른 한편으로는 “이건 한 달짜리 프로젝트라 추천하지 않습니다. 이 상태로 커밋하고 데모로 남기는 건 어떨까요” 같은 답을 받은 뒤 LLM을 설득하고 안심시켜야 했음. 둘 다 한 시간 이하로 끝날 걸 알고 있는데도 그랬음. 그런데 “그래, 완전히 새로운 걸 해봐. 방법은 네가 찾아”라고 하면 시도하긴 하니, 그런 의미에서는 두려움이 없다고도 볼 수 있음

Lobsters에서 “바이브 코딩”에 대한 뉘앙스 있는 얘기라니, 지옥이 얼어붙었나 봄 /s
농담은 제쳐두고 동의함. 내 경험과도 맞음

“코드를 이해하는 비용이 더 비싸졌다”는 말에는 일반적으로는 잘 동의하지 않음
생각 없이 생성된 LLM 코드라면 맞을 수 있지만, 적절히 안내하면 LLM도 읽기 쉽고 계층이 잘 나뉜 코드를 만들 수 있음. 물론 그 경우 아키텍처 선택의 대부분은 사람이 하는데, 애초에 그래야 한다고 봄
반례로, 익숙하지 않은 사람이 작성한 코드를 이해하는 데 LLM이 매우 뛰어나다고 느꼈음. Claude Code에게 특정 코드를 깊이 분석해 각 부분을 설명하는 Markdown 문서를 만들게 하고, 내가 리뷰하거나 이해하기 시작할 순서까지 제안받을 수 있음
이건 정말 가치가 큼

익숙하지 않은 코드에서 LLM을 쓰는 경험은 대체로 좋았지만, 관례에서 벗어난 부분에서 창의적으로 지어내고 거짓말하는 경우가 있음. 문제는 코드가 낯설기 때문에 둘을 구분하기 어렵다는 점임

“인간은 대체로 기하급수 곡선을 잘 이해하지 못한다. 그래서 복리 같은 동화를 믿는다”라니, 복리가 동화라는 뜻인가? 내가 뭔가 오해한 건가?