소단지 경비원을 위한 주차 관리 웹 애플리케이션 회고

서론

현실적이고 실용적인 것

나는 현실적이고 실용적인 것을 좋아한다. 예를 들면 [원하는 꿈을 꾸게 해주는 기계] vs [편하게 잘 수 있게 눈을 따듯하게 해주는 안대] 라고 했을 때 나는 전자 보다는 후자를 선택한다. 물론, 남들이 생각하지 못 한 것을 만들고 불가능 한 것을 성공시킬 때 발전할 수 있다고 하지만 일단은 눈 앞에 있는 불편함과 당장 해결할 수 있는 문제를 해결하는 쪽을 선택하는 것을 좋아한다. 이렇게 당장의 문제를 하나하나 해결하다 보면 지금은 수면 안대를 만들겠지만 나중엔 꿈을 꾸게 해주는 기계를 만들 수 있을 것이라고 믿고 있기 때문이다.

프로젝트를 계획한 이유

이번에 소단지 경비원을 위한 주차 관리 웹 애플리케이션(이하, 소경관)을 만든 이유도 마찬가지다. 내가 할 수 있는 범위 내에서 내가 살고 있는 단지에서 근무하는 경비원분이 주차를 비가 오나 눈이 오나 수기로 체크하고 있기 때문에 이런 반복적이고 불편한 문제를 프로그래밍을 통해 해결할 수 있겠다 싶어서 생각하게 되었다. 조금 더 살을 붙이자면 주차를 수기로 체크하는 것을 간단하게 웹 애플리케이션으로 처리함으로써 주차 관리의 질을 높일 수 있겠다 생각했고, 결국 주차 관리의 높은 질이란 단지 내 외부 주차 차량이 줄어든다는 것과 주차 문제에 대한 소통이 주민들과 잘 되면서 우리의 편리로 돌아오기 때문에 경비원을 위한 웹 애플리케이션이면서 우리를 위한 웹 애플리케이션이 되기도 한다는 것도 체크해 두고 싶다.

그럼, 소경관 프로젝트를 만듦으로써 나의 계획이 성공했나?.. 아니다. 프로젝트를 완성시켰을 지언정 실사용에 적용시킬 수 없었기 때문에 실패했다고 생각한다. 그 과정에 대해 회고한다.

본론

구상

처음에 소경관을 어떻게 완성시킬지에 대해 많은 고민을 했었다. 프로젝트 질을 높이는 것도 중요했지만 사실 프로젝트의 질을 높이기 보다 코드의 질을 높이고 싶었다. 때문에 가능하면 기능을 줄여서 핵심 기능만 놔두도록 하고 코드를 깔끔히 작성하는 쪽을 택하고 싶었는데 교수님에게 피드백을 받으면서 나만의 그 바램이 무너져버렸다.

소경관 프로젝트는 나 혼자 만드는 프로젝트라고 하더라도 학교 시험 대체 과목 형식으로 만들어야 하는 만큼 온전한 내 의지의 프로젝트 일 수가 없었다. 교수님이 원하는 기능을 추가하기로 했고 결국 별로 하고 싶지 않았던 차량 번호판 인식(OCR) 기능을 추가했다.

나만 이렇게 강제로(?) 기능을 추가 당한 게 아니기 때문에 뭐라 할 수도 없고 일단 해당 기능을 포함시켜서 진행하는 쪽으로 구상을 하게 되었다.

일단, 회원 가입(사용자)에 관한 부분은 MariaDB로 진행하기로 했다. 프로젝트 필수 조건에 MongoDB 사용이 있지만 그래도 방학 동안 새로 배운 JPA를 사용해 보고 싶기도 했고 유저 정보는 수정과 삭제가 많이 들어갈 것 같아 MariaDB를 선택해서 프로젝트를 진행하기로 결정했다. 또, 사용자가 관리하는 차량에 관한 정보는 근무 일지를 작성하고 조회에 대한 작업이 많을 것 같아 MongoDB를 사용하기로 결정하면서 DB 사용 부분에 대해서는 이렇게 간단하게 구상했다.

View도 중요했다. 교수님이 무조건 이쁘게 만들라고 했다. 나는 프론트를 이쁘게 만들 자신이 없었다. 때문에 부트스트랩 템플릿을 가져다 사용하기로 결정했다. 그래도 내가 직접 만드는 것 보다 있는 템플릿을 사용하면 반이라도 가겠지 싶은 마음이었다. 그리고 프론트를 이쁘게 가꾸는데 시간을 투자하고 싶지 않았다. 기본적인 기능이 동작하는 것만 확인하면 차라리 그 시간을 아껴 코드를 깔끔하게 다듬고 싶은 마음이었다.

프로젝트 처음 시작할 때는 이정도만 생각했던 것 같다. 이렇게 생각을 하고 가지고만 있었기 때문에 처음에 다들 막막하기도 해서 스타트가 밀릴 수 밖에 없었다. 진짜 프로젝트 스타트를 하게 된 시점은 아마 문서 작성을 하고 나서부터인 것 같다.

문서 작성

아마 다들 구상을 머릿속에서 마쳤을 것이다. 얼마나 깊게 구상을 했던 짧게 했던 중간고사 대체로 WBS, ERD, 메뉴구조도, 테이블명세서, 프로그램명세서, 화면설계서는 작성해야 했기 때문에 구상을 구체화 하는 시간을 갖게 되었다. 이전에는 생각만 하고 있으니 발전이 없었는데 확실히 문서로 작성을 해두니 메뉴얼이 생긴 느낌이 되어서 프로젝트 진도가 훅훅 나가기 시작했다.

이렇게 여러 문서를 작성하면서 소경관 기능을 다듬었다. 근데 이런 문서 작성을 처음 해 보다 보니 어떻게 작성해야 잘 작성한 문서인지 구상을 할 때 얼마나 꼼꼼하게 해야 했었는지 몰랐기 때문에 나중에 개발을 하면서 재구상을 하면서 시간을 많이 빼앗겼다.

구상 실패와 재구상

개발을 하면서 작성된 메뉴얼을 따라 진행을 하였는데 구상의 빈틈을 많이 볼 수 있었고 개발 도중에 그런 빈틈을 수리하면서 개발을 한다는 것이 얼마나 힘든 일인지 알게 되었다. 구상은 아무리 튼튼하게 해도 개발을 진행하다 보면 빈틈이 있기 마련이라고 했고, 구상에 상당한 시간을 쏟고 개발은 적은 시간에 빨리 해야 한다는 글도 다수 봤음에도 이해하지 못 하고 있었지만 이번 경험을 통해 깨달을 수 있었다.

내가 실패한 구상을 크게 바라보면 내가 사용할 기술에 대해 사전에 많이 조사하지 못 했다는 것과 기술과 스프링에 대한 지식이 부족했다는 것 정도로 압축할 수 있을 것 같다. 이 외에는 내가 떠올려보지 못 한 부분이 문제가 되기도 했지만 세세하게 적었다간 자괴감이 올 수 있으니 이만 적는다.

여튼, 구상 실패를 경험하고 재구상을 하는 과정은 개발 중이라 어려웠다. 이미 만들어둔 부분과 호환성을 생각해야 했고 생각보다 이 버전에 관한 문제가 머리 아프게 터지는 경우도 있어서 최대한 Git을 활용하여 터지면 롤백.. 터지면 롤백.. 하는 식으로 진행했다.

새로운 기술

이번에 소경관을 진행하면서 내가 방학 동안 따로 인터넷 강의를 구매해서 공부했던 새로운 기술을 적용해 보기로 했다. JPA도 살짝 적용했고 뷰 템플릿도 원래 사용하던 JSP대신에 Thymeleaf를 사용하기도 했고, Gradle를 사용하고 백단 검증 로직이나 에러 메시지 처리에 대한 부분도 적용해 봤다.

학교에서 알려준 부분은 기초적인 내용이라 활용하기 좋지만 실무 프로젝트에 사용하기엔 부족하다 느꼈고 그래서 인터넷 강의를 구매해서 방학 동안 공부를 했었는데 확실히 도움이 되었다. 새로운 기술을 사용하면서 아무래도 구글링을 하는 시간도 많아지고 오류를 만나는 시간도 길었지만 구글링과 오류는 많이 접하면 접할수록 실력이 는다고 생각하기 때문에 오히려 좋았던 부분이다. 물론, 오류를 만나는 시점에선 소름이 돋지만 말이다.

Docker와 K8s도 공부를 했었기 때문에 활용하고 싶었지만 교수님의 반대로 사용하지 않고 진행했다. 지금와서 생각해 보면 괜히 까불다 망할뻔 했다.라는 생각도 든다.

중간 피드백

학교에서 프로젝트를 만들면서 중간 피드백에 대한 체크도 진행했는데 나는 무난히 통과했다. 조금 진도를 앞서나가고 있었기도 하고 이때 모각코 스터디를 하고 있었는데 같이 공부하는 경력 개발자님이 스터디 발표 때 코드 보여드리면 코드 리뷰를 해주셔서 조금씩 체크하면서 하고 있었기 때문에 널널했다.

사실 프로젝트를 만드는 과정은 머리를 싸매면서 만들었기 때문에 딱히 풀어 적을 게 없는 것 같다. 방학 때 공부한 코드 보고 적용하고 오류 만나면 관련 예시 찾아보고 해결하고 공식 문서 체크하고 어떻게 사용하는지 확인해서 적용하고 잘 모르면 스터디 발표 때 질문하던가 커뮤니티에 질문하던가 해서 조언 받고 해결하고의 반복이었다.

촉박함과 퀄리티

중간 피드백까지는 널널했던 시간이 촉박하다고 느껴지는 시간이 오게 되었는데 동기들이 슬슬 완성해 가기 시작할 때 부터였다. 내 페이스에 맞춰 완성시키면 된다고 하지만 주변 동기들이 기능 한,두개를 남겨두고 있을 때 슬슬 쫄려왔다. 게다가 나는 학교에서 배운 기술 외 따로 공부한 내용을 적용하는 부분이 많았기 때문에 다른 사람에게 막히는 부분을 물어보기도 애매했고 혼자 구글과 씨름을 해야 했다.

시간은 널널하지만 마음속 촉박함은 결국 내 코드의 퀄리티를 낮췄다. 중간에 Dto와 Vo의 경계를 잃어버리게 되고 검증과 에러 메시지 처리의 혼동이 와버렸다. 이 외에도 다양한 하자가 생기기 시작했는데 결국 프로젝트 자체 퀄리티에 영향이 가게 되었다.

중간에 제일 쫄렸던 부분 중 하나는 OCR 부분인데 강제로 넣은 차량 번호판 인식 기능을 어떻게 구현할까 고민하는 도중에 2가지 정도로 간추려졌다.
1. 유튜브를 참고해서 Spring과 Flask 통신을 통해 해결한다.
2. Tesseract OCR을 사용한다.

나는 2번을 선택했고 구현하였으나 테서렉트의 처참한 인식률에 좌절하여 교수님께 조언을 구했으나 테서렉트 쓰지 말라, Open CV 써라, 알아서 해와라, 할 수 있다.. 정도의 말을 듣고 결국 스스로 다른 방법을 탐구하기 시작했다. 그러던 와중에 Kakao Vision을 알게 되었고 여기에서 지원하는 OCR 기능을 테스트 해 봤는데 상당히 인식률이 좋아 사용하기로 결정하게 되면서 시간을 좀 많이 잡아 먹었다.

첫 배포

완성을 다 하고 첫 배포를 시작했다. 이전에도 공모전 여러개를 나가면서 프로젝트를 팀단위로 만들어 봤지만 배포하는 작업은 내가 도맡아서 한 적은 없다. 물론, 이후에 따로 배포는 해 봤지만 정식으로 만든 프로젝트 배포는 처음해 보는 일이다.

배포 자체는 어렵지 않았다. 먼저, jar로 빌드해주고 AWS EC2 Ubuntu에 옮겨주었다. 서버에 Java를 설치하고 간단하게 실행시켜 서버를 돌릴 수 있었다. 배포하고 기능 테스트를 진행할 때 로컬에서 되던 게 안 되는 경우도 있어서 조마조마했다.

배포하는 과정에서 딱히 문제가 없었다. 처음에 경로를 절대 경로로 안 잡아서 경로를 못 잡았다는거.. 수정해서 고쳤고 딱히 배포로 문제가 된 것은 없는 것 같다. 정상적인 배포 후 이제 먼저 검사 받을 수 있는 기간이 오게 되었다.

탈락

만든 프로젝트는 수업 시간에 모두가 보는 앞에서 프레젠테이션을 켜서 발표하는 식으로 진행한다. 1차적으로 기본 요구 조건을 모두 만족시켜야 하고 2차적으로 작성한 서류의 모든 조건을 만족시켜야 한다.

1차적 기본 요구 조건은 HTML5 사용할 것, MongoDB사용과 Open API사용 정도만 신경쓰면 되었지만 모두 만족시켰고 2차 서류의 조건을 만족시키는지 기능 테스트를 하는데 도중에 에러가 뜨는 문제가 발생했다. 이것 때문에 1차 발표에서 탈락하게 되었다.

수정과 다급함

탈락의 원인은 내가 문자 메시지 서비스를 넣는다고 문자 API를 사용했는데 이 API 서비스가 유료여서 요금을 충전해야 한다. 처음에 테스트를 체험하고 사용하면 몇 통은 공짜로 할 수 있는데 그 뒤로는 결제를 해야 했기 때문에 설마설마 했는데 역시, 설마가 사람 잡는다고 딱 부족한 요금에 걸려버렸다. 게다가 오류에 대한 예외 처리도 안 해서 페이지 오류가 떠버리니 당연 통과를 할 수 없었고 급하게 충전을 하려고 보니 충전하는 과정도 일반 신용카드로 하는 게 아니라 OTP 있어야 하고 까다로워서 집에 와서 충전을 할 수 있었다.

집에 와서 요금 충전을 마치고 코드를 수정하면서 예외 처리 부분에 대한 코드도 갈아 엎었다. 기존에 Controller를 사용하니까 API 서비스를 제공하는 곳에서 보내주는 에러 코드를 받을 수 없었는데 RestController로 바꾸면서 API 서비스에서 제공하는 에러 코드를 받아와 예외 처리도 같이 진행해 주었다. 이렇게 다급하게 수정을 하다 보니 처음에 지향하던 깔끔한 코드와 거리감이 조금 생기기도 했지만 기능을 정상으로 되돌려 놓을 수 있었다.

통과

수정하고 기능을 정상적으로 만들어 둔 다음에 다음 날에 다시 검사를 받았다. 기능을 수정하는 날 재배포까지 해서 테스트를 했기 때문에 정상적으로 모든 게 동작했다. 결국 통과는 할 수 있었지만 임시방편으로 코드를 짜둔 것이 몇 개 있어서 매우 걸렸다. 그리고 다행히 완료 기간보다 5일 정도 빠르게 프로젝트를 완료할 수 있었고 순위로는 4번째로 통과했다. 하지만 내가 처음에 원하던 튼튼한 기본 기능과 깔끔한 코드와 거리가 조금 멀어졌고 이는 연이은 구상 실패와 기술에 대한 이해 부족으로 이어진 결과였기 때문에 나중에 다시 사용한다면 다듬어야 하는 부분이 되었고 실사용에 적용하지 못 하는 이유가 되었다.

결론

실패 이유

프로젝트 자체는 동작하지만 실패했다고 생각한다. 내가 지향하던 깔끔하고 탄탄한 코드와 거리가 멀어졌기 때문이다. 코드에 대해 일단 스스로의 만족도가 높지 않다. 내가 배운 것은 이것 이상인 것 같은데 내가 실제 적용할 수 있었던 것은 그것의 반 정도 밖에 안 되었던 것 같다. 다르게 말 하면 공부를 하면서 잘 이해했다고 생각했지만 사실은 반 정도 밖에 이해를 못 했었던 것이고 결국 코드 퀄리티를 떨어뜨리면서 스스로의 실패라고 생각하게 되는 계기가 되었다.

배운 것

하지만, 이번을 통해서 다음에 더 잘 할 수 있는 경험을 쌓을 수 있었다.

1. 구상은 매우 튼튼하게 해야 한다.
2. 사용할 기술에 대해 꼼꼼히 체크해 봐야 한다.
3. 재구상을 하는 도중에도 코드의 가독성을 신경써야 한다.

당장 떠올려지는 것만 해도 이렇다. 토대로 이번에 졸작 겸해서 또 하나의 프로젝트를 해 볼 예정인데 이 프로젝트에는 이전에 부족했던 점을 참고하여 조금 더 나은 형태의 프로젝트를 만들 수 있을 것 같다.