AI 코딩 도구를 쓸 때 사람이 정해야 하는 것

AI에게 맡기면 안 되는 판단

AI 코딩 도구는 구현 속도를 올려준다. 이건 부정하기 어렵다. 하지만 무엇을 만들지, 어디까지 만들지, 어떤 상태를 완료로 볼지는 대신 정해주지 못한다. 특히 작은 웹서비스에서는 기능을 더하는 능력보다 빼는 판단이 중요하다.

예를 들어 랭킹, 댓글, 로그인은 모두 그럴듯한 기능이다. 만들고 싶다. 솔직히 버튼 하나만 더 누르면 만들 수 있을 것처럼 보인다. 하지만 첫 목표가 콘텐츠와 Play라면 지금은 제외하는 것이 맞다. 기능을 미루는 것은 포기가 아니라 검증 순서를 지키는 일이다.

사람이 잡아야 하는 기준

• - 이 페이지가 왜 존재하는지
• - 사용자가 첫 10초 안에 무엇을 할지
• - 서버 없이 정적으로 가능한지
• - 검색엔진에 제출할 만큼 완성되었는지
• - AI가 만든 코드가 실제 운영 조건을 통과했는지
• - 다음 콘텐츠를 더 빨리 만들 수 있는 구조인지

AI는 선택지를 늘린다. 사람은 선택지를 줄인다. 이 역할을 헷갈리면 프로젝트는 빠르게 커지지만 목적은 흐려진다. bobob.app의 1차 목표도 그래서 작게 잡았다. 개발과 AI 글을 쓰고, 관련된 가벼운 Play를 붙여 반응을 본다.

맡길 일과 남길 일

이 구분을 하지 않으면 "많이 만들었다"가 목표가 된다. 지금 bobob.app에 필요한 것은 많이 만든 흔적보다 직접 운영하는 흔적이다. 글이 짧으면 묶고, Play가 비슷하면 시각적 은유를 다시 잡고, sitemap이 넓으면 줄인다. 이런 결정은 AI가 대신 내리기 어렵다.

결정이 필요한 순간들

AI가 제안한 것을 그대로 받아들이면 프로젝트는 늘어난다. 그래서 나는 아래 순간에는 반드시 사람이 멈춰서 결정해야 한다고 본다.

이 질문을 통과하지 못하면 만들 수 있어도 미룬다. 미루는 일은 소극적인 선택처럼 보이지만 작은 사이트에서는 적극적인 품질 관리다. 지금의 bobob.app은 모든 기능을 보여주는 곳이 아니라, 직접 만든 글과 작은 Play가 서로 이어지는지 확인하는 곳이다.

마지막에 사람이 읽어야 하는 문장

AI가 만든 문장은 종종 너무 매끈하다. 반대로 내가 급하게 쓴 문장은 너무 내부 사정처럼 들릴 때가 있다. 대표 글에는 둘 다 남기면 안 된다. 방문자가 알아야 할 것은 "이 사람이 어떤 판단을 했고, 지금 무엇을 확인했는가"다. 그래서 대표 글에는 표, 체크리스트, 검증 경로를 넣고, 짧은 제작 메모는 하나의 로그로 묶는다.

대표 글을 읽을 때는 몇 가지를 본다. 한 문단이 키워드만 나열하고 있지 않은지, 표가 실제 판단을 도와주는지, 체크리스트가 다음 행동으로 이어지는지, 관련 Play가 억지로 붙어 있지 않은지 본다. AI가 문장을 매끄럽게 만들 수는 있지만, 이 글이 왜 이 사이트에 있어야 하는지는 사람이 설명해야 한다.

no라고 말한 기능들

• - 계정 저장은 뺐다. 지금은 사용자가 바로 눌러보고 결과를 보는 흐름이 더 중요하다.
• - 댓글도 뺐다. 운영자가 감당할 수 없는 공개 입력면은 작은 사이트의 신뢰를 빠르게 흔든다.
• - 랭킹도 뺐다. 점수 경쟁보다 글에서 말한 판단을 손으로 확인하는 것이 먼저다.
• - 서버 상태 저장도 뺐다. 정적 배포와 브라우저 상호작용만으로 검증 가능한 구조를 우선했다.
• - 모든 글 sitemap 제출도 뺐다. 짧은 제작 메모는 archive/noindex 후보로 두고, 대표 글만 공개 신호로 보낸다.

이 목록은 나중에 절대 하지 않겠다는 뜻이 아니다. 지금 하지 않는다는 뜻이다. AI 도구가 빨라질수록 “나중에 해도 되는 것”을 지금 섞지 않는 일이 더 중요해진다.

바로 해보기

프롬프트 재료 나누기는 사람의 역할을 작은 게임으로 만든다. 목적, 맥락, 제약을 구분하는 순간 AI에게 맡길 일과 사람이 정할 일이 분리된다.

실제 프로젝트에서 갈라지는 순간

AI 코딩에서 가장 헷갈리는 순간은 “가능하다”와 “지금 해야 한다”가 섞일 때다. 로그인도 가능하고, 랭킹도 가능하고, 댓글도 가능하다. 하지만 가능하다는 이유만으로 넣으면 작은 사이트는 금방 설명하기 어려워진다. 사용자는 왜 들어왔는지 잊고, 운영자는 무엇을 검증해야 하는지 잃는다. 그래서 사람의 첫 판단은 구현 가능성이 아니라 지금 목표와의 거리다.

bobob.app에서는 이 기준이 더 분명하다. 지금 필요한 것은 계정 기능이 아니라 원본 글, 직접 만든 Play, 검증 가능한 발견 경로다. AI가 새로운 기능 후보를 많이 내더라도, sitemap에 남길 대표 글과 noindex로 보낼 짧은 메모를 가르는 일은 사람이 한다. 이것은 취향 문제가 아니라 공개 운영 표면을 정리하는 일이다.

검증에서 사람이 읽는 신호

하네스가 녹색이어도 사람이 읽어야 하는 신호가 있다. 제목이 같은 말을 반복하는지, 설명이 실제 경험보다 키워드에 기대는지, 관련 Play가 억지로 붙어 있는지 보는 일이다. 반대로 사람이 느낌만으로 판단하면 놓치는 것도 있다. canonical, robots, sitemap count, feed item count, structured data는 명령으로 확인해야 한다. 결국 좋은 마감은 둘 중 하나가 아니라 둘을 붙이는 일이다.

그래서 완료 판단도 AI에게만 맡기지 않는다. 명령은 사실을 보여주고, 사람은 그 사실이 목표와 맞는지 해석한다. `harness:blog-play-mvp`가 통과해도 대표 글이 실제로 읽을 만한지 다시 본다. `harness:submitted-url-health`가 통과해도 Search Console에서 색인됐다고 말하지 않는다. `색인 생성 요청됨`은 요청일 뿐이고, `discovered pages`는 발견일 뿐이다. 이런 단어를 섞지 않는 것도 사람이 해야 하는 일이다.

AI 코딩의 장점은 빠르게 초안을 만들고 반복을 줄여준다는 점이다. 하지만 공개할 표면을 고르고, 기능을 줄이고, 관찰 기간을 기다리는 일은 느리다. 나는 그 느린 부분이 작은 웹서비스의 품질을 만든다고 본다. 빠르게 만들되 천천히 공개하는 쪽이 지금 bobob.app에 맞다.