고양이의 만행 홈페이지를 어떻게 개발하고 운영할지 기록

왜 홈페이지가 필요한가?

익숙하지 않은 SNS

요즘엔 뭔가 사업을 한다고 하면 SNS를 먼저 시작한다. 내가 처음 시작한 SNS는 싸이월드, 그 다음에는 페이스북이었던 것으로 기억한다. 그리고 인스타그램도 했었지만… 2,000명 정도 팔로워가 되었을 무렵 계정을 지우고 다시 만들었다. 지금은 소수의 지인들만 보는 인스타그램이 되었다. 페이스북도 중간에 한 번 지우고 다시 만들었다. 지금은 페이스북을 사용하는 소수의 지인 소식을 듣는 용도 외로는 거의 사용하지 않는다.

블로그와는 다른 홈페이지

사진과 영상을 촬영하고 편집하는게 익숙하지 않아서 잘 쓰지 않게 되는 것 같다. 그 보다는 블로그를 꽤 오래 사용했다. 그 기간 동안 예전에 작성한 블로그 사용기처럼 온갖 플랫폼을 전전했다. 그러다보니 전기장판 출판사나 사담미디어, 고양이의 만행 등 사업을 하면서 처음 든 생각은 홈페이지를 만드는 것이었다. 하지만 홈페이지를 만들고 운영했던 사람이라면 알겠지만, 블로그랑 홈페이지는 전혀 다르다. 처음에는 정적 웹사이트 생성기로 홈페이지 제작을 시도해봤지만, 도저히 익숙하지 않은 플랫폼으로 원하는 형태를 만드는 것은 쉽지 않았다.

홈페이지를 직접 만들기로 한 이유

처음에는 편집이 간단한 notion을 홈페이지로 사용했고, 지금은 wordpress를 사용하고 있다. notion은 공식 홈페이지로 쓰기에는 디자인이 살짝 아쉬웠다. (내가 디자인 감각이 있는 것은 아니지만, 일반적으로 홈페이지에 기대하는 틀이 있으니까) 온갖 커스텀(우피(Oopy)에 이전글 다음글 버튼 추가 같은)을 추가했지만, 그럴거면 그냥 직접 만드는게 낫지 않나? 라는 생각이 들었다. 워드프레스도 PHP 지식의 한계로 기능 추가에 어려움이 있어서 만족스럽지 않았다. (비록, SEO 측면에서는 가장 좋았지만)

결국 언어별 페이지, 별도의 백엔드가 필요한 ERP나 CRM 기능, 출판사 고객의 판매 조회나 정산 등의 서비스를 통합하기 위해서는 내가 잘 아는 언어로 만들 필요가 있었다. 다행히 Python에는 Django라는 강력한 백엔드 프레임워크가 있었다. 비록 Django도 프론트엔드를 지원하지만, (실제로 구현해보니 복잡한 작업도 가능했다) 편리하지는 않았다. 다행히 Django의 부족한 프론트엔드 기능을 대체할 서비스는 너무나 많아 오히려 어떤 기술 스택을 활용할지 고민이 될 정도였다.

어떻게 시작할까?

내부 서비스 부터

아무리 Python을 오래 사용했어도, Django를 사용하는건 다른 문제였다. 웹 개발은 사실 처음 해보는 거였고, 웹 호스팅을 위해 클라우드 서버를 두거나 nginx, gunicorn 등을 설정하는 것도 쉽지 않았다. 로드 밸런스나 CDN도 처음에는 뭔 소린가 했다. 그래서 잘 알고 익숙한 것 부터 시작했다. 내부 서비스를 만드는 것이다. 지금 가장 필요한 서비스는 복식부기 장부였다.

복식부기 장부 만들기

기존에는 Google Sheets로 만든 (Google Sheets로 복식부기 장부 만들기 참고) 복식부기 장부를 사용하려고 했다. 연결 재무제표까지 구현한 상태였는데, 작성이 너무 어려웠다. 게다가 어쨌든 Google Sheets는 DB가 아니라서 데이터의 무결성이나 실수로 수정하는 등의 관리를 하는게 어려웠다. 무엇보다 그 당시에는 AI를 이용한 자동화가 쉽지 않았다. 그러다보니 장부를 작성하면서 계정과목을 일일이 설정하는 것도 어려웠고, 항목별 계정과목을 매칭해서 정리하기도 쉽지 않았다.

다 하려면 하는 일이고, 대부분 구현했지만 어쨌든 손이 가지 않는 도구였다. 특히 직접 입력하거나 거래내역 데이터를 받아서 정리하고 넣어야 하는데, 수작업을 하기도, 파이썬으로 코드를 짜기도 애매한 작업이었다. (파이썬으로 코드를 짤 것이었으면 그냥 다 파이썬으로 만들지) 그래서, 이걸 Django로 구현하기로 했다. 특히, OpenAI API를 이용해서 계정과목을 자동으로 정해주는 기능을 넣기로 했다.

별도로 프론트엔드를 쓸 필요는 없었다. 주먹구구식이라도, 자바스크립트를 사용하면 어찌어찌 다 되었다. 유지보수나 협업, 확장성 따위는 고려하지 않은 하지만 기능은 제대로 작동하는 웹페이지가 완성되었다. 거래내역 파일을 업로드하면, 자동으로 변환해서 원하는 항목은 기존 값을 토대로 API가 계정과목을 정리해서 저장했다. 당연히 직접 수정하고, 거래내역에 없는 항목을 추가할 수도 있었고, 재고 관리도 함께 가능했다. 그래도 실무에서 사용하지는 않았다.

이제 이 경험을 토대로 제대로 된 홈페이지를 만들 차례다.

이제, 홈페이지 만들기 시작

Django 템플릿으로 홈페이지 개발

주먹구구식으로 만든 홈페이지를 뜯어고쳤다. Django 프론트엔드를 사용한다는 점은 그대로 두고 유지보수성과 확장성, 개발편의성을 고려해서 코드는 전부 뜯어고쳤다. 복식부기 장부 외에 다른 ERP 시스템이나 SCM 시스템을 개발할 수 있도록 구조를 변경하고, 기존 코드는 재사용성을 고려해서 분해했다. 이 과정에서 코드 파일을 기능에 따라 세부적으로 쪼개서 적절하게 폴더로 묶어서 분류했다.

Django 프론트엔드도 자바스크립트와 html 코드, css를 모두 분리했다. (당연한 거지만) 이를 통해 모든 페이지가 필요에 따라 공통된 UI를 따르고, 계층 구조를 따라 다른 앱도 향후 동일한 레이아웃을 갖도록 했다. js는 모두 기능별로 별도 파일로 분류해서 가시성을 높이고 오류에 대응하기 쉽도록 개선했다.

Django 템플릿에서 Next.js로 프론트엔드 수정

그리고 이렇게 만든 홈페이지는 사용하지 않았다. 간단한 이유다. 프론트엔드를 Next.js로 다시 개발할 것이기 때문이다. 예전에 Next.js를 프론트엔드로, Django를 백엔드로 개발하던 프로젝트가 있었다. 사담미디어, 전기장판 출판사, 고양이의 만행, 개인 블로그를 모두 묶어서 공통된 레이아웃과 유사한 UI를 갖는 하나의 프로젝트로 만들려고 시도한 적이 있다.

고양이의 만행 홈페이지의 대부분을 만들고, 핵심이 되는 UI를 구성했을 때, 깨달았다. 다른 홈페이지에 이 형태를 그대로 이식한다는 것이 바보 같은 생각임을. 물론, 페이지별 구조는 대부분 비슷하다. 몇 가지 완성된 구조에 동일한 형태의 페이지와 데이터 형태를 가져다 쓴다. 하지만, 각 페이지가 매우 유사해도 페이지마다 커스텀이 들어가고 형태가 달라졌다. 즉, 공통 컴포넌트로 모든 것을 처리하는 것은 매우 단조로운 홈페이지를 만들게되고, 공통 컴포넌트를 불러서 각 페이지별로 커스텀하는 것은 훨씬 폼이 많이 드는 일이었다.

그래서 도메인에 따라 프로젝트를 분리하기로 했다. 고양이의 만행 홈페이지는 고양이의 만행 홈페이지 백엔드 프로젝트와 고양이의 만행 홈페이지 프론트엔드 프로젝트로 분리했다. 당연히 전기장판 출판사와 사담미디어 프로젝트도 분리했다. 블로그는 Obsidian Publish를 사용하기로 했다.

그러다보니 앞서 만든 복식부기 장부 홈페이지(역시 사담미디어, 전기장판 출판사, 심지어 가계부까지 .. 통합해서 연결 재무제표를 만든)도 쪼개서 각 도메인에 집어넣기로 했다. 이 과정에서 프론트엔드도 Next.js로 다시 구성하기로 했다. 다행히 기존 Django 프로젝트는 필요한 부분만 가져와서 API만 추가하면 되는 문제였다. 연결 재무제표라는 목표는 각각의 장부에서 데이터를 가져와서 구성하면 될 일이었다.

고양이의 만행 홈페이지부터

도구가 정해지고, 어느 정도 프로토타입이 모두 개발된 상태에서 고민이 생겼다. 이미 대부분의 업무가 완전하진 않지만, 파이썬으로 자동화된 전기장판 출판사의 홈페이지를 만들고, 각 기능을 홈페이지로 이전할까 아니면, 올해 초에 볼로냐에 참가하는 고양이의 만행 홈페이지(영문, 한글)를 먼저 만들 것인가였다. 결론은 고양이의 만행 홈페이지를 먼저 만들기로 했다.

  1. 고양이의 만행 홈페이지는 당장 볼로냐아동도서전에 참가하기 때문에 필요하다.
  2. 전기장판 출판사 업무는 이미 파이썬으로 어느 정도 자동화가 되어있다.
  3. 고만행 홈페이지 개발이 더 쉽다.
    1. 왜냐하면, 고양이의 만행은 브랜드라서 별도의 장부가 필요 없기 때문이다.
    2. 그래서 별도의 백엔드 없이, Next.js로 모두 개발을 완료할 수 있다.

그래서 고양이의 만행 홈페이지를 먼저 만들기로 했다. 장기적으로 Django 기반 Backend가 탑재되겠지만, 일단은 프론트엔드를 빠르게 만들어서 배포하는 것이 목표로 잡혔다. 현재 진행중이다. 관련 내용이 궁금하면 index를 참고하기 바란다. 이상.