본문으로 건너뛰기
DEVKBS
작업 원장
016Roowa2024.08 · 약 3주

Roowa I&T 기업 웹사이트

Notion을 CMS로 쓰는 두 번째 사이트

기간
2024.08 · 약 3주
분류
웹사이트
역할
프론트엔드 단독
구성
디자인 1 · 프론트엔드 1
사이트 보기

01개요

roowa.kr을 만들면서 구축한 Notion API 연동 구조를 계열사 사이트에 다시 쓰는 프로젝트였습니다. 기간이 3주뿐이었고, 그 안에 가능하다고 본 이유가 앞 프로젝트의 구조를 그대로 가져올 수 있다는 점이었습니다.

해 보니 재사용은 생각처럼 간단하지 않았습니다. 앞 프로젝트의 컴포넌트가 roowa.kr의 데이터베이스 스키마를 전제로 짜여 있었기 때문입니다. 그대로 복사하면 돌아가지만, 구조가 조금만 달라져도 고칠 곳이 여기저기 흩어져 있었습니다.

그래서 노션에서 데이터를 가져오는 부분과 가져온 데이터를 화면에 그리는 부분을 확실히 나눴습니다. 앞쪽은 프로젝트를 옮겨도 그대로 쓰고, 뒤쪽은 사이트마다 새로 씁니다. 이렇게 나눈 뒤에야 재사용이라고 부를 만한 코드가 생겼습니다.

02기술 결정

문제, 선택, 결과 순서로 적었습니다.

  1. 결정 01

    재사용할 코드와 매번 새로 쓸 코드를 먼저 나눈다

    문제
    앞 프로젝트의 컴포넌트를 복사해 왔더니 노션 속성 이름이 컴포넌트 깊숙한 곳에 박혀 있었습니다. 스키마가 조금만 달라도 여러 파일을 헤집어야 했습니다.
    선택
    노션 응답을 도메인 타입으로 변환하는 어댑터 층을 만들고, 화면 컴포넌트는 그 도메인 타입만 알게 했습니다. 노션 속성 이름은 어댑터 한 곳에만 존재합니다.
    결과
    다음 사이트를 만든다면 어댑터의 매핑 테이블만 바꾸면 되는 상태가 됐습니다.
  2. 결정 02

    비개발자가 CMS를 직접 관리하게 한다

    문제
    소규모 기업 사이트에 별도의 관리자 시스템을 만드는 것은 비용 대비 효율이 떨어집니다. 그렇다고 수정 요청을 매번 개발자가 받으면 유지보수가 끝나지 않습니다.
    선택
    이미 사내에서 쓰고 있는 Notion을 그대로 CMS로 삼았습니다. 담당자는 새 도구를 배울 필요 없이 늘 쓰던 화면에서 페이지를 수정합니다.
    결과
    공지·채용·서비스 소개를 클라이언트가 직접 갱신합니다. 개발자에게 오던 문구 수정 요청이 사실상 사라졌습니다.
  3. 결정 03

    문의 메일은 서버 액션으로 처리한다

    문제
    문의 폼을 위해 별도의 API 라우트를 만들고 클라이언트에서 fetch 하는 구조는, 이 규모의 사이트에서 불필요한 왕복과 파일을 만듭니다.
    선택
    Next.js 서버 액션에서 Nodemailer를 직접 호출하고, 검증은 서버·클라이언트 양쪽에서 같은 스키마로 했습니다.
    결과
    폼 하나에 파일 하나. 코드가 짧아졌고 자격 증명이 클라이언트로 새어 나갈 여지도 없앴습니다.

03주요 기능

  • Notion 기반 콘텐츠 관리

    공지·서비스 소개·채용을 Notion 데이터베이스에서 가져와 렌더링.

  • 문의 메일 전송

    서버 액션 + Nodemailer로 폼 제출을 처리하고 동일 스키마로 양쪽 검증.

  • 카카오맵 오시는 길

    지도 API로 위치를 표시하고 길찾기로 바로 연결.

  • 반응형 기업 소개

    회사 소개·연혁·서비스를 모바일에서도 읽기 편한 흐름으로 재구성.

04화면

Desktop

  • 01

  • 02

  • 03

  • 04

Mobile · 반응형

  • 01

  • 02

  • 03

  • 04

05회고

'재사용 가능한 코드'라는 말은 옮겨 보기 전까지 아무 근거가 없습니다. 앞 프로젝트에서 잘 만들었다고 뿌듯해했던 컴포넌트가, 두 번째 프로젝트에서 제일 손이 많이 갔습니다.

외부 API에 기대는 구조라면 어댑터 층은 처음부터 두는 게 좋습니다. 노션 스키마는 클라이언트가 언제든 바꿀 수 있고, 그 변경이 화면 컴포넌트까지 번지면 곤란합니다.