다가오는 루프

루프는 미리 원하는 바를 충분히 이해하는 데 시간을 썼을 때 작동함. 전제는 명확성이고, 주니어 동료에게 넘길 수 있을 만큼 신중한 명세를 쓸 수 있을 정도여야 함
보통 그걸 이해하기까지는 망가진 엉성한 버전을 56번 거쳐야 함. 이 56번의 시행착오는 가속할 수 없고, 어떤 에이전트 기술도 인간 두뇌가 생각하는 시간을 피하게 해주지 못함. 그래서 대부분의 시간은 “내가 원하는 걸 모르겠다, 코드를 읽고 쓰고 만져봐야겠다”와 “이제 충분히 지나서 원하는 걸 아는 것 같다” 사이를 오가며 보냄. 스스로를 속이기 매우 쉽지만, 정말로 원하는 바를 알게 된 뒤에야 루프를 쓸 수 있음. 많은 사람이 에이전트로 앞질러 갈 수 있다고 생각하지만, 이해와 명확성은 흉내 낼 수 없고 그 단계를 건너뛴 사람은 고통스러울 정도로 티가 남

Codex에게 내 pi 세션을 모두 추출하는 도구를 만들게 했음. 프롬프트와 하위 에이전트 대화를 필터링해야 했고, 그다음 내가 만드는 패턴을 분석시켜 바깥쪽 가이드 생성 프롬프트의 흐름도로 바꿈
원하는 걸 오래 고민할 필요는 없었고, 그냥 그걸 하길 원했음. 결과는 아직 섞여 있고 섬세한 코드베이스를 맡길 정도로 신뢰하지는 않지만, 만들고 있는 게임에서는 확인에 쓰는 시간이 이전의 1/5로 줄었음. 꼭 좋은 일만은 아님. 시간을 덜 쓰면서 좋은 아이디어를 놓치고 있을 가능성이 큼. 다만 전에는 프롬프트가 기계적으로 #now-do-this, #now-review-that이 되었고 제안의 90%가 맞는 상태에서 정체돼 있었음. 이제는 “어려운 것부터 하고, 진행하면서 정리·리팩터링하라”와 첫 반환 뒤 “작업을 되돌아보라”를 자동으로 상기시켜 남은 문제를 털어놓게 한 뒤, 그걸 가이드 생성 프롬프트에 넣어 새 작업을 뿌리면 됨

망가진 버전 5~6개를 거쳐야 한다는 데 전적으로 동의함. 다만 내가 좋아하는 방식으로 대부분을 처리해준다고 믿을 수 있는 하네스(프롬프트 + 스킬 + 모델)를 찾고 나서는, 그 과정의 코딩·탐색 부분은 빨라졌음
반복은 빨라졌지만, 그 엉성한 버전들을 거치는 데 드는 노력은 거의 비슷함. 여전히 어떤 아이디어, 원칙, 설계가 해법에 맞는지, 다음에 뭘 시도할지 이해하고 내 정신 모델을 조정해야 하기 때문임. 결국 더 짧은 시간 안에 더 많은 정신적 노력을 쓰는 느낌이고, 코드 작성에서 조금 절약되는 정도임. 숙련되면 코드 타이핑 자체는 애초에 큰 비중이 아니었음. “그저” 프롬프트를 쓰고 코드를 읽는 것 같은데도 똑같이 지치거나, 압축된 반복 주기 때문에 더 지칠 때도 있음

이제 매일 이런 일을 겪고 있고, 낙담스럽고 걱정됨. 완전히 설명할 수 없는 코드를 더 많이 병합하는 이유는, 예전에는 코드 작성과 협업적 기술 계획으로 쌓던 정신 모델을 이제 코드 리뷰에 맡기고 있기 때문이라고 봄
코드 리뷰는 이 목적에 맞지 않음. 다만 교육학을 참고한 구조화된 연습을 코드 리뷰에 붙여서, 마찰과 이해 사이의 균형을 더 잘 맞출 수는 있다고 생각함. 이런 연습을 테스트해줄 도움을 찾고 있음

효과적으로 코드 리뷰하는 능력은 코드를 쓰는 것보다 훨씬 어려움. 변경이 시스템의 다른 부분에 어떤 영향을 주는지 좋은 지도가 없으면 사실상 도장 찍기 의식에 가까움
GitHub의 빈약한 PR UI도 도움이 안 됨. 직접 바뀌지 않았지만 영향을 받는 코드베이스 주변을 탐색해서 문제를 찾고 강조할 도구가 제한적임

당신 제품이 뭔지 궁금함. 에이전트 무리가 인간 기준의 100배 수준으로 개발한 제품이 어떤지 꼭 보고 싶음. 굉장할 것 같음

이런 코드는 보안 취약점으로 가득한 경우가 많음. 해킹 위에 해킹을 쌓은 꼴이고, 1천 줄로 더 안정적으로 만들 수 있었던 일을 이상한 대체 경로로 가득한 10만 줄 코드로 끝내게 됨
잘못된 경계 조건을 대체 경로로 처리하기보다 불가능하게 만드는 시스템을 선호해야 한다는 원문의 말은 매우 중요함. 대체 경로 방식은 대체 경로 위에 또 대체 경로를 구현하게 만들고, 각 대체 경로는 코드량을 기하급수적으로 늘리며 어쩐지 항상 새 문제를 만듦. 거의 “시스템 설계의 일반 법칙”이라고 불러도 될 정도임. 대체 경로는 실패 위험을 낮추지만, 실패가 실제로 일어나면 더 복잡하고 해롭게 만듦. 소프트웨어 엔지니어로서는 AI가 만드는 새 코딩 환경이 마음에 듦. 빅테크가 나를 위한 무한한 일을 만들어줬기 때문임. 인간 개발자는 코드 실행의 핵심 구성 요소가 되었고, 때때로 반드시 발생할 거의 무한한 어려운 미처리 예외를 처리하기 위해 항상 대기해야 함. 이제 소프트웨어 엔지니어는 노동자라기보다, 대부분 책상에 앉아 커피를 마시다가 드물게 문제가 생기면 개입하는 보안 요원에 가까워짐

몇 달째 말해온 것과 이어짐. LLM은 작업 완료에는 뛰어나지만, 미감과 취향에는 약함
일에는 두 종류가 있음. 하나는 목표 지향 작업으로, 달성할 목표가 있고 거기에 이르는 방식은 별로 중요하지 않음. 보안이 완벽한 예임. 시스템을 익스플로잇하려면 익스플로잇이 아름다운지는 거의 신경 쓰지 않고, 그저 극비 핵 계획에 접근하고 싶을 뿐임. 연구도 비슷해서, “연구 품질” 코드는 AI 시대 이전부터 악명 높게 엉망이었음. 다른 하나는 취향 지향 작업임. 큰 코드베이스에 기능을 추가할 때 목표가 그 기능 추가라고 생각하지만, 실제로는 아닌 경우가 많음. 코드베이스가 앞으로의 변경을 잘 받아들이게 유지하는 것이 그 특정 기능보다 훨씬 중요하고, 여기에는 취향이 필요함. 유지보수성과 코드 품질은 동의어가 아니며, 코드 품질은 수단일 뿐이고 그 목적은 유지보수성임

많은 조직이 코드 품질과 유지보수성을 전혀 우선순위로 두지 않는 세계로 빠르게 이동 중임. Claude가 코드를 쓸 거라면 그 코드가 “유지보수 가능”하거나 “품질이 좋은지”가 중요할까? 아니라는 관점임. 작동하고 빠르면 된다는 식임

LLM이 자연스럽게 잘못된 경우까지 처리하려 드는 문제는 많은 PR 리뷰에서 싸워온 부분임. 특히 이미 작성된 뒤에는 과도한 널 검사가 해롭다고 설득하기가 매우 어려움
더 나은 모델링, 그리고 합 타입을 허용하는 언어가 아니라면 이런 “산탄총 파싱”에 보편적으로 먹히는 반론을 아직 찾지 못했음. 어쩌면 정말 큰 문제가 아닐 수도 있음. 하지만 코드베이스를 실제로 읽고 리팩터링할 때는 이런 불필요한 검사를 관리하는 게 늘 답답했음. 일단 들어간 뒤에는 로깅이나 광범위한 조사를 먼저 추가하지 않고서는 안전하게 삭제하기 거의 불가능할 때도 있음

자주 통하는 논리는 선택값이 사실상 프로그램이 가질 수 있는 가능한 상태 공간을 분기시킨다는 것임. 상태 공간이 커질수록 코드를 추론하고 유지보수하기 어려워짐
이것이 바로 바람직하지 않은 상태를 표현 불가능하게 만든다는 말의 핵심이기도 함

AI 코드 리뷰는 과도하고 망상적인 방어적 편집증을 부추김. 함수 깊숙한 곳에서 삼중 널 검사를 하는 건 기술적으로는 실제 위험일 수 있지만, 실제로는 그 함수를 호출하거나 호출할 수 있는 모든 함수에서 이미 널 검사를 했기 때문에 절대 도달해서는 안 되는 경우가 많고, 굳이 방어할 가치가 없을 수 있음

얼마나 불가능한 경우를 말하는지가 중요함. 나는 꽤 방어적 프로그래밍을 하는 편임
지금은 아무것도 이 함수에 음수를 보내지 않더라도, 미래의 코드 변경으로 그 가정이 깨지는 게 얼마나 어려울까? 명확한 오류가 최선이라고 늘 생각했음. 코드에 익숙하지 않은 사람도 입력의 유효 범위에 어떤 가정이 있는지 알 수 있고, 불가능한 이상치를 고려할 필요가 없어짐

내 병목은 명세에 있음. 에이전트 루프는 이제 나에게 덜 중요한 문제가 됨
만들고 싶은 것에 대한 명확한 이해를 얻고, Claude Code의 계획 모드에서 실행 가능한 명세를 쓰는 것을 목표로 전달하면, 에이전트가 구현에 들어갔을 때 대체로 매우 좋은 결과가 나옴. 하지만 효과적인 이 전략은 명세를 쓰는 부담을 나에게 크게 줌. 에이전트는 각 명세를 대개 훌륭히 처리하고 코드 리뷰 기반 후속 작업도 보통 2~3번이면 되지만, 곧 다시 명세가 필요한 단계로 돌아옴. 또 내가 자리를 비웠을 때 에이전트가 한 작업을 끝냈고 파일이 겹치지 않아 충돌이 없는 기존 명세를 시작할 수 있어도, 새 브랜치를 만들고 시작해도 된다는 걸 모름. 자기 전 “작업 X를 하고 완료·푸시한 뒤 작업 Y를 시작하라”고 말하곤 하지만 그 이상은 잘 안 됨. 종종 Y를 시작하다 질문이 생기고, 그 뒤 에이전트는 남은 시간 내내 멈춰 있음. 마지막 문제는 위와 결합된 의존성임. 예를 들어 오늘은 백그라운드 작업 처리기를 작성했는데, 당연히 이후 작업의 잡들은 그 시스템을 필요로 함. 이런 일이 꽤 자주 생김. 구현 중 결정된 세부사항을 반영하려면 명세 자체도 구현 후 갱신해야 함. 그래도 이제 바깥쪽 루프가 필요해지기 직전임. 관문은 거의 전적으로 명세 작성과 PR 리뷰에 있음. 그 관문이 중요하지 않은 곳에서는 에이전트가 계속 굴러가길 원함. 덧붙여, 우리에게는 나쁘더라도 LLM에게 더 좋은 도구를 쓰기 시작해야 한다고 강하게 믿음. 예를 들어 Rust는 컴파일러가 너무 엄격해서 나에게는 성가시지만, LLM에게는 훌륭함

바로 이런 방식이어야 함. 훌륭함. 지난 20년 동안 빨리 만들자는 흐름 속에서 축소돼온 시스템 엔지니어링의 가장 중요한 부분임
이제 만들기가 더 자동화됐으니, 명세와 시스템 설계가 다시 중요한 선두 역할을 할 수 있음. 엔지니어링과 품질이 돌아올지도 모름

내 코딩 경험과도 맞고, AI가 아직 코딩을 해결하기까지 갈 길이 멀다고 몇 년간 말해온 기대와도 맞음. 프로그래밍의 어려운 부분은 키를 눌러 파일에 코드를 넣는 게 아니라, 문제를 이해하고 깔끔하고 확장 가능한 좋은 해법을 떠올리는 것임
AI는 기술적으로 작동하는 괜찮은 해법을 만드는 데는 뛰어나지만, 해법에 대한 좋은 비전을 갖는 데는 꽤 약함. 아이디어를 주고받고 탐색하면서 이해를 높이는 데는 여전히 매우 유용하지만, LLM이 구현할 좋은 명세를 쓰는 일이 직접 코드를 쓰는 것보다 훨씬 쉽지는 않음

“매우 좋은 결과”를 어떻게 정의하는지가 궁금함. 성공의 정의에 깔끔하고 유지보수 가능한 코드가 포함되는가? 나는 계속 루프 안에 있어야 함. 내 코드는 수천 명의 사용자에게 배포되기 때문에, 어떤 문제든 증폭됨

“명세 작성”이 프로그래밍의 본질적 복잡성임. 결국 은탄환은 없다는 말임
에이전트가 있든 없든, 천공카드든 인터프리터든, 끝내 프로그래밍은 프로그래밍임

LLM의 가장 큰 코드 냄새는 “모든 잘못된 경우를 처리”하려고 하고, 이제는 불가능한 오류까지 처리하려 든다는 점임. 왜 그렇게 집착하는지 모르겠음
Python에서는 완전히 타입 검사되는 코드베이스에서, 해당 속성이 있다고 정의된 타입에 hasattr 검사를 붙이는 식으로 자주 나타남. 왜 이러는 걸까? 사전 학습 때문인지, 강화 학습 때문인지 궁금함. 후자라면 연구소들이 고쳐줬으면 함

아마 누락된 오류 처리보다 불필요한 오류 처리 쪽으로 실수하는 편을 택하기 때문일 것임. 학습에서 런타임 오류를 강하게 벌점 처리할 가능성이 큼

대부분은 학습 데이터 때문이라고 봄. 나도 “잘못된 상태를 표현 불가능하게 만들자” 팀임
HN에서는 이 얘기가 많이 나오지만, 오픈소스든 직장이든 내가 작성하지 않은 코드베이스가 이걸 정말 잘하는 걸 보면 아직도 놀람. 대부분의 프로그래머는 오류가 발생하지 않게 만들고 데이터가 그 사실을 반영하게 하기보다, 오류 메시지가 튀어나오는 지점에서 조각을 주워 고치는 식으로 생각함. “대부분”이라고 한 건 현재 AI에도 이런 사고방식 자체의 문제가 있다고 보기 때문임. 인간이 코드베이스를 마지막 단계에서 이해하는 수준, 즉 보장의 흐름을 전체적으로 이해하는 수준을 지금 AI에게 주기는 어려움. 원시 코드 수준에서는 이런 보장이 컨텍스트 창을 쉽게 터뜨릴 만큼 많은 코드에 걸쳐 있는 경우가 많음. 메모리식 파일로 요약하려 해도 문제가 있음. 보장에 대한 텍스트가 적혀 있다고 해서 AI가 올바른 정보를 꺼낸다는 뜻은 아니며, 인간도 코드만 읽고는 마찬가지임. AI에게 이런 이해를 주는 것이 “불가능”하다고는 말하지 않겠지만, 설령 이해하게 만들더라도 AI의 작업 방식은 그 이해에 자주 반대로 작동함. 내 해결책은 대체로 AI가 이걸 이해하길 포기하는 것이었음. 보통 사람들이 하듯 문제 해법을 프롬프트로 만들고, 나쁜 잘못된 상태를 표현 불가능하게 만들고 싶으면 필요한 리팩터링 과정을 AI에게 단계별로 시킴. 아주 작으면 직접 함. 맵/딕셔너리, 배열, 문자열, 정수로 가득한 코드를 더 철저히 타입화하도록 단계적으로 시키면 실제로 꽤 잘함. 아무리 자세히 써도 단일 프롬프트로 좋은 설계가 나오는 경우는 많지 않았음. 두 개의 별도 작업으로 다루는 편이 잘 맞음. 그리고 타입의 차이를 주의 깊게 봐야 함. AI는 .JustSetItAndIgnoreAllThePreAndPostConditions(string) 같은 메서드를 몰래 끼워 넣는 걸 좋아함. 현장에는 “오류 상태를 표현 불가능하게 만들도록 잘 구조화된 타입에 나중에 유지보수자가 와서 모든 걸 깨는 JustEffingDoIt 메서드를 추가한” 학습 데이터가 많을 것 같음. 가장 좋은 방어 중 하나는 이런 타입을 자체 파일에 두고, 추가된 모든 메서드를 쉽게 훑어보며 그런 짓을 하면 바로 잡는 것임. 문서에 하지 말라는 경고와 유지되는 사전·사후 조건을 잔뜩 적어봤지만 변화는 미미했음

학습 세트에 있는 코드베이스의 압도적 다수가 완전히 타입 검사되지 않았거나, 전혀 깨끗하지 않기 때문임. 혹은 Stack Overflow 조각들이라 기존 맥락이 없어서 널 검사가 유효하지 않다고 가정할 수 없는 것일 수도 있음

정말 공감함. 모든 dataclass에 getattr을 쓰는 건 기묘한 선택임

학습된 패턴과 맞기 때문임. AI는 코드를 이해하지 못함. 실제 논리 흐름을 추론할 수 없고, 패턴만 다룰 수 있음

코드는 정보 시스템에 대해 공유되고 쌓인 이해의 일부임
이런 루프가 우리 모두를 지속적으로 밀려오는 소프트웨어의 파도 속에서 움직이게 만든다면, 가장 높은 수준의 논리적 정보 시스템 설계에서는 결국 인간의 판단과 비즈니스 요구사항 균형이 전부가 됨. 회사나 시장의 특정 틈새에 맞추려면 모든 프로그래머가 비즈니스 분석가, 시장 조사자, 사업가가 되어야 함. 단, AI 도구가 잘 “덜컹거리지” 못하는 특정 틈새나, 보조금이 붙은 AI 토큰 시대가 끝나 이 모든 루프가 너무 비싸지는 경우는 예외임. 이는 전문가 시스템과 Symbolics Lisp 머신의 반복처럼 느껴짐. 잠깐 동안 우리가 마주친 사실은, 코드 자체가 무언가를 못 한다기보다 회사의 조직 구조가 결국 소프트웨어에 그대로 실리므로, 회사 조직을 바꿀 수 없다면 소프트웨어의 유연성에도 한계가 있다는 점이었음. 데이터 흐름도와 도메인 지식, 도메인 모델링, 보편 언어가 우리가 품질, 기능, 비기능 표준과 관례를 정하는 메타언어가 될 수 있음. “루프를 도는 clanker”들이 “완료”라고 말하기 전에 데이터·동작·성능 계약을 충족하게 만들어야 함. 이제 “완료”는 컴파일되는 코드, 빌드되는 코드, 배포되는 코드, 심지어 운영에 올라간 코드만을 뜻하지 않음. 사용자 요구, 운영자 요구, 유지보수자 요구를 모두 충족하는 코드여야 함. 그래서 쓰이는 언어는 우리 모두를 문법을 아는 사람보다 비즈니스 분석가와 소프트웨어 아키텍트에 더 가깝게 만들 수 있음. UML의 복수와 선언형·논리형 설계·BDD의 귀환일까?
오타 검사는 gemma4-12b로 했지만 메시지를 바꾸게 하지는 않았음

언제부터 내가 루프 안에 억지로 들어가 있지 않아도 되는지 계속 생각함. 개발자로서 코드 구조를 다듬고, 더 명확하게 만들고, 좋은 추상화를 생각하고, 모듈로 나누는 일을 정말 좋아함
거기서 즐거움을 느끼지만, 어느 순간 내가 제한 요인이 된다는 것도 이해함. 소프트웨어의 목적이 사람들에게 이익을 주는 것이라면, 코드가 어떻게 보이는지 여전히 신경 써야 할까? 지금은 답이 “그렇다”라고 생각하지만, 3년 뒤에는? 10년 뒤에는?

소프트웨어가 계속 사람들에게 이익을 주길 원한다면, 답은 그렇다임

기술 외에는 별 의미를 느끼지 못하는 곳에 있다면 힘들 수 있음. 곧 더 충족감 있는 일로 향하는 실존적 전환이 올 것 같음. 순진한 생각일 수도 있고, 그냥 내가 나 자신에게 필요하다고 느끼는 것일 수도 있음

리팩터링은 언제든 에이전트에게 시킬 수 있음. 생각만 해도 지칠 만큼 큰 리팩터링도 해낼 수 있음

무언가가 판단을 많이 요구하고 “내가 깊이 아끼는 코드”라면, 여기서 말하는 방향에는 동의하기 어려움. 깊이 신경 쓰는 결정을 위임하려 하지 말아야 함 에이전트 루프와 하네스 루프라는 구분은 마음에 들지만, 미리 정확히 명세할 수 있는 것만 위임해야 함. 내 경우 대개 반복 가능한 작업, 예를 들어 “X를 어떻게 했는지 보고, Y에도 그렇게 해” 같은 것들이고, 이는 본질적으로 예측 가능한 일임. 내 판단이 빠지면 결국 내가 “아니”라고 할 일이라면, Armin이 말한 에이전트 루프 안에서 협업하는 쪽으로 내려와야 함. 그건 완전히 괜찮음. 빠르면서도 안전함. AI 코딩 도우미 이전에도 가끔 엄청나게 생산적인 엔지니어가 팀에 들어오곤 했음. 동료들은 “너희가 그걸 다 해낸 건 팀에 X가 있어서잖아!”라고 부러워했지만, 그런 사람을 곁에 두는 저주를 겪어보진 못한 것임. 완벽히 정렬돼 있지 않으면, 그들은 엄청난 속도로 잘못된 방향으로 달려감

깊이 신경 쓰는 결정을 위임하지 말아야 함. 아니면 그 결정을 넣을 결정론적 방법을 찾으면 됨

정확함. 고도로 숙련됐다고 생각하는 사람에게도 외주 주지 않을 일이라면, 왜 기계에 외주 주겠음?

이게 실제로 무슨 뜻인지 모르겠음. 더 큰 그림을 암시하도록 설계된 것 같은 추상 개념을 늘어놓는 장황한 글일 뿐이고, 결국 AI가 코드를 써주게 하는 이야기임
앞으로 이렇게 되는 건가? 사실 우리는 생각의 리더가 아니라, AI 바보 무리를 정답 쪽으로 몰아가려는 유사 교사가 되어 가고 있는데, 여전히 사고의 리더처럼 보이려고 역할을 신비화해야 하는 건가? 그게 전부 기술 허세라는 걸 들키지 않으면서?

이건 장황한 글도 아니고 추상적이지도 않음. 여기의 내용은 덜 감독되는 방식으로 “AI가 코드를 쓰게 하는 것”의 2차 효과에 관한 것임
글쓴이가 더 간결하게 다듬을 수는 있었겠지만, 현재 수준에서 독자가 내용을 이해하지 못한다고 해서 신비화가 일어나고 있다는 뜻은 아님

AI 과대광고를 받아들이면 저렇게 떠들게 됨. Yegge는 더 심한 예임

소프트웨어 엔지니어링 분야가 둘로 갈라지고 있다고 확신함. 이것들은 실제 우려이고, 에이전트 루프와 강한 AI 보조 작업 흐름을 써온 개발자에게는 말이 되는 일관된 논리임
나는 직장과 개인 프로젝트에서 원문이 말하는 바를 정확히 보고 있는데, 누군가는 이것을 “추상 개념을 늘어놓는 장황한 글”로 본다는 점이 무서움. 대다수가 지금 벌어지는 일을 전혀 모른다는 생각이 듦

예전 기술 블로그는 바로 실행 가능한 README 가이드처럼 읽혔음. 이 글은 읽으면서 “이 정보로 뭘 하라는 거지?”라는 생각이 들어 끝까지 못 읽었음
AI 분야에서 최신 최고 기술의 유통기한은 2주 정도임. Ralph Wiggum 루프를 따라잡지 못했는데, 이제는 시도하지 않길 잘했다고 느낌 https://news.ycombinator.com/item?id=46682325