[아이북조아] 최종 발표 자료 및 아이북조아를 마치며

'아이북조아'는 LG 유플러스 유레카 백엔드 비대면 1기 교육과정을 수료하며 진행한 종합 프로젝트이다. 

백엔드 팀원 6명이 모여 서버 사이드 렌더링으로 웹사이트를 구축하였고, 다음과 같은 좋은 성과가 있었다. 

 

 

이제 발표 자료 일부를 살펴보며, 프로젝트 회고를 진행해 보려 한다. 

 

이번 프로젝트의 잘한 점

1. 페어 프로그래밍 진행 (의사소통과 협업 능력 함양)
2. 애자일한 프로젝트 관리 (Jira, Slack, Github, Canva 등)
3. 확실한 성능 테스트 및 테스트 코드 작성
4. 이후 DB 관련하여 추가 테스트 및 조사 실시

---

먼저 페어 프로그래밍 진행이다. 

 

 

'아이북조아'는 2명&2명&2명 || 3명&3명 페어 프로그래밍으로 개발을 진행했다. 

페어 프로그래밍은 함께 코드 방향을 의논한 뒤에, 각자가 역할을 맡아 코드를 쓰고 리뷰하는 방식으로 진행하였다.

직접 진행해 보며 느낀 페어프로그래밍의 장점은 아래와 같다.

 

• 대화를 하며 더 나은 코드를 도출할 수 있다. 
• 모르면 바로 물어볼 수 있기 때문에 문제가 빠르게 해결된다. 
• 추후 개발 범위가 넓어지면 코드 리뷰가 어려워 지는데, 해당 내용을 아는 페어가 있기에 끝까지 적절한 코드 리뷰를 해줄 수 있다.
• 팀장이나 개발리드에게 질문이 몰리지 않아 개발의 속도가 향상된다. 
• 좋은 동료를 얻을 수 있다!!! 

아래는 페어와 함께 좋아요/싫어요 시, redis의 어떤 자료구조를 써야 추후에 mysql 이관이 쉬울지를 고민하며 작성한 노션 글이다.

redis의 다양한 자료 구조에 대해 살펴보고, 근거를 바탕으로 최선의 선택을 내리기 위해 노력했다. 

🧸 피드백 구현을 위한 Redis 구조 고민

🧸 회원의 성향 변화량이 Redis에 계속 쌓일 경우, 해당 데이터는 매우 커질 것으로 예상된다. 이 대용량 데이터를 어떻게 처리할 것인가?

 

---

 

두 번째는 프로젝트 관리 측면으로, 애자일 방법론을 사용하였다.

 

아래의 일을 통해 프로젝트의 일정과 각 세부 작업들을 확실하게 관리할 수 있었다. 팀원들이 스프린트에 맞춰 개발을 착실히 해 주어 일정 관리에 거의 어려움이 없었다. 

지라를 통해서는 다음의 과정을 통해 일정을 관리하였다. 

 

• 유저 스토리와 에픽을 구분하여 기능별 세부 작업 작성
• 플래닝 포커를 통해 스토리 포인트를 산정하여 작업의 복잡도와 우선순위를 설정
• 매일 짧은 스크럼을 통해 유연한 일정 및 우선순위 관리
• 매주 스프린트 계획을 세우고 목표를 설정하여 효율적으로 진행 상황을 관리
• 칸반 보드로 작업 상태를 추적

---

 

다음은 확실한 성능 테스트 및 테스트 코드 작성에 관련한 내용이다. 

 

 

파트너(승희님)와 함께 맡은 기능이다. 

 

• 좋아요/싫어요를 누를 경우, 책의 MBTI에 따라 회원의 MBTI가 변화한다. 
• 회원의 MBTI에 맞추어 매일 추천책 N권을 업데이트한다. 

이 기능을 구현하며 어려웠던 점은 아래와 같다. 

 

[기능 구현 관련 어려움]

• 회원의 MBTI가 0.1씩 변하는 모든 상황을 일일이 DB에 저장할 수는 없는 법. 어떻게 DB 접근을 최소화할 것인가?
  '성향 누적 변화량' 테이블을 두어 오늘의 변화량을 모두 합산한 다음 update하는 식으로 처리. 변화량이 5를 넘어가면 mbti를 변화시켜 서비스적 어색함을 제거하고(하루는 infp, 하루는 intp, infp, intp... 계속 변화하는 것을 막기) DB 접근을 최소화한다. 
• MBTI 검사를 실시하지 않았거나 or 성향을 삭제하는 바람에 성향이 없는 경우, 어떻게 책을 추천해 줘야 하는가?
  회원 가입 또는 모든 성향 삭제 시, 모든 점수가 50인 기본 MBTI를 부여한다. 
• 복잡한 성향 처리를 하나의 배치 안에서 끝낼 수 있는가?
  초기 2개였던 스텝을 4개로 분리하도록 대대적인 리팩토링을 실행. 중간중간 temp table을 활용하여 스텝간 데이터 공유에 어려움이 없게 하고, 각각의 조건들(누적 변화량이 5를 넘었는가? MBTI가 변화했는가?)을 체크하기 쉽도록 구성한다. 

 

[테스트 관련 어려움]

• batch를 테스트하기 위해서 몇 건의 데이터가 필요한가?
  100만 건의 다운로드를 기록한 '아이들나라' 앱이 모티브였기 때문에, 이보다 작은 앱이라 가정하며 회원을 10만 명으로 잡고 진행하였다. 테스트 결과는 다음과 같다. 

• 10만 건을 기준으로 할 때, 어느 정도의 시간이 소요되었을 때 batch가 제대로 진행되었다고 말할 수 있는가?
  이는 배치가 너무 오래 걸리지 않으면 괜찮다고 생각했다. 일정한 시간에 정확히 끝나는 것이 보장된다면 해당 배치는 새벽에 진행되므로 비즈니스에 영향을 미치지 않을 것이라 가정했다. 10만 건에 7분 정도라면, 일단 준수한 수준이라고 가정한다. 활동을 하지 않는 멤버에 대해 계속 추천을 하지 않도록, 추후 로그인 한지 1개월 이하인 회원만 추천해 주는 방향도 고려해 볼 수 있다. 
• 병목 지점을 어떻게 확인할 수 있는가?
  JDBC 쿼리 및 모든 스텝 실행 시간을 로그를 찍어 확인하였다. 모든 쿼리를 bulk로 고쳤지만, step2에서 복잡한 조건 + 한번에 여러 테이블에서 데이터 들고오기를 하는 과정에서, 추가 데이터 조회 시 쿼리가 하나씩 날아가는 것을 확인하였다. 이 부분이 병목 지점. 

 

데이터를 넣고 돌리고 지우고... 징글징글한 테스트의 반복이었다. 

 

또한, 각각의 상황에 맞는 테스트 코드를 작성하여 배치 로직의 신뢰성을 높이고자 했다. 

 

총 2개의 배치 중, 하나는 단위 테스트, 하나는 통합 테스트를 실시하였다. 

 

배치에서 중요한 점은 오류가 나지 않는 것. 한번 job이 실패했을 때 처리해야 하는 데이터가 너무 크기 때문이다. 

따라서 데이터가 없을 때, 에러가 났을 때 등 각각의 엣지 케이스를 고려한 단위 테스트가 좀더 유효하지 않았나... 그럼에도 결국 통합 테스트까지 모두 필요하다고 생각한다. + 개발자 driven한 방식이지만..., 배치 오류 시 slack 알람이 오도록 구현하여 배치 실패 시 개발자가 바로 알 수 있도록 하였다. 

 

---

마지막 잘한 점은, DB 관련하여 추가 테스트 및 조사를 실시한 것이다. 

 

멘토님들께서 보통 복합키를 쓰지 않는다고 해 주셨는데, 복합키란 어떤 때에 쓰는지, 성능상 이점이 있는데 왜 쓰지 않는 것인지 궁금해서 해당 내용에 대한 테스트를 실시하였다. 관련 내용은 아래의 링크에 적혀 있다. 

https://kmcp.tistory.com/87

좋아요 테이블, 어떻게 구성하면 좋을까? PK 2개 vs. PK 1개(feat.FK 2개)

 

---

이번 프로젝트의 아쉬운 점

1. 책 추천 시, 더 다양한 메타 데이터를 활용하지 못한 점
2. Chat GPT로 분석하는 책 MBTI, 제대로 되는지 확인하지 못한 점

먼저 책 추천 시 '회원 성향'을 제외한 더 다양한 메타 데이터를 활용하지 못한 점이 아쉽다. 

어떤 팀은 책 추천에 머신 러닝을 도입했지만 너무 성과가 좋지 않아서 도중에 방법을 바꾸었다. 이유는 데이터가 턱없이 부족해서. 기계 학습을 위해서는 10만 건이 아니라, 더 많은 실물 책 데이터가 필요하기 때문이다.

그럼에도 불구하고 가장 많이 조회한 도서 카테고리라든지, 최근에 접속했을 때 읽은 도서와 유사한 책이라든지... 다양한 데이터를 활용할 수 있었을 텐데, 하는 생각이 든다. 

 

도서 등록 시, gpt를 이용하여 책의 MBTI를 점수화해서 함께 등록한다.

지금 생각해 보니 가능한 일이었는지, 책의 줄거리라는 것이 MBTI 점수로 정량화될 수 있었던 것인지 많은 의문이 남는다. gpt는 분명 답을 내려주긴 했다. 하지만 무엇을 보고 답을 내려주었던 것일까? 주인공의 성격? 아니면 책의 분위기나 장르? LLM이 내려주는 답 속에 숨겨진 의미 또한 철저히 파헤쳐 봐야 함 & LLM의 성능을 판단하기 위해 정량적 기준을 세워야 함을 알게 되었다. 

 

---

 

마지막으로, 수고해 주신 팀원분들께 무척 감사하다. 모두 올해 건강하고 행복하고 지내셨으면! 그리고 오래 보는 사이가 되었으면.