가장 먼저 진단해야 했던 고객은 우리 자신이었다

FINDVALUE의 포지셔닝은 지금까지 세 번 바뀌었습니다. 콘텐츠 마케팅 회사였다가, AI 기반 디지털 성장 파트너가 되었다가, AI 기반 Business Design Studio를 거쳐 지금의 맞춤형 AI·디지털 솔루션 파트너에 이르렀습니다. 방향을 정할 때마다 이름부터 다시 정의해야 했습니다.

이 글은 그 세 번의 변화가 왜 일어났는지, 그 과정에서 무엇을 발견했는지를 기록한 것입니다. 완성된 결과보다 판단의 과정을 남기려고 씁니다. 이 프로젝트는 계속 진행 중이라 아래 내용도 상황에 따라 바뀝니다.

문제

브랜드를 다시 정의할 때마다 화면의 카피도 함께 흔들렸습니다. 진짜 문제는 홈페이지가 없었다는 게 아니었습니다. FINDVALUE 스스로도 무엇을 하는 회사인지 한 문장으로 답하지 못했다는 것이었습니다. 화면에 남은 흔적은 두 가지였습니다.

• Hero 우측 다이어그램은 한때 SEO, 콘텐츠, 홈페이지, CRM, AI 자동화 같은 기술 이름을 그대로 나열하고 있었습니다. 방문자에게 "우리가 파는 것"을 먼저 보여주려 한 것입니다.
• 홈페이지 서비스 요약은 /services의 상품 카테고리 4개(마케팅 성장, 디지털 구축, AI 업무 활용, 연결·확장)를 그대로 옮겨 왔습니다. 카테고리 이름만 보면 여전히 기능별 분류처럼 읽혔습니다.

둘 다 "왜 존재하는가"보다 "무엇을 파는가"가 먼저 보이는 구조였습니다.

원인

이 문제는 카피를 다듬는 것만으로 해결되지 않았습니다. 순서 자체가 거꾸로였기 때문입니다. 상품과 서비스를 먼저 정하고, 철학은 나중에 붙이려 했습니다. 그러다 보니 화면은 계속 "무엇을 파는 회사"로 보였습니다.

발견한 핵심

정보는 왜(WHY) → 무엇을(WHAT) → 어떻게(Method) → 어떤 절차로(Process) 순서로 배치해야 한다는 것을 발견했습니다. 왜가 없으면 방문자는 "그래서 이 회사가 뭘 하는 건데"라고 묻고, 왜만 있고 무엇이 없으면 "그래서 무슨 도움을 받을 수 있는데"라고 묻습니다.

실행

이 발견은 실행 순서를 그대로 결정했습니다.

WHY 정리

• 브랜드 철학을 "고객은 이미 가치를 가지고 있습니다. FINDVALUE는 그 가치를 발견하고 세상과 연결합니다"로 확정하고, 이후 모든 판단을 append-only Decision Log로 남기기 시작했습니다.
• Hero와 Why FINDVALUE 섹션을 "무엇을 하는가"보다 "왜 존재하는가"가 먼저 읽히도록 다시 썼습니다.

WHAT 정리

• Hero에 실행 방법을 보여주는 짧은 태그 줄을 추가했습니다. 철학만 있고 무슨 일을 하는지 안 보인다는 문제를 보완하기 위해서였습니다.

METHOD 재구성

• 홈페이지 서비스 요약을 /services 상품 카테고리 나열에서, 실행 방법 7가지(홈페이지·콘텐츠·SEO·AEO·GEO·온라인 광고·CRM·AI 업무 자동화·운영 시스템)를 결과 중심으로 설명하는 구조로 바꿨습니다.
• "AI 업무 활용"과 "AI 업무 자동화"처럼 사이트 전체에서 혼용되던 용어를 정리했습니다.

PROCESS 및 운영 체계 정리

• 향후 고객 동의 프로젝트를 어떻게 다룰지 Case Study System을 설계했습니다. 새 콘텐츠 타입을 만드는 대신 기존 Build Log를 확장하는 방식을 택했습니다.
• 앞으로 쓰일 모든 프로젝트 글이 같은 구조와 품질을 유지하도록 Project Writing Standard를 만들었습니다.

결과

지금까지 실제로 남은 것은 다음과 같습니다.

• 홈페이지 정보 구조가 다시 짜였습니다. Hero, Why FINDVALUE, Execution Area, Services 요약이 지금의 형태로 남아 있습니다.
• 판단 근거 29건이 Decision Log에 append-only로 기록돼 있습니다.
• Project Writing Standard에 앞으로 쓰일 프로젝트 글이 따라야 할 8단계 구조와 발행 전 체크리스트를 남겼습니다.
• Case Study System을 통해 고객 동의 프로젝트를 다룰 데이터 구조를 준비했습니다. 실제 고객 동의 프로젝트는 아직 없습니다.

여기까지는 "만들려던 것이 실제로 남았는가"를 확인한 단계이지, 완성이라고 보지는 않습니다.

배운 점

새로운 문제가 생길 때마다 새로운 구조를 만들고 싶은 유혹은 매번 있었습니다. 서비스 요약을 고칠 때도, 고객 동의 프로젝트를 다룰 방법을 정할 때도 그랬습니다. 하지만 두 경우 모두 답은 새로 만드는 게 아니었습니다. 이미 있는 것의 역할을 다시 정의하는 쪽이 더 나았습니다.

이건 이번 한 번의 우연한 결론이 아닙니다. FINDVALUE는 문제를 만나면 먼저 지금 있는 것으로 풀 수 있는지부터 확인합니다. 새로 만드는 것은 그다음입니다.

다음 단계

이 문서는 계속 갱신됩니다. 다음으로 남아 있는 것은 실제 고객 동의 프로젝트가 생겼을 때 Case Study System과 Project Writing Standard를 처음으로 실전에서 검증하는 일입니다.

이 프로젝트가 남긴 것은 완성된 홈페이지 화면이라기보다, 그걸 만드는 동안 FINDVALUE가 스스로 무엇인지 다시 확인했다는 사실에 가깝습니다. 브랜드를 먼저 정의하고 홈페이지를 만든 것이 아니라, 홈페이지를 만드는 과정 자체가 브랜드를 정의하는 과정이었습니다.