과연 내 이력은 이직하는데 부족한걸까? (경력편) -3

[이력 정리] - 과연 내 이력은 이직하는데 부족한걸까? (경력편) -1.   
[이력 정리] - 과연 내 이력은 이직하는데 부족한걸까? (경력편) -2

이제 내 경력이야기의 마지막일거 같다. SI에 근무했지만 했던 프로젝트가 2개밖에 존재하지 않는다. 그렇다고 해서 엄청많은 이야기가 있었던것도 아니었다. 내 개발 역사는 개발 그리고 문서였다. 의미없는 문서만 적는게 일상이었다. 남는게 아무것도 없다. 남은거라고는 오로지 기억에 의존할뿐이었다. 또, 나는 트러블 슈팅한 경험도 있지않는다. 이유는 모르겠다. 분명 열심히했던거 같은데 아무것도 기억이 나지 않는다. 난 여러가지 방법으로 이걸 선택했고 저걸 선택했고 그러지 않았다. 일단 정신차리고 어떤걸 했는지 깊게 고민하자. 

이번에 할 이야기는 오픈소스로 개발을 진행하였다.
https://github.com/IoTKETI/citydatahub_data_core_module  
https://github.com/IoTKETI/citydatahub_data_marketplace_module   
https://github.com/IoTKETI/citydatahub_security_module

이 소스로 개발을 진행하였다. 대부분 여기서 이렇게 했으니 그래야지 라는 접근법으로 개발했던거 같다.
이제 이걸 토대로 설명을 해보자. 나는 이 프로젝트 이후로 짤렸다.. ㅜㅜ
최근에 안 사실인데 이거 다시 한다고 한다.ㅡㅡ 

암튼 이거에 대해 말해볼려구 한다.
저 구조를 보면 알겠지만 모노레포로 되어 있다. 우리는 이걸 멀티레포로 가져간다고 하셨다.
또, 백엔드와 프론트가 혼재된 형태로 되어 있었는데 백엔드와 프론트를 분리를 하기를 원했다.
그래서 adminportal  같은 경우는 제거가 되었다.
이렇게 하는 목적이 내가 생각하기엔 프론트 서버와 백엔드 서버를 따로 관리하고 싶어서 그랬던걸로 기억한다.

요 부분은 잘모르기때문에 일단 넘어가자.

또한 문제가 언어가 자바만 사용하는게 아니었다. 예를들어 시큐리티 같은 경우는 노드로 되어있었고, 코어쪽은 자바로 되어있던걸로 기억한다. 두가지 문제로 인해 언어를 자바로 수정하였는데 첫번째 이유는 노드로 개발할 줄아는 백엔드 개발자의 부재였고, 하나의 언어로 가야 관리하기 유리했기때문에 자바로 했었던걸로 기억한다. 그리고 겸사겸사 자바의 버전을 21로, 스프링 부트 버전을 3.0으로 최신으로 변경하였다. 여기서 버전을 올린 이유는 별 이유없었던걸로 기억한다. 버전을 올려야 사용하기 편하기 때문있었을까? 잘 모르겠다. 

이렇게 언어 통일과 개별적으로 레파지토리를 생성을 시켰다. 이 회사가 전 프로젝트도 그랬고 인프라쪽을 k8s를 이용하고 있었다. 그러면 내가 k8s를 어느정도 사용할 줄알면 좋을텐데 전혀 사용하지 못했다. 배포 같은 경우도 젠킨스에서 버튼 딱각하면 되었기 때문에 어떻게 배포가 진행이 되었는지 정확하게 알길이 없었다. 그 당시 배포를 파이프라인으로 진행했었는데 그게 왜 그걸 선택했는지 잘몰랐었다. 인프라쪽에서 코드를 전달하면 gitlab주소랑 이거저거 바꿔서 사용하였다. 근데 생각할까 그렇다고 해서 그게 어떤 과정인지 정확하게 모른채 사용했던걸로 기억한다. 아무튼 이렇게 배포까지 설정하고 나서

내가 맡았던 모듈은 시큐리티쪽이랑 마켓플레이스쪽이었다. 원래같은 경우는 시큐리티는 oauth를 사용했어야 했었다. 하지만 나는 그렇게 개발하지 않았다. 왜냐하면 공공기관으로 납품을 시킨다는 생각은 안했고 그저 가입 하면, 상품을 구매해서 사용해도 되지 않았나 생각했었다. 이건 생각보다 할 얘기가 없고, 그저 저번 프로젝트에서 내용을 가져오지 않았나 싶다.
아무튼 내가 개발했던것중에 기억나는건 에러코드같이 공통적인 에러코드를 한 곳에서 관리를 하고 싶었다. 왜냐하면 저번 프로젝트에서는 에러 코드를 각자 관리를 했었는데 관리포인트가 많았던걸로 기억한다 그래서 한곳에서 관리하게 되면 편하지 않을까 해서 진행하게 되었다. 하지만 단점도 존재헀다. 하나의 페이지에서 코드를 수정했기때문에 충돌 문제가 많이 발생하였다. 또, 젠킨스로 서버에 배포를 했었는데 기존 서버에는 수정되기 이전의 코드가 존재했었기 때문에 한번은 배포를 해줘야 반영이 되었었다. 마지막으로 한가지 문제가 있었는데 프론트에 어떤 에러 코드인지 알려줘야 했었는데 그것을 알려줄 방법이 없었다. 왜냐하면 이 모듈은 서비스가 아니었기 때문이다. 또 스프링이 아니었다. 그렇기 때문에 직접 api를 만들어서 사용할 수 없었다. 물론, 순수 자바에 네트워크연결하고 스웨거까지 연결하면 연동도 될수 있을 수 도 있겠지만 그렇게하면 공수가 커지기 때문에 하지는 않았다. 아까 서버에 이것을 저장한다고 했었는데 로컬에서 테스트했을 때는 localMaven을 사용할 수 있었지만 젠킨스로 배포했을때는 저장되는 위치가 달랐다. 위치가 다른 이유는 인프라쪽에서 설정했기때문에 달랐었다. 그래서 그 정보를 가져오기 위해서는 그 경로를 직접 지정을 해줘야 했었다. 이걸 찾는데 생각보다 쉽지 않았던걸로 기억한다.
암튼 연동을 시키면, SDK로 등록한 공통 코드 정보를 가져올 수 있었는데 하나의 도메인을 선정해서 api로 만들었던걸로 기억한다.

내가 생각할때 가장 치명적인 문제는 공통 코드를 수정하게 되면 필수적으로 공통 SDK를 배포해서 서버에 반영해줘야하고 그 공통 코드를 사용하는 도메인도 이후에 배포가 진행이 했어야했다. 지금 생각해보면 도메인을 배포할때 필수적으로 SDK를 배포하게 하게 하면 좋지 않을까 생각한다. 이건 간단하게 생각한거라 다른 문제가 있을지는 잘모르겠다. 일단은..
요런 문제가 있었고

그리고 나는 마켓플레이스라는것을 개발했었는데 마켓플레이스는 사용자가 구매할 데이터를 판매하는 곳이라 생각하면 된다. 쉽게 말해 공공 데이터 포탈이라 같다고 볼 수 있다. 근데 의문인게 이 프로젝트가 공공 데이터와의 어떤 차별점으로 이걸 사용하는지는 잘 모르겠다. 내가 생각할때는 공공 데이터 포탈을 쓰는게 낫지않나 생각한다.
아무튼 계속 말하면 사용자가 데이터를 최초 구매하게 되면 서비스키가 생성이 되어지는데 이것을 초창기에는 시큐리티쪽에 존재하는걸로 만들려고 했었다. 왜냐하면 시큐리티가 보안쪽이고 서비스키도 보안에 관련된거라 생각해서 여기에 있는게 맞다고 판단했다. 그래서 처음 생각한게 마켓플레이스에서 서비스키가 생성이 되어지면 그걸 시큐리터 도메인에 전송하는 로직을 생각을 했어야 했다. 아무리 생각해도 카프카을 이용하는게 맞을거 같은데 그건 안된다고 했던걸로 기억한다. 왜냐하면 카프카로는 그걸 하면 안된다고 설명하였다. 하지만 지금 대용량 트래픽을 배운지금 그건 더 말이안된다고 생각한다. 아무튼 그건 반려당했고 그럼 restTempate을 이용해서 찌르는것도 반려당했다. 이것도 안되고 저것도 안되면 시큐리티쪽에서 이것을 저장이 불가능하였다. 그래서 곰곰히 생각했는데 서비스키도 상품과 관련되니까 마켓플레이스에 있어도 되지 않나 생각이 들어서 그냥 마켓플레이스에 넣기로 결정했다. 
서비스키는 계정별로 하나씩 배포가 되었는데 데이터를 사용할때 서비스키의 활성화 여부를 체크를 했었다. 이 부분은 AOP로 개발을 진행하였다. 여러가지 방법이 있었는데 AOP를 선택한 이유는 서비스키를 사용하는 부분이 단순히 데이터를 구매하는 부분에서만 사용이 안될 수도 있다고 생각했다. 그래서 AOP를 이용해서 전반적으로 적용을 시켜놓는것이 가장 좋다고 판단하였다. 또한, 사용도도 측정할 수 있었는데 정해진 갯수만큼 데이터를 이용할 수 있게 만들어야 했다. 그래서 AOP를 이용했다. 스케쥴링도 생각해봤고 메소드를 따로 만들어서 생각해봤지만 스케쥴링을 사용하게 되면 정합성이 맞지 않았고, 메소드를 따로 만들면 중복이 많이 될거라 생각했다. 그래서 중복을 최소화할 수 있는 방법으로 AOP을 선택하였다.
이렇게 서비스키를 만들었다.
데이터는 총 3가지 방법으로 제공이 되었는데 HTTP, MQTT, Websocket으로 제공하였다. 근데 내가 이걸 테스트했을때 이걸 제공하는 이유를 설명해주지 않았다. 단지 KETI에서 사용하고 있어서 이걸 따른다고 알고 있다. 이게 이해가 안된다는거다. 분명히 얘네를 지원하는 이유가 있을텐데.. 아무튼 내가 찾아본 결과 HTTP는 웹 서버를 만든다고 할때 가장 기본적이기 때문에 사용한거 였구
MQTT는 모바일이나 IOT통신할때 사용이 된다고 한다. 마지막으로 Websocket같은 경우는 양방향 통신을 목적이기 때문에 차트를 만들기 위해서 사용이 되는 정도로 알고 있다.

이정도 정리하면 될거 같다.