기존 파일들을 어떻게 호환시킬 것인가? 문제상황 현재의 가장 큰 개발 과제 중 하나는 바로 기존 블로그 글에 대한 마이그레이션과 관련된 부분이다. 기존의 데이터는 정적 사이트 생성기인 Gatsby를 활용하여 쿼리를 통해 구현이 되어 있다. 하지만 웹 서비스 형식으로 구현이 될 현재의 형태에서 기존의 파일 기반의 블로그의 데이터들은 데이터의 변환이 되었든, 호환이 되었든 무언가 조치를 통하지 않으면 안된다. 요구 기준 사항 MySQL 을 기준으로 잘 동작할 수 있게 처리가 되어야 한다. (미확정) 검색 기능 최적화를 위해 Elasticsearch 같은 검색 엔진을 고려할 수도 있다. 2번이 아니더라도 자체적인 검색 기능 구현함에 있어 성능최적화를 고려해야한다. 향후 글쓰기에서 필요한 기능들이 동일하게 동작하도록 호환이 되어야하고, 기존의 데이터들은 메타데이터 형식으로 MD 파일 상단에 동일하게 위치해 있음에서 호환이 되어야 한다. 결론 파일 형식을 그대로 이어가면서, 파일 형식에서…

BTB Project 이번에 혼자 진행하는 해당 프로젝트는, 일종의 마지막 정리에 가까운 프로젝트이다. 이 프로젝트에 대한 내용 정리를 위한 글로써 지속적으로 업데이트를 해볼 예정이다. “Beyond The Bracket” 우리는 개발을 하면서 여러 상황에 놓인다. 어려운 일들, 힘든 일들, 과연 내가 가능할까? 하는 생각들은 불안과 공포, 체념을 야기하게 된다. 그리고 그건 마치 우리가 치는 코드의 꺽쇠와 비슷한 느낌을 주곤 한다. 컴퓨터의 어떤 프로그래밍 언어도 꺽쇠(Edge Bracket)를 사용한다. 꽤 특이한 친구들이 있긴 하지만 대부분의 C 기반인 경우 를 통해 범위를 정하며 그 범위는 소위 어렵게 말하면 stack frame의 역할을 하기에 벗어나면 segmentation fault를 발생 시키고 만다. 컴퓨터 입장에서 이러한 룰을 정한 것은 어쩌면 CS적 의도이므로, 이게 꼭 나쁜건 아닐 수 있다. 하지만 결국 그 한계를 정해 놓고 나니 생기는 불편함, 그리고 그…

개요 프로젝트의 목표, 범위, 기능을 정의하는 문서로, 프로젝트의 근간이 될 문서를 작성해야 한다. 필요 문서 요구사항 명세서 : 프로젝트의 목적, 목표, 기능, 사용자 요구사항을 상세히 기술해보는 연습을 한다. 유스케이스 : 사용자와 시스템 간의 상호작용을 기술하여 기능적 요구사항을 명확히 하는 역할을 한다. 요구사항 명세서를 잘 쓰기 위해… 요구사항 명세서(SRS, Software Requirements Specification)은 요구사항 정의서, 요구사항 기술서와 같은 문서로 봐도 된다. 스타트업 내부 의견을 정리하기 위해 작성하는 것이 좋다. 왜 작성해야 하나? 프로젝트 전체 규모를 파악 구현 가능 여부에 대한 논의 커뮤니케이션 비용 절약 프로젝트 일정 계획 수립 요구사항 명세서의 종류 기능적 요구사항(Functional Requirements) 기능적 요구사항은 기능들을 설명한다. 비기능적 요구사항(Non-Functional Requirements) 비기능적 요구사항은…

만들어보자 내가 직접 만드는 블로그 나의 기술 블로그를 만든다. 그러나 여기서 풀스택으로 준비를 해보도록 하며, 우선 백엔드 개발 이후 프론트 쪽을 공부하면서 학습한 내용을 기반으로 개발을 진행해본다. 장기 프로젝트로 생각하고 좀 천천히 진행하면 좋을 듯, 대신 기본적으로 해본 것들은 강화시키고, 안 해본걸 먼저 구현해보는 것을 핵심으로 삼았으면 한다. 백엔드 쪽은 아름다운 설계를 추구하고 설계를 해보도록 노력해보자. SOLID 원칙을 지키면서 간단하게 구현해보자. 프론트는 구현 자체에 집중하는 구조를 하되, 프론트엔드에서 사용되는 주요 기술을 아는게 중요할 것 같기도 하다. 필수 기능들은? 내가 로그인해서 쉽게 사용이 글 작업이 가능해야 한다. oAuth 문서 작업이 가능한 기능들로 구현하고 싶은데, 좀 더 유연하게 글 쓸 수 있으면 좋겠다. 문서기능 썸네일 미리보기 기능 댓글 기능 게시판 형태 기능 게시판 추가 게시판 삭제 게시판 수정 글에서 이미지 최적화 기능 최대한 빨리 이…

개발 단계 개발 초기 개발 중기 개발 후기 런칭 본문 개발 단계 개발 초기 개발 중기 개발 후기 런칭

Peer 프로젝트, 전반부 마무리, 다음을 고민하기 전에 정리해보자 본 글은 프로젝트의 전체 과정을 정리하고자 쓰여진 글이다. 그렇기에 정확하게 기억을 하고, 프로젝트를 설명 할 때의 기초가 되도록 하기 위해서이다. 앞으로의 프로젝트는 다른 방향성을 가질 지도 모르지만, 반성과 성장은 언젠가 도움이 될거니깐! 다소 딱딱하고 재미없는 글이지만, 남을 위한 글이 아니라 나를 위한 글이라는 점 양해 바란다. 구성 단계 피어의 시작은 심플한 기획과 함께 했다. 동료 학습, 협업, 이걸 위한 커뮤니티가 피어의 주인장이 가지고 있는 생각이었다. 스케일 업을 하고 싶었고 커뮤니티화 되는 것을 보고 싶다고 생각했다. 그렇다면 유저는 확대 재생산 될 수 있어야 하며 커뮤니티는 생동력이 있어야 한다는 본질적인 행동을 유도해야 했다. 그렇다면 필요한 게 뭔가를 고민했다. 결론은 심플했다. 팀업이 재생산 될 원초적 심리는 뭘까. 프로젝트, 스터디를 같이 하는 이유를 극대화시켜야 한다는 생각에 집중하게 …

Next Peer 를 위한 고민 : 시작 피어 웹 서비스의 구현의 목적은 총 3단계로 구성되어 있다. 기획의 핵심은 순환이다. 프로젝트, 스터디의 핵심은 결국 계속해서 타인과 타인 사이에서도 남아야 하며, 만드는 사람들은 목적을 쉽게 달성하며, 동시에 쉽게 자기나 자신의 결과물을 잘 보이는게 핵심이다. 그걸 위해 시작하는 모집글 작성에서 시작하여 협업을 위한 허브 역할의 팀 페이지와 게시판, 쪽지, 그리고 최종적으로 쇼케이스나 피어로그와 같은 것들이 협업의 과정에서의 순환과 결과물의 공유와 강조 등을 포함한다. 그런 전체 목표 중에 다음 주 중에 공개될 피어 웹 어플리케이션은 대략 2.3~4 단계정도의 진행 정도를 보여준다. 핵심적인 기획은 아직 적용이 안되어 있으며, 특히나 프론트의 딜레이와 버기한 상황들은 앞으로 해당 내용의 확장, 혹은 진화에 조금 더 시간이 걸릴 것으로 보인다. 어쨌든 프론트의 딜레이와 보안을 하려고 하다보니 시간이 남게 되었고, 덕분에 조금 더 백엔드 구…