본문 바로가기

개발 노트/Experience

사이드 프로젝트를 정리하며

728x90
반응형

사이드 프로젝트

 

개요

올해 2월 1일부터 11월 1일까지 사이드 프로젝트를 진행했다. 본업에서 할 수 있는 시도에는 여러 제약이 있었고, 그 한계를 본업 밖에서 풀어보고자 하는 목적이 있었다. 본업에서는 쉽게 경험할 수 없는 프로젝트 코드 아키텍처 구성과 다양한 기술 적용을 시도하며, 스스로 발전할 수 있는 시간을 갖기 위함이었다.

 

그런 관점에서 보면 이것저것 많은 시도를 해본 것 같다. 다만 프로젝트가 완성되어 유의미한 성과로 강조할 만한 결과가 없다는 점은 아쉬움으로 남는다. 사이드 프로젝트 치고는 꽤 긴 시간을 들였기에, 그동안 이 프로젝트에서 내가 어떤 시도를 했는지 남겨보고자 한다.

 

 

프로젝트 관점

무슨 프로젝트였나?

진행한 프로젝트는 “품앗이”이라는 이름으로 불리며 개발 관련 멘토링 플랫폼이다. 현업 개발자들에게 자유롭게 질문할 수 있는 플랫폼 개발이 목적이었다. 이후에는 그 안에서 취업 활동을 중심으로 한 유의미한 정보 제공이 추가되었다.

 

진행 방식

프로젝트는 스프린트 방식으로 진행했다. 초기에는 매주 1회 구글 미팅을 통해 진척 상황을 공유했고, 이후에는 격주 진행으로 변경했다. 변경 이유는 거창한 목적이라기보다는 각자의 개인 일정을 배려하기 위함이었다고 생각한다.

 

각자 진행한 내용은 KPT 회고 방식으로 공유했다. 프로젝트 특성상 결과물이 눈에 보이기 어렵다는 점에서, PM과 논의를 거쳐 도입한 방식이다. 노션에 회차별로 KPT 기준으로 정리해 두면, 미팅 당일 그 내용을 바탕으로 무엇이 이뤄졌는지 한눈에 파악할 수 있었고 꽤 효과적이라는 인상이 남는다.

 

또한 개발 관련 이슈는 Jira를 통해 관리했다. 티켓을 생성하고 상태를 추적함으로써, 현재 진행 중인 업무를 체계적으로 모니터링할 수 있었던 점도 장점이었다.

 

맡은 역할

프로젝트에서 맡은 역할은 백엔드 개발이다. 곁가지로 QA라던지 운영에 관련된 부분을 처리하기도 했다. 이 프로젝트를 개발하면서 시스템 구성을 크게 “플랫폼 정보 제공용 API”와 “알림 처리용 스케쥴러”로 구성했다. 추후 시스템을 역할에 따라 분리할 수 있으면 잘게 쪼개보려 구상 중이었는데 그 단계 이전에 프로젝트가 종료되어 목적을 달성할 수는 없었다.

 

결과나 성과

유의미한 성과를 내었다고는 할 수 없지만 굉장히 큰 특징인 부분 하나가 존재하는데 “실사용자 발생”이라는 점이다. 이는 PM이 외부에 프로젝트 소개를 할 수 있던 자리를 통해 달성할 수 있었던 목표였지 않을까 싶다.

또한 프런트 측에서 SEO 최적화를 통해 구글 검색 페이지 1페이지에 노출되었던 것도 성과라고 생각한다

 

 

프로젝트 개발 관점

사용 언어와 프레임워크

개발에는 Python 3.12와 FastAPI를 선택했다. Python은 익숙한 언어이며, FastAPI는 구조와 아키텍처를 개발자가 자유롭게 설계할 수 있다는 점이 가장 큰 선택 이유였다. Django는 강력한 기반 기술을 제공하지만, 그만큼 프레임워크가 정해준 구조를 따르는 경우가 많아 유연성이 제한된다.

 

반면 FastAPI는 이러한 제약에서 벗어나며, 내가 원하는 스타일로 핵심 로직과 기술 스택을 구성할 수 있다. 이러한 장점 덕분에 이번 프로젝트를 통해 달성하고자 했던 “코드 베이스 구성과 기술 실험”에 대한 부분을 충분히 시도할 수 있는 환경을 구성했다.

 

무슨 기능들을 개발했나?

프로젝트 개발 관점에서 내가 작업했던 부분들에 대해 기억에 남는 것들을 리스트업 해보자면 다음과 같다.

 

개발

국내 주요 테크 기업(네카라쿠배) 채용공고 자동 수집 및 실시간 알림 시스템 구축

  • 국내 주요 테크 기업, 일명 네카라쿠배의 채용 정보를 자동으로 수집하고 실시간 알림을 제공하는 시스템을 구축했다. Python 기반의 BeautifulSoup과 Selenium으로 각 기업 웹사이트를 주기적으로 크롤링하고, 기업별 최적화된 어댑터 모듈로 데이터 추출 정확성을 높였다. 수집된 공고는 MySQL에 저장하고, 새로운 공고가 등록되면 Firebase Cloud Messaging을 통해 실시간 푸시 알림을 전송해 구직자의 정보 탐색 시간을 최소화했다.

플랫폼 핵심 데이터 모델 설계 및 OAuth2 기반 인증·사용자·채용공고 API 구현

  • 플랫폼의 핵심 데이터 모델을 설계하고 OAuth2 기반 인증과 사용자 및 채용공고 관련 API를 구현했다. DDD 원칙에 따라 핵심 엔티티와 값 객체를 정의하고, SQLAlchemy ORM으로 MySQL 스키마를 설계했다. OAuth2와 JWT 기반 인증 및 카카오 소셜 로그인을 연동해 사용자 가입과 로그인 절차를 간소화했으며, FastAPI와 Pydantic으로 안정적 RESTful API를 제공해 프런트엔드 개발 효율을 높였다.

Python Gemini API 연동을 통한 채용공고 분석, 요약 및 핵심 키워드 추출 시스템 개발

  • Python Gemini API를 활용해 채용공고를 분석하고 요약하며 핵심 키워드를 추출하는 시스템도 개발했다. Gemini 모델을 통해 직무 내용, 자격 요건, 우대 사항 등을 3~5 문장으로 요약하고, 기술 스택과 요구 역량 등 핵심 정보를 추출했다. 배치 처리로 시스템 부하를 분산해 효율성을 높이고, 구직자가 빠르게 적합한 공고를 확인할 수 있도록 지원했다.

QNA 게시판 답변 실시간 푸시 알림 시스템(Firebase FCM) 구축

  • QNA 게시판에는 답변 실시간 푸시 알림 시스템을 도입했다. 게시판에서 새로운 답변이 등록되거나 수정되는 이벤트를 감지하고, Firebase Admin SDK를 통해 질문자의 디바이스에 FCM 알림을 전송했다. 알림에는 답변 일부와 QNA 게시글로 이동 가능한 딥링크를 포함해 사용자 편의성을 높이고, 커뮤니티 참여를 촉진했다.

Pytest 기반 핵심 기능 단위·통합 테스트 및 안정성 검증 체계 구축

  • 시스템 안정성을 위해 Pytest 기반 단위 및 통합 테스트 체계를 구축했다. 각 유스케이스와 도메인 로직을 단위 테스트로 검증하고, Mocking으로 외부 의존성을 분리해 테스트 독립성을 확보했다. 통합 테스트로 데이터베이스 연동과 API 호출을 검증했다. 개발환경에 PyCrunch를 사용해 코드 변경 시 테스트 코드 자동 실행 환경도 구성했다.

클린 아키텍처 기반 모듈화 코드베이스 및 확장성·유지보수성 최적화 시스템 설계

  • 클린 아키텍처 기반 모듈화 코드베이스를 설계하고 시스템 확장성과 유지보수성을 최적화했다. Presentation, Application, Domain, Infrastructure 계층으로 분리하고 도메인별 모듈화를 적용해 응집도를 높이고 결합도를 낮췄다. DI 컨테이너를 활용해 객체 의존성을 외부에서 주입하도록 설계, 테스트와 컴포넌트 교체의 유연성을 확보했다.

GzipMiddleware 적용 전후 API 응답 크기 비교를 통한 네트워크 효율성 및 클라이언트 성능 개선 분석

  • GzipMiddleware를 적용해 API 응답 데이터를 압축하고 네트워크 효율과 클라이언트 성능을 개선했다. Middleware 적용 전후로 Content-Length와 응답 시간을 측정한 결과, 대규모 응답 데이터에서 평균 70% 이상 데이터 크기를 줄여 전송 효율성을 높였다. 이를 통해 클라이언트 로딩 속도가 개선되고 서버 네트워크 자원 사용량을 최적화했다.

컨벤션

GitHub Actions + Gemini API를 활용하여 PR 리뷰용 템플릿을 설계하고 자동화하여 코드 리뷰 일관성 확보

  • 코드 품질과 문서화의 일관성을 높이기 위해 다양한 자동화 도구를 도입했다. 먼저, GitHub Actions와 Gemini API를 활용해 PR 리뷰용 템플릿을 설계하고 자동화함으로써 코드 리뷰의 일관성을 확보했다. 이를 통해 팀원 간 리뷰 기준이 통일되고, 중요한 검토 항목이 누락되는 문제를 방지할 수 있었다.

AI 기반 Commit Message 템플릿을 도입하여 일관된 커밋 기록 유지

  • 또한, 커밋 메시지의 일관성을 위해 AI 기반 Commit Message 템플릿을 도입했다. PR 생성 시 자동으로 커밋 메시지를 추천하도록 설정하여, 협업 과정에서 커밋 히스토리가 체계적으로 관리되도록 했다. 이 덕분에 코드 변경 내역을 추적하거나 분석할 때 훨씬 용이해졌다.

MCP를 적용하여 표준화된 DocString 작성 규칙 수립 및 문서화 품질 향상

  • 마지막으로 MCP(Maintainable Code Practices)를 적용하여 DocString 작성 규칙을 표준화하고 문서화 품질을 높였다. 함수와 클래스마다 일관된 DocString을 작성하도록 규칙을 정의하고 문서화함으로써 코드 이해도를 높이고, 유지보수와 기능 확장 시 발생할 수 있는 혼란을 최소화했다.

시스템

AWS(EC2(t2.micro)) 기반의 FastAPI 프로젝트 배포 구성 및 배포

  • AWS EC2(t2.micro) 환경에 FastAPI 프로젝트를 배포하고, 안정적인 서비스 운영을 위해 서버 설정과 배포 과정을 구성했다.

Locust를 활용한 API 성능 테스트

  • 배포 후 Locust를 활용해 주요 API 엔드포인트에 대한 부하 테스트를 수행하고, 성능 병목 구간과 응답 시간을 분석해 서비스 안정성과 효율성을 검증했다. 이를 통해 실제 운영 환경에서의 성능 최적화와 신뢰성 있는 API 제공 기반을 마련했다.

위에 나열한 항목 이외에도 상세히 정리하면 더 많은 걸 적을 수 있을 듯싶다. 그러나 그렇게 정리하면 한도 끝도 없을 듯싶어 위 선에서 정리는 마무리하고자 한다.

 

상기해 보니 꽤나 많은 일들을 처리한 듯싶다. 나열된 내용은 단순히 주어진 기능 구현을 넘어서 추가로 필요하다 싶은 요소들을 넣었기에 기억에 남는 내용이다.

 

이슈

이 단락에서는 기억나는 이슈 몇 개를 적어보고자 한다.

 

사용자 로그인이 불가했던 이슈

8월 13일 점심쯤에 실 사용자의 회원가입 버그가 있었다.

문제는 SQLAlchemy의 imperative mapping 방식에 있었다. 회원을 중심으로 여러 테이블을 추가하다 보니 테이블 간의 참조 관계를 설정하지 못해 발생한 이슈였다. SQLAlchemy의 imperative 방식은 domain mapping을 할 수 있게 지원되는데 해당 부분에서 이를 챙기지 못해 발생한 실수였다. 이러나저러나 본업에서 이런 실수가 있었다면 상당히 욕을 먹게 되지 않았을까 싶다.

 

크롤러의 데이터 참조 방식이 변하다.

시스템 구성 초기에 네카라쿠배의 채용공고 사이트를 분석해 크롤러를 만들었다. 사이트가 데이터를 참조하는 방식을 트래킹 해서 만든 것이라 사이트 구조가 변경되지 않는 이상 변할 일이 없을 것이라 생각했다. 이 때쯤만 해도 사이트 구조가 크게 변경될 것이라는 생각도 잘 안 했던 것 같다. 이로 인해 어떤 시점에 카카오 쪽에 데이터 수집이 실패한 로그를 종종 보곤 했다.

 

돌이켜보면 안일한 생각이기도 한 것 같다 굴지의 대기업은 채용 시즌에 따라 사이트의 구성이 바뀌기도 하고 채용 이벤트에 따라 사이트 구조에 변화를 주기도 한다. 단순히 상반기와 하반기로만 나눠보면 6개월마다 변경되는 셈이라고 볼 수 있다.

 

설령 변경되더라도 그때 가서 대처하자라는 낙관론이었는데 생각보다 주기가 빨리 찾아온다는 교훈을 얻었다. 다시 돌아가도 같은 선택을 할 테지만 크롤러를 만들 때 해당 사이트의 구조가 변경될 때 어떤 식으로 대처할까라는 계획은 세워두는 것이 핵심인 듯싶다.

 

 

마치며

https://github.com/poomasi/be-poomasi-api

 

GitHub - poomasi/be-poomasi-api

Contribute to poomasi/be-poomasi-api development by creating an account on GitHub.

github.com

 

진행되는 동안에는 본업 이외의 재미를 추구한다는 목적에서는 충분히 그 재미를 알 수 있던 프로젝트였다. 돌이켜보니 생각보다 많은 내용을 개발도 했고 그 경험들이 남았던 프로젝트다. 무엇보다 최근 학습한 내용을 중심으로 아키텍처를 구상하기도 하고 또 구현하면서, 실 사용자가 이를 이용한다는 생각에 실제로 일을 하는 것처럼 진행되었던 사이드 프로젝트다.

 

꾸준히 키워낼 수 있었으면 싶은 마음도 있지만 시작이 있으면 끝도 존재하기에 여기서 마무리된 건 어쩌면 당연한 수순 아닌가 싶기도 하다. 여러 일들이 있었지만 어찌 됐건 실 사용자를 받을 수 있을 만큼의 프로젝 트였던 건 그만큼 프로젝트에 참여한 멤버분들의 노력이 뒷받침되었기 때문이라고 생각한다.

 

사이드 프로젝트였다기보단 사이드 허슬에 가까운 활동이었다는 점을 마지막으로 이만 글을 마친다.

728x90
반응형