Poemable side project(2)

오형근·2022년 5월 4일
0

Project

목록 보기
2/10

4월 한달 간 매일 조금씩 프로젝트를 개발하고자 했다. 시간이 많이 투자된 것은 아니지만, 간단하게나마 전체 기획부터 CI/CD 파이프라인 구축까지 구현할 수 있었다. 덕분에 DevOps에 대한 지식도 쌓고, 흥미가 생긴 것 같다. 각설하고, 지금부터 프로젝트에 대한 얘기를 천천히 풀어보려고 한다.

시작

프로젝트의 시작은 취미였던 시 쓰기에서 출발했다. 인스타그램에 올린 시가 약 40편 정도였고, 이 시들을 게시할 수 있는 공유 시집과 같은 서비스가 있었으면 좋겠다고 생각했다. 물론 운영되는 시 관련 서비스가 많지만, 사람들에게 시 쓰기의 매력을 말해주고 시 쓰기를 장려하고자 하는 목적을 가진 서비스를 내가 직접 구축하고싶다는 마음이 커 프로젝트를 기획하게 되었다.

처음에는 노션에 기획본을 작성했다. 이전까지는 무언가를 제작할 때 코드의 반복이나 재사용성과 같은 디자인 패턴, 가독성 좋은 코드에 대해서는 전혀 고려하지 않은 채 코드를 작성했었는데, 이번부터는 이를 기획단계에서 충분히 고려해야겠다는 생각을 하였다.

공유시집 페이지 제작하기(노션 정리본)

구현하고자 하는 기능들과 유저 동선을 생각한 뒤에 정리해서 적어두었고, Figma로 어떤 형태의 디자인이 나올지 그려보았다.

CI/CD와 애자일

이번 프로젝트에서 중점을 둔 것은 애자일 방법론에 입각한 개발이다. 서비스에 버전을 붙이고 매 업데이트마다 버전을 업그레이드하며 그 내용을 기록하는 것이다. 그렇기에 처음 출시는 간단한 CRUD 정도만 구현된 상태에서 이루어졌다. 이후 내가 추가하고 싶은 기능들이나, 주변인들에게 받은 조언을 참고하여 추가 업데이트를 진행하려고 한다. 그렇기 위해서는 CI/CD 파이프라인 구축이 필요했고, AWS-Amplify를 이용하여 파이프라인을 구축하는데 성공했다. Git commit 만으로 이루어지는 배포라니! 클라우드 컴퓨팅의 맛을 제대로 봐버렸다.

서버리스 개발

프로젝트를 하면서 배운 큰 줄기 중 하나인 서버리스 개발도 할 얘기가 많다. Poemable 서비스를 개발하면서 AWS AppSync를 이용하여 API를 제작 및 연동하였고, 이를 프론트엔드와 직접적으로 연결해 별도의 서버 구축 없이 DynamoDB와 소통할 수 있도록 했다. 이번 개발을 발판으로 타 서버리스 툴들도 도전해보고(FaunaDB 등), AWS에 있는 다른 서비스들도 능숙해지도록 공부하고 싶다는 생각을 하였다.


그렇게 만들어진 서비스의 큰 Configuration은 다음과 같다.

F.E. | React, SCSS Module, Styled-components
State Management Tool | ContextAPI(React built in method)
B.E. | AWS-AppSync, Graphql
Database | DynamoDB
Infra | AWS-Amplify

이 외에도 자잘하게 다양한 라이브러리를 끌어다 썼지만, 큰 줄기는 이정도이다.
이제 각각을 사용한 계기나 후기를 말하고자 한다.

React

리액트는 SPA 개발을 위해 내가 가장 능숙하게 다룰 수 있는 툴이었다. 물론 Svelte를 못 쓰는 것은 아니지만 React에 대한 개념을 굳히고 싶었고, 뒤에서 언급할 ContextAPI를 경험하고자 해서 사용하였다.

SCSS Module

컴포넌트 마다의 style을 어떤 방식으로 관리할지에 대해 고민이 많았다. 이미 많이 쓰이는 다양한 방법들이 있었고, 유명한 라이브러리 중 하나인 Styled-components는 저번에 충분히 사용해보았다고 생각했기 때문에 이번에는 Module을 활용해 하나의 파일에서 style을 관리해보고자 하였다.

실제로 사용하면서 좋았던 점은, 컴포넌트마다 파일에 JSXstyle이 같이 써 있어혼잡했던 것을 하나의 파일에 style만 따로 관리할 수 있어 파일 간 style 비교가 수월했다는 것이다. 또한 백틱을 사용해 작성하지 않으니 SCSS Extension의 도움을 충분히 받을 수 있다는 점도 좋았다. JSX 파일에는 JSX 코드만 담을 수 있다는 점도 장점으로 생각된다. 나는 아마 앞으로도 style 모듈화를 더 선호하지 않을까 싶다...

Styled-Components

그럼에도 Styled-Components는 부득이한 상황에 빛 같은 존재로 다가온다. style 모듈화를 시킨 시점에서도 전역 Context에 따라 달라지는 Style을 구현하기 위해서는 Styled-Components를 이용한 Context 전달이 필수적이었다. 이러한 경우 Styled-Components는 아주 큰 도움이 되었다. 앞으로도 이처럼 SCSS Module을 기반으로 특정 상황에서 Styled-Components를 이용하는 방법이 사용될 것 같다.

Context API

최근에 작성한 글에서 설명이 잘 되어 있다. 여타 상태 관리 라이브러리와 견주어 큰 단점을 발견하지 못했고(작은 프로젝트라 그럴지도...) 앞으로도 기회가 되면...? 사용할 것 같다. 내장 메소드를 사용해 의존성을 낮추는 것은 언제나 좋으니까!!

AWS-AppSync + Graphql

AppSync를 이용해 API를 구축하는 것은 생각보다 어렵지 않았다. 이런 방법으로 간단하게 백엔드를 구축하고 DB 연동을 진행한다니! 서버리스 개발에 흥미를 크게 느낀 부분이었다. 서버리스 개발이 얼마나 좋은 기술인지 생각하게 되었다. 물론 서버에서만 진행 가능한 다양한 기능들을 못 사용한다는 것은 단점이었지만, AWS의 다른 서비스들이 워낙 탄탄하고 이를 쉽게 연동 가능하다는 점은 스타트업들에게 분명히 희소식일 것이다.

Graphql은 내가 본래 공부해보고 싶은 쿼리 언어였다. 스택 간의 차이점을 분명히 인식하고 상황에 맞는 스택을 선택하는 것은 개발자의 기본 소양이라고 늘 생각하기 때문이다. REST API를 이용한 개발은 좋고 잘 쓰이지만, GQL을 이용한 overfetchingunderfetching 방지는 GQL만의 강력한 무기라고 생각된다. 또한 AppSync를 이용하면 GQL을 쉽게 구현하고 사용할 수 있으니, 개발하는 내내 배우는 즐거움이 계속되었다.

AWS-Amplify

웹 앱을 구축하기 좋게 설계되어있고, 별도의 큰 설정 없이 몇 분 만에 CI/CD 파이프라인을 구축한다는 것은 엄청난 장점이고 나에게 재미 그 자체였다. AppSync를 이용해 배포한 백엔드가 있으면 이를 연동해 빠르게 웹 앱을 빌드할 수 있었다. AWS 간의 기능을 쉽게 연동하고 이용할 수 있다는 것이 큰 장점이 되는 것 같다. 이후에는 Github Action 등의 다른 툴들을 이용한 파이프라인 구축도 공부하고 싶다.


이번 프로젝트는 AWS에 대한 맛보기와 GQL 공부를 위해 시작하였다. 그러나 결과적으로는 DevOps에 대한 관심도가 크게 증가하였고 관련된 공부를 더 이어나가고 싶어졌다. 그래서 당장 다음에는 Golang을 공부하고자 하는 목표가 생겼다.(물론 ts 먼저...)

결과적으로 앞으로 공부하고 싶은 과제들은 다음과 같다.

  • typescript, go, svelte
  • vite와 같은 롤업 기반 번들러
  • IaC(Terraform...)
  • 컨테이너 (Docker, Kubernetes)
  • TDD, DDD
  • AWS
  • Recoil, mobX
  • Node, Deno
  • 디자인 패턴
  • 네트워크
    ....

하여간 욕심은 정말 많다. 천천히 조금씩 해보자.

아, 위의 공부를 진행하면서도 기회가 될 때마다 Poemable에 대한 업데이트나 리펙토링도 진행해보고자 한다. Be Agile!

profile
eng) https://medium.com/@a01091634257

0개의 댓글