이번 에이전트 하네스 수업의 개념을 AI에게 설명하면서 제가 원래 하던 작업 중 하나인 '상가 탐색 관제 서버'에 적용해서 작업을 해달라고 요청했습니다.
이 작업은 원래 API 서버에서 GET과 POST를 이해하기 위해 시작했는데, 이후 실제 지도와 위치 검색, 검색 반경, 상가 마커를 차례로 붙이면서 조금씩 커지고 있었습니다.
기능을 작은 단계로 나눠 구현하고 있었기 때문에 Skill 조합을 연습하기에도 적당해 보였습니다.
결과부터 말하면 프로젝트는 잘 진행됐습니다.
서울시청을 검색하면 반경 500m의 상가 3,131개를 지도에 표시했고, 실제 Docker와 모바일 화면까지 검증했습니다. 이후 서버 이벤트 기능까지 진행하면서 전체 테스트는 90개가 됐습니다.
90개 모두 통과했습니다.
그리고 이것을 사례글을 쓰려고 AI가 정리해준 초안을 읽다가 문제가 생겼습니다.
재미가 없었습니다.
처음에는 AI가 글을 재미없게 쓴 줄 알았습니다. 다시 생각해보니 제가 이 프로젝트에서 특별히 기억하는 장면이 없었습니다.
기록에는 TDD, 계약 RED/GREEN, 접근성 Gate, Docker Gate, Eval, 독립 리뷰가 빼곡하게 남아 있었지만, 전 이것들에 관여한 기억은 없었고, 무슨 말인지 이해도 안갔습니다.
그래서 결국 AI에게 다시 물었습니다.
“Gate가 정확히 뭐야?” “계약을 먼저 실패시켰다는 게 무슨 뜻이야?” “왜 테스트를 일부러 실패시켜?”
Skill 조합을 배우려고 시작한 프로젝트였는데, 정작 AI만 Skill 조합을 열심히 사용하고 있었습니다.
👩💻 순서
정말 순탄하게 AI는 잘 굴러갔다
오류가 없어서 오히려 배운 것도 없었다
모든 마찰을 AI에게 맡기며 쌓인 인지부채
학습모드 ON Skill에 대한 대략적인 구상
1. 정말 순탄하게 AI는 잘 굴러갔다
이 프로젝트에서 이틀간 반나절씩 계속 AI를 돌리면서 실질적으로 제 결정이 개입한 건 딱 한 번 뿐이었습니다.
이 단계에서는 검색한 상가를 지도 마커와 목록으로 연결하는 작업이었습니다.
기존 API는 검색한 곳으로부터 가까운 순으로 상가를 최대 100개까지 반환했습니다.
그런데 서울시청 주소와 반경 500m를 입력해 실제 데이터를 확인하자 전체 상가가 3,131개였습니다.
화면에 나온 100번째 상가는 중심에서 약 112m 거리에 있었습니다.
500m를 검색했지만 실제 화면은 112m 정도까지만 보여주고 있었습니다. 지도 외곽이 비어 있어서 나머지 3,031개는 없는 것처럼 보였습니다.
그렇다고 상가 3,131개를 모두 클릭 가능한 지도 마커로 만들기도 어려웠습니다.
AI는 몇 가지 대안을 제시했고, 저는 전체 상권의 밀도와 상세 탐색 대상을 분리하는 안을 선택했습니다.
전체 3,131개는 같은 좌표끼리 묶어 Canvas 숫자 버블로 표시
상세 카드와 키보드로 접근할 수 있는 마커는 100개씩 활성화
더보기를 누르면 다음 100개를 추가
100m·300m·500m 링으로 거리 표시
같은 좌표의 상가를 묶자 3,131개가 396개의 좌표 버블로 줄었습니다.
여기까지 제가 기억하는 것은 세 번째 대안을 선택했다는 점과, 지도에 상가가 빽빽하게 나타났다는 것입니다.
그 뒤부터 AI는 아래 Circuit을 따라 작업했습니다.
실제 데이터 측정
→ API 계약 RED
→ UI 계약 RED
→ 최소 구현
→ 자동 테스트 Gate
→ Docker Gate
→ 실제 브라우저 Gate
→ 모바일 Gate
→ 독립 리뷰
→ RADAR 기록첫 구현에서는 테스트 42개가 통과했습니다.
독립 리뷰에서는 이전 검색 결과가 최신 화면을 덮을 수 있는 문제, 같은 거리의 상가 정렬이 흔들릴 수 있는 문제, 지도 실패 후 잘못된 마커가 남는 문제 등이 발견됐습니다.
AI는 각 문제를 다시 테스트로 재현하고 수정했습니다.
비슷한 sibling 경로도 함께 확인했습니다. 주소 검색뿐 아니라 건물 후보 선택과 자동완성 입력이 엇갈릴 때 이전 요청이 화면을 덮는 문제까지 찾아냈습니다.
수정 후 테스트는 53개로 늘었고 모두 통과했습니다.
이후 프로젝트는 검색 완료 효과와 서버 이벤트 전달 기능까지 진행됐습니다. 전체 회귀 테스트는 90개가 됐고, Docker와 독립 리뷰도 통과했습니다.
AI는 정말 열심히 머리를 싸매며 굴러갔습니다.
저는 너무 열심히 굴러가는 중이라 중간에 용어를 물어보면 방해하는 것 같아 조용히 결과를 기다렸습니다.
2. 오류가 없어서 오히려 배운 것도 없었 다
이전 사례글에서는 AI가 제가 요청한 문제를 다른 문제로 바꿔버린 큰 오류가 있었습니다.
그때는 실제 화면과 결정 기록이 서로 맞지 않았고, 저는 뒤늦게라도 “왜 이렇게 됐지?”라고 물어볼 수밖에 없었습니다.
원래 요청과 AI의 해석을 다시 비교했습니다. 어떤 대안을 승인했는지, 무엇을 잘못 전제로 삼았는지도 확인했습니다.
오류가 저를 멈춰 세운 것입니다.
반면 API Server에서는 특별히 큰 사고가 없었습니다.
위의 경우 외에는 제가 '이제 Phase 몇 단계 구현해줘'하면 AI가 알아서 돌아가고 테스트하고 오류를 고치고 검증을 완료했습니다.
제가 결과를 확인했을 때는 대부분 해결되었고, 프로젝트는 계속 앞으로 갔습니다.
이틀간 로드맵 상의 진도도 쭉쭉 빠졌고 사례글을 작성하기 위해 초안 작성을 요청했습니다.
그런데 사례글 초안을 읽어보니 도저히 제 경험이라고는 받아들일 수 없었습니다.
계약을 RED로 만들었다는 것이 무슨 뜻인지, 자동 테스트 Gate와 Docker Gate가 왜 따로 필요한지는 설명하기 어려웠습니다.
기록은 AI가 무엇을 했는지 설명하고 있었지만, 제가 무엇을 이해했는지는 보여주지 못했습니다.
그래서 저는 초안을 꼼꼼하게 읽으면서 번호를 달고 모르는 용어와 의미, 이 과정이 왜 필요했는지를 물어봤습니다.
그제야 이번 프로젝트의 문제가 보였습니다.
기술적으로는 큰 오류가 없었고, 그래서 새롭게 깨달을 계기도 없었습니다.
3. 모든 마찰을 AI에게 맡기며 쌓인 인지부채
기술부채는 지금은 작동하지만 나중에 수정하고 관리하기 어려운 코드 가 쌓이는 상태를 말합니다.
이번에는 코드보다 제 머릿속에 다른 종류의 부채가 쌓였습니다.
AI는 계속 작업할 수 있지만, 저는 왜 이 순서로 진행했고 무엇을 통과했는지 제 말로 설명하기 어려운 상태
저는 이것을 이번 프로젝트에서 생긴 인지부채라고 생각합니다.
문제 없이 잘 돌아가니 모르는 말이 나와도 가만히 있고, 제가 판단해야 할 일이 생기면 AI가 가장 추천하는 안을 포함해 대안을 정리하고, 오류가 생기면 알아서 실패 Owner도 찾아냈습니다.
제가 흐름을 완전히 이해하지 못해도 다음 단계로 넘어갈 수 있었습니다.
편리했습니다.
그런데 학습 프로젝트에서는 모든 마찰이 나쁜 것이 아니었습니다.
왜 테스트가 실패했는지 잠깐 생각해보는 것, 서로 다른 Gate가 무엇을 확인하는지 구분하는 것, 이 실패를 어느 Owner에게 돌려보내야 할지 고민하는 과정도 학습의 일부였습니다.
AI가 개발 과정의 마찰을 줄이면서 학습에 필요했던 마찰까지 함께 없애버렸습니다.
결국 AI가 작성한 사례글에는 90개의 테스트를 통과했다는 내용이 남고, 제 머릿속에는 후와고(제 반려봇)가 엄청 열심히 굴렀다는 기억만 남았습니다.
4. 학습모드 ON Skill에 대한 대략적인 구상
요새 바이브코딩에 시간을 더 쏟으면서 저라는 사람은 단순히 일이 효율적으로 진행되는 것 뿐만 아니라 거기에서 얻어가는 무언가가 있길 바란다는 것을 알게 되었습니다.
그래서 급한 일이 아니고, 처리 결과를 시간 내서 확인할 수 있을 때 사용할 '학습모드 ON'을 구상하고 있습니다.
현재 Circuit은 대략 아래와 같습니다.
요청
→ TDD
→ 구현
→ 각 Gate
→ 독립 리뷰
→ 완료학습모드를 켜달라고 요청하면 작업 중간 중간에 다음의 것들을 넣습니다.
작업 전
→ 이번에 관찰할 개념 하나 선택
작업 중
→ 실제 RED 또는 Gate 실패 장면에서 짧게 설명
작업 후
→ 구현한 내용과 연결한 간단한 퀴즈한 번에 모든 용어를 습득할 생각은 아닙니다.
예를 들어 오늘의 개념이 Gate라면 자동 테스트, Docker, 브라우저 검증이 각각 무엇을 확인하는지만 관찰합니다.
작업이 끝난 뒤에는 이런 짧은 문제를 받을 수 있습니다.
자동 테스트는 모두 통과했습니다. 그런데 실행 중인 Docker 화면에는 수정한 기능이 보이지 않습니다. 다음으로 무엇을 확인해야 할까요?
정답을 미리 암시하지 않고 제가 한번 골라본 뒤, 실제 프로젝트에서 어떤 Gate가 이 문제를 확인했는지 연결하는 방식입니다.
TDD를 배우는 날에는 RED/GREEN 한 가지만 봅니다.
새 기능의 테스트를 작성했는데 처음부터 통과했습니다. 이 테스트를 그대로 믿어도 될까요?
이 정도라면 AI가 작업하는 흐름을 계속 유지하면서도 제가 완성된 결과만 받지는 않을 것 같습니다.
근데 막상 일이 잘 안풀리는데 AI가 오류 해결에 집중하지 않고 퀴즈만 내면 좀 어이없을 것 같기도 합니다.
이런 경우에는 퀴즈가 나오는 타이밍에 조건을 걸어서, 검증 실패로 인한 재검증이 몇 회 이상인 경우에는 넘어가는 걸 고려해야 할 것 같아요.
(다 쓰고 보니 제가 너무 복에 겨운 고민을 하는 것 같기도 하네요...)
