AI는 엔지니어링 규율을 덜이 아니라 더 요구함

이제는 누가 시스템을 이해하고 AI를 효과적으로 쓰는지, 누가 아무것도 모르면서 LLM 복붙만 뿌리는지 구분하기가 훨씬 어려워짐
2025년 전에는 성과가 낮거나 버티기만 하는 사람들은 기여가 적어서 비교적 드러났지만, 이제는 모든 엔지니어가 그럴듯한 형식의 PR, 코드 리뷰, 기술 설계 문서 등을 쏟아냄
C레벨이 AI를 최대한 쓰라고 강하게 압박하는 영향도 크고, 각 엔지니어 입장에서도 최대한 많이 만들어내는 게 유리한 게임 이론적 대응이기도 함
그럴듯해 보이는 문서와 코드에 완전히 잠기고 있으며, 그 양을 처리하려고 다시 AI에 의존하게 됨
이 시기의 후폭풍은 규모 면에서 특히 두드러지는 기묘한 형태의 기술 부채가 될 것 같음

회사와 특히 매니저의 기술 이해도에 따라 다르겠지만, 내 직장에서는 가장 효과적인 기여자들이 순 코드 줄 수가 거의 0이거나 심지어 음수인 경우가 많음
LLM은 많이 만들어내고 뭔가를 추가하는 걸 좋아하지만, 정말 유능한 엔지니어는 더 적은 코드와 더 적은 움직이는 부품으로 더 많은 비즈니스 성과를 냄

AI를 마법처럼 여기는 사람들도 있음
“프로세스를 자동화하는 데 AI를 쓰고 싶은데 프로세스 문서가 완전하지 않으니 AI가 도와주길 바란다”는 말을 자주 들음
무에서 결과를 만들 수는 없다고 설명해도, 모든 AI 논의가 결국 같은 방향으로 돌아감
그 AI 자동화에 넣을 문서를 만드는 해법도 AI를 쓰자는 식이라, AI로 문서를 만들고 AI로 요약해 넣고 AI가 설명하는 우로보로스 같음
코드도 똑같이 AI로 수천 줄을 만들고, 다시 AI로 설명하는 일이 벌어질 것임

“장교에는 영리한 사람, 근면한 사람, 어리석은 사람, 게으른 사람이 있고 보통 두 특성이 결합된다… 영리하고 게으른 사람은 어려운 결정을 내릴 명료함과 배짱이 있어 최고 지휘직에 적합하다. 어리석고 근면한 사람은 늘 피해만 만들기 때문에 어떤 책임도 맡기면 안 된다” — Kurt von Hammerstein-Equord
요즘은 LLM 덕분에 기여량만 보면 근면해 보이기가 너무 쉬움
차이는 이제 무능한 사람이 신중하고 경험 많은 엔지니어보다 문자 그대로 몇 자릿수 더 많은 산출물을 만들어낼 수 있다는 데 있음

내 경험상 성과가 낮거나 대충 버티는 사람들은 자기 코드를 읽지 않아서 꽤 투명하게 드러남
PR이 완벽한 관문은 아니지만 지금 가진 거의 유일한 관문 중 하나이고, 누가 노력하는지 아닌지는 꽤 분명함

“시스템을 이해하고 AI를 효과적으로 쓰는 사람과 LLM 복붙만 하는 사람을 구분하기가 훨씬 어려워졌다”는 건 괜찮음
면접 단계의 알고리즘 질문이 시스템 지식을 가진 척하는 사람들을 완전히 걸러줬을 테니까, 그렇지 않나?

“그건 코드 문제가 아니라 평가 문제다”, “코드가 귀중해지는 건 지식이 코드 안에만 살 때다”라는 말에 공감함
하루 종일 AI가 쓴 코드를 읽는 건 고통스럽고, 사람이 가장 유능해야 하는 순간에 뇌를 녹이는 끔찍한 방식임
수동 프로그래밍에는 코드를 읽고, 쓰고, 컴파일되거나 실행되거나 원하는 동작을 할 때까지 고치는 생산적이고 만족스러운 피드백 루프가 있음
AI 코드는 그 절반을 대신해줄 뿐 아니라 마지막의 “딸깍” 하는 순간도 덜 감동적임. 그 순간에 도달하려고 어딘가를 살짝 속인 건 아닌지 확신할 수 없기 때문임
AI 생성 코드를 프로그래밍의 유일한 지속 산출물로 삼는 건 업계의 막다른 길임
Charity가 흥미로운 작업 공간으로 가리키고, 올바르게 버리는 것은 아키텍처 다이어그램과 명세임
내 의심으로는 사람이 직접 쓰는 프롬프트, Markdown 계획, 유도문에 더 가까움
인간으로서 직접 만들어낸 것에 집중해야 “AI가 내 지시를 따랐는가”라는 핵심 루프의 기반이 되고, 코드 리뷰에서도 더 높은 지렛대가 됨
PR에 도달할 때쯤이면 Claude에 충분히 입력해서 코드를 다시 생성할 수 있을 텐데, 현재 업계 기본값은 그 세션을 전부 버리고 코드만 배포하는 것임. 이건 거꾸로임

동료가 5천 줄짜리 코드 리뷰를 던지면, 더 작고 검토 가능한 조각으로 쪼개서 다시 가져오라고 할 것임
큰 코드 덩어리는 인간이 사실상 리뷰할 수 없는데, LLM이 관련되면 많은 사람이 그 사실을 잊는 것 같음

하루 종일 AI 코드를 읽는 고통은 대규모 오프쇼어 팀을 상대하는 것과 매우 비슷함
매일 엄청난 코드 더미가 리뷰하라고 오고, 정말 지침
그래도 AI가 더 낫다고 느끼는 건, 규칙을 적어두면 적어도 따르는 경향이 있기 때문임
오프쇼어 개발자들 중 상당수는 같은 실수를 매일 반복함
우리 회사가 더 나은 오프쇼어 개발자를 뽑아야 하는 듯함

하루 종일 AI 코드를 읽는 게 고통스럽다는 데 동의함
예전에는 코딩을 통해 만들던 시스템에 대한 정신 모델의 일부를 이제 코드 리뷰에 의존해 형성하고 있음
시스템의 세부 사항을 이해하고 기억하는 일이 더 어려워지고 있는데, 스스로 “생성한” 정보가 읽기만 한 정보보다 더 잘 기억된다는 점을 생각하면 놀랍지 않음
교육학에서 얻은 교훈을 코드 리뷰 확장에 적용하고 있으며, 이 말이 와닿는다면 이야기해보고 싶음

프롬프트나 세션을 캡처하는 제품이 있는지 궁금함
임시방편으로는 Claude에게 세션 요약을 커밋 메시지 일부로 쓰게 할 수 있겠지만, 더 구조화되고 높은 수준의 도구가 있는지 알고 싶음

투입한 노력 대비 얻는 게 별로 아닐 수도 있음
잘 설계된 계획에 맞는 검증 가능한 코드를 원한다면 사실상 의사 코드를 작성하고 AI가 번역하게 해야 함
그럴 거면 애초에 왜 AI에게 코드를 쓰게 하는지 의문임
개인적으로는 직접 계획하고, 쓰고, 디버깅하는 게 더 재미있음. 그게 애초에 프로그래밍을 좋아하게 된 부분이기도 함

최근 이 생각을 정말 많이 하고 있음
소프트웨어 개발에 대한 내 직관의 상당 부분은 25년 동안 “어떤 코드를 쓰는 데 얼마나 걸리는가”에 쌓인 경험에 기반함
전체를 깨뜨리진 않지만 누군가 밟으면 약간 지저분해질 엣지 케이스 검증을 추가할지 고민할 때, 코드 몇 시간이 더 든다면 건너뛸 수도 있음
하지만 프롬프트 하나면 왜 안 하겠나?
새 기능을 이해하기 쉽게 만들려면 전용 API 탐색기가 있으면 좋겠지만, 예전에는 투자 정당화가 안 됐을 것임
그런데 Codex로 10분이면 된다면 이야기가 달라지고, 실제로 그랬음: https://tools.simonwillison.net/datasette-extras-explorer#ur... 릴리스 노트에서도 연결됨 https://docs.datasette.io/en/latest/changelog.html#extra-sup...
더 큰 규모로는 예전엔 아예 고려하지 않았을 프로젝트도 있음. 커스텀 SQLite SELECT 쿼리 파싱 라이브러리가 필요하긴 해도 일주일 이상 들일 만큼은 아니었음
하지만 지금은 가능해짐: https://github.com/simonw/sqlite-ast
코드 줄을 더 빨리 생산할 수 있다는 게 가치 있다고 하면 사람들이 매우 화내고 깔보기도 함
물론 “코드 줄 수”로 산출을 재는 건 멍청함
하지만 가치를 전달하는 검증된 코드 줄 수를 재는 건 멍청하지 않고, 이제 그걸 더 빨리 할 수 있음

최대한 공손하게 말하자면, 그래서 누가 신경 쓰나?
Google이 가치 있는 이유는 데이터를 빨아들여 광고 수익을 만들고, 수익 대비 지출이 작기 때문임
그 많은 “베팅”들은? 웃기지, 그래서 어떻게 됐나?
공학을 위한 공학은 경제에 아무 가치가 없고, 즉 무의미함
아무도 듣고 싶어 하지 않는 냉정한 진실은, 특정 시점의 경제 안에 존재할 수 있는 것은 제한되어 있고 가치가 있으며 경제적으로 지속 가능한 것만 살아남는다는 것임

“코드 줄을 더 빨리 생산할 수 있는 게 가치 있다고 하면 사람들이 화낸다”는 말에 대해, 어떤 사람들은 자기 이름을 걸어야 하는 것을 이해하는 것을 중요하게 여김
신경 안 쓰는 사람도 많지만, 신경 쓰는 사람도 있음

이 글이 좋았고, 다른 댓글 다수는 그렇지 않은 것 같으니 내 생각을 적어봄
새 코드베이스를 시작할 때 어떻게 최대한 빨리 도움이 되는 기여자가 될까? 나는 곧장 사람과 사람이 쓴 문서로 감
이 시스템이 원래 해결하려던 문제가 무엇인지, 원래 설계가 무엇이었고 가장 큰 문제가 무엇이었는지, 현재 누가 쓰는지를 확인함
이걸 알면 왜 그런 방식으로 만들어졌는지 추측할 수 있어서 코드 읽기가 훨씬 쉬워짐
이 블로그 글도 인기를 얻었음: https://blog.gpkb.org/posts/just-send-me-the-prompt/
Charity는 아주 오래된 문제를 보고 새 기술이 어떤 새 해법으로 이어질 거라 기대하는 듯함
현재 세대 도구가 AI 소프트웨어 개발 이야기의 끝이라고 생각하진 않을 것임
설계 문서를 Claude code에 던져놓고 떠나자는 말도 아님. 설계 문서도 완전하지 않아서, 온보딩할 때 사람과 이야기하고 오래된 티켓과 사후 분석도 읽어야 함
프로덕션에서는 인프라가 현재 상태가 된 이유를 알기 어려운 걸 싫어하기 때문에 지금은 인프라 코드화를 함
코드베이스 역시 “현재 상태가 된 이유를 알기 어렵다”가 기본 상태이고, 이는 “Programming as Theory Building” 이전부터 관찰된 문제임
그래서 인프라와 비슷하게, 소프트웨어 개발도 “코드가 현재 상태가 된 이유”를 더 명확하게 만드는 도구 중심으로 바뀔 것이라고 기대하는 듯함

반응이 이렇게 갈리는 건 인프라 코드화 경험과, 코드 외 산출물을 전혀 만들지 않는 엔지니어링 팀 경험의 차이 때문인지 궁금함
새 코드베이스에 들어갈 때 사람과 사람이 쓴 문서를 먼저 보는 방식이 맞지만, 많은 엔지니어링 팀에는 그런 문서가 전혀 없음
결정은 한 엔지니어의 머릿속이나 저장되지 않는 채팅에서 내려지고, 명세는 정리 중 삭제된 티켓의 몇 줄 메모였거나 추적 도구가 바뀌며 사라짐
코드베이스나 기능의 지도도 없고, ADR도 없고, 관측 가능성도 최소임
남는 건 코드뿐이라 코드를 읽어 무슨 일이 벌어지는지 알아내고, 특정 영역에 최근 커밋한 엔지니어에게 왜 그렇게 했는지 기억하는지 물어봐야 함
누군가 변경을 하면 전혀 관련 없다고 생각한 코드베이스 반대편이 깨지기도 함

글은 좋았지만 결론까지 가는 길은 좀 의아했음
AI에 더 많은 규율이 필요한 건 맞지만, 이론적으로 그 규율은 좋은 엔지니어가 되는 것보다 훨씬 쉽게 배울 수 있음
20년 전 좋은 확장 가능한 C 코드를 쓰려면 천재이거나, 기술 자체에 헌신해야 했음
ASan, LSan, UBSan, TSan, GDB 같은 수많은 도구를 손바닥 보듯 알아야 했고, DWARF 파일을 직접 읽어야 한다면 더 끔찍했음
짧은 시간에 마스터하기는 현실적으로 어렵고, 동시에 시스템 설계도 배워야 했는데 이는 거의 직교하는 별도 역량임
이제는 사용하는 언어와 프레임워크의 위험 요소를 알고, LLM에게 그것을 테스트하라고 지시하고, 충분히 테스트했는지 확인할 인프라를 갖추고, 실제 테스트와 구현을 읽으면 됨
Rust를 읽고 이해하는 건 Rust 개발 중 나오는 마법 같은 오류를 디버깅하는 것보다 훨씬 쉬움
특정 시나리오에 Loom 테스트가 필요하다는 걸 알아보고, 실제로 작성했는지 감지하는 도구를 만드는 것도 쉬움
C나 Zig를 계속 쓰더라도, 각 도구를 개별적으로 익히는 것보다 언제 써야 하는지 알고 감지하는 편이 훨씬 쉬움
SQL 읽기는 어렵지 않고 거의 절반의 비즈니스 종사자도 할 수 있음. Python은 겨우 조금 더 어렵고, Rust도 50쪽짜리 읽기 가이드를 보면 이해 가능한데, 시행착오로 10년을 보내는 비용에 비하면 아주 작은 대가임
“LLM은 알 수 없는 방식으로 작동한다”에서 “그러니 더 많은 규율이 필요하다”를 거쳐 “모든 것이 괜찮다”로 가는 길은 명확하지 않음
모든 것이 괜찮다는 데는 동의하지만 그 사고 과정이 분명한 경로라고 보진 않음
실제로 작동하게 만들려는 의지가 있고, 무엇이 실패하게 만드는지 조금 시간을 들여 이해하는 사람이라면 LLM을 활용해 엄청난 일을 해낼 수 있음
LLM은 복잡한 것을 만드는 비용을 거의 무료에 가깝게 만들기 때문에 오히려 상황을 훨씬 더 복잡하게 만들 것임
공학은 언제나 규율과 작동하게 만드는 것에 관한 일이었지만, 예전에는 가치 있으려면 선행 기술 집합이 필요했음
그 대부분이 이제 사라졌고, 전보다 훨씬 쉬워졌음
규율은 여전히 필요하지만, 불 속에서 10년을 구르는 것에 비하면 규율은 싸다고 봄

방금 이 약 200줄짜리 PR을 검토하는 데 일주일을 썼음: https://github.com/ncruces/wasm2go/pull/37
숙련된 사용자가 제출했고 아마 최전선 LLM에 물어봤을 가능성이 큼
그런데도 뭔가 잘못된 느낌이 들었음. 이해하지 못했고, 이해하지 못한 채 병합할 생각도 없었음
미래에 문제를 일으킬 방식으로 틀렸을 거라고도 의심했음
그래서 네 가지 방식으로 리뷰했음: 이해하고 개선하기, 더 나은 알고리즘으로 하기, 업스트림에서 문제를 고쳐 피하기, 내 머리에 맞게 처음부터 다시 쓰기
답은 두 번째나 세 번째일 거라 예상했지만, 두 번째는 맞는 답이긴 해도 그걸 쓰려면 프로젝트를 처음부터 다시 해야 했고, 세 번째는 정말 되길 바랐지만 안 됐음
결국 첫 번째와 네 번째를 섞게 됐고, 아직 완전히 확신하진 않지만 이제 문제와 해법은 이해함
내 접근이 더 낫다고 생각하는 건 당연함
그래도 양쪽 모두 주석을 제거한 뒤 LLM에게 리뷰를 시켰음
LLM은 원래 PR이 명백히 더 낫다고 답했고, 내가 왜 아닌지 설명하자 내가 맞다고 답했음
주석을 넣고 시도하면 LLM들은 내 것이 더 낫다고 말함. 내가 실제 문제를 찾았기 때문임
하지만 그게 내가 그렇게 말하도록 유도했기 때문에 내 것이 더 낫다고 말하는 건지 모르겠음

글을 읽어보니 “모든 모델은 틀렸다”는 격언을 잊은 것 같음
“현실적인” “시뮬레이션” RPG를 좋아하는 사람들이 흔히 하는 실수이기도 함
어떤 대상을 충분히 포괄적으로 모델링하면 그 모델은 그냥 대상 자체가 됨
실제 장소의 모든 세부 사항을 포함하는 위치 모델을 만들려면 1:1 축척 모델이 필요하고, 그건 결국 그 장소의 복사본임
시스템 기능의 100%를 신뢰성 있게 재현할 수 있을 만큼 충분한 계획, 즉 모델에 대한 프롬프트는 아마 그 시스템의 소스 코드 자체일 가능성이 큼

그 격언의 뒷부분은 “하지만 어떤 모델은 유용하다”임
IT와 프로그래밍의 상당 부분이 잘 이해된 조각들을 붙이는 일에 불과한지 자주 궁금했음
8년 전에는 LLVM을 훨씬 단순한 시스템으로 대체하고, 수작업 최적화를 단순한 AI “최적화기”로 바꾸면 왜 안 되는지 생각했음
단순 컴파일 코드를 “최적화된” 코드로 변환하도록 훈련하면 된다고 봤지만, 당시 합의는 AI 시스템이 쓸 수 있을 만큼 신뢰성 있게 올바른 코드를 만들기 어렵다는 쪽이었음
AI가 그런 저수준 코드도 대체할 수 없다면 고수준 문제는 당연히 훨씬 멀리 있어야 함
그런데 사람들은 고수준 문제에 AI를 씀
내 가설은 현대 디지털 엔지니어링의 많은 부분이 플러그 앤 플레이라는 것임

2023년 전에는 HN에서 모두가 코드 줄 수를 줄이는 게 가장 강력한 시니어 지표라고 떠받들었던 걸 기억함

아직도 그렇지 않나, 적어도 상당 부분은 그렇다고 봄
다만 LLM 코드 줄 수의 홍수를 거슬러 수영 경주를 이기기엔 흐름이 너무 셈
그리고 LLM이 좋은 코드를 쓸 수 있느냐는 글의 가정에도 동의하지 않음
작동하는 코드는 쓰지만, 데모고르곤이 쓴 것처럼 보여서 보면 좀 속이 안 좋아짐
나쁘긴 한데 인간이 절대 쓰지 않을 방식으로 나쁨
신입 개발자가 쓴 스파게티 코드를 읽을 때와는 다른 불쾌함이고, 배 속 어딘가에서 Cthulhu의 알이 부화하는 듯한 종류의 역겨움임

기능을 제거하지 않고 코드 줄을 줄이는 게 핵심임

단순화는 여전히 좋음
예전에 다니던 회사에서 한 시니어는 입사 후 매니저가 될 때까지 코드만 제거했던 게 기억남

이 글은 읽는 재미가 없었음
문장 자체나 각 문단은 괜찮았지만 전체로 보면 산만했고, 감히 말하자면 무의미했음
단어는 정말 많았지만 실제로 말한 건 너무 적어 보였음

이 글에는 충분한 생각이 들어가지 않은 것 같음
예를 들어 2025년에 코드 생산의 경제학이 뒤집혔다는 표현은 정확하지 않음
예전에는 제조 과정이 3D 프린팅처럼 엄격히 더하는 방식이었다면, 이제는 CNC 밀링처럼 빼는 방식이 보완된 것에 가까움
요구되는 “형태”는 별로 바뀌지 않았고, 특정 허용 오차를 신경 쓴다면 인간의 노력도 바뀌지 않았음
시장이 요구하는 정도만큼 여전히 제품을 소중히 여기고, 재사용하고, 돌보고, 큐레이션해야 함
“코드 줄은 리뷰하기에 이상적인 산출물이 아니다”라는 말에도 동의하지 않음
여기서 “이상적”이 무슨 뜻인가?
어릴 때 모든 시험에서 “풀이 과정을 보여라”가 규칙이었음
이유는 내일 출시할 제품만이 아니라 다음 세대의 정신 모델과 사고 과정을 개선하려는 것이기 때문임

블로그 글은 사람들이 반드시 독자가 아니라 스스로를 즐겁게 하려고 올리기도 하니, 나는 재미있게 읽었음

나도 비슷함. 글의 큰 아이디어는 좋지만, 구조와 장황함 때문에 다른 사람에게 공유하고 싶지는 않았음

왜 그런지 알 것 같음

메타지만, 읽다가 포기했음
언어가 따라가기 정말 어려웠고 글의 핵심도 눈에 띄지 않았음

이런 글을 보면 소프트웨어 엔지니어 일자리가 사라질 거라는 말이 더 의심스러워짐
2026년의 소프트웨어 엔지니어 일은 2020년과도 다르고, 1990년과는 말할 것도 없이 다른데, 왜 2026년의 일이 그대로 유지되거나 전부 없어지거나 둘 중 하나라는 거짓 양분법을 믿어야 하나?
아주 오래전 Google에서 일할 때 모든 코드를 리뷰한다는 생각이 새로웠음
그 전 MS에서는 코드가 CD에 구워져 박스에 들어가는 식이라, 프로젝트 끝의 위험이 큰 시점까지 대부분 리뷰되지 않았음
2000년에서 2004년 사이 소프트웨어 엔지니어가 시간을 쓰는 방식은 급격히 바뀌었고, 공유 이해를 늘리고 협업을 촉진했기 때문에 더 나아졌다고 봄
AI가 코드를 쓰고 인간이 리뷰에 더 많은 시간을 쓴다면 나쁜 일만은 아닐 수 있음
하지만 AI 코드가 충분히 좋아지면 철저한 리뷰를 선택 사항으로 여기게 될 것임
그러면 소프트웨어 엔지니어의 일은 예전과 매우 달라지고, 코드를 많이 쓰지도 리뷰에 많은 시간을 쓰지도 않게 됨
IDE는 도도새처럼 사라질 수도 있음
초점은 AI 코딩 팀이 과제에서 벗어나지 않게 하는 목표와 테스트 설정으로 옮겨갈 수 있음
프로젝트가 어디로 향하는지 잘 아는 소프트웨어 엔지니어가 아키텍처에 더 많은 시간을 쓸 수도 있음. 목표 지점이 합당하게 바뀔 때 AI가 이것저것 다시 쓰는 걸 원치 않을 테니까
탐색에도 더 많은 시간을 쓸 수 있음. 한 방식으로 만들고, 다른 방식으로 만들고, 또 다른 방식으로 만든 뒤 비교하고, 서로 다른 접근에서 새 아이디어를 생성하는 식임
누구보다 더 나은 예측을 가진 건 아니지만, 역할이 사라진다는 쪽에는 강하게 반대하고, 지금까지 여러 번 그랬듯 진화한다는 쪽에 찬성함. 다만 지금처럼 빠른 적은 없었을 수 있음

“코드를 영구적인 것으로 취급한 건 코드를 생산하는 노동이 병목이었기 때문”이라는 말은 맞지 않다고 봄
코드를 영구적인 것으로 여긴 이유는 코드를 진실의 원천으로 봤기 때문임
컴퓨터는 문서를 실행하지 않고 코드를 실행함
요구사항 문서가 코드와 모순된다면, 기본값은 요구사항 문서가 틀렸다고 보는 것이었음
코드를 명세와 분리할 수 없음. 코드가 곧 명세이기 때문임