바이브 코딩 다음은 루프 엔지니어링 — AI 초보 개발자의 성장기

다마고찌를 키우던 필자가 한 걸음 더 나아가 만난 루프 엔지니어링

필자는 얼마 전 블로그 글에서 “AI는 다마고찌처럼 키워야 한다“고 쓴 적이 있다. https://mansgadget.com/ai-skills-claude-chatgpt-gemini/

이 글에서 필자는 AI를 본격적으로 사용하기 시작하면서 겪었던 과정 중 AI에게 일감을 맡길 때 어떻게 하면 일관되고 효율적으로 맡길까를 고민하던 결과로 SKILL에 대한 이야기를 했었다.

그런데, 오늘은 거기서 더 나아가 에이전트 코딩을 넘어서 루프 엔지니어링(Loop Engineering)이라고 하는 개념에 대해서 필자의 성장기를 바탕으로 풀어보려고 한다.

이는 필자와 같은 고민을 안고 있는 모든 AI 초보자분들께 길잡이로써 작음 보탬이라도 되고자 함이니, 천천히 행간을 잘 따라와주시면 어느덧 ‘나 AI 좀 쓰네?’하는 생각을 하실 수 있으리라 생각한다.

요즘 내 머릿속에서는 나와, 내 맥 안에서 돌고 있는 나만의 클로드 코드가 드래곤 길들이기의 히컵과 투스리스처럼 보인다. 혼자서는 엄두도 못 내던 분량의 영상 작업을 일주일도 안 돼 해냈는데, 정확히는 내가 만든 통합 스튜디오 「바이브 스튜디오」가 해낸 일이다.

이를 위해서는 우선, AI의 시대가 어떻게 진화하고 있는지 살펴볼 필요가 있다.

이미지 한 장으로 사람들을 놀라게 한 AI 전성시대의 시작

처음 AI가 사람들에게 주목받기 시작했던 건 실사에 가까운 사진같은 이미지들을 내 마음대로 만들어낼 수 있다는 희망을 사람들에게 보여주기 시작하면서 일 것이다.

특히 미드저니로 만든 “스페이스 오페라 극장”이라는 제목의 ‘작품’은 디지털 파인아트 경쟁 부문에서 우승을 하게되면서 인공지능 생성물에 대한 저작권 논란을 불러 일으키는 등 2020년대는 그야말로 본격적인 AI 전성시대를 맞이하고 있다고 해도 과언이 아니다.

사람들이 열광한 건 단순한 챗봇을 넘어, 프롬프트를 잘 주면 사진 같은 이미지가 나온다는 점이었을 것이다. AI에게 일을 맡기는 방식은 그 프롬프트에서부터 계속 달라진다.

AX를 미뤄 두다 갑자기 따라잡아야 하게 된 개발자들

하지만, 불행히도 모두가 적극적인 AX를 누리고 있는 것은 아니다.

특히 그 중에서 개발자들의 경우는 15개월 전 Ruby on Rails의 DHH와 같은 보수적인 입장 또는 바빠서 여전히 AX에 소극적이었다가 최근 급속도로 AI 없이 개발이 어려울 정도의 상황이 사방에서 펼쳐지자 당혹스러워 하는 경우를 종종 보게 되는데, 오늘은 그래서 SW 개발에 있어서 최신 AX는 어디까지 진화했는지 알아보고, 챗봇에서부터 프롬프트, 스킬, 루프 엔지니어링 등 AI 활용 각 단계가 어떤 차이가 있는지, 왜 이런 변천사가 있는지 천천히 설명하면서 여러분의 AX를 남들과 같은 선상에 끌어 올려보고자 한다.

DHH가 왜 돌아섰는지는 짝 영상(https://youtu.be/NNEAZl4xMWk)에서 자세히 다뤘으니 확인해 주시면 좋겠다. 관련 글은 https://mansgadget.com/dhh-rails-world-hand-coding/ 에 있다.

지금 내가 어디쯤인지 가늠하게 해 주는 AI 활용의 네 단계

우선은 AI를 쓴다는 말 속에 서로 다른 네 가지 방식이 섞여 있다는 점부터 짚어 보도록 하겠다. 챗봇, 프롬프트, 에이전트, 루프다.

이 넷은 어떤 AI를 쓰는지보다 일하는 동안 사람이 끼어드는 때에 따라 나뉜다. 단계를 하나씩 옮길 때마다 무엇이 달라지는지만 보면 지금 내가 어디쯤 서 있는지 알 수 있다.

나는 프롬프트 단계에서 처음 손에 잡히는 성과를 냈다. 그리고 에이전트 단계에서 바이브 스튜디오를 만들다가 바로 그 「0」을 만났다. 그 이야기는 뒤에서 짧게 한다.

1단계 챗봇 — 한 마디 말하면 한 마디 답하던 방식

챗봇은 내가 한 마디 하면 AI가 한 마디 답하고, 그다음 말은 다시 내 차례가 되는 방식이다. 대화가 이어지는 것 같아도 앤트로픽 문서의 설명대로 챗봇에 쓰이는 API는 앞의 대화를 기억하지 않아서, 말할 때마다 대화 기록 전체를 통째로 다시 보내야 한다.

그러니 다음에 할 일도, 답이 맞았는지도 사람이 한 걸음씩 정한다. 투스리스에 빗대면 히컵이 페달을 밟을 때마다 꼬리날개가 한 번씩 움직이던 1편의 비행이다.

2단계 프롬프트 — 지시문 하나로 승부하던 방식

프롬프트 자체는 네 단계 모두에 들어가는 재료이고, 여기서는 지시문 하나로 승부하는 쓰는 법을 가리킨다. 말을 주고받으며 더듬기보다 역할, 맥락, 예시, 형식을 처음부터 담아 한 번에 원하는 결과를 받아 낸다.

첫 성과를 내기 쉬운 단계지만 결과가 아쉬우면 그 지시문을 고쳐 쓰고 점점 길게 늘이게 된다. 아무리 길고 자세해져도 늘 마음에 쏙 들기는 어려웠고, 매번 같은 품질로 나오기도 쉽지 않았다.

내 작업에서는 이렇다. 고객 인터뷰 내용을 내 도메인 지식과 개발 경험으로 해석해 AI에게 지시했더니, 초안 작성을 시작한 지 1주일 만에 워크플로우, 와이어프레임 설계서, 디자인 시스템 정의서, 비주얼 디자인 가이드라인 등 100페이지가 넘는 기획 문서를 디자인 팀에 전달할 수 있었다. 인터뷰에서 진짜 요구를 가려낸 건 내 경험이었는데, 결과가 됐는지는 이 단계에서도 하나하나 내가 봐야 했다.

3단계 스킬 — 일하는 법을 파일에 적어 두고 맡기던 방식

세 번째 단계는 에이전트이고, 스킬은 그 에이전트가 읽는 파일이다. 회사의 양식과 말투, 하면 안 되는 일을 파일에 적어 두면 AI가 일하다 필요할 때 꺼내 읽는데, 클로드의 스킬도 구글의 젬스도 같은 생각에서 나왔다.

목표를 주면 AI가 파일을 열고 명령을 돌린 다음 그 결과를 보고 다음 행동을 스스로 정한다. 다음 행동을 정하는 쪽이 사람에서 AI로 처음 넘어가는 단계이고, 투스리스에 빗대면 3편의 자동 꼬리날개다.

오픈AI의 한 팀은 이런 환경을 깔아 두고 사람이 손으로 쓴 코드 0줄로 다섯 달 동안 약 100만 줄을 만들었다고 밝혔다. 다만 일을 맡기는 것도, 「다 됐습니다」라는 보고를 확인하는 것도 아직은 사람이 한다.

4단계 루프 — 사람이 프롬프트를 주던 일을 시스템이 대신하는 방식

루프는 에이전트를 한 겹 더 큰 반복으로 감싼다. 정해 둔 시간이나 사건이 일을 시작시키고, 만드는 쪽과 따로 둔 검사자가 완료 기준으로 결과를 잰다.

기준을 넘으면 멈추고, 못 넘으면 대화 밖에 남겨 둔 기록을 이어 읽으며 다시 돈다. 올해 6월 애디 오스마니가 이를 루프 엔지니어링으로 글에 정리했는데, 그 글이 인용한 클로드 코드 책임자 보리스 체르니의 말이 이 단계를 한 줄로 보여 준다. 「이제 클로드에게 프롬프트를 쓰지 않는다. 클로드에게 프롬프트를 주는 루프가 돌고 있다.」

여기에는 반드시 달아야 할 것이 하나 있다. 「좋아질 때까지」 같은 모호한 문장 대신 오스마니의 예처럼 「인증 테스트가 전부 통과하고 린트가 깨끗할 때」라고 써야 루프가 멈춘다. 사람은 매 걸음을 밟는 대신 기준을 쓰고, 루프가 멈췄을 때 결정한다.

문장을 더 길게 붙여도 제자리였던 까닭은 무엇일까

METR가 2025년 여름에 숙련 개발자 16명에게 실제 작업 246건을 맡겨 보았더니, 이들은 20% 빨라졌다고 믿었지만 실제로는 19% 더 오래 걸렸다.

빨라졌다는 느낌은 AI가 답을 들고 돌아오는 시간이 줄어든 데서 나온다. 원하는 답을 들고 오기까지 다시 시키는 시간이 늘었으니 전체로는 오히려 더 걸린 것이다.

자기가 낸 시험을 자기 답안지로 채점하면 늘 백 점이 나오듯, 만든 쪽의 숫자로 만든 쪽을 재면 늘 0이 나온다. 그래서 프롬프트 시대의 흔한 실수는 결과가 아쉬울 때마다 문장을 더 길게 붙이는 것이었고, 정작 필요했던 건 매번 같은 방식으로 일하게 하는 매뉴얼과 결과가 됐는지를 재는 기준 두 가지였다.

사람이 끼어드는 때가 점점 뒤로 물러나는 앞으로의 방향

네 단계를 나란히 놓으면 오른쪽으로 갈수록 사람이 끼어드는 때가 한 마디마다에서 일 하나마다로 줄고, 끝내는 기준을 쓸 때와 루프가 멈췄을 때만 남는다.

이 넷은 겹쳐 있어서 루프 안에는 에이전트가, 에이전트 안에는 프롬프트가 들어 있다. 오른쪽이 늘 정답은 아니어서, 앤트로픽도 단순한 프롬프트로 시작하고 그것으로 모자랄 때만 에이전트를 더하라고 권한다.

루프도 그걸 만드는 개발자가 같이 자라야 좋아진다.

날짜 문자열 정리 함수 하나로 챗봇에서 스킬까지 올라가 보는 따라 하기

다음은 필자가 이 글을 위해 새로 짠 연습용 사례이며, 내 실제 작업 기록이 아니다. 낯선 소프트웨어 대신 누구나 손댈 수 있는 작은 일 하나로 세 단계를 올라가 보면 된다. 예로 흩어진 형식으로 적힌 날짜 문자열을 한 가지 형식으로 정리하는 함수 하나를 고른다.

1단계는 챗봇이다. 뒤섞인 날짜 몇 개를 붙여 넣고 한 형식으로 바꾸는 함수를 만들어 달라고 말한 뒤, 빈 값은 어떻게 하는지, 연도가 두 자리면 어떻게 읽는지 한 마디씩 되묻는다. 다음 질문도, 답이 맞았는지도 내가 정한다.

2단계는 프롬프트다. 역할(함수를 짜는 개발자), 맥락(어떤 형식의 날짜가 들어오는지), 예시(입력과 기대하는 출력), 형식(함수 하나에 짧은 설명)을 지시문 하나로 묶어 한 번에 받는다. 지시문을 고치는 일과 결과를 확인하는 일은 내 몫이다.

3단계는 스킬이다. 이름 짓는 방식, 오류를 알리는 양식, 입력 모양을 멋대로 추측해 바꾸지 않는다는 금지 사항을 파일에 적어 두고 에이전트에게는 목표만 준다. 에이전트가 파일을 읽고 코드를 만들어 돌려 본 뒤 「다 됐습니다」라고 보고하면, 그 말이 맞는지 확인하는 일은 아직 내가 한다.

같은 함수에 완료 기준과 따로 둔 검사자를 달아 루프로 바꾸는 따라 하기

같은 함수를 이번에는 루프로 바꾼다. 기준 한 줄, 따로 둔 검사자, 인수인계 기록, 멈추는 규칙 네 가지를 단다.

기준은 됐다 안 됐다가 분명해야 한다. 오스마니의 예처럼 「인증 테스트가 전부 통과하고 린트가 깨끗할 때」처럼 참과 거짓이 갈리는 문장으로 적는다.

함수를 만든 에이전트가 자기 예시로 재면 늘 통과하므로, 검사자에게는 따로 준비한 입력을 돌리게 한다. 못 넘으면 지금까지 한 일과 실패한 이유를 적어 둔 기록 파일을 읽고 다시 돈다. 정해 둔 횟수나 사용량에 닿으면 루프가 멈추고 사람이 결정한다.

사람이 끼어드는 때는 기준을 쓸 때와 멈췄을 때뿐이다.

「검사 672 ALL OK. 실전 0회.」에 속았던 필자의 에이전트 바이브 코딩

앞의 사례를 받치는 내 기록을 짧게 적는다. 바이브 스튜디오 첫 버전은 전형적인 에이전트 바이브 코딩이었고, 검사 144개를 통과하더니 사흘이 채 안 돼 672개로 늘었는데 기록에는 「검사 672 ALL OK. 실전 0회.」라는 줄이 붙어 있었다.

영상에 입히는 자막 싱크는 계속 어긋나는데 검사는 늘 0이었다. 자막을 만든 숫자 자신으로 자막을 쟀기 때문이고, 에이전트에게 일만이 아니라 채점표까지 넘긴 것이 원인이었다.

고침은 앞의 네 가지와 같다. 프로젝트마다 RESUME.md라는 인수인계 파일에 상태와 다음 할 일을 적게 하고 줄 수에 상한을 뒀으며, 완료 검사는 스크립트, 제미나이, 클로드 표본으로 나눠 맡겼다.

사용량 창이 차면 기다리는 멈추는 규칙도 달았다. 커밋된 코드 사본에서 검사 3,869개를 전부 통과해야 서비스에 올라가게 했는데 10월 2일부터 5일 아침까지 서른 번 가운데 열 번이 여기서 막혔다.

잰 숫자로만 말하면, 자막은 말보다 보통 0.54초 어긋나 있다가 음성 신호로 따로 재니 0.04초로 들어왔다. 0.5픽셀 넘게 흔들린 프레임은 22.9%에서 0%가 됐고, 버그 92건 가운데 88건에는 다시 나면 잡아낼 검사의 이름이 적혀 있다.

얼마나 빨라졌는지는 잰 숫자가 없어 말하지 않는다. 완료 기준이 틀리면 루프는 틀린 쪽으로 성실하게 돈다는 한계도 있다.

오늘 바로 해 볼 수 있는 첫 루프의 완료 기준 한 줄

AI를 길들인다는 건 더 길게 시키는 일이 아니라 「됐다」를 누가 재는지 정하는 일이다. 프롬프트, 젬스, 스킬, 루프로 이름은 계속 바뀌었지만 정작 바뀐 건 사람이 끼어드는 때 하나였다.

오늘 해 볼 일도 하나다. 매주 되풀이하는 일 하나를 골라 됐다 안 됐다가 분명한 「다 됐다」의 기준을 한 줄로 적고, 그 기준에서 벗어난 결과가 나오면 결과만 고치지 말고 그걸 만든 쪽을 한 번 고쳐 본다. 앞의 날짜 정리 함수가 그 첫 연습이다.

내일 맡길 일 하나의 「다 됐다」를 나는 무엇으로 정할 것인가.