AI+UX 이론과 실전 사이
솔직하게 고백하는 것으로 시작하겠다.
나는 1995년부터 웹을 만들었다.
지금처럼 드래그 앤 드롭 툴이 없던 시절, HTML 태그를 한 줄 한 줄 직접 타이핑 하면서 페이지를 만들었다. 당시엔 그걸 '날코딩'이라고 불렀다. 디자인과 코딩이 분리되지 않았고, 머릿속에 그린 레이아웃을 코드로 직접 구현하는 것이 웹디자이너의 일이었다.
그 시절이 내 출발점이다. 그런데 언젠가부터 나는 강의실에 있었다.
AI+UX 혁신 전략을 이야기하고, 디자인 주도 혁신을 설명하고, AI 시대의 업무 방식 변화를 강연했다. 그렇지만 사실상 나는 ‘직접 만드는 일’에서는 멀어져 있었다.
어느 순간부터 마음 한 구석에서 떳떳하지 못하다는 인식이 나를 뒤로 끌어당기기 시작했다.
"AI로 이렇게 달라질 거예요", "이렇게 활용해야 합니다"라고 말하면서,
정작 나는 AI로 뭔가를 실제로 만들어볼 생각을 하지 못했다는 것을 깨달았다.
물론 AI를 도구로 이런저런 테스트를 해 본 적은 있었다.
텍스트를 생성하고, 이미지를 만들어보고.
그런데 프로젝트를 — 처음부터 끝까지, 실제로 서비스되는 무언가를 — AI와 함께 완성한 경험은 하지 못하고 있었다.
죄책감이라고 부르기엔 거창하고, 불안이라고 부르기엔 조용했다.
굳이 표현하자면, 현장을 떠난 강연자의 무력감이 만드는 마음의 짐 같은 것이었다.
“나는 지금 내가 직접 확인하지 않은 것을 이야기하고 있는 건 아닌가.”
그 질문이 이 프로젝트를 시작하게 만들었다.
마침 운영 중인 디노베이션 파트너스 홈페이지도 오래 손을 못 대고 있었다. 리뉴얼이 필요했다.
이번이야말로 마음의 짐을 덜어낼 수 있는 기회라고 생각했다.
시작 전에 내 머릿속에는 두 가지 질문이 있었다.
"AI로 진짜 할 수 있나?"
"한다면, 기존 방식과 뭐가 다른 건가?"
95년 무렵, 웹디자이너 시절의 나라면 이렇게 했을 것이다.
- 머릿속으로 레이아웃을 그리고,
- HTML을 열고, <table> 태그로 격자를 짜고,
- 픽셀 단위로 위치를 잡는다.
코드가 곧 붓이었다. 구현하면서 동시에 디자인했다.
지금은 어떻게 다를까?
클로드의 프로젝트 기능을 열고, 처음은 코드 한 줄 없이 대화만 했다.
과거에 새 프로젝트를 시작할 때는 텍스트에디터인 SimpleText를 열었다.
지금은 대화를 시작한다.
"이 홈페이지를 찾아오는 사람이 누구인가?"
"그 사람이 어떤 판단을 내려야 하는가?"
"그 판단을 돕기 위해 어떤 순서로 무엇을 보여줘야 하는가?"
이걸 클로드와 함께 정리했다.
나는 강의에서 늘 이렇게 말해왔다.
"AI에게 맥락을 잘 전달하는 것이 핵심입니다." 맞는 말이다.
그런데 막상 해보니, 내가 강의에서 말한 '맥락'은 너무 가볍게 설명되고 있었다.
단순히 프롬프트를 잘 쓰는 문제가 아니었다.
클로드의 프로젝트 기능은 대화의 맥락을 기억하고 축적한다.
첫 대화에서 공유한 회사의 결, 방문자 유형, 원하는 어조가 이후 모든 작업의 기준점이 된다.
대화가 쌓일수록 클로드는 단순히 지시를 수행하는 것이 아니라 이 프로젝트의 방향을 함께 이해하는 쪽으로 달라졌다. 맥락의 축적이 곧 협업의 질을 결정했다.
앞으로 강의에서는 이 부분을 더 강조해야겠다고 생각했다.
좋은 프롬프트 한 줄이 아니라, 좋은 맥락을 쌓아가는 대화의 설계가 AI 협업의 진짜 핵심이라는 것을.
클로드는 이 대화에서 한 가지 프레임을 제안했다.
B2B 고관여 의사결정자가 홈페이지를 볼 때 거치는 신뢰의 세 단계 —
- 누가 운영하는가?
- 무엇을 해왔는가?
- 무엇을 할 수 있는가?
이 구조가 전체 IA의 뼈대가 됐다.
과거 방식이라면 이 단계를 내가 혼자 고민했을 것이다. 아니면 기획자와 회의를 했을 것이다.
지금은 대화 상대가 생겼다. 밤 11시에도 피곤하지 않은, 어떤 직원도 대신할 수 없는 대화 상대가.
구조가 잡히자 본격적인 코딩이 시작됐다.
index.html부터 시작해서 각 페이지를 순서대로 완성해 나갔다.
- 네이비와 블루 기반의 컬러 시스템,
- Pretendard 폰트,
- 스크롤 애니메이션,
- 스티키 헤더,
- 모바일 햄버거 메뉴.
- 서비스 페이지에는 탭 내비게이션을 달고,
- 인사이트 페이지에는 뉴스레터 아카이브와 브런치 연재 탭을 구성했다.
예전 방식으로 하면 어땠을까?
- 아마 각 파일을 열고,
- CSS를 짜고,
- 기능 하나를 구현하면
- 다음 기능으로 넘어갔을 것이다.
온전히 혼자, 머릿속과 손가락 사이를 왔다 갔다 하면서.
그리고 솔직히 말하면,
디자이너 출신인 나의 코드는 전문 개발자의 그것보다 무겁고 복잡한 구조였다.
기능은 같아도 코드의 품질은 달랐다.
지금은 다르다. 클로드가 코드를 제안하면 나는 읽는다. 읽으면서 판단한다.
- 이 방향이 맞는가?
- 이 구조가 우리 브랜드와 맞는가?
- 이 컴포넌트가 모바일에서도 의도대로 작동하는가?"
여기서 내가 발견한 결정적 차이가 있다.
과거엔 '어떻게 만드는가'가 작업의 중심이었다.
지금은 '무엇을 만들어야 하는가'가 중심이 된다.
나는 강의에서 이 말을 자주 했다.
"AI 시대에는 실행보다 기획이 중요해집니다." 틀린 말은 아니었다.
그런데 막상 직접 해보니 그 말이 얼마나 피상적으로 전달되고 있었는지 깨달았다.
구현의 병목이 사라지는 순간,
기획과 판단의 무게는 단순히 '중요해지는' 수준이 아니라 그것이 작업의 전부가 된다.
클로드는 내가 방향을 잘못 잡아도 만들어준다.
틀린 방향으로 완성도 높게.
무엇을 만들지 판단하지 못하면, AI는 그냥 잘못된 것을 빠르게 만들어주는 도구가 될 뿐이다.
앞으로는 이렇게 말해야겠다.
"기획이 중요해진다"가 아니라,
"기획을 못 하면 AI를 쓸수록 더 빠르게 잘못된 방향으로 간다"라고.
물론 순탄하지만은 않았다.
PHP 백엔드를 구성할 때, 서버에 올리면 파일 경로가 맞지 않아 오류가 났다. $_SERVER['DOCUMENT_ROOT']로 동적으로 경로를 잡으려 했는데 서버 환경이 달랐다.
예전이었다면 직접 서버 설정을 뒤지고, 개발자 커뮤니티를 검색하고, 시행착오를 거쳤을 것이다.
이번엔 에러 메시지를 클로드에게 공유했다.
원인 분석이 나왔고, 절대 경로 하드코딩으로 해결하는 방안이 제시됐다.
개발자라면 더 나은 방법을 알았을지 모른다. 나는 일단 작동하는 쪽을 택했다.
그래도 30년 전 날코딩의 경험이 있었기에, 클로드가 하는 말이 무슨 뜻인지는 알아들을 수 있었다.
이 대목에서 다시 한번 실감했다.
나는 강의에서 "AI는 도구가 아니라 협업자입니다"라고 말해왔다.
이번에 그 말의 의미가 좀 더 구체적으로 다가왔다.
협업자라는 건 내가 아무것도 몰라도 된다는 뜻이 아니다. 오히려 반대다.
협업자의 제안이 맞는지 틀린 지를 판단하려면 내가 먼저 충분히 알아야 한다.
30년 전의 웹 경험이라도 없었다면 클로드의 제안이 옳은지조차 판단하기 어려웠을 것이다.
"AI는 누구나 쉽게 쓸 수 있다"는 말을 나도 해왔다.
틀린 말은 아니지만, 지금은 조금 다르게 말하고 싶다.
AI는 누구나 시작할 수 있지만, 잘 쓰려면 판단할 수 있는 사람이어야 한다.
도메인 경험과 맥락 이해가 AI 협업의 전제조건이라는 것을,
이번에 몸으로 확인했다.
마지막 날, 나는 코드보다 콘텐츠에 더 많은 시간을 썼다.
- 어떤 파트너를 어떤 순서로 소개하는가?
- 서비스 가격을 ‘숫자’로 명시할 것인가? ‘문의 후 협의’로 남길 것인가?
- 메인 첫 문장이 방문자를 멈추게 만드는가?
- 뉴스레터 아카이브의 썸네일이 콘텐츠의 신뢰도를 올리는가?
이 질문들은 클로드와 함께 풀었지만, 답은 브랜드에 대한 나의 이해에서 나왔다.
그리고 여기서 나는 한 가지를 더 확인했다.
AI는 내가 명확하게 생각할수록 더 잘 작동한다.
모호하게 던지면 그럴듯하지만 어딘가 빗나간 결과가 나온다.
"이 페이지를 보는 사람이 누구고, 이 섹션에서 무엇을 느껴야 하고, 다음에 어떤 행동을 해야 하는지"를 구체적으로 설명할수록 결과물이 달라진다.
나는 UX 강의에서 항상 이렇게 말한다.
"사용자를 먼저 생각하라."
AI와 일하면서 이 원칙이 AI에게도 그대로 적용된다는 걸 알았다.
AI와의 협업에서 '사용자'는 곧 '최종 독자'고, 그 독자를 내가 얼마나 선명하게 그리고 있는지가 AI가 만들어내는 결과의 질을 결정했다.
UX의 원리가 AI 협업에도 그대로 통한다는 것.
이건 강의에서 더 강하게 말해도 좋겠다.
과거의 날코딩은 손의 기술이었다.
지금의 AI 코딩은 생각의 기술이다.
5개 페이지, 구독 시스템, 관리자 페이지, PHP 백엔드. 모두 실제 서버에 올라가서 작동하고 있다.
하지만 내가 이 프로젝트에서 정말 확인하고 싶었던 건 완성된 홈페이지가 아니었다.
"AI로 진짜 만들 수 있나?"
— 할 수 있다. 그런데 조건이 있다. AI에게 좋은 질문을 던지려면 내가 먼저 좋은 기획자여야 한다.
"기존 방식과 무엇이 달라졌나?"
— 구현의 병목이 사라졌다. 대신 '무엇을'과 '왜'를 생각하는 일이 작업의 전부가 됐다. 이건 내가 강의에서 말해온 것과 방향은 같지만 무게가 달랐다. 중요해지는 정도가 아니라, 그것이 전부가 된다.
"강의한 것과 실제는 달랐나?"
— 방향은 맞았다. 그런데 실제로 해보니, 내가 말해온 것들이 얼마나 피상적인 언어로 전달되고 있었는지를 알게 됐다. 그 묵직한 마음의 짐은 한결 가벼워졌지만, 대신 새로운 숙제가 생겼다. 더 실감 있는 언어로, 더 구체적으로 말해야 한다는 것.
AI 시대에 디자이너와 기획자의 역할이 사라진다는 이야기를 많이 한다.
나는 이번 경험에서 반대의 확신을 얻었다.
AI가 구현을 담당할수록, 무엇을 왜 만드는지를 생각하는 능력의 가치가 올라간다.
그리고 그 능력은 경험과 도메인 이해 위에서만 작동한다.
1995년 무렵, 날코딩이 내게 가르쳐준 것도 결국 그것이었다.
코드를 짜는 능력이 아니라, 코드로 무엇을 표현할 것인지를 생각하는 훈련.
30년이 지나, 도구가 바뀌었다. 그러나 생각의 자리는 그대로다.
다만 한 가지는 덧붙이고 싶다.
AI+UX를 이야기하는 사람이라면, 한 번은 직접 만들어봐야 한다.
이론은 현장을 만나야 비로소 단단해진다.
이 글은 클로드의 프로젝트 기능을 활용해 dinnovation.kr을 리뉴얼한 실제 경험을 바탕으로 씁니다.
다음에는 구체적으로 어떤 방식으로 대화하고 무엇을 판단했는지를 더 자세히 다뤄볼 예정입니다.