complainZero 프로젝트 회고

뉴딜 과정이 끝났다

ComplainZero

비교적 짧은 시간 내에 구현해야했던 는 많은 기능을 배제하고 할 수 있는 것에만 집중하기로 팀원들 내 합의 후 진행한 프로젝트였다.

원래는 게시판 겸 펀딩 사이트를 구현하려고 했는데 몸집이 너무 커지기도 커져서… 결국 중계 사이트를 만들었다. 유스케이스는 그리지 않아 권한 별 설정을 보여주기 위해 만든 PT…

프로젝트 전반에 대한 회고

시간 압박에 쫓겨 개인적으로 배우는 프로젝트였다기보단 빨리 빨리 구현에 중점을 둔 프로젝트였다. 코드를 타이핑하는데에 급급해 문서 작성을 하지 않았고, 이 때문에 불필요한 작업들을 여러 번 하는 경우도 있었다. 내가 한 줄의 코드를 짜는 것보다 타인과 소통하며 협업하는 게 더 중요하다는 걸 배웠지만…. 소통이 안되는 건 내 문제인가….. 하하…

프로젝트 구현

구현에 있어 제일 힘들었던 것은 프로시저와 트리거 내 루프문 제어였다. 포스팅을 통해 트러블 슈팅을 기록하겠지만, 왜 안되는지 알 수 없는… 그런 거였다. 레퍼런스가 많기에 구현에 그다지 오래 걸리지 않으리라 생각했는데 데이터베이스마다 조금씩 문법 차이가 있어 레퍼런스 예제 소스가 전혀 적용이 안됐다ㅠㅠㅠ 사용한 maria DB는 insert all과 같이 mysql에서 제공하는 다중 데이터 insert 문을 제공해주지 않았고, 트리거 내에서도 사용이 힘들었다. 이에 모든 걸 DB에서 처리해야겠다는 계획을 변경해 서비스 단에서 트랜젝션을 이용해 제어를 시도했다.

프로시저 또한 힘들었다. 이것도 정말… 트러블 슈팅 꼭 기록할 것. 프로젝트 내 게시물 상세보기는 조건에 따라 join테이블이 달라지는데, 조건을 사용해야 했기에 결과적으로 DB 처리를 원하면 프로시저를 사용해야한다는 것을 알았다. 트랜젝션을 생성해 DB GUI 툴에서 실행했을 때 정상적인 값을 가지고 오는 것을 확인했건만 호출 결과와 mybatis의 연동이 자동으로 되지 않아 원인을 찾는데 많은 시간이 소비되었다.

아쉬운 점

전반 회고 맥락과 비슷하게, 기능적으로는 배우는 게 많이 없었던 프로젝트였다. 이미 해보거나 잘하는 기능을 맡아 구현했다. 욕심 부리지 않기 위해 프로젝트 규모를 작게 잡아 되레 인원에 비해 너무 소소한 프로젝트였다고 생각한다. 사실… 우리가 4명이었지만 거의 3명인 조였고… 하아… 만약 기회가 된다면 펀딩 사이트처럼 연계 알림 후 결제 시스템을 구현해보거나, 카카오나 네이버 아이디를 이용한 회원가입을 구현해도 재밌었으리라 생각한다.

처음에 하지 않은 문서 작업이 뒤에서 크게 발목을 잡으리라 생각치 못한 프로젝트였다. 폴더 구조를 짜두고 시작한 것이 아닌 터라, 나중에 시큐리티 패턴식을 적용하거나 타일즈를 구현할 적마다 폴더 구조를 다시 맞춰야 하는 번거로움이 발생했고, 후에 적용하면 할수록 팀원 간 혼동도 잦았다. 또한 트러블슈팅을 하지 않아 팀원 내 똑같은 에러가 발생해도 팀원 내부에서 도움을 주지 못하고, 문제가 발생한 회원이 다시 레퍼런스를 찾아봐야 하는 등의 비효율적인 측면도 두드러진 프로젝트였다. 특별한 api를 적용하는 경험은 하지 못했지만 문서 작업과 협업에 대해 생각해보는 계기였다.