메일함에 JetBrains Air 윈도우 버전 출시 안내가 와 있었어요. 그전까지는 Air라는 제품에 별 관심이 없었고, 솔직히 있는지도 몰랐습니다. 예전 같았으면 JetBrains 새 제품이라는 말만 보고 바로 눌러봤겠지만, 이번에는 메일을 한참 묵혀 두었다가 열어봤어요.
저는 JetBrains All Products Pack을 3년 단위로 연장해 쓰던 사람이었습니다. 새 IDE나 새 기능이 나오면 꽤 꼼꼼히 살펴보던 때도 있었고요. 그런데 작년부터는 IntelliJ IDEA만 구독하는 쪽으로 줄였고, 지금은 그 구독도 계속할지 잘 모르겠어요.
그래서 Air를 보며 먼저 든 감정은 제품 자체에 대한 호기심보다, 조금 안타깝고 씁쓸한 쪽에 가까웠어요. JetBrains가 못해서 그런 건 아닙니다. 오히려 아직도 다음 시대로 넘어가려고 바쁘게 뛰고 있다는 게 보여서, 그 모습이 더 씁쓸했습니다.
공식 블로그에 따르면 JetBrains Air는 2026년 6월 29일에 윈도우 지원을 추가했습니다. x64와 ARM64 다운로드를 모두 제공하고, Plan 모드, Git worktree 기반 병렬 실행, 에이전트 결과 리뷰, 한 에이전트가 만든 코드를 다른 에이전트에게 리뷰시키는 흐름까지 담았습니다.
윈도우 지원 자체가 중요하다는 뜻은 아니에요. 저한테 그 메일은 Air라는 제품을 처음 보게 만든 계기였을 뿐입니다. 정작 마음에 걸린 건 따로 있었어요. “JetBrains가 왜 이런 제품을 만들어야 했을까”라는 질문입니다.
한때 JetBrains는 개발 도구의 정답이었다#
저한테 JetBrains는 오랫동안 “개발 도구의 정답”에 가까웠어요.
자바나 코틀린을 한다면 IntelliJ IDEA를 여는 게 너무 당연했습니다. 파이썬은 PyCharm, 웹은 WebStorm, 고는 GoLand, C#은 Rider처럼 언어마다 믿고 쓰는 제품이 있었고, All Products Pack 하나면 거의 모든 개발 환경을 JetBrains 안에서 해결할 수 있다는 느낌도 있었어요.
강점도 분명했습니다.
- 코드 탐색이 좋다
- 자동완성이 좋다
- 리팩터링이 안전하다
- 디버거가 편하다
- 큰 프로젝트를 이해하는 능력이 좋다
- 언어별 세부 동작을 깊게 안다
특히 IntelliJ IDEA는 그냥 편집기가 아니었어요. 제 기준에서는 거의 조종석이었습니다. 프로젝트를 열고, 구조를 보고, 호출 경로를 따라가고, 리팩터링하고, 테스트를 돌리고, 디버깅하는 흐름이 모두 IDE 안에 들어 있었어요.
그래서 저는 All Products Pack을 계속 연장했습니다. 돈이 아깝지 않았어요.
그런데 작년부터는 IntelliJ IDEA만 구독하는 쪽으로 바꿨고, 지금은 그 구독도 계속할지 모르겠어요. 싫어진 건 아닙니다. 그냥 손이 덜 갑니다.
이제 코드를 직접 편집하는 시간이 줄었다#
요즘 제 개발 흐름은 예전과 많이 달라졌어요.
예전에는 코드를 직접 열고 고쳤습니다. 에러가 나면 해당 파일로 가고, 관련 함수를 찾고, 코드를 읽고, 수정하고, 테스트를 돌렸어요. 좋은 편집기와 좋은 IDE가 곧 생산성이던 시절이었습니다.
그런데 이제는 에이전트에게 일을 맡기는 시간이 훨씬 많아졌어요.
문제를 설명하고, 관련 맥락을 주고, 실패 로그를 보여주고, 테스트를 돌리게 하고, 패치를 만들게 합니다. 저는 그 결과를 보고 방향을 잡거나, 위험한 지점을 짚거나, 다시 시켜요.
냉정하게 말하면 에이전트는 저보다 코딩을 잘합니다. 적어도 많은 경우에는 그래요.
타이핑이 빠르다는 뜻은 아니에요. 에이전트는 지치지 않고 파일을 탐색하고, 여러 가능성을 시험하고, 테스트를 돌리고, 실패 로그를 다시 읽은 뒤 패치를 만듭니다. 사람이 편집기 앞에서 직접 줄을 고치는 방식과는 처리량이 달라요.
물론 저는 diff를 보면 코드를 이해할 수 있습니다. 변경 의도도 읽고, 이상한 부분도 찾을 수 있어요.
문제는 바로 그 지점입니다. 이제 사람이 diff를 전부 읽는 일이 병목이 되기 시작했어요.
diff 리뷰가 안전장치에서 병목으로 바뀐다#
예전에는 코드 리뷰가 자연스러운 안전장치였어요. 사람이 코드를 쓰고, 다른 사람이 줄 단위로 읽고, 이상한 부분을 잡았습니다. 코드가 만들어지는 속도와 리뷰 속도가 어느 정도 맞았기 때문입니다.
하지만 에이전트가 한 번에 여러 파일을 고치고, 여러 작업을 병렬로 수행하고, 다른 에이전트가 다시 리뷰까지 하는 흐름으로 가면 이야기가 달라집니다.
사람이 모든 diff를 줄 단위로 읽는 방식은 더 이상 잘 확장되지 않아요.
그래서 앞으로는 “모든 코드를 읽는 능력”보다 “무엇을 검증해야 하는지 아는 능력”이 더 중요해질 가능성이 큽니다.
제가 보고 싶은 건 단순한 diff 묶음이 아니에요. 이런 증거입니다.
- 원래 문제가 무엇이었는지
- 에이전트가 어떤 해결 방향을 택했는지
- 어떤 파일과 경계를 건드렸는지
- 어떤 테스트가 실패했고, 어떤 테스트가 통과했는지
- 공개 API나 데이터 구조가 바뀌었는지
- 권한, 결제, 삭제, 마이그레이션 같은 위험 지점이 있는지
- 되돌릴 수 있는 변경인지
- 아직 남은 불확실성이 무엇인지
diff는 여전히 필요합니다. 다만 중심은 아니에요. 궁금하거나 위험한 부분을 깊게 볼 때 펼쳐보는 감사 자료에 더 가까워질 것 같습니다.
이 지점에서 IDE의 역할도 달라집니다.
예전 IDE는 개발자가 직접 코드를 쓰는 작업대였어요. 앞으로의 IDE는 어쩌면 에이전트가 만든 결과를 검증하는 현미경에 가까워질지도 모릅니다.
터미널로 돌아가는 게 이상하게 자연스럽다#
재밌는 건, 에이전트 중심으로 갈수록 개발 환경이 오히려 터미널 쪽으로 돌아간다는 점이에요.
겉으로는 인공지능, 에이전트, 자동화, 병렬 실행 같은 미래형 단어가 붙습니다. 그런데 실제 사용감은 꽤 텍스트 중심이에요.
- 요구사항은 텍스트로 준다
- 로그는 텍스트로 나온다
- 테스트 결과도 텍스트다
- 패치도 텍스트다
- Git도 텍스트 흐름에 잘 맞는다
- 에이전트의 작업 기록도 텍스트다
에이전트에게 터미널은 꽤 좋은 무대입니다. 입력과 출력이 분명하고, 실행 기록이 남고, 재현하기 좋으며, 원격 서버에서도 자연스럽게 돌아가요.
그래서 TUI로 돌아가는 흐름이 퇴보처럼 느껴지지 않습니다. 오히려 에이전트 시대에는 이쪽이 더 잘 맞는 옷처럼 보여요.
코드 편집기는 사람이 손으로 코드를 짤 때 가장 강력했습니다. 하지만 에이전트가 작업을 수행하고 사람이 검증하는 구조에서는, 화려한 편집 화면보다 명령, 로그, 패치, 테스트 결과, 작업 목록이 더 중요해집니다.
JetBrains가 Air를 만든 이유도 여기에 있을 거예요.
Air는 터미널 에이전트와 풀 IDE 사이의 빈 공간을 겨냥합니다. 공식 블로그에서도 그렇게 설명합니다. Plan 모드로 작업을 정의하고, Git worktree에서 에이전트를 병렬로 실행하고, 결과를 리뷰하는 흐름입니다. 방향은 분명히 맞아요.
동시에 이것이 JetBrains의 몸부림처럼 보이는 이유도 여기에 있습니다.
앱 형태라는 애매한 자리#
Air를 보면서 더 안타까웠던 지점은 여기였어요. JetBrains가 들고 온 답이 결국 “앱 형태의 개발 환경”이라는 점입니다.
코드를 잘 모르는 라이트 유저라면 굳이 JetBrains라는 이름값에 크게 반응하지 않을 가능성이 큽니다. 그 사람들에게 중요한 건 JetBrains의 26년 개발 도구 역사나 리팩터링 엔진이 아니에요. 그냥 코덱스 앱이든 클로드 코드 앱이든, 설명을 넣었을 때 원하는 결과가 나오느냐가 더 중요합니다. 이 층에서는 JetBrains 브랜드가 생각보다 큰 무기가 아닐 수 있어요.
반대로 이미 에이전트 개발에 익숙한 파워 개발자들은 터미널 CLI 쪽으로 가고 있습니다. 파일, 로그, 테스트, Git, 서버, 작업트리가 모두 그 안에 있기 때문이에요. 이 사람들에게 별도의 데스크톱 앱은 오히려 무겁고 거추장스럽게 느껴질 수 있습니다. 에이전트에게 일을 시키려고 굳이 새 앱을 열어야 한다면, 이미 터미널에서 잘 굴러가던 흐름이 한 번 더 끊깁니다.
그러면 Air는 애매한 위치에 놓입니다.
- 라이트 유저에게는 JetBrains 이름값이 크게 와닿지 않는다
- 파워 개발자에게는 앱이 CLI보다 무겁게 느껴질 수 있다
- 기존 IDE 사용자에게는 방향은 이해되지만, 이미 작업 습관이 바뀌었을 수 있다
그래서 더 안타까워요. 제품의 방향이 완전히 틀린 것은 아닌데, 겨냥해야 할 사용자의 습관이 이미 양쪽으로 갈라진 뒤에 나온 느낌이 있습니다. JetBrains는 여전히 좋은 도구를 만들고 있지만, 이제는 “좋은 앱”이라는 답만으로 개발자의 중심을 다시 가져오기 어려운 시대가 된 것 같습니다.
JetBrains가 잘하던 문제의 중요도가 내려간다#
JetBrains가 못해서 안타까운 게 아닙니다. 오히려 반대입니다.
JetBrains는 여전히 코드를 깊게 이해하는 회사입니다. 언어별 분석, 리팩터링, 탐색, 디버깅 같은 영역에서는 아직도 강합니다. 다만 개발자가 매일 마주하는 병목이 바뀌고 있습니다.
예전 병목은 이랬습니다.
내가 코드를 얼마나 빠르고 정확하게 쓸 수 있는가?
지금 병목은 점점 이렇게 바뀝니다.
에이전트가 만든 결과가 정말 맞는지 어떻게 판단할 것인가?
이 질문 앞에서는 전통적인 IDE의 강점이 그대로 1등 카드가 되지 않습니다. 좋은 코드 편집과 탐색은 여전히 중요하지만, 중심은 작업 지휘와 검증 쪽으로 옮겨갑니다.
그래서 JetBrains Air가 흥미롭습니다. 방향은 맞습니다. 하지만 늦게 전장에 들어온 느낌도 있습니다.
개발자들의 습관은 이미 많이 바뀌었습니다. Claude Code, Codex CLI, OMP 같은 도구를 쓰는 사람들은 점점 편집기가 아니라 에이전트 세션에서 개발 흐름을 시작합니다.
IDE를 열지 않는다는 말은 과장이 아닙니다. 정말로 코드 편집기를 거의 쓰지 않는 날이 생깁니다.
그때 IDE는 사라지는 것이 아니라 중심에서 밀려납니다. 필요할 때 여는 고급 분석 도구가 됩니다.
이 변화가 씁쓸합니다. JetBrains는 개발자가 직접 코드를 쓰던 시대의 최고 도구를 만들었는데, 이제 그 시대의 전제 자체가 흔들리고 있기 때문입니다.
개발자는 점점 현업이 되어 간다#
이 흐름 속에서 개발자의 역할도 바뀝니다.
앞으로 개발자는 점점 “코드를 쓰는 사람”이라기보다, 현업과 기술 사이에서 문제를 정의하고 결과를 검증하는 사람이 될 가능성이 큽니다.
예전 개발자의 핵심 역할은 요구사항을 코드로 바꾸는 일이었습니다.
요구사항 → 설계 → 코드 → 테스트 → 배포
하지만 에이전트가 구현을 맡기 시작하면 사람의 역할은 이렇게 바뀝니다.
현실 문제 → 정확한 정의 → 검증 가능한 조건 → 에이전트 실행 → 증거 기반 승인
이때 중요한 것은 단순 코딩 실력이 아닙니다. 도메인 지식입니다.
결제 시스템을 예로 들면, “결제 실패 시 재시도”라는 요구사항은 코드로는 간단해 보일 수 있습니다. 하지만 실제로는 승인 전 실패인지, 승인 후 콜백 실패인지, 정산 반영 전 실패인지, 사용자에게는 실패로 보였지만 카드 승인은 된 상태인지가 모두 다릅니다.
이 차이를 모르면 에이전트는 틀린 목표를 아주 성실하게 구현할 수 있습니다.
그래서 앞으로 개발자의 해자는 이런 쪽으로 옮겨갈 것 같습니다.
- 도메인 지식
- 문제 정의 능력
- 검증 기준 설계
- 위험 감각
- 운영 감각
- 데이터 해석
- 제품 판단
- 에이전트에게 일을 나누는 능력
반대로 가장 위험한 위치는 이쪽일 겁니다.
현업보다 업무를 모르고, 에이전트보다 구현을 못하는 개발자.
예전에는 그래도 “코드로 만들 수 있다”는 것만으로 가치가 컸습니다. 하지만 구현 장벽이 내려가면 결국 누가 문제를 더 정확히 아는지가 중요해집니다.
현업은 점점 개발자화되고, 개발자는 점점 현업화됩니다. 경계가 흐려집니다.
개발자가 사라지는 것이 아니라 층이 올라간다#
이 말을 개발자의 종말처럼 받아들일 필요는 없다고 봅니다.
개발자가 필요 없어지는 게 아니라, 개발자가 서 있는 층이 올라가는 것에 가깝습니다. 손으로 모든 코드를 직접 쓰는 능력보다, 시스템이 올바른 방향으로 움직이게 만드는 능력이 중요해집니다.
코딩 능력이 쓸모없어지는 것도 아닙니다. 다만 코딩 능력은 직접 생산력에서 감사 능력 쪽으로 옮겨갑니다.
- 이 변경이 왜 위험한지 알아보는 능력
- 상태가 어디서 깨질 수 있는지 보는 능력
- 트랜잭션 경계와 권한 경계를 의심하는 능력
- 테스트가 진짜 행동을 검증하는지 판단하는 능력
- 에이전트가 넣은 우회 코드를 알아차리는 능력
이런 감각은 여전히 개발자의 감각입니다. 다만 하루 종일 편집기에서 줄을 고치는 방식은 줄어들 수 있습니다.
앞으로 좋은 개발자는 아마 이런 사람일 겁니다.
도메인을 이해하고, 에이전트에게 일을 시키고, 결과를 증거로 검증하고, 최종 책임을 질 수 있는 사람.
이 정의는 예전 개발자상과 꽤 다릅니다. 하지만 나쁘지만은 않습니다.
오히려 현실에 더 가까운 역할일 수도 있습니다. 개발은 원래 코드 자체가 목적이 아니라, 현실 문제를 해결하기 위한 수단이었으니까요.
JetBrains Air를 보며 씁쓸했던 이유#
그래서 JetBrains Air 홍보 메일을 보고 마음이 복잡했습니다.
제품 방향은 이해됩니다. 에이전트 시대에 맞춰 Plan 모드, 병렬 작업, worktree, 리뷰 흐름을 묶는 것은 당연히 필요합니다. JetBrains가 가진 코드 이해 능력과 연결되면 꽤 강력한 도구가 될 수도 있습니다.
하지만 동시에, 이것은 JetBrains가 예전처럼 개발자의 중심 자리를 당연하게 차지하던 시대가 끝났다는 신호처럼 보였습니다.
예전 JetBrains는 말 그대로 작업대였습니다.
이제 JetBrains는 에이전트 시대의 지휘판이 되려고 합니다.
그 전환이 성공할지는 모르겠습니다. 하지만 전환해야 한다는 사실 자체가 시대 변화를 보여줍니다.
저는 아직 JetBrains를 좋아합니다. IntelliJ IDEA를 열면 여전히 잘 만든 도구라는 생각이 듭니다. 그런데 구독을 계속할 이유가 예전만큼 강하지 않습니다.
이 감정이 제일 씁쓸합니다.
좋은 도구인데, 나쁜 도구가 된 것도 아닌데, 그냥 제 작업 흐름의 중심에서 밀려나고 있습니다.
한때 개발자에게 IDE는 집이었습니다. 이제는 에이전트 세션, 터미널, 로그, 테스트, diff, 작업트리가 집이 되어 가고 있습니다. IDE는 그 집 안의 방 하나가 되는 느낌입니다.
정리하면#
JetBrains Air를 처음 보고 든 생각은 운영체제 지원 소식보다 개발 도구의 무게중심 변화에 가까웠습니다.
제 눈에는 Air라는 제품이 이렇게 읽혔습니다.
- JetBrains도 에이전트 중심 개발을 피할 수 없다고 보고 있다
- IDE 중심 시대는 저물고 있다
- 개발 환경은 오히려 텍스트와 터미널 중심으로 돌아가고 있다
- 코드 작성보다 문제 정의와 검증이 병목이 되고 있다
- 개발자는 점점 도메인 지식으로 살아남아야 한다
- diff를 보는 능력보다, diff를 보지 않아도 믿을 수 있는 검증 구조가 중요해지고 있다
JetBrains Air가 성공할지는 아직 모르겠습니다. 하지만 이 제품이 나왔다는 사실만으로도 개발 도구의 무게중심이 어디로 이동하는지는 꽤 선명해졌다고 봅니다.
저는 아마 당분간 JetBrains 구독을 다시 늘리지는 않을 것 같습니다. JetBrains가 싫어져서가 아닙니다. 제가 코드를 쓰는 방식이 바뀌었기 때문입니다.
그리고 어쩌면 앞으로의 개발자는 코드를 더 적게 쓰고, 더 많이 판단하는 사람이 될지도 모르겠습니다.
여러분은 어떻게 느끼시나요? 아직 IDE가 개발의 중심인가요, 아니면 에이전트와 터미널이 이미 중심을 가져갔다고 보시나요? JetBrains Air 같은 도구가 그 사이에서 다시 자리를 만들 수 있을지도 궁금합니다.