Life log/Development log

[Report] 12월 프로젝트 회고

검은 까마귀 2024. 1. 4. 15:31

원래는 프로젝트를 하고 회고를 잘 안했는데

이번에 프로젝트를 마무리 하면서 회고를 작성하려고 한다.

 

회고를 작성하는 이유는 뭘까?

단순히 생각했을때 일기이긴 하지만

내가 나의 잘못을 다시 반성하는 글이라고 생각된다.

 

# 꼬꼬무 공부법

내가 이 프로젝트를 통해 공부법을 얻은거 같다.

컨테이너 환경, 리눅스, 가상환경 등등

이론적인 것들, 머리속에서 추상화 되어있는 것들을

경험하는 방식의 공부 할 수 있었다.

 

 

대부분 CS책들을 보면

"얘는 이렇게 설계 되어있어 이런 점이 유리하다."

이게 끝이다.

 

나는 공부하면서 컴퓨터도 위대한 발명품 중 하나인데

결과랑 사용 방법만 나와있는지 모르겠다.

 

난 항상 why가 궁금하다

"왜 namespace를 만들어서 자원을 격리했을까?"

"컨테이너 오케스트레이션이 왜 필요하지?"

 

LoadBalancer가 왜 필요한가? 라는 질문에

프로젝트 전의 나라면 "부하를 분산하기 위해서 입니다!" 라고 답변했을꺼다.

 

지금의 나는 "scale-out, 즉 수평적 서버 확장을 위해서 필요한 장치로 여러대의 서버에게 부하를 분산하기 위한 장치"

라고 답변할거다.

(적절한 예시인지 아닌지는 모르겠지만ㅠㅠ)

 

 

프로젝트 전의 나는 그냥 LoadBalancer만 안거지

왜 LoadBalancer가 있어야하는지 몰랐던거다.

 

이렇게 꼬리에 꼬리를 무는 질문을 통해

내가 원하는 답을 찾아냈던거 같다.

 

물론 방법은 오래 걸린다.... 이런걸 삽질이라고 하지만

확실히 공부도 하고 이론에 적용해보니 내 머릿속에 잘 들어온거 같다.

 

#퍼블릭 클라우드(AWS)?K8S?

사실 전에 스타트업 업무를 할때 부터 AWS, 클라우드, CI/CD부터

어려운 미션이 주어졌다.

 

일단 해냈고 잘 마무리되었지만,

마음한켠에 잘된건가? 라는 의문을 품었다.

지적 호기심이었다.

(물론 이력서에 이것들을 녹일 수 있을지는 잘 모르겠지만...)

 

 

그래서 퍼블릭 클라우드인 AWS도 레퍼런스를 찾아서 구축해보았다.

(EKS, ELB, AMP, AMG, Cloud Front, S3도 구축해보았다.)

 

이런 AWS 서비스를 바탕으로 구현해보니

로컬에서 구축해보는것이 중요하다!

 

서비스를 이용하기전 직접 구축해보고 왜 이렇게 되는지 알아야지

퍼블릭 클라우드로 넘어왔을때

동작 방식에 대해서 이해가 가능했다.

 

나는 구름톤 트레이닝중에

온프레미스로 구축한 경험이 있기때문에

EKS의 편리성을 확실히 느꼈다.

 

불편함을 경험하고 편안함을 경험하는 것과

불편함을 경험하지 못하고 편안함을 경험하는 것은

경험의 퀄리티에 있어서 큰 차이를 갖게 되는것 같다.

 

EKS 여러 기능들을 효율적으로 운용해보지 못한 점들은 아쉽다.

(새로 추가된 Karpenter 써보고 싶었지만.... 나중에 꼭 회사가면 써봐야징)

 

사실 신입을 준비하는 취준생에게는

이렇게까지 쿠버네티스랑 AWS의 서비스을 내세우지 않아도 되지않을까 싶다...

(현업에서 일하는 분들에게 비벼질 수 있다.)

기본에 충실하면 뭐든 맡겨도 잘 할수 있을거같다.

 

#MSA 구조

현재 가장 많은 주목을 받고 있는 설계중 하나이다.

나 또한 이 흐림에 올라타고 싶었고

토이프로젝트 겸 5명의 팀으로 구성되어있어

괜찮을거 같다고 생각했다.

 

사실 준비하는 과정에서 그렇게 어렵지 않았다.

이미 짜여진 코드를 레포별로 찢는 작업이기때문에

기존의 백엔드 개발이 있던 분들이라 금방 나눴다.

 

아쉬웠던 점은,

인증/인가를 api gateway쪽에서 부터 시작하여

뒷단 서비스까지 가야했지만

 

api gateway하시는 분이 상당히 애를 먹은 것 같다.

(그때 나는 로그를 수집하는 Promethus, Grafadana 작업중)

 

 

아쉽게 프로젝트 막바지가 와서 그런 상황이였기때문에

대응을 제대로 하지 못했다ㅠㅠ

 

또 하나는, MSA의 장점을 살리지 못한거 같아서

개인적으로 아쉬웠다.

 

개인적으로 MSA 장점은 장애가 나지 않게

서비스의 의존도를 분리하는 것도 있지만

 

최고의 장점은 다양한 프레임워크와 언어의 확장에 있어서

자유로워질 수 있다고 생각한다.

하지만, 모든 팀원 분들이 java개발자를 희망하고 있어

spring 프레임웍으로 모든 작업을 진행했다.

 

뭐 이렇게 MSA 구축하면서 많은 리서치를 찾아보았는데

 모놀로식 서비스가 더 좋다고 말하는 Stackoverflow의 글도 있었다.

https://stackoverflow.blog/2020/11/23/the-macro-problem-with-microservices/

 

The macro problem with microservices - Stack Overflow

November 23, 2020The macro problem with microservicesIn just 20 years, software engineering has shifted from architecting monoliths with a single database and centralized state to microservices where everything is distributed across multiple containers, se

stackoverflow.blog

 

이렇게 관련 자료를 리서치하면서

"MSA 좋아!"를 무지성으로 외치던 나에게 "어쩌면 안좋을지도?"

비판적인 시선을 갖게 되었다.

 

 

한 가지를 잃으면 한 가지를 얻는 Trade-off 처럼

기술에도 양면이 있다.

항상 뭔가를 선택할때 이런 고민이 필요할거 같다.

내가 얻는것 말고 잃을 수 있는 것은 무엇인가에 대한 고민

 

#소프트스킬

사실 프로젝트를 언제든지 구할 수 있었는데

전에 있던 회사에서 사람들한테 치였다고 해야하나....

 

인간관계는 누군가의 잘못이 1:100으로 이루어진 경우는

많지 않기 때문에 나 역시도 의사소통 스킬에 문제가 있었지 않나 싶다

 

 

그래서 퇴사하고도 같이 개발은 하고싶은데

팀원을 구하기가 무서웠다

같이 하는 팀원들이 항상 나에게 무언가를 요구해올까 무섭고

나와 의사소통이 되지 않을까 무서웠다

하지만, 어쨌든 돌파구가 필요했고 돌파해야했다.

 

그래서 여러 책도 읽어보고

말을 어떻게 이쁘게 해야하나

나름의 고민의 시간을 가졌고

프로젝트에서 어떻게해야하나를 고민했다.

 

 

- 팀원에게 싫은 소리가 하기 싫다.

- 안되는 일로 짜증내고 싶지 않다.

- 모두의 능력에 맞춰 업무 분장을 해주고싶다.

- 소외되는 인원 없이 프로젝트에서 모두가 성장하면 좋겠다.

 

프로젝트가 끝나고 솔직한 피드백 없이

끝나서 팀원들의 마음은 잘 모르겠지만

과반 이상은 만족했다.

 

어떤 누가 남한테 싫은 소리를 하고 싶을까?

이걸 방지하기 위해 작업이 원할히 진행되기 위해

 

전에 포스팅했던 프로젝트 문서관리 법을 통해 포스팅한 내용으로 의사소통을 진행했다.

사실 뭐... 100% 문서화가 잘 진행되지 않았지만

그래도 꾸준히 회의록도 작성하고 slack에도 공지하며 진행했다.

(WBS 빼고.... 작업 내용이 사람마다 작업이 변동되서)

2023.11.20 - [Life log/Development log] - [Report] 프로젝트에서 문서 관리법!

 

[Report] 프로젝트에서 문서 관리법!

회사를 다니면서 인프라쪽 관련해서 프로젝트를 할 수 있는 기회가 생겨서 참여를 하게되었습니다. 토이프로젝트가 처음은 아니지만 그래도 회사에서 기획도 잠깐하고 개발도 잠깐했던 사람으

blaj2938.tistory.com

 

안되는 일로 짜증내는건 사실 개인적인 능력의 부족이기 때문에

남들이 다 해두라고 한걸 못한건 나의 잘못이다

밤새우면 해결된다ㅋㅋㅋㅋㅋ

 

 

취준을 하고 있고 면접을 보고 학교기말고사를 치는 팀원분들이 있어서

업무 분장에 꽤나 고려해야될게 많았다.

 

어느정도 러닝커브가 있고 경력있는 분들에게 어려운 작업을 맡기고

스프링이 처음이거나 기말고사로 개인적인 이슈가 있는 분들에게는

쉬운 작업을 맡겼다.

( 내 기준.... 그분들한테는 쉽지 않았을 수도 있다)

 

그리고 1달의 시간동안 끝내야 했기에

작업에 이슈가 생기는 언제든 질문을 하면 아는 선에서 답변을 드렸다.

(물론, 해주지는 않고 키워드만 던졌다)

 

모두가 성장하는건.....

사실 본인이 어떤 성장인지 정의하기 때문에 모른다.

 

누군가는 포트폴리오가 필요했을꺼고

누군가는 AWS와 쿠버네티스를 공부하고 싶었을 것이다.

(난 후자인 면에서 성장했다고 생각한다.)


 

물론 누군가는 힘들었다고 말할 수 있지만

내가 원하는 것을 만들기 위해 끝까지 부여잡고 있는 시간은 소중했고

개발하는 시간보다 인프라를 고민을 하는 시간이 더 길었다.

 

1달의 시간이 꽤 괜찮았던거 같다

개발자들이 토이프로젝트를 꾸준히 하는 이유가

바로 여기에 있지 않을까 싶다.

 

그리고 프로젝트를 마치면서 go lang을 배워보고 싶다는 생각이 들었다.

자바만 하니깐 너무 재미가 없다.

지루해... 자바... 올해가 가기전에 언어 폭도 늘리는걸로...

반응형