어느덧 24년이 하루 남았습니다. 매번 느끼지만 23년 역시 빠르게 지나간 것 같습니다.
글을 쓰고 있는 지금은 30일인데, 글이 올라가는 시점은 31일이 되지 않을까 싶어서 제목을 저렇게 정해봤습니다.
🖥️ 고등학교 그리고 대학교에서도 이어집니다
2년 전, 고등학교에서 학과 인트라넷을 만드는 프로젝트를 진행했습니다.
학교와 함께 클라우드 서버와 도메인을 지원받고 정식 동아리로 발전시켜 서비스 오픈까지 했었습니다.
이번에는 대학교입니다. IT동아리에 들어가서 백엔드 파트로 프로젝트를 진행하게 됐습니다. 어쩌다 보니 다른 과를 지원하게 됐는데, 학과 졸업인증 관리 서비스입니다. 기존 졸업인증(졸업 신청 및 심사)은 엑셀과 수기로 관리하고 있고 자료가 파편화돼 있는데 이를 합치고 웹으로 관리할 수 있게 만드는 프로젝트입니다.
프로젝트의 주요 기능을 정리하면 아래와 같습니다:
- 졸업 심사 신청 (+ 첨부파일 업로드)
- 졸업 심사 승인, 거부
- 졸업 심사 일정 관리
- 졸업 심사 외 기능 (게시판 등등...)
기능들을 보면 순수 CRUD이었고 실제 개발할 때도 크게 복잡한 부분이 없었습니다. 다만, 이번 프로젝트에서는 유지보수를 목표로 잡고 개발했었습니다. 고등학교 했던 프로젝트보다 훨씬 기대 수명이 큰 프로젝트였기에 쉽게 기능을 붙이고 뺄 수 있었어야 됐습니다.
'유지보수를 쉽게 하려면 어떻게 해야 할까?'라고 고민하던 중 단순히 생각한 게 '의존성을 줄이자'였습니다. 프로젝트 기능이 적으니까 쉽게 의존성을 줄일 수 있고, 의존성을 줄이면 기능을 넣고 빼기에도 편해지지 않을까 생각했습니다.
의존성 관리는 프레임워크의 도움을 받았습니다. 해당 프로젝트는 Java를 베이스로 하고 있고 Java와 함께 유명한 프레임워크인 Spring과 DI 방법론을 사용했습니다. 유지보수와 관련해서 프로젝트 구조를 찾아보니 클린 아키텍처, 헥사고날 등 여러 아키텍처가 있었습니다.
헥사고날 아키텍처는 요악하면 입력, 출력용 Port를 만드는 아키텍처입니다. 이 역시 좋은 아키텍처이지만 정해진 시간 안에서 배우고 적용하기에는 무리가 있었습니다.
결국 적용한 구조는 클린 아키텍처입니다. Entity(Model), UseCase, Presentation으로 분리하여 개발했습니다.
이와 함께 SOLID 원칙 중 다섯 번째 DIP(의존성 역전; Dependency Inversion Principle) 방법론을 활용했습니다. 모든 Usecase 앞에는 Interface를 놓았고 비즈니스 로직이 변경될 일이 있으면 Interface를 구현한 로직만 변경해 주면 됩니다.
다만, 클린 아키텍처를 제대로 학습해서 적용했나?라고 질문하면 완벽하게 대답하지는 못할 것 같습니다. 글을 쓰는 지금도 클린 아키텍처를 공부하면서 함께 글을 쓰고 있습니다. 공부하면서 많이 놓친 부분이 많았고 기회가 된다면 다시 공부해 볼 계획입니다.
백엔드 유지보수와 함께 배포 환경의 유지보수도 중요했습니다. 원래 계획은 Docker를 사용해서 배포 방법을 문서화시키는 거였는데.. 아쉽게도 학교 내부 이유로 Docker를 사용할 수 없었습니다.
PM2와 Shell Script를 활용하는 걸로 계획을 바꿨습니다. PM2는 쉽게 백그라운드에 서버를 올릴 수 있고 자동시작도 간편하게 설정할 수 있도록 도와줍니다. 배포 과정을 Shell Script로 작성해 두면 자세한 배포 과정을 몰라도 Shell Script를 실행해서 쉽게 배포할 수 있게 됩니다.
(23년 12월쯤 서비스 릴리즈를 했는데, 이 자리를 빌려서 같이 한 동아리원들께 감사 인사를 드립니다 🙇)
✈️ 대한민국을 지키는 가장 높은 힘
대한민국을 지키는 가장 높은 힘, 공군에 입대하였습니다.
목표는 군대에서도 개발하려 했지만, 개발병은 아쉽게도 떨어져서 대안으로 일반 전산병으로 들어갔습니다. 입대 후에는 시간이 굉장히 많아졌습니다. 공군 특성일까요? 자기 개발 할 수 있는 시간이 충분히 보장됐습니다.
이 빈 시간 동안 뭘 했는지는 아래에서 소개해보겠습니다.
📚 책을 읽기 시작했습니다
최근 몇 년 동안 자의적으로 책을 읽어본 적이 적습니다. 읽어도 전공이나 교양 수업을 위해 책을 읽은 게 끝이었습니다. 노는 시간이 아까워서 오랜만에 책을 읽어봤습니다.
종이책, 전자책 다양하게 샀는데 아직도 뭘 주력으로 할지 고민입니다. 종이책의 넘기는 감성이 마음에 드는데, 무게나 편리함을 생각하면 전자책이 압승이었습니다. (이미지로 올린 두 책은 종이책으로 읽었습니다)
클린 아키텍처, 클린 코드 책이 왜 그렇게 유명한지 궁금해서 직접 읽어봤습니다. 그 외에도 가상 면접 사례로 배우는 대규모 시스템 설계 기초, 타입으로 견고하게 다형성으로 유연하게 책들을 읽어봤고 실용주의 프로그래머하고 Real MySQL도 읽어보고 있습니다.
(SW마에스트로 전자도서관 덕분에 제 책 값을 아꼈습니다. 고마워요!)
글을 쓰고 있는 지금 '가상 면접 사례로 배우는 대규모 시스템 설계 기초' 두 번째 시리즈가 나왔다는 소식을 들었습니다. 이 책도 사서 읽어볼 계획입니다!
🎲 토이 프로젝트를 해봅시다 - Marble
토이 프로젝트도 해보고 있습니다.
보드게임 중 주사위(그래서 프로젝트 이름을 Marble로 정했어요)를 던져 도시에 가고 땅이나 건물을 사거나 벌칙을 수행하는 경제 게임이 있습니다. 이를 모방해서 웹 기반으로 보드게임을 만들어보고 있습니다.
프론트엔드는 React, 백엔드는 NestJS를 사용하고 있습니다. 토이 프로젝트 또는 취미로 하는 프로젝트의 장점은 원하는 스택을 마음대로 적용할 수 있는 거라고 생각합니다. Marble 역시 원하는 스택과 방법론을 적용해보고 있습니다.
Turborepo로 모노레포를 구축하여 프론트엔드와 백엔드 저장소를 같이 관리하고, 쓰기와 읽기 작업을 분리하는 CQRS 패턴도 적용해보고 있습니다. 나중에 기회가 된다면 CQRS에서 발전해서 이벤트 소싱(Event Sourcing)을 적용해 볼 계획입니다.
NestJS와 함께 Nestia라는 라이브러리도 함께 적용해보고 있습니다. 기존 백엔드와 통신 방법이 직접 API 주소를 호출했다면, Nestia는 백엔드 코드를 기반으로 AJAX 요청 코드를 만들어주는 라이브러리입니다. 만들어진 API 라이브러리를 모노레포와 함께 사용하고 프론트엔드에서 API를 호출하고 있습니다.
ORM은 Prisma를 사용하고 있습니다. 기존에 Prisma도 써보고 Sequelize, TypeORM도 써봤는데 모두 장단점이 있지만 제일 마음에 들었던 건 Prisma인 것 같습니다. Prisma 역시 모노레포를 활용해서 따로 데이터베이스 스키마를 관리하고 있습니다.
주제가 게임이다 보니 유저 정보, 게임 상태는 어떻게 관리할까? 프론트엔드 디자인이나 음악은? 등 기술 내외적으로 여러 고민을 하고 있습니다. 게임 상태 관리에 대한 답으로는 Redis를 골랐습니다. 백엔드 서버에서 자체 오브젝트로 관리하면, 혹시라도 서버 스케일아웃을 하게 될 때 복잡해지지 않을까 생각했습니다.
MVP만 빠르게 만들고 올해 안에 게임이라도 되게 해 보자! 하고 프로젝트를 시작했는데 아직도 한 참 남았습니다... 😅
Marble은 오픈소스 프로젝트로 진행하고 있습니다. 관심 있는 분들은 아래 깃허브에서 확인할 수 있습니다!
https://github.com/SkyLightQP/marble
GitHub - SkyLightQP/marble: 웹으로 구현한 도시건설 보드게임
웹으로 구현한 도시건설 보드게임. Contribute to SkyLightQP/marble development by creating an account on GitHub.
github.com
✏️ 블로그 글도 열심히 써볼게요
올해 블로그 글. 2022년 회고록을 빼면 무려 0편을 썼습니다.
써보려고 계획한 글들이 몇 개 있는데 실천에 옮기지는 못 한 게 아쉽습니다. 2024년에는 한 편이라도 글을 써볼 계획입니다. 작심삼일이라는 말이 있지만, 작심삼일을 10번이나 반복하면 1달이 지나가니까 괜찮을 거 같습니다.
블로그에 비해서 글은 썼지만 그래도 부족한 Today I Learned도 있습니다. (https://til.skylightqp.kr/)
TIL 역시 24년에는 열심히 써볼 계획입니다.
마무리
DevOps, Infrastructure 쪽을 깊게 배워보고 싶어서 알아보고 있습니다.
몇 년 전부터 k8s가 빠르게 올라오고 있고 알고 있으면 언젠가 도움이 되는 기술이 아닌가 싶습니다. Docker를 배울 때는 거부감 없이 배웠는데 k8s 시작하기가 참 어려울 것 같습니다. AWS도 깊게 배워보고 싶어서 udemy에서 강의 영상을 구매했습니다. 실제로 보고 공부해야 될 텐데 강의 수집이 될까 봐 걱정입니다.
아, 그리고 블로그 댓글 시스템을 GitHub기반으로 변경했습니다! 물론 티스토리 자체 댓글 기능을 못 쓸 뿐이지 기존 댓글 내용은 남겨놨습니다.
벌써 2023년이 지나가고 2024년을 앞두고 있습니다. 그럼, 모두 새해 복 많이 받으세요! 🙇
'회고록' 카테고리의 다른 글
| 졸업 그리고 입학 : 2021~2022 회고록 (0) | 2022.12.30 |
|---|---|
| 벌써 2021년? (1) | 2020.12.31 |
| 2019년 회고 (0) | 2019.12.31 |