☃ 2026.03 아티클 아카이브

요즘 AI 코딩 도구를 쓰다 보면, 프롬프트 몇 번만으로 기능이 빠르게 만들어진다. 이른바 바이브 코딩(vibe coding) 이다. 일단 돌아가면 됐고, 빠르게 만들고, 빠르게 확인한다. 개인 프로젝트나 실험용 프로토타입에서는 이 방식이 꽤 잘 먹힌다.

프로그래밍 언어를 만든 사람을 떠올리면 보통 문법, 타입 시스템, 성능 같은 키워드부터 생각하게 된다. 그런데 Anders Hejlsberg의 이야기를 따라가다 보면 더 근본적인 축이 보인다.

AI 에이전트는 이제 꽤 많은 일을 해낸다. Claude든 GPT든, 집중된 단일 작업을 주면 제법 잘 수행한다. 문제는 실제 일이 단일 작업이 아니라는 점이다. 현실의 업무는 보통 이렇게 생겼다.

최근 Y Combinator 인터뷰에서 OpenClaw 제작자 Peter Steinberger가 던진 말이 강하게 남았다. “앱의 80%는 사라질 것이다.” 과장처럼 들리지만, 인터뷰 전체를 보면 단순한 자극적 전망이 아니다.그가 말하는 핵심은 명확하다.

AI가 단순 추천을 넘어서 상품 탐색 → 비교 → 결제 → 사후 처리까지 대신 수행하는 시대가 오고 있다. 이 흐름을 흔히 에이전틱 커머스(Agentic Commerce) 라고 부른다. 그리고 지금 이 시장의 핵심 인프라로 자주 언급되는 두 축이 있다.

최근 AI 코딩 에이전트 생태계에서 브라우저 자동화를 다루는 방식이 조금씩 바뀌고 있다. 특히 Playwright 쪽에서는 기존의 테스트 실행 중심 CLI와는 결이 다른, AI 에이전트 친화적인 playwright-cli 흐름이 눈에 띈다.

Playwright를 감싼 또 하나의 도구가 아니라, AI 친화적인 브라우저 자동화 인터페이스. 최근 AI 코딩 에이전트가 브라우저를 다루는 방식은 빠르게 바뀌고 있다.

최근 AI 기반 UI 생성 흐름에서 자주 부딪히는 문제가 있다. “자연어로 UI를 만들게 하고 싶다. 그런데 결과는 예측 가능해야 한다.” 이 지점에서 vercel-labs/json-render는 꽤 명확한 해법을 제시한다. 한 줄로 요약하면 다음이다.

AI 코딩 에이전트가 점점 보편화되면서, 이제 중요한 건 단순히 “에이전트를 쓰는가”가 아니다. 더 중요한 건 에이전트에게 어떤 작업 규칙과 실행 문맥을 구조적으로 주입하느냐다.

최근 AI 에이전트 관련 프로젝트들을 보다 보면, 단순한 챗봇을 넘어서 스스로 계획하고, 도구를 호출하고, 결과를 검증하는 구조가 빠르게 늘어나고 있다. 그중 virattt/dexter는 이 흐름을 금융 리서치 도메인에 맞춰 구체화한 프로젝트다.

AI 코딩 에이전트가 강해졌다고 해도, 프론트엔드 버그 수정은 아직 귀찮다. 이유는 단순하다. 문제 위치를 정확히 전달하기 어렵기 때문이다. 예를 들어 실제 협업이나 개인 개발 중에도 이런 식의 요청이 자주 나온다.

LLM, Transformer, GPT 같은 단어는 이제 너무 흔하다. 그런데 실제로 Transformer가 내부에서 어떻게 동작하는지를 직관적으로 이해하는 것은 여전히 어렵다.

Git은 강력하지만 강력한 만큼 불편한 순간도 많다. 브랜치를 옮기려는데 stash를 해야 할지 고민해야 하고, interactive rebase를 하려면 에디터에서 TODO 파일을 수정해야 하고, 파일 일부만 스테이징하려면 patch 단위로 씨름해야 한다.

AI를 도입하는 조직이 늘고 있다. 문제는 이제 AI 보안을 “모델 성능”이나 “프롬프트 품질” 정도로 볼 수 없다는 점이다.

AI를 이야기할 때 보통은 생산성, 자동화, 혁신을 먼저 떠올린다. 그런데 실제 현장에서는 반대 질문도 반드시 같이 따라와야 한다. “AI가 잘못 작동하면 무슨 일이 벌어질까?”, “누군가 AI를 악용하거나, AI 자체가 공격받으면 어떤 피해가 생길까?”

네이버가 공개한 NAVER Security Whitepaper 2025의 핵심 메시지는 명확하다. AI는 개발 생산성을 크게 끌어올렸지만, 그만큼 보안 위협도 더 빠르고 더 정교하게 진화했다.