project
11 posts
[BTB] 데이터베이스 설계 문서

데이터베이스 설계 문서 들어가면서 공유 링크 ERD Cloud 를 활용해서 데이터베이스 모델링을 마무리 지었다. 아무래도 서비스 자체의 규모나 기능의 규모가 작다 보니 내용 자체가 방대하기 보단, 하나 하나의 디테일 적으로 어떻게 해야 할 지를 고민을 많이 했다. 효율성을 위한 부분, 특히나 블로그로써 기능적으로 문제 없다를 넘어서서 현재 가장 중요시 생각하는 ‘검색’을 위해 어떤 기능을 어떻게 넣을 지를 상당히 많이 고려했다. 구성 1 : 게시글 게시글의 핵심은 단순히 글을 작성한다가 아니라, 작성 도중에 사용자인 내가 사용을 그만두거나, 잠시 나가게 된다고 하더라도 다시 돌아왔을 때 다시 작성이 가능하도록 구성을 해 내는 것에 그 의미가 있다. 또한 핵심 중에 핵심으로는 글을 어떻게 블록화 하고, 향후 여러가지 프론트 기술을 접목시키거나 할 때 어떻게 이를 이끌어 낼 것인가에 대한 구조적 뒷받침이 되는가? 이며, 마지막으로는 검색을 위해 어떻게 데이터를 지정해야 하는지에 대한…

May 31, 2024
project
[BTB] 프로젝트 관리 일지

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

May 21, 2024
project
[B2B] 아키텍처 설계문서

아키텍처 설계문서 전체 아키텍처 영겁의 시간을 거쳐, 여러 이슈들을 파악했다. 무엇보다 핵심은 Docker, Kubernetes를 적용 시키는 것이 가능하도록 만들 수 있는가? 에 대한 문제를 내가 이해하고 짜는 것을 목표로 삼았다. 그렇게 기본적인 각 요소들이 어떤 식으로 연결되어야 할지, 그 구조가 이제는 좀 명확해진 것으로 보여지고 이를 문서로 정리하고자 한다. 핵심 기능 본 구조의 핵심은 아래와 같다. : Kubernetes를 활용하여 어떠한 클라우드 프로바이저, 로컬에서도 동작 가능한 설계, 세팅이 자동으로 설정되도록 만든다. : 기본적으로 Auto Scaling 은 HPA(Horizontal Pod Autoscaler)에서 제공해주는 기능으로 애플리케이션의 부하에 따라 자동으로 Pod의 수를 조절해주는 역할을 한다. 이를 통해 가용성의 극대화와 리소스 사용을 최적화해준다. 기본적인 전략 React 서버의 경우 SSR 을 지원하지 않고 기본적인 정적인 데이터들의 전…

May 20, 2024
project
[BTB] 파일 마이그레이션 기능 제작을 위한 고려

파일 구조 마이그레이션을 위한 고민 chatGPT와의 논의 사항 질문 나는 현재 기존의 정적인 블로그 사이트를 동적인 웹 어플리케이션 사이트로 구축하고 싶어. 기존의 파일들은 다음 내가 올린 파일 처럼 구조가 짜여져 있으며, 기존 데이터를 SQLite 데이터베이스에 입력을 시켜야 하는 상황이라서, 먼저 기존 데이터를 마이그레이션 시키는 기능을 어떤 식으로든 구현해야 하는 상황이야. 가장 편리한 방법으로 스크립트나 프로그램을 짜줘. 기존 문서에서 새로운 양식으로 변환하는 방법은 다음과 같아. 내가 지정한 디렉토리에서, md 파일들을 하위 디렉토리까지 전부 찾아서 탐색을 해야하고, 각 파일은 자기 자신이 있는 위치 기준, src 라는 폴더 안에 자기 문서 안에 쓰인 이미지가 들어있어. 이미지 링크를 발견하면, 이미지를 탐색 한뒤 이미지 사본을 내가 지정한 디렉토리로 옮길 수 있어야 해. 더불어 문서 앞에는 properties 가 존재 하는데 포팅을 위한 데이터 구조는 다음과 같아.(…

May 14, 2024
project
[BTB] 고민 정리 - 기존 파일의 관리 방법 & 이미지 처리 방법

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

April 06, 2024
project
[BTBP] 요구사항 명세서 및 유스케이스 작성

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

March 25, 2024
project
[BTBP] 취업을 위한, 동시에 내 실력을 위한 기술블로그 풀 스크레치 프로젝트를 구상해보자

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

March 13, 2024
project
[peer] 피어 개발 이야기 (2) - 개발 단계

Intro 본 글은 피어 개발의 과정에서 느낀 바, 알게 된 바에 대한 정리를 목적으로 하는 글이다. 과정에 있었던 상황과, 과정에서의 내 생각들이 담겨 있기에 peer 전체를 대변해주지는 않는다. 그러나 가능하면 공정하고, 상황 그대로를 묘사하려고 노력했음을 알아주길 부탁드린다. 개발 단계 개발 초기 기획의 끝이 보이지 않았다 개발이 시작되고 틀이 잡혀나가고, 팀 내에는 나름대로 드디어 시작이구나! 라는 생각이 감돌았다. 모두들 의욕이 올라 오는 게 보였기에 이제 할 일은 무엇인가? 에 대한 진지한 생각과 함께 개발에 임하게 되었다. 우선, 목표를 정확하게 전달할 필요를 다시 느꼈다. 무언가 스스로 해내는 경우는, 스스로가 자신 만의 목표에 몰입 될 때라고 나는 생각해왔기 때문이다. 그렇기에 프론트와 백 양쪽에 쉬운 목표들, 이루기에 어렵지않다고 판단되는 영역과 상당히 난이도 있는 영역, 크게는 두 줄기의 목표를 부여해 주었다. 프론트의 경우, 프론트엔드 개발의 핵심이라고도 할 …

February 23, 2024
project
]peer] 피어 개발 이야기 (1) - 준비 단계

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

February 23, 2024
project
[peer] 피어 알림 시스템 구축을 위한 고민 정리

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

February 09, 2024
backend
project
작성중

런칭과 찾아온… 1. 달성함 peer의 긴 개발 마라톤, 2월이 되자 드디어 그 끝이 보이기 시작했다. 런칭을 위한 수준은 부족해도 기능적으로 동작 가능한 수준을 지정했고 팀원들의 맡은 바는 하루 평균 수십개의 커밋이 올라오는 것으로 우리의 열정이 대변되는 것 같이 느껴졌다. 그렇게 드디어 라는 말이 나올 때 즈음, 나에게도 검은 구름이 찾아오고 있었다. TMI에 200%인 이야기지만 상황을 설명해야 하니… 조금 돌아가보고자 한다. 나의 아버지는 목사님이셨다. 이미 소천하신 몸이시지만 나름 자랑스럽게 생각하는 부분은 목사를 되고 마지막까지 농촌에서 일하시면서 농촌 소멸이라는 사실을 일찍이 느끼고 선교를 하시던, 정말로 대단하신 분이셨다. 그러나 문제는 그런 이상적인 일에 생각과 삶을 바친다는 것은 너무나 당연하게도 돈과는 거리가 먼 일이었고, 그런 여파는 나에게도 몰려왔기에 그렇기에 나는 사회학, 정치학 쪽의 석사 코스를 가기를 포기할 수 밖에 없었고 돈을 벌 수 밖에 없었다. …

May 18, 2000
project