한화시스템 BEYOND SW 캠프의 네 번째 프로젝트인 데브옵스 프로젝트는 약 2.5주의 짧은 기간 동안 작은 서비스 기획, 백엔드/프론트엔드 개발 및 Kubernetes 환경에 배포, Jenkins CI/CD 파이프라인 구성까지 포함하였다. DAO 팀은 두뇌 트레이닝을 위한 퀴즈 플랫폼 NBTI를 개발하였다. 주요 기능은 다음과 같다.
1. 주요 기능
- 회원: 계정 관리, 정보 조회, 활동(검사 및 학습) 내역 조회
- 이의제기: 학습 문제 이의제기 신청 및 내역 조회
- 검사: 6개 영역에 대한 문제 풀이 및 결과 조회
- 학습: 선택한 영역에 대한 문제 풀이 및 결과 조회
- 관리자: 회원 관리, 이의제기 승인/반려, 모든 회원 활동 내역 조회, 문제 관리
2. 기여한 점
1. 팀명 및 프로젝트명 제안
이번 프로젝트의 팀명과 프로젝트명은 모두 필자가 제안한 이름으로, 투표를 통해 최종 선정되었다.
팀명: DAO
DAO는 Dev Artists Organization의 약자로, 개발로 예술을 해보겠다는 의미를 담았다. 개발 용어 중 이렇게 의미를 부여할 수 있는 것을 찾고 있었는데, DAO는 Data Access Object의 약자이기도 하여 두 가지를 모두 충족하는 이름이었다.
프로젝트명: NBTI
NBTI는 National Brain Training Interface의 약자로, 전국민 두뇌 트레이닝 서비스임을 나타내는 이름이다. MBTI가 많이 유행하던 시기여서
MBTI의 시대는 끝났다. 이제는 NBTI다.
를 슬로건으로 삼았다. 프로젝트명이 NBTI로 선정되고, README 파일의 팀원 소개는 각자의 MBTI 이미지를 활용하였다.
2. 경험 공유
이번 프로젝트는 기존의 PPT 발표 방식이 아닌 부스 체험 방식의 발표로 진행되었는데, 초기 기획을 너무 체험 위주로 잡았던 탓에 기획을 한 차례 수정하였다.
기존 방향성을 최대한 유지하며 수정한 것이 문제 풀이 및 채점 플랫폼인데, 콘텐츠가 중/고등학교 수학 문제였다는 점만 제외하면 필자의 전 직장에서 운영했던 서비스와 유사했다. 당시의 경험을 최대한 복기하여 팀원들에게 공유하였고, 이를 바탕으로 짧은 기간 내에 개발할 수 있도록 간소화된 형태로 프로젝트 방향성을 잡을 수 있었다.
3. 문제 제작 및 검수
검사 및 학습을 제공하는 서비스를 기획했기에, 서비스 운영에 필요한 문제를 확보해야했다. 역할을 나누어 문제 일부를 제작하고, 또 다른 팀원이 만들어온 문제에 오류가 없는지 확인 및 수정하였다. 개발 외적으로도 꽤 많은 노력이 들어간 부분이었다.
4. 관리자 기능 중 이의제기 및 문제 관리 기능 구현
관리자 기능 중 이의제기 조회 및 승인/반려 처리, 문제 등록, 수정, 삭제에 대한 백엔드 및 프론트엔드 개발을 담당하였다.
3. 배운 점
1. MyBatis 없이 JPA 기반 환경에서 동적 쿼리 작성
관리자의 목록 조회 기능에는 조건에 따른 필터링이 포함되어 있기에 동적 쿼리를 작성해야 했다. 이전 백엔드 프로젝트와는 다르게 CQRS 패턴을 사용하지 않고 layered 아키텍처로만 코드를 작성했으며, MyBatis 없이 JPA만을 사용했다. 이를 위해 Repository를 다음과 같은 구조로 작성하였다.
public interface ProblemRepository extends JpaRepository<Problem, Integer> {
}
public interface ProblemRepositoryCustom {
}
@Repository
public class ProblemRepositoryImpl implements ProblemRepositoryCustom {
}XXXRepository: JPA 기본 repositoryXXXRepositoryCustom: JPA 기본 repository를 확장하여 사용하기 위해 필요한 인터페이스XXXRepositoryImpl: 실제 동적 쿼리를 작성하는XXXRepositoryCustom의 구현체
QueryDSL 등을 이용한 동적 쿼리 작성 시에도 위와 같은 3단 구조가 필요하며, 반드시 이름 규칙을 지켜야 Spring Data JPA가 인식하여 합쳐준다고 한다. (CustomXXXRepository와 같은 다른 이름 사용 불가)
2. 관리자 조회 기능
관리자 조회 기능을 설계할 때, 회원 ID, 문제 ID, 이의제기 ID 등 인조 식별자 PK는 값을 매핑하기 위한 용도이므로 굳이 목록 조회 화면에 표시할 필요는 없다고 생각했다. 하지만 한 목록 조회 기능에서 같은 행이 2번 나타나는 버그가 발생했는데, 원인을 파악해보니 이는 초기 데이터가 잘못 설정되어 동일한 ID를 가진 행을 2번 조회했기 때문이었다. 목록 조회 시 ID를 화면에 함께 띄워줬다면 디버깅 시간을 줄일 수 있었을 것이다.
이 경험을 통해 인조 식별자 PK는 단순 매핑용 값에 그치지 않고, 디버깅시 유용한 정보임을 배웠다. 요구사항에 따라 의도적으로 숨기는 경우가 아니라면 관리자의 목록 조회 시 함께 표시하는 게 좋다고 생각하게 되었다.
4. 아쉬운 점
짧은 기간동안 진행된 프로젝트이다보니 프론트엔드에서 컴포넌트화에 많은 신경을 쓰지 못한 점이 아쉬웠다. 특히, 페이징 처리에 사용되는 페이징 바는 3명이 각자 코드를 작성하는 바람에 작동하는 로직이 달랐다. 같은 관리자 페이지 안에서 페이징 바의 스타일이 다른 부분도 있었는데, 다른 팀원의 제안으로 이 부분은 스타일을 통일하는 방향으로 수정되었다.
최종 프로젝트에서는 규모가 큰 만큼, 유지보수성 향상을 위해 페이징 바를 컴포넌트화 하여 이를 개선하였다.
5. 느낀 점
확실히 모든 일은 처음이 어렵지, 한 번 경험해보고 나면 익숙해진다는 것을 느꼈다. 백엔드/프론트엔드 프로젝트에 비해 짧은 기간에 개발 및 배포까지 해야하는 프로젝트였지만, 지금까지의 프로젝트 중 가장 완성도 높은 결과물을 만들어낼 수 있었다.
특히, 맡은 기능 개발을 모두 완수하고 기능 테스트 및 디버깅까지 성공적으로 해낸 첫 프로젝트였기에 더욱 뜻깊었다. 이전까지의 프로젝트에서 부족함을 많이 느껴 자신감을 잃은 상태였는데, 개발에 대한 자신감을 되찾게 해준 소중한 프로젝트였다.
