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

 (charitydotwtf.substack.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • AI 코드 생성 품질이 높아진 것은 코드 리뷰를 버리라는 신호가 아니라, 코드가 싸고 빠르게 재생성되는 환경에서 검증과 운영 규율을 더 강하게 요구함
  • 2025년 말 Opus 4.5 이후 AI는 흔한 패턴에서 중간 수준 소프트웨어 엔지니어에 가까운 코드를 더 빠르고 저렴하게 만들 수 있게 되었고, agentic harness·도구 사용·function calling·MCP가 이 전환을 뒷받침함
  • 코드 생산 비용이 거의 0에 가까워지면서 코드 줄은 귀중하게 보존할 자산이 아니라, 현재의 이해를 물질화한 재생성 가능한 캐시에 가까워짐
  • immutable infrastructure가 실행 중인 서버를 고치지 않고 교체하게 만든 것처럼, AI 시대의 애플리케이션 코드도 변경 자체보다 행동 검증, characterization test, capture/replay, 트래픽 분할, 관측 가능성이 중요해짐
  • 비결정적 시스템은 인간이 품질 게이트로 버티는 방식보다 trace, production eval, 빠른 피드백 루프 같은 엔지니어링 규율을 요구하며, AI는 소프트웨어가 여전히 기술자와 규율을 필요로 한다는 사실을 없애지 않음

2025년에 뒤집힌 코드 생산의 경제성

  • 2025년 대부분 동안 AI 생성 코드는 “slop”이며 계속 그럴 수 있다는 입장이 합리적이고 주류적인 판단이었음
  • 2025년 11월 Opus 4.5 이후, AI는 적어도 흔한 패턴에서는 중간 수준 소프트웨어 엔지니어와 비슷한 품질의 코드를 훨씬 빠르고 싸게 생성할 수 있게 됨
  • Opus 4.5는 단일 원인이라기보다 티핑 포인트에 가까움
    • agentic harness는 LLM을 도구와 함께 루프에 넣는 코드 구조임
    • 이런 하네스는 2025년 중반 현실적인 형태가 되었고, 전조는 2024년 말까지 거슬러 올라감
    • tool use, function calling, MCP가 2025년 동안 쌓이며 연말에 범용 사용성으로 이어짐
  • 첫 번째 변화에서 “보면 믿겠다”는 회의는 용인될 수 있었지만, 같은 속도의 변화가 다시 나타나는 상황에서는 같은 태도를 유지하기 어려움

코드가 귀한 자산에서 재생성 가능한 산출물로 바뀜

  • 2025년에 일어난 핵심 변화는 코드 생산의 경제성이 뒤집힌 것임
    • 코드를 생성하는 일이 어렵고 오래 걸리고 비싸던 상태에서, 사실상 즉시 가능하고 저렴한 상태로 바뀜
    • 코드 줄은 재사용하고 보살피는 대상에서 버릴 수 있고 다시 만들 수 있는 대상으로 이동함
  • 소프트웨어 엔지니어링 팀의 진짜 산출물을 공유된 이해로 보는 관점도 있음
    • 그 이해는 사람들의 머릿속에 캐시처럼 저장되고, GitHub 커밋과 프로덕션 배포로 디스크에 내려감
    • 하지만 사람의 기억은 잊기 쉽고, 반복에 무뎌지며, 작은 세부사항을 놓치기 쉬움
    • 머릿속 모델은 사용자가 실제로 만나는 세계와 계속 어긋남
  • SRE 관점에서는 좋은 소프트웨어 팀의 진짜 산출물이 프로덕션에 있음
    • “Only prod is prod”
    • 프로덕션은 개발 이후의 장소가 아니라 개발의 한 단계로 다뤄져야 함

Phoenix Architecture와 immutable infrastructure의 유사성

  • Honeycomb은 2025년 8월 AI mandate를 냈고, devtools 회사로서 최신 기술의 어려운 문제를 다뤄야 한다고 판단함
  • Chad Fowler의 Phoenix Architectures는 AI 코드 시대를 immutable infrastructure와 연결함
    • Chad Fowler는 2013년에 “immutable infrastructure”라는 말을 만든 인물임
    • Relocating Rigor는 Martin Fowler가 Thoughtworks meetup 요약에서 언급한 글임
  • The Death and Rebirth of Programming의 핵심은 실행 중인 것을 고치지 말고 교체하라는 원칙임
    • immutable infrastructure, stateless services, containers, blue-green deployments, infrastructure as code는 모두 같은 전제를 공유함
    • AI는 이 전제를 인프라에서 애플리케이션 코드로 확장함
    • 재작성 비용이 낮아지면 제자리 수정은 위험해지고, mutation은 엔트로피를 쌓으며, replacement는 그것을 리셋함
  • The Deletion Test는 구현 전체를 삭제한다고 상상하게 함
    • 삭제가 두려운 이유는 코드 자체보다 필요한 동작, 허용할 수 없는 실패, 항상 지켜야 할 불변조건, 새 버전의 정확성 판단 기준을 모르기 때문임
    • 잊힌 엣지 케이스를 고친 버그가 무엇인지 모르는 것도 같은 문제임
    • 이는 코드 문제가 아니라 평가 문제임
  • 코드가 지식이 사는 유일한 장소일 때 코드는 귀중해짐
    • 과거에는 코드를 만드는 노동이 병목이었기 때문에 코드를 영속적 자산처럼 다루는 것이 합리적이었음
    • 재생성이 쉬워지면 코드는 현재 유용하지만 낡으면 버릴 수 있는 이해의 물질화된 뷰처럼 작동함

서버를 재생성하듯 코드를 재생성할 수 있어야 함

  • handcrafted server pets에서 immutable infrastructure cattle로 이동한 경험은 mutability가 이해의 적이라는 교훈을 남김
    • 실행 중인 산출물을 제자리에서 고치면 drift가 생김
    • drift는 시스템 유지보수를 어렵게 만듦
  • Honeycomb은 매주 화요일 cron으로 가장 오래된 Kafka 노드를 죽임
    • 이 방식 때문에 부트스트래핑과 밸런싱 프로세스가 반복 가능하다는 확신을 가질 수 있음
    • 데이터는 재생성 가능하고, 중요한 약속은 다른 곳에 있음
  • 코드를 같은 방식으로 재생성할 수 없다면 그 코드를 충분히 이해하지 못하는 신호임
    • 어떤 약속을 했는지 모름
    • 어떤 의존성이 깨질지 모름
    • 대부분은 깨뜨려 보면서 발견함
  • 오래 걸리고 고통스러운 migration, rewrite, legacy code 교체, strangler fig는 코드 줄이 너무 많은 책임을 떠안았던 사례임
    • 코드에는 개발자 의도, 사용자 기대, 암묵적·명시적 동작, 과거 버그의 흔적이 함께 묶여 있었음

리뷰 대상은 코드 줄만이 아님

  • 코드 줄을 유지하고 변경하는 비용이 컸기 때문에 다른 산출물들이 충분히 발전하지 못했음
    • 아키텍처가 어떻게 변하는지 이해하고 토론할 산출물이 부족함
    • 아키텍처 자체도 코드에서 어렴풋이 추론되는 경우가 많음
  • 이상적인 방향은 아키텍처 다이어그램을 토론하고 합의한 뒤, 그 변경에서 코드를 재생성하는 방식에 가까움
  • 모든 코드가 인간 이해를 우회해 AI가 명세대로 생성하게 된다고 단정할 수는 없음
    • 전체 가능성은 spec이 무엇인지, 또는 무엇이 될 수 있는지에 달려 있음
    • 고통스러운 데이터베이스 migration을 겪어 본 사람이라면 사용자 기대를 재생 가능하고 자동화 가능한 형태로 추출·형식화하는 일이 어렵다는 점을 알아야 함
  • 도구는 아직 없지만 관련 아이디어는 이미 있음
    • 운영과 QA에서 온 behavioral test, characterization test, capture/replay, traffic splitter가 해당됨
    • 이 기법들은 무엇이 옳아야 하는지보다 실제로 무엇이 일어나고 있는지를 관찰하고 인코딩하는 데 가깝음
    • 좋은 의미의 observability가 여기에 포함됨

인간은 검증용 품질 게이트에 적합하지 않음

  • 프로덕션의 비결정적 코드는 이전부터 했어야 할 일을 강제로 하게 만듦
    • trace 계측
    • production에서의 test와 eval
    • 프로덕션을 개발 이후가 아니라 개발 단계로 다루는 방식
  • 사람의 뇌는 검증에 적합하지 않음
    • 반복적이고 사소한 차이를 계속 확인하는 일에서 기계보다 약함
    • 인간의 역할을 품질 게이트 능력에만 두면 소프트웨어 품질은 취약해짐
  • 인간은 창의성, 영감, 논리적 도약 등에서는 오래 역할을 유지할 수 있지만, validation에서 기계를 이기는 주체로 두기는 어려움

AI 시대의 결론은 규율의 복귀

  • 지난 2년의 AI 담론이 많은 엔지니어에게 낯설고 두려웠던 이유는, 일부 AI 목소리가 소프트웨어가 더 이상 엔지니어링 문제가 아니라고 말하는 것처럼 보였기 때문임
    • “SaaS is dead”
    • “Making AI great at coding was the strategy that unlocks everything else”
    • Adam Jacob은 소프트웨어 일자리의 큰 변화를 예상하는 인물로 다뤄짐
  • 2025년이 vibe coding의 해였다면, 2026년은 규율로의 복귀처럼 보임
    • AI가 중간 수준 소프트웨어 엔지니어만큼 코드 줄을 생성하게 되면서 가능한 미래의 범위가 불안정하게 넓어졌음
    • 머릿속 지식은 시스템에 인코딩되기 전까지 AI가 사용할 수 없음
  • 빠르고 짧은 피드백 루프에서 일하는 소프트웨어 팀은 매우 적음
    • 비율은 5% 정도, 확실히 10% 미만으로 제시됨
    • AI 도구는 이 방식을 이전보다 더 가까이 가져올 수 있음
  • 엔지니어링 규율 없이 AI만으로 거대한 투자수익이 생기는 상황은 가까운 시기에는 우려 대상이 아님
    • 많은 팀이 시도하겠지만, 가치가 있는 것은 disposability가 아니라 durability에 의해 뒷받침됨
  • 사용자는 매일 Slack에 로그인할 때 버튼과 메뉴가 미묘하게 바뀌는 것을 원하지 않음
    • 금융 거래가 대부분의 경우에만 완료되는 것도 원하지 않음
    • determinism은 사라지지 않음
  • AI는 마법이 아니며, 소프트웨어는 여전히 엔지니어링임
    • 기술은 technologist를 필요로 함
    • 앞으로 검토해야 할 산출물은 코드 줄만이 아니라 다른 종류의 엔지니어링 산출물로 넓어짐

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 이제는 누가 시스템을 이해하고 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가 이것저것 다시 쓰는 걸 원치 않을 테니까
    탐색에도 더 많은 시간을 쓸 수 있음. 한 방식으로 만들고, 다른 방식으로 만들고, 또 다른 방식으로 만든 뒤 비교하고, 서로 다른 접근에서 새 아이디어를 생성하는 식임
    누구보다 더 나은 예측을 가진 건 아니지만, 역할이 사라진다는 쪽에는 강하게 반대하고, 지금까지 여러 번 그랬듯 진화한다는 쪽에 찬성함. 다만 지금처럼 빠른 적은 없었을 수 있음

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

답변달기