전자정부프레임워크프로젝트를 끝내며 내가 배운 것

전자정부프레임워크(링크)는 이번 프로젝트에서 처음 사용해보았다. 사실 특별히 새로울 건 없었다. 왜냐하면 Spring프레임워크와 거의 똑같기 때문이다.

전자정부프레임워크란 “효율적인 정보시스템 개발을 위한 코드 라이브러리, 인터페이스규약, 설정정보 등의 뼈대를 제공하는 표준프레임워크”라고 한다.
즉, egovframework는 Spring프레임워크 + MyBatis + MySql + Jsp + Jquery 조합에다가 전자정부프레임워크가 제공하는 라이브러리나 클래스가 추가되어있다고 보면 된다.

Keep

현재 만족하고 있는 부분과 계속해서 이어갔으면 하는 부분

1. 가능한 많은 기능을 담당하고자 한 것!
   팀장님이 일이 많아서 팀장님이 담당하시는 기능 중 일부를 받아냈다. 덕분에 하나의 프로젝트에서 다양한 기능을 담당하여 개발할 수 있었다! 야근도 꽤 했지만 많이 성장했다! 뿌듯해!
2. 프로젝트 설정을 추가한 것!
   프로젝트 진행 중 CSRF 방어가 필요했는데 여러 방법으로 해결할 수 있었다. 각 페이지마다 하거나 form태그마다 할수도 있었지만 프로젝트 차원에서 해결하는 방법이 가장 좋다고 판단이 들어 Spring Security도입을 건의했다. 다행히 잘 받아들여져서 프로젝트 설정을 직접 추가하는 경험을 할 수 있었다. 프로젝트 진행 중간에 프로젝트 셋팅을 건든다는 게 살짝 두려웠던 건 사실이다. 혹시나 내가 추가한 설정들때문에 잘되던 동작들이 꼬일까봐 걱정했는데 다행히 잘 작동해서 정말 뿌듯했다.
3. XSS와 CSRF의 차이를 명확히 안 것!
   CSRF(링크)는 사이트 간 요청 위조 약자로 공격대상이 Server이다.
   XSS(링크)는 사이트 간 스크립팅의 약자로 공격대상이 Client이다.
4. ES5와 ES6 차이를 정확히 안 것!
   브라우저 호환성과 ES5와 ES6 차이(링크)를 확실히 알게되었다.
5. 검색조건 유지를 위해 return url을 사용 한 것!
   필수기능이라고도 할 수 있는 검색조건 유지기능 시작 전에는 어려울 줄 알았는데 막상해보니 간단하게 끝났다! return url을 사용하여 목록화면에서 상세화면으로 들어갔다가 뒤로 가기를 해도 페이징과 검색조건이 그대로 유지되도록 구현했다.
6. 달력 라이브러리를 커스텀해서 썼다.
   디자인팀에서 퍼블을 하는데 달력을 넣기 힘들다고 지원요청을 받았다. 달력 라이브러리를 구글링하며 제일 적합하고 커스텀할 수 있는 라이브러리를 선택해서 적용하고 특정 날짜를 클릭하지 못하게 막는다던지, DB에 저장된 날짜는 클릭안되게 달력에 처리한다든지 등 프론트와 백을 넘나들며 기능을 완성했다. library docs가 충분하지않아서 영어로도 엄청 검색을 하면서 구현했는데 꽤나 재미있는 경험이었다.

Problem

개선이 필요하다고 생각되는 부분

1. 트리구조 메뉴를 개발하는데 쿼리로 애를 많이 먹었다. 서버로 재귀호출을 돌리면서 tree데이터를 json으로 만들어 화면에 던진 뒤에 jsTree라이브러리(링크)를 사용해 개발을 완료할 수 있었다. 고급 SQL에 대한 공부가 필요하다.
2. egovframework를 충분히 활용하지 못했다. 시간도 없을뿐더라 기존 CMS를 건들이지 않는 선에서 다루느라 egovframework의 많은 기능을 활용하지못해 아쉽다.
3. 프로젝트 전체 흐름을 이해하는 데 꽤나 시간이 걸렸다. 중간중간에 고객사 요구사항이 바뀌기도 했고 내가 담당해야하는 페이지가 계정 권한별로 달라서 초반에 헷갈렸다. 이윽고 적응했지만 더 빠르게 프로젝트 전체 그림을 파악하고 싶다.

Try

Problem의 해결책이 될 수 있는 부분

1. recursive등 고급 SQL을 더 깊게 공부할 것
2. 프로젝트셋팅때부터 질문을 미친듯이 할 것
3. 프로젝트를 한 눈에 빨리 파악하기 위해서는 역시 다양한 프로젝트를 접해본 경험이 중요하다. 앞으로도 성장할 수 있는 기회가 보인다면 미리 걱정하지말고 기회를 잡을 것.

코드리뷰 및 질의응답

팀장님께 부탁드려서 코드리뷰를 진행했다! 바쁘신 와중에도 코드리뷰와 프로젝트리뷰 제안을 흔쾌히 수락해주셨다. 감사합니다 팀장님😀
코드리뷰시간을 알차게 사용하기 위해서는 준비를 철저히 해야한다. 팀장님이 구현한 기능들을 쭈욱 살피고 궁금했던 점들과 구글링을 통해 나오지 않는 질문들, 그리고 구현하던 중 궁금했던 모든 것들을 미리 한 데 모아 노션에 정리했다.

1. pathvariable보다는 query parameter를 사용하는 게 더 나은가요?
   이번에 디테일페이지를 들어갈때 pathvariable를 사용했는데 중간에 로직수정이 필요한 바람에 전부 query parameter를 사용하게 되었다.
   그럼 처음부터 query parameter를 사용하는 게 나았을까하는 의문이 들었다. 네이버나 다음같은 대형사이트들도 대부분 query parameter를 사용하길래 pathvariable은 덜 사용되는 건지 궁금해서 문의드렸다.
   팀장님이 답변해주시길 RESTful API에 맞게 설계하려면 pathvariable를 사용하면 되고 그게 아니라면 query parameter가 더 나은 프로젝트들도 있다고 답변해주셨다!
2. async await는 비동기일때 사용할 것!
   이번에 async await를 이용하여 코드를 구현했는데 팀장님이 코드개선을 한 번해주셨다. 비동기작업이 없는 경우 async await보다는 flag변수를 선언해서 사용하면 빠르고 간단하게 동기작업을 할 수 있다!
3. HashMap 사용시 파라미터 정리를 쉽게할 수 있다.
   파라미터가 많지 않은 경우 HashMap을 사용하여 DAO내에서 파라미터를 제대로 분리해주면 편리하게 사용할 수 있고 각 클래스의 역할도 완벽히 나눌수있다!
4. MariaDB나 MySQL에서는 group by 사용시 모든 select 컬럼을 넣지 않아도 되는 이유?
   기본적으로 group by 사용시 select절의 모든 컬럼을 넣어줘야하는데 MariaDB나 MySQL에서는 넣지 않아도 정상작동한다.
   그 이유가 무엇일까? 바로 sql_mode에 only_full_group_by속성을 on한 경우(참고글) 모든 컬럼을 넣지않아도 DB가 알아서 group by시 필요한 컬럼들을 챙긴다.
   하지만 select절의 모든 컬럼을 넣지 않은 쿼리를 다른 DB에서 실행시 오류가 발행하므로 웬만하면 모든 컬럼을 다 기입하는 버릇을 들이는 것이 좋다.
5. 구글링을 통해 알게된 정보들 중 좋은 글을 어떻게 판단할까요?
   프로젝트를 할때마다 구글링을 정말 많이하게되는데 관련 글을 읽다보면 서로 반대되는 주장을 하는 글이나 뭐보단 뭐가 더 좋다는 비교글이 많이 있다. 이때 어떤 것이 옳은 것인지 판단이 잘 안 설때가 종종 있어 팀장님께 정보글 판단 기준에 대해 여쭤보았다.
   팀장님의 경우 일단 수용 → 직접 테스트코드 작성 → 겪어봐야 알게 됨 주로 이 루트로 판단한다고 하셨다. 나도 글만 읽지말고 Test Unit등을 작성해보는 습관을 들여야겠다.