Loki 's Blog

들어가며

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

문제는 그 다음이다. 잘못된 방향을 인지하지 못한 채 승인 버튼을 누르면 그 순간 잘못된 설계 위에서 동작하는 코드가 그대로 만들어진다. 정작 화면은 문제없이 뜨고, 요청한 기능도 정확히 그대로 동작한다. 코드가 돌아간다는 사실이 방향이 맞다는 확신으로 착각되기 때문에, 오히려 설계가 잘못됐다는 사실을 더 늦게 알아차리게 된다.

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

결국 지금 개발자에게 필요한 건 방향을 잘못 잡지 않도록 미리 고민하고 설계하는 능력이라고 생각한다. 코드를 얼마나 빨리 짜느냐보다, 그 코드가 향할 방향을 얼마나 제대로 잡느냐가 더 중요해진 것이다.

잘못된 설계가 불러온 비용

이전에 SEO를 연습해보려고 토이 프로젝트를 하나 만들었다. 목록 페이지의 카테고리 필터 구현을 AI에게 맡겼고, 로컬 상태로 관리하는 코드가 나왔다. 별다른 검토 없이 그대로 승인했다.

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

필터 상태가 URL에 없으니, 어떤 카테고리 URL로 접근해도 서버는 같은 초기 화면을 내려줬다. 사용자가 화면에서 카테고리를 바꿔도 주소는 그대로였고, /products?category=shoes처럼 특정 카테고리 결과를 가리키는 URL도 만들어지지 않았다.

뒤늦게 코드를 다시 들여다보고 나서야, 이 구조가 SEO라는 프로젝트의 목적과 맞지 않는다는 사실을 알게 됐다. 돌이켜보면, 코드를 승인한 순간 이미 잘못된 방향으로 들어선 셈이었다.

문제는 필터 코드 하나가 아니었다. 로컬 상태를 기준으로 엮여 있던 로직을 전부 다시 정리해야 했다. 상태를 읽고 쓰는 흐름을 하나씩 찾아 쿼리 파라미터 기반으로 바꿔야 했고, 이는 단순한 수정이라기보다 상태 관리 방식 자체를 다시 설계하는 작업에 가까웠다.

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

이번에는 개인 프로젝트라 빠르게 수정하고 넘어갈 수 있었다. 팀과 함께 만드는 프로젝트였다면 이야기가 달랐을 것이다. 문제를 발견한 사람이 이슈를 공유하고, 담당자를 찾아 원인과 수정 범위를 설명하는 것부터 시작해야 했다. 그 뒤에는 코드 리뷰와 QA, 배포 일정까지 따라왔을 것이다.

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

시간을 어디에 더 쓸 것인가

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

로컬 상태 사례에서 방향을 정하는 데 들인 시간은 사실상 없었다. 필터 상태를 어디에 둘지 고민하지 않은 채, AI가 내놓은 코드를 그대로 받아들였기 때문이다. 반면 뒤따라온 추가 수정 시간은 코드 수정과 재검증, 조직을 거치는 과정까지 합쳐 몇 배로 불어났다.

그때 필요했던 건 대단한 고민이 아니라, 딱 몇 분이었다. 로컬 상태로 관리해도 되는지, 그 판단 한 번이면 충분했다. 몇 분을 들여 방향을 정하는 쪽이, 뒤에 붙는 수정 시간을 통째로 없애는 쪽보다 나은 선택이다. 구현이 빨라진 지금은 이 차이가 훨씬 크게 벌어진다.

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

그렇다면 지금 늘려야 할 건 고민 시간이고, 줄여야 할 건 추가 수정 시간이다. 당장은 시간을 더 쓰는 쪽처럼 보여도, 그 시간이 막아주는 건 몇 배로 불어나는 수정 비용이다. 지금 들이는 몇 분이, 나중에 치를 몇 배를 대신할 것이다.

정리하며

방향을 잡는다는 말이 거창하게 들릴 수 있다. 하지만 실제로는 구현 전에 필요한 질문을 던지는 일에 가깝다. 같은 질문이라도 언제 던지느냐에 따라 결과는 달라진다. 문제가 터진 뒤에야 묻는다면, 그때부터는 설계가 아니라 수습이 된다.

뒷단에서는 이미 문제가 코드와 화면에 반영되어 있다. 관련 로직을 다시 수정하고, 영향을 받은 부분을 확인하고, 결과를 검증해야 한다. 반면 앞단에서는 아직 아무것도 굳어지지 않았다. 문제를 발견해도 방향만 바꾸면 된다.

앞단에서 몇 분을 들여 던진 질문이, 뒷단에서 발생할 몇 배의 수정 비용을 막는다. 결국 방향을 잡는다는 건 같은 질문을 던지는 시점을 뒷단에서 앞단으로 옮기는 일이다.

개발자가 시간을 써야 할 곳은 코드를 작성하는 순간이 아니라, 코드가 작성되기 전에 질문을 던지는 순간이다. 무엇을 만들지, 어떤 기준으로 만들지, 그 결정이 어디까지 영향을 미칠지 판단하는 일은 여전히 사람의 몫이다.

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