16. 후기

index

한 달 전으로 돌아간다면

본격 코드 작업 이전에 팀원들이 기능 이외의
불필요한 생각을 덜 하게끔 좀더 명확한 규약을 세운다.

내 실력을 더 객관적으로 바라보고 아무 기능이나
다 가능하듯이 말하지 않는다.

팀원들의 적극적인 회의 참여를 주도하여 핵심 기능에 대한 명세
과정에서 서로 숙지할 수 있도록 이끈다.

포트폴리오도 중요하지만 내 공부도 중요하다.
학원 수업 시간에 혼자 작업하기보단 수업을 들을 것이다.

모든 책임을 내가 지려 하지 말고 팀원을 더 믿는다.

스탠다드한 Rest 방식의 데이터 송수신에 나름 익숙해졌기에
생산성이 조금은 나아졌을 테니, 복잡한 로직에 욕심내고 싶다.

팀장의 고충

1차 프로젝트는 3명이서 진행했고 팀원들 실력이 워낙 좋다보니
나는 명목상 팀장이지, 서로 의견을 내고 피드백을 하며
능동적으로 맡은 파트를 해내고 다른 파트를 지원했다.

최종 프로젝트는 인원부터 5명이다보니.
팀장 노릇을 확실하게 할 사람이 필요했다.
이땐 정말 팀장처럼 대부분의 과정을 지시했다.
사람 다루는 일이 정말 힘든 거구나 새삼 또 느껴졌다.

프로젝트 환경 구성 등 내 할 일을 하면서
업무 지시, 깃헙 등을 함께 공부, 서비스에 대한 명세까지 했다.
몸이 두 개 였으면 하는 생각이 처음 들었다.

프로젝트 기간 동안 몇번이나
그냥 그만두고 싶고,
내가 왜 이렇게까지 고생해야될까
혼자 생각에 잠기기도 했다.

하지만 군말없이 잘 따라와주는 팀원들을 돌아봤을 때
그래도 나는 복에 겨운 팀장이구나 싶었다.

차츰 팀원들이 스스로의 힘으로 결과를 보여줄 때마다
나는 뿌듯했고 내가 시간을 헛되이 보내고 있진 않구나 생각했다.

프론트엔드

우린 템플릿을 가져와 디자인 작업을 했다.
어떻게 보면 이건 실수였다.
만들어져 있는 걸 가공하는 건 굉장히 어려웠다.

그래도 bootstrap.css, 템플릿의 css 파일을
직접 수정 하여, 전체 반영해봄으로써
프론트엔드의 고충또한 알게되었다.

쉬운 게 없구나 생각했고,
프론트는 정말 사용자 편의를 위해서라면 끝이 없다고 느꼈다.

백엔드라고 프론트엔드를 등한시할 게 아니라,
프론트엔드를 기초적으로나마 이해해야 협업이 가능하다 생각한다.

나중에 리액트와 서버 지식도 공부하여
사이드 프로젝트로 상용 서비스를 개발해보고 싶다.

기획, 요구사항, 명세

기획, 설계 단계는 정말 명확해야 했다.
적어도 내가 아는 모든 것을 공유해야 하고,
상대가 말하는 모든 것 또한 귀담아 들어야 한다.

함께 모여 공책에 끄적거리는 걸로 끝내면 절대 안 됐다.
공책에 정확히 작성하든 지, 컴퓨터 앞에서 직접 타이핑하며 해야 한다.

스스로 고객사라 세뇌하며 최대한 요구사항을 작성하긴 했으나,
내면에선 나는 고객사가 아니라며 회피한 순간도 있었다.

커뮤니케이션과 기록은 정말 중요하다.

api

외부 api, 여러 연동 모듈 등
알고나면 굉장히 간편한 것들이지만
시작이 두려워 손을 못 대는 것 같다.

이번엔 시간이 턱없이 부족해서 가져와 쓴 건 별로 없다.

템플릿을 가져와 사용하는 것도 어려웠고,
캘린더에 간단히 표시를 하는 것조차 막막했다.

하지만 하고나면 정말 별 거 아니다.
이건 내 실력과 관련없이,
애초에 오픈소스나 api 개발자분들이 너무 잘 만들어 놨고,
가이드라인도 다 작성되어 있기 때문이다.

프로젝트, 포트폴리오

대학에 가지 않고 건설 등 노동일만 전전하던 내게,
프로젝트라 불리우는 세련된 작업은 처음이다.

난 목적, 의도를 중시하며 살기에
“프로젝트라는 건 어디에 초점을 맞춰야될까” 고민이 많았다.

고민 끝에 나타난 생각은 아래와 같다.

학습 내용에 대한 복습을 통한 성장
협업과 커뮤니케이션 능력 향상
기교부리지 않는 선에서 적합한 api 활용
서비스를 상용화할 지에 대한 여부

우리 팀 모두가 성장하길 바랬고,
끊임없는 커뮤니케이션, 깃을 활용한 협업,
불필요하거나 중요치 않은 api 는 뒤로 미루고,
저작권 등의 문제가 생길 수 있으므로
기능 외적인 것에 대해 스트레스 받지 않도록
상용화는 고려하지 않기로 했다.

팀원들에게 바랬던 점

대단한 건 아니지만, 그동안 스스로 공부하며 느꼈던
개발 철학과 방향을 많이 공유했다.

당장 아래와 같은 내용이 기억난다.

스택 트레이스만 봐도 대부분의 예외를 잡을 수 있다.  
데이터의 흐름을 못 따라간다면 로그를 남겨라.  

커뮤니케이션은 말로만 하는 게 아니라 코드로도 해야한다.  
남들이 알아볼 수 있는 코드를 작성해야 한다.  

그리고 내게 뭔가 물어볼 때면,
자신의 손으로 완성할 수 있도록 몇가지 포인트만 짚어줬다.

떠먹여 준 것도 아니다.
다들 알아서 잘 해냈다.
난 그런 걸 원하기도 했다.

자기주도 학습

따뜻한 학원의 품을 벗어나면 찬 바람이 썡썡 불 게 뻔하다.
나는 팀원들이 스스로 공부하는 법을 배우길 바랬다.

팀원의 입장이 된다면

프로젝트 매니저가 처음 말 할 때 확실히 들어 둔다.
내가 구상한 방향을 스케치하건 상세히 나타내어 의논한다.

내 업무에 신경쓰지 않도록 믿음을 주고 싶다.
책임을 나눌 수 있는 팀원이 되고 싶다.

반성해야될 점

암호화 암호화는 단방향이어야 된다는 걸 알게 되었다.
패스워드를 암호화에 Base64 를 사용했는데, 복호화가 가능하여 무의미하다는 걸 알게 되었다.
쿠키에 어쩔 수 없이 회원 정보를 줘야할 때는 괜찮은 것 같다.

인덱스 조회
많은 도서 데이터를 활용해보고 데이터베이스 인덱스의 중요성을 또다시 느꼈다.
검색이 필요할 때 반드시 인덱스 컬럼으로 찾도록 sql 을 짜야된다.

예외
역시 정상 로직보단 예외에 대한 경우의 수를 철저히 방어하는 게 훨씬 어려운 것 같다.

적용하지 못한 기능

Security
적어도 내가 맡은 계정 관련해선 완벽하게 짜고 싶었지만
시간과 역량이 부족했던 것 같다.
중복 회원 관련 세션 관리조차 하지 못했다.

Batch
게시판 글 목록,
체크아웃 하지 않고 간 회원
두 가지 처리를 배치로 하고 싶었다.

Web Socket
회원 대여 예약 시, Staff 에게 알림을 보내고 싶었다.

돈 계산 로직
어떤 프로젝트를 할 지 결정할 떄부터,
돈 계산이 많은 프로젝트를 하고 싶었다.
중고 거래 플랫폼이나 쇼핑몰을 떠올렸는데
팀원이 도서관 얘기를 꺼내서 대여료 관련해서 넣자고 생각했다.
구현은 했으나 지표를 좀더 다양히 보여주는 건 시간이 부족했다.

최근 본 도서 목록
쿠키를 통해서 최근 본 도서 목록을 우측 네비게이터에 넣고 싶었다.

관리자의 다양한 기능
관리자 페이지에서
자유게시판 말머리,
멤버십 가입비,
멤버십 별 혜택 등을 수정할 수 있도록 테이블을 만들었으나
이또한 시간이 부족했다.

느낀 점

다 적고나니 정말 지친다.

원래는 원대한 계획을 갖고 있었는데,
최종 프로젝트가 끝나면 스프링 부트와 JPA 환경으로 갈아 끼우는 거다.

데이터베이스 관련 설정만 좀 건드리면 될 것 같았지만
동적 쿼리가 많은 Betty 소스를 단순히 JPA 로 바꾸고 싶다 하여 기능을 구현할 수 없을 것 같다.

아마도 QueryDSL 이란 걸 배워야 될 듯하다.
부트 환경으로도 섵불리 못하겠는 건,

취업 준비와 함께 만지기엔 시간이 많이 소요될 것 같다.
스프링 부트 공식 문서도 열심히 들여다보고 있을 게 뻔하기 때문이다.

참고한 부분

이번 포트폴리오에서 굉장히 큰 도움을 받은 블로그

Yun Blog

해당 페이지 이외에도 눈여겨 볼 포스트들이 굉장히 많다.

모든 도서 관련 자료들은 알라딘 사이트를 참고하였습니다.