블로그를 학교생활 기록 창구로 만들기 — 프로젝트 분류 체계 고민 (연재 5/6)

학습 주제

블로그를 단순 포스팅 모음이 아니라 내 학교생활을 기록하는 일종의 개인 데이터베이스로 쓰고 싶다는 생각에서 출발했습니다. 특히 프로젝트형 과목을 들으면서 뭘 했는지, 어떤 과정을 거쳤는지, 팀 프로젝트라면 어떤 갈등이 있었고 어떻게 풀었는지를 나중에 다시 꺼내볼 수 있게 정리해두고 싶었습니다. 오늘은 그 첫 단계로 프로젝트 탭의 분류 체계를 어떻게 잡을지 고민한 날입니다.

탐구 과정

처음에는 단순하게 프로젝트를 "개인 프로젝트"와 "팀 프로젝트"로 나누면 되겠다고 생각했습니다. 실제로 구현하기도 쉬운 방향이고요. 그런데 막상 이 구조로 정리하려고 하니 뭔가 어색한 부분이 있었습니다.

제가 진짜 원하는 건 "수강 과목을 기반으로 한 기록"인데, 개인/팀이라는 축만으로는 그게 잘 드러나지 않는다는 걸 깨달았습니다. 예를 들어 LearningCollector나 k8s-manifests 같은 프로젝트는 애초에 특정 과목과 상관없이 제가 개인적으로 진행한 것들이고, 반면 팀 프로젝트라고 해도 전공 수업에서 한 것과 동아리에서 한 것은 성격이 완전히 다릅니다. 개인/팀 태그만 붙이면 "이게 어느 수업, 어느 맥락에서 나온 프로젝트인지"가 묻혀버리는 문제가 있었습니다.

핵심 학습 내용

이번에 정리하면서 명확해진 건 분류 기준을 정할 때 "구현이 쉬운 축"과 "내가 실제로 필요로 하는 축"이 다를 수 있다는 점입니다.

• 개인/팀 구분: 구현은 단순하지만, 프로젝트의 맥락(어떤 수업, 어떤 목적)을 설명해주지 못함
• 과목 기반 구분: "어떤 과목의 프로젝트인가"라는 정보를 직접 담을 수 있어서, 나중에 특정 과목을 돌아볼 때 훨씬 유용함
• 다만 모든 프로젝트가 과목에 속하는 건 아니라서, 과목 필드를 필수로 강제하면 개인 프로젝트들은 억지로 끼워 맞추게 되는 부작용이 생길 수 있음

정리하자면 두 축은 서로 배타적인 게 아니라 계층이 다른 정보라는 걸 알게 됐습니다. 개인/팀 여부는 프로젝트의 성격을 나타내는 태그고, 과목명은 프로젝트가 어떤 맥락에서 나왔는지를 나타내는 정보라서, 둘 다 필요하다면 별개의 필드로 관리하는 게 맞겠다는 결론에 가까워졌습니다.

이해한 내용

분류 체계를 설계할 때는 먼저 "이 분류로 나중에 무엇을 찾아보고 싶은가"를 먼저 정해야 한다는 걸 새삼 느꼈습니다. 저는 "무슨 과목에서 뭘 했는지"를 나중에 검색하듯 찾아보고 싶은 거였고, 그렇다면 개인/팀 구분만으로는 부족하다는 게 확실해졌습니다.

또 하나 배운 건, 스키마를 짤 때 "지금 당장 구현하기 쉬운 것"과 "나중에 필요한 것" 사이에서 균형을 잡아야 한다는 점입니다. 과목명 필드를 처음부터 넣을지, 아니면 개인/팀 구분만 먼저 넣고 과목 정보는 나중에 확장할지는 결국 우선순위의 문제였습니다.

실전 적용

이 고민을 바탕으로 다음과 같은 방향으로 스키마를 잡아볼 계획입니다.

• 프로젝트마다 개인/팀 태그는 기본으로 유지
• 과목과 연관된 프로젝트에는 과목명 필드를 추가로 부여 (없는 경우는 비워둠)
• 나중에 과목별로 필터링해서 "이 과목에서 한 프로젝트들"을 모아볼 수 있는 뷰를 만드는 것을 목표로 함
• 팀 프로젝트의 경우 갈등 상황이나 해결 과정을 별도 섹션으로 기록해서, 단순 결과 정리를 넘어 과정 자체를 남기는 방향으로 진행

추가 학습 계획

다음에는 실제로 이 스키마를 블로그에 어떻게 데이터로 저장할지(예: 프론트매터 필드 설계, 필터링 UI 구현 방식) 구체적으로 정해볼 예정입니다. 과목명과 개인/팀 태그를 함께 쓸 때 UI에서 어떻게 보여주는 게 자연스러울지도 더 고민해볼 계획입니다.