웹사이트제작, 개발자의 기술보다 기획자의 '이것'이 먼저입니다

솔직히 고백하자면, PM으로서 처음 프로젝트를 맡았을 때 저는 보기 좋은 웹사이트를 만드는 데에만 혈안이 되어 있었습니다. 디자이너에게는 "더 세련되게", 개발자에게는 "최신 기술 스택으로 빠르게"만을 외쳤죠. 결과는 어땠을까요. 디자인은 화려했고 기능은 넘쳐났지만, 정작 사용자는 가입조차 하지 않고 이탈했습니다. 그때 뼈저리게 느꼈습니다. '예쁜 쓰레기'를 만들었구나, 하고 말이죠.

많은 분들이 웹사이트제작을 고민할 때 디자인 툴이나 개발 언어부터 떠올립니다. 하지만 수많은 실패와 시행착오를 겪으며 제가 깨달은 건, 성공적인 프로덕트는 코드 한 줄 작성하기 전에 이미 절반은 결정된다는 사실입니다. 오늘은 개발자 동료들, 그리고 스타트업 실무자 여러분께 기술 스택보다 중요한 '본질'에 대해 이야기해 보려 합니다.

왜 우리는 3천만 원짜리 실패작을 만들었나

몇 년 전, 클라이언트로부터 의뢰받은 프로젝트가 있었습니다. 예산도 넉넉했고 기간도 여유로웠습니다. 우리는 자신만만하게 React 기반의 SPA(Single Page Application)를 제안했고, 화려한 인터랙션을 위해 Framer Motion 같은 라이브러리를 잔뜩 얹었습니다. 서버는 AWS 기반으로 오토 스케일링까지 고려한 탄탄한 아키텍처를 짰습니다.

문제는 런칭 일주일 뒤에 터졌습니다. 고객사 대표님으로부터 연락이 왔는데 목소리가 심상치 않았습니다. "사이트가 너무 느리고, 우리 고객들은 도대체 뭘 눌러야 할지 모르겠답니다." 알고 보니 해당 서비스의 주 타겟층은 5060 세대였고, 그들의 모바일 환경은 생각보다 좋지 않았습니다. 우리가 공들여 만든 화려한 애니메이션은 그들의 저가형 스마트폰에서 버벅거렸고, 햄버거 메뉴 버튼조차 낯설어했습니다.

기술적으로는 훌륭했지만, 비즈니스적으로는 완벽한 실패였습니다. 우리는 사용자의 맥락(Context)을 전혀 고려하지 않고 우리만의 기술 파티를 벌였던 겁니다. 그때의 부끄러움은 아직도 제 등골을 서늘하게 합니다.

기술 이전에 정의해야 할 3가지 질문

그 뼈아픈 실패 이후, 저는 웹사이트제작 프로세스를 완전히 뜯어고쳤습니다. 개발 IDE나 피그마(Figma)를 켜기 전에 반드시 팀원들과 함께 다음 세 가지 질문에 대한 답을 내리는 시간을 갖습니다. 이 과정 없이는 단 한 줄의 코드도 짜지 않습니다.

첫째, "누가, 어떤 상황에서 이 사이트에 접속하는가?" 단순히 '20대 여성' 같은 인구통계학적 정의로는 부족합니다. '출근길 지하철에서 한 손으로 급하게 정보를 찾는 20대 직장인'처럼 구체적인 상황을 그려야 합니다. 그래야 모바일 퍼스트로 갈지, 로딩 속도를 최우선으로 할지, 버튼 크기를 얼마나 키울지가 결정됩니다.

둘째, "사용자가 여기서 얻어가야 할 단 하나의 가치는 무엇인가?" 모든 기능이 다 중요하다고 말하는 기획서는 최악입니다. 사용자가 사이트에 들어와서 '구매'를 해야 하는지, '정보'를 얻어야 하는지, '문의'를 남겨야 하는지, 핵심 목표(North Star Metric) 하나를 정해야 합니다. 그 외의 모든 요소는 이 목표를 달성하기 위한 수단이거나, 과감히 제거해야 할 잡음일 뿐입니다.

셋째, "우리는 이 사이트를 어떻게 유지보수할 것인가?" 이 부분이 개발자분들이 가장 공감하실 대목일 겁니다. 지금 당장 최신 기술인 Next.js 14를 도입하는 게 중요한 게 아닙니다. 현재 팀의 리소스로 운영 가능한지, 1년 뒤에 누가 이 코드를 들여다봐도 수정할 수 있는지가 중요합니다. 오버 엔지니어링은 결국 기술 부채라는 이름으로 우리 발목을 잡습니다.

성공적인 웹사이트를 위한 PM의 체크리스트

이제 실전으로 들어가 봅시다. 제가 사내에서 프로젝트 킥오프 때마다 활용하는 체크리스트를 공유합니다. 이 항목들을 하나씩 지워나가는 것만으로도 프로젝트의 리스크를 현저히 줄일 수 있습니다.

• 목적 정의 (Goal Setting)

  • 사이트의 핵심 KPI가 명확히 정의되었는가? (예: 리드 수집 월 100건)

  • 타겟 페르소나의 Pain Point를 한 문장으로 정의할 수 있는가?

• 기술 스택 검토 (Tech Assessment)

  • 선택한 기술 스택이 팀 내에서 능숙하게 다룰 수 있는 것인가?

  • SEO(검색 엔진 최적화)가 중요한 프로젝트라면 SSR(Server Side Rendering)을 고려했는가?

  • CMS(콘텐츠 관리 시스템)가 필요한가, 아니면 정적 사이트로 충분한가?

• 사용자 경험 (UX Core)

  • 페이지 로딩 속도가 3초 이내인가? (Core Web Vitals 기준)

  • 모바일 환경에서의 가독성과 터치 영역이 충분히 확보되었는가?

  • CTA(Call To Action) 버튼이 명확하게 눈에 띄는가?

결국은 비즈니스 임팩트입니다

개발자라면 누구나 새로운 기술을 써보고 싶고, 더 우아한 아키텍처를 구현하고 싶은 욕심이 있습니다. 저 역시 그랬으니까요. 하지만 우리가 만드는 것은 예술 작품이 아니라 비즈니스 문제를 해결하는 도구라는 점을 잊지 말아야 합니다.

가장 좋은 웹사이트제작은 화려한 기술의 집약체가 아닙니다. 사용자의 문제를 가장 빠르고 정확하게 해결해 주는, 그래서 비즈니스의 성장에 기여하는 사이트입니다. 때로는 워드프레스 테마 하나로 뚝딱 만든 사이트가 수억 원을 들인 커스텀 개발 사이트보다 더 큰 매출을 내기도 합니다.

지금 진행 중인 프로젝트가 막막하게 느껴진다면, 잠시 모니터에서 눈을 떼고 다시 처음으로 돌아가 보세요. 우리는 누구를 위해, 무엇을 해결하려고 이 사이트를 만들고 있는가? 그 본질적인 질문에 대한 답이 여러분의 코드를, 그리고 프로덕트를 올바른 방향으로 이끌어 줄 것입니다.