처음부터 거창하게 에이전트를 도입한 것은 아니었다. 이전까지는 챗 형태로 알고리즘 일부를 물어보거나, 작은 코드 조각을 도움받는 정도였다. 그래서 첫 에이전트 경험은 꽤 선명하게 남아 있다.
“이 정도로 복잡한 프로젝트를, 얘가 어디까지 이해하고 고칠 수 있을까?”
그런 시험에 가까운 마음으로 여러 작업을 맡겨봤다. 놀랍게도 대부분의 경우 에이전트는 내가 말한 요구사항을 실제로 동작하는 결과물까지 만들어냈다.
처음의 놀라움
처음에는 속도와 실행력이 가장 크게 다가왔다. 복잡한 프로젝트 구조를 어느 정도 읽고, 여러 파일을 고치고, 테스트까지 붙이는 흐름은 이전의 챗 기반 도움과는 완전히 달랐다.
하지만 그 놀라움은 오래가지 않았다. 작업을 반복할수록 에이전트가 프로젝트의 모든 맥락을 꿰고 움직이는 것은 아니라는 점이 보이기 시작했다. 이것이 아직 기술적으로 어려운 일인지, 토큰 비용과 성능 제한 때문에 의도적으로 제한된 것인지는 알 수 없다.
중요한 건 결과다. 에이전트는 요구사항을 처리하지만, 그 요구사항이 프로젝트 안에서 어떤 의미를 갖는지까지 항상 이해하지는 못한다.
요구사항과 설계 사이의 틈
에이전트는 “이 기능이 동작하게 해줘”라는 말에는 꽤 잘 반응한다. 문제는 그 기능을 구현하는 방식이다.
프로젝트 구조를 잘 아는 사람이라면 기존 흐름을 따라갔을 부분에서, 에이전트는 새로운 우회로를 만들기도 한다. 이미 있는 관리 코드를 놓치거나, 비슷한 역할의 함수를 하나 더 만들거나, 지금 당장은 돌아가지만 나중에 유지보수를 어렵게 만드는 설계를 붙이기도 한다.
즉, 결과는 맞아 보이는데 구조가 흔들릴 수 있다.
이 간극을 방치하면 프로젝트는 점점 누더기에 가까워진다. 기능은 늘어나지만 기준은 흐려지고, 코드를 읽는 비용은 계속 커진다.
바이브 코딩의 문제는 속도에서 시작된다
AI의 작업 속도는 사람이 따라가기 어렵다. 몇 분 사이에 여러 파일이 바뀌고, 새로운 흐름이 생기고, 겉보기에는 요구사항이 해결된다.
그 모든 코드를 매번 사람이 꼼꼼하게 다시 읽는 것은 현실적으로 어렵다. 그래서 많은 경우 결과물만 확인한다.
일단 잘 동작하네.
이 판단이 반복되면 위험하다. 작동 여부만 보고 넘어간 코드가 쌓이면, 어느 순간 유지보수하기 어려운 구조가 된다. 내가 느낀 현재 바이브 코딩의 한계는 여기에 있다.
바이브 코딩 자체가 나쁘다는 뜻은 아니다. 다만 기준 없이 “느낌대로 맡기는 방식”을 라이브 서비스에 그대로 적용하면, 나중에 감당하기 어려운 부채가 생길 수 있다.
하네스는 거창한 장치가 아니다
이 문제를 겪고 나면 자연스럽게 하네스라는 개념이 필요해진다.
처음에는 나도 “그래서 하네스가 정확히 뭔데?”라는 질문을 계속했다. 돌아오는 설명은 대체로 추상적이었다.
AI에게 하네스를 채워서 원하는 동작만 하도록 만드는 것.
말은 이해되지만, 실제로 무엇을 해야 하는지는 여전히 흐릿하다.
내가 지금 이해한 하네스는 조금 더 단순하다. 에이전트가 작업할 때 반복해서 따라야 하는 기준을 계속 주입하는 것이다.
- 프로젝트 구조는 어디서 확인하는지
- 어떤 파일은 직접 수정하지 말아야 하는지
- 어떤 테스트를 반드시 돌려야 하는지
- 성능 개선은 어떤 지표로 판단하는지
- 새 기능은 기존 흐름 중 어디에 붙어야 하는지
이런 기준이 있어야 에이전트의 속도가 프로젝트의 방향과 어긋나지 않는다.
스킬은 하네스의 한 형태가 될 수 있다
에이전트에는 보통 스킬이라는 개념이 있다. 반복되는 작업을 더 잘 처리하도록 돕는 작업 문서다.
예를 들어 A 프로젝트 구조 파악법이라는 스킬이 있다면, 그 안에는 이런 내용이 들어갈 수 있다.
- 인증 흐름은 어디에서 시작되는지
- 콘텐츠 저장은 DB를 우선하는지, 파일을 우선하는지
- 배포 전에 어떤 검증을 해야 하는지
- 절대 우회하면 안 되는 기존 구조는 무엇인지
이런 문서를 관련 작업마다 읽게 만들면, 스킬은 사실상 하네스처럼 작동한다. 에이전트가 매번 처음 보는 프로젝트처럼 움직이지 않도록 붙잡아주는 장치가 되는 것이다.
좋은 지시는 작업의 레일이 된다
하네스는 꼭 별도의 문서일 필요는 없다. 지시 자체가 하네스가 될 수도 있다.
예를 들어 성능 최적화 해줘라는 요청은 너무 넓다. 어디를, 얼마나, 어떤 기준으로 줄여야 하는지 알 수 없기 때문이다. 그러면 에이전트는 눈에 보이는 작은 수정만 하고 멈추거나, 엉뚱한 부분을 건드릴 수 있다.
반대로 이렇게 말하면 다르다.
이 구간을 프로파일링해서 최적화 전후 시간을 비교하고, 최소 30% 이상 줄여줘.
이 문장에는 측정 지점, 목표 수치, 성공 기준이 들어 있다. 에이전트는 이제 막연히 “좋아 보이는 코드”가 아니라, 정해진 목표를 향해 움직인다.
아직은 감독이 필요하다
요즘은 직접 코드를 쓰는 시간보다 에이전트를 감독하는 시간이 더 길어졌다. 요구사항을 제대로 이해했는지, 기존 구조를 무시하지 않았는지, 결과만 맞고 설계가 흐트러진 것은 아닌지 확인하는 일이 많아졌다.
에이전트는 분명 뛰어난 도구다. 하지만 좋은 도구일수록 사용자의 기준이 더 중요해진다.
“당연히 잘 해주겠지”라는 믿음만으로 맡기기에는 아직 위험하다. 특히 자신의 프로젝트 구조를 스스로 모르는 상태에서 모든 것을 에이전트에게 넘기면, 이후에는 꽤 골치 아픈 상황이 생길 수 있다.
아직은 그렇다.
에이전트가 개발을 대신해주는 시대라기보다, 개발자가 에이전트를 어떤 기준으로 움직이게 할지 설계해야 하는 시기에 더 가깝다고 느낀다. 그리고 그 기준을 붙잡아주는 것이, 지금 내가 이해한 하네스다.