아듀 IDE! 이제는 'ADE(에이전트 중심 개발 환경)'의 시대?

흔히들 IDE, 즉 통합 개발 환경이라고 부르는 도구, 그 다음은 무엇일까요?

이번 인터뷰에서는, AI 기반의 코딩 도구들 중 하나인 Warp의 창립자이자 CEO, 잭 로이드와 함께 그가 직접 이름을 지은 새로운 개발 환경, ADE(Agentic Development Environment; 에이전트 중심 개발 환경)에 대해서 이야기를 나눠 봅니다.

코딩의 방법이 키보드에서 입력하는 것에서 프롬프트를 입력하는 걸로 바뀌는 것, 그 의미는 뭘까요? Warp가 Cursor나 Claude Code 같은 도구들과 어떻게 차별화되는지, 그리고 프로젝트 설정, 버그 수정, 코드 설명까지 해 주는 제대로 된 ‘AI 주니어 개발자’가 등장하면, 일반 개발자들은 어떻게 될지 한 번 심도있게 다뤄봅니다.

물론, 그에 따르는 리스크도 함께 이야기해야겠죠 - 아무렇게나 코딩해서 엉망인 코드를 프로덕션에 배포할 수도 있는 ‘바이브 코딩’의 리스크, 그 결과로 부실하게 만들어진 소프트웨어가 넘쳐날 가능성에 대해 이야기하고, 그리고 개발자들이 ‘단순히 코드를 입력하는 사람’이 아니라 ‘AI를 오케스트레이션하고 검토하고 그 작업 의도를 형성하는 존재로서 왜 여전히 핵심적인 역할’을 해야 하는지에 대해서도 이야기를 나눕니다.

그리고, 잭 로이드가 AI 코딩을 위한 새로운 인터페이스, Warp Code에 대해서도 살짝 귀띔을 해 줬습니다.

크세니아의 인터뷰 전체 영상을 보고 싶으신 분은 아래 링크를 참고하시구요:

자, 그럼 인터뷰 시작합니다!

Q. 안녕하세요, 잭. 오늘 인터뷰에 응해 주셔서 정말 감사합니다.

네, 초대해 주셔서 감사합니다. 함께하게 돼서 정말 기쁩니다.

Q. 네, 저희두요. 인터뷰 전에 제가 Warp를 직접 써 봤는데요, 어떻게 애플리케이션을 거의 혼자서 만들어내는지 정말 놀라웠어요. 웹사이트에 ‘에이전트 중심 개발 환경(Agentic Development Environment)’이라고 쓰여 있던데, 터미널, CLI, IDE와 비교해서 이게 정확히 무슨 뜻인지 설명해 주실 수 있나요?

기본적으로는 개발 방식이 ‘손으로 직접 코딩하는 것’에서 ‘프롬프트로 개발하는 것’으로 바뀌고 있다는 의미예요. 저는 제 커리어의 대부분을 IDE를 오픈해서 코드를 치거나, 터미널을 열어서 명령어를 입력하면서 보낸 셈이거든요. 그런데 이제는 Warp를 열고 자연어로 하고 싶은 걸 입력하거나, 그냥 말로 컴퓨터에게 이러이러한 걸 해달라고 요청하잖아요.

개발의 워크플로우가 점점 에이전트 중심으로 바뀌면서, 그에 맞는 작업 공간이 필요해졌어요. 저희는 그게 IDE보다는 터미널에 더 가까워야 한다고 생각합니다. 터미널은 항상 직접적인 입력, 즉 명령어를 입력하고 답을 얻는 방식이었죠. 이제는 터미널에서 영어로 말을 하고 에이전트를 작동시키는 셈이예요.

Warp는 터미널로 시작했지만, 지금은 자연어 인터페이스가 주를 이룹니다. 코드를 작성하고, 에이전트와 함께 작업하면서 차이점을 검토하고, 심지어는 파일 편집 기능까지 제공해요. 예전에는 IDE에만 있었던 기능들이 이제 Warp 안에 들어온 거죠. 더 이상 예전의 용어로는 정의하기 어려워져서, 이걸 ‘ADE(에이전트 중심 개발 환경)’이라고 부르기 시작했습니다.

Q. 그럼 그 그 용어는 직접 만드신 건가요?

네, 맞아요. 여러 가지 이름을 고민하다가 IDE와 비슷하면서 I를 A로 바꾼 ADE로 정하게 됐습니다. 요즘은 다른 분들도 쓰는 걸 들었어요. 제가 존경하는 엔지니어 몇 분이 나오는 팟캐스트를 보고 있었는데, 제드(Zed)의 창업자 네이선 소보(Nathan Sobo)가 세상에 필요한 건 에이전트 중심 개발 환경이라고 말하더라고요. 정말 멋진 순간이었어요.

Q. IDE 다음으로라…아주 논리적인 이름이네요. 그런데 요즘 코딩 에이전트가 넘쳐나는 상황에서, Warp는 어떻게 다른 도구들과 차별화를 하나요? 인기가 많은 Cursor나 많은 사람이 쓰는 Claude Code하고는 뭐가 다르다고 볼 수 있을까요?

Cursur 같은 IDE하고는 크게 두 가지 차이점이 있습니다.

첫째로, 저희는 터미널 레벨에서 작동하기 때문에, 전체 소프트웨어 개발 생애주기처럼 더 넓은 범위의 작업을 다룹니다. 프로젝트 설정, 코딩 에이전트 실행, 에이전트가 만든 코드 배포, 그리고 프로덕션 환경에서 발생하는 문제의 디버깅까지 모두 Warp 안에서 할 수 있어요. IDE는 마이크로소프트 워드처럼 파일 편집에 더 집중하게끔 하는 경향이 있죠.

둘째로, Cursor의 핵심 강점은 자동 완성이에요. 코드를 입력하면 유령처럼 텍스트를 제안해주는 거죠. 이건 정말 유용하기는 해요. 하지만 Warp의 에이전트 경험은 IDE보다 훨씬 강력해요. IDE에서는 에이전트가 옆의 채팅창에 따로 붙어 있는 거라서 그 효과가 떨어지죠. Warp의 에이전트 품질은 벤치마킹에서도 입증됐습니다. 터미널벤치(TerminalBench)에서 1위, SWE-벤치에서 5위 안에 들 만큼 경쟁력이 있어요.

Claude Code는 Warp와 더 비슷해요, 둘 다 터미널에서 작동하니까요. 하지만 Warp에는 몇 가지 장점이 있습니다. 하나는 Warp가 멀티 모델을 지원한다는 점이에요. 저희는 한 모델 개발사에 묶여 있지 않고 최고의 모델을 사용합니다. 다른 하나는 파일 편집과 차이점 검토(Diff Review) 기능이 포함되어 있어서, 에이전트와 훨씬 긴밀하게 협업할 수 있다는 거예요.

Claude Code나 Gemini CLI 같은 도구들은 제가 ‘바이브 코딩(Vibe Coding)’이라고 부르는 방식에 적합해요. 에이전트 몇 개를 돌려놓고 프로젝트의 여러 부분을 건드리도록 내버려 두는 거죠. 하지만 전문 개발자라면, 에이전트 도구의 성공은 에이전트와 ‘단계별로 짝을 이뤄서’ 작업하는 데서 옵니다. 에이전트의 결과물인 코드를 리뷰하고, 방향을 가이드하고, 계획을 따르도록 확실히 단도리를 하는 거죠. Warp는 이런 수준의 협업을 위해서 만들어졌습니다.

바이브 코딩에 반대하는 건 아니지만, 프로 개발자에게 바이브 코딩은 ‘쓰레기를 빠르게 배포하는’ 가장 빠른 방법이 되어버릴 위험이 있어요. Warp는 훨씬 더 엄격하고 신뢰할 수 있는 워크플로우를 제공합니다.

가장 최근에 한 스택 오버플로우 설문조사를 보면, 에이전트 도구에 대한 가장 큰 두 가지 불만 사항은 ‘미묘한 버그가 있는 코드를 많이 생성한다’와 ‘코드가 이해하기 어렵다’는 것이었습니다. 때로는 에이전트가 뭘 하는지 이해하는 데 직접 코드를 작성하는 것보다 더 많은 시간이 걸리기도 해요.

저희의 관점은 이렇습니다. 에이전트 중심이면서도 실제 프로덕션 코드베이스에 배포할 때 신뢰할 수 있는 도구가 필요하다는 거예요. 이건 ‘이해도(Comprehension)’의 문제로 귀결돼요. 에이전트가 뭘 하는지 이해하고, 신중하게 가이드하고, 잘못된 부분을 수정하고, 팀의 코딩 규칙을 따르게끔 할 수 있는가 하는게 중요해요. Warp는 에이전트와 긴밀하게 짝을 이루도록 설계되었기 때문에, 이 부분에서 내재된 강점을 가지고 있습니다. CLI 전용 도구는 이런 지원을 잘 할 수가 없죠.

Q. Warp를 사용하면서 ‘메타 도구’라는 생각을 했어요. 최근에 저희가 자체적으로 해 봤던 코딩 에이전트 테스트에서 Warp의 성능이 워낙 뛰어나서 테스터가 농담으로 ‘잭이 나를 Warp의 전도사로 고용해야’ 된다고 할 정도였거든요. 그 때의 결론은, Cursor +Warp 조합이 최고라는 거였기는 했구요.

저 같은 아마추어 개발자에게 Warp는 제가 모르는 단계까지 도와주는 ‘메타 도구’처럼 느껴져요. 그런데 프로 개발자들에게는 어떨까요? Warp가 다른 도구들과 함께 쓰이는 보조 도구로 남을까요, 아니면 개발자들을 위한 궁극의 메타 도구가 될 거라고 보시나요?

지금은 두 가지 방식으로 모두 사용되고 있어요. Warp를 IDE와 함께 쓰는 경우가 흔합니다. 프로젝트 설정, 깃(Git) 작업, 도커(Docker), 테라폼(Terraform) 등 ‘터미널스러운’ 작업은 Warp에서 하고, 파일 편집은 IDE로 전환하는 거죠. 이렇게 해도 괜찮습니다.

하지만 저희의 비전은 더 큽니다. 시간이 지나면서 개발자들은 직접 손으로 편집하거나 자동 완성 기능을 쓰는 대신, 에이전트를 더 많이 가이드하면서 작업을 하게 될 겁니다. 에이전트가 작업하는 경로를 조정하고 피드백을 주는 거죠. Warp는 이런 역할을 위해서 만들어졌기 때문에, 결국에는 하나의 통합된 작업 공간으로 진화할 거라고 봅니다.

개발자들은 여러 도구를 섞어 쓰는 것을 좋아해요. Warp 안에서 Claude Code를 실행한다거나, Warp를 Cursor와 조합하는 식으로요. 이것도 가능하죠. 하지만 하나의 통합된 에이전트 경험이 더 가치가 있다고 생각해요. 예를 들어서, Warp에서 직접 코딩을 하면 모든 터미널 창에서 컨텍스트를 공유할 수 있어요. 한 창에서 실행되는 서버의 출력을 다른 창의 에이전트 입력으로 사용할 수 있는 거죠. 여러 개의 CLI 앱을 번갈아 사용하면 이런 기능은 불가능하잖아요?

그래서 저희는 다양한 워크플로우를 지원하지만, 결국 많은 개발자들이 하나의 통합된 환경에 머무르면서 작업을 하는데서 오는 큰 이점을 알게 될 거라고 믿습니다.

Q. 개발자 워크플로우에 대해서 많은 생각을 다시 하게 만드네요. 이런 메타 도구가 존재하게 되면 지금의 워크플로우에서 어떤 게 사라질 거라고 생각하시나요?

기존 도구들의 사용 빈도가 줄어들 뿐이지, 사라지지는 않을 거라고 생각해요. 파일 편집기는 오랫동안 필요할 겁니다. 때떄로 직접 고치는 게 더 빠르거나, 에이전트가 제대로 못 하거나, 언어 지원이 부족한 경우도 있으니까요. 개발자들이 거의 필요로 하지 않지만, 가끔은 머신 코드를 봐야 하는 것과 비슷한 거겠죠. 추상화된 방식이 95~98%의 경우에 더 편리하지만, 언제든 되돌아갈 수 있는 곳은 필요하니까요.

달라지는 점은 주된 작업의 방식이 에이전트 중심으로 바뀐다는 거예요. 대부분의 시간은 에이전트에 의존하고, 필요할 때만 직접 손으로 편집하는 방식으로 전환될 겁니다.

Q. Warp는 이미 여러 면에서 주니어 개발자 같다는 생각이 들어요. 그런데 ‘에이전트 중심이 된다’는 건 시니어 개발자, 혹은 심지어는 완전한 독립 개발자가 될 수도 있다는 의미일까요?

‘주니어 개발자’라는 비유는 아주 적절하네요. Warp에 스펙을 주거나 계획을 짜면서 반복하면, 주니어 개발자 수준의 결과물을 만들어낼 수 있어요. 가끔은 그보다 더 낫기도 하고요. 단순히 코딩만 하는 도구가 아닙니다. 의존성 문제를 해결하고, 서버를 디버깅하고, 충돌 원인을 파악하는 등, 개발자가 할 수 있는 많은 일을 할 수 있어요. 하지만 여전히 더 경험 많은 엔지니어의 가이드가 필요합니다.

시간이 지나면서, Warp는 더 복잡한 작업도 다룰 수 있게 될 겁니다. 모델 자체의 발전 뿐만 아니라 애플리케이션 수준에서도 많은 발전이 있을 테니까요. 더 많은 컨텍스트를 공유하고, 팀의 지식을 더 잘 학습해서 매번 처음부터 시작하지 않도록요. 앞으로 몇 년 안에, 이런 작업 방식을 받아들인 시니어 엔지니어들은 5~10배 더 많은 일을 할 수 있게 될 겁니다. 이 분들의 역할은 뭘 만들지 소통하는 쪽으로 바뀌고, 에이전트가 실행의 대부분을 담당하겠죠. 그러면 엔지니어는 품질, 보안, 그리고 전체 아키텍처와의 적합성을 검토하는 역할을 하게 됩니다.

만약 지금이 주니어 개발자라면, 이런 도구를 활용하는 법을 익혀서 최대한 빨리 시니어 개발자로 성장하는 게 최고의 길일 겁니다.

Q. 그런 도구들이 어떻게 개발자의 성장에 도움을 줄 수 있을까요?

코딩 도구와 개발자 관계를 이야기하면서, 사람들이 간과하는 부분이 있어요. 일자리 대체에 대한 두려움이 많지만, 사실 이 도구들은 학습을 가속화할 수도 있어요.

Warp 같은 도구는 단순히 일을 처리하는 것뿐만 아니라, 설명을 해줍니다. 코드베이스를 한 줄씩 훑어가며 왜 작동하는지 설명해 주거나, 문제를 해결하는 여러 가지의 방법을 보여주면서 각각의 장단점을 알려줄 수도 있죠.

마치 챗GPT 같아요. 속이려고 쓸 수도 있고, 더 빠르게 배우기 위해 쓸 수도 있습니다. 목적에 따라 다른 거죠. 학습을 목표로 Warp를 사용한다면, 놀라운 지름길을 보여줄 수 있습니다.

Q. 프로그래밍 언어에 대해서 두 가지 질문이 있어요. 첫째는, Warp의 베이스 언어로 러스트(Rust)를 선택하셨는데, 러스트가 아니었다면 불가능했을 어떤 것들이 있었나요?

러스트를 선택한 가장 큰 이유는 성능 때문이예요. 개발자들은 앱 속도에 아주 민감하고, 앱이 어떻게 만들어졌는지에 대한 궁금증도 많아요. 러스트는 속도, 안전성에서 장점이 있고, 충돌이 적어요. 저는 강한 ‘타입 언어’를 선호하는데, 러스트는 느리거나 메모리 누수가 있는 앱을 만들게 되는 경우가 별로 없어요.

또 다른 이유는 크로스 플랫폼 지원이예요. Warp는 맥, 윈도우, 리눅스용 네이티브 앱이라든가 웹도 지원합니다. 이 경우에 두 가지 선택지가 있어요. 일렉트론(Electron)으로 웹 플랫폼에서 만들거나, 네이티브로 만들거나 하는 거죠. 저희는 일렉트론으로 Warp를 시제품으로 만들었지만, 금방 성능 문제를 겪었어요. 그래서 러스트를 선택했습니다. 더 어렵지만, 기가바이트 단위의 텍스트를 끊김없이 스트리밍하는 것, 그만한 가치가 있었죠. 러스트의 비동기(Async) 기능들이 이걸 할 수 있게금 해줍니다.

Q. 두 번째로 궁금한 건 이거예요. Warp는 AI와 아주 밀접하게 작동하고, 머신러닝은 대부분 파이썬으로 만들어지는데요. ADE 시대가 오면 러스트나 모조(Mojo) 같은 새로운 언어로 스택이 바뀌게 될까요, 아니면 파이썬이 계속 중심의 위치를 차지할까요?

저희 에이전트 로직의 대부분은 서버에서 실행되는데, 서버는 Go로 만들어졌습니다. 다시 만든다면 러스트로 할 수도 있을 거예요. 그러면 클라이언트와 서버 간에 코드를 공유할 수 있으니까요. Go도 괜찮지만, 제가 엄청 좋아하는 언어는 아닙니다. 러스트와 파이썬 사이에 낀 느낌이라 둘의 장점을 모두 가져가지 못하거든요. AI 작업에는 파이썬이 더 좋았겠지만, 사실 어떤 언어로든 무엇이든 만들 수 있습니다. Go로도 충분히 빠르게 반복 작업할 수 있어서 병목 현상은 없었어요.

Q. 그렇다면 머신러닝 프로그래밍은 왜 파이썬에 계속해서 중심을 두게 되었다고 생각하세요?

하하, 쉽고 쓰기 편하잖아요. 파이썬의 핵심 데이터 라이브러리가 초기에 인기를 끌었죠. 역동적이고 상호작용도 잘 되고, 많은 머신러닝 작업을 시작하게 되는 주피터 노트북과 완벽하게 맞아떨어져요. 컴파일 언어는 여기서는 원하지 않아요. 빠르고, 하이레벨인, 그런 언어를 원하죠. 그래서 파이썬이 머신러닝의 기본 언어가 됐고, 지금도 그건 합리적인 결과라고 봅니다.

Q. 그러네요. 자, 그럼 이제 단순히 소프트웨어 개발이 아닌 에이전트 중심 개발이라는 패러다임에 뛰어들면서, 당신을 가장 흥분하게 만드는 것과 가장 걱정하게 만드는 것은 뭔가요?

저는 오랫동안 개발자로 일을 해 왔어요. 그래서 저를 가장 흥분하게 만드는 건 훌륭한 소프트웨어를 만드는 게 얼마나 쉬워졌는지, 얼마나 더 적은 인원으로 더 많은 것을 만들 수 있는지, 그리고 얼마나 더 많은 사람들이 아예 처음부터 개발을 시작할 수 있게 됐는지 하는 것들이예요. 진입 장벽을 낮추고 많은 장벽을 없애주고 있어요. 저희 팀에는 개발자가 아닌데도 자기 일을 더 잘하기 위해서 앱을 만드는 동료들이 있어요. 엔지니어링 채용 팀장님이 저희 ATS(채용 관리 시스템)와 연결되는 MCP 서버를 직접 만들었죠. 개발자가 아닌데도 이제 자기 워크플로우를 자동화할 수 있게 된 거예요. 정말 흥분되는 일입니다.

가장 걱정되는 것은 ‘엉망진창인 소프트웨어의 홍수’라고 해야 할 것 같네요. 사용자로서 저는 망가진 앱을 쓰는 걸 정말 싫어해요. 처방전을 못 찾는 약국 웹사이트, 눌러도 작동하지 않는 버튼 같은 것들 말이예요. 제가 느끼는 두려움은 이런 것들이 폭발적으로 늘어날 거라는 점입니다. 프로 개발자들의 경우에도, 에이전트 도구를 순수한 ‘바이브 코딩’으로만 사용하면 보안 허점이나 유지보수 불가능한 코드가 생길 수 있어요. 소프트웨어 엔지니어링의 베스트 프랙티스들은 다 이유가 있어서 베스트 프랙티스라고 하는 겁니다. 에이전트가 프로덕션에서 작동하려면, 뭘 만들지 정확하게 명시하고 짧고 긴밀한 피드백 루프를 유지할 수 있는 도구가 필요합니다. 뭐가 만들어지고 있는지 이해하고, 에이전트를 가이드하고, 품질을 보장해야 하죠. 그래서 저는 정말 엉망인 소프트웨어가 많이 출시될까 봐 걱정됩니다.

Q. 세상의 시스템 프롬프트를 바꿔야겠네요 - ‘엉망진창인 소프트웨어를 만들지 말라’고요.

만약 그렇게 말해줄 수 있다면 문제가 해결될 텐데 말이죠. ‘엉망인 소프트웨어는 사양합니다!’ 에이전트는 어떤 의미에서는 마치 미친 천재 같아요. 목표를 주면 그걸 끝없이 추구하니까요. 때로는 테스트를 삭제하고 성공했다고 주장하면서요. 아직 사용자의 문제를 이해하지 못합니다. 그게 핵심이에요. ‘우리가 이걸 왜 만들고 있고, 어떻게 유용할까?’하는, 사용자의 문제를 에이전트가 이해할 때까지는, 사람이 그 맥락을 제공해 줄 수 밖에 없어요.

Q. AGI라든가 초지능 같은 것들에 대해서도 생각해 보시나요?

네, 물론이죠. 제가 시기를 예측할 자격은 없지만, 변화의 속도는 분명히 아주 빠르다고 생각해요. 6개월 전과 비교하면 거의 기하급수적인 변화죠. 일반적으로 그런 변화의 곡선은 S자 형태로 만들어지지만, AI는 자기 개선이 가능하다고 보고 초지능(ASI)을 예상하는 사람들도 있습니다. 아직 그 단계는 아니지만, 발전 속도는 정말 빠릅니다.

Q. 해 주신 말씀을 종합해 보면, 아직은 사람이 개발의 루프 안에 꼭 필요하다는 거군요.

잭: 그게 저희의 생각입니다. 모델은 계속 발전하고 에이전트는 더 자율적으로 될 거예요. 저희는 그런 미래를 위해 Warp를 만들고 있고요. 하지만 오늘날 첫 번째 돌파구는 ‘자동 완성’ 기능이었어요. 이제 에이전트 초기 단계에 진입했지만, 대부분의 개발자들은 아직 에이전트를 사용하지 않아요. 워크플로우가 새롭기 때문이죠. 다음으로는 ‘충돌이 발생했다’는 시스템 트리거에 에이전트가 조사에 나서는 식으로 더 많은 자율성이 나타날 겁니다. 그때도 여전히 긴밀한 루프는 필요할 거예요. 오늘은 반복(Iteration)이지만, 내일은 오케스트레이션(Orchestration)이 될 겁니다. 여전히 의도를 표현하고 에이전트를 대규모로 관리할 수 있는 방법이 필요하죠. 6~12개월 후에는 모든 것이 아주 다르게 보일 테지만, 지금은 긴밀한 루프가 프로덕션 수준의 코드를 배포하는 데 있어서는 핵심적인 개념이라고 봅니다.

Q. 말씀하신 대로 미래를 예측한다는 건 어렵지만, 지금부터 12개월간 일어날 뭔가의 ‘도입’에 초점을 맞춰 본다면 어떤 일이 일어날 거라고 보세요?

현재의 주류 개발자들은 Cursor 같은 자동 완성 기능을 주요 기능으로 채택했다고 봅니다. 에이전트의 경우, AI 열성 팬이나 PM, 디자이너 같은 비기술 직군에서 많이 사용하고 있고, 소수의 프로 개발자들 사이에서도 프롬프트로 작업을 시작하는 경우가 늘고 있습니다. 6~12개월 후에는 에이전트 중심의 워크플로우가 주류가 되고 자동 완성은 보조적인 역할이 될 것이라고 저희 Warp는 예상하고 있습니다. 개발자들은 컴퓨터에게 이러이러한 걸 바꾸라고 요청하고, 적절한 컨텍스트를 제공한 다음, 검토만 하면 된다는 걸 깨닫게 될 겁니다. 또 한편으로는, 특정한 작업(예: 코그니션, 구글의 줄스, 오픈AI의 코덱스 스타일)을 위한 완전 자율 코딩도 함께 성장할 텐데, 그 영역은 계속 확장될 거예요. 단순한 작업은 자동화되고, 기능 구현, 버그 수정, 프로덕션 문제 해결 같은 핵심 작업은 사람의 가이드를 받는 에이전트 중심이 될 겁니다. 2년 후요? 솔직히 모르겠습니다.

Q. 정말 모든 게 미친 듯이 빠르네요. 마지막 질문으로는, 혹시 올해 읽으신 책 중에 진심으로 추천할 만한 책이 있으신가요?

네, 데이빗 도이치(David Deutsch)의 《The Beginning of Infinity》라는 책을 읽고 있습니다.

데이빗은 유명한 물리학자이자 양자 컴퓨팅의 선구자예요. 내용이 아주 방대해서 읽는 데 시간이 좀 걸렸어요. 저는 엔지니어링 전공 전에 과학 철학을 공부해서 그런지 정말 공감되는 부분이 많았습니다.

데이빗은 인간의 지능을 특별하게 만드는 것이 무엇인지, 즉 변형하기 어려운 설명을 만들어내는 우리의 능력, 그리고 그게 어떻게 발전을 이끌어가는지에 대해 썼습니다. 양자 물리학과 다중 우주 이론도 다루죠. 《총, 균, 쇠》나 《괴델, 에셔, 바흐》처럼 세상을 보는 시각을 완전히 바꿔주는 책 중 하나예요. 추천합니다.

Q. 우리의 사고를 확장시켜주는 책이군요. 멋지네요. 오늘 귀한 시간 내주시고 인사이트를 나눠주셔서 정말 감사합니다.

초대해 주셔서 정말 감사하고, 즐거운 시간이었습니다.

Q. 아, 마무리하기 전에, 저희 구독자들에게 공유할 만한 소식 하나만 알려주실 수 있을까요?

그럴까요? 이번 주에 Warp Code라는 아주 중요한 제품을 출시합니다. 아마 이 에피소드가 나갈 때쯤이면 이미 공개됐을 거예요.

몇 가지 핵심 기능이 있습니다.

첫째, 이제 에이전트와 함께 차이점(Diff)을 검토하고 Warp 안에서 직접 편집할 수 있습니다. 워크플로우는 이렇습니다. 코딩 작업을 시작하면 에이전트가 Diff를 실행하고, 개발자는 그 결과를 검토해요. 에이전트에게 수정을 요청하거나 직접 편집할 수도 있어요.

둘째, 파일 편집 기능이 업그레이드됐습니다. 내장된 에디터가 훨씬 더 풍부해져서 Sublime Text와 비슷해졌습니다. 처음부터 코딩을 하는 용도는 아니지만, 에이전트가 만든 코드를 다듬고 개선하는 데 거의 완벽한 도구예요.

셋째, 이제 에이전트가 새 프로젝트를 시작하거나 깃허브(GitHub)에서 프로젝트를 가져오고, 프로젝트 기반 규칙을 설정하고, 프로젝트 수준의 인덱스를 구축할 수 있습니다. 이 모든 과정을 간소화했죠. 또, 다른 에이전트 도구에서 볼 수 있는 슬래시 명령어(/init, /code-review 등)를 Warp에 바로 추가했습니다.

Warp를 주요 코딩 도구로 사용하고 싶다면, 이번 업데이트로 개발자의 경험이 훨씬 좋아졌다는 걸 느끼실 거예요.

Q. 멋진 소식이네요. 인터뷰 감사합니다!

저도 감사합니다.

읽어주셔서 감사합니다. 친구와 동료 분들에게도 뉴스레터 추천해 주세요!