제2장 「마케터와 UIUX의 전격 채용」

이 기사는 개인 개발 서비스 CheckMe (checkme.run) 의 개발 이야기입니다.

공개 직후, 접속은 조금씩 들어오고 있었다. 하지만 무엇을 해야 할지, 무엇이 먹히고 있는지 전혀 알 수 없었다. Nginx의 액세스 로그(Access Log)는 있다. 하지만 그것이 "무엇을 의미하는가"를 읽어낼 시각이 없었다.

"세계 보정급 탑 마케터" 라는 페르소나(Persona)를 프롬프트(Prompt)로 정의했다.

당신은 Web 서비스의 그로스(Growth)를 전문으로 하는 탑 마케터입니다.
다음의 Nginx 액세스 로그를 분석하여,
- 사용자의 과제 가설
...

일반적인 Chat AI에게 "로그 분석해줘"라고 던지는 것과, 페르소나를 명확하게 정의하여 던지는 것은 완전히 다르다. 후자는 "이 키워드로 들어오는 사용자는 시험 전의 절박함을 가지고 있다. 지금 당장 여기에 집중해야 한다"라는 판단이 포함된 제안이 돌아온다.

마케터가 "무엇을 만들 것인가"를 정의한 후, UIUX 탑 디렉터를 채용했다.

그녀의 진단 결과 (발췌):

문제점	수정 방침
입력 폼이 불친절함	h1 직하단에 씬(Scene)별 즉시 실행 카드 배치
...	<details> 태그로 접기
1페이지 이탈이 많음	관련 도구로의 동선 (Chip UI) 추가

이것들은 기술적인 이야기가 아니다. 설계의 이야기다. 기술적으로 구현 가능한지를 생각하기에 앞서, "사용자 경험(UX)으로서 올바른가"를 정의할 수 있는 사람(페르소나)이 필요했다.

LLM에 페르소나를 부여할 때 효과적이었던 점:

• 직책·전문성을 구체적으로 정의하기 ("마케터"보다는 "그로스 해킹 전문 탑 마케터")

• 컨텍스트(Context)를 전부 전달하기 (로그·URL·타겟층·현재 상황)

• 아웃풋(Output) 형식을 지정하기 (우선순위가 포함된 리스트, 근거 포함)

• 같은 세션에 여러 페르소나를 부르지 않기 (역할이 섞임)

• LLM의 페르소나 설계는 "어떤 전문가에게 상담하고 싶은가"를 그대로 정의하면 된다.

• 데이터(로그)를 전달하여 "의미의 해석"을 시키는 것이 가장 가성비가 좋다.

• UIUX와 로직 구현은 분업할 수 있다. 먼저 UIUX를 확정한 뒤 구현하는 것만으로도 품질이 올라간다.

다음 장에서는, 테스트 코드 제로·STG(Staging) 환경 없는 상태로 운영 환경(Production)이 붕괴된 밤의 이야기가 이어진다.