툴을 만들게 된 배경은 생각보다 단순했다.

광고회사에 속해있는 우리 팀은 인원이 많지 않고, 주 업무는 UX/UI 컨설팅이다.

​

그런데 어느 순간부터 SEO 진단 요청이 눈에 띄게 늘기 시작했다. SEO 자체가 낯선 영역은 아니었지만,(광고회사에 속한 UX/UI팀의 특성이기도 할 것 같다.) 문제는 요청이 한두 건이 아닐 때였다.

​

SEO 업무가 한꺼번에 몰리면 원래 해야 할 UX/UI 컨설팅 일정에 차질이 생기기 시작했다. 이 상황이 반복되다 보니 자연스럽게 이런 질문이 들었다.

"이걸 계속 사람이 처리하는 게 맞을까?"

반복되는 SEO 진단, 비슷해지는 결과

​

SEO 진단 요청이 많아질수록 결과의 형태도 거의 비슷해졌다. 페이지는 달라도 확인하는 기준은 늘 같았다.

네이버 서치어드바이저 가이드와 일부 발표된 애드부스트 정보를 기준으로 HTML 구조를 하나하나 대조하고, 오가닉 검색과 광고 확장검색 관점에서 문제가 되는 지점을 정리하는 일의 반복이었다.

​

여기에 또 하나의 요구가 더해졌다.

여러 팀에서 자신들이 제안서에 바로 쓰기 좋은 하나의 템플릿에 맞춰 결과를 정리해주길 바랐다.

이쯤 되니 이런 생각이 들었다.

불과 몇년 전만 해도 어려웠던 일

불과 몇년 전만 해도 이런 시도는 현실적으로 쉽지 않았다. 네이버 SEO 가이드는 분명 존재했지만, 실제 페이지를 기준으로 진단하려면 사람이 직접 가이드를 읽고, HTML을 보고, 항목을 하나씩 대조할 수밖에 없었다. 또 HTML이나 웹 개발에 지식이 없는 사람은 가이드를 이해하는 것 부터가 난관이었다.

​

그래서 우리팀은 오래전 부터 이 업무를 효율적으로 처리하기 위해 많은 노력을 했지만 자동화라고 해봐야 결국 가이드를 정리한 문서를 만드는 수준에 머물렀기에 효과가 매우 미미했다.

개발의 시작점, 바이브코딩 실험

​

IT관련 업무를 하며, 바이브코딩이 도대체 무엇인가?

궁금하기도 하고 한편으로는 개발을 거의 모르는 내가 해볼 수 있는 작업인지 왠지 모를 두려움에 쉽사리 시도해보지 못하고 있던 분야(?) 였다.

​

하지만 툴 개발은 아주 단순한 프롬프트에서 시작했다.

우연히 알게 된 AI툴 '마누스'에서 그냥 이런 툴을 만들 수 있을지 물어보는 것 뿐이었다.

“나는 광고회사에서 일하는 UX/UI 팀이고,

SEO 진단 툴을 만들고 싶다. 사용자가 홈페이지 url를 입력하면 해당 HTML 구조가 네이버 서치어드바이저/애드부스트 기준으로 상위 노출에 적합한지 진단하고,

오가닉 검색과 광고 확장검색 두 기준에서 개선할 점을 도출해주는 툴을 만들고 싶은데 가능할까?”

​

프롬프트 한마디로 마누스는 이 툴을 만드는게 가능한지, 어떻게 만들 수 있는지, 얼만큼의 일정이 소요되는지 등 기획문서 하나를 뚝딱 만들었다.

​

그리고 여기에 몇 가지 조건을 내 입맛대로 입력했다.

• 모든 기준은 네이버 서치어드바이저와 공식 가이드만 사용할 것

• 개선 방안은 근거 가이드가 필수적으로 있을 것

• 진단 결과는 체크리스트 형태로 노출할 것

이렇게 AI와 대화하다보니 툴의 기본 구조는 생각보다 빠르게 만들어졌다.

AI의 시대, 업무 방식이 바뀌었다

​

AI가 실무에 들어오면서 우리는 비로소 의미있는 자동화를 시작해 볼 수 있게 되었다!

이번에 만든 SEO 진단 툴은 네이버 서치어드바이저와 공식 가이드를 기준으로 삼아, 사용자가 입력한 홈페이지 링크의 HTML 구조를 분석하고 해당 페이지의 오가닉 검색과 광고 확장검색 두 관점에서 가이드 충족 여부를 체크리스트 형태로 판단해주는 방식으로 설계했다.

중요한 점은, 이 툴이 사람처럼 맥락을 해석하거나

책임지는 판단을 대신해주는 도구는 아니라는 점이다.

이 툴이 하는 일은 이미 정해진 공식 기준을 빠짐없이 대조해주는 것에 가깝다.

문서를 거의 쓰지 않은 개발 방식

​

이 툴을 만들면서 나는 기획서도, IA도, 유저 플로우도,

와이어프레임도 따로 작성하지 않았다. 물론 이 툴이 내부용이고 시범 성격의 프로젝트였기 때문에 가능했던 방식이긴 하다.

그럼에도 불구하고, 기존 서비스 개발에서 당연하게 여겼던 문서들이 이번 과정에서는 거의 필요하지 않았다.

내가 실제로 작성한 건 문제 정의 몇 줄/PRD(GPT로 작성)/ 일부 정책과 고려사항 정도였다.​

이마저도 정제된 문서 형태가 아니라 상당히 러프한 말투로 전달했고, 구조화와 가공은 대부분 AI가 맡았다.

사람이 해야 했던 일은 따로 있었다

아이러니하게도 문서 작업은 줄었지만, 사람이 고민해야 할 영역은 더 또렷해졌다.

​

AI를 검증하기 위해

• 사용자 시나리오와 니즈를 직접 정리했고

• 결과가 어긋나는 지점을 체크했고

• 예외 케이스를 계속 추가했다.

​

이 과정을 거치며 느낀 건, 정말 중요한 건 형식을 위한 문서가 아니라 꼼꼼한 기획, 정책 정의, 그리고 예외에 대한 판단이라는 점이었다.

형식보다 중요한 건 ‘명령의 정확도'라는 생각이 들었다.

• 무엇을 시키고 싶은지

• 어디까지 허용할지

• 무엇을 절대 하면 안 되는지

이걸 얼마나 구체적이고 정확하게 명령할 수 있는지가

결과를 훨씬 크게 좌우했다. 문서가 사라진 게 아니라,

문서의 역할이 프롬프트와 정책으로 압축된 느낌에 가깝다.

혼자에게 적합한 방식, 팀에는 효율적인 결과

​

비록 찍먹 실험에 가까웠지만 바이브코딩이나 AI를 활용한 개발 방식은 협업보다는 혼자에게 더 잘 맞는 방식이라는 생각이 들었다.

​

내가 어디까지 만들었고, 어떤 의도로 설계했는지는

결국 나만 알고 있다. 중간에 다른 사람이 손을 대면

오히려 구조가 꼬이거나 수정 비용이 더 커질 가능성도 있었다.

다만 결과적으로는 팀 전체의 업무 효율은 분명히 올라갔다. 개발 지식이 없는 팀원들도 프롬프트를 통해

즉시 사용자 요구사항 반영이 가능했고, 유지보수 역시 수월했다. 결과적을 이 툴을 통해 업무 하나가 거의 줄어든 셈이다.

AI를 쓰면서, 오히려 사람이 해야 할 일이 더 또렷해졌다.

​

이번 경험을 통해 UX/UI의 역할에 대해서도 다시 생각하게 됐다. 피그마(AI로 멋진 디자인을 뚝딱 만들어 주더라..)도 그렇고, 각종 기획 문서들도 그렇고, 이제는 무엇을 꼼꼼하게 작성하거나 예쁘게 만드는 일 자체가 UX/UI의 핵심 역할은 아니게 된 것 같다.

​

형식이나 산출물은 AI가 훨씬 빠르고, 일정 수준 이상으로 만들어줄 수 있다. 대신 앞으로 더 중요해질 역량은

• 스스로 해야 할 과업을 정의할 수 있는지

• 전체 일을 어떻게 나눌지 판단하고, 스케줄을 짜서

• 최대한 효율적으로 밀어붙일 수 있는지

그리고 그 효율 속에서도 반드시 사람이 체크해야 할 지점이 무엇인지 알고, 놓치면 안 되는 부분을 명확히 알고 있는지인 것 같다.

(말하고보니 PM이 하는 일의 대부분...)

​

바이브코딩? AI를 가지고 놀며 느낀점

​

이번 프로젝트가 제대로 된 바이브코딩인지 분명하게 말할 수는 없지만 이를 통해 느낀 점도 많다.

우선 한계도 분명하는 점, 로그인 기능이 붙거나(개인정보 수집) 더 정교한 판단과 평가가 필요해지면, 결국 별도의 개발이 필요해진다.

개발을 모르는 나는 지금도 여전히 버그를 잡고 있고, 이 디버그 전쟁은 아직 끝나지 않았다. 그럼에도 불구하고, 첫 시도로는 충분히 의미 있는 결과라고 느낀다.

​

앞으로도 업무를 하다 불편한 지점이 보이면 이 정도 규모의 가벼운 툴 개발은 계속 시도해볼 생각이다. 이 과정을 반복하다 보면 언젠가는 꽤 쓸모 있는 툴이나, 어쩌면 돈이 되는 툴도 나오지 않을까, 그 정도의 기대는 해본다.

​

chat GPT, 클로드, 마누스 AI등 여러 툴을 함께 사용해보면서 느낀 점도 있다. AI 툴은 정보를 보고 비교해서 고르는 것 보단, 쓰다 보면 나와 맞는 도구를 발견하게 되는 것에 가깝다는 점이다.

마누스는 충분히 좋은 파트너였지만, 크레딧 제한이 커

개발 과정에서는 항상 신중할 수밖에 없었다.

그래서 프롬프트 하나하나를 더 고민하게 됐고, 어쩌면 그 점이 이 툴을 더 진지하게 만들게 한 이유였는지도 모르겠다.

​

(활용해보고 싶다면 아래 링크로 가입하시길,

1500크레딧을 받을 수 있다.)