커뮤니티 서비스 검색 API 개발기 (1)

오늘은 요즘 개발하고 있는 학교 커뮤니티 서담의 검색 Extension의 개발기를 이야기해보려한다.

시작하게 된 계기

평소처럼, 혼자서 프로젝트를 하던 와중 동아리 단톡방에서 학교 선배가 같이 프로젝트를 진행 할 사람을 구한다는 글을 보았다.

그 프로젝트는, 우리 학교 커뮤니티 서비스인 서담의 검색 전용 구글 크롬 Extension 개발 프로젝트였다.

일단, 서담은 Django로 개발되어 있는데 현재 총 글이 70만건 정도 되어가고 서담 사이트내에서 검색이 원할하지 않다는 특징이있다.

사람들이 제일 많이 사용하는, "익명게시판 2"는 글이 제일 많고 어떤 검색어에 대한 검색 쿼리를 날리면 결과를 받을 때 까지 보통 15초~30초 정도의 시간이 걸리니.. 이미 말 다했다.

심지어 서버에 부담이 된다고 현재는 본문 검색도 지원하고 있지 않은 상황이였다.

그래서 이것을 해결하고, 더 좋은 검색을 위한 프로젝트인 가칭 "서담서치"의 개발을 동아리 선배가 제안하였고, 그 제안을 받아들여 프로젝트를 시작하게 되었다.

내가 맡은 파트

일단, 프로젝트를 진행 할 인원들을 다 모으고나서 파트 분배를하였는데 파트는 아래와 같이 나뉘었다.

• Crawling 파트
• Elastic Search 파트
• API 파트
• Front-End 파트

내가 맡은 파트는 역시나 평소에 자주하고 관심있는 Backend API 구축이다.

그 후, 각 파트에대해 필요한 기본 기능에 대해 PM을 맡은 선배에게 브리핑을 받고 API 설계에 들어가게 되었다.

API 설계 및 기반 잡기

제대로 된 API 설계를 위해서 처음부터 계획을 잡고 시작하는게 좋을 것 같다고 생각하여, 아래의 글을 참고하여 API 설계를 시작하였다.

참고 자료 - 백엔드가 이정도는 해줘야 함

1. 버전 관리는 Github를 사용하기로 했다.

   • 평소에 개발 할 때는, 전부 main 브랜치에 때려박는 안좋은 습관이 있었다.
   • 이번에야 말로 GitFlow를 따라서 개발하고 싶었고, 그 방법을 따라서 개발하기로 했다.
   • Youtrack에서 이슈를 생성하고, 그 이슈에 해당하는 feature 브랜치를 만들어서 개발했다.
   • 그 후에 PR을 올리고, review를 받은 뒤 Merge하는 방식을 선택했다.

2. 이슈 트래킹을 위해서, 협업 툴로 Youtrack을 사용하기로 했다.

3. API를 그냥 그대로 쓸 수는 없기에, 웹 서버 및 Reverse Proxy로 NginX를 선택했다.

4. API 구현 형태는 REST API의 형태를 제대로 만들기 어렵다 판단하여, 일단 HTTP API로 선택했다. 응답형식은 현재 가장 많이 사용하고있는 JSON을 선택했다.

5. DB는 라즈베리파이에 부담이 되지 않을 가벼운 DB가 필요했고 SQLite3를 선택했다.

   • API의 DB에는 유저 정보와 쿼리 정보 이외에는 저장 할 정보가 없기 때문에 문제 없다고 생각하여 선택하였다.

6. Authentication을 위한 인증방식은 JWT를 사용하기로했고, Access Token과 Refresh Token 모두 사용하기로 정했다.

7. 유저가 서담의 회원이여지만, 검색이 작동 될 수 있도록 해야 했기에 서담 회원임을 인증 할 수 있는 방법을 생각했어야했다.

   • 처음에는 이걸 어떻게 할지 고민이 많았는데.. ( 서담에서 인증할 수 있는 OAuth 같은 것을 제공하지 않으니.. )
   • 예전에, 같은 동아리 분인 shiftpsh님이 처음에 solved-ac를 만들었을 때 사용한 방법이 생각나 그 방법을 참고하기로 했다. 심지어 그걸 블로깅까지 해놓으셔서 참고하기 좋았다.
   • 참고 자료 - solved ac 개발기
   • 위 방법을 참고하여, 미리 작성되어있는 인증용 게시물에 인증용 문자열을 댓글을 달고 그 후 API 서버가 5분뒤 크롤링을 통해 체크하여 유저의 권한을 정회원으로 바꿔주는 작업을 할 수 있도록 진행하였다.

8. API 버전과 End-point 설계

   • 버전은 {API_URL}/{version}/{END_POINT}와 같은 방식으로 관리하기로 마음 먹었다.
   • 새로운 버전이 올라가더라도, 이전 버전을 일단은 유지하여 update하지 않았을 수도 있는 Extension이 문제없이 돌아가도록 이전 버전도 그대로 유지하도록하였다.
   • End-Point는 위에서 말했듯이 HTTP API를 구현하기로 했지만, 그래도 REST 형식에 맞추고 싶었기에 최대한 그 방식에 맞추기로 했다.
   • REST 관련 자료는 아래 링크가 제일 잘되어 있는 것 같다.
   • 참고자료 - REST

9. API 응답 설계

   • API가 응답을 했을 때, 매 End-Point마다 다 다른 형식으로 대답을 주면 프론트엔드 입장에서 힘이 들 수 있다고 생각하여 API 응답형식을 하나의 spec으로 정해보기로 했다.
   • 포맷은 여러 형식이 있었는데, 제일 간단하고 파악하기 쉬운 Jsend 방식을 따르기로 했다.

10. 개발 언어 및 프레임워크 및 ORM 정하기
    아래와 같은 생각을 하였고, 결국 Javascript, Express, Prisma를 선택하였다.

    • Server 환경이 라즈베리 파이를 사용하기 때문에, Spring은 X
    • 생산성을 생각하면 express를 선택하는 것이 개발 속도가 빠르게 나온다. 하지만, express는 swagger 문서 작성이 너무 힘들다...
    • FastApi 안해봤다. 하지만, 예제를 보니 할만 할 수도 있다고 생각이 든다.
    • Django는 너무 과하고, Flask는 너무 가볍다.
    • 무슨 ORM을 쓸 것인가?
      • Express → Sequelize 혹은 Prisma인데, 개발하기에는 Prisma가 편하니까 Prisma로 가자.
      • FastApi → SQLAlchemy 를 쓰는 것 같은데, 이것도 안써봐서 모르겠다.

    → 아무리 생각해봐도 평소에 자주쓰던 Express 써야 할 것 같다.
    -> Express에 swagger도 붙여서, 프론트엔드 파트에서 쉽게 API를 사용 할 수 있는 documentation 작성도 하기로하였다.
    -> 이 부분은 주관적인 생각이 꽤 많이 들어갔으니, 자신의 생각과 다를 수 있습니다.

11. 개발 방법론

    • 이 API를 개발하기 전에, TDD에 대해 공부를 해보았고 간단하게 사용해본적밖에 없었다.
    • 이번 개발에서는 TDD를 한 번 적용해보고 싶다는 생각을 했고, 실제로 적용하여 개발하는중이다.
    • Test용 프레임워크로는 Jest와 Supertest를 통해 진행하기로하였다.
    • TDD를 한 달여간 사용 해본 후기는
      • 일단, 테스트 코드 작성은 생각보다 더 어렵다.
      • 하지만, 작성해놓은 뒤 실제 코드를 작성하고 테스트를 진행하여 통과하면 기분이 좋다.
      • 평소에 놓칠 수 있었던 부분도 한 번 더 체크 할 수 있는 기회가 있다.

12. 배포 방법

    • CircleCI를 사용하여 CI/CD를 진행하기로 했다.
    • feature branch로 PR을 올리면, 자동으로 CircleCI가 테스트를 진행하게 설정하였다.
    • 그 후 PR이 완료되어 merge되면, CircleCI가 배포까지 진행한다.
    • CI/CD를 진행 할 때는, Docker 컨테이너를 이용하기로 하였다.
    • main 브랜치에 merge되면, 테스트가 진행된 후 배포 쉘 스크립트가 작동하고Docker가 서버에서 build된 후 새로운 컨테이너로 교체되도록 하였다.
    • Docker 내부에서는 PM2로 API 프로세스를 관리하여, 중간에 API가 crash되어도 auto restart 될 수 있도록 설정하였다. 또, PM2에서 로그를 남겨 Docker 볼륨을 통해 로그를 저장 할 수 있도록 설정하였다.
    • CircleCI, Docker 그리고 PM2 관련 글은 velog에도 올려놓았으니 참고해보자.

현재 개발하면서 느끼는 점.

백엔드는 생각하는 것보다 신경써야 할 것이 엄청나게 많고, 모르는 기술과 개발 방법론을 알아가면서 개발을 하는 것은 언제나 흥미로운 것 같다.

현재 개발중인 이 API가 실제로 production에서 작동 할 때 어떤 문제가 발생 할지는 모르겠지만, 최대한 API에 문제가 생기지 않게 하나하나 꼼꼼히 체크하면서 개발해야겠다.