나만의 블로그를 만들어보자는 생각으로 새로운 프로젝트를 약 2개월가량 진행했다. 결과는 대실패 !!
프로젝트를 진행하면서 스스로 고민하고 배운점도 많고, 앞으로의 프로젝트에 대해 개선할 부분도 많다고 생각하게 되었다.
프로젝트를 진행했던 과정과 깨달은 점, 그리고 앞으로의 프로젝트는 어떻게 진행할지에 대한 생각을 기록하고자 한다.
프로젝트 시작
티스토리 블로그에는 오랜만에 작성하는 블로그 글이긴 하지만, 중간중간 다른 방식의 블로그를 탐험해보았다.
노션과 같은 노트 앱을 사용한 방법도 고려해보았고, Github Pages나 다른 무료 호스팅 방법을 사용해보기도 했다. Obsidian에서 블로그를 포스팅하는 플러그인을 사용하는 시도도 해보았다.
여러가지 방법을 시도하다 결국 내가 직접 만드는 블로그 프로젝트를 한 번 시도하게 되었다.
프로젝트 계획
AWS S3, CloudFront를 사용하여 낮은 비용으로 처리할 수 있고, 내가 직접 만들게 되니 높은 커스텀 가능성을 가질 수 있도록 목표했다.
프론트 앱은 React를 선택했고, 블로그 글의 목록을 만드는 등의 작업을 위해서 AWS Lambda를 선택했다.
개발을 하여 Github으로 push 하게 되면 Github Action를 통해
- React 앱은 바로 S3로 업로드
- 노트 파일, 노트 트리 구조를 Lambda를 통해 파싱 후 S3 업로드
- S3파일을 CloudFront를 사용하여 배포
하는 방식을 선택하였다
AWS Lambda 생성
AWS Lambda 서비스는 서버리스 컴퓨팅 서비스이다.
Node.js, Python 등으로 구성한 코드를 클라우드 상에서 실행하는데, 코드가 실행되는 시간에 대해서만 비용을 청구한다.
노트 목록에 대하여 일부 데이터를 생성하려고 하는데, 노트 목록 변경은 많지 않을 것이다. 그렇다고 하여 로컬에서 데이터를 만들고 업로드 하는 방식은 번거로웠기 때문에, Lambda 서비스를 선택했다.
Lambda 함수는, 노트 목록들을 업로드 하면,
- 노트들을 저장한 폴더 구조를 사이드바에서 보여줄 수 있도록 데이터 구조화
- 노트들의 링크나 frontmatter 정보를 별도로 저장하여 활용가능한 데이터로 저장
폴더 구조 데이터 생성
노트 영역이 보이는 것 다음으로 사이드바를 생각했다. Jekyll 등을 사용하면 간단하게 블로그를 만들 수 있지만, 보통은 작성 순서별 단순 정렬된 목록만 구성하게 된다. 당장에는 글이 많지 않을 것이기에 원하는 글을 조회하는 것에는 큰 문제가 없겠지만, 조금 욕심이 났다. 그래서 트리구조의 파일목록을 구성하고자 했다.
폴더 1
├── 노트 1
├── 노트 2
└── 노트 3
폴더 2
├── 폴더 2-1
│ ├── 노트4
│ ├── 노트5
│ └── 노트6
├── 노트7
└── 노트8
위와 같은 폴더 구조를 프론트에서 트리 형태로 보여줄 방법에 대해 고민했다. 재귀적인 형태의 JSON으로 데이터를 저장하도록 했다.
{
"folders": [
{
"name": "폴더 1",
"folders": [],
"files": [
"노트 1",
"노트 2",
"노트 3"
]
},
{
"name": "폴더 2",
"folders": [ { "name": "폴더 3", ... } ],
"files": [ ... ]
}
]
"files": []
}
폴더 구조를 위와 같은 재귀적인 형태의 JSON으로 저장하였고, React에서 재귀적 컴포넌트 구조로 이를 나타내었다.
메타데이터 활용
노트의 내용만 잘 나타내어도 되지만, 조금 더 활용할 수 있는 방법이 없을까 고민했다. Obsidian의 frontmatter에 작성한 메타데이터나, 노트 내부의 링크 정보를 별도로 저장하여 태그별 필터링이나 연결된 노트 탐색 등의 기능을 추가하고 싶었다.
React 앱 생성
React 앱은 기본적인 구조로 구성했다. 사이드바에서 파일 목록을 트리 형태로 보여주고, 메인 영역에서 마크다운을 렌더링하는 구조이다.
Lambda에서 생성한 JSON 데이터를 fetch하여 사용했고, 재귀적 컴포넌트를 사용하여 폴더 트리를 구현했다. 각 파일을 클릭하면 해당 마크다운 파일을 불러와 렌더링하는 방식으로 동작하도록 했다.
Lambda 마크다운 파서 변경
프로젝트를 진행하며 마크다운 파서 관련 문제를 마주했다. 초기에 사용했던 파서는 기본적인 마크다운 문법은 잘 처리했지만, Obsidian의 wikilink 문법([[]])이나 일부 확장 문법들을 제대로 파싱하지 못했다.
새로운 파서 라이브러리를 찾아 적용하는 과정에서, 단순히 라이브러리를 교체하는 것만으로는 부족하다는 것을 깨달았다. Obsidian의 다양한 확장 문법들을 모두 지원하려면 커스텀 파싱 로직을 추가해야 했고, 이는 예상보다 훨씬 많은 시간과 노력이 필요한 작업이었다.
이 과정을 반복하다가 프로젝트를 더욱 길게 이끌어가기는 힘들겠다는 생각을 하게 되었다.
프로젝트 마무리
글 하나를 작성하는 것인데, 오히려 복잡성이 너무 커지는 바람에 프로젝트를 마무리할 시점이 다가왔다고 느꼈다.
마크다운 파서 문제가 가장 큰 고민이었다. 아직은 간단한 파싱의 문제였기 때문에 빠르게 해결했지만, 조금만 더 복잡한 문제를 마주하게 된다면 문제 해결에 시간이 상당히 소모될 것이라 생각이 들었다. 링크가 많아진다거나, 순수 마크다운이 아니라 flavored 마크다운 문법들의 경우 별도 파싱 기능을 추가하거나 수정해야 하는데, 이것이 오히려 비효율적이라는 생각이 들었다.
다른 문제로는 비용을 줄이기 위해 선택한 구조가 오히려 더 복잡해져버렸다는 점이다. Lambda를 수정하면 부가적인 문제가 발생하여 React 앱까지도 수정해야 할 경우가 있었다. 간단하게 배포하려다 일이 몇 배로 더 많아진 것 같은 느낌도 들었다.
프로젝트 회고
다음 프로젝트를 기획하고 진행할 때 고려해야 할 점들을 정리했다.
1. 명확한 기한과 목표 설정
이번 프로젝트를 진행하며 두루뭉실하게 것들을 '나중에 결정' 할 것으로 미뤄두었다.
그런데 막상 그런 문제들을 마주치게 되었을 때, 어떻게 할지 결정을 하지 못한 체 시간을 잡아 먹은 경우들이 있다.
대표적으로 마크다운 파서 기능 개발이다. 마크다운의 어떤 부분까지 지원할지에 대해 고민을 하지 않았다보니, 처음에는 일반적인 마크다운 파서로 충분했다.
그런데, obsidian 마크다운을 지원한다거나 할 때 마다 새로운 라이브러리르 찾아보았지만 한계가 있었고, 결국 스스로 만들기 까지 했다.
만약 처음부터 어디까지는 지원하고, 어떤 것은 지원하지 않을지 명확히 정해두었다면 좋았을 듯 싶었다.
2. 프로젝트 마무리 시점 판단
CSS 스타일링을 제외하고, 대체적으로 마무리되었다고 생각했다.
CSS를 AI 도움을 받아가며 조금씩 진행하고 있었는데, 완벽하게 마무리하진 못하는 상태에서 생각보단 많은 시간이 걸렸다.
이 때, 목표 기한을 설정했는데, 이 기한을 초과할 때서야 기한을 늘릴지, 마무리를 할 지 고민을 했다. 그렇게 기한을 어영부영 늘리기를 몇 차례...
처음부터 완벽한 프로젝트는 없다. 다만, 지금은 어디까지 개발할 것인가를 정하고 마무리하거나, 프로젝트를 그만 둘 용기도 필요하다.