** 기획, DB 설계, UI 설계, Problem-solving 및 결과 페이지는 별도의 게시물로 작성하였습니다. Semi-AllCampus 시리즈에서 확인할 수 있습니다.
1. 칭찬하고 싶은 점
칭찬하고 싶은 점을 다르게 말하면, 파이널 프로젝트에 가서도 진행하고 싶은 프로세스 정도라고 생각할 수 있겠다.
1-1. 내부 일정을 타이트하게 잡기
내부 일정을 타이트하게 잡은 덕분에 PPT 및 발표 준비가 원활하게 이루어졌다. 아무리 학원 내부에서 진행되는 발표라고 하더라도 발표 준비를 허술하게 하는 것은 프로답지 못하다고 생각했다. 그 아이템이 무엇이든 자신이 만든 것을 알리지 못하면 무용하다.
나의 전공 탓도 있는 것 같지만 안 하느니만 못한 발표를 하고 싶진 않았기 때문에 팀원들을 설득, 일정을 타이트하게 잡고 모두가 잊지 않도록 정리하여 공유하는 작업을 계속했다.
1-2. 노션 데이터베이스를 이용해 개발일지 누적하기
메인, 헤더 담당이라 다른 사람들의 작업이 이루어지길 기다렸다가 완료되면 Select로 읽어와야 하는 일들이 많았다. 그렇기 때문에 일정 정리가 제대로 되지 않으면 놓치는 부분이 발생할 거라고 생각했다. 그리고 팀회의 시간의 질을 높이기 위해서라도 회의 주제와 과제를 철저히 구분해 기록하고 공유해야만 놓치는 인원 없이 잘 따라올 거라고 생각했다.
나 또한, 변경 사항이 기억나지 않을 때마다 데이터베이스를 들여다보며 진행 상황 등을 복기할 수 있어 도움을 많이 받았다.
1-3. 적극적으로 커뮤니케이션 및 피드백하기
디스코드를 활용해 변경 사항을 백업할 수 있도록 제안했던 것이 나였기에 적극적으로 사용한 것도 나였고, 단체 채팅방에서 팀원들에게 가장 많은 사항들을 피드백하고 일정을 공유하고 의견을 물은 것도 나였다.
원활한 팀플을 위해서는 커뮤니케이션이 제일 우선시되어야 한다고 배웠다. 그리고 아무리 각자의 기능은 알아서 책임지고 구현하기로 했다지만, 그것들이 모여 하나의 사이트를 만드는 게 우리의 목표인데 남이사 오류가 어디서 나든 말든 스타일이 깨지든 말든 내버려두면 안 되는 건 아닌가 하는 생각이 있었다.
사실 매 일정을 준수하지 못하고 늦는 팀원 때문에 내가 해야 하는 PPT 작업이 차일피일 계속 밀릴 때는 정말 포기하고 싶었다. 그래도 그 팀원이 제몫을 해낼 수 있도록 모두가 인내하고 기다린 덕에 시연 시 '완성도가 높다'라는 피드백을 받을 수 있었다고 생각한다.
2. 아쉬운 점
2-1. 기능 구현에 좀 더 집중할 걸
끝나고 보니 더 욕심낼 수 있었다는 생각이 든다. 회원가입-로그인 부분이 빠르게 처리되어야 회원제 서비스를 구현하기에 용이했기 때문에 다른 팀원들보다 빨리 작업에 착수했고, 그 덕에 시간 여유가 있어 UI를 신경쓰다 보니 어쩌다ㅜㅜ UI 총괄이 되었다.
팀원들이 '페브님 덕에 UI가 진짜 깔끔해졌다'고 피드백 해줄 정도로 신경을 많이 썼다. (나도 익숙한 편이 아니라 고생을 많이 했어서 그 말을 들었을 땐 솔직히 눈물날 뻔했다 ㅜㅜ) 후회까진 아니지만 그 시간에 기능을 더 구현해보며 나의 역량을 테스트하고, 모르는 건 선생님께 질문도 해가며 프로젝트를 진행할 걸 그랬다는 생각이 든다.
파이널 프로젝트에서는 퀄리티 상승에 일조하기 위해 전체를 보는 것과 나의 기능 구현에 집중하는 것중 후자에 더 집중해보고 싶다.
2-2. 업무 순서를 제대로 짜지 않고 소요 시간을 파악하지 않은 것
내 나름의 업무 진행 순서를 철저히 기록해둘 필요가 있었다고 생각한다. 돌이켜보니 손에 잡히는 대로 혹은 그날 끌리는 대로 일정 관리를 했던 것 같다. 00일까지 이걸 해내야지가 아니라 오늘이 00일인데 여기까지 했다 이런 식?
Spring Boot를 배우는 지금, 그보다는 MVC2 패턴이 간단하긴 하지만 vo → DAO → action → jsp(view) 이런 식으로 내부 순서를 짰다면 아주 조금이라도 더 효율적으로 일정 관리를 할 수 있었을 것이라고 생각한다.
그리고 업무 소요 시간이 파악되어야 그 날 소화해야 하는 업무량을 정할 수 있고, 비는 시간이 생겼을 때 그 시간을 더 효율적으로 사용했을 거라고 생각한다. 처음해보는 개발 팀플이라 눈 앞에 있는 걸 빨리하자는 생각에 업무 계획을 세우는 것에 느슨하지 않았나 싶다.
2-3. 코드 리뷰를 하고 싶었다!
우리 팀에도 전공자들이 있었기 때문에 내가 작성한 코드 자체를 피드백받고 더 효율적인 코드, 클린 코드가 되려면 어떻게 해야 하는지 리뷰 시간을 갖고 싶은 마음이 컸다. 계획은 그러했지만 ^^; 현실은 시연 과정에서 오류가 나는 것은 없는지 살펴 보고 피드백해주는 게 전부였다. 물론 다른 사람이 작성한 코드를 내가 시간을 내어 살펴보며 좋은 건 차용해도 되긴 하지만, 팀원들에게 피드백 받으며 얻어가는 것이 분명 있지 않았을까 싶어 아쉬움이 남는다.
3. 다음 프로젝트에서 새로 시도하고 싶은 것
3-1. 외부 API 사용
Spring Boot로 파이널 프로젝트를 진행하면서는 외부 API를 적극 사용해 퀄리티를 한층 더 끌어올리고 싶다. 사용하길 원하는 외부 API로는 간편 결제, 이메일 전송 등이 있다.
3-2. 예약 기능
세미 프로젝트에서 진행한 건 회원 관리와 일반 게시판 형태의 중고거래라서 '쇼핑몰' 형태나 '예약/예매' 형태의 기능을 담당해보고 싶다. 복잡해서 질문할 거리도 많고 스트레스도 많이 받겠지만, 구현했을 때 성취감이 매우 클 것 같다.
4. 내가 생각하는 좋은 개발자란?
다른 분들의 회고록을 찾아 보다가 좋은 항목 같아서 가져와봤다.
4-1. 자신의 역량을 정확히 파악하고 있는 개발자
그렇지 않으면 팀원에게 피해를 준다. 혼자 일정을 무한정 조정할 수 있는 사이드프로젝트라면 모를까, 듀데잇이 소화하기에 버겁다면 양해를 구해야 하고 늦을 것 같으면 미리 사과하고 공유해야 한다.
주니어 단계에서는 아무래도 어렵겠지만, 그럴수록 업무 소요 시간도 체크하고 다른 분들의 개발 과정도 구글링해가며 더욱 철저히 챙겨야 하는 부분이라고 생각했다.
4-2. 원하는 것을 이해하기 쉽게 말할 수 있는 개발자
국비 팀프로젝트의 특성상 기획 단계부터 함께했는데, 자신이 무얼 구현하고 싶어하는지/이건 왜 구현하기 어려운지/어떻게 구현하면 되는지 말하지 못하는 사람이 많아 보였다. 혼자 모든 업무를 다 맡을 것이 아니라면 주장을 명확히, 능력차가 있는 사람도 이해할 수 있도록 풀어 설명할 수 있는 능력을 갖춰야 한다고 생각했다. 이를 위해서도 역시나 4-1이 필요하지 않나 생각해본다.
5. 최종 후기
코딩하면 시간이 정말 빨리 간다... 회고록을 작성하며 일정 복기를 해보니 언제 이 시간이 다 지나갔는지 모를 일이다 싶은 거다. 뭐 다르게 말하면 '결국 다 지나간다'가 되겠지. 긍정적으로 생각해본다. 시간이 빨리 가는 건 내가 집중했다는 뜻일 테니까.
확실한 건 재밌었다는 것이다. 업무 혹은 업무 외적인 요소에 스트레스를 왕창 받아도 다시 노트북 앞에 앉아 이클립스를 켤 만큼 코딩은 매력적이라는 것을 배웠다. 그리고 개인 능력을 쑥쑥 키워 깊이와 폭을 모두 갖춘 개발자가 되고 싶어졌다. 아 주말에 이렇게 공부하는 사람이 많다는 것도 알게 되었다^^ 놀라운 점은 그들의 80% 정도는 개발자라는 점이고....내 미래고....ㅋㅋㅋㅋㅋㅋㅋ
파이널 프로젝트에서는 조금 더 나를 믿고 싶다. 그리고 앞서 작성한 내용들을 명심하며 팀플을 진행, 프로젝트 퀄리티와 그 외적인 측면에 보다 만족한다고 회고록을 작성할 수 있었으면 좋겠다. 다시 돌아온 취준까지 빠이팅야 !!
