** 기획, DB 설계, UI 설계, UML 설계 및 메뉴 구조도 작성과 결과 페이지는 별도의 게시물로 작성하였습니다. Final-ZIBI 시리즈에서 확인할 수 있습니다.
1. 칭찬하고 싶은 점
1-1. 수용과 보완
세미 프로젝트 회고록을 작성하며 잘했다고 여긴 점은 적용하고 부족했던 점은 보완하여 파이널 프로젝트를 진행했다. 팀원 구성에 큰 차이가 없었기에 운영 방침을 정하는 것에 어려움이 없었고, 새로 오신 분이 팀장님이 되면서 그 분의 의견 중 좋은 것을 수용해 더 나은 운영이 가능했다고 생각한다.
그리고 팀장님이 일정을 운영하는 방식이 나와 잘 맞았으며 책임감도 강한 분이었던 덕분에 이번 프로젝트에서는 나의 기능 구현에 좀 더 집중할 수 있었다. 정말 감사하다고 말씀드리고 싶다!
타이트한 일정상 제대로 된 코드 리뷰는 어려웠지만, 서로의 코드를 봐주고 보다 효율적인 코드를 짤 수 있도록 대화하는 시간을 더 많이 가졌다. 세미 프로젝트를 거치며 팀원들 대부분이 친밀감을 쌓으며 더 적극적으로 변한 덕분이었다. 분명 더 많은 작업을 했는데 더 여유 있었다.
MVC2 패턴을 배움에 있어 충분한 시간이 주어졌던 것과 달리, 스프링 부트는 수업과 프로젝트가 완벽히 동시에 진행되었다. 그랬기에 누락되는 파일 혹은 설정이 없도록 하려면 업무 순서를 명시해두어야 한다고 생각했다.
프로젝트 관리용 노션 페이지에 업무 순서 외에도 클린코드 규칙, 자주 발생하는 에러 해결 방법 등을 명시해 오며가며 계속 눈에 익도록 했다.
매일 저녁 개발일지를 누적하며 데이터베이스를 정리할 때 내일 처리할 업무를 정리하는 시간도 추가했다. 두 번째 프로젝트를 운영하며 내 실력을 어느 정도는 파악하게 되었다 싶어 신기했다.
1-2. 디테일을 살림
프로젝트를 진행할 때 기능을 최대한 많이 구현해보는 것은 그 누구도 뭐라할 수 없는 핵심 목적이다.
하지만 디테일한 부분을 신경 써보지 않고 고민하지 않으면 막상 신경 써야 할 때 문제가 생긴다는 게 내 생각이었다. 팀 프로젝트는 내가 자의로 조절할 수 없는 타이트한 일정 속에서 이루어진다. 따라서 이럴 때 안내 문구 하나, 위치 하나라도 좋으니 사용자의 편의를 생각하며 코드를 짜는 경험을 해봐야 한다고 믿었다.
이용에 불편함이 없도록 사용자의 입장에서 할 수 있는 한 최선을 다했다. 디테일에 집착한 게 아니라 디테일을 살렸다. 화면 이미지는 이전 게시글에서 확인할 수 있다.
2. 아쉬운 점
2-1. 컬럼이 너무 많았다.
DB 설계 시 '컬럼이 너무 많아 이후에 힘들 것'이라는 피드백을 강사님으로부터 받았었다. 추린다고 추렸는데, 그 당시에는 포기할 수 없는 기능이라고 생각해 변경하지 않은 것들이 많았다. 그 결과 무수히 많은 조건 체크 지옥에 갇혔다. (나의 모임 내역에만 약 30가지의 조건 체크가 필요했다.)
경우의 수를 그림으로 그려가며 UI 등에서 예외 사항이 발생하지 않도록 마지막에 마지막까지 신경 쓴 덕분에 완성은 했지만, 이게 좋은 설계라는 생각은 들지 않았다.
물론 현업에서는 컬럼의 양과 데이터의 양이 더 많겠지. 나는 단지 지금의 내 상황에서 컬럼의 양을 적절히 조절할 수 있도록 기획 단계에서 조금 더 신경을 썼어야 한다고 말하고 싶은 것이다. 큰 그림 그리기의 부재였다고나 할까.
이번 경험을 통해 '큰 그림 그리기'의 중요성에 대해 다시 한 번 배웠다.
3. 다음 프로젝트에서 새로 시도하고 싶은 것
3-1. 결제 기능
이메일 전송, 이지웍에디터, 주소 API, SNS 공유 등 세미 프로젝트와는 비교할 수 없을 정도로 다양한 기능들을 구현했다. 결제 기능, 특히 간편 결제 기능을 구현해 보면 재밌을 것 같다고 생각했다.
3-2. 더 다양한 API
다른 조의 발표를 들으며 생소한 API/라이브러리들이 많아 흥미로웠다. 예를 들자면 네이버 이미지 캡차 API, TMDB, 하이차트 등이 있다. 우리 사이트에 적용한다면 어떻게 사용할 수 있을까, 어떤 원리로 작동되는 걸까를 생각하며 발표에 더 집중할 수 있었다. 확실히 스프링 부트로 넘어오니 세미 때보다 재미가 있었다.
4. 내가 생각하는 좋은 개발자란?
4-1. 나눔을 즐길 수 있는 개발자
세미 회고록에서 자신의 역량을 정확히 파악하고 있는 개발자, 원하는 것을 이해하기 쉽게 말할 수 있는 개발자를 꼽은 바 있다. 파이널을 진행하며 느낀 '좋은 개발자'의 덕목은 '나눔을 즐길 수 있는가'였다.
나는 광고 전공을 졸업해 2곳의 광고 대행사에서 일했다. 많은 이들이 잘 모르겠지만 광고 대행사의 업무는 대부분 폐쇄적으로 이루어진다. 비딩(광고 수주를 위해 기획서 PT 등을 진행하는 일)에 앞서 기획서 작성에 참여를 하였는데도 말단 직원은 기획서 완성본은 구경할 수조차 없는 일도 많다. (이전 회사에서는 작성한 장표마다 작성자 이름도 썼다 ㅎㅎ..)
그런 환경에서 일해오다 보니 모드 전환이 늦었던 것 같다. 나름대로는 엄청난 구글링과 오랜 시간을 거쳐 CSS 하나를 변경한 뒤 팀 repo에 commit을 해두면, 다른 팀원이 홀랑 가져다 쓰는 게 너무 스트레스였던 거다. '그래도 우리가 "풀스택" 과정인데 말도 없이 가져간다고??', 'CSS는 신경 쓰는 사람이 손해라는 말이 있다지만 이래도 돼?', '컨트롤러단도 아니고 CSS 일부일 뿐이지만.. 하지만..하지만!!!' 싶어 꽁해 있기도 했다.
그러던 나는 팀장님으로부터 도움을 받으며 생각을 바꾸게 되었다. 회원가입/로그인을 맡아 다른 팀원들보다 작업을 빨리 시작한 분이었는데, CSS 기틀을 잡으며 팀원들에게 자신이 짜둔 코드들을 흔쾌히 퍼주는 게(?) 아닌가! 게다가 기능적인 부분을 구현함에 어려움이 있을 때에도 함께 논의하고 같이 고민해 주는 모습을 보면서 '내가 모드 전환이 되지 않았었다'는 것을 인정하게 되었다. 생각해 보면 나도 구글링을 통해 다른 개발자들이 짠 코드를 참고한 건데, 왜 내가 나누는 건 그렇게 아까워했을까. 창피하기도 하고, 이제 알았으니 다행이다 싶기도 하고.
앞서 팀원들끼리 세미 때보다 더 많이 대화하고 도움을 주었다고 말한 바 있는데, 그런 분위기가 형성된 건 전적으로 새로 우리 팀에 합류한 팀장님 덕분이다. 이 사실을 깨달은 뒤에는 도움을 요청하는 것도, 도움을 주는 것도 즐겁고 마음 편한 일이 되었다. 중요한 사실을 이제라도 배우게 되어 다행이다.
5. 최종 후기
벌써 수료한지 12일이나 지났다니. 수업이 끝나고 집에 오면 최소 2시간에서 4~5시간까지 복습에 몰두했던 5.5개월이 끝났다는 게 지금도 믿기지 않는다.
좋은 팀장님과 더 친해진 팀원들 덕분에 팀 프로젝트 다운 팀 프로젝트를 경험할 수 있었다. 외부 API를 사용하며 기능 구현의 폭이 넓어진 덕에 작업하는 내내 너무 재밌었고, 강사님 도움을 받으며 어렵게만 느껴졌던 기능을 구현해낼 때마다 쾌감도 엄청 났다.
세미 프로젝트를 끝마친 뒤의 바람대로, 나의 속도를 믿고 여유를 갖춘 채 프로젝트를 진행했다는 점을 너무너무너무 칭찬해 주고 싶다. 내 이름을 걸고 하는 나의 일, 나는 개발을 더 잘하고 싶다!
