현대자동차 소프티어 부트캠프 3기 교육이 시작된 지 2주 정도의 시간이 지났습니다.
소프티어 OT를 기다리던 날이 엊그제 같은데 벌써 2주라니...
2주 동안 해가 바뀌며 저의 생일이 있었고 소프티어 교육에서는 3번의 조편성과 한 번의 프로젝트, 디자인과 기획 그리고 GA에 대한 교육이 있었습니다.
앞으로 남은 교육 또한 빠르게 지나갈 거라는 생각이 들어 새삼 밀도 높은 시간을 보내야 할 것 같다는 생각이 들었습니다. 남은 시간 후회 없이 보내고자 다음 교육 시작 전에 지금까지의 기간을 회고하고자 합니다.
회고 전에 앞서
제가 소프티어 부트캠프를 신청할 당시 제가 정한 목표는 "좋은 사람들을 많이 만나 많은걸 배우자"입니다.
물론 취업 연계를 통한 현대자동차 입사가 가장 중요하고 이루고 싶은 목표이고 이를 위해 열심히 공부할 것입니다. 두 번째 목표를 위와 같이 정한 이유는 보다 가까운 목표이고 외부 변수보다는 저의 태도와 능력으로 달성률이 결정되는 목표이기 때문입니다. 또한 현대자동차에 입사하더라도 혹은 입사하지 못하더라도 좋은 사람들을 많이 만나는 것은 앞으로 많은 도움이 될 것이라 생각합니다.
현재까지 아래와 같은 일정으로 교육이 진행됐습니다. 시간 순서대로 회고를 작성할 것이지만 아무래도 가장 많은 시간을 보내고 기억에 많이 남는 워밍업 프로젝트(이하 소프티5)의 회고가 길어질 것 같아 GA강의와 소프티5의 순서를 바꿔 소프티5 회고를 마지막에 작성하겠습니다.
- 1일 차: 전체 OT
- 소프티어 부트캠프가 어떻게 운영될 것인지에 대한 전체 OT입니다.
- 2일 차: 각 직무별 OT
- BE 직무의 경우 간단한 프로그램을 페어 프로그래밍으로 진행했습니다.
- 3, 4일 차: 직무 별 강의
- 전체를 대상으로 각 직무에 대한 이해를 위한 강의가 진행됐습니다.
- 5 ~ 9일 차: 워밍업 프로젝트 소프티5
- 기획, 디자인, 개발(BE, FE 혹은 BE, 안드로이드) 모든 직무로 구성된 팀으로 5일 동안 하나의 프로젝트를 진행했습니다.
- 10, 11일 차: 워밍업 프로젝트 회고, GA강의
1, 2일 차: 전체 OT와 각 직무별 OT (BE) 회고
1일 차 전체 OT에서는 소프티어 부트캠프 운영에 대한 OT가 진행되었고 1기, 2기와는 어떻게 다른지 설명 들었습니다. 부트캠프가 처음인 저에게는 부트캠프가 어떻게 진행되는지, 어떤 기업들이 어떤 부분을 맡아 이 부트캠프가 구성되는지 알게 된 날이었습니다.
점심 먹을 때 친해질 겸 직무 별로 조를 짜주셨는데 첫날 같이 밥 먹은 분들과 친해져 슬랙으로 개인 DM도 하고 집도 같이 가며 쭉 친하게 지내고 있습니다. (친구 +3 = 3)
2일 차 BE 직무의 직무별 OT에서는 오목, 바카라, 포커 중 하나의 프로그램을 페어 프로그램으로 작성하는 시간을 가졌습니다. 저와 짝이 된 분은 git에 익숙하지 않아 제가 아는 데까지 설명해 드렸습니다. 같이 검색하며 제가 설명한 내용이 맞는지 검증하고 제가 확실하지 않았던 부분과 몰랐던 부분에 대해 알 수 있었습니다.
또 `페어 프로그래밍`을 처음 경험해 봤습니다. 페어 프로그래밍을 하며 코딩 방식의 차이에 대해 몸으로 느낄 수 있었습니다. 초반에는 변수명과 함수명, 함수로 분리할 것인 지, 클래스를 따로 만들 것인 지, 이 기능은 어느 클래스에 포함시켜야 하는지에 대해 이야기했고 같은 기능을 구현할 때도 생각한 알고리즘이나 방향 등이 달라 재밌었습니다. 어느 정도 규칙이 생긴 뒤로는 알고리즘 등 내부 구현에 대해 이야기를 많이 했습니다.
git에 대해 공부한 시간 때문인지 원하는 모든 기능을 구현하지 못한 것은 아쉬웠지만 git을 공부했고 다른 사람과 코딩 스타일을 맞춰보는 좋은 경험을 했습니다. (친구 +2 = 5)
- git에 대해 확실하지 않았던 부분:
- rebase와 merge의 차이
- branch와 head, detached head, fast forward
- git에 대해 몰랐던 부분:
- 협업 flow
- pull request의 진행 과정
3, 4일 차: 직무 별 강의(기획, 디자인, FE, BE) 회고
각 직무에 대한 강의를 들었고 굉장히 유익한 시간이었습니다. 모든 직무에서 공통되게 설명한 부분을 뽑자면 애자일 방법론과 직무 간의 소통이었습니다. 소통은 당연히 중요하지만 애자일 방법론이 대세가 되며 다른 직무의 눈높이에서 본인의 직무를 설명하고 다른 직무를 이해하는 소통이 강조되는 것 같습니다.
- 프로젝트 방식: 폭포수 모델과 애자일
애자일 방법론에 대해 제가 이해한 내용을 바탕으로 정리하고 소통에 대해 정리해보겠습니다.
위 그림이 폭포수 모델과 애자일을 가장 잘 표현한다고 생각되어 발표자료에서 가져왔습니다. 문제 되진 않겠죠...?
먼저 전통적으로 하나의 프로젝트를 진행한다면 `폭포수 모델`을 떠올립니다. 폭포수 모델은 방향성이 있는 방법론입니다. 어떤 서비스를 만들지 정하고 해당 서비스에 필요한 기능 명세를 만든 뒤 각 기능들을 개발하고 마지막에 모든 기능을 종합해 전체 서비스를 완성합니다. 기업의 조직 단위로 생각하기 쉽고 공장의 분업과 같이 내가 맡은 일을 완벽히 수행한다면 다른 부분은 잘 이행되고 있나 확인만 하면 되는 방법론입니다.
하지만 단계별로 진행되어 앞 단계에서 정해진 요구사항에 맞춰 다음 단계를 진행하기 때문에 변화에 유연하지 않습니다. 또 결과물이 마지막에 완성되기 때문에 과정 중에는 결과물을 보고 테스트할 수 없고 마지막에 합치는 과정에서 문제가 생긴다면 개발 초기에 문제를 발견한 경우보다 비용이 큽니다.
요즘에는 빠르게 변화하는 기술에 유연하지 못한 폭포수 모델 대신 `애자일` 방법론이 많이 사용되는 것 같습니다. 애자일은 중요한 기능에서 시작해 완성된 서비스를 만든 뒤 기능을 추가하는 방법론입니다. 위 그림과 같은 하나의 사이클(스프린트)을 기능 단위로 여러 개 이어 붙여 서비스의 크기를 키워 나갑니다. 애자일은 개발과 테스트를 이어서 진행할 수 있고 피드백을 바로 적용하여 유연하게 대응할 수 있습니다.
앞으로 소프티어에서 진행하게 될 프로젝트도 정해진 기간 동안 폭포수 모델의 초기에 정한 모든 기능을 구현하지 못할 가능성이 높으니 애자일로 진행하려 합니다.
- 직무 간 소통
애자일로 프로젝트를 진행하면 직무 간 소통이 폭포수 모델에 비해 자주, 디테일하게 이루어질 것입니다. 이때 상대방이 모르는 전문 용어를 사용하는 것보다는 풀어 설명하고 상대방 직무에 대한 기본 적인 지식이 있다면 소통이 원활할 것입니다.
이번 강의 중 개발 용어를 디자인과 기획 직무에게 설명하는 시간이 있었습니다. 설명 과정에서 해당 기술을 왜 사용하고 사용하지 않으면 어떻게 되는 지를 포함한 기술의 핵심을 요약해 설명하는 것이 빠르고 정확하게 설명하는 방법 중 하나라는 생각을 하게 됐습니다.
또 설명하며 제가 정확하게 알고 있지 않다는 것을 확인하게 되었고 설명을 통해 제가 아는 것을 확인하는 것이 중요하다는 것을 다시 느꼈습니다. 더 자주 공부한 내용을 블로그에 정리해야 할 것 같습니다.
10, 11일 차: GA강의 회고
저는 현재 이 블로그에 GA를 적용한 상태입니다. 예전에 구글 광고를 달며 분석도 해보자는 생각에 추가했지만 사용방법을 몰라 방치하고 있었습니다. 마침 따로 시간 내어 공부하기엔 우선순위에서 항상 밀렸던 GA 강의가 있어 재밌게 수강했습니다.
먼저 GA를 배우기 전에 데이터 분석에 대한 수업을 해주셨는데 페이지에서 어떤 데이터를 남겨야 하는지, 데이터에는 어떤 종류가 있으며 각 종류(page, event, state)는 어떤 정보를 담아야 하는지에 대해 배울 수 있었습니다.
GA강의에서는 앞서 배운 데이터를 GA를 이용해 분석하는 방법을 배웠습니다. 사실 내용이 너무 많고 처음 보는 용어가 많이 등장해 중간중간 길을 잃었지만 실습을 통해 다시 정신을 차리게 됐습니다.
무엇보다 사용자 이탈률과 사용자 별 행태 분석이 흥미롭고 와닿았습니다. 실습할 겸 제 블로그에 대해서도 몇 가지 분석을 해봤습니다.
제 블로그는 모바일에서 데스크톱보다 접속이 많지만 데스크톱에서 접속 시간이 더(훨씬) 깁니다. 또 남성이 여성에 비해 두 배정도 많습니다.
5 ~ 9일 차: 워밍업 프로젝트 소프티5 회고
1/4 ~ 1/10 주말 포함 7일 동안 기획, 디자인, FE(2), BE(2) 6명이 한 팀이 되어 프로젝트를 진행했습니다.
다른 개발자와의 협업, 다른 직무와의 협업, spring boot 프레임워크 모두 처음인 저에게는 너무 값진 시간이었습니다.
기획과 디자인 과정에서도 의견을 내고 개발 과정에서 기획, 디자인의 의견을 수용하며 프로젝트 한 부분이 재밌었고 기획 디자인에 대해서도 많이 배웠습니다. 무엇보다 짧은 시간 동안 좋은 사람들과 빠르게 친해질 수 있어서 좋은 시간이었습니다. (친구 +6 = 11)
저의 부족한 점을 많이 발견한 시간이어서 아쉬움이 큽니다.
- Spring boot와 Spring data JPA
저는 Java를 알고리즘 문제를 풀며 공부한 적은 있지만 Java로 프로그램을 제작해 본 것은 처음입니다. 당연히 Spring 프레임워크도 경험이 없었습니다. 그나마 다행이었던 점은 Node 진영의 Spring이라 불리는 Nestjs를 공부하고 사용하며 스프링에서 가져온 개념들을 공부한 적이 있습니다. 덕분에 MVC패턴과 컨트롤러, 서비스, 레포지토리, ORM, 인터셉터, 필터, 어노테이션과 같은 개념을 접한 적이 있고 프로젝트를 진행하며 "이런 거 없나? 분명히 있을 텐데" 하며 찾아가며 진행할 수 있었습니다.
하지만 Spring data JPA의 경우 TypeORM과 비교해 훨씬 추상화되어 있었습니다. 함수의 바디가 없고 인터페이스의 이름만으로도 커스텀이 가능했고 어노테이션도 많은 기능을 제공했습니다.
또 배포과정에서 Node 진영과 다른 부분 때문에 헤맸습니다. Node 진영의 경우 JS는 인터프리터 언어이기 때문에 클라우드 서버에 JS런타임과 소스코드를 다운받아 개발환경과 거의 같은 환경에서 서버 애플리케이션을 실행하면 됐지만 Java의 경우 JRE와 빌드된 파일만 필요하기에 더 간단하다고 생각한 게 화근이었습니다. 헤맨 부분은 환경변수들도 같이 빌드가 되는지 혹은 빌드 결과에는 환경변수 파일의 경로만 포함되는지, 빌드 파일은 FTP 프로토콜로 로컬에서 클라우드로 넘겨줘야 하는지 배포 자동화는 어떻게 하는지 몰라 헤맸습니다.
Spring 프레임워크에 대해 더 공부해야 할 것 같습니다.
- 애자일과 배포 자동화
개발을 애자일 하게 진행하려 했으나 하다 보니 완벽한 폭포수 모델이 됐습니다. 기능 명세를 거의 다 작성한 후 개발을 시작했고 개발 과정도 FE와 BE가 개별적으로 진행했습니다. 기능 명세에 따라 FE와 협의를 통해 필요한 API end-point와 요청, 응답 형식을 먼저 정의하고 FE와 BE가 개별적으로 개발한 후 마지막에 연결해 서비스를 완성했습니다. 그렇다 보니 연결 과정에서 많은 문제가 발견되었고 발표 날까지 수정했습니다.
프로젝트 시작 부분에서 배포 자동화 파이프라인을 구축하고 기능 단위로 배포했다면 더 좋은 결과가 있지 않았을까 하는 아쉬움이 큽니다.
- 깃허브를 통한 협업
프로젝트를 시작하기 전 협업 flow를 정했습니다. github flow와 커밋 컨벤션을 정했고 기능 개발부터 pull request까지 git 커맨드를 순서대로 정리해 공유했습니다. 하지만 짧은 시간 동안 익숙하지 않은 툴을 사용하다 보니 버전관리에 문제가 생겼고 이를 해결하는데도 시간이 소모됐습니다. 후반에는 코드 리뷰 없는 pull request가 진행되었고 사실상 github flow가 의미 없어졌습니다.
이를 통해 pull request를 적극적으로 활용하는 방법과 협업에서 원격 저장소와 로컬 저장소에서 동기화 문제 등을 배울 수 있었습니다.
지금까지 종합 회고
"좋은 사람들을 많이 만나 많은걸 배우자"
지금까지는 목표 달성에 가까운 것 같습니다. 하루 동안 임시로 편성된 조에서도 친해져 계속 이야기하고 있고 같이 소프티5에서 프로젝트를 진행했던 `15지조`와는 정말 친한 형동생언니누나가 됐습니다. 오며 가며 마주친 분들과도 이야기하며 알아가는 중입니다. 다음 주부터 직무별 교육이 시작되는데 BE 40명 모두와 이야기해 보는 게 목표입니다.
주말에는 그 주에 공부한 내용 정리와 CS공부를 해볼까 합니다.
'소프티어 부트캠프' 카테고리의 다른 글
[소프티어 부트캠프 3기] BE WAS 프로젝트 회고(1/15 ~ 1/30) (1) | 2024.04.02 |
---|---|
[최종 프로젝트] 예약 시스템 데이터베이스 설계하기 (0) | 2024.03.14 |