AI 구조 컨설팅이 보안 침해 대응이나 데이터 복구 전문가처럼 고가치 컨설팅의 큰 형태가 될 것 같음
순수하게 AI가 작성한 시스템은 인간이 이해할 수 없는 복잡도까지 커지고, 결함 수정률은 줄어드는 반면 결함당 토큰 소모는 늘어나며, 결국 AI 변경이 고치는 결함보다 더 많은 결함을 만들면서 전체가 불안정해질 수 있음
그런 난장판을 클린룸처럼 정리하고 핵심 설계 원칙을 추출한 뒤, 아마 여전히 AI를 써서 새로 재구축하는 특수한 절차가 필요해질 것임
미래의 소프트웨어 공학은 애초에 이런 일을 피하는 원칙이 중심이 되겠지만, 기존 소프트웨어 공학도 안정된 설계 원칙에 도달하는 데 예상보다 오래 걸렸듯이 그걸 배우는 데 20년은 걸릴 듯함
“순수 AI 작성 시스템이 인간이 이해할 수 없는 복잡도까지 커지고…”라는 대목을 보면, AI가 정말로 크고 복잡한 소프트웨어 시스템에서 인간 수준 성능에 도달하려는 모양이라는 농담이 가능함
비기술자 친구가 Claude로 재고 관리 솔루션을 바이브 코딩해서 병원 계약을 따냈음
병원 측이 IT 부서 서버 접근권까지 줬는데, Claude를 연결할 수 없어 배포 방법을 몰라 크게 헤매며 연락해 왔고, 앱에는 흥미로운 데이터/상태 관련 문제도 있는 듯함
그 복잡도는 필요 없는 장황한 복잡도일 것 같음
마치 Amazon 물건을 무제한 무료로 집에 배송받는 사람처럼, 이론상으론 풍요로운 삶이지만 실제로는 번영이 아닌 무언가에 파묻히게 되는 모습이 떠오름
원작 Westworld 영화의 대사가 떠오름: “이것들은 매우 복잡한 장비입니다… 거의 생명체만큼 복잡하죠. 어떤 경우에는 다른 컴퓨터가 설계했습니다. 우리는 정확히 어떻게 작동하는지 모릅니다.”
그 결과가 어땠는지는 다들 알 것임
최근 비슷한 고객을 만났는데, 전체 인프라와 CI/CD가 바이브 코딩되어 있었음
수천 줄짜리 Github Actions 안에 Kubernetes를 반쯤 구현해 놓았고 이해가 불가능했음
AI 마케팅은 싫지만, 경험 있는 사람이 더 빨리 움직이게 해주는 도구로는 유용하다고 봄
다만 전문가가 아니면 AI는 하려는 일마다 복잡한 해법을 만들어내는 듯함
그는 AI 자체 사용보다는, 회사와 사람들이 의사결정과 사고를 AI에 외주 주는 현상을 말하는 것 같음
AI로 코드를 쓰는 게 AI 정신증이거나 나쁜 건 아니지만, 그냥 프롬프트를 넣고 AI가 말하는 걸 믿어버리면 AI 정신증에 가깝다고 봄
Twitter의 금융권 사람들과 VC들이 주제에 대해 조금만 스스로 생각하면 될 일을 ChatGPT 스크린샷으로 사고와 추론을 대체하는 모습을 자주 봄
이런 도구는 아이디어, 사고, 조언에는 형편없고 패턴 매칭으로 보이는 패턴을 내놓을 뿐이라, 아이디어를 얘기해 보면 대개 가장 일반적인 헛소리를 뱉음
반면 코드 작성처럼 패턴 매칭이 실제로 도움이 되는 작업에는 꽤 유용하지만, 사고와 의사결정까지 맡기면 안 됨
AI는 “맞는 정답”과 “틀린 정답”을 모두 준다고 생각함
거의 항상 논리적으로 맞아 보이는 텍스트를 만들지만, 그 텍스트 안에는 해당 사용 사례에 맞지 않을 수 있는 잘못된 암묵적 가정과 결정들이 들어갈 때가 있음
진짜 맞는 해법을 만들려면 문제 정의가 제대로 되어야 하고, 그게 해법을 만드는 것보다 더 어려울 수도 있음
회사들이 Fortune이나 Inc 같은 잡지에 사고를 맡기던 것과 얼마나 다른지 궁금함
아니면 임의의 컨설턴트에게 맡기는 것과도 비슷함
“AI가 좋은 아이디어라고 했다”가 “업계 흐름을 따라갔다”보다 정말 더 나쁜가 싶음
주변의 여러 사람이 이미 이런 단계를 겪었음
혼자 그러는 경우에는 친구와 가족이 이상한 행동이나 말을 지적하면서 어느 정도 제동이 걸림
하지만 고용주가 리더십 차원에서 그렇게 하기 시작하면 얼마나 나빠질지 상상하기 어려움
동참하라는 압박을 받거나 해고를 두려워하게 되고, 생각을 조절해 줄 사람은 반대하는 동료뿐인데 그런 사람들은 떠나거나 해고될 가능성이 큼
직장을 지키려면 맞춰서 행동해야 함
사고를 AI에 외주 주면 마법 같은 속도 향상이 생김
에이전트가 대신 결정을 내리기 때문에 에이전트 속도로 일이 움직이고, 종종 말도 없이 결정을 내린 뒤 “계획은 이렇다”는 최종 출력만 줌
그걸 제대로 검토하려면 문제를 깊이 이해해야 해서 다시 인간 속도로 돌아가야 하니, 결국 대충 훑고 승인하게 됨
핵심은 어떤 결정을 외주 줄지 의식적이고 신중하게 정하는 것임
그러려면 속도를 늦춰야 하고, 과장된 10배 바이브 코딩 이득은 줄어들지만, 대신 더 많이 개입하고 인지 부채도 덜 쌓임
배열을 어떻게 순회할지, 한 호출의 출력을 다른 호출의 입력으로 어떻게 맞출지 같은 지루한 결정은 에이전트에게 맡기면 됨
진짜 결정은 미리 하고 명세에 담아야 함: 경계, API, 핵심 자료구조, 시스템과 책임, 오류 처리, 보안과 개인정보의 강한 제약을 정의해야 함
모호하면 멈추라고 에이전트에게 지시해야 하며, 좋은 엔지니어라면 부작용 없이 2~3배 속도 향상을 얻을 수 있음
어쩌면 이 일이 소프트웨어 공학을 진짜 공학 분야로 바꿀지도 모름
지금은 프롬프터들이 회사 전체 인프라를 세우고 있음
개인적으로 아는 한 사람은 회사 데이터베이스를 더 새 Postgres 버전으로 마이그레이션했고, 결국 성공하긴 했지만 과정을 설명하는 걸 들으며 이를 갈았음
“서버에 휘발유를 붓고 담배를 피웠지만 걱정 마, 지하실에서 소화기를 찾았어. 게이지는 비었다고 나오지만 흔들면 아직 액체 소리가 나” 같은 느낌이었음
그가 회사를 떠나면, 그 DB 인프라를 유지할 더 자신감 넘치는 프롬프터가 필요해질 것임
이 글은 “버그를 배포해도 괜찮다, 에이전트가 인간이 못 하는 속도와 규모로 고칠 수 있다”고 말하는 사람들과는 논쟁할 수 없다고 짚음
그런데 최상위 답글이 바로 “하지만 에이전트는 엄청 빠르다”고 주장하는 예시임
도구가 출시 전에 버그를 고칠 만큼 충분히 좋고 빠르지 않다면, 출시 후에는 어떻게 그렇게 쉽게 따라잡을 수 있다고 믿는지 모르겠음
코드베이스와 기능이 두 배가 되는 이득이 버그가 두 배가 되는 피해보다 크다고 가정하는 것일 수도 있음
적어도 이번 분기 투자자 뉴스에는 좋아 보이겠지만
수정에도 버그가 없다는 걸 어떻게 아는지 모르겠음
계속 더 많은 쓰레기를 배포하게 될 수도 있는데, 피드백 루프는 고객인가?
그렇게 빠르다면 배포 전에 버그를 빨리 고치면 됨
AI 붐 초기에 친구와 이야기하면서, AI에 과도하게 의존하면 온갖 참사가 생길 거라고 했음
돌아온 답은 “게임 이론이야. 누군가는 할 거고, 너도 할 수밖에 없어. 그렇게 나쁠 리 없어”였음
논리는 유용하지만 위험을 무시하는 건 별개임
엄청 빠르게 움직이며 모든 걸 박살 내면 결국 좋은 결과가 나온다고 가정하는 건 위험함
이 AI 흐름은 잘 진행되고 있지 않고 마음에 들지 않음
현실적으로 내 사업은 버그가 있어도 더 높은 효율로 계속 운영되고 있음
정신증이 있는 쪽이 꼭 “우리 쪽”이라고는 생각하지 않음
아주 큰 회사에 다니는데, 우리 회사는 언제나 현대화와 기술 도입이 빙하처럼 느렸음
그런데 이상하게도 이제 그게 경쟁 우위가 될 수도 있음
말 그대로 Battlestar Galactica 줄거리임
삶이 예술을 따라감
독일에서 일하는 게 이렇게 기뻤던 적이 없음
예전에는 아직도 팩스가 남아 있다는 식으로 농담했지만, 이런 열풍이 없는 문화권에서 일하는 게 이렇게 다행일 줄 몰랐음
HN을 읽으면 토큰 극대화주의자와 AI 정신증 환자의 Alice's Wonderland에 들어가는 느낌임
여기서는 이런 식으로 일하라고 강요받는 사람을 진짜 한 명도 모름
Rich Hickey의 Simple Made Easy와 Clojure를 만들 때의 접근이 떠오름
LLM이 전체 프로그램을 생성하기 전에도, 복잡한 프레임워크는 개발자가 프로그램의 초기 버전을 매우 빨리 만들게 해줬지만 이해하기 어렵고 그래서 디버그와 수정도 어려워지는 대가가 있었음
어떤 사람들은 AI가 아무리 뒤얽히고 복잡한 프로그램을 작성하더라도, AI가 항상 충분히 똑똑해서 디버그하고 유지보수하고 수정할 수 있을 거라고 베팅함
나는 그렇게 확신하지 못하겠음
AI 정신증은 AI 사용에 반대하는 입장이 아님
AI 코딩 도구를 매일 쓰지만, AI 도구에는 미래라는 개념이 없음
“이게 운영에서 깨지면 내가 못 고칠 텐데, 새벽 3시에 나를 호출하겠지”라고 생각하는 엔지니어의 이기적인 사고에 우리는 안정적인 시스템 구축을 의존해 왔음
CPAN에서 완벽한 라이브러리를 찾아 직접 일하지 않으려는 일반적인 게으름도 있었고, 때로는 직접 쓰는 것보다 라이브러리를 못 찾는 데 더 오래 걸렸음
AI 도구로 수천 줄의 코드를 작성해 운영에 넣었고 대체로 자연스럽게 느껴졌는데, 2017년부터 사람들에게 코드를 전부 직접 타이핑하지 말고 작성하라고 말하며 테스트에서 나쁜 코드를 잡는 함정을 설치해 왔기 때문임
하지만 AI가 하지 않는 한 가지는 코드를 덜 쓰는 것임: https://xcancel.com/t3rmin4t0r/status/2019277780517781522/
프롬프트 때문인지 모르겠지만, 내 코딩 에이전트는 Opus 4.7 기반이고 “이런 게 6개월 뒤 새벽 2시에 터질 종류” 같은 말을 자주 함
버그 보고는 사람들이 고쳐질 거라는 믿음을 잃어도 줄어듦
버그를 보고하는 일은 꽤 큰 시간 투자가 필요한 경우가 많기 때문임
어떤 그룹이나 회사에 대한 신뢰가 무너질 때 이런 일이 꽤 자주 일어남
여기에 실제로 접수되는 보고서의 상당 부분이 AI가 생성하거나 다시 쓴 것일 가능성도 더해짐
그 때문에 잘못 보고될 가능성이 높고, 일부 내용이 틀릴 수도 있음
여러 방향에서 공격받는 셈임
적대적 전술까지는 아직 들어가지도 않았음
도덕이 없다면 에이전트로 경쟁사에 가짜 버그 보고를 쏟아붓는 것보다 좋은 방법이 뭐가 있겠나
그냥 AI가 버그를 보고하게 하면 됨
문제 해결임
맞음. 다만 이 문제는 AI 주도 프로젝트에만 있는 건 아님
Mitchell이 관찰한 것의 상당수, 어쩌면 전부는 AI가 없어도 충분히 일어날 수 있음
정말 이상한 위치에 있다고 느낌
AI가 코드 작성의 경험과 실천에 가져오는 변화가 너무 싫어서, 컴퓨터를 쓰는 일 말고는 뭐든 하고 싶을 정도이지만, 동시에 이 도구들이 매우 강력하고 계속 좋아지고 있다고도 생각함
Mitchell의 요지는 타당함. 이런 도구가 썩은 기초를 들여와도 전체 구조가 무너진 뒤에야 발견될 수 있음
그때 책임져야 하는 자리에 있으면서 예전처럼 코드베이스를 깊이 이해하지 못하는 상황은 피하고 싶음
하지만 인간도 오래전부터 미묘하면서도 치명적인 버그를 코드에 넣어 왔음
그래서 많은 부분은 아직 열려 있는 경험적 질문처럼 느껴짐
예전에는 없던 방식으로 끔찍하게 무너지는 시스템을 많이 보게 될까? 일부는 그럴 수 있음
동시에 명세와 검증 쪽으로 더 이동해야 한다는 걸 배우게 되지 않을까? 잘 모르겠음
어쨌든 이 방식의 시스템 구축은 중간에 충돌이 있더라도 피할 수 없어 보임
반AI 진영에도 나름의 반동적 정신증이 있는 것 같음
AI와 엮이고 싶지 않지만, 이 도구를 써 본 경험도 부정할 수 없음
이런 현실적이지만 부정적인 AI 논의를 할 공간이 더 많았으면 함
Mitchell이 좋은 개발자인 이유도 여기에 있음
Hacker News 의견들
AI 구조 컨설팅이 보안 침해 대응이나 데이터 복구 전문가처럼 고가치 컨설팅의 큰 형태가 될 것 같음
순수하게 AI가 작성한 시스템은 인간이 이해할 수 없는 복잡도까지 커지고, 결함 수정률은 줄어드는 반면 결함당 토큰 소모는 늘어나며, 결국 AI 변경이 고치는 결함보다 더 많은 결함을 만들면서 전체가 불안정해질 수 있음
그런 난장판을 클린룸처럼 정리하고 핵심 설계 원칙을 추출한 뒤, 아마 여전히 AI를 써서 새로 재구축하는 특수한 절차가 필요해질 것임
미래의 소프트웨어 공학은 애초에 이런 일을 피하는 원칙이 중심이 되겠지만, 기존 소프트웨어 공학도 안정된 설계 원칙에 도달하는 데 예상보다 오래 걸렸듯이 그걸 배우는 데 20년은 걸릴 듯함
병원 측이 IT 부서 서버 접근권까지 줬는데, Claude를 연결할 수 없어 배포 방법을 몰라 크게 헤매며 연락해 왔고, 앱에는 흥미로운 데이터/상태 관련 문제도 있는 듯함
마치 Amazon 물건을 무제한 무료로 집에 배송받는 사람처럼, 이론상으론 풍요로운 삶이지만 실제로는 번영이 아닌 무언가에 파묻히게 되는 모습이 떠오름
그 결과가 어땠는지는 다들 알 것임
수천 줄짜리 Github Actions 안에 Kubernetes를 반쯤 구현해 놓았고 이해가 불가능했음
AI 마케팅은 싫지만, 경험 있는 사람이 더 빨리 움직이게 해주는 도구로는 유용하다고 봄
다만 전문가가 아니면 AI는 하려는 일마다 복잡한 해법을 만들어내는 듯함
그는 AI 자체 사용보다는, 회사와 사람들이 의사결정과 사고를 AI에 외주 주는 현상을 말하는 것 같음
AI로 코드를 쓰는 게 AI 정신증이거나 나쁜 건 아니지만, 그냥 프롬프트를 넣고 AI가 말하는 걸 믿어버리면 AI 정신증에 가깝다고 봄
Twitter의 금융권 사람들과 VC들이 주제에 대해 조금만 스스로 생각하면 될 일을 ChatGPT 스크린샷으로 사고와 추론을 대체하는 모습을 자주 봄
이런 도구는 아이디어, 사고, 조언에는 형편없고 패턴 매칭으로 보이는 패턴을 내놓을 뿐이라, 아이디어를 얘기해 보면 대개 가장 일반적인 헛소리를 뱉음
반면 코드 작성처럼 패턴 매칭이 실제로 도움이 되는 작업에는 꽤 유용하지만, 사고와 의사결정까지 맡기면 안 됨
대체로 고점은 더 높고 저점은 더 낮아졌으며, 위의 묘사는 매우 정확함
관련해서 쓴 글은 다음과 같음: https://mitchellh.com/writing/my-ai-adoption-journey, https://mitchellh.com/writing/building-block-economy, https://mitchellh.com/writing/simdutf-no-libcxx
마지막 글은 AI 덕분에 한 복잡한 변경이며, 내가 어떻게 합리적으로 접근하는지도 보여줌
거의 항상 논리적으로 맞아 보이는 텍스트를 만들지만, 그 텍스트 안에는 해당 사용 사례에 맞지 않을 수 있는 잘못된 암묵적 가정과 결정들이 들어갈 때가 있음
진짜 맞는 해법을 만들려면 문제 정의가 제대로 되어야 하고, 그게 해법을 만드는 것보다 더 어려울 수도 있음
아니면 임의의 컨설턴트에게 맡기는 것과도 비슷함
“AI가 좋은 아이디어라고 했다”가 “업계 흐름을 따라갔다”보다 정말 더 나쁜가 싶음
혼자 그러는 경우에는 친구와 가족이 이상한 행동이나 말을 지적하면서 어느 정도 제동이 걸림
하지만 고용주가 리더십 차원에서 그렇게 하기 시작하면 얼마나 나빠질지 상상하기 어려움
동참하라는 압박을 받거나 해고를 두려워하게 되고, 생각을 조절해 줄 사람은 반대하는 동료뿐인데 그런 사람들은 떠나거나 해고될 가능성이 큼
직장을 지키려면 맞춰서 행동해야 함
에이전트가 대신 결정을 내리기 때문에 에이전트 속도로 일이 움직이고, 종종 말도 없이 결정을 내린 뒤 “계획은 이렇다”는 최종 출력만 줌
그걸 제대로 검토하려면 문제를 깊이 이해해야 해서 다시 인간 속도로 돌아가야 하니, 결국 대충 훑고 승인하게 됨
핵심은 어떤 결정을 외주 줄지 의식적이고 신중하게 정하는 것임
그러려면 속도를 늦춰야 하고, 과장된 10배 바이브 코딩 이득은 줄어들지만, 대신 더 많이 개입하고 인지 부채도 덜 쌓임
배열을 어떻게 순회할지, 한 호출의 출력을 다른 호출의 입력으로 어떻게 맞출지 같은 지루한 결정은 에이전트에게 맡기면 됨
진짜 결정은 미리 하고 명세에 담아야 함: 경계, API, 핵심 자료구조, 시스템과 책임, 오류 처리, 보안과 개인정보의 강한 제약을 정의해야 함
모호하면 멈추라고 에이전트에게 지시해야 하며, 좋은 엔지니어라면 부작용 없이 2~3배 속도 향상을 얻을 수 있음
어쩌면 이 일이 소프트웨어 공학을 진짜 공학 분야로 바꿀지도 모름
지금은 프롬프터들이 회사 전체 인프라를 세우고 있음
개인적으로 아는 한 사람은 회사 데이터베이스를 더 새 Postgres 버전으로 마이그레이션했고, 결국 성공하긴 했지만 과정을 설명하는 걸 들으며 이를 갈았음
“서버에 휘발유를 붓고 담배를 피웠지만 걱정 마, 지하실에서 소화기를 찾았어. 게이지는 비었다고 나오지만 흔들면 아직 액체 소리가 나” 같은 느낌이었음
그가 회사를 떠나면, 그 DB 인프라를 유지할 더 자신감 넘치는 프롬프터가 필요해질 것임
이 글은 “버그를 배포해도 괜찮다, 에이전트가 인간이 못 하는 속도와 규모로 고칠 수 있다”고 말하는 사람들과는 논쟁할 수 없다고 짚음
그런데 최상위 답글이 바로 “하지만 에이전트는 엄청 빠르다”고 주장하는 예시임
코드베이스와 기능이 두 배가 되는 이득이 버그가 두 배가 되는 피해보다 크다고 가정하는 것일 수도 있음
적어도 이번 분기 투자자 뉴스에는 좋아 보이겠지만
계속 더 많은 쓰레기를 배포하게 될 수도 있는데, 피드백 루프는 고객인가?
돌아온 답은 “게임 이론이야. 누군가는 할 거고, 너도 할 수밖에 없어. 그렇게 나쁠 리 없어”였음
논리는 유용하지만 위험을 무시하는 건 별개임
엄청 빠르게 움직이며 모든 걸 박살 내면 결국 좋은 결과가 나온다고 가정하는 건 위험함
이 AI 흐름은 잘 진행되고 있지 않고 마음에 들지 않음
정신증이 있는 쪽이 꼭 “우리 쪽”이라고는 생각하지 않음
아주 큰 회사에 다니는데, 우리 회사는 언제나 현대화와 기술 도입이 빙하처럼 느렸음
그런데 이상하게도 이제 그게 경쟁 우위가 될 수도 있음
삶이 예술을 따라감
예전에는 아직도 팩스가 남아 있다는 식으로 농담했지만, 이런 열풍이 없는 문화권에서 일하는 게 이렇게 다행일 줄 몰랐음
HN을 읽으면 토큰 극대화주의자와 AI 정신증 환자의 Alice's Wonderland에 들어가는 느낌임
여기서는 이런 식으로 일하라고 강요받는 사람을 진짜 한 명도 모름
이런 느낌이라면 새 CLI 도구 Burn, Baby, Burn (those tokens) 가 마음에 들 수도 있음: https://github.com/dtnewman/burn-baby-burn/tree/main
Show HN은 여기 있음: https://news.ycombinator.com/item?id=48151287
Rich Hickey의 Simple Made Easy와 Clojure를 만들 때의 접근이 떠오름
LLM이 전체 프로그램을 생성하기 전에도, 복잡한 프레임워크는 개발자가 프로그램의 초기 버전을 매우 빨리 만들게 해줬지만 이해하기 어렵고 그래서 디버그와 수정도 어려워지는 대가가 있었음
어떤 사람들은 AI가 아무리 뒤얽히고 복잡한 프로그램을 작성하더라도, AI가 항상 충분히 똑똑해서 디버그하고 유지보수하고 수정할 수 있을 거라고 베팅함
나는 그렇게 확신하지 못하겠음
AI 정신증은 AI 사용에 반대하는 입장이 아님
AI 코딩 도구를 매일 쓰지만, AI 도구에는 미래라는 개념이 없음
“이게 운영에서 깨지면 내가 못 고칠 텐데, 새벽 3시에 나를 호출하겠지”라고 생각하는 엔지니어의 이기적인 사고에 우리는 안정적인 시스템 구축을 의존해 왔음
CPAN에서 완벽한 라이브러리를 찾아 직접 일하지 않으려는 일반적인 게으름도 있었고, 때로는 직접 쓰는 것보다 라이브러리를 못 찾는 데 더 오래 걸렸음
AI 도구로 수천 줄의 코드를 작성해 운영에 넣었고 대체로 자연스럽게 느껴졌는데, 2017년부터 사람들에게 코드를 전부 직접 타이핑하지 말고 작성하라고 말하며 테스트에서 나쁜 코드를 잡는 함정을 설치해 왔기 때문임
하지만 AI가 하지 않는 한 가지는 코드를 덜 쓰는 것임: https://xcancel.com/t3rmin4t0r/status/2019277780517781522/
버그 보고는 사람들이 고쳐질 거라는 믿음을 잃어도 줄어듦
버그를 보고하는 일은 꽤 큰 시간 투자가 필요한 경우가 많기 때문임
어떤 그룹이나 회사에 대한 신뢰가 무너질 때 이런 일이 꽤 자주 일어남
그 때문에 잘못 보고될 가능성이 높고, 일부 내용이 틀릴 수도 있음
여러 방향에서 공격받는 셈임
적대적 전술까지는 아직 들어가지도 않았음
도덕이 없다면 에이전트로 경쟁사에 가짜 버그 보고를 쏟아붓는 것보다 좋은 방법이 뭐가 있겠나
문제 해결임
Mitchell이 관찰한 것의 상당수, 어쩌면 전부는 AI가 없어도 충분히 일어날 수 있음
정말 이상한 위치에 있다고 느낌
AI가 코드 작성의 경험과 실천에 가져오는 변화가 너무 싫어서, 컴퓨터를 쓰는 일 말고는 뭐든 하고 싶을 정도이지만, 동시에 이 도구들이 매우 강력하고 계속 좋아지고 있다고도 생각함
Mitchell의 요지는 타당함. 이런 도구가 썩은 기초를 들여와도 전체 구조가 무너진 뒤에야 발견될 수 있음
그때 책임져야 하는 자리에 있으면서 예전처럼 코드베이스를 깊이 이해하지 못하는 상황은 피하고 싶음
하지만 인간도 오래전부터 미묘하면서도 치명적인 버그를 코드에 넣어 왔음
그래서 많은 부분은 아직 열려 있는 경험적 질문처럼 느껴짐
예전에는 없던 방식으로 끔찍하게 무너지는 시스템을 많이 보게 될까? 일부는 그럴 수 있음
동시에 명세와 검증 쪽으로 더 이동해야 한다는 걸 배우게 되지 않을까? 잘 모르겠음
어쨌든 이 방식의 시스템 구축은 중간에 충돌이 있더라도 피할 수 없어 보임
반AI 진영에도 나름의 반동적 정신증이 있는 것 같음
AI와 엮이고 싶지 않지만, 이 도구를 써 본 경험도 부정할 수 없음
이런 현실적이지만 부정적인 AI 논의를 할 공간이 더 많았으면 함
Mitchell이 좋은 개발자인 이유도 여기에 있음