AI를 오래 쓸수록 이상하게도 AI를 덜 믿게 된다.
처음에는 반대였다. 언론이나 각종 매체에서 보는 AI는 무엇이든 알고, 무엇이든 만들며, 실수까지 스스로 고치는 도구처럼 보였다. 실제로 처음 에이전트에게 복잡한 작업을 맡겼을 때는 나도 꽤 놀랐다. 몇 분 만에 여러 파일을 읽고 고친 뒤, 동작하는 결과물을 내놓았기 때문이다.
하지만 작업을 반복할수록 처음의 인상과 실제 능력 사이에 틈이 보이기 시작했다. AI는 빠르고 아는 것도 많다. 동시에 내가 작업하는 프로젝트의 사정에는 놀랄 만큼 무지하다. 결과가 자연스러워 보인다는 것과 내 프로젝트에 맞게 만들어졌다는 것은 전혀 다른 이야기였다.
그래서 요즘 자주 떠오르는 질문이 있다.
AI가 많은 일을 대신해주는 시대에도 내 지식은 필요할까?
지금까지의 답은 그렇다. 다만 지식을 사용하는 자리가 달라지고 있다.
AI는 프로젝트의 사정을 모른다
현재 널리 쓰이는 OpenAI, Claude, Gemini 같은 AI의 중심에는 대규모 언어 모델이 있다. 아주 단순하게 말하면, 모델은 입력된 문맥을 바탕으로 다음에 이어질 가능성이 높은 토큰을 예측하며 답을 만든다.
실제 제품에는 검색과 도구 사용이 붙고, 답을 내기 전에 여러 단계로 추론하거나 결과를 다시 검토하는 과정도 들어간다. 이전보다 훨씬 복잡한 일을 처리할 수 있게 된 이유다.
그렇다고 프로젝트의 목적까지 저절로 이해하는 것은 아니다. 더 좋은 해결책이 어딘가에 있더라도 주어진 문맥에서 떠오를 가능성이 낮다면 답에 포함되지 않을 수 있다. 왜 일부러 단순한 구조를 택했는지, 곧 없앨 기능은 무엇인지, 운영자가 특정 데이터 상태를 의도적으로 유지하고 있는지는 코드만 읽어서는 알기 어렵다.
추론을 오래 한다고 없는 정보가 생기지도 않는다. 오히려 비어 있는 맥락을 그럴듯한 가정으로 채울 때가 있다.
AI가 내놓는 답은 주어진 문맥 안에서 그럴듯한 답이다. 내가 원하는 것은 현재 구조와 운영 방식, 앞으로의 변경 가능성까지 고려한 답이다. 둘은 가끔 같지만 언제나 같지는 않다.
체력바와 스킬바를 맡겨보면
RPG 게임 프로젝트에 이렇게 요청했다고 해보자.
체력바와 스킬바 UI를 구현해줘.
특별한 기준이 없다면 AI는 흔히 볼 수 있는 RPG 화면을 참고해 제법 그럴듯한 UI를 만들 것이다. 체력은 빨간색으로 표시하고, 화면 아래에는 스킬 아이콘과 재사용 대기시간도 붙일 수 있다. 결과 화면만 보면 요구사항이 해결된 것처럼 보인다.
문제는 그 안쪽이다.
프로젝트에 이미 있는 UI 리소스를 재사용했는지, 해상도가 달라져도 레이아웃이 유지되는지, 캐릭터 상태와 UI가 기존 이벤트 흐름으로 연결되는지 확인해야 한다. 비슷한 역할의 관리 코드를 새로 만들지는 않았는지도 봐야 한다. 지금은 잘 보여도 전투를 다시 시작할 때 이벤트가 중복되거나, 화면을 열고 닫을수록 객체가 남을 수 있다.
게임 엔진과 프로젝트 구조를 아는 사람은 이런 위험을 먼저 떠올린다. 기존 프리팹과 리소스를 찾고, 상태 변경이 어디에서 전달되는지 확인한 뒤, 새 코드를 현재 구조 안에 붙이라고 지시할 수 있다.
반대로 관련 지식이 없다면 판단 기준은 화면에 보이는 결과뿐이다. 그 상태로 기능을 계속 덧붙이면 겉은 빠르게 완성되지만 안쪽은 조금씩 갈라진다. 나중에 버그가 드러났을 때는 어디서부터 손대야 할지 모를 만큼 복잡해질 수도 있다.
바이브 코딩이 위험해지는 지점도 여기에 있다. AI로 코드를 만드는 행위 자체가 문제는 아니다. 결과를 평가할 기준 없이 속도만 따라가는 것이 문제다.
테스트도 범위를 정해야 한다
AI 에이전트는 작업을 마친 뒤 테스트로 확인하려는 경향이 강하다. 원래는 좋은 습관이다. 사람이 놓칠 수 있는 오류를 잡고, 같은 문제가 다시 생기지 않도록 남겨둘 수 있다.
그런데 검증 범위를 정하지 않으면 테스트가 작업보다 커진다.
내가 원한 것이 체력바 색상 변경뿐인데 전체 테스트 모음을 돌리고, 여러 번 실행해도 산출물 바이너리가 같은지 비교하려 들 수 있다. 이번 변경과 관계없는 기능까지 다시 검증하기도 한다. 안전해 보이지만 실제로는 시간과 토큰을 쓰는 만큼 확신이 늘어나지 않는다.
색을 바꿨다면 해당 화면을 직접 열어보는 편이 가장 빠르고 정확할 수 있다. 공유 로직의 조건문을 고쳤다면 그 조건을 통과하는 작은 테스트 하나가 적절하다. 결제나 권한처럼 실수 비용이 큰 영역이라면 그때는 검증 범위를 넓혀야 한다.
테스트를 줄이자는 이야기가 아니다. 변경의 위험에 맞는 검증을 고르자는 이야기다.
한 줄짜리 권한 변경은 꼼꼼히 확인해야 하고, 문구나 색상 수정은 실제 화면 한 번으로 충분할 수 있다. 이 차이를 판단하려면 결국 해당 기능에 대한 지식이 필요하다.
"효율적으로"는 기준이 아니다
이 판단까지 AI에게 맡기면 되지 않을까 생각할 수도 있다.
알아서 버그 없이 효율적으로 고쳐줘.
문제는 이 문장에서 효율의 기준이 비어 있다는 것이다.
AI가 효율이라는 단어를 모르는 것은 아니다. 다만 내 프로젝트에서 무엇을 아껴야 하는지는 알 수 없다. 구현 시간을 줄이는 것이 우선인지, 변경 파일을 최소화해야 하는지, 운영 위험을 낮춰야 하는지에 따라 답은 달라진다.
"버그 없이"도 비슷하다. 모든 환경에서 버그가 없다는 사실을 증명하기는 어렵다. 어디까지 확인하면 이번 작업을 끝낸 것으로 볼지 사람이 정해야 한다.
그래서 막연한 부탁보다 작업의 경계를 함께 주는 편이 낫다.
기존 UI 리소스와 상태 전달 흐름을 먼저 확인하고, 새 관리 계층은 만들지 말 것. 색상만 바꾼 뒤 실제 전투 화면에서 체력바를 확인하고 끝낼 것. 전체 테스트는 돌리지 말 것.
이 정도면 무엇을 읽어야 하는지, 무엇을 만들지 말아야 하는지, 어디까지 검증하면 되는지가 선명해진다.
좋은 지시는 길어서 좋은 것이 아니다. 사람이 이미 알고 있는 기준 중 이번 작업에 필요한 것만 정확히 꺼내놓으면 된다.
방법론은 판단을 전달하는 도구다
AI의 한계를 보완하기 위해 프롬프트, 하네스, 반복 루프, 그래프 형태의 작업 흐름과 여러 스킬이 계속 나오고 있다.
나도 이전 글에서 하네스를 에이전트가 반복해서 따라야 하는 작업 기준이라고 정리했다. 지금은 그 생각이 조금 더 분명해졌다. 하네스는 지식을 대신하는 장치가 아니라, 사람이 가진 지식과 판단을 AI가 놓치지 않도록 전달하는 장치에 가깝다.
프로젝트 구조를 모르면 어떤 규칙을 넣어야 하는지 알 수 없다. 실패 비용을 모르면 테스트 범위를 정할 수 없다. 사용 목적을 모르면 여러 해결책 중 무엇이 더 나은지도 고르기 어렵다.
방법론은 이 판단을 반복해서 적용하기 쉽게 만든다. 판단 자체를 없애주지는 않는다.
지식은 판단의 기준으로 남는다
예전에는 지식이 직접 결과물을 만드는 데 주로 쓰였다. 코드를 작성하고, 설계를 그리고, 오류를 추적하는 일이 중심이었다.
AI가 그중 많은 부분을 대신하면서 직접 타이핑하는 시간은 줄었다. 대신 어떤 구조를 따라야 하는지 알려주고, 결과에서 이상한 부분을 발견하며, 어느 정도 검증하면 충분한지 결정하는 일이 커졌다.
AI는 사람이 하루에 작성할 수 있는 것보다 많은 코드를 몇 분 안에 만들 수 있다. 잘못된 방향으로 움직일 때 생기는 부채도 같은 속도로 쌓인다.
그래서 도메인 지식은 AI와 경쟁하기 위해 필요한 것이 아니다. AI가 만든 결과를 다루기 위해 필요하다.
무엇을 맡겨도 되는지, 무엇은 직접 봐야 하는지, 언제 더 검증하고 언제 멈춰야 하는지 아는 것. 지금 내게 지식은 그런 기준에 가깝다.
AI가 많은 일을 대신해도, 무엇을 시키고 어디서 의심하며 언제 멈출지는 아직 사람이 정해야 한다.
적어도 지금은 그렇다.