소마 마지막 스프린트. 그리고 회고(리뷰는 나중에)

끝!

소마 프로젝트 과정이 끝났다. 결론적으로 우리는 많은 것들을 짧은 시간 안에 만들어 냈다.

1. 데이터 파이프라인(Kafka Event Driven Architecture)

2. github Api Data 수집기

3. 알람 서버

4. 웹 서버

 

많은 일들이 있었고 이를 행하기 위해서 여러 노력을 했다.

나의 경우엔 CI/CD가 정말 문제였다. Window, Linux가 뒤섞인 배포 환경에 언어까지 JAVA(MVN, Gradle),JS(Nodejs), Python이 뒤 섞인 프로젝트이다 보니 파이프라인 하나를 짜는 것이 모두 새로운 일이 되어 버렸다.

특히 그 안에서 .yml, .json 등으로 만들어진 보안 정보를 대치하고 집어넣는 일이라는 것이 쉬운 일은 아니었다.

 

그럼에도 아쉬움이 남는 것은 TBD 환경 등을 통해 테스트 환경을 꾸렸어야 하지 않았나? 라는 생각과

Azure 를 쓰더라도 WebApp같은 구린거 쓰지 말고 VM으로 확실하게 배포해서 처리하는 것이 낫지 않았나? 라는 생각이다.

전반적인 프로젝트 진행에 있어서 아쉬운 것은 많지만 내 입장에서 아쉬운 것이 무엇이냐 하면 이런 것이리라.(AWS 쓸걸 그랬다. 쩝...)

그렇다.

 

아무튼 뭐 아쉽긴 해도 프로젝트 개발도 완료했고. 더 이상의 개발은 없다. 라고 못 박았기 때문에 진행은 안 할 것이다. 아쉽다. 아키텍처를 더 공부해야겠다. 라는 생각을 하게 되는 요즘이다.

 

얻은 것에 대한 이야기

1. BigData Architecture

그렇다. 난 사실 빅데이터가 뭔지, 어떻게 처리해야할지 전혀 알지 못하는 무지랭이 바보 똥멍청이었다.

MlOps라던가.... Data Engineering 이라는 이야기를 들을 때 마다 어 그거 그냥 NoSQL에다 때려박고 시작하는거 아녀? 라는 바보 같은 생각을 하곤 했었다.

이런 바보 같은 생각을 가진 채로 실제로 많은 데이터가 들어온다는 '가정' 하에 프로젝트를 진행하려다 보니 많은 문제점에 봉착했다.

 

와 Event Driven이라고! 데이터 수집은 어떻게 할건데?

 - Node로 받으면 되지~(그 노드는 얼마나 늘릴 수 있는데???)

 - 아잇! 그럼 Spring~(와 쓰레드가 몇개여, 어디까지 처리할 수 있어??)

 - 엄.... 그럼 K8S?(와 돈이 썩어나나보다. 데이터 수집에 그 돈을 태울 자신이 있다고? 약간 배보다 배꼽이 클텐데?) 

 - 라는 의식의 흐름이 계속되었고, Serverless Function에 대한 이해와 응용이 필요한 시점임을 그때서야 깨달았다. Serverless Function에 대한 이야기는 추후에 계속할 예정이다.

 

데이터를 얼마나 빨리 사용자에게 보여줄거야?

 - 음... 들어오자마자 바로 처리하면 되지 않을까?

 - 그럼 데이터가 충분치 않다면 그냥 확인만 하고 끝내는거야? 

 - 데이터가 Realtime으로 들어오게 된다면 DB가 터지지 않을까?

 - Batch에 대한 고민은 했어?

 - Near Realtime으로 가는 것이 훨씬 좋은 것 같아. Kafka의 도입도 생각해 봐야하지 않아?

 

오 Kafka~ 데이터 Duplication 났다! 어쩔거야??

 - 오... DB에서 Unique 걸면 일단 되지 않을까?

 - 그럼 그 전의 데이터들은 유일성이 보장되지 않는거네? DB에 돈 많이 쓰나봐?

 - 오... Redis를 Queue로 사용해야하겠다...

 

ELT를 이렇게 하는 것이 맞을까? 아닌 것 같은데.

 - 일단 데이터를 Load하는 곳과 Transform한 결과가 들어가는 부분이 같아졌어. 비용 문제겠지?

 - OLAP에다가 시계열 데이터를 집어넣은 것이 맞는 선택인지에 대해 생각해봐야해.

 - 결과를 OLAP에다가 집어넣는것은 옳은 선택일까?

 

2. Deployment Pipeline / Operation

처음으로 Serverless Function을 메인으로 사용했고, 서버까지 Serverless PaaS로 사용하다보니 팀 전체가 협업을 하는 과정에서 Deploy를 하기 힘들어진다. 라는 문제가 발생했다. 

 

모든 것을 자동화 시켜야해.

 - 파이프라인 짜지 뭐. 이번엔 Github Action 사용해서 해보지 뭐

 - Github Action이 어떻게 진행되는지는 알아? Jenkins 사용할 때는 네가 TBD 써서 처리하고 그랬잖아. 근데 여긴 없어. 팀원들도 TBD를 원하진 않아보이네?

 - 와... 응... 그러네... 좀 더 설득을 해볼 걸 그랬어.

 - 와 그래도 만들긴 했네, PR 시에 Build Test도 진행하고, 근데 빌드가 너무 오래 걸리는데? 이야~

 - Cache를 넣어야해...

 

Severless Function에서 발생하는 문제들이 보이지 않아!

 - Runtime에서 문제가 생기는 것 같은데, 콘솔에 들어가기 전까진 에러 메세지가 보이지 않아. 심지어 로그 모듈도 따로 써야하네? 복잡한 Function에서는 이걸 여기저기서 갖다 써야하는데 이게 맞아?

 - 어... Slack으로 메시지를 보내는 객체를 만들게...

 - ㅋㅋ 언어만 세개인데 가능하지?

 

야, 너희 성과를 Private으로만 남겨놓을거야?

 - 아니지?

 - 그럼 레포를 Public으로 돌려.

 - 그렇다고 하기엔 environment Setting이 노출되어선 안되니까...

 - github Action을 써. Repository Secret도 적극적으로 이용하고.

 

3.  Agile

Agile을 해보고 싶었어.

 - Agile이 왜 좋은지에 대해 알아보기 위해서는 써보는 것이 맞다고 생각해.

 - 어떻게 하는지는 알고? 어떻게 쓸건데?

 - 스크럼으로 진행하는 것이 괜찮을 것 같아. 방법은 수업을 통해서 들었어.

 - 진짜 Agile이라는게 뭔지 모르는 상태라면 힘들거야.

 

Scrum의 유지도 힘들다는걸 알아버렸어.

 - 와 학교 다니고 이것저것 하면서 Scrum하니까 세명밖에 안 되는 프로젝트인데 자꾸 안 하게 되네?

 - 뭐 그게 필요충분조건은 아니지만 스크럼도 제대로 안 하면서 스프린트라는 말은 왜 하는거야?

 - 스크럼에서 제대로 된 정보의 교환이 이루어지는 것에는 많은 조건들이 수반된다는 것을 알게 되었어.

 

UserStory에 따라서 일하자.

 - 이것 저것 기획을 진행하고 이걸 쓰기 위해서 코드를 짰어. 이제 합쳐볼 때야.

 - 문제가 생기는구나. 이번 스프린트는 이걸 고치는데 다 쓰지 않을까?

 - 그럼 그 전까지 우리가 보여줄 수 있는 것은 아무것도 없어. 이게 Agile인가? Lean Product의 기본을 잊은 것 같다.

 - User Story에 맞게 하나하나 해결해 나갔다면 구조 자체는 지금 보다 좋지 않을 수 있지만 더 나은 개발을 할 수 있었지 않았을까?

 

4. 좋은 개발자

 좋은 개발자에 대한 생각 

 좋은 개발자란 무엇일까? 라는 생각이 마지막에는 계속해서 들었던 것 같다.

 만나는 멘토님들께 물어봤고 이러한 대답을 얻었지만 아직 잘 모르곘다.

 

 - 자신의 상태를 계속해서 알리고, 이를 통해서 팀에 도움이 되는 사람이 될 수 있는 사람.

  - 스프린트, 업무를 진행함에 있어서 자신의 상태를 알리지 않는 개발자들이 꽤 된다. 그리고 그들은 협업에 있어서 결국 문제를 발생시킨다. 보통 개발자이고, 하루 8시간 개발을 진행한다고 하면. 이상적인 상황에서 개발자는 한명당 하루 3~4개의 티켓을 해결한다. 하지만 자신의 상태를 알리지 않는 개발자들은 문제가 생겼을 경우 이러한 문제들을 '혼자서' 해결하게 되기 때문에 문제가 되는 것이다. 이는 팀의 프로젝트 진행에 있어서 엄청난 낭비이다. '누가' 해결하는 것이 문제가 아니고 '어떻게' 해결했다가 중요하다. '팀'으로 행동했으면 좋겠다.

 

 - 질문을 잘 하는 사람.

  - 이상적으로 좋은 개발자라는 것을 말 하긴 어려운 것 같다. 하지만 여러분이 앞으로 상용 업무를 진행함에 있어서 당부드리고 싶은 말은 '질문을 잘 하는 사람이 되라. 핑프가 혼자서 이상한 결론을 내놓는 주니어보다 훨씬 낫다.' 이다. 같이 일 하는 사람들과 후배들을 볼 때 마다 느끼는 것인데, 질문을 잘 하는 친구들이 같이 일 하기 좋다. 라는 것이 내 생각이다. 물론 핑프가 되지는 않았으면 하지만... 뭐 핑프들이 혼자 머리 싸매고 이상한 짓 하다가 Code Review 요청해서 일 다시하게 하는 사람들보단 나은 것 같다. 계속해서 나은 방향을 물어봐라. 그것이 팀을 위한 길이고 여러분을 위한 길일 것이다.

 

 - 개발을 사랑하는 사람, 개발을 즐기는 사람, 미래를 보는 사람

  - 개발을 좋아하고 좋아하는 사람이 좋은 개발자인것 같다. 개발이라는 것은 정말 힘든 일이다. 이것을 계속해서 할 수 있다는 결국 개발을 좋아하는가, 더 나아가 사랑하는가? 에서 갈리는 것 같다. 물론 업으로 생각하는 사람 또한 있겠으나, 나는 개발을 사랑하는 사람이 좋은 개발자가 되지 않나? 라는 생각이다. 그리고 추가적으로 자신이 쓰는 기술에 매몰되지 않고 미래를 살펴서 나아갈 수 있는 사람이 되어야 한다. 라는 생각도 한다.

 

SOMA KPT

우리는 마지막 스프린트에서 리뷰만 하고 바로 KPT를 진행했다. 주제는 소마.

사실 이것도 내가 하자고 했는데, 그냥 내 팀원들이 이 과정에서 뭘 얻었는지 알고 싶었고, 무엇이 아쉬웠는지 알고 싶었다.

그리고 결과는 다음과 같다. 고마운것도. 좋았던 것도 많았지만 결국 아쉬움이 많이 남을 수 밖에 없는 것 같다.

1. K(eep)
   1. 동인
      1. 아낌없는 지원이 정말 감사했다.
      2. 앞으로의 방향성에 대한 인사이트를 얻을 수 있어서 좋았던 것 같다.
      3. 공부하는 법에 대한 생각을 바꾸게 되었다. 개발자들은 어떻게 공부하는지에 대해 많이 보게 된 듯.
      4. 나쁜 선택이 일어나는 지점에 대해 알게 되었다.
   2. 종현
      1. 혼자 공부하는 법을 익혔다.
      2. 부족함을 많이 알게 됐다. 발전할 수 있는 토대를 알게 됐다.
      3. 좋은 사람 ^.^
   3. 인혁
      1. 팀 선택이 좋았다. 우리팀 정말 좋은 팀이다.
      2. 자신감을 얻었다. 나는 정말 개발을 못한다고 생각했다. 하지만 여기서 자신감을 얻었다.
      3. 경험 그 자체로 좋았다. 소마 자체가 너무 즐거웠다.
      4. 팀, 그리고 다른 팀 사람.
         1. 그냥 사람들을 많이 만나게 된 것이 좋았다.
2. P(roblem)
   1. 동인
      1. 멋진걸 만들어 내고 싶었지만 난 또 안전한 개발 환경을 만들어내지 못했다.
      2. 관심사를 다양하게 분리한 바람에 정말 죽어라 했나? 라는 질문에 대답을 못하겠다.
      3. 공부가 부족했다. 언어나 프레임워크에 대한 이해 없이 진행한 점이 너무 부끄러웠다.
      4. 도움 주는 사람들에게 상처를 준 것 같다 라는 생각을 한다. EX) 조대협 멘토님
   2. 종현
      1. 생각보다 열심히 하지 않았다! > 시간 누수가 좀 있었다.
      2. 공부를 하지 않았다.
         1. 원리를 먼저 파악하는 사람이 되어야한다. 라는 깨달음을 얻었다.
   3. 인혁
      1. 팀을 팀으로 두지 못했다.
         1. 내 팀원을 팀의 누군가가 아닌 그저 한명으로 인식했다.
      2. 팀원을 믿지 못했다.
         1. ‘내가 뭐라고’ 라는 생각에 좀 더 많은 논의를 하지 못했다.
         2. 이걸로 인해 팀원을 믿지 못하게 됐다.
      3. 열심히 했냐?
         1. 난 했다. 프로젝트를 열심히 한건 몰?루 겠다.
      4. 코드 리뷰가 잘 안됐다.
      5. 애자일이 잘 안됐다.
      6. 클린 시리즈 중 하나도 제대로 한 것이 없다.
3. T(ry)
   1. 종현
      1. 공부가 최우선이다. 어떤 프로젝트를 시작하기 전에 준비를 좀 하고 착수하고 싶다.
   2. 동인
      1. 좀 더 Ops적인 특성을 살려서 사람들을 설득해야한다. 내가 중요하다고 생각했으면, 그 또한 가치가 있는 것이다. 대화에 있어서 포기하지 말자.
      2. 고민을 좀 더 하고 싶다. 인프라에 대한 고민과 내가 아는 걸 통한 고민을 멈춰서는 안된다.
   3. 인혁
      1. 코드 리뷰를 빡세게 하고 싶다.
      2. TDD를 하고 싶다.
      3. 내가 하고 싶은 프로젝트 할거다.
      4. 난 내가 아는거까지 할거야.
         1. 이해하지 못한 것은 개발하지 않을 것이다.
         2. 모르는 것을 꾸역꾸역 이끌어나가는게 힘들었다.

 

마무리하며

어울리지 않게 주저리주저리 말이 많았다. 아직 최종 발표도 안 했는데 말이다. 내 생각이 담긴 더 깊은 이야기는 다음에 할까 한다.