뒷단에 존재하는 매출에 아주아주아주 간접적인 영향만을 미치는 시스템을 재구축해야한다. 누가 시작한걸까? 자의반 타의반? 사실 엔지니어로서 하고싶긴하지만 조직에서의 관심과 지원은 아주적어.. 평가를 받는 직원입장에서는 썩 내키지만은 않는..

기술적인 입장위주로 정리해보자

...

재구축작업전의 상태:

• 코드가 복잡하다.
• 지워야할 미사용 코드가 많다.
• 복잡한 코드를 손대기 꺼린다.
• 버그를 하나 고치면 다른 버그가 생긴다.
• 코드베이스가 너무 크고 빌드와 배포가 답답해서 자꾸 미룬다.
• 데이터 정확도 낮음 (복잡한 처리 프로세스로 예외 상황 자주 발생)
• 새로운 기능이나 비지니스 추가 어렵고 버그가능성 높음
• 
  

사실 현재의 안좋은 상황에 대한 표현을 하자면 끝이 없을것 같다. 짬날때마다 추가하자.

우리 팀에서 1개월 이상짜리 프로젝트는 일정을 추정한다는건 일단 틀릴 확률이 극히 높다. 비지니스 특성상 대부분 외부의 데이터를 받아서 처리한다. 처리한 데이터를 외부로 제공하는 부분은 적다. 연말이되니 각종 팀에서 NFR을 진행한다고 난리다. 언제까지 해줄수 있냐 언제까지 해줄수 있냐... 거기다가 비지니스 관련 개발 요구 한 두개가 윗선으로 올라갔다가 내려오면서 우리의 우선순위를 가볍게 바꾸어준다. 농담인지 진담인지 우리 재구축 프로젝트의 일정을 보고받았던 매니져는 스스로 바꾼 우선순위 조정한건 잊어버린건지 우리 재구축프로젝트가 예정대로 끝나느냐고 사람좋게 웃으며 물어본다. 자기는 맨첨에 들었던 일정만 기억하는 경향이 있다나? ㅎㅎ 재밌다. 글의 성격이 자꾸 프로젝트 관리쪽으로 흘러가려고 한다. 자제하고..

"완료하지 못하더라도 들인 시간만큼은 최대한 버리지 않도록 하자"가 사실은 나의 개인적인 최대 전략이었다. 다행히 Phase 1, Phase 2까지 약간은 늦어졌지만 잘 끝냈고 잘 동작하고 있고 혜택을 보고 있다.

덕지덕지 커지고 지저분해진 시스템을 크게 한덩어리를 분리하는 과정, 스프링부트를 기반으로 분리했다. 일단 비지니스코드는 그대로 옮겨진 상태라 지저분한 상태 그대로지만, 코드베이스가 작아지면서 빌드와 배포가 무지 빨라졌다. 이제 조금이라도 고치고 싶은 부분이 있으면 바로 고쳐서 바로 배포하는 경우가 많아졌다.

기존의 큰 프로세스 하나를 두개의 프로세스로 분리했다. 기존에는 외부의 메시지를 받아 복잡한 Process1을 수행하고 또 동일 트랜잭션에서 또 하나의 관련 Process 2를 수행했다. 카프카 컨슈머가 해당 로직을 동기적으로 처리하고 있었다. 일단 이를 두개의 프로세서로 분리했다. 컨슈머는 Process1까지만 처리하고 Process2는 별도의 프로세스가 배치로 처리했다. 사실 두번째 Processs가 만들어내는 데이터는 실시간으로 생성될 필요가 없는 데이터였다. 다만 Process1에서 만들어진 데이터를 기반위에서 만들어지는 데이터라 아마 처음에 개발할때는 큰 고민없이 그대로 동일 트랜잭션에 끼워넣었을것이다.

뭐가 좋아졌나... // TODO

Kafka Consuming을 이벤트 처리의 시작점으로 하는 팀의 입장에서 고충과 노하우?도 따로 정리해보자. 아.. rebalancing..

원래 '외부 API 데이터에 대해 도메인 내부적으로 필요한 값들로만 구성된 내부 데이터 저장소 구축'을 Phase 3의 주제로 계획했었으나, 팀원들의 다양한 의견으로 '마이크로 서비스하에서 Smart한 통합테스트 환경 구축'으로 바뀌었다. 사실 외부데이터 의존도가 상당히 높은 시스템의 특성상 이런 부분이 여러모로 필요하다고 생각해왔었다. 하지만 나의 설득력 부족과 논리적인 필요성에 대한 정리가 안된상태에서 난상토론끝에 이것보다는 일단 테스트환경이 더 필요하다 라는 결론에 도달하게 된것이었다. 물론 테스트환경구축에 대한 생각도 사실은 더 오래전에 하고 있긴했었다. 하지만 대부분이 동의하지 않는 상황에서 내 의견대로 진행될경우 팀원들의 참여도가 떨어질거라는 생각을 하고 있었다. 그렇게 하는 일은 재미없지 않은가.. 나 개인적으로는 외부데이터 저장소 구축이 더 급하고 더 효용성이 높아 보였기 때문에 처음에 Phase 3로 잡았던 것이었다. (참고로 이 프로젝트에 대한 상위 매니져용 보고 문서는, 처음에는 내가 테스크 필요항목과 각종 백데이터, 현상황, 기본적인 설계방향, 시스템 구성방안만을 제공해서 팀 매니져가 작성하는 그림이었으나, 어찌하다보니 전체적으로 내가 머리를 짜내서 만들어야하는 그림으로 바뀌어 있었다. 처음에는 사실적이고 객관적인 부분에 대한건 당연히 내가 주도적으로 설계하고 그리는게 맞다는 생각에서 진행을 했는데 점점 문서가 기술문서보다는 두리뭉실한 관리자용 계획보고서같은 쪽으로 변하고 있었다. 다른건 할만했지만 현 팀의 속도와 예상업무를 종합적으로 검토해서 이 프로젝트가 언제쯤 어떻게 진행될건지를 예측해서 적어야하는 부분이 무척 어려웠다. 너무나 막연하다는 생각이 있어서 태스크별 추정소요리소스를 적는 부분도 사실은 오차범위가 넓을거라는 생각을 하고 있었는데 이걸 토대로 진행일정을 예측한다는건.. 정말 틀릴 확률 99%이라는 생각이 머릿속을 떠나지 않았기 때문이었다. 사실 사이징을 위한 태스크 추출작업조차도 많은 부분 추상적인 부분이라 태스크가 추가될 가능성이 너무 높았기때문이었다. 이 보고서 작성에 대한 에피소드는 따로 적어야겠다. 이거 자체가 하나의 과제였다. 나에게는.. 첨에는 기술문서 관점에서 시작했으나..) 하지만 Phase 2가 완료되는 무렵 일정은 원래보다 늦어졌고 사실 이번 프로젝트의 핵심이자 가장 도적적인 부분인 Phase 4를 먼저 하는게 차라리 나을것 같다는 여러명의 의견이 있었다.(아래에서 이제 Phase 3로 언급, '이벤트스토어기반메시지처리') 사실 나도 테스트 환경 구축은 지금 시국?상 사치스럽다는 생각이 들정도로 다른쪽에 더 많이 급한 상태였다. 그리고 내용적으로도 테스트 환경구축보다는 복잡 다양하게 쏟아져 들어오는 많은 이벤트를 정교하게 오차 없이 처리하도록 하는 과제가 더 도전적이었다. (이벤트 스토어를 구성하고 해당 이벤트 엔트리를 정확한 근거로 가지는 정확한 시스템을 만들어보자는것도 원래 작년부터 구상해오던 나의 기본 아이디어였기 때문이기도 하다.)

아 글로 쓰려고 하니 막상 쓸게 없을줄 알았는데.. 뭔가 주저리주저리 할말이 많은것 같다.

연말이 가까워지는 현재, 그나마 경험있는 팀원 한두명이 또 다시 빠진다고 하고 프로젝트는 진행할 수록 생각지 못했던 가지들로 인해 예상 소요시간이 자꾸 늘어나고 있다.

그나마 다행히 Phase 3을 설계 및 진행하면서 원래 Phase3의 별도 스텝으로 진행하고자했던, '외부 도메인 데이터에 대한 내부 저장' 태스크를 하게 되었다. - 이 부분도 별도로 얘기할만큼 얘기가 많지만 간략히 얘기하자면 우리팀은 1년전 2년전 데이터도 처리해야하는 비지니스가 있다. 하지만 대부분의 외부 팀들은 현재가 중요하다. 6개월만 지난 데이터도 DW로 넘겨버리고 API로는 제공을 하지 않으려고 한다. 나중에 따로 더 써야겠다... - 일단 이 태스크를 완료하면 외부데이터 참조와 관련하여 현재 발생되는 많은 문제를 커버할수 있게된다. 새로운 로직에 적용하기 전 일단 기존 로직에서 외부 API를 호출하기전에 이번에 구축하게되는 '외부 도메인 데이터 내부 저장소'를 이용하도록 간단히 먼저 고치려고 한다. 이제 데이터 발생시점에 우리쪽에 저장해두기때문에 오래된 데이터를 처리해야할때도 큰 고민없이 사용할 수 있다. 외부 API호출횟수를 크게 줄일수 있다. 테스트가 조금이나마 더 쉬워진다. (우리는 다양한 시나리오의 테스트 데이터가 필요하고 이를 위해 다양한 Mock 데이터를 테이블에 넣어서 테스트하는것이 API Mocking을 통해 테스트하는 더 쉬울것이다. 물론 스마트한 런타임 통합 테스트환경을 구축하면 되지만 적지않은 시간이 설계와 구현에 들어갈것이다. 그리고 이 mock table을 통하는 방법으로 구현하면 그 테스트 환경 구현 자체도 더 심플해지고 좀더 빨리 구현가능할것 같다.)

계획 보고에는 '테스트환경구축'으로 되어 있으나.. 이걸 할수 있을까 난 Ph3이 끝나면 다른 걸 하거나.. 뭐 하여간 좀 먼일이 될것 같은 예감이 든다.

아.. 단계별 롤아웃.. 마이그레이션..

• spring cloud stream
• spring boot
• kotlin
• pattern : 다양한 소스로부터 인입되는 대량?의 메시지를 동일한 정책으로 정확하게 처리하기(event store based)
• pattern : event stream pipeline을 통해, 외부 데이터(메시징, API)에 대한 의존성 높은 시스템에서 안전하게 데이터 참조하기