9개월 개발자, 두 번째 프로젝트를 마친 후 느낀 점
서론
6개월차 신입 개발자의 2019년 회고록을 작성하고 벌써 3달이 지났다.
나의 회사 생활 시간은 1년이 마치 1달 같다. (선임들도 나만 시간이 되게 빠른것 같다고 하신다..) 첫 프로젝트 동구청을 마치고 두 번째 프로젝트인 공주대를 진행하면서 느끼고 배운점 들을 글로 남겨두려 한다.
두 번째 프로젝트 : 공주대학교
이번 프로젝트는 기간이 넉넉하지 않았다. 약 2 달간 진행한 프로젝트인데 결과는 일단 성공적으로 마무리 지었다. 첫 프로젝트에서는 구청 웹 페이지 제작이었으며, 이번엔 대학 웹페이지 제작이어서 비슷하지만 다른 경험을 한다는 것에 대해 배울게 많을 것 같다고 느꼈다.
이번 프로젝트의 팀원은 개발팀장(차장)님(5년차), 여자개발자선임(4년차), 나(1년차) 이렇게 3명이서 구성되었으며 두 분다 일을 깔끔하게 하는 스타일이라 프로젝트가 산으로 갈 걱정은 전혀 하지 않았다.
팀장님과 같이하는 첫 프로젝트였는데 같이 일해보니 코딩만 잘한다고 팀장이 될 수 있는건 절대 아닌것 같다. 팀원 입장에서 지켜본 결과 팀장의 자질 중 가장 중요하다고 느낀 것은 프로젝트가 산으로 가지 않게 일정 조율을 잘 하며, 다른 프로젝트를 진행하는 개발 팀원들의 프로젝트까지 어느정도 신경을 쓰고 관리해야한다는 점인것 같다.
구청과 대학 웹 페이지 제작에 있어서, 두 가지의 가장 큰 차이점은 사용자 페이지의 모든 게시판에 글을 작성하기 위해선 직원, 학생, 교수들이 로그인을 하고 글을 작성한다는 점에서, 사용자 페이지에서도 권한체크가 따로 필요했다. 이 부분은 4년차이신 여자 선임 개발자 분께서 처리 해주셨다.
권한 부분은 정말 민감한것 같다.. 이번 프로젝트를 하면서 스프링 시큐리티 공부 필요성을 느꼈다.
이번 1차 산업 프로젝트(공주대학교) 를 진행하면서 개발해야하는 프로그램 들 중 가장 신경써야 하는 두 프로그램이 있는데 조직도(대표 조직도/직원관리, 학과 조직도/교수관리)와 시설물 사용신청 이었다.
운이 좋게도 이 가장 중요한 프로그램 2개를 내가 맡게 되었다. (아마 팀장님께서 여러 경험을 해보라고 나한테 맡기신게 아닌가 싶다.)
조직도 프로그램 개발
대학과 학과 조직도가 정말 이렇게 사이즈가 큰 편인줄 몰랐다. 구청 조직도와 대학 조직도는 극과 극인것 같다. (프로그램마다 다르겠지만, 대학 조직도 사이즈가 훨씬 큰편)
조직도를 개발할 때 한번 공주대 공주 캠퍼스에 가서 코딩을 한적이 있다.
밤 7시 30분 쯤 찍은 사진인데 건물이 되게 낡아 보였다. 캠퍼스 구경 같은건 하지 못하고 코딩만 하다 가서 조금 아쉬웠다.
결과적으로 조직도 프로그램을 마무리는 잘 지엇지만, 만족하는 프로그램이냐? 라고 물어본다면 NO 이다.
첫 번째 이유: 조직도라는 큰 프로그램을 처음 개발하기 때문에 로직을 생각하는 부분에 있어서 미숙했다. (경험 부족)두 번째 이유: 기획자 분이 처음 웹 기획자로써 일하는 거였기 때문에, 공주대 담당자분과 협의 과정에서 미숙한 부분이 많았다. 결국 프로젝트 끝날때 까지 자잘자잘한 요청사항과 수정사항이 들어왔다. (고객 변심이 가장 많은 프로그램이었다.)세 번째 이유: 리팩토링 방법 미숙. 프로젝트를 진행하다가 주말에 집에서 서로 Team Viewer 를 키고 팀장님과 일을 했었는데.. 내 코드를 내가 한참을 보고서도 어떤 역할을 하는것인지 정확하게 알지 못했다. 나름 메서드 명과 변수명, 메서드 분리 등 신경써서 한다고 했지만.. 전혀 신경쓰지 않은 듯한 프로그램이었다. (리팩토링 방법을 몰라 그냥 대충 메서드 분리하고 그럴싸하게 보이게 만든 듯한 느낌?)
차장님이 항상 강조하는건 쉽게 생각하라 하신다. 하지만 난 이말이 너무 어렵게 다가온다 .. 경험에서 오는 차이 때문에 내가 보는 시야와 차장님이 보는 시야가 다르기 때문에 내가 생각했을 때의 쉬운것과 차장님이 생각했을 때 쉬운게 서로 다르다고 느낀다. 항상 강조하셔서 모든 프로젝트 할 때마다 어떻게 쉽게 구현할까 라는 생각을 가지고 한다. 결과적으로 내가 느끼기엔 쉽게 생각 하기 위해선
경험과스킬이 뒷 받침 되야 한다.
이번 조직도 프로그램을 개발하면서 리팩토링의 중요성에 대해서 크게 느꼈으며, 기존것을 재사용하는 것도 알고 쓴다면 좋지만, 좀 더 다양한 방법을 생각하며 개발해야겠다라는 마음가짐이 생겼다.
시설물 사용신청 개발
조직도 프로그램이 끝나고 다른 프로그램들을 쳐내면서 시설물 사용 신청(관리자와 사용자) 를 개발하기 까지 텀이 조금 있었다.
이때 집에서 조금씩 마틴 파울러의 리팩토링 1판 을 읽고있었다.
조직도에서 리팩토링의 중요성에 대해서 크게 느꼈기 때문에, 시설물 사용 신청 개발은 내가 만족 할 만한 프로그램을 만들어야 겠다라고 생각했다.
시설물 사용 신청에 있어서 가장 중요한 것은 동시성(Concurrency) 문제를 해결해야 하는 것이었다. 같은 조건(시설물명, 신청일, 신청시간) 에 대해서 동시에 사용자와 관리자가 신청한 경우, 이를 막기 위해서 동시성에 대해 공부를 해야 했으며, 찾아본 결과 시설물에 적용할 방법은 ReentrantLock 과 synchronized 블록을 지정하는 방법으로 추려졌다. 복잡한 동기화 로직의 경우 ReentrantLock 이 효율성이 더 좋지만, 시설물 신청의 경우 단순 동기화 블록만 지정하면 됬기에 synchronized 를 통한 메서드 블록 지정을 선택 했다.
위 링크에 이번 시설물 사용 신청을 개발하면서 쓰인 동기화 블록과 어떻게 로직을 구현했는지에 대해서 아티클을 작성하였다.
조직도가 스스로 만족할만한 프로그램이 아니어서, 시설물 사용신청은 더 신경써서 만들었으며 스스로도 만족할 만한 결과물이 나왔다.
이번 공주대 프로젝트를 진행하면서 스프링 시큐리티, 리팩토링, 디자인 패턴에 대해서 공부해야겠다 라는 목표? 마음가짐? 이 생겼으며, 두 번째 프로젝트까지 경험해서 그런지 개발에 흥미가 더 생긴것 같다.
프로젝트가 성공적으로 끝났는지의 기준
동구청, 조폐공사(중간에 수정사항과 게시판 이관을 도와줬음. 다른 선임 개발자 분들의 프로젝트), 공주대 까지 프로젝트를 진행하면서, 주어진 개발기간, 팀원, 성향 모두 다 달랐으며 이러한 경험을 통해서 프로젝트가 성공적으로 끝났는지에 대해서 판가름 할수 있는 안목이 약간 생겼다.
- 프로젝트가 끝난 후 마음속에 신경 쓰이는 일이 없을 때
- 수정사항 요청이 적게 들어올 때(혹은 큰 프로그램에 대한 큰 수정사항 이 없는 경우)
- 더 이상 프로그램 개발을 추가적으로 하지 않아도 되는 경우(기존에 합의된 내용 이외의 추가 요청은 어쩔 수 없음)
나열하면 더 있겠지만 내가 느끼기엔 크게 세 가지 정도 인것 같다. 나중에 내가 메인으로 프로젝트에 투입되는 경우 공주대 프로젝트 처럼 처음에 힘들더라도 나중에 후련한 마음이 들게끔 프로젝트를 진행 해볼생각이다.
신입 개발자 충원 예정
프로젝트가 끝난 후 반가운 소식 중 하나가 신입 개발자 2명이 충원 될거라는 얘기 였다. 새로운 사람이 들어오는 건 언제나 흥미롭다. 나도 신입이지만, 신입이 들어온다면 개발에 대한 열정 또는 노력하는 모습이 보이면 정말 나 또한 열정적으로 알려주면서 공부하고, 신입에게 배울점도 내가 배우고, 신입과 내가 더 나은 방향으로 성장해서 회사에 보탬이 되고싶다.
회고
이제 (만) 1년차가 되기까지 3개월이 남았다. 회사 입사일이 정말 어제 같은데 시간이 너무 빠르게 느껴진다. 앞으로도 더 새로운 경험을 많이 하고 싶다. 회사에서 나의 노력과 성과를 좋게 봐주셔서 감사하지만, 난 아직 한참 부족한것 같다. 번 아웃이 오지 않게 꾸준히 해야겠다.
