Loki's Blog

들어가며

원하는 기능을 프롬프트에 작성하면 데이터 처리 로직부터 화면까지 순식간에 나온다. 이전 같으면 반나절은 걸렸을 CRUD 하나가 지금은 요청 몇 번으로 끝나고, 인증 처리나 폼 검증처럼 매번 손이 가던 반복 작업도 크게 다르지 않다. 바이브코딩이라는 말이 유행하는 것도 이 지점 때문이라 생각한다. 구현 자체는 더 이상 병목이 아니다. 그렇다면 무엇이 병목인가?

AI는 결과만 확인할 뿐, 방향은 판단하지 않는다

AI는 프롬프트와 결과물이 일치하는지만 확인한다. 그 프롬프트 자체가 시스템의 제약과 맞는지, 나중에 어떤 요구사항과 부딪힐지는 AI의 검증 범위 밖이다. 잘못된 방향을 인지하지 못한 채 승인 버튼을 누르면, 그 순간 잘못된 설계 위에서 동작하는 코드가 그대로 만들어진다.

겉보기엔 아무 문제가 없다. 화면은 정상적으로 뜨고, 요청한 기능도 정확히 그대로 동작한다. 하지만 그 뒤에는 시스템의 제약과 어긋난 설계가 숨어 있다. 코드가 돌아간다는 사실이 방향이 맞다는 확신으로 착각되기 때문에, 오히려 설계가 잘못됐다는 사실은 더 늦게 드러난다.

상태를 어디에 둘지, 이 필드가 왜 필요한지 같은 질문에 스스로 답하지 못하면 애초에 다음 줄을 쓸 수 없었다. 구현 과정 자체가 설계 근거를 언어화하도록 강제하는 절차이기도 했다. AI에게 맡기면 이 언어화 과정 없이 결과물부터 받는다. 코드는 그대로 손에 쥐어지지만, 왜 그 구조를 선택했는지는 누구도 설명해본 적 없이 남는다.

이렇게 놓친 방향은 시간이 지난다고 저절로 드러나지 않는다. 오히려 그 위에 다른 코드가 계속 쌓이면서 되돌리는 범위 자체가 점점 커진다. 그렇게 나온 결과물은 나중에 몇 배의 시간과 비용을 들이고서야 제자리로 돌아오고, 구현이 빨라진 만큼 그 대가를 치르는 속도도 함께 빨라진 셈이다.

결국 지금 개발자에게 필요한 건 방향을 잘못 잡지 않도록 미리 고민하고 설계하는 능력이라고 생각한다. 프롬프트를 정교하게 쓰는 일과는 다르다. 프롬프트가 아무리 정교해도, 요청 자체가 잘못된 방향이면 결과물도 그 방향으로 정교해질 뿐이다. 코드를 짜는 속도보다 그 코드가 향할 방향을 잡는 정확도가 중요해졌다.

잘못된 설계가 불러온 비용

이전에 SEO를 연습해보려고 토이 프로젝트를 하나 만들었다. URL을 기준으로 서버가 페이지를 렌더링하는 구조였고, 검색엔진은 사용자가 화면에서 클릭해 바꾼 상태를 그대로 기억하지 않는 대신 각 URL을 요청해 그 주소에서 확인할 수 있는 콘텐츠를 기준으로 페이지를 이해한다.

이때, 목록 페이지의 카테고리 필터 구현을 AI에게 맡겼고, 로컬 상태로 관리하는 코드가 나와 별다른 검토 없이 그대로 승인했다. 필터 상태가 URL에 없으니 어떤 카테고리 URL로 접근해도 서버는 같은 초기 화면을 내려줬고, 사용자가 화면에서 카테고리를 바꿔도 주소는 그대로였다. /products?category=shoes처럼 특정 카테고리 결과를 가리키는 URL도 만들어지지 않았다.

뒤늦게 코드를 다시 들여다보고 나서야, 이 구조가 SEO라는 프로젝트의 목적과 맞지 않는다는 사실을 알게 됐다. 돌이켜보면, 코드를 승인한 순간 이미 잘못된 방향으로 들어선 셈이었다. 프롬프트에는 “카테고리 필터를 만들어 달라” 는 요청만 있었고, URL 상태로 관리해야 한다는 제약은 담겨 있지 않았다. 그 제약을 프롬프트에 넣어야 한다는 판단 자체가 애초에 빠져 있었다.

코드 한 줄 수정으로 끝나지 않았다

로컬 상태를 기준으로 엮여 있던 로직을 하나씩 찾아 쿼리 파라미터 기반으로 바꿔야 했다. 상태 관리 방식 자체를 다시 설계하는 작업이었다. 로컬 상태는 컴포넌트 트리 안에서 자유롭게 읽고 쓰면 끝이었지만, URL 상태는 라우팅 계층을 거쳐야 했다. 값을 어디서 가져오는지에 대한 가정 자체가 바뀌다 보니, 필터를 참조하던 곳마다 그 가정을 하나하나 다시 확인해야 했다.

그 위에서 필터와 정렬 조합이 정상적으로 동작하는지도 다시 확인해야 했다. 처음부터 URL 상태로 설계했다면 들지 않았을 비용이다.

이번에는 개인 프로젝트라 이슈 공유나 승인 절차 없이 바로 고칠 수 있었다. 팀 프로젝트였다면 사정이 다르다. 문제를 발견한 사람이 이슈를 공유하고, 담당자를 찾아 원인과 수정 범위를 설명하는 절차부터 거쳐야 한다. 그 뒤에는 코드 리뷰와 QA, 배포 승인까지 이어진다. 각 단계마다 실제로 일하는 시간보다 다음 사람 차례를 기다리는 시간이 더 크다. 이슈가 담당자에게 배정되기까지, 리뷰어가 PR을 확인하기까지, QA 일정에 들어가기까지 매 단계가 대기열에 줄을 서는 일이다.

필터 하나를 고치는 데도 이 정도의 과정이 필요하다. 단순한 필터 문제를 넘어 더 큰 범위의 문제였다면, 관련 정책을 다시 정의해야 했을 수도 있고 기획이나 디자인과의 조율까지 필요했을 것이다. 고민 없이 내린 승인 한 번이, 결국 여러 사람이 각자의 시간을 나눠 투입해야 하는 큰 문제로 돌아온다.

시간을 어디에 더 쓸 것인가

작업에 드는 시간을 세 갈래로 나눠보면 방향을 잡는 고민 시간과 실제로 만드는 구현 시간, 그리고 방향이 잘못됐을 때 뒤늦게 붙는 추가 수정 시간으로 나뉜다. 이 중 구현 시간은 AI 덕분에 확실히 줄었지만, 그렇다고 전체 시간이 줄어드는 건 아니다. 방향을 잘못 잡으면 그만큼이 고스란히 추가 수정 시간으로 돌아오기 때문이다.

고민 시간은 판단 하나에 드는 비용이지만, 추가 수정 시간은 그 판단을 놓쳤다는 사실을 알아차리는 시간부터 원인을 추적하고 코드를 고치고 다시 검증하는 시간까지를 모두 합친 비용이다. 같은 문제를 다루더라도 후자가 구조적으로 더 클 수밖에 없다.

로컬 상태 사례에서 방향을 정하는 데 들인 시간은 없었다. 필터 상태를 어디에 둘지 고민하지 않은 채, AI가 내놓은 코드를 그대로 받아들였기 때문이다. 반면 뒤따라온 추가 수정 시간은 코드 수정과 재검증은 물론, 이슈 공유부터 배포 승인까지 대기열을 도는 과정까지 합쳐 몇 배로 불어났다. 발견하는 데도 계기가 필요했고, 원인을 추적한 뒤에야 로직을 다시 설계했고, 그 위에 필터와 정렬 조합까지 재검증했다. 판단 한 줄이면 끝났을 일이 네 단계로 늘어난 셈이다.

그때 필요했던 고민 시간은 몇 분이 전부였다. 로컬 상태로 관리해도 되는지, 프롬프트에 그 판단 한 줄만 넣으면 충분했다.

고민 시간을 늘리는 게 손해처럼 느껴질 수 있지만, 이 시간은 경험이 쌓이면서 함께 줄어드는 값이다. 어떤 문제를 어떻게 풀어야 하는지가 쌓일수록 같은 방향을 잡는 데 드는 시간은 눈에 띄게 짧아진다. 처음 겪는 문제 앞에서만 시간을 조금 더 쓰게 되는 구조로 바뀌는 것이다.

한 번 겪은 문제는 “이번에도 URL 상태로 관리해야 하는가” 같은 구체적인 질문으로 남는다. 다음번에는 그 질문에 답만 하면 되니, 처음부터 다시 고민할 필요가 없어진다. 그렇다면 지금 늘려야 할 건 고민 시간이고, 줄여야 할 건 추가 수정 시간이다. 당장은 시간을 더 쓰는 쪽처럼 보여도, 그 시간이 막아주는 건 몇 배로 불어나는 수정 비용이다. 지금 들이는 몇 분이, 나중에 치를 몇 배를 대신할 것이다.

정리하며

방향을 잡는다는 말이 거창하게 들릴 수 있다. 하지만 실제로는 구현 전에 필요한 질문을 던지는 일에 가깝다. 앞서 다룬 URL 상태 문제도 그중 하나일 뿐, 어떤 결정이든 던지는 시점이 늦을수록 되돌리는 비용은 커진다.

뒷단에서는 이미 문제가 코드와 화면에 반영되어 있다. 발견하고, 원인을 추적하고, 로직을 고치고, 다시 검증하는 네 단계를 그대로 거쳐야 한다. 이미 그 결정 위에 다른 코드가 의존하고 있어, 하나를 바꾸면 그 위에 얹힌 것들까지 함께 흔들리기 때문이다.

반면 앞단에서는 아직 아무것도 굳어지지 않았다. 상태를 어디에 둘지, API를 어떤 스키마로 설계할지, 컴포넌트의 책임을 어디까지 둘지 같은 질문은 아직 그 결정을 참조하는 코드가 없어 방향만 바꾸면 그만이다. 결국 방향을 잡는다는 건 같은 질문을 던지는 시점을 뒷단에서 앞단으로 옮기는 일이다.

그 지점을 옮기는 일만큼은, AI가 대신해주지는 않는다. 개발자가 시간을 써야 할 곳은 코드를 작성하는 순간이 아니라, 코드가 작성되기 전에 질문을 던지는 순간이다. 무엇을 만들지, 어떤 기준으로 만들지, 그 결정이 어디까지 영향을 미칠지 판단하는 일은 여전히 사람의 몫이다. AI는 프롬프트와 결과물이 일치하는지만 확인할 뿐, 그 프롬프트가 맞는 방향인지 확인하는 자리에는 다른 누구도 없기 때문이다.

AI가 구현을 대신해주는 범위가 넓어질수록, 우리는 더 앞단에서 방향을 결정해야 한다. 결국 AI 시대의 개발자는 코드를 빠르게 만드는 사람보다, 잘못된 방향으로 코드를 만들지 않는 사람에 가깝다.