코딩 없이 고객 포털 만드는 법

언젠가 모든 프리랜서나 작은 에이전시는 두 번째 직업을 떠안게 됩니다. 바로 고객에게 지금 무슨 일이 벌어지고 있는지 알려 주는 일이죠.

산출물을 마무리하고, PDF를 이메일로 보내는데, 엉뚱한 사람을 참조로 넣습니다. 고객은 오래된 메일 스레드에 답장합니다. 누군가는 인보이스가 어디 있느냐고 묻습니다. 또 다른 누군가는 웹사이트가 다 됐냐고 묻습니다. 월요일 아침에 누가 무엇을 물었고 내가 답을 했는지 안 했는지 파악하는 데만 40분을 씁니다.

고객 포털은 이것을 해결합니다. 고객이 로그인해서 — 프로젝트 상태, 파일, 인보이스, 메시지 등 — 지금 무슨 일이 벌어지는지 당신에게 묻지 않고도 볼 수 있는 한 곳이죠. 예전에는 이런 걸 만들려면 개발자, 6주, 그리고 고객이 스무 명 이상인 에이전시한테나 말이 되는 예산이 필요했다는 게 문제였습니다.

AI 앱 빌더로는 하루 오후면 코딩 없이 고객 포털을 만들 수 있습니다. 방법은 이렇습니다.

고객 포털에 실제로 필요한 것

AI 빌더에게 무언가를 만들어 달라고 하기 전에, “고객 포털”이 구체적으로 무슨 의미인지 알아 두면 도움이 됩니다. 대부분은 보기보다 단순합니다.

핵심만 보면, 고객 포털은 다음을 갖춘 비공개 웹사이트일 뿐입니다.

로그인 — 고객마다 자기 계정이 있고, 자기 프로젝트만 봅니다
프로젝트 상태 페이지 — 지금 어느 단계인지, 무엇이 끝났는지, 다음은 무엇인지
파일 섹션 — 산출물, 계약서, 참고 자료
메시지 스레드 — 아니면 적어도 이메일에 묻혀 사라지지 않도록 메모 섹션이라도

그게 전부입니다. 나머지(인보이스, 시간 추적, 피드백 양식)는 나중에 얹을 수 있는 부가 기능입니다. 이 네 가지부터 시작하면 월요일을 잡아먹던 “우리 지금 어디까지 됐나요?” 질문의 90%를 커버하게 됩니다.

AI 빌더에게 설명하는 법

AI로 만들 때 가장 흔한 실수는 한 번에 너무 많은 것을 요청하는 것입니다. “프로젝트 관리, 인보이스 발행, 파일 공유, 채팅 시스템을 갖춘 고객 포털을 만들어 줘”라고 하면, 테스트하기 어렵고 고치기는 더 어려운 방대한 초안이 나옵니다.

대신, 하나의 사용 사례와 하나의 사용자 유형부터 시작하세요. 이런 식으로 해 보세요.

“제가 관리자로 로그인해서 프로젝트를 만들 수 있는 웹 앱을 만들어 줘. 각 프로젝트에는 이름, 상태(계획 중 / 진행 중 / 검토 중 / 완료), 그리고 메모 필드가 있어. 이메일로 고객을 초대할 수 있고, 고객은 로그인해서 자기 프로젝트와 그 상태, 메모만 볼 수 있어.”

이 설명은 두 문단에 들어가고, 그날 안에 실제로 쓸 수 있는 무언가를 만들어 냅니다. 명확한 데이터 모델(상태와 메모가 있는 프로젝트), 두 가지 사용자 역할(당신과 고객), 그리고 하나의 핵심 제약(고객은 자기 데이터만 본다)을 갖추고 있죠.

그게 작동하면, 거기에 파일을 추가합니다. 그다음 어쩌면 메시지를요. 추가하는 것마다 별도의 요청입니다.

고객 포털에서 진짜 중요한 세 가지

모든 기능이 똑같이 중요하지는 않습니다. 이 세 가지가 고객이 실제로 포털을 쓰느냐, 아니면 계속 당신에게 이메일을 보내느냐를 가릅니다.

1. 로그인은 쉬워야 합니다.

석 달 전에 설정한 비밀번호를 기억해야만 프로젝트 상태를 확인할 수 있다면, 고객은 그냥 당신에게 이메일을 보낼 겁니다. 비기술 사용자에게 가장 좋은 방식은 매직 링크 로그인입니다. 이메일을 입력하면, 링크가 도착하고, 그걸 클릭하면 들어가집니다. 잊어버릴 비밀번호가 없죠.

AI 빌더에게 이렇게 말하세요. “매직 링크 로그인을 써 줘 — 사용자가 이메일을 입력하면 링크를 받고, 그걸 클릭하면 로그인되도록.” 요즘 AI 빌더 대부분은 이걸 명령 한 번으로 연결해 줍니다.

2. 상태는 클릭하지 않아도 보여야 합니다.

고객이 포털을 열었을 때 가장 먼저 보이는 것은 쓸모 있는 무언가여야 합니다. 내비게이션 메뉴가 아니라요. 텅 빈 대시보드도 아니라요. 자기 프로젝트의 상태가, 바로 그 자리에, 명확한 라벨과 함께 보여야 합니다.

“대시보드에서 각 프로젝트를 카드로 보여 주고, 프로젝트 이름과 현재 상태를 눈에 띄게 표시해 줘. 상태는 색으로 구분해 줘. 완료는 초록색, 진행 중은 노란색, 검토 중은 주황색, 계획 중은 회색.”

3. 파일 섹션은 정말로 작동해야 합니다.

고객이 무언가를 다운로드하고, 다른 데에 다시 업로드하고, 확인 메일을 보내야 하는 “파일 공유”는 이메일보다 못합니다. 빌더에게 프로젝트에 파일을 업로드하고 고객이 그걸 바로 다운로드할 수 있게 해 달라고 하세요. 그 이상으로 거창할 필요는 없습니다.

첫날에 할 일

다음은 실제로 통하는 정확한 순서입니다.

프로젝트, 상태, 역할(관리자 + 고객)을 갖춘 기본 앱을 만듭니다.
당신을 관리자로 추가하고, 가짜 프로젝트 하나를 만들고, 가짜 고객 한 명을 추가합니다.
가짜 고객으로 로그인합니다(다른 브라우저나 시크릿 모드를 쓰세요). 그 프로젝트가 보이나요? 그 프로젝트만 보이나요?
매직 링크 로그인을 추가합니다.
새 시크릿 창에서 로그인 흐름 전체를 테스트합니다.
파일 업로드를 추가합니다.
진짜 고객 한 명, 진짜 프로젝트 하나를 추가하고, 직접 써 보라고 부탁합니다.

7단계가 중요합니다. 기능을 다섯 개 더 만들기 전에, 그 물건이 실제 세상에서 작동하는지부터 알아내세요. 진짜 고객은 무엇이 헷갈리는지 즉시 알려 줄 겁니다 — 그리고 그건 거의 항상 당신이 예상했던 것과 다릅니다.

포털이 그만한 가치가 없을 때

고객 포털은 다음과 같을 때 말이 됩니다.

동시에 활동하는 고객이 서너 명 이상이다
고객이 상태를 충분히 자주 물어봐서 그게 진짜 시간을 잡아먹는다
“준비되면 메일 드릴게요”보다 더 전문가답게 보이고 싶다

다음과 같다면 아마 말이 안 됩니다. 한 번에 고객이 한 명이거나, 프로젝트 주기가 매우 짧거나(주 단위가 아니라 일 단위), 또는 고객과 당신 둘 다 이미 편하게 쓰는 도구가 있는 경우죠.

판단 기준은 이렇습니다. “우리 지금 어디까지 됐나요?”에 답하는 데 일주일에 한 시간 넘게 쓰고 있다면, 포털은 만드는 데 드는 그 오후 한나절의 값을 해낼 겁니다.

만든 다음에

고객 포털의 진짜 위험은 기술이 아닙니다 — 정착입니다. 몇 년간 당신에게 이메일을 보내 온 고객은, 바꿀 이유를 주지 않으면 계속 이메일을 보낼 겁니다. 포털을 처음 공유할 때는, 링크만 보내지 마세요. 링크를 보내고, 통화하면서 함께 로그인해서, 프로젝트를 확인할 때 무엇이 보이는지 정확히 보여 주세요.

한 번 로그인해서 쓸모 있는 것을 본 고객은 다시 로그인할 것을 기억합니다. 아무 맥락 없이 링크만 받은 고객은 절대 열어 보지 않습니다.

이게 실제로 어떤 모습인지 궁금하다면, 가장 단순한 버전부터 — 프로젝트와 상태만 — 만들어 보세요. 거기에 언제든 더할 수 있습니다. 오늘 끝낼 수 있는 버전이, 다음 달에 만들지도 모를 완벽한 버전보다 더 가치 있습니다.