Daily News Korea

[태그:] 개발자

  • MPC 창시자 로저 린, ‘단일 탭’ 고수 비결은?

    MPC 창시자 로저 린, ‘단일 탭’ 고수 비결은?

    브라우저 탭이 지금 몇 개 열려 있는지 한번 세어보자. 10개? 20개? 그 중에 실제로 지금 보고 있는 건 하나뿐인 경우가 태반이다. 힙합 비트메이킹의 판을 통째로 바꾼 MPC 창시자 로저 린(Roger Linn)은 탭을 딱 하나만 열어둔다. 그것도 의도적으로, 고집스럽게.

    LM-1에서 MPC60까지 — 로저 린이 뭘 만든 사람인지

    1980년대 초, 로저 린은 LM-1을 내놓았다. 드럼 머신 역사에서 최초로 실제 타악기 소리를 샘플링한 장비였다. 그 전까지 드럼 머신들이 전자 신호로 만들어낸 인공 소리를 썼던 것과는 차원이 달랐다.

    후속작 린드럼(LinnDrum)은 더 멀리 나아갔다. 마이클 잭슨, 프린스의 앨범에 그 소리가 박혔다. 80년대 팝과 R&B 히트곡들의 뼈대를 뜯어보면 상당수가 린드럼이다. 본인이 모르고 들었던 곡들에도 이미 깔려 있을 가능성이 높다.

    그리고 1988년. 아카이(Akai)와 함께 출시한 MPC60이 세상에 나왔다. 샘플러, 시퀀서, 드럼 머신을 하나로 묶었다. 비트 메이킹이라는 개념 자체를 새로 정의한 기계였고, 힙합 프로듀서들에게는 지금도 성경 같은 존재다. 단순한 악기가 아니라 창작의 문법을 바꾼 도구였으니까.

    탭 하나, 그게 다

    The Verge 보도를 보면 로저 린이 요즘도 브라우저 탭을 단 하나만 켜고 작업한다는 게 나온다. 처음엔 그냥 옛날 사람의 습관인가 싶었는데, 읽을수록 그게 아니다. 철학이다.

    탭을 많이 열어두면 뭔가 일을 많이 하는 것 같은 기분이 든다. 실제로는 그 사이를 왔다 갔다 하면서 아무것도 제대로 못 하는 경우가 많다. 인지과학에서 ‘컨텍스트 스위칭 비용’이라고 부르는 현상이다. 작업 하나에서 다른 작업으로 전환할 때마다 뇌는 재정비 시간이 필요하고, 그 비용이 쌓이면 하루가 끝나도 정작 깊이 있는 결과물은 없다.

    로저 린은 그걸 직관적으로 알았거나, 아니면 오래 겪으면서 자연스럽게 도달했을 수도 있다. 탭 하나. 지금 하는 것만. 그게 그의 작업 방식이다.

    솔직히 이걸 따라 하기가 쉽지 않다. 업무 특성상 여러 창을 동시에 봐야 하는 경우가 분명히 있다. 하지만 ‘지금 이 탭이 꼭 열려 있어야 하는가’를 한 번씩만 따져도 반은 줄일 수 있다. 알림이 와서 탭을 열었는데 실제로 볼 필요가 없는 것들, 생각보다 많다.

    이 습관이 창의력과 무슨 상관인가

    LM-1을 만들 때, 린드럼을 설계할 때, MPC60을 구상할 때 — 공통점이 있다. 한 가지 문제를 끝까지 파고드는 방식으로 만들어진 결과물이라는 거다. 샘플링을 어떻게 음악에 쓸 수 있을까, 시퀀서와 드럼 머신을 합치면 어떤 새 가능성이 열릴까. 그 질문 하나에 오래 붙어 있었기 때문에 나온 물건들이다.

    창의적인 돌파구는 대부분 멍하게 아이디어가 떠오르는 게 아니다. 한 문제에 오래 머물다가 나온다. 뇌가 그 문제에 충분히 잠겨 있어야 연결고리를 찾기 시작한다. 탭을 계속 넘기며 자극을 받는 상태에서는 그 잠김이 일어나지 않는다.

    딥 워크(Deep Work) 개념을 정립한 칼 뉴포트가 한 말과 정확히 같은 맥락이다. 깊이 있는 집중이 없으면 표면적인 결과물만 나온다. 로저 린의 단일 탭 습관은 그걸 브라우저 레벨에서 구현한 것이다.

    개발자와 창작자에게 이게 왜 중요한가

    코드를 짜거나 글을 쓰거나 디자인을 하거나 — 깊이 들어가야 하는 작업일수록 방해가 치명적이다. 유튜브 탭, 슬랙 탭, 이메일 탭, SNS 탭이 다 열려 있으면 주의는 계속 분산된다. 알림 하나가 뜨면 5분이 날아가는 경우도 허다하다.

    멀티태스킹이 생산성의 상징처럼 여겨지던 시대가 있었다. 지금은 다르다. 연구들을 보면, 동시에 여러 작업을 하는 게 효율적인 경우는 두 작업 중 하나가 아주 단순할 때만 해당한다. 코드 리뷰를 하면서 슬랙을 동시에 잘 보는 사람은 없다. 둘 다 절반씩 하는 거다.

    로저 린의 방식을 그대로 복사할 필요는 없다. 탭 하나만 열기가 현실적으로 어렵다면, 시작점은 더 작게 잡아도 된다. 집중이 필요한 시간대 2시간 동안만 관련 없는 탭을 전부 닫아본다. 슬랙 알림을 1시간 단위로 확인한다. 브라우저 탭 수에 상한선을 스스로 정해본다. 그것만으로도 체감이 달라진다고 하는 사람들이 꽤 있다.

    결국 로저 린이 말하지 않고 몸으로 보여주는 건 이거다. 전설적인 물건을 만드는 사람들이 특별한 비결을 가진 게 아니라, 대부분의 사람들이 흘려버리는 집중력을 지켜냈다는 것. 탭 하나가 그 상징이다.

    출처: The Verge

    관련 기사

  • AI 코딩 시대: 개발자 실력 퇴화 없이 성장하는 법

    AI 코딩 시대: 개발자 실력 퇴화 없이 성장하는 법

    레딧(Reddit) 개발자 커뮤니티에서 요즘 자주 보이는 말이 있다. “AI가 내 뇌를 썩게 한다.” 농담처럼 쓰지만, 절반은 진심이다. GitHub Copilot이나 Claude, ChatGPT 같은 AI 코딩 도구가 일상 깊숙이 들어온 지금, 생산성은 올라갔는데 실력은 제자리라는 느낌을 받는 개발자들이 늘고 있다. 이게 착각일까, 아니면 실제 문제일까.

    AI 코딩 도구, 편한 건 맞는데

    정규 표현식 하나 쓸 때마다 검색하던 시절이 있었다. 이제는 AI한테 물어보면 3초 안에 나온다. 특정 API 사용법, 간단한 유틸리티 함수, 반복적인 보일러플레이트 코드 — 이런 건 AI가 확실히 빠르다. 작업 효율이 올라가고, 덕분에 더 복잡한 문제에 집중할 시간이 생기는 건 분명한 이점이다.

    근데 문제가 있다. AI가 만들어준 코드를 그냥 붙여넣다 보면, 그 코드가 왜 그렇게 동작하는지 모르는 채로 넘어가는 경우가 생긴다. 디버깅 상황이 오면 그제야 발등에 불이 떨어진다. AI가 짠 코드 구조를 파악 못 해서 에러 하나 잡는 데 몇 시간을 쓰는 일도 적지 않다. AI는 “확률적으로 그럴듯한 코드”를 내놓는 것이지, 최적의 정답을 보장하지 않는다. 보안에 취약한 코드, 비효율적인 알고리즘을 아무렇지 않게 생성하기도 한다. 이 점은 분명히 짚고 가야 한다.

    “왜?”를 묻는 습관이 전부다

    AI 코드를 복사해서 붙여넣기만 하면 성장이 멈춘다. 좀 과한 말처럼 들릴 수 있는데, 실제로 그렇다. 코드 한 줄이 있으면 왜 이 방식인지, 왜 이 알고리즘인지, 메모리나 성능 측면에서 어떤 영향이 있는지를 파고드는 습관이 필요하다. “어떻게 동작하는지”가 아니라 “왜 이렇게 설계됐는지”를 물어야 한다.

    수학 시험에서 답만 외운 학생은 응용 문제에서 무너진다. 풀이 과정을 이해한 학생은 변형 문제도 푼다. 개발도 똑같다. AI가 제시한 해결책의 근거를 직접 찾아가는 과정 — 그게 문제 해결 능력을 키우는 가장 확실한 방법이다. AI는 해결책을 주지만, 그 해결책이 왜 맞는지 또는 더 나은 대안이 있는지는 알려주지 않는다. 그 빈틈을 채우는 게 개발자의 몫이다.

    AI 코드는 ‘초안’이다. 끝이 아니라 시작

    AI가 생성한 코드를 최종 결과물로 쓰면 안 된다. 보안 취약점은 없는지, 성능 저하 요소는 없는지, 6개월 뒤에 다른 사람이 읽어도 이해되는 구조인지 — 이걸 직접 따져보는 게 개발자 몫이다. 그냥 문법 오류 잡는 수준이 아니라, 코드 전체를 자기 코드처럼 리뷰해야 한다는 얘기다.

    예를 들어 AI가 단순 반복문으로 처리한 부분을 스트림(Stream) API나 람다(Lambda)식으로 리팩토링하거나, 더 적합한 라이브러리 함수를 찾아 교체하는 작업. 이게 AI가 절대 대신해줄 수 없는 영역이다. 저는 AI가 짠 코드에 제 이름을 올리기 전에 항상 “더 좋게 만들 수 있을까?”를 먼저 고민한다. 이 습관 하나가 실력 차이를 만든다. 더 효율적인 알고리즘이나 깔끔한 디자인 패턴으로 개선하는 작업 — 이건 개발자의 고유한 영역이고, 이 과정이 쌓여야 진짜 실력이 된다.

    기본기는 여전히 대체 불가다

    알고리즘, 자료구조, 운영체제, 네트워크, 데이터베이스. AI가 아무리 발전해도 이 영역의 이해는 흐릿해지면 안 된다. AI가 엉뚱한 코드를 뱉었을 때 “이게 왜 틀렸는지” 바로 캐치하는 능력은 기본기에서 나온다. 건축가가 최첨단 설계 도구를 써도 재료 특성과 구조 역학을 모르면 건물이 무너지는 것과 같은 이치다. 도구가 좋아질수록, 도구를 제대로 쓸 사람의 기반도 탄탄해야 한다.

    객체 지향, 함수형 같은 패러다임에 대한 깊이 있는 이해가 있어야 AI가 제안한 코드를 제대로 평가할 수 있다. AI 시대라고 고전 서적을 내려놓을 이유가 없다. 오히려 기본기가 탄탄할수록 AI를 더 잘 쓸 수 있다. “어떻게” 동작하는지를 아는 것을 넘어 “왜 그렇게 해야 하는지”를 아는 것 — 그게 결국 기본기에서 나온다. 바닥부터 코드를 짜보는 연습을 꾸준히 해야 하는 이유가 여기 있다.

    AI 도구 자체를 새 기술 스택처럼 배워라

    GitHub Copilot, ChatGPT, Claude — 이 도구들도 특징이 다르고 잘 맞는 상황이 다르다. 그냥 “AI 씀”으로 끝내지 말고, 각 도구의 강약점을 파악해서 상황에 맞게 고르는 안목이 필요하다. 프롬프트 엔지니어링, 즉 AI한테 원하는 결과를 끌어내는 능력은 이제 개발자의 실질적인 역량이 됐다. 이걸 기술 스택 하나 더 배우는 것처럼 접근하면 된다.

    코드 생성 말고도 AI를 쓸 수 있는 곳이 많다. 문서 작성 보조, 테스트 케이스 생성, 리팩토링 제안, 버그 탐지 — 이 4가지만 잘 활용해도 개발 흐름이 달라진다. “AI가 나쁜 건가”를 따지기보다 “어디에 쓰면 내 생산성이 올라가나”를 고민하는 게 훨씬 현실적이다. AI를 외면하거나 무조건 쓰는 양쪽 극단 모두 손해다.

    AI는 도구다. 동료처럼 쓰되, 판단은 내가 한다

    AI를 똑똑한 주니어 개발자처럼 생각하면 편하다. 시키는 건 잘하는데, 맥락을 완전히 이해하거나 최적의 판단을 내리는 건 아직 부족하다. 단순 반복 코딩, 빠른 정보 탐색 — 이건 AI한테 맡기면 된다. 대신 개발자는 그 시간에 더 높은 수준의 문제에 집중해야 한다.

    새로운 시스템 아키텍처를 설계하거나, 복잡한 비즈니스 로직을 구현하거나, 팀원과 방향을 맞추거나, 예측 못 한 문제에서 통찰을 찾는 일 — 이건 아직 사람의 영역이다. 사용자 경험(UX) 개선도 마찬가지다. AI는 이 과정에서 보조 역할을 할 뿐이다. 개발자의 역할이 “코드 짜는 사람”에서 “AI와 협력해 문제 푸는 사람”으로 바뀌고 있다는 건, 솔직히 나쁘지 않은 변화다.

    결국 갈리는 건 이 차이다

    AI를 능숙하게 활용해 생산성을 끌어올리는 개발자와, AI에 의존하다가 실력이 정체되는 개발자. 이 둘의 격차는 앞으로 더 벌어질 가능성이 높다. 비판적 사고력과 지속적인 학습 — 식상하게 들리지만, AI 시대에 가장 실질적인 무기다. 변화에 능동적으로 적응하는 개발자가 결국 롱런한다.

    AI는 특정 기술 스킬을 단순화하거나 대체할 여지가 분명히 있다. 동시에 더 큰 문제를 풀 수 있는 여지도 만들어준다. AI라는 도구를 어떻게 쓸지는 결국 개발자 손에 달려 있다. 스스로 성장하기 위해 AI를 쓰는 사람과, AI에 기대 성장을 멈추는 사람. 어느 쪽이 될지는 지금 하는 선택들이 쌓여서 결정된다.

    출처: Reddit r/technology

    관련 기사

  • AI 시대 클라우드: 개발자에게 필요한 건 무엇? 새로운 플랫폼 선택 가이드

    AI 시대 클라우드: 개발자에게 필요한 건 무엇? 새로운 플랫폼 선택 가이드

    AWS 콘솔 들어가본 사람은 안다. 메뉴 구조부터 과금 방식까지, 뭔가 하나 바꾸려면 문서 3개는 뒤져야 한다. 그런데 Claude나 ChatGPT는 3초 만에 코드를 뽑아준다. 이 속도 차이가 이제 실제 개발 병목으로 드러나고 있다.

    AI 코딩 도구 덕분에 초안 작성 속도는 폭발적으로 빨라졌는데, 배포·인프라 구성은 아직도 옛날 방식이다. 코드를 만드는 속도와 그걸 실행하는 환경 사이의 간극. 이게 지금 개발자들이 느끼는 가장 큰 불편이다.

    AI 코딩 도구가 만들어낸 새로운 병목

    AI 에이전트가 초 단위로 코드를 뽑아내는데, 배포는 2~3분이 걸린다. 테라폼 돌리고, 파이프라인 기다리고. 이 2~3분이 집중력을 끊는다. 작은 것 같아도 하루에 수십 번 반복되면 생산성 차이가 엄청 난다.

    • 속도 병목: AI가 생성한 코드를 바로 올릴 수 없다. 기존 배포 파이프라인이 AI 속도를 못 따라간다.
    • 복잡한 의존성: AI 앱은 GPU, 대용량 메모리, 복잡한 패키지 조합을 요구한다. 기존 클라우드에서 세팅하는 데 시간이 한참 든다.
    • 예측 불가 비용: 쓰든 안 쓰든 프로비저닝된 VM 값은 나간다. AI 워크로드는 몰아 쓰고 쉬는 패턴이 많아서 유휴 시간 비용이 그냥 날아간다.

    한 전문가는 “신과 같은 지능이 3초 안에 문제를 해결하는데 시스템이 병목이 되면 안 된다”고 했다. 맞는 말이다. 문제는 기존 클라우드 구조가 이 속도에 맞게 설계된 게 아니라는 점이다.

    AWS·GCP가 느리고 비싼 이유

    아마존 웹 서비스(AWS)나 구글 클라우드(GCP)가 나쁜 건 아니다. 그냥 AI 시대에 맞게 설계된 게 아닐 뿐이다. 이 플랫폼들은 원래 ‘모든 것을 위한’ 범용 인프라다.

    • 범용성의 역설: 모든 걸 다 지원하려다 보니 특정 워크로드에선 비효율이 생긴다. AI 추론처럼 요구사항이 뚜렷한 작업에서 이 비효율이 도드라진다.
    • 과금 구조 문제: ‘프로비저닝된 용량’에 대해 돈을 낸다. 실제 사용량이 아니다. 유휴 VM도 돈이 나간다. 한 기업 CTO는 이전 인프라에서 월 1만 5천 달러 나가던 게 플랫폼 이전 후 월 1천 달러로 줄었다고 밝혔다. 15분의 1이다.
    • 배포 속도: 테라폼(Terraform) 같은 표준 도구를 써도 배포 한 번에 2~3분은 기본이다. AI 에이전트가 초 단위로 코드를 만들어내는 속도와 맞지 않는다.
    • 레거시의 무게: 수조 원 규모의 레거시 수익 모델이 있다. 기존 고객 유지와 새 기술 도입 사이에서 구조를 쉽게 바꾸지 못한다. 이건 단순히 의지의 문제가 아니다.

    요약하면 이렇다. AWS·GCP는 ‘뭐든 된다’는 게 장점인데, 그게 동시에 AI 시대엔 약점이 되고 있다.

    AI 시대 클라우드, 달라야 할 3가지

    AI 개발자한테 진짜 필요한 게 뭔지 정리하면 크게 세 가지다.

    1. 1초 미만 배포

      AI 에이전트가 코드 만드는 속도에 인프라가 맞춰야 한다. 2~3분 배포는 이제 옛날 얘기다. 실제로 1초 미만 배포를 달성한 플랫폼에서 개발 속도가 10배 이상 향상됐다는 사례가 나오고 있다. 배포 기다리는 시간이 사라지면 흐름이 끊기지 않는다.

    2. 초 단위 온디맨드 과금

      AI 워크로드는 예측이 어렵다. 몰아서 쓰고 한동안 쉬는 패턴이 많다. 실제로 쓴 만큼만 초 단위로 과금하는 구조가 필요하다. 이 방식으로 전환했을 때 비용을 65% 이상 줄인 사례도 있다. 유휴 시간 비용이 0이 된다는 게 핵심이다.

    3. 수직 통합 인프라

      네트워크, 컴퓨팅, 스토리지를 직접 통제하면 외부 의존성이 줄고 성능 최적화 폭이 넓어진다. 복잡한 설정 없이 데이터베이스, 스토리지, 네트워킹을 한 곳에서 관리하는 경험. 이게 개발자가 인프라 대신 제품에 집중하게 만드는 구조다.

    실제로 등장하고 있는 AI 네이티브 클라우드들

    샌프란시스코 기반 클라우드 스타트업 중 일부는 구글 클라우드 의존을 완전히 끊고 자체 데이터센터를 구축하는 선택을 했다. 꽤 과감한 베팅이다.

    • 배포 시간: 1초 미만. 이게 실제 사용자 경험에서 체감 차이를 만든다.
    • 비용: 기존 대형 클라우드 대비 50% 이상 저렴, 일부 신생 클라우드 대비 3~4배 싸다고 한다. 유휴 VM 과금 자체가 없다.
    • 수직 통합: 네트워크·컴퓨팅·스토리지를 직접 설계했다. 최근 대형 클라우드 장애 때도 자체 인프라는 멀쩡히 돌아갔다는 게 눈에 띈다.
    • 입소문 성장: 광고 없이 개발자 입소문만으로 사용자가 늘고 있다. 복잡한 인프라 관리 대신 제품 개발에 집중할 수 있다는 게 이유다.

    기존 클라우드가 ‘있는 기능 다 쓰세요’라면, 이쪽은 ‘AI 개발에 필요한 것만 제대로’다. 포지셔닝이 명확하다.

    플랫폼 고를 때 실제로 봐야 할 것들

    선택지가 많아졌다는 건 좋은 일이다. 다만 뭘 봐야 할지 정리해두면 의사결정이 빠르다.

    • AI 도구·CI/CD 연동:

      현재 쓰는 AI 코딩 도우미나 배포 파이프라인과 얼마나 자연스럽게 붙는지 확인해야 한다. AI 에이전트가 직접 배포를 트리거하고 인프라를 분석하는 수준인지가 포인트다.

    • 과금 방식과 예측 가능성:

      실사용량 기반 과금인지, 유휴 리소스 비용이 발생하는지 꼭 따져야 한다. 청구서 보고 놀라는 일은 한 번이면 충분하다.

    • 성능과 확장성:

      AI 모델 돌리려면 vCPU·RAM이 넉넉해야 한다. 트래픽 급증 시 얼마나 빠르게 스케일업되는지, PostgreSQL·MySQL·MongoDB 지원 범위도 체크 포인트다.

    • 보안 인증:

      기업 환경이라면 SOC 2 Type 2, HIPAA 인증 여부가 필수다. SSO, 감사 로그, BAA(Business Associate Agreement) 제공 여부도 계약 전에 확인해야 한다.

    • 관리 편의성과 지원:

      인프라 관리에 드는 시간이 줄어야 개발팀이 제품에 집중한다. UI가 직관적인지, 문제 생겼을 때 기술 지원이 빠른지. 이건 직접 써봐야 안다.

    AI 클라우드 비용 줄이는 실용 전략

    ‘어디에 올릴까’보다 ‘어떻게 효율적으로 쓸까’가 더 중요해졌다. 몇 가지 정리했다.

    • 리소스 모니터링 습관화: 어떤 인스턴스가 얼마나 유휴 상태인지 정기적으로 확인해야 한다. 스펙 과잉 인스턴스 쓰다가 비용 터지는 경우가 생각보다 많다.
    • 서버리스 아키텍처 활용: AWS Lambda, Google Cloud Functions 같은 서버리스 함수는 이벤트 발생 시에만 실행되고 나머지 시간엔 비용이 0이다. AI 추론이나 특정 백엔드 작업에 잘 맞는 구조다.
    • AI 특화 플랫폼 병행 검토: 기존 클라우드와 AI 네이티브 플랫폼을 섞는 하이브리드 전략도 현실적인 선택지다. 전부 옮기기 부담스럽다면 새 프로젝트부터 시작해보는 게 낫다.
    • 컨테이너화 + 오케스트레이션: 도커(Docker)와 쿠버네티스(Kubernetes) 조합은 리소스 효율을 높이고 배포를 자동화한다. 설정 초기 비용이 있지만 규모가 커질수록 효과가 크다.
    • 예약 인스턴스 활용: 꾸준히 쓰는 리소스는 예약 인스턴스나 저장형 플랜으로 할인받는 게 맞다. AI 워크로드의 변동성을 잘 예측해야 한다는 게 전제 조건이다.

    앞으로 클라우드 시장, 어디로 가나

    한 전문가는 앞으로 5년 동안 ‘지금까지 존재했던 소프트웨어의 1,000배에 달하는 소프트웨어가 온라인에 등장할 것’이라고 예측했다. 이 소프트웨어들은 전부 어딘가에서 실행돼야 한다. 클라우드 인프라 수요가 폭발적으로 늘 수밖에 없다는 얘기다.

    • AI 네이티브 클라우드의 부상: 초고속 배포와 유연한 과금을 무기로 한 신생 플랫폼들이 기존 거대 클라우드의 틈새를 파고들 가능성이 크다. 이미 그 조짐이 보이고 있다.
    • 수직 통합의 경쟁력: 하드웨어부터 소프트웨어 스택 전체를 직접 통제하는 플랫폼이 성능·비용·사용자 경험에서 차별화를 만들어낼 것이다.

    AWS와 GCP가 사라지진 않는다. 다만 AI 개발 특화 영역에서 점유율을 잃을 수 있다. 시장이 세분화되는 방향이다.

    출처: VentureBeat AI

    관련 기사

  • Vercel 해킹, 개발자들 데이터 유출 비상…다음은 어디?

    Vercel 해킹, 개발자들 데이터 유출 비상…다음은 어디?

    Vercel이 뚫렸다. 직원들의 이름과 이메일 주소, 활동 타임스탬프가 밖으로 새어 나갔고, 해커들은 이미 그 데이터를 온라인에서 팔겠다고 나선 상태다. The Verge 보도를 보면 Vercel 측도 피해 사실을 공식 인정했다. 조용히 묻힐 사건이 아니다.

    뭐가 얼마나 나갔나

    이번 공격의 배후로 지목된 건 샤이니헌터스(ShinyHunters)다. GTA6 개발 영상을 통째로 유출시켜 락스타 게임즈를 발칵 뒤집었던 그 그룹. 마이크로소프트, 포드도 이들한테 당한 이력이 있다.

    • 해커들이 확보했다고 주장하는 건 Vercel 직원들의 이름과 이메일 주소다.
    • 활동 타임스탬프도 포함돼 있다. 언제 누가 무엇을 했는지 흔적이 통째로 넘어간 셈이다.
    • Vercel은 현재 피해 범위를 파악하면서 추가 차단에 들어간 상태다.

    직원 이메일이 유출되면 뭐가 문제냐고? 피싱 공격의 시작점이 된다. 이름과 이메일 조합만 있어도 꽤 정교한 스피어 피싱이 가능하고, 내부 시스템 접근 시도로 이어지는 게 샤이니헌터스의 전형적인 수순이다. 데이터 자체보다 그걸 레버리지 삼아 더 깊이 파고드는 방식. 솔직히 이 부분이 더 걱정된다.

    왜 개발 플랫폼이 더 위험한가

    샤이니헌터스는 단순히 데이터를 빼가는 데서 멈추지 않는다. 기업의 약점을 공개하고, 신뢰도를 갉아먹는 방향으로 움직인다. 랜섬보다는 평판 타격 쪽에 더 무게를 두는 그룹이다.

    • Vercel은 단순한 SaaS가 아니다. 수많은 개발자가 프로젝트를 올려두고 매일 코드를 밀어 넣는 인프라다. 여기서 보안이 흔들리면 개별 프로젝트의 안정성에도 직결된다.
    • API 키, 환경 변수, 소스 코드—Vercel 하나에 붙어 있는 민감한 정보가 한두 개가 아니다. 이번에 유출된 건 직원 정보지만, 다음 단계로 내부 시스템 접근을 노릴 경우 파장이 어디까지 갈지 예측하기 어렵다.
    • 클라우드 플랫폼의 편의성이 커질수록 거기에 쌓이는 데이터도 늘어난다. 배포 한 번에 GitHub 연동, 환경 변수 관리, 도메인 설정까지 다 해주는 게 Vercel의 강점인데, 그 편의성의 반대편에는 한 곳이 뚫리면 전부 위험해지는 구조가 있다. 이게 딜레마다.

    개발 생태계를 노린 공격이 일반적인 기업 데이터 유출과 다른 이유가 여기에 있다. 피해가 한 기업에서 끝나지 않는다. 그 플랫폼 위에서 돌아가는 수천 개의 서비스와 프로젝트가 잠재적 위험에 노출된다.

    지금 당장 해야 할 것들

    Vercel 쓰고 있다면 체크해야 할 것들이 있다. 나중에 해도 되는 게 아니다.

    • 2단계 인증(2FA) 활성화: 아직 안 켜놨으면 오늘 안으로. Vercel 계정 설정에서 30초면 된다. 이게 기본 중의 기본이다.
    • API 키·접근 토큰 재발급: 유출 여부와 상관없이 일단 교체하는 쪽이 낫다. 외부 서비스와 연결된 토큰들을 중심으로.
    • 연동 서비스 권한 점검: GitHub, GitLab 등 Vercel에 붙어 있는 서드파티 앱의 접근 권한을 다시 확인하고, 쓰지 않는 연동은 끊어라.
    • 비밀번호 교체: 다른 서비스와 같은 비밀번호를 쓰고 있다면 즉시 바꿔야 한다. 크리덴셜 스터핑 공격에 그대로 노출되는 구조다.

    제로 트러스트(Zero Trust)—어떤 플랫폼도 무조건 믿지 않는다는 원칙—를 개발 프로세스에 녹여야 할 시점이다. 귀찮아 보이는 이 절차들이 실제 공격을 막는다. 해봤으면 안다.

    국내 개발자들한테도 남 얘기가 아니다

    국내에서 Vercel 쓰는 팀이 적지 않다. Next.js 기반 프로젝트라면 배포할 때 Vercel이 가장 먼저 손이 가는 선택지다. 빠르게 프로토타입을 올려야 하는 스타트업이나 개인 개발자들 사이에서 활용도가 높다.

    • 이번 사건은 클라우드 플랫폼 선택 기준을 다시 생각하게 만든다. 기능이나 속도만 볼 게 아니라, 해당 업체가 보안 사고를 어떻게 처리해왔는지까지 따져봐야 한다. 사고 자체보다 대응 방식이 신뢰도를 결정한다.
    • 외부 플랫폼 의존도가 높은 팀일수록 그 플랫폼의 보안 사고가 자사 서비스에 직접 연결된다. 보안 감사와 개발자 보안 교육을 한 번이라도 제대로 해둔 팀과 그렇지 않은 팀의 차이가 이런 순간에 갈린다.
    • 결국 기술 선택의 문제만이 아니다. 개발 문화 전반에서 보안을 어떻게 다루느냐의 문제다. 편한 걸 쓰되, 그 편의성이 어떤 위험과 함께 오는지 계속 인식하고 있어야 한다. 이번 사건이 그 인식을 끌어올리는 계기가 됐으면 한다.

    출처: The Verge

    관련 기사

  • 한국 개발자를 위한 2026 클라우드 선택 가이드: AWS vs Azure vs GCP vs 네이버클라우드 실전 비교

    한국 개발자를 위한 2026 클라우드 선택 가이드: AWS vs Azure vs GCP vs 네이버클라우드 실전 비교

    스타트업 인프라를 맡던 첫 해, 클라우드 관련 의사결정이 하루에도 몇 번씩 있었다. “이거 어디에 올리면 되냐”고 물어볼 때마다 돌아오는 답은 항상 비슷했다. “그냥 AWS 쓰세요.” 근데 정말 그게 맞는 선택인지는 아무도 확인해주지 않았다. 한국 리전 성능은 어떤지, 원화 결제가 되는지, 공공기관 입찰에 나갈 수 있는지. 이런 현실적인 질문에 답해주는 자료가 거의 없었다. 대부분의 블로그 글은 영어권 시장 기준이거나, 단순히 스펙 표만 늘어놓은 수준이었으니까.

    그래서 직접 정리했다. 3년간 AWS, Azure, Google Cloud Platform, 네이버클라우드 네 곳을 실제 프로덕션에서 운영해봤고, 그 과정에서 얻은 한국 현지 관점의 비교를 담았다. 스타트업 대표, 개인 개발자, 중견기업 인프라 담당자 모두에게 도움이 될 실전 가이드다.

    숫자로 보는 2026년 한국 클라우드 현황

    2026년 4월 기준으로 각 클라우드의 한국 시장 점유율과 리전 현황을 먼저 정리했다. 리전 위치와 가용 영역(AZ) 수가 장애 복구 전략에 직결되기 때문이다.

    항목 AWS Azure GCP 네이버클라우드
    한국 리전 서울 (2016) 한국 중부 (2017) 서울 (2020) 한국 (2018)
    가용 영역 수 4 AZ 3 AZ 3 AZ 2 Zone
    한국 시장 점유율 약 62% 약 15% 약 12% 약 8%
    원화 결제 가능 (VAT 별도) 가능 (VAT 포함) 가능 (VAT 포함) 가능 (내국인 우선)
    공공기관 CSAP 일부 획득 일부 획득 진행 중 전체 인증
    한국어 기술 지원 유료 (Business+) 유료 (Standard+) 유료 (Standard+) 무료 포함

    AWS의 AZ 수가 4개라는 건 단순한 숫자 이상이다. Multi-AZ 구조를 두 세트 만들 수 있어서 블랙스완급 장애 상황에서 실제로 버텨낸다. 네이버클라우드는 Zone이 2개뿐이라 이 부분은 약점이 맞다.

    공공기관 입찰이 있다면 이야기가 달라진다. CSAP(클라우드 보안 인증) 전체 등급을 모두 획득한 건 네이버클라우드가 유일하다. 공공 계약 비중이 높은 SI 업체라면 솔직히 선택지가 거의 없다고 봐야 한다.

    실제로 얼마나 차이 나나: 같은 스펙 월 비용 직접 비교

    가장 자주 받는 질문이다. “그래서 어디가 제일 싸냐?” 2026년 4월 기준으로 실제 서비스에 자주 쓰이는 스펙을 기준으로 월 비용을 뽑아봤다.

    비교 기준: 웹 서버 1대(2 vCPU, 4GB RAM), 데이터베이스 1대(2 vCPU, 8GB RAM, 100GB SSD), 월 500GB 데이터 전송, 스토리지 200GB. 서울 리전, 리눅스, 정가 기준(할인 미적용).

    항목 AWS Azure GCP 네이버클라우드
    웹 서버 (월) 약 82,000원 약 78,000원 약 74,000원 약 65,000원
    DB 서버 (월) 약 195,000원 약 188,000원 약 178,000원 약 148,000원
    데이터 전송 500GB 약 55,000원 약 50,000원 약 53,000원 약 35,000원
    스토리지 200GB 약 6,000원 약 5,500원 약 5,200원 약 4,800원
    월 총액 약 338,000원 약 321,500원 약 310,200원 약 252,800원

    네이버클라우드가 약 25% 저렴하다. egress 비용 차이가 결정적이다. 글로벌 3사의 데이터 전송 비용은 GB당 100~110원 수준인데, 네이버클라우드는 70원 정도다. 트래픽 많은 서비스라면 연 단위로 수백만 원 차이가 난다.

    다만 이 숫자만 보고 결정하면 안 된다. AWS는 1년 또는 3년 예약 인스턴스로 최대 60%까지 할인되고, 스타트업 크레딧 프로그램도 있다. AWS Activate 크레딧으로 1년간 거의 무료에 가까운 비용으로 썼던 경험이 있다. 초기 비용이 확 줄어드는 경우가 많다는 걸 감안해야 한다.

    AWS: 표준이라는 말의 무게, 그리고 진짜 단점

    AWS의 강점은 서비스 다양성이다. 2026년 현재 200개가 넘는 서비스. EKS(Kubernetes), Lambda(서버리스), SageMaker(ML) 같은 분야에서 생태계가 가장 성숙해 있다. 새로운 기술이 나오면 AWS가 가장 먼저 대응한다.

    프로덕션 워크로드 10개 정도를 AWS에서 운영해봤는데 장애가 거의 없었다. 2023년 서울 리전 대규모 장애 사건이 있긴 했지만, 다른 클라우드들도 비슷한 규모의 장애는 있었다. 전반적인 안정성은 1위가 맞다.

    단점은 가격 정책의 복잡함이다. EC2 요금, EBS 요금, 데이터 전송 요금, API 호출 요금이 다 따로 계산된다. 월말 청구서를 받고 “어? 이건 왜 과금됐지?” 하는 순간이 반드시 온다. 실제로 S3 PUT 요청 수만 1만 건 넘겨서 예상 못한 요금을 낸 적이 있다. Cost Explorer를 매일 확인하는 습관은 사실상 필수다.

    Azure: .NET 스택이거나 엔터프라이즈라면 사실상 기본값

    Azure의 진짜 강점은 Windows 서버와 Active Directory 통합이다. 기존 Windows 환경이 있는 중견·대기업이라면 Azure로 가는 게 거의 자연스러운 수순이다. Office 365와의 SSO 통합도 설정이 몇 번의 클릭으로 끝난다.

    한국에서 Azure를 쓰는 패턴은 두 가지로 뚜렷하다. 첫째, SAP이나 Oracle 같은 엔터프라이즈 소프트웨어 마이그레이션 프로젝트. 둘째, Microsoft 파트너십이 있는 대기업의 내부 시스템. 스타트업이 Azure로 시작하는 경우는 거의 본 적이 없다.

    소규모 팀 관점에서 Azure의 약점은 “AWS보다 복잡한데 장점이 명확하지 않다”는 것이다. 포털 UI는 개선됐지만 여전히 AWS 콘솔보다 학습 곡선이 가파르다. 이 부분은 솔직히 좀 아쉽다.

    GCP: BigQuery 하나만으로도 이유가 된다

    GCP는 데이터 분석에서 확실한 우위가 있다. BigQuery는 한 번 써보면 AWS Redshift나 Azure Synapse로 돌아가기 어렵다. 수백 TB 데이터에 대한 쿼리가 몇 초 만에 끝나는 경험은 진짜 충격적이다.

    머신러닝도 마찬가지다. Vertex AI, TPU, Gemini API 연동까지 한 생태계에서 해결된다. ML 프로젝트를 시작할 때는 거의 항상 GCP부터 고려하게 되는 이유가 여기 있다.

    일반 웹 서비스 호스팅 관점에서는 AWS와 비슷한 가격에 비슷한 성능이다. 큰 차이가 없다. GCP를 선택하는 이유는 보통 BigQuery, TPU, Spanner 같은 특정 서비스 때문이지, 웹 호스팅 자체의 강점 때문은 아니다. 한국에서 GCP 프로덕션 사용자 커뮤니티가 아직 상대적으로 작다는 점도 고려해야 한다. 문제가 생겼을 때 한국어 자료 찾기가 AWS보다 확실히 어렵다.

    네이버클라우드: “그냥 AWS 카피” 아니다

    처음엔 나도 네이버클라우드를 그냥 한국판 AWS 카피 정도로 봤다. 2년 전부터 실제로 몇 개 프로젝트를 올려보면서 생각이 바뀌었다. 장점이 명확히 있다.

    가격이 싸다. 위 비교표에서 봤듯이 전체적으로 20~25% 저렴하다. egress 비용이 낮다는 건 한국 고객 대상 서비스를 운영할 때 실제로 큰 차이를 만든다.

    기술 지원이 한국어로 무료다. AWS에서 Business 플랜 한국어 지원을 받으려면 월 최소 100달러(약 13만 원) 이상 추가로 내야 하는데, 네이버클라우드는 기본 플랜에 한국어 지원이 포함된다. 전화 문의까지 되고, 평균 응답 시간도 AWS보다 빠른 편이었다.

    공공·금융·의료 CSAP 인증도 완벽하다. 이 세 분야 고객을 상대한다면 네이버클라우드가 사실상 유일한 옵션인 경우가 많다.

    단점도 분명하다. 글로벌 확장이 필요한 서비스에는 부적합하다. 해외 리전이 몇 개 있긴 하지만 AWS와 비교가 안 된다. 서버리스, 컨테이너 오케스트레이션 같은 고급 서비스는 아직 성숙도가 부족하다. 국내 중심 서비스에는 좋지만, 글로벌 서비스를 목표로 한다면 신중하게 따져봐야 한다.

    상황별 최적 클라우드: 이 기준으로 고른다

    3년간 4개 클라우드를 다 돌려본 후 내린 결론이다. 책에서 보는 이론이 아니라 실제로 돈 나가는 결정을 내린 경험에서 나온 판단이다.

    1. 스타트업 초기 (매출 0~5억) — AWS다. AWS Activate 크레딧 10만 달러를 받을 수 있고, 서비스 다양성 덕분에 피벗하기도 쉽다. 가격이 약간 비싸도 생태계가 주는 속도감이 훨씬 크다.

    2. 한국 내수 B2C 서비스 (매출 5억~50억) — 네이버클라우드를 진지하게 고려해볼 시점이다. egress 비용 차이만으로도 연 수백만 원 절약이 가능하고, 한국어 지원이 무료라 운영 부담도 적다. 글로벌 확장 계획이 없다면 더욱 매력적이다.

    3. 데이터 분석 / 머신러닝 중심 — GCP다. BigQuery와 Vertex AI의 조합은 AWS나 Azure가 따라오지 못한다. 분석 워크로드만 GCP로 분리하는 하이브리드 구조도 흔히 쓴다.

    4. 대기업 내부 시스템 / .NET 기반 — Azure다. 기존 Windows 자산을 재활용할 수 있고, Office 365 연동이 강력하다. 다른 선택지가 오히려 비효율적인 경우가 많다.

    5. 공공기관 입찰 / 금융 / 의료 — 네이버클라우드가 사실상 유일하다. CSAP 인증이 앞서 있고, 계약 조건 면에서도 한국 기관과의 궁합이 좋다.

    6. 개인 개발자 / 사이드 프로젝트 — GCP 프리티어를 추천한다. e2-micro 인스턴스 1대가 영구 무료고, 300달러 크레딧도 있어서 첫 해는 사실상 무료로 쓸 수 있다. AWS 프리티어는 1년 한정이라 부담스럽다.

    자주 묻는 질문

    Q1. 클라우드 마이그레이션에 평균 얼마나 걸리나요?
    규모에 따라 크게 다르다. 작은 웹 서비스는 1~2주면 충분하고, 중견기업 수준의 ERP 시스템은 보통 6개월~1년 걸린다. 50대 서버 규모 마이그레이션을 직접 맡아봤는데, 계획 포함 8개월이 걸렸다. 데이터베이스 이전이 항상 가장 어렵고 오래 걸린다.

    Q2. 클라우드 비용이 예상보다 많이 나오는 이유는?
    가장 흔한 원인 세 가지다. 첫째, 데이터 전송 비용을 과소평가한 경우. 둘째, 개발·테스트 환경을 끄지 않고 방치한 경우. 셋째, 자동 스케일링 설정 오류로 과도하게 확장된 경우. 매주 Cost Explorer를 확인하는 습관이 필요하다.

    Q3. 한국 리전이 없는 클라우드를 써도 되나요?
    한국 사용자 대상 서비스라면 비추천이다. 도쿄 리전을 쓰면 한국에서 접속 지연이 30~50ms 정도 추가된다. 게임이나 실시간 서비스는 치명적이고, 일반 웹 서비스도 사용자가 체감할 수준이다. 반드시 한국 리전이 있는 클라우드를 선택해야 한다.

    Q4. 네이버클라우드의 가장 큰 단점은 무엇인가요?
    글로벌 확장이 어렵다는 점이다. 리전이 몇 개 있긴 하지만 AWS나 Azure 수준의 확장성은 없다. 서버리스 컴퓨팅, 관리형 Kubernetes 등 고급 서비스의 성숙도도 아직 글로벌 3사만큼 높지 않다. 국내 중심 서비스에는 좋지만, 글로벌 서비스를 꿈꾼다면 신중해야 한다.

    Q5. 멀티 클라우드 전략은 현실적인가요?
    대기업에는 유효하다. 중소기업이나 스타트업에게는 일반적으로 비효율적이다. 관리 복잡도가 기하급수적으로 올라가고, 인력이 두 배로 필요해진다. 스타트업에 멀티 클라우드를 권하지 않는다. 한 곳에 집중해서 전문성을 키우는 게 훨씬 낫다. 특정 워크로드만 다른 클라우드로 분리하는 정도는 괜찮다.

    Q6. 쿠버네티스는 어느 클라우드가 가장 편한가요?
    GKE(Google)가 가장 편하다. Kubernetes가 원래 Google이 개발한 기술이라 그런지 매니지드 서비스로서의 완성도가 높다. EKS(AWS)도 좋지만 네트워킹 설정이 복잡하고, AKS(Azure)는 안정성이 두 곳보다 약간 떨어진다. 네이버클라우드의 NKS는 기본 기능은 되지만 아직 부족한 부분이 있다.

    결국 “운영 문화”가 클라우드를 결정한다

    3년간 네 개 클라우드를 다 써본 후 내린 결론이 하나 있다. “가격과 스펙만 보고 선택하면 안 된다.” 우리 팀이 어떤 기술 스택에 익숙한지, 한국어 지원이 얼마나 필요한지, 공공·금융 관련 규제가 있는지, 글로벌 확장 계획이 있는지. 이런 것들이 결정적인 요소다.

    지금 새로 사업을 시작한다면 이렇게 하겠다. 기술 스택이 익숙한 팀이라면 AWS로 시작. 한국 내수 B2C라면 네이버클라우드. 데이터 중심 사업이라면 GCP. 비용 때문에 네이버클라우드로 갈아타는 건 매출 30억을 넘긴 이후에 고민해도 늦지 않는다. 초기엔 속도가 절대값이다.

    한 가지 확실한 건, “남들이 쓰니까 AWS”라는 이유로 선택하지는 말라는 것이다. 2026년의 한국 클라우드 시장은 각자 뚜렷한 강점이 있는 경쟁 구도가 됐다. 상황에 맞는 선택이 가장 중요하다.

  • 개발자 AI 코딩 생산성 5배 높이는 워크플로우 가이드

    개발자 AI 코딩 생산성 5배 높이는 워크플로우 가이드

    Claude Code를 직접 만든 사람은 어떻게 쓸까. Anthropic의 Claude Code 개발 책임자 Boris Cherny가 자신의 AI 코딩 워크플로우를 공개했고, 개발자 커뮤니티에서 상당한 반향을 일으켰다. VentureBeat AI 보도에 의하면, 이 방식을 따르면 개발자 한 명이 소규모 엔지니어링 팀 수준의 아웃풋을 낼 수 있다고 한다. 처음엔 과장처럼 들린다. 그런데 실제 방법을 뜯어보면 납득이 간다. 소프트웨어 개발 분야에서 AI는 이미 단순한 코드 자동 완성 도구를 넘어섰다. Cherny의 워크플로우는 그 다음 단계가 어떤 모습인지를 구체적으로 보여준다.

    AI를 비서 1명처럼 쓰면 안 된다

    대부분의 개발자가 AI를 활용하는 방식은 단순하다. 질문 하나를 던지고, 답을 받고, 또 질문한다. 근본적으로 1:1 대화 구조에서 벗어나지 못한다. Cherny는 완전히 다른 방식을 택한다.

    그는 터미널에서 Claude 인스턴스를 5개 동시에 실행한다. 각 탭에 1번부터 5번까지 번호를 붙이고, iTerm2의 시스템 알림 기능으로 각 인스턴스가 입력을 기다릴 때마다 알림을 받는다. 이건 그가 X 게시글에서 직접 밝힌 내용이다.

    병렬 처리의 효과는 명확하다. 1번 AI가 테스트 스위트를 돌리는 동안, 2번은 레거시 모듈을 리팩토링하고, 3번은 문서 초안을 쓴다. 개발자는 코드를 직접 타이핑하는 대신, 각 AI 에이전트에 지시를 내리고 결과를 조율한다. 실시간 전략 게임에서 유닛을 운용하는 것과 비슷한 느낌이다. 사령관 역할이다. 로컬 터미널 외에도 claude.ai 웹에서 5~10개의 Claude 세션을 동시에 운영하며, ‘텔레포트’ 명령으로 로컬과 웹을 유연하게 오간다. 이렇게 환경을 세팅하면 개발자의 에너지 배분이 달라진다. 문법을 타이핑하는 데 쓰던 에너지가 고수준의 문제 해결과 아키텍처 설계로 이동한다. 이게 핵심이다.

    왜 느린 모델 Opus 4.5를 고집하나

    AI 개발에서 빠른 모델이 좋은 모델이라는 건 착각이다. Cherny는 Anthropic의 가장 무겁고 느린 모델인 Opus 4.5를 모든 작업에 쓴다. “내가 사용해 본 코딩 모델 중 최고”라는 게 그의 말이다.

    이 선택의 배경에는 핵심적인 통찰이 있다. 현대 AI 개발의 진짜 병목은 AI가 코드를 생성하는 속도가 아니다. 개발자가 AI의 실수를 수정하는 데 드는 시간이다. 작고 빠른 모델은 초기 응답은 빠르지만, 오류가 많아 수정에 더 많은 사람의 시간이 들어간다. 반면 Opus 4.5 같은 고성능 모델은 초기 컴퓨팅 비용이 높더라도, 오류가 적고 도구 사용 능력이 뛰어나 전체적인 수정 시간을 대폭 줄인다. 컴퓨팅 비용을 더 내는 대신 수정 비용을 아끼는 구조다. 결과적으로 더 빠른 개발이 가능하다. 기업 기술 리더들에게 이 계산은 상당히 중요한 시사점을 준다.

    AI 건망증을 고치는 CLAUDE.md 파일

    AI의 고질적인 문제다. 어제 가르쳐 준 것을 오늘 또 모른다. 세션이 바뀌면 리셋이다. 기업의 코딩 스타일이나 아키텍처 결정 사항을 AI가 지속적으로 기억하게 하려면 어떻게 해야 할까.

    Cherny 팀은 Git 저장소에 CLAUDE.md라는 파일 하나를 유지하는 방식으로 이 문제를 해결한다. 이 파일이 AI에게 전달되는 지속적인 지침서 역할을 한다. “Claude가 잘못된 작업을 할 때마다, 다음번에는 그러지 않도록 CLAUDE.md에 추가한다”고 그는 설명했다.

    이 방식은 코드베이스를 스스로 교정하는 유기체처럼 만든다. PR을 리뷰하다가 AI가 만든 오류를 발견하면, 코드만 고치지 않는다. AI의 지침을 업데이트하도록 태그를 지정한다. 제품 리더 아카쉬 굽타(Aakash Gupta)의 표현이 딱 맞다. “모든 실수가 규칙이 된다.” 팀이 함께 AI를 쓰는 시간이 쌓일수록 AI 에이전트는 점점 그 팀의 방식에 맞게 다듬어진다.

    반복 작업을 없애는 슬래시 명령어와 서브 에이전트

    Cherny의 워크플로우에서 반복 작업은 슬래시 명령어로 처리한다. 프로젝트 저장소에 커스텀 슬래시 명령어를 추가해 복잡한 절차를 키 입력 한 번으로 끝낸다. 예를 들어 /commit-push-pr은 하루에 수십 번 호출하는 명령어다.

    이 명령어 하나가 처리하는 일이 있다. git 명령어 입력, 커밋 메시지 작성, 풀 리퀘스트 열기 — 이 세 단계를 AI 에이전트가 자율적으로 처리한다. 수동으로 반복하던 버전 관리 작업 전체가 없어지는 셈이다. 이건 개발자가 지루한 절차에 쓰던 시간을 실제 문제 해결로 돌리는 핵심 전략이다.

    서브 에이전트도 빼놓을 수 없다. 메인 작업이 끝나면 아키텍처를 정리하는 ‘코드 간소화(code-simplifier)’ 에이전트가 동작하고, 최종 배포 전에는 ‘앱 검증(verify-app)’ 에이전트가 엔드 투 엔드 테스트를 돌린다. 각 개발 단계를 전담하는 AI 페르소나들이다. 단순한 자동화가 아니라 개발 파이프라인 자체를 AI 에이전트 체인으로 재설계하는 것에 가깝다.

    AI가 직접 검증하는 루프 — 코드 품질이 달라진다

    AI가 코드를 만들고 끝. 이게 대부분의 방식이다. Cherny는 다르다. 검증 루프(verification loop)를 추가한다. 이 루프가 AI 생성 코드의 품질을 2~3배 끌어올린다고 그는 주장한다.

    구체적으로 이렇다. “Claude는 Claude Chrome 확장 프로그램을 사용해 claude.ai/code에 적용하는 모든 변경 사항을 테스트한다.” AI가 브라우저를 직접 열어 UI를 확인하고, 코드가 작동하고 사용자 경험이 만족스러울 때까지 반복적으로 수정한다. 텍스트 생성기가 아니라 테스터로 동작하는 것이다.

    이것이 뜻하는 바는 분명하다. AI에게 자신의 작업을 검증할 수단을 줘야 한다. 브라우저 자동화, 셸 명령어 실행, 테스트 스위트 실행 — 이 수단들이 AI를 단순한 코드 작성기에서 결과물 책임자로 바꾼다. 코드를 쓰는 것과 그 코드가 작동한다는 걸 스스로 증명하는 건 전혀 다른 일이다. 그 차이가 최종 결과물의 신뢰성을 바꾼다.

    결국 개발자의 역할이 바뀐다

    Boris Cherny의 워크플로우가 드러내는 건 도구의 변화가 아니다. 역할의 변화다. AI 코딩이 IDE 자동 완성 기능에 머물렀던 건 이미 지난 이야기가 됐다. 지금 AI는 개발 노동 그 자체를 위한 운영 체제로 기능한다.

    이 변화는 개발자의 역할을 다시 정의한다. 직접 코딩하는 사람이 아닌, AI 에이전트 부대를 지휘하고 복잡한 시스템을 설계하며 AI의 학습을 돕는 전략가이자 아키텍트. AI를 보조 도구가 아닌 협업하는 워크포스로 인식하고 이 패러다임에 적응하는 개발자가 앞으로의 경쟁에서 실질적인 우위를 점한다. 예측이 아니다. 이미 진행 중인 현실이다.

    출처: VentureBeat AI

    관련 기사