들어가기 전
LMS(Learning Management System)은 코로나 세대 대학생들은 많이 들어봤을텐데요!
저는 LXP를 처음 들었을 때 LMS랑 비슷한 친구구나 하고 넘어갔었어요.
하지만 프로젝트를 시작하기 전 어떤 차이가 있는지 알고 넘어가는게 좋겠다! 싶어서 들어가기 전에 간단히 소개를 해보려 합니다.
LXP가 뭐죠?
LXP는 "Learning eXperience Platform"의 약자로 학습 경험 플랫폼을 의미해요.
LMS와 LXP는 "온라인 학습을 위한 플랫폼"이라는 공통점을 가져요.
하지만 둘은 초점이 달라요. LMS는 교수자(관리자) 중심의 교육 관리와 콘텐츠 제공에 초점을 두었다면, LXP는 학습자 중심의 개인화된 경험과 콘텐츠 추천에 초점을 두어요.
요즘은 점차 LMS -> LXP의 형태의 플랫폼으로 변화하고 있다고 하네요 🙌
본격 프로젝트 스타-또!
어쩌다가 팀장
프로젝트를 시작하기 전 별도의 스터디를 진행했으면 하는 강사님의 말씀에 총 5팀의 스터디 그룹이 생성됐어요! (그 중 한 팀이 저희 Anado팀 입니당 ㅎㅎ)
저는 처음이라 나서지 말자.. 하는 마음에 자원하지 않았는데,, 저의 초롱초롱 눈이 강사님께 닿았는지 ㅎ 팀장 제의를 받게 되었습니다 !!
팀장으로 간택(?)이 되고 나서 어떻게 하면 모두가 좋은 학습을 할 수 있을지 많이 고민했던 것 같아요. 그래도 걱정했던 것과 다르게 다른 팀원 분들이 부담을 주지 않고 모두가 한 마음으로 으쌰으쌰하니까 시너지가 나더라구요 🥹
나의 목표
프로젝트를 진행하기 전 제가 얻어가고 싶은 부분이 무엇인지에 대해서 고민해봤어요.
자주 사용했던 Spring Boot를 사용하지 않고 Java + HikariCP 를 사용해서 구현을 했어요.
항상 JPA를 사용했던 터라 내부적으로 어떻게 동작을 하고, HikariCP를 사용할 때는 어떤 차이가 있는지에 대해서 잘 몰랐어요.
그래서 이번 프로젝트의 목표에서 학습과 협업을 가장 큰 키워드로 잡아 봤어요.
- 학습 : 무심결에 사용했던 프로젝트 구조와 JPA가 아닌 HikariCP는 어떤 매력이 있는지 알아보자!
- 협업 : 나와는 다른 견해를 가진 팀원들과 논의를 자주 하며 의견을 전달하는 연습을 하자!
위와 같이 조금은 세부적?인 목표를 가지고 시작했어요
잘한 것 같아요!
중간 논의
프로젝트를 시작하기 전 요구사항 명세서 작성 및 ERD 설계를 꼼꼼히 진행했어요.
각자 도메인을 정하고 난 후 요구사항 명세를 진행하는데 서로 놓친 요구사항이 있다면 알려주는 과정이 인상적이었어요.
꼼꼼히 명세를 작성하고 도메인 분석 후 ERD 설계까지 이틀 정도의 시간동안 충분히 논의를 진행하여 최종적으로 위와 같은 결과가 나오게 되었어요.
문서화
중간 중간 논의하는 과정을 빠짐없이 기록하려 했어요.
각자 프로젝트 구현 시작 전 Daily Scrum을 작성하며 마지막에는 목표량을 달성했는지 확인도 하며 "실무에서 이런 식으로 진행하겠구나!"를 느낄 수 있었어요.
한 팀 = 한 마음
논의 과정이나 프로젝트 구현 과정에서 아무도 빠짐없이 적극적으로 자신의 의견도 내고,
구현하는 과정에서 궁금한 점이 생기면 가감없이 질문을 했어요.
사실 프로젝트를 위해 만들어진 팀이었다면 이러한 분위기가 나오지 않았을 것 같은데 사전에 스터디를 진행하며 친해졌던 게 큰 작용을 한 것 같아요.
그래서 각자 맡은 도메인 부분을 구현하기 바빴을 수 있었지만 모두가 자신의 일처럼 의견을 공유해주면서 더 빠른 시간 안에 해결할 수 있었던 것 같아요
함께 해준 모든 팀원들에게 감사했던 시간이었습니다 🤭
아쉬웠어요!
좋은 점이 많았던 만큼 아쉬웠던 부분도 있었어요.
현실적인 구현 목표
처음 저희는 요구사항과 ERD 설계에 시간을 다른 팀보다 많이 쓴 것 같다고 생각했어요.
물론 후회되는 건 아닙니다!
저희의 처음 도메인 분석 후 ERD는 아래와 같았어요.
이렇게 문의, 리뷰도 있으면 좋겠다고 생각했죠.
하지만 주어진 시간은 제한적이고 핵심 기능 구현에 힘쓸 시간보다 다른 기능을 구현하는데에 힘을 쓸 것 같다는 의견이 구현하던 중간에 나오게 되었어요.
그래서 "꼭 있어야 하는 기능"을 추린 후의 최종적으로 위의 ERD가 탄생하게 되었어요!
조금 더 현실적인 시간을 고려하고 핵심 위주의 설계에 초점을 두고, 이후에 부가 기능으로 구현했다면 좋았을 것 같다고 생각이 들었어요 😂
끝없는 논의
분명 꼼꼼하게 정의했다고 생각했지만 가장 중요한 "컨벤션"에 대한 논의를 사전에 하지 못했어요. 그러다보니 중간에 위의 이미지와 같이 끝없는 논의의 시간이 있었어요.
한 주제로 논의를 진행하기 시작하면 모두 구현을 하다가 멈추게 되었어요.
논의가 끝나면 그에 관련된 꼬리 논의 주제가 나오고 그러다보니 생각했던 시간보다 많은 시간을 논의 시간에 쏟게 된 것 같아요.
이 과정을 통해서 논의 중에도 본질을 벗어나는 주제에 대해서는 멈출 줄도 알아야 한다는 것을 깨닫게 되었어요.
코드 리뷰
저희는 처음에 코드 리뷰의 문화를 경험해보자는 이야기가 나왔어요.
브랜치 전략을 Main - Develop - Feature/{기능}으로 가져가며 Develop -> Main에 PR 규칙을 리뷰 2명으로 두었어요.
하지만, 각 도메인을 구현하느라 리뷰를 해줄 시간을 확보하지 못했어요.
그래서 codeRabbit이라는 리뷰 AI를 이용하며 자동화를 했어요. 코드 래빗이 너무 리뷰를 잘해주더라구요!
리뷰를 받는 것은 좋았지만 코드래빗에만 의존하며 리팩토링을 하게 되는 과정에서 각 팀원들이 서로의 코드를 이해하기 위한 과정이 생략된 것 같아 아쉬움이 남았어요.
마치며
피드백 & 느낀점
저희 포텐업의 프론트엔드와 백엔드 모두가 모여서 발표하는 시간을 가졌어요.
(제가 발표하게 되어 얼마나 떨렸는지 몰라요!!)
발표를 직접 보시고 강사님께 아래와 같은 피드백을 받았어요!
피드백을 보고 '아쉬움을 느꼈던 부분도 발표할 때 비춰졌구나'하고 느꼈어요.
더더욱 신경써야할 부분이라고 생각하게 되었습니다.
그래도 팀 분위기에 대해서 칭찬 받아서 기분 좋았습니다!
추가로 기술적 목표였던 HikariCP 사용 경험도 짧게 공유하자면, JPA의 '편리함' 뒤에 숨겨진 동작 원리를 고민해볼 수 있는 좋은 기회였어요.
직접 쿼리를 작성하고 Connection Pool을 관리하며 SQL의 중요성을 다시 한번 깨닫게 되었습니다. 물론, 반복적인 CRUD 작업을 처리할 때는 JPA가 그립더라구요 😆
다음 목표
- 코드 리뷰 시간 확보 및 규칙 정하기!
- 논의 주제에서의 본질을 벗어나지 않기 -> (실험) 논의 시간 타임박스 정해서 진행해보기!
- 서로 성장할 수 있는 분위기를 만들기!
긴 글 읽어주셔서 감사합니다 🙇🏻♀️
참고 자료
