들어가기 전에
이번 프로젝트를 진행하며 팀장으로서 느낀 점들을 따로 기술하기 위해 이번 글을 쓴다. 팀원은 모두 비전공자이자 갓 개발을 시작한 국비 훈련생이었고, 때문에 완벽한 소프트웨어 공학적인 프로세스를 진행한 건 아니었다. 그래도 주제에 걸맞게 애자일처럼 제품 고민부터 설계, 개발까지 모두 끝내보게 되었다. 부족한 스크럼 마스터(?)가 되어 어떻게 지금까지 시간을 분배했고 나아왔는지 적어보려 한다.
시간 분배
개발 정량으로는 120시간 개발시간이 주어지게 되었다. 잘못한 점, 잘한 점을 말하기 전에 우선 절대적인 시간을 어떻게 투자했는지 대충이나마 적어놓으려 한다. 목록을 적어두고 하나하나 짚는 시간을 가지도록 하겠다.
- Github Pull Request 10시간
- 프로젝트 통합 10시간
- 잡다한 질문들(예. 중복체크 시 회원가입 버튼이 안눌림, 문의게시판 댓글이 안 달림, 마이페이지 전체 체크박스 체크 등등) 6시간
- Bootstrap 5.1 안내 2시간
- 팀원 Eclipse 및 sql developer 오류 잡기 2시간
- 팀원 테이블 설계 변경으로 db 변경 1시간
Github는 도움이 되었는가?
- Github Pull Request 10시간
- 프로젝트 통합 10시간
위 시간 분배를 보면 알겠지만, Github을 팀원들에게 전파해주고 또 프로젝트를 통합하는데 많은 시간이 소요되었다. 원래도 알고 있었지만, 이번 프로젝트를 하면서 확신하게 되었다. Github는 초보자에게 매우 어려운 툴이다. 하지만, 그렇다고 다른 수단을 활용했을 때 Github만큼의 효율이 나오는가? 내 짧은 식견으로 보기에 Spring 개발에 한해서는 대체 수단은 거의 없다. 주변에서 쉽게 접할 수 있는 클라우드들이나 메신저로 압축파일을 주고받는 걸 비교했을 때 장점이 특출나다.
그 장점의 이유는 간단히 줄일 수 있다. 개발소스의 모든게 이진파일이 아닌 텍스트로 나오기 때문이다.
파일을 이미 프로젝트에 업로드한 게 있다면, 이진파일은 그 안 내용이 수정된 건 보이지 않고, 텍스트 파일은 수정내용이 모두 보이게 된다. 이건 일반 압축파일로 주고 받는다면 절대 얻을 수 없는 최대 장점이다. 팀장은 프로젝트를 통합하는만큼 프로젝트를 지키는데 진심이어야 한다. 팀원이 실수로 다른 사람의 코드를 날리게 되더라도 이전 버전으로 롤백이 가능해야하거나 막을 수 있는 능력이 있어야한다. 저렇게 변경하거나 삭제하는 텍스트 제목만 확인해도 그 사람이 담당한 파일인지 확인 가능하기 때문에 관리하기가 매우 쉽다.
다음은 팀원이 커밋을 실수하여 파일을 날릴 뻔하는 예이다. (이때는 연습기간이었기 때문에 간단한 파일들이어서 날려도 상관은 없었다.)
지금보면 빨간색으로 되어있는건 모두 삭제한다는 내용이다. 이를 쉽게 식별하고 커밋을 닫을 수 있다. 또 실수로 이 커밋을 받아주더라도, 커밋을 통해 쉽게 롤백이 가능하다.
위 장점은 소스가 텍스트라는 장점과 시너지를 일으켜 관리하는 패키지가 많을 때 큰 장점으로 다가온다. 우리가 이번에 만든 것 같은 아주 기초적인 프로젝트일지라도 패키지가 많다.
나도 절대 숙련자라고는 말하지 못하겠지만, 5개월동안 협업을 하고 프로젝트에만 300커밋 가까이 해오면서 이 프로젝트를 압축파일 형태로 주고받았다면 제대로 관리할 수 있었을까 싶다.
롤백상황이 되었을 때 롤백을 아주 쉽게 받아들일 수 있는 것도 팀장의 능력이라 할 수 있겠다. 즉, 팀원이 Github를 모를 때 안내해주는 건 합당한 선택이었던 것 같고 투자한 20시간이 그렇게 아깝지 않았던 것 같다.
개발자로서 질문할 수 있다는 것
- 잡다한 질문들(예. 중복체크 시 회원가입 버튼이 안눌림, 문의게시판 댓글이 안 달림, 마이페이지 전체 체크박스 체크 등등) 6시간
내가 생각하기에 개발자로서 누군가에게 질문할 수 있다는 건 굉장히 큰 장점이라고 생각한다. 사실 개발자에게 무언가를 질문한다는 건 굉장히 어려운 일이다. 자신의 상황을 말로 완전히 풀어 설명하는 것도 어려울 뿐더러 대체로 남의 답을 듣고 해결할 정도면 자신이 그 상황을 완벽히 파악하고 있는 경우가 많기 때문이다.
나를 믿고 질문해주었기 때문에, 성심성의껏 대답해주었다. 하지만, 근본적으로 문제를 파악하지 못하고, 시간을 써야할 구간에 시간을 안 쓰고 물어볼 경우에는 냉정하게 대했던 것 같다. 그런 경우엔 문제 접근 방법이 잘못된 경우가 많았기 때문에 접근 방법을 제시하였다.
지금 생각해보면 팀장 1명, 팀원이 5명이었기 때문에 개발을 상대적으로 조금 적게 맡고 하루 개발시간의 10% 정도 팀장이 다른 사람 옆에 앉아 함께 개발하는 방법도 유효한 것 같다. 그렇게 되면 일주일 동안 한 것을 확인도 하면서 프로젝트 병합도 쉽게 진행시킬 수 있는 것 같다. 하지만, 보통 이건 적용하기 힘든 막바지에 다다러서 깨닫기 때문에 현재 깨달은 것 같다 :(
스타일 통일
- Bootstrap 5.1 안내 2시간
CSS 스타일로는 twitter에서 개발하여 무료로 푼 것으로 유명한 BootStrap을 사용하였다.
테마는 Simplex를 사용하였고 팀원들과 통일된 테마를 사용하게 하기위해 CSS를 안내하는데 시간을 썼다. 다음은 팀원들에게 알려주었던 사이트이자 내 자신도 참조하니 좋았던 사이트이다.
BootSwatch
W3Schools Bootstrap5
getbootstrap DOCS
BootSwatch 는 특히 보고 적용하기 쉬운데 그래서 다음과 같이 쉽게 쓰고 적용했다. 그리고 팀원들에게 공유하여 웹사이트 전체적인 색깔을 통일시켰다.
Bootstrap 적용시 주의점은 3, 4 그리고 5가 모두 문법이 다르다는 사실이다. 필자는 5였으므로 5에 따른 문서를 찾기위해 부단히 노력하여 CSS를 적용하였다.
기초 설정
- 팀원 Eclipse 및 sql developer 오류 잡기 1시간
- 팀원 테이블 설계 변경으로 db 변경 1시간
아직은 모두가 초보자이자 입문자이기 때문에 완벽한 설계는 없었으며 많은 부분 고쳐가며 개발을 진행했다. 또 이번에 느낀 건데 ObjectAid의 클래스 다이어그램, 그리고 개발 환경을 맞추기 위해 시작할 때는 모두가 Eclipse 2020-03 버전을 사용하였으나 어느새 켜보니 본인을 포함하여 팀원 대다수의 Eclipse 가 2021-12 버전으로 업그레이드 되어있었다. 하지만, 다행히도 프로젝트는 문제 없이 돌아갔으며 버전을 맞추기 위해선 자동 업데이트부터 막는 방법을 찾고 시작해야할 것 같다.
마무리하며
이번 프로젝트를 진행하며, 팀을 위해 쓴 시간들을 복기해보았다. 팀원과 많은 부분 신뢰관계가 두터웠기 때문에 지금까지 진행되었던 것 같다. 이번 프로젝트를 양분 삼아 앞으로 도약하기 위해 노력해야할 것 같다. :) 프로젝트가 성공적으로 마쳐가는 것 같아 팀원들에게 모두 그 공을 돌린다. 국비과정을 듣고 있는 개발자 모두를 항상 응원한다. 항상 파이팅!!
