데브코스 수료!! 마지막 회고록

설렘과 걱정의 마음으로 시작했던 프로그래머스 백엔드 Devcourse 과정이 5개월이 지나 막을 내렸다. 5개월 동안 교육을 받으면서 개발, 협업 등 많은 것을 학습해왔다. 그럼 5개월 전의 나는 어떤 사람이었고 데브코스 과정을 듣는 5개월 동안 어떻게 성장했는지 기록해보자. 전체적으로 적긴 했지만 그래도 최종 프로젝트 끝난 뒤의 회고록이어서 최종 프로젝트 위주로 작성해보았다.

데브코스 시작 전의 나

나는 원래 노는 것을 좋아했던 대학생이었다. 탁구에 빠져서 휴학하고 6개월 동안 오로지 탁구만 친 적도 있었고, 1년 동안 워킹홀리데이로 호주도 다녀왔었다. 놀면서 공부도 같이 했으면 좋았으려 만 안타깝게도 공부도 잘 안 했었다.

 

4학년이 돼서야 부랴부랴 ‘뭘 해야 할까?’ 고민하다가 ‘안정적인 직업이 좋지 않을까?’란 생각에 공기업 준비를 시작한다. 그렇게 열 달 동안 한국사, 정보처리 기사 취득하고 토익 시험 보고 NCS 공부를 하면서 지냈다.

 

그렇게 공부를 하다가 공기업에 취업한 선배와의 만남 이후 깊은 고민에 빠지게 되었다.

‘나한테는 안정적인 것만이 정답이 아니구나.’

‘그래도 개발할 때는 어렵긴 해도 즐거웠는데...’

전산직이긴 하지만 개발도 거의 안 하고 IT 관련 사무직만 하고 정해진 틀에 맞춰 일을 평생 하는 것은 적성에 안 맞는다고 생각했다.

 

결국, 공기업 준비를 접고 개발자가 되기로 결정했다. 하지만, 개발자가 되기 위해 자소서도 쓰고, 포트폴리오도 만들어보려 해도 개발자가 되기 위해 해온 경험들이 없었다. 당연히 모든 입사지원이 서류에서 탈락을 했고, 그러던 와중에 프로그래머스 백엔드 데브코스를 모집 공고를 보고 지원을 했다. 그때 당시에 벼랑 끝이었기 때문에 데브코스에 올인하기로 결심했다.

 

이후, 정말 다행히도 면접에 합격하여 데브코스 프로그램에 참여하게 되었다.

첫 번째 팀

데브코스 과정이 시작됐다. 처음 만나는 6명의 교육생들과 1명의 멘토가 팀을 이뤘다. 초기 커리큘럼은 자바, 데이터베이스와 스프링에 관한 내용이었다. 여기까지는 대학 생활을 하면서 공부했던 내용이라 크게 어려움 점은 없었다. 강의 외에 가장 얻은 게 많았던 블로그 포스팅에 대해 정리해보자.

 

 

블로그 포스팅

 

데브코스 1주 차 회고록을 시작으로 블로그 운영을 시작했다. 처음엔 회고록만 작성할 생각이었지만 시간이 지나면서 독후감이나 개발 공부에 대한 글도 추가되었다. 블로그를 운영한다는 것이 처음엔 부정적이었다. 글을 작성하는 데 시간도 오래 걸리고 나의 글을 다른 사람에게도 공개해야 한다는 민망함 때문이다.

 

하지만, 막상 시작해보니 개인적으로 얻는 것이 훨씬 많았다. 그중에서도 가장 큰 장점은 내 생각을 정리할 수 있다는 점이다. 이전까지의 나는 문제를 해결하거나 프로젝트가 끝났을 때 정리를 한 적이 없었다. 문제 상황은 뭐였고 어떻게 해결했는지, 프로젝트에선 뭐가 나빴고 좋았는지 등 정리할 것들이 넘쳐나는데 말이다.

 

구체적으로 글을 썼을 때 뭐가 달라졌을까?

먼저 문제 상황에 대해 글을 쓴다면, 기본 구조는 다음과 같다. 문제가 발생한 상황, 원인, 해결방법. 이런 구조 덕분에 단순히 해결한 것에서 그치지 않고 문제가 왜 발생했고, 어떻게 해결해야 하고 왜 그렇게 해결해야 했는지 생각을 정리하고 내 것으로 만들 수 있었다.

 

프로젝트도 마찬가지다. 프로젝트를 하면서 뭐가 좋았는지, 뭐는 안 좋았는지, 팀 문화 또는 팀원들에 대한 피드백 등을 남겼다. 그러면 이번 회고에서 나온 부분을 반영해서 다음 프로젝트를 할 때는 더 개선된 형태로 진행할 수 있다.

두 번째 팀

두 번째 팀을 하는 동안에는 새로운 걸 시도하지는 않았다. 이때부터, 교육과정이 JPA, Spring Security, DevOps 등등 너무 어려워져서 강의를 따라가기만 해도 너무 바빴다. 그래서 시간의 대부분을 강의를 여러 번 듣고, 그중에서 이해를 안 갔거나 더 깊게 알고 싶은 부분을 포스팅하면서 보냈다.

 

그리고 드디어 첫 프로젝트를 시작했다. 지금까지 프로젝트를 할 때는 대부분 정해진 틀 없이 주먹구구 식으로 진행을 했었다. 그래서 이번에는 진짜 개발자가 된 것처럼 협업 프로세스를 경험해보고자 하였다.

팀 프로젝트에 대한 내용은 다음 회고록으로 대신한다. 중간 팀 프로젝트 회고록

최종 프로젝트

대망의 최종 프로젝트가 다가왔다. 나는 이력서에 쓸 마땅한 프로젝트가 없었기에 이 최종 프로젝트가 데브코스를 지원했던 가장 큰 이유였다. 이전 프로젝트와 다르게 이번에는 백엔드 3명, 프론트엔드 3명과 팀을 이루어서 진행하게 되었다. 그럼 프로젝트 기간 동안 느꼈던 일들을 정리해보자.

 

목표 달성 여부

 

목표까지 얼마나 달성했는가?라고 물어보면 대략 70% 정도는 이룬 것 같다. 왜 70%까지 달성했다고 생각했는지 그리고 나머지 30%는 왜 달성하지 못했는지 정리해보자.

70% 목표 달성이라고 생각한 이유는 다음과 같다.

 

• 우선 목표했던 기능의 우선순위 Must Have와 Should Have 기능은 대부분 구현했다.
• 구현하는 과정에서 Spring MVC 구조와 JPA를 적절히 활용하였다.
• 동적인 쿼리 작성을 위해서 QueryDSL이라는 새로운 기술도 접해봤다.
• 파일로 로그를 관리하여 배포 서버에서 발생한 에러도 확인해보았다.

그럼 목표 달성에서 30%가 미달인 이유는 무엇일까?

 

• 테스트 코드를 거의 작성하지 못했다 - 마감 기한까지 서비스가 돌아가게끔 하는 게 1순위라 생각하고 테스트 코드 작성을 소홀히 했다.
• 객체 지향을 잘 지키지 못했다 - 엔티티가 다른 엔티티를 생성하거나 다른 VO를 생성하는 코드가 있다.
• 이미지 파일 관련 작업을 시도해보지 못했다 - 프로필 이미지라든가 게시글을 공유할 때 자신이 여행 가서 찍은 사진들도 공유할 수 있게 이미지 기능을 구현하지 못한 것이 아쉽다.
• 시큐리티 부분이 엉성하다 - 로그아웃, 토큰 만료 기간, 보호받는 리소스 설정, 유저 권한 설정 등 리팩토링해야 할 부분이 엄청 많다.

프론트와의 첫 협업. 의사소통의 중요성

 

개발하면서 정말 의사소통을 자주 그리고 꼼꼼히 해야겠구나를 느꼈다. 프론트와는 API를 통해 요청과 응답을 하는데, 이 부분에서 몇 가지 서로 다르게 이해한 부분들이 있었다.

 

아주 사소한 부분은 숫자의 범위에 대한 부분이 있었다. 전체 여행 일정 안에 첫째 날, 둘째 날 같은 여행 순서가 있었는데 이 부분에서 백엔드는 1부터 시작, 프론트는 0부터 시작했던 이슈가 있었다. 서로의 입장에서는 당연히 상대방도 ‘1부터 했겠지’, ‘0부터 했겠지’라고 생각해서 발생한 이슈였다. API에서 주고받는 데이터를 정할 때는 데이터 명, 타입과 더불어 데이터의 범위 또한 정해야 한다는 것을 깨달았다.

 

팀장의 역할

 

이번 프로젝트는 나의 기획으로 진행하게 되어 자연스럽게 팀장을 맡았다. 처음으로 팀장을 해보았는데 역할도 늘어나고 결정에 따른 책임도 있다 보니 꽤 부담이 컸다. 그럼 팀장을 하면서 어려웠던 두 가지만 정리해보자.

 

먼저, 일정 산정의 어려움이다. 이 프로젝트는 12월 21일까지 발표 자료와 영상 제출이라는 명확한 데드라인이 있었다. 따라서, 역순으로 자료는 만드는 데 며칠, 그렇다면 도메인 별로 개발하는 데 며칠이 걸릴지 계산을 해야 했다.

 

하지만, 개발 경험이 별로 없었기 때문에 지금 우리가 하고 있는 이 프로젝트가 4주라는 시간 안에 할 수 있는 규모인지도 파악하기 어려웠다. 세부적으로는 도메인 별로 서비스 요구사항 별로 자신이 며칠 만에 구현할 수 있는지 판단을 해야 하는데 그것이 꽤나 어려웠다. 처음엔 그냥 대충 잡아도 되지 않을까?라고 생각했었지만 당연히 말도 안 되는 소리였다. 예를 들어, 소요 시간을 2일로 잡았는데 예상치 못한 에러를 만나서 3~4일이 걸리면 전체 일정에 차질이 생기게 되고, 그렇다고 4일로 넉넉하게 잡으면 다른 요구사항들을 축소시켜야 했기 때문이다.

 

이 문제를 해결하기 위해 우리 팀은 MoSCoW 기법을 통해서 우선순위를 나누기로 했다. 기준은 다음과 같았다.

 

1. Must have : 에러까지 고려하여 일정을 넉넉하게 잡아서 반드시 구현해야 하는 기능
2. Should have : 적절하게 일정을 잡았을 때 웬만하면 구현해야 하는 기능
3. Could have : 있어도 좋겠지만 꼭 있어야 할 필요는 없는 기능
4. Won’t have : 당장 이번 프로젝트 기간 동안에 구현하지 않고 추후로 미뤄도 되는 기능

각 서비스 기능들에 우선순위를 정하고 나니 프로젝트 여정의 윤곽을 잡을 수 있어서 많은 도움이 되었다. 물론 이어서 나오는 다음 문제 때문에 큰 애로사항이 있었지만...

 

두 번째 문제는 의지가 없는 팀원을 어떻게 끌고 갔어야 했는지에 대한 것이다. 그 팀원이 기여한 부분을 말하자면 프로젝트 4주 기간 동안 Security도 적용하지 않은 User도메인 CURD만 작성하고 끝냈다. 그 팀원은 데브코스를 하기 전에 게임 개발자로 일을 했었는데, 데브코스 과정이 끝나면 다시 게임 개발자를 하러 갈 것이라 했다. 그래서 오프라인에서 모이는 날에도 팀원들한테 지금 만들고 있는 게임을 자랑을 하기도 했다...

 

여기서 딜레마가 생겼다. 나는 팀장으로서 프로젝트를 성공적으로 이끌어야 할 책임이 있었지만 그 팀원은 이미 백엔드에선 마음이 떠난 상태였다. 더군다나 팀 프로젝트 마감일 다음 주까지 게임 관련 포트폴리오를 제출해야 한다고 했다. 만약, 이 팀이 회사였다면 나는 당연히 강하게 제지하고 쓴소리를 했을 것이다. 근데 같은 취준생 입장에서 결국은 쓴소리를 못 했다. 결국은 모두 다 취업을 하기 위해 발버둥 치는 것인데, 그 팀원 입장에서 취업에 도움되지 않는 일을 강요할 수 없었다.

 

결국은 그 팀원 대신에 나와 다른 백엔드 팀원 한 명의 시간을 갈아 넣어 프로젝트를 마치긴 했다. 하지만, 프로젝트가 끝난 뒤에도 ‘나만 참는다고 되는 게 아닌데 다른 팀원들을 위해서라도 쓴소리를 했어야 했나?’, ‘프로젝트를 무사히 마쳐서 다행이지. 만약 프로젝트 마무리가 아쉬웠다면 쓴소리를 안 했던 내 잘못이겠지?’ 이런 생각이 계속 들었다. 개발하는 것보다 팀장으로서 팀의 방향을 정하고 이끄는 게 더 어려웠다...

 

일정 공유

 

위에서 개발의 우선순위와 그에 따른 예상 일정을 계획했었다. 하지만, 매일 진행하는 스크럼에서는 자신의 개발 진행 상황 및 계획을 명확하게 공유하지 못했는데 이 문제가 전체 일정에 악영향을 끼쳤다.

 

이 문제는 프로젝트 중간에는 고치지 못했고, 마무리 후 회고 시간에 나온 것인데 모두가 공감했다. 그래서 구체적으로 어떻게 일정을 공유했어야 했는지 다 같이 정리해보았다.

 

• 현재 스프린트의 목표는 무엇인지
• 이를 위해 무엇을 구현해야 하는지
• 현재까지 완료된 것들은 무엇인지
• 지금은 무엇을 하고 있는지
• 앞으로 무엇을 할 예정인지

위와 같이 팀 차원의 목표를 정하고 자신의 상황이 어떤지 명확하게 공유해야 일정 조절이 필요할 경우 빠르게 대응할 수 있을 거란 결론이 나왔다. 가뜩이나 비대면으로 진행하기 때문에 이러한 일정 공유는 정말 필수적이라 생각한다.

 

규칙

 

규칙 부분에서도 아쉬운 점들이 있었다. 바로 코드 컨벤션 규칙과 코드 리뷰 규칙이다.

 

이번 프로젝트는 코드 컨벤션 제약이 굉장히 느슨한 상태로 자유롭게 개발했다. 처음부터 컨벤션 없이 진행할 생각은 아니었다. 개발을 시작하기 전에는 아직 코드 작성도 안 했는데 무엇을 정해야 할지 몰라서 코드 리뷰를 하면서 컨벤션을 정하기로 했다.

 

하지만, 문제는 명확하게 어떤 걸 코드 컨벤션 규칙으로 정해야 할지 몰랐다는 것이다. 예를 들어, 누구는 롬복을 사용하고 누구는 롬복을 사용 안 했다. 리뷰 당시에는 ‘이건 각자 개발하는 취향 아닐까?’란 생각으로 넘어갔다. 그런데 이런 사소한 것들이 쌓이고 쌓이다 보니 나중에는 각자 맡은 도메인의 코드 스타일이 너무나 달랐다. 결국은 그 당시에는 개발 기한을 맞춰야 했기 때문에 코드 컨벤션은 리팩토링 이슈로 남겨놓고 넘어갔다.

 

지금 당장은 서비스 규모가 작고 다들 본인이 작성했던 코드기 때문에 문제가 없지만, 미래를 생각하면 코드 컨벤션 규칙은 무조건 정해야 한다고 느꼈다. 회사라고 생각한다면, 개발을 했던 사람이 퇴사를 하고 새로운 개발자가 맡을 수가 있다. 또, 서비스 규모가 커져서 엄청 여러 개의 클래스들을 만들어야 할 수도 있다. 이런 경우에 클래스마다 코드 작성 스타일이 다르다면 코드를 이해하고 유지보수하는 데 엄청난 비용이 들 것이다. 미래의 팀을 생각한다면 지나친 자유는 좋지 않다고 생각하고, 코드는 무조건 A 사람이 작성하든 B 사람이 작성하든 같은 스타일로 작성할 수 있도록 코드 컨벤션을 정하는 것이 좋을 것 같다.

 

두 번째로 코드 리뷰의 명확한 규칙을 정하지 않았었다. 코드 리뷰를 받기 위해 PR을 생성했지만, 무의미한 approve가 많았던 것 같다. 미리 여러 규칙들을 정해놓고 코드리뷰 단계에서 이에 대한 검증과 불필요하거나 잘못된 로직의 유무 등 다양한 문제점과 개선점을 찾아 전달 및 공유하고 전체적인 품질 향상을 했어야 했다. 하지만 실제로는 단순히 “그 PR을 봤다”라는 의미로 전락한 것 같아 조금 아쉬웠다.

마무리. 앞으로의 계획

이력서

 

데브코스 과정은 마무리지만 신입이 되기 위한 준비는 이제 시작이다. 첫 취업 준비로 이력서를 써보았다. 이미 온라인에 참고할 수 있는 개발자 이력서가 많았지만 그걸 나만의 스토리로 만드는 건 쉽지 않았다. 이력서는 면접관들이라는 명확한 타깃과 나를 어필해야 한다는 생각에 짧은 분량을 쓰면서도 너무 고민이 많이 되었다.

 

cs 스터디 시작

 

기술 면접을 위한 cs 스터디도 시작했다. 방식은 실제 면접을 하는 방식으로 한 명이 지원자 역할, 나머지가 면접관 역할을 하며 정해진 주제에 대해 답변하는 형식으로 정했다.

 

리팩토링

 

최종 프로젝트의 리팩토링도 계속할 생각이다. 테스트 코드도 그렇고 객체지향 관점의 개발에서 리팩토링을 하고 새로운 기능도 추가해보고 싶다. 프로젝트 마지막 날에 팀원들이랑 모여서 자체 QA를 진행해서 여러 가지 문제를 찾았었는데 그거 먼저 해결해야겠다.

 

그럼 마지막으로... 신입 개발자로 취업하게 해 주세요!!!!!!!!!!!!!!!!!!!!!!!!!