코드는 볼 필요 없어, 클랭커가 알아서 하게 둬.
내 이름이 PR에 붙어 있고, 문제가 생길 때 밤에 호출을 받는다. 게다가 나는 이 모든 노력에 참여하게 된 이유가 코드가 정말 마음에 들고, 누가 또는 무엇이 작성했든 상관없이 그것을 보고 싶기 때문이다. 그래서 내가 검토할 것이다.
솔직히 말해서, 내가 유일한 사용자로서 장난감을 만들고 시간 투자를 원하지 않는다면, 클랭커에게 스스로 하게 시킬 것이다. 그리고 내가 요청했다고 생각했던 저주받은 꿈의 결과로 생긴 루브 골드버그(Rube Goldberg) 같은 혼란 더미에 내 깨끗하고 섬세한 손을 넣지는 않을 것이다.
다른 모든 것에 대해서는, 나는 코드를 보고 싶다.
나는 내 엔지니어링[^5]의 품질, 즉 흔히 “나만의 기술(my craft)”이라고 불리는 것에서 큰 자부심을 느낀다. 그것은 나의 정체성의 일부이다. 단순성, 신뢰성, 보안, 비용, 성능, 유지보수성 등을 균형 있게 맞추는 솔루션을 찾는 것이다. 나는 프로덕션 환경(prod)에서 무언가를 망가뜨릴 때 끔찍하게 싫어한다. 그것은 개인적인 실패이며, 수치심을 느끼게 하고, 내 평판에 더러운 얼룩처럼 느껴진다. 작동하지 않는 것들을 배포할 때도 싫어한다. 그리고 다른 사람의 것이 고장 났는데, 내 크고 못생긴 얼굴이 그들의 PR 옆에 어리석은 “👍 LGTM”과 함께 붙어 있을 때도 싫어한다. 내가 어떤 소프트웨어 조각을 망쳐서 누군가 잠에서 깨어나게 할 때, 나 자신도 잠을 이루지 못한다. 그것이 최악의 기분이다.
이러한 접근 방식은 기계(clanker)가 작성한 코드를 맹목적으로 신뢰하는 것과 양립할 수 없습니다. 그 코드는 95%의 시간 동안 기능적일 수도 있습니다1. 괜찮을 수도 있고, 심지어 당신이 직접 만든 것보다 나을 수도 있습니다. 하지만 95%는 100%가 아닙니다. 그것은 무언가를 놓칩니다. 호기심이 없습니다. 인간처럼 배우지 않습니다. 멈춰 서서 질문하지 않습니다. 제한된 컨텍스트 윈도우를 가지고 있습니다. 전체 학습 과정은 점수를 최대화하는 것입니다. 유일한 목표는 작업을 완료하는 것뿐입니다. 마치 훈련 중인 강아지처럼, 당신이 준 프롬프트와 어느 정도 일치하는, 반쯤 씹고 침으로 가득 찬 '무언가'를 내놓습니다. 그런 다음 그것은 꼬리를 흔들며, 만화경 같은 눈으로 당신을 바라보며 말합니다. “봐요, 제가 해냈죠. 저를 사랑해 주실 건가요?”. 작업하는 코드베이스가 클수록 쓰레기를 도입할 확률이 높아집니다. 그리고 그 쓰레기는 더욱 복잡하게 쌓여서, 이전의 덜 정교했던 형제들이 만들어낸 공포 위에 또 다른 것을 구축합니다.
오, 코드를 빨리 작성하네요! 저보다 훨씬 빠릅니다. 그리고 대부분의 경우(검토 후), 그 코드가 제가 직접 만든 것보다 더 좋습니다. 게다가 시간도 훨씬 적게 걸립니다. 유용합니다. 멋진 도구입니다. 저는 “사용하지 마라”고 말하는 것이 아닙니다. 저는 이렇게 말하고 싶은 것입니다. 당신의 이름이 PR에 올라 있고, 페이저(pager)가 온콜 로테이션에 있다면, 그 코드는 당신의 것이며, 당신은 그것을 읽고 이해해야 합니다.
이 단계에 이르러 우리는 모두 자동화 시스템(clanker)이 독특하고 폭발적이며 장관적인 방식으로 문제를 일으켰던 전투 이야기를 가지고 있습니다. 너무 오래 자유롭게 방치하면 미쳐버립니다. 생명 유지 수준의 컴포넌트를 제거하는 최적화(Optimizations). “이것은 건드리지 마시오”라고 표시된 코드가 완전히 망가진 경우. 부주의하게 끌어들인 라이브러리들. 과정에서 자체적으로 발명한 기능들. 통과시키기 위해 수정된 단위 테스트(Unit tests). 도달할 수 없는 엣지 케이스(edge-cases)를 커버하기 위해 추가된 엄청난 양의 코드. 그리고 그 코드 말입니다. 코드를 본 적이 있습니까? 오직 '추가'만으로 구축된 코드요. 잘못된 조건에 대한 100% 커버리지를 제공하는 수천, 수만 개의 작업별 단위 테스트(task-specific unit-tests). 이미 14번 구현된 함수의 재구현(Re-implementation). 사방에 만연한 중복성(Redundancy). 코드의 모든 줄마다 붙은 쓸모없는 주석들. 아무도 읽지 않을 알렉산드리아 도서관 분량의 잘못된 문서화(documentation). 그러다가 그것이 고장 나고, 이유를 묻자 말이 안 되는 근본 원인 분석(root cause analysis)을 자신만만한 태도로 지껄입니다. 마치 4살짜리가 파란 개가 실제로 존재한다고 주장하는 것처럼요.
다른 에이전트(agent)에게 첫 번째 에이전트의 코드를 검토해 달라고 요청합니다: 더 많은 테스트를요. 더 많은 엣지 케이스를요. 만약 히그스 보손(Higgs boson)이 바로 그 순간 비트를 뒤집으면 무슨 일이 일어날지 생각해 본 적 있습니까? 성능을 확인해 달라고 요청하면: “당신 말이 완벽히 맞아요, 제가 그걸 깜빡했네요. 성능 개선을 위해 코드를 더 추가할게요.” 만약 자동화 시스템(clanker)이 코드베이스를 자유롭게 돌아다니게 둔다면, 바로 저렇게 됩니다. 종종 그렇게 극적이지 않습니다. 종종 더 단순한 문제들입니다. 그것은 주로 '추가' 방식으로 작동하며, 항상 최종적인 즉각적인 작업에 국한됩니다: “코드를 추가해야겠어.” “더 많은 코드를 작성해.” 여기저기 코드, 사방에 코드가요. 이 모든 것은 쓰레기에 불과합니다. 그리고 그 위로 또다시 쌓아 올립니다.
하지만 이제 코드 품질에는 신경 쓰지 않죠? 오직 자동화 시스템(clankers)만 만지니까요, 그렇죠? 저는 신경 씁니다. 방금 말씀드렸듯이 제가 코드를 검토해야 하기 때문입니다. 제가 더 이상 이해할 수 없는 난장판이 되어버린다면 제대로 할 수 없습니다. 코드 품질을 놓칠 수는 없습니다.
좋습니다. 하지만 그건 사용자 문제가 들립니다: 프롬프팅을 못하고 LLM에게 책임을 전가하고 있는 겁니다.
젠장, 제가 '당신은 실수할 수 없는 명망 높은 Principal 10x 엔지니어maxxer이다', '실수하지 마라', 그리고 '네 쓰레기를 재차 확인하라'를 추가하는 걸 잊었네요. 제가 클랭커(clankers)와 겪었던 모든 문제들은 신중하게 작성된 수많은 프롬프트2로 패치될 수도 있을지 모릅니다. 어쩌면 그것이 미래에 개발자들을 차별화할 요소일지도 모릅니다: 각자가 자신만의 클랭커를 최고의 클랭커로 만드는 비밀스러운 소스와 향신료 조합을 가지고 있는 것이요. 저는 그저 나이 들고 까칠한 노인일 뿐입니다. 저는 지난 20년간 제 코드에 대한 대가를 받아왔고, 꽤 잘합니다. 어쩌면 제가 TOOL을 제 도구 체인(toolchain)에 삽입하기 위해 진심으로 노력했다는 주장을 할 만한 약간의 자격을 얻었는지도 모르겠습니다. 그리고 현재 저의 결론은 이렇습니다: 그 기술은 몇 년 동안 존재해 왔으며, 저는 그것을 맹목적으로 신뢰하지 않을 이유들을 제게 제공했습니다.
비밀스러운 허브와 향신료로는 엔지니어링에 맞설 수 없습니다. 우리는 이 도구들에서 나오는 모든 것의 품질을 강제하기 위한 공식화된 프로세스와 입증되고 반복 가능한 제어 메커니즘이 필요합니다. 이런 것은 아직 존재하지 않습니다. 언젠가 나타날 수도 있겠지만, 아직은 그렇지 못합니다3. 그때까지 저는 그것에 대해 맹목적으로 비난하지 않을 것입니다. 만약 스스로를 소프트웨어 엔지니어라고 생각한다면, 당신도 잠시 시간을 들여 생각해 봐야 할 겁니다.
제 경험상, 아무리 많은 시스템 프롬프트나 CLANKER.md
지침(instructions), 반복적인 재시도(re-iterations), 다른 모델에 의한 검토(reviews by other models), 위협, 또는 심리적 조작이 clankers가 행동을 신뢰성 있게 수정하도록 만드는 것 같습니다. 그리고 그게 저를 정말 미치게 만드는 부분입니다: 특히 고집 센 주니어 개발자가 같은 실수를 세 번째 할 때, 잠시 코치 역할을 하며 배우도록 확실히 도와주면 실제로 레벨업하는 데 도움이 됩니다. Clankers는 학습하지 않습니다. 그들은 할 수 없습니다. 왜냐하면 근본적인 기술 자체가 학습할 수 없기 때문입니다4. 여러분은 그들의 컨텍스트 윈도우(context window)에 지침을 주입할 수 있습니다. 운이 좋으면 평가 과정에서 해당 지침들을 고려할 것이고, 그러면 컨텍스트가 조금 커지겠지만, 결국 여러분이 말한 것은 무시하고 자신들의 가중치(weights)에 내장된 것을 선호하며 진행할 것입니다. 어쩌면 언젠가는 더 좋아질 수도 있을 겁니다. 하지만 아직 그 단계는 아닙니다.
언제부터 호기심과 면밀한 검토가 나쁜 것이 되었을까요? 만약 저에게 clankers가 작성한 코드에 대한 책임을 지라고 한다면, 저는 그 코드를 검토해야 합니다. 그리고 아무에게도 말하지 마세요. 하지만 가끔은 제가 직접 작성하기도 합니다.
참고 사항
거짓말을 하는 것이 아닙니다. 통계 자료를 인용하지는 마십시오. ↩
의심해 보세요. ↩
그리고 그것은 clanker 열풍 속에서 작업할 수 있는 가장 흥미로운 것 중 하나일 수도 있습니다. ↩
지능의 적절한 정의는 학습하고 적응하는 것이라고 주장할 수도 있으며, 따라서 LLM은 인공적인 것이든 아니든 '지능(Intelligence)'이라 불리는 것에서 제외되어야 합니다. 하지만 저는 마케팅 용어에 대해 논하기 위해 여기에 온 것이 아닙니다. ↩
