한화시스템 Beyond SW캠프 15기 참가자 박성용입니다. 해당 포스팅은 첫번째 프로젝트인 DB 프로젝트에 대한 자세한 리뷰 내용을 기록하고자 합니다. 앞으로 진행할 모든 프로젝트에 대해서도 동일하게 리뷰를 남길 것이며 각 프로젝트 별로 발생하는 문제들은 무엇이며 어떻게 해결하였고 이전 프로젝트에서의 문제를 다음 프로젝트에선 해결했는지 못했는지 피드백할 수 있는 데이터로서 사용하는 것이 포스팅의 주 목적입니다.
1. 프로젝트 소개
우선 저희 프로젝트 BILLON에 대한 간략한 소개를 시작으로 리뷰를 시작하겠습니다.
친환경 모바일 영수증 관리 시스템인 BILLON은 환경오염의 주 원인중 하나인 종이 영수증을 대체하는 솔루션을 제공하는 동시에 사용자별 소비 패턴 분석, 매장 매출 분석, 포인트 적립 및 관리, 리뷰 작성 등의 기능을 제공합니다.
종이 영수증의 심각한 환경 오염에 대한 문제 의식을 기반으로 시작된 저희 프로젝트에 대한 자세한 내용과 프로젝트 코드에 대해 알고싶으신 분들은 하단의 깃허브 주소로 이동해서 확인해주시길 바라겠습니다.
[BILLON 프로젝트 깃허브 주소]
https://github.com/DBDIBABIDIBU/be15-1st-DBDIBABDBU-mobile_receipt
2. 프로젝트 진행 과정
프로젝트 진행 과정에 대한 자세한 세부 내용은 동일 시리즈 이전에 작성한 포스팅에서 서술하였습니다. 저희의 프로젝트가 어떤 방식과 순서로 진행되었는지 매우 구체적으로 작성되었으므로 꼭 해당 포스팅에서 확인해주시길 바라겠습니다.
대략적인 개요는 다음과 같습니다.
2-1. 아이디어 선정 및 기획 과정
진행 방식
피그마 잼(Figma Jam)을 활용하여 브레이밍스토밍 과정을 통해 아이디어를 작성하고 공유한 뒤 선별 과정을 거쳐 프로젝트를 선정하였습니다.
문제점
아이디어가 선정된 후 개별적으로 해야 할일을 나누어 진행하는 과정에서 소통 부족의 문제가 있었고 프로젝트와 관련된 사전 조사와 주요 기능 정리가 되지 않은 채 다른 업무를 진행했었기 때문에 이후 프로젝트와 관련된 큰 문제에 의해 프로젝트 아이디어를 다시 생각해야 되는 과정에서 이미 작업한 내용들을 다시 작성해야 되는 문제를 야기하게 되었습니다.
교훈
따라서 의사결정 후에도 지속적인 소통이 필수적이고 공동의 목표를 미리 검토하여 프로젝트 방향성을 설정한 뒤 선택한 아이디어에 대해 사전 조사 및 발생할 수 있는 이슈에 대한 검토를 진행하여 다음 단계로 넘어가기 전에 모든 에러 상황을 초기에 없애는 작업이 필수적으로 수반되야 한다는 것을 학습했습니다.
2-2. 요구사항 정의서 작성 과정 및 협업 방식 변화
진행방식
요구사항 정의서 작성의 경우 모든 팀원들이 한장소에 모여서 함께 정리하는 방식을 채택하였습니다.
교훈
처음에는 비효율적으로 보였지만 이후 수정 및 협업이 훨씬 원활해지는 결과를 보면서 협업 시 모든 팀원이 프로젝트의 전체 흐름을 이해하는 것의 중요성을 인식하게 되었고 한번 모두의 합의에 의해 정리한 초안을 기준으로 수정을 하는 것은 쉬운 과정임을 깨닫게 되었습니다.
2-3. 정기 회의(스프린트 미팅)
진행방식
매일 아침 20분간 짧은 회의를 진행하였고 진행 상황 점검 및 공유 시간을 가졌고 회의 내용을 회의록으로 작성하여 회의 내용을 문서화하여 기록하는 과정을 진행하였습니다.
교훈
이번 프로젝트에서 가장 유의미했던 방식으로 프로젝트 진행 방향을 명확히 설정할 수 있고 특히 회의록을 작성하여 해야할 업무를 기록하고 액션 아이템을 도출했던 것은 진행 상황을 빠르게 검토하고 프로젝트를 체계적으로 관리할 수 있었던 매우 중요한 과정임을 깨달을 수 있었습니다.
2-4. ERD 설계 및 수정 과정에서의 시행착오
진행 방식
저희는 공부 목적으로 모든 팀원이 개별적으로 ERD를 설계 후 투표를 통해 BASE가 될 ERD 선택 후 피그마 잼에서 추가 및 수정할 엔터티와 속성을 논의하는 과정으로 전체적인 ERD를 설계하는 과정을 수반하였습니다.
문제점
ERD 수정 과정에서 소통 부족으로 인해 의견 통합이 어려웠고 구두 논의가 많아 기록을 못해 이전 의견들이 잊혀지는 경우가 발생하였고 일부 팀원만 이해하고 나머지는 이해하지 못해 합의가 어려운 상황이 종종 밝생하였습니다.
교훈
처음에는 개인별 ERD를 분배하여 구현해오는 것이 효율적이라고 생각이 들었지만 모두가 ERD를 구현해오니 프로젝트 구조를 깊이 있기 이해하게 되고 다양한 관점을 반영한 풍성한 ERD를 설계할 수 있어 좋았던 것 같습니다.
해결책
다음 프로젝트에선 노션에서 안건함 페이지를 생성하여 변경사항 및 안건이 생기면 무조건 해당 페이지에 기록하여 모든 팀원이 해당 안건에 대해 인지할 수 있도록 하고 변경사항 제안에 대한 기록이 가능하도록 하여 소통 문제를 해결해보고자 합니다.
2-5. 컨벤션 정리 및 준수 과정
진행 방식
SQL 컨벤션(테이블 네이밍, 포맷 컨벤션), PR, 이슈, 프로젝트 구조 컨벤션, Git 브랜치 및 커밋 메시지 컨벤션을 설정하여 해당 컨벤션에 맞춰 문서를 기록하고 코드를 작성하였습니다.
문제점
컨벤션을 정하긴 했지만 팀원들이 익숙해지는데 시간이 많이 필요했고 모든 컨벤션을 완벽하게 준수하지 못했던 것 같습니다.
해결책
따라서 다음 프로젝트에서는 컨벤션을 사전에 철저히 정리하거 적용하여 계속해서 연습해서 습관화 할 수 있는 환경을 구축하여 우리가 정의한 컨벤션을 완벽하게 준수하여 메시지를 작성하고 코드를 작성할 수 있었으면 좋겠습니다.
2-6. 테스트 케이스 구현 및 개선점
진행 방식
ERD를 기준으로 DDL 구문 작성 후 공유를 통해 로컬환경에서 동일한 테이블을 기준으로 기능을 구현하고 테스트 케이스를 작성할 수 있도록 하였고 기능 구현은 업무를 분담하여 작성 후 코드 리뷰를 통해 작성한 코드가 기능을 제대로 구현할 수 있는지, 요구사항 정의서에 기록한 모든 기능들이 구현되었는지를 확인하는 과정을 거쳤습니다. 또한 기능 구현 과정에서 DDL의 지속적인 변경이 발생하여 계속 변경되는 DDL을 Github PR로 공유하는 과정을 거쳐 번거로움을 야기시켰습니다.
문제점
코드 리뷰를 진행하긴 했지만 코드 가독성, 성능, 유지보수성 측면에서 더 좋은 코드가 무엇일지에 대한 고민을 하지 못했던 점이 아쉬운 것 같습니다.
해결책
초기 단계부터 빠르게 전체 스텝을 진행 후 반복 수정을 통해 프로젝트를 진행할 필요가 있는 것 같습니다. 그렇지 않으면 기능 구현 및 테스트 케이스 작성 등의 프로젝트의 마지막 실행 단계에서 마감에 쫒기게 되어 높은 품질의 코드를 작성하는 것이 어려워 전체적인 결과의 수준을 높이지 못할 것 같습니다.
3. 내가 기여한 것
아이디어 선정부터 ERD 설계 및 테스트 케이스 구현까지 팀원 모두가 함께했던 내용은 제외하고, 제가 기여한 부분만 정리하여 기록하고자 합니다. 이 과정에서 경험한 문제 해결 방법과 성과를 공유하고 아직 경험하지 못한 수행 단위는 무엇인지 검토할 수 있는 기준 자료로 사용하고자 합니다.
3-1. 프로젝트 발표를 위한 PPT 제작 🎨📊
프로젝트를 효과적으로 발표하기 위해 명확한 흐름을 갖춘 PPT가 필요했습니다. 특히, 프로젝트의 문제 정의, 해결 과정, 핵심 기능 및 결과를 직관적으로 전달하는 것이 중요했습니다.
따라서 프로젝트에 대한 설명과 핵심 기능 및 트러블 슈팅에 대한 이해도와 몰입도를 높이기 위해 적절한 이미지를 배치하여 가독성을 향상시켰고 다이어그램을 적극 활용해 설명력을 높이려고 노력했고 PPT가 프로젝트에 대한 내용을 이해 하는데 도움이 되었다는 피드백을 받아 뿌듯했던것 같습니다.
3-2. 쿼리 성능 향상
테스트 중 특정 쿼리의 실행 속도가 예상보다 느리게 동작하는 문제가 발생하였고 이에 대한 원인을 찾던 중 COUNT(*)를 사용한 중복 검사가 불필요한 전체 테이블 검색 (Full Table Scan)을 유발하는 것이 문제의 원인 임을 알게 되었습니다.
COUNT()는 모든 행을 스캔해야 하므로 데이터가 더 많아질수록 COUNT()의 비용이 기하급수적으로 증가할 것으로 판단하여 소스 코드 내 모든 COUNT(*)를 사용하여 중복 검사를 진행한 것을 EXISTS로 변경하여 성능 향상을 야기시켰습니다.
3-3. COLLATE(문자 정렬 방식) 디버깅
SP_ISSUE_RECEIPT 프로시저 실행 중 리터럴 값과 컬럼 간의 Collation 불일치로 인해 utf8mb4_general_ci와 utf8mb4_uca1400_ai_ci 간의 "Illegal mix of collations" 오류가 발생했고 디버깅 과정을 통해 현재 프로젝트의 상황에 맞는 해결 방법으로 문제를 해결했습니다.
이에 대한 자세한 내용은 제가 구체적으로 작성한 아래 포스팅을 꼭꼭꼭!!! 확인해주시길 바라겠습니다.
[COLLATE(문자 정렬 방식) 디버깅 과정]
https://velog.io/@low_level_v99/mariaDB-Illegal-mix-of-collations-%EB%AC%B8%EC%A0%9C-%EB%B6%84%EC%84%9D-%EB%B0%8F-%ED%95%B4%EA%B2%B0-%EA%B3%BC%EC%A0%95
3-4. 트랜잭션 관련 트러블 슈팅 해결
SP_ISSUE_RECEIPT에서 SP_POINT_EARN 호출 중 오류 발생 시, 트랜잭션이 롤백되지 않고 일부 데이터가 삽입되는 문제가 발생했습니다.
원인 분석 결과 트랜잭션이 선언된 프로시저 내부에서만 유효하며, 호출된 프로시저로 전파되지 않는다는 점을 확인했고 각 프로시저에서 개별적으로 트랜잭션을 선언하고 예외 처리를 수행하도록 변경하여 문제를 해결했습니다.
이를 통해 트랜잭션이 정상적으로 동작하며 오류 발생 시 전체적인 롤백이 적용되어 데이터 정합이 유지되는데 기여하였습니다.
4. 마무리 및 다음 프로젝트를 위한 피드백
이번 프로젝트를 통해 얻은 가장 중요한 교훈은 문제 발생 시 원인을 정확히 분석하고, 논리적인 해결책을 도출하는 과정의 중요성이었습니다. 특히 데이터베이스를 다루면서 발생하는 다양한 이슈(쿼리 성능 저하, COLLATE 충돌, 트랜잭션 롤백 문제 등)를 직접 해결하며 단순한 기능 구현을 넘어 최적화와 안정성까지 고려하는 것이 얼마나 중요한지 깊이 깨닫게 되었습니다.
그리고 다음 프로젝트에서는 더 나은 협업과 코드 품질 향상을 위해 아래의 사항을 개선하고자 합니다.
- 개발 컨벤션을 철저히 준수하고, 코드 리뷰를 더 적극적으로 활용
- 기존보다 명확한 SQL, Git 브랜치 및 PR 컨벤션을 정하고, 모든 팀원이 이를 완벽히 준수할 수 있도록 꾸준한 연습 및 습관화 과정 필요
- 코드 리뷰 시 가독성, 성능, 유지보수성을 고려하여 개선 가능한 부분을 적극적으로 공유
- 트러블슈팅 과정 문서화 및 공유
- 프로젝트 진행 중 발생한 이슈와 해결 과정을 더욱 상세히 정리하여 다음 프로젝트에서도 유사한 문제 발생 시 참고할 수 있도록 문서화
- 안건함을 추가하여 모든 팀원이 새로운 안건 및 변경사항에 대해 인지하고 해당 안건에 대한 피드백을 기록화 할 수 있는 환경 구축
이번 프로젝트를 통해 경험한 다양한 문제 해결 과정은 앞으로의 프로젝트에서도 매우 유용한 지식이 될 것으로 확신하고 다음 프로젝트에서도 더 나은 개발자가 되기 위해 계속해서 성장하고, 문제 해결 능력을 더욱 강화할 수 있도록 노력할 것입니다.
좋은 개발자는 문제를 피하는 것이 아니라, 문제를 정확히 이해하고 해결하는 과정에서 성장한다고 생각합니다. 피 한방울 안난 것을 자랑스럽게 생각하지 말고 오히려 상처만 남더라도 성장으로 승화시킬 수 있는 다양한 역경과 고난에 맞설 수 있는 개발자가 되도록 노력하겠습니다.
