대부분의 바이브 코딩 (vibe coding) 회고는 웹 앱을 만드는 사람들에게서 나옵니다. 그들의 코드가 틀리면, 페이지 렌더링이 실패합니다.

저는 소프트웨어가 물리적으로 움직이는 하드웨어와 통신하는 IoT 시스템을 다룹니다. 그중 일부는 제 책상에서 접근할 수 없는 네트워크에 있습니다. 제 코드가 틀리면, 누군가는 현장으로 직접 운전해서 가야 합니다.

이것이 2026년 7월 현재 제가 생각하는 바입니다. 이에 대한 제 관점은 대략 매달 바뀌어 왔으므로, 그에 맞춰 참고하시기 바랍니다.

학습의 순서가 뒤집혔다

과거의 방식: 언어를 배우고, 그다음 그것으로 구축한다.

지난 1년 동안 저는 그 반대로 해왔습니다. 무엇을 만들고 싶은지 선택합니다. 그 언어의 성질을 알 수 있을 정도로만 훑어봅니다. 바로 작동하는 시스템으로 직행합니다. 그런 다음 리팩터링 (refactoring)을 하면서 언어를 제대로 배웁니다.

이해는 첫 번째 코드를 쓰기 전이 아니라, 리팩터링 과정 중에 찾아옵니다. 저는 이런 방식으로 한 번도 써본 적 없는 언어들을 익혔고, 튜토리얼을 따라 했을 때보다 그 언어들을 더 잘 알게 되었다고 생각합니다. 모든 개념이 제가 이미 가지고 있던 문제와 결합되어 다가왔기 때문입니다.

첫 번째 한계는 환각 (hallucination)이 아니라 반복이었습니다. 매 세션마다 동일한 구조를 다시 도출해야 했고, 아무것도 축적되지 않았습니다. 기술이 하나의 기능으로서 존재하기 훨씬 전부터, 저는 저만의 투박한 버전들을 만들었습니다 — 재사용 가능한 명령 블록, 의도적인 토큰 예산 책정 (token budgeting) 등 말이죠. 그 문제는 이후 대체로 사라졌습니다.

AI는 범위를 좁히기 전까지 중간 단계의 답변만 제공한다

이것이 제가 여러분이 가장 얻어갔으면 하는 핵심입니다.

얼마 전, 저는 소프트웨어가 아날로그 전화선과 통신하도록 만들어야 했습니다. 저는 문제를 주의 깊게 설명했습니다. 오랫동안 저는 합리적이지만 쓸모없는 답변들을 받았습니다 — SIP 라이브러리, 소프트폰 스택, 오디오 라우팅 같은 것들이었죠. 제 문제가 아닌 문제에 대해서는 모두 정답이었습니다.

그러고 나서 저는 질문을 멈추고 하드웨어 자체에 대해 읽기 시작했습니다. 그곳에서 저는 존재조차 몰랐던 두 가지 용어를 발견했습니다: 바로 아날로그 전화 인터페이스의 양면인 FXO와 FXS입니다. 제 문제 전체가 그 구분 속에 있었는데, 저는 그 핵심을 건드리지 못하는 단어들로 문제를 설명하고 있었던 것입니다.

저는 그 두 용어를 던져 넣었습니다. 답변은 즉시 바뀌었습니다.

모델은 변하지 않았습니다. 마침내 제 문제를 가리키는 단어를 찾아냈고, 그 단어를 얻기 위해서는 먼저 무언가를 배우러 가야 한다는 사실을 깨달았습니다.

AI는 제가 모르는 것을 가르쳐주지 않습니다. AI는 제가 절반만 알고 있는 것을 완성해 줄 뿐입니다. 그 '절반만 아는 상태'는 여전히 저의 몫입니다.

그에 따른 결론은 다음과 같습니다. 도메인이 표준화되어 있을수록, 중간 단계의 답변이 곧 정답이 될 확률이 높습니다. 웹 프로토타이핑 (Web prototyping)의 경우, 이제 AI를 사용하는 한 명이 전통적인 방식으로 일하는 소규모 팀을 압도하며, 그 격차는 매우 큽니다. 반면 임베디드 (Embedded) 분야에서는 매번 제가 직접 범위를 좁혀나가야 합니다.

제품이 된 재앙

어느 시점에 저는 여분의 Raspberry Pi 쉘 (shell)을 모델에게 넘겨주고 실행하게 했습니다. coreutils를 건드리기 전까지는 아주 아름답게 작동했지만, 결국 기계는 망가졌습니다.

버려도 되는 보드를 잃은 것은 비용이 들지 않았습니다. 진짜 비용이 든 것은 하나의 가정이었습니다. 모델이 수행한 대부분의 작업은 합리적이었습니다. 실패의 원인은 그럴듯해 보이는 명령과 되돌릴 수 없는 명령 사이에 아무것도 없었다는 점이었습니다. homebutler의 실행 안전 계층 (execution-safety layer)은 바로 그 지점에서 탄생했습니다. 에이전트 (agent)가 무엇이든 할 수 있는 쉘 (shell) 대신, 호출할 수 있는 제한된 도구 세트를 제공하는 방식입니다.

사람들은 제 규칙이 하나의 카테고리, 예를 들어 "AI가 프로토콜 파서 (protocol parser)를 건드리게 하지 마라"와 같은 형태일 것이라고 예상합니다. 하지만 저에게 그런 규칙은 없습니다. 저의 기준은 폭발 반경 (blast radius)입니다. 로그 형식을 바꾸는 20줄의 코드와 장치 컨트롤러 (device controller)에 접근하는 20줄의 코드는, 비록 디프 (diff) 상으로는 동일해 보일지라도 결코 같은 대상이 아닙니다. 이를 판단하기 위해서는 시스템을 이해하고 있어야 합니다.

병목 현상은 나에게로 이동했다

초기에는 생성된 모든 것을 완전히 이해할 때까지 진행하기를 거부했습니다. 그러다 명백한 사실을 깨달았습니다. 생성은 빨랐지만, 저의 읽기 속도는 그렇지 않았고, 그 격차는 점점 벌어지고 있었습니다.

그래서 저는 코드를 훑으며 호출 경로 (call paths), 복잡도 (complexity), 구조 (structure)를 자연어로 보고해 주는 커스텀 스킬 (custom skill)을 만들었습니다. 이제 저는 모든 것을 읽는 대신 그 보고서를 읽습니다.

솔직히 말씀드리겠습니다. 저는 검증(verification) 작업을 검증 대상이 생성된 것과 동일한 부류의 시스템에 위임했습니다. 이것은 명백한 약점입니다. 하지만 다른 대안을 택했다면 속도 향상의 의미가 없어졌기에 그렇게 했습니다. 저는 이 문제를 해결한 것이 아니라, 하나의 트레이드오프 (tradeoff)를 선택한 것입니다.

내가 잃은 것

최근 동료의 코드를 리뷰해 달라는 요청을 받았습니다. 저는 즉시 수정 사항을 파악했습니다. 전체적인 구조가 제 머릿속에 이미 들어있었기 때문입니다. 하지만 막상 키보드 앞에 앉았을 때 코드를 작성할 수 없었습니다. 어떤 함수를 불러와야 하는지 기억나지 않았기 때문입니다.

설계(design)는 온전했습니다. 그것을 머릿속에서 꺼내는 것이 불가능했을 뿐입니다. 1년 전이었다면 가능했을 일입니다.

이것이 괜찮은 척하고 싶지는 않습니다.

내가 얻은 것

서로 다른 곳에 존재하는 아이디어들을 연결하는 능력입니다.

단일 지점에서의 깊이(depth)가 아닙니다. 그것은 AI가 가장 빠르게 메운 격차입니다. 만약 제가 한 가지 주제를 깊게 파고들어야 한다면, 이제는 오후 한나절이면 충분합니다. 깊이는 저렴해졌습니다.

저렴해지지 않은 것은, 이쪽의 아이디어와 저쪽의 아이디어가 서로 다른 옷을 입고 있을 뿐 같은 아이디어라는 것을 인식하는 능력입니다. 시스템의 전체적인 형상을 시야에 담고, 그 이음새가 어디에 있는지 아는 것입니다.

그것이 바로 전화선 문제(phone line problem)의 실체였습니다. 기술적으로 어려운 것이 아니라, 정답이 제가 서 있는 영역과 연결하지 못했던 다른 영역에 존재했을 뿐입니다.

그리고 그 연결하는 작업이 결과물의 품질을 결정합니다. 형상을 볼 수 있다면, 모델에게 어떤 연결이 중요한지 알려줄 수 있습니다. 그렇지 못하면, 자신도 모르는 사이에 영원히 그럴듯한 중간 답변(middle answer)만을 받게 될 것입니다.

모든 한계는 나였다

시간의 흐름을 따라 나열해 보면 그 패턴을 놓치기 어렵습니다. 위에 나타난 모든 한계는 마치 도구의 한계처럼 보입니다. 하지만 그중 어느 것도 도구의 한계가 아닙니다.

반복되는 현상은 모델이 기억하지 못한 것이 아니라, 제가 비계 (scaffolding)를 구축하지 않았기 때문이었습니다. 중간 답변들이 얕았던 것은 내용이 부실해서가 아니라, 제가 아직 그 용어를 완전히 소유하지 못했기 때문이었습니다. '죽은 파이(dead Pi)'가 무모함이었던 것은, 그럴듯한 것과 되돌릴 수 없는 것 사이에 아무런 층(layer)을 쌓지 않았기 때문이었습니다. 리뷰의 병목 현상은 바로 저 자신이었습니다.

올해 모델은 거의 모든 면에서 더 나아졌습니다. 하지만 제 시스템을 이해하는 능력은 나아지지 않았고, 앞으로도 그럴 것입니다. 그것은 기술(skill)이 아니라, 당신이 직접 서 있어야만 하는 장소의 문제이기 때문입니다. 내 책상 위의 게시판, 아무도 기록하지 않았지만 모두가 이미 알고 있는 제약 조건, 새벽 2시에 내가 목격했던 실패들. 이 중 그 어떤 것도 훈련 데이터 (training data)에 포함되어 있지 않습니다. 왜냐하면 그 중 어느 것도 기록된 적이 없기 때문입니다.

내가 하는 모든 일이 빨라졌지만, 단 한 가지 예외가 있었습니다. 바로 무엇이 무엇과 연결되는지를 결정하는 것입니다. 그 결정은 여전히 나의 몫이며, 이전보다 훨씬 더 많은 결과물에 결부되어 있습니다. 따라서 조각들이 어떻게 맞물리는지 파악하는 것의 가치(return)는 올해 줄어든 것이 아니라 오히려 올라갔습니다. 이는 제가 예상했던 것과는 정반대의 결과였습니다.

그래서 지금 당장 스스로에게 무엇을 구축할 가치가 있느냐고 묻는다면, 저는 언어나 프레임워크, 혹은 더 나은 프롬프트 (prompt) 작성법을 말하지 않을 것입니다. 대신 저는 하나의 지식을 다른 지식과 결합하는 능력을 말할 것입니다. 이것은 모델이 제공할 수 없는 유일한 입력값이며, 모델이 되돌려주는 모든 것의 품질을 결정합니다.

1년이 지난 후의 제 답변은 이것입니다. 당신의 답변은 다를 것입니다. 당신은 제가 한 번도 서 본 적 없는 곳에 서 있기 때문입니다.