Lenny's Podcast에서 나눈 에이전틱 엔지니어링 대담 핵심 정리

Watch "Why we’ve passed the AI inflection point and automation has already started | Simon Willison" on YouTube

11월의 변곡점

4:19 - 두 AI 연구소가 모델의 코딩 성능을 끌어올리기 위해 모든 역량을 쏟아부은 결과, 11월에 제가 말하는 변곡점(inflection point)이 찾아왔습니다. GPT 5.1과 Claude Opus 4.5가 등장한 시점입니다.

두 모델 모두 이전 모델 대비 점진적인 개선이었지만, 그 개선이 어떤 임계치를 넘어섰습니다. 전에는 코드가 대체로 동작하긴 해도 하나하나 꼼꼼히 살펴봐야 했는데, 어느 순간부터 지시한 대로 거의 항상 제대로 동작하게 된 겁니다. 이 차이가 실로 엄청납니다.

이제는 코딩 에이전트를 실행시키고 이런 기능을 하는 Mac 앱을 만들어줘라고 하면, 아무것도 못 하는 버그 덩어리가 아닌 쓸 만한 결과물이 돌아옵니다.

다른 지식 노동자들의 선행 지표로서의 소프트웨어 엔지니어

5:49 - 하루에 코드 1만 줄을 뽑아낼 수 있고, 그 대부분이 동작합니다. 그런데 이게 과연 좋은 걸까요? '대부분'에서 '전부'로 가려면 무엇이 필요할까요? 우리 앞에는 완전히 새로운 질문들이 쌓여 있습니다. 그래서 저는 소프트웨어 엔지니어가 다른 지식 노동자들의 선행 지표(bellwether)가 된다고 생각합니다.

코드는 에이전트에게 제시하는 문제 중 가장 다루기 쉬운 편입니다. 코드는 명확히 맞거나 틀리거든요. 동작하거나 동작하지 않거나 둘 중 하나입니다. 미묘하게 숨겨진 버그가 있을 수 있지만, 대체로는 제대로 작동하는지 확인할 수 있습니다.

반면 에세이를 써준다거나 소송 자료를 준비해준다면, 그 결과물이 실제로 잘된 건지, 맞는지 틀리는지 판단하기가 훨씬 어렵습니다. 그런데 이 문제가 지금 소프트웨어 엔지니어들에게 먼저 닥치고 있습니다. 우리가 첫 번째 당사자인 셈입니다.

그래서 우리는 지금 이런 질문들을 씨름하고 있습니다. 앞으로의 커리어는 어떤 모습일까? 지금까지 대부분의 시간을 차지하던 일이 더 이상 그렇지 않을 때, 팀으로 어떻게 일해야 할까? 이 변화가 다른 지식 노동 분야로 확산될 때 어떤 양상이 펼쳐질지, 지켜보는 것 자체가 흥미로울 것 같습니다.

법조계는 이 문제로 특히 심하게 타격을 받고 있습니다. AI 환각 판례 데이터베이스에 등록된 사례가 이미 1,228건에 달합니다!

에피소드 도입부인 첫 부분에서도 이런 이야기가 나옵니다:

예전에는 ChatGPT에 코드를 요청하면 코드를 뱉어줬고, 그걸 직접 실행하고 테스트해야 했습니다. 코딩 에이전트는 이제 그 단계를 대신 처리해줍니다. 그렇다면 다른 지식 노동 분야 중에서도 이런 에이전트 루프가 실제로 적용될 수 있는 곳이 얼마나 될까요? 아직 저에게는 열린 질문입니다.

스마트폰으로 코드 작성하기

8:19 - 요즘은 코드의 상당 부분을 스마트폰으로 작성합니다. 솔직히 놀랍습니다. 해변에서 강아지를 산책시키면서도 실질적인 작업을 할 수 있다니, 정말 즐겁습니다.

주로 Claude iPhone 앱을 활용하는데, 일반 Claude 채팅 세션(이제 코드 실행도 가능합니다)을 쓰거나 웹용 Claude Code를 제어하는 방식으로 사용합니다.

책임감 있는 바이브 코딩

9:55 본인만 사용할 용도로 바이브 코딩을 한다면, 버그가 생겨도 피해는 자신에게만 돌아오니 마음껏 해도 됩니다. 하지만 그 코드를 다른 사람들이 쓸 수 있도록 배포하는 순간, 즉 내 버그가 남에게 피해를 줄 수 있는 순간부터는 한 발짝 물러서서 신중하게 접근해야 합니다.

관련 글: 바이브 코딩, 언제 해도 괜찮을까?

다크 팩토리와 StrongDM

12:49 '다크 팩토리'라는 이름은 공장 자동화 개념에서 왔습니다. 공장이 완전히 자동화되어 사람이 필요 없어지면 불을 꺼도 됩니다. 기계들은 공장 바닥에 사람이 없어도 완전한 어둠 속에서 작동할 수 있으니까요. 소프트웨어에서 이것은 어떤 모습일까요? [...]

한 가지 정책이 있는데, 아무도 코드를 직접 작성하지 않는다는 것입니다. 컴퓨터에 코드를 타이핑해서는 안 됩니다. 솔직히 6개월 전만 해도 말도 안 된다고 생각했습니다. 그런데 지금은 제가 만들어내는 코드의 약 95%를 직접 타이핑하지 않습니다. 이 세계는 이미 현실이 됐습니다. 최신 모델들의 수준이 충분히 올라왔기 때문에, 저 변수 이름 바꿔줘, 리팩토링 해줘, 여기 이 줄 추가해줘라고 하면 그냥 해줍니다. 직접 키보드로 치는 것보다 빠릅니다.

그런데 다음 규칙은 아무도 코드를 읽지 않는다는 것입니다. StrongDM이 작년부터 실제로 실천하기 시작한 부분이 바로 이것입니다.

StrongDM의 다크 팩토리 실험에 대해서는 2월에 훨씬 자세히 다룬 바 있습니다.

병목은 이제 테스트로 넘어갔다

21:27 - 예전에는 스펙을 작성해서 개발팀에 넘기면 잘 되면 3주 후에 구현물이 돌아왔습니다. 지금은 코딩 에이전트가 얼마나 잘 갖춰져 있느냐에 따라 다르지만 그게 3시간 안에 끝나기도 합니다. 그렇다면 이제 어디가 병목이 될까요?

제품 개발을 해본 사람이라면 누구나 알겠지만, 처음 아이디어는 언제나 틀립니다. 중요한 건 그걸 빠르게 검증하고 테스트하는 것입니다.

실제로 작동하는 프로토타입을 훨씬 빠르게 만들 수 있으니 테스트 속도도 크게 빨라졌습니다. 그래서 요즘 제 작업 방식에 흥미로운 변화가 생겼는데, 어떤 기능을 설계하고 싶을 때 구현 방식을 세 가지 정도 각각 프로토타이핑해보는 겁니다. 시간이 거의 안 들거든요.

저는 원래 프로토타이핑을 즐겨했는데, 지금은 그 가치가 더욱 높아졌습니다.

22:40 - UI 프로토타입은 이제 공짜입니다. ChatGPT와 Claude는 어떤 것을 설명하든 설득력 있는 UI를 뚝딱 만들어줍니다. 지금은 이렇게 일해야 합니다. 제품 디자인을 하면서 바이브 코딩으로 간단한 프로토타입을 만들어보지 않는 사람은, 이 단계에서 얻을 수 있는 가장 강력한 도구를 놓치고 있는 겁니다.

그런데 그다음은 어떻게 할까요? 하나 대신 세 가지 선택지가 생겼을 때, 어느 것이 최선인지 어떻게 증명할 수 있을까요? 저도 아직 확신 있는 답이 없습니다. 결국 여기서는 전통적인 사용성 테스트가 빛을 발할 것 같습니다.

프로토타이핑에 대해 뒤에서 한 번 더 언급합니다:

46:35 - 제 커리어 내내 저의 강점은 프로토타이핑이었습니다. 작동하는 프로토타입을 빠르게 만들어내는 것, 회의에 나타나서 '이렇게 구현할 수 있습니다'라고 보여주는 것이 저의 차별점이었습니다. 그런데 그게 사라졌습니다. 이제는 누구든 제가 하던 걸 할 수 있습니다.

이건 정말 지친다

26:25 - 코딩 에이전트를 제대로 활용하려면 25년 경력의 소프트웨어 엔지니어로서 쌓은 모든 역량을 총동원해야 합니다. 정신적으로 정말 소진됩니다. 에이전트 네 개를 병렬로 돌리며 네 가지 문제를 동시에 처리하다 보면 오전 11시쯤에는 이미 그날 치 에너지가 다 떨어집니다. [...]

번아웃 없이 지속 가능한 방식을 찾는 것, 새로운 한계를 발견하는 것, 이것도 하나의 개인적인 기술이 됐습니다.

코딩 에이전트가 나 대신 일을 하고 있으니 30분만 더 버티면서 작업을 더 돌려놓고 자야겠다 싶어 잠을 못 이루다가 새벽 4시에 깨어나는 사람들 이야기를 많이 들었습니다. 그건 분명히 지속 불가능한 방식입니다. [...]

이런 도구들을 사용하는 방식에는 도박이나 중독과 비슷한 요소가 있습니다.

방해를 받아도 잃는 것이 훨씬 줄었다

45:16 - 개발자를 방해하지 않는 것이 얼마나 중요한지 자주 이야기합니다. 개발자들이 2~4시간짜리 집중 작업 시간을 확보해야 머릿속에 맥락을 충분히 구성하고 코드를 제대로 쏟아낼 수 있다고요. 그런데 그게 완전히 달라졌습니다. 지금 저의 개발 작업은, 에이전트에게 다음에 무엇을 할지 프롬프트를 입력하는 데 2분이면 충분합니다. 그 사이에 다른 일을 하다가 돌아오면 됩니다. 예전보다 훨씬 더 유연하게 방해를 수용할 수 있게 됐습니다.

소프트웨어 공수 산정 감각이 무너졌다

28:19 - 25년 동안 뭔가를 만드는 데 얼마나 걸리는지 감이 쌓였습니다. 그런데 그게 완전히 쓸모없어졌습니다. 더 이상 통하지 않습니다. 어떤 문제를 보고 2주 걸릴 테니 시도할 가치가 없다고 판단했던 것들이, 이제는 20분이면 끝날 수도 있습니다. 2주가 걸렸던 이유가 AI가 지금 대신 처리해주는 지루하고 번거로운 코딩 작업들 때문이었으니까요.

저는 AI가 못 할 것 같다고 생각하는 작업도 계속 던져봅니다. 가끔은 해내거든요. 못 해냈을 때도 뭔가 배우게 됩니다. 그런데 특히 이전 모델들이 못 했던 걸 해냈을 때, 그건 사실상 최첨단 AI 연구의 최전선에 서 있는 순간입니다.

중간 어딘가에 있는 사람들이 가장 힘들다

29:29 - 대형 IT 컨설팅 회사인 ThoughtWorks가 약 한 달 전 오프사이트 행사를 열었습니다. 여러 기업의 엔지니어링 VP들을 한자리에 모아 이 주제로 논의를 나눴는데, 거기서 흥미로운 이론이 나왔습니다. AI 도구는 경험 많은 엔지니어에게도, 신입 엔지니어에게도 유용하다는 겁니다. 경험자에게는 역량을 증폭시켜주고, 신입에게는 온보딩의 많은 문제를 해결해줍니다. 문제는 그 중간 어딘가에 있는 사람들입니다. 시니어 레벨에는 아직 못 미쳤지만 주니어도 아닌 미드 커리어 단계, 지금 가장 어려운 처지에 놓인 그룹이 바로 이들입니다.

Cloudflare의 인턴 1,000명 채용과 Shopify의 유사한 움직임도 언급했습니다.

Lenny가 그 중간에 낀 사람들에게 어떤 조언을 해줄 수 있냐고 물었습니다:

31:21 - 꽤 무거운 질문을 주셨네요! 제 생각에 나아갈 방향은 이 변화에 적극적으로 올라타서, 어떻게 하면 이게 나를 더 나은 사람으로 만들어줄 수 있는지를 찾아내는 겁니다.

AI가 대신 해주면 내가 아무것도 배우지 못한다는 기술 퇴화(skill atrophy) 걱정을 하는 분들이 많습니다. 그 불안을 느낀다면, 거기에 맞서야 합니다. 기술을 어떻게 활용할지 의식적으로 생각해야 합니다. 어떤 질문이든 대체로 제대로 답해주는 도구가 생겼을 때, 어떻게 하면 내 실력을 키우고 새로운 걸 배우고 훨씬 더 야심찬 프로젝트에 도전하는 데 활용할 수 있을지 생각하는 겁니다. [...]

33:05 - 지금 모든 것이 너무 빠르게 변하고 있습니다. 유일한 범용 기술은 변화에 유연하게 적응하는 능력입니다. 지금 우리 모두에게 필요한 것이 바로 그겁니다.

AI를 잘 활용하는 사람이 어떤 특성을 가졌는지 이야기할 때 가장 많이 나오는 단어가 주체성(agency)입니다. 저는 에이전트에게 주체성이란 전혀 없다고 생각합니다. AI가 절대 가질 수 없는 것이 바로 주체성인데, 인간적인 동기와 의지가 없기 때문입니다.

그러니 결국은 자신의 주체성에 투자하고, 이 기술을 활용해 지금 하는 일을 더 잘하고 새로운 것을 시도하는 방법에 투자하는 것이 답이라고 생각합니다.

소프트웨어를 평가하기가 더 어려워졌다

상세한 문서와 탄탄한 테스트를 갖춘 소프트웨어를 만들기가 너무 쉬워진 탓에, 오히려 어떤 프로젝트가 진지하게 만들어진 것인지 파악하기가 어려워졌습니다.

37:47 가끔 소프트웨어 아이디어가 떠오르면, Python 라이브러리 같은 걸 한 시간 안에 뚝딱 만들어서 문서와 테스트까지 갖춘 상태로 마무리할 수 있습니다. 몇 주를 쏟아부었을 때나 나올 법한 결과물처럼 보이고, GitHub에 올릴 수 있는 수준입니다.

그런데... 믿음이 안 생깁니다. 그 이유는 모든 단계를 너무 빠르게 훑고 지나쳤기 때문입니다. 품질은 아마 괜찮겠지만, 그 품질을 확신할 만큼 충분히 들여다보지 못했습니다. 가장 중요한 것은, 아직 직접 써보지 않았다는 겁니다.

돌이켜보면 남이 만든 소프트웨어를 쓸 때 제가 가장 중요하게 보는 것은, 그 사람이 몇 달 동안 직접 사용해봤는지입니다.

저한테는 직접 만들고 한 번도 써보지 않은 꽤 멋진 소프트웨어가 있습니다. 실제로 써보는 것보다 만드는 게 더 빨랐거든요!

AI 도구는 쓰기 쉽다는 오해

41:31 - 다들 그냥 챗봇이잖아요, 쉽겠네요 라고 합니다. 쉽지 않습니다. AI에 관한 가장 큰 오해 중 하나가 이 도구들을 효과적으로 활용하는 게 쉽다는 겁니다. 많은 연습이 필요하고, 안 되는 것과 되는 것을 수도 없이 시도해봐야 합니다.

코딩 에이전트, 이제 보안 연구에도 쓸 만해졌다

19:04 - 지난 3~6개월 사이에 코딩 에이전트가 보안 연구자로서도 신뢰할 만한 수준이 되기 시작했습니다. 보안 연구 업계 전체에 파장이 일고 있습니다.

Thomas Ptacek의 글을 참고하세요: 취약점 연구는 이제 끝났다.

동시에, 오픈소스 프로젝트들은 엉터리 보안 신고 세례를 받고 있습니다:

20:05 - 아무것도 모르는 사람들이 ChatGPT한테 보안 취약점 찾아달라고 시킨 다음 그 결과를 그대로 유지보수자에게 제보합니다. 보고서 형식은 그럴듯합니다. ChatGPT는 취약점 보고서를 꽤 그럴듯하게 작성하거든요. 하지만 완전한 시간 낭비입니다. 실제 문제인지 검증조차 되지 않았으니까요.

올바른 방식의 좋은 사례는 Anthropic과 Firefox의 협력입니다. Anthropic 보안팀이 모든 보안 문제를 직접 검증한 뒤 Mozilla에 전달했습니다.

OpenClaw

물론 OpenClaw 이야기도 빠질 수 없었습니다! Lenny는 Mac Mini에 직접 설치해서 쓰고 있었습니다.

1:29:23 - OpenClaw는 사람들이 개인 디지털 어시스턴트를 얼마나 원하는지를 잘 보여줍니다. 보안 문제를 눈감는 것은 물론이고, 설치 과정 자체도 만만치 않은데도 불구하고 말입니다. API 키와 토큰을 만들고 이것저것 설치해야 합니다. 결코 쉬운 셋업이 아닌데도 수십만 명이 해냈습니다. [...]

OpenClaw의 첫 번째 코드 라인은 11월 25일에 작성됐습니다. 그리고 슈퍼볼에는 AI.com 광고가 나왔는데, 사실상 OpenClaw를 화이트라벨로 제공하는 호스팅 업체의 vaporware 광고였습니다. 11월에 첫 코드를 작성하고 불과 3개월 반 만에 슈퍼볼 광고까지 간 겁니다.

Drew Breunig이 OpenClaw를 디지털 펫으로 묘사한 것은 여전히 마음에 드는 표현입니다:

한 친구가 OpenClaw는 기본적으로 다마고치라고 했습니다. 디지털 펫이고, Mac Mini는 어항이라는 거죠.

기자들은 신뢰할 수 없는 소스를 다루는 데 익숙하다

Datasette를 통한 데이터 저널리즘 분야에서의 AI 활용 실험을 이야기하면서:

1:34:58 - 진실을 밝혀내는 것이 본업인 저널리즘에 AI는 궁합이 안 맞는다고 생각할 수도 있습니다. 하지만 반대로 생각해보면, 기자들은 늘 믿을 수 없는 소스를 상대해왔습니다. 저널리즘의 본질은 여러 사람과 이야기하고, 그 중 일부는 거짓말을 하며, 그 속에서 진실을 가려내는 것입니다. 그러니 기자가 AI를 또 하나의 신뢰하기 어려운 소스로 취급하는 한, 사실 다른 어떤 직군보다 AI와 함께 일하는 데 더 잘 갖춰져 있는 셈입니다.

펠리컨 벤치마크

물론 자전거를 탄 펠리컨 이야기도 했습니다:

56:10 - 펠리컨이 자전거 타는 그림을 얼마나 잘 그리는지와 다른 모든 분야의 성능 사이에 매우 강한 상관관계가 있는 것 같습니다. 왜 그런지는 아무도 설명을 못 해줍니다. [...]

벤치마크를 AI 연구소들이 속임수를 써서 통과하면 어떡하냐는 질문을 계속 받았습니다. 저의 대답은 언제나 같습니다. 솔직히 제가 원하는 건 그냥 정말 멋진 펠리컨 자전거 그림입니다. 세상의 모든 AI 연구소가 그걸 얻기 위해 벤치마크에서 속임수를 쓰게 만들 수 있다면, 그래도 제 목표는 달성되는 셈입니다.

59:56 - 사람들이 자주 놓치는 것이 있는데, 이 분야는 본질적으로 우습습니다. 역사상 가장 진보한 컴퓨터라고 불리는, 엄청난 비용과 전력을 쏟아부은 존재들이 펠리컨이 자전거 타는 그림을 그려보라고 하면 다섯 살짜리가 그린 것 같은 결과물을 내놓습니다. 저는 그게 정말 웃깁니다.

마지막으로, 앵무새에 관한 반가운 소식

Lenny가 마무리하면서 청중에게 남기고 싶은 말이 있냐고 물었고, 저는 지금 세상에서 가장 반가운 소식을 꺼냈습니다.

1:38:10 - 뉴질랜드에 카카포(Kākāpō)라는 희귀 앵무새가 있습니다. 현재 전 세계에 250마리밖에 남지 않았습니다. 날지 못하는 야행성 앵무새로, 통통하고 아름다운 초록빛 생김새를 가졌습니다. 반가운 소식은 2026년 번식 시즌이 아주 좋게 진행되고 있다는 겁니다.

카카포는 뉴질랜드의 리무(Rimu) 나무가 대량 결실을 맺는 시기에만 번식합니다. 리무 나무가 마지막으로 그런 해를 보낸 것은 2022년으로, 그 이후 4년 동안 단 한 마리의 카카포 새끼도 태어나지 않았습니다.

올해 리무 나무에 열매가 맺혔고, 카카포가 번식을 시작했습니다. 수십 마리의 새끼가 태어났습니다. 정말 좋은 소식입니다. 희귀한 뉴질랜드 앵무새에게 정말 기쁜 시간입니다. 한번 찾아보세요, 정말 사랑스럽습니다.

둥지에서 두 마리 새끼와 함께 있는 Rakiura의 라이브 스트림을 꼭 보세요!

YouTube 챕터

Lenny 팀이 YouTube 영상에 정의한 챕터 전체 목록입니다:

00:00: Simon Willison 소개
02:40: 2025년 11월의 변곡점
08:01: AI 코딩으로 지금 가능한 것들
10:42: 바이브 코딩 vs. 에이전틱 엔지니어링
13:57: 다크 팩토리 패턴
20:41: 병목이 이동한 곳
23:36: 인간의 뇌가 계속 가치를 발휘할 영역
25:32: 소프트웨어 엔지니어를 위한 변론
29:12: 경험 많은 엔지니어가 더 좋은 결과를 내는 이유
30:48: 영구적인 하위 계층으로 전락하지 않기 위한 조언
33:52: AI를 활용해 실력을 증폭하는 법
35:12: Simon이 그 어느 때보다 열심히 일하는 이유
37:23: 2022년 이전 사람이 직접 작성한 코드의 시장
40:01: 예측: 2026년 말까지 엔지니어의 50%가 코드의 95%를 AI로 작성
44:34: 코드 비용이 낮아진 영향
48:27: Simon의 AI 스택
54:08: 리서치에 AI 활용하기
55:12: 자전거 타는 펠리컨 벤치마크
59:01: AI가 내재적으로 우스운 이유
1:00:52: 자신이 할 수 있는 것을 독점하려는 심리
1:08:21: 더 나은 AI 코드를 위한 레드/그린 TDD 패턴
1:14:43: 좋은 템플릿으로 프로젝트 시작하기
1:16:31: 치명적인 삼중 위협과 프롬프트 인젝션
1:21:53: 97% 정확도가 낙제인 이유
1:25:19: 편차의 정상화
1:28:32: OpenClaw: 모두가 외면하는 보안 악몽
1:34:22: Simon의 다음 행보
1:36:47: 결과물 없는 컨설팅
1:38:05: 카카포 앵무새에 관한 반가운 소식

현재 블로그의 장문 아티클만 표시됩니다. 모든 포스트를 받아보려면 /atom/everything/을 구독하거나, 다른 구독 옵션을 확인하세요.