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

Roowa I&T 기업 웹사이트

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

기간
2024.08 · 약 3주
분류
웹사이트
역할
프론트엔드 단독
구성
디자인 1 · 프론트엔드 1
사이트 방문
Roowa I&T 기업 웹사이트 데스크톱 화면
Roowa I&T 기업 웹사이트 모바일 화면

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

Mobile · 반응형

  • Roowa I&T 기업 웹사이트 모바일 화면 1

    01

  • Roowa I&T 기업 웹사이트 모바일 화면 2

    02

  • Roowa I&T 기업 웹사이트 모바일 화면 3

    03

  • Roowa I&T 기업 웹사이트 모바일 화면 4

    04

05회고

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

외부 API에 의존하는 구조에서 어댑터 층은 선택이 아니라 필수입니다. 노션 스키마는 클라이언트가 마음대로 바꿀 수 있는 것이고, 그 변경이 화면 컴포넌트까지 전파되면 안 됩니다.