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

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

저번에 iam에 대해 정리를 했었는데 생각보다 많이 했던거 같다. 이제 나머지 config,metering,billing,lincense에 대해 정리를 하면 될거 같다. 얘네 같은 경우는 내가 main으로 가져가는 도메인이 아니기때문에 상대적으로 적을거라 예상한다.

아마 정리는 3편까지 할거 같고 4편에는 이력서에 어떻게 적을지 작성해보는 시간을 가질려고 한다.

자 본견적으로 시작해서 config부터 시작하자.

config: 각 도메인에서 환경설정으로 사용될 서버에 대한 정보가 저장되어있다. 근데 소신발언하자면 초반에는 이 내용들이 나름 잘 지켜진거 같은데 나중에 되니 각 도메인에서 설정 API를 따로 만들었다. 어떤건지 정확하게는 기억이 나지는 않지만 아무튼 내 생각엔 그렇다.
간략하게 서버에 관련해서 말하면 메일서버, db서버, 클라우드 서버등등이 있었다. 여기서 조금 자세하게 말할 서버는 db서버다. 
왜 DB서버가 있을까? 그 이유는 iam파트에서도 말했듯이 외부에서 DB정보를 가져와야 했었다. 그리고 그러한 정보가 config에 있다고 생각하면 된다. 이 도메인같은 경우에는 이미 완성이 되있는 도메인이었기때문에 딱히 할말은 없지만 초창기에는 DB서버는 오라클만 존재했었다. 하지만 추후에 오라클뿐만아니라 다른 DB서버도 접근이 되어야 했었다. 크음.. config에는 딱히 개발한게 없는듯하다. 다음으로 넘어가자. 여기는 유지보수만헀었던걸로 기억한다. 내 기억이 맞다면 뭔가 이슈가 있었는데 지금은 기억이 나지 않는다.ㅜㅜ

metering,billing: 이 두개를 묶은 이유는 두개는 매우 밀접한 관계가 있는 도메인이기 때문에 묶어 놨다. 원래는 얘는 내 도메인이 아니었다. 하지만 어쩌다보니 이 도메인들이 내 도메인이 되었다. 정확히 말하면 내 사수?(사수맞나)가 이 도메인을 가져간다고 했었는데 나한테 짬때렸었다.ㅜㅜ 내가 기억하기로는 미터링이라는 곳에서 자원들을 관리가 되어지는 걸로 알고 있다. 네트워크라던지 nas라던지 vm이라던지 그러한 정보들을 미터링이라는 도메인에서 얼마나 사용했는지 체크를 했었었다. 그런데 문제는 스케쥴링으로 데이터를 가져오고 있었는데 이게 무지막지하게 컸었고 그것을 해결하고 싶었다. 미터링에 대한 버그는 대부분 이 스케쥴링에서 나왔던걸로 기억한다. 지금 생각해보면 네트워크 vm, nas에 관련된 정보들을 클래스로 분리를 해서 관리해야 되지 않았나 생각한다.
아무튼 프로젝트별로 자원을 얼마나 사용이 되었는지 관리가 되어지는데 조금있다가 AWS를 잠깐말할예정이다. 이 도메인은 내가 개발하지 않았다.
이제 빌링이다. 빌링은 말그대로 과금을 담당하는 도메인이다. 미터링에서 사용여부,사용량을 체크하고 그걸 토대로 과금이 되어진다. 초창기에는 프로젝트단위 30일씩 과금을 매겼었는데 이걸 자원별로 각각 일당 얼마씩 과금이 되는지 보고 싶다는 고객사의 니즈가 있었다. 그래서 단순하게 생각했을때 프로젝트마다 어떤 자원이 있는지 확인하고 30일로 나누어서 얼마나 과금이 되었는지 체크를 했었다. 그런데 과금이 내 마음대로 나누어 떨어지지 않았다. 1단위, 소수점으로 떨어질거라고는 생각했었지만 무한소수로 될줄은 몰랐다.인터넷에 찾아보니 은행가의 반올림으로 해결을 하라고 했다. 적용했지만 소용이 없었다. 그래서 어쩔 수 없이 고객사랑 얘기를 해 소수점 둘째자리로 하기로 했다. 근데 이때 내가 2년차였는데 내가 과금을 맡은게 맞았나? 싶다. 
아무튼 아까 AWS얘기를 잠깐할려고 하는데 원래 자원은 미터링이랑 빌링에서 처리를 했어야했다. 하지만 aws는 달랐다. 나는 이게 이해가 되지 않는다. 왜 AWS에서 미터링이랑 과금을 처리했는지.. 이럴거면 뉴타닉스와 vmware에도 각각 존재하는게 맞다고 생각하는데 아무튼 AWS는 자체적으로 이게 존재했던걸로 기억한다.

또 생각난게 뉴타닉스와 vmware은 원화로 하고 AWS는 달러로 했다. 어째서 AWS를 원화로 안했는지 의문이다. 실시간으로 환율적용하면 되지 않나 싶다. 솔직히 이 도메인들은 뭔가 기분나쁜 도메인이다.

licnese: 결론부터 말하면 이 도메인은 실패하였다. 원래 목적은 도커와 K8S를 읽어서 라이선스 도메인으로 각 서버를 배포하는걸 목표로 만들었던걸로 기억한다. 하지만 결국 하지 못했다. 일단 이건 주니어 2명이서 만들었고 내가 k8s쪽을 맡아서 개발을 진행하였다. (하지만 한명이 결국 퇴사하면서 이 도메인은 내가 가져갔다.) 일단 이 도메인의 역할부터 설명하자면 이 프로젝트는 4가지의 방향성을 가지고 있었다. basic, plus, enterprise 하나가 기억이 안나네... 아무튼 버전이 올라가면서 기능이 추가되는 형식이었으며 특정 도메인은 특정 버전에서 사용을 할 수 없다. 하지만 이게 관리자페이지에서 사용할 도메인을 설정할 수 있었다. 내가 기억이 나는 걸로 말하면 도커는 서버에 등록되어있는 tar파일과 매핑해줘서 실제로 서버에 올라가있는지 확인하는 역할을 했었고 k8s쪽에서 그 tar정보를 가지고 배포를 시킬 수 있는걸로 개발했던걸로 기억한다. 그때당시 도커나 k8s나 제대로된 지식이 없는 상태에서 만들다보니 제대로 만들 수 없었다. k8s API가 있어서 그걸 사용했지만 어찌된 영문인지 기억은 나지 않는다. 하지만 이 도메인에는 아주큰 치명적인 문제가 있엇다. 버전에 각 도메인을 넣고 그 버전을 배포를 시키면 배포가 되어졌는데 문제는 라이선스 도메인도 버전에 등록을 시킬 수 있었다. 즉, 본인을 본인이 배포가 되어지는 시스템인데 그렇다고 이걸 뺄수 없었던게 라이선스가 수정이 되기 때문이다. 결국 완벽하게 개발이 되지 않는 상태에서 계속 버그가 조금씩나온걸로 기억했고 다른 도메인과 달리 라이선스 같은 경우는 서버를 직접 사용하는 도메인이기때문에 테스트하는것이 생각보다 쉽지 않았다. 실제로 tar데이터를 못가져오는 버그가 있었다. 하지만 내가 기억하기로는 이 도메인은 미완인 상태로 계속 끝까지 남아있었던걸로 기억하
고 개인적으로 실패한 도메인이 아닌가 싶다.

---

✅ Config

• 역할: 각 도메인별 환경 설정 (메일 서버, DB 서버, 클라우드 등)을 저장
• 개발 여부: 개발 X, 주로 유지보수
• 특이사항:
  • 초기에는 도메인 간 설정 일관성이 있었으나, 이후 각 도메인별로 설정 API를 따로 만들기 시작
  • DB 서버 설정은 초기에는 오라클만 있었지만 이후 다양한 DB를 지원하게 됨
  • 특정 이슈가 있었던 것 같으나 기억은 흐릿함

---

✅ Metering & Billing

• 역할: 자원 사용량 측정(Metering) + 그에 따른 과금 처리(Billing)
• 개발 여부: 본래 담당자가 있었으나 실질적으로 넘겨받아 관리
• 특이사항:
  • Metering: VM, NAS, 네트워크 등의 사용량을 스케줄링 방식으로 수집 → 데이터 양이 많아 성능 이슈 발생
    • 대부분의 버그가 이 스케줄링 로직에서 발생
    • 자원별 클래스로 분리하여 관리하는 방식이 아쉬웠음
  • Billing:
    • 초기에는 프로젝트 단위로 30일마다 과금
    • 고객사의 요청으로 자원별 일 단위 과금 추가 → 소수점 처리 문제가 발생 (은행가 반올림 적용 시도 → 소수점 둘째 자리로 합의)
    • 2년차 때 과금 도메인을 혼자 맡으며 책임감과 부담감 느낌

---

❓AWS 관련

• 이슈: AWS는 미터링/빌링 로직이 자체적으로 존재 → 기존 방식과 이질적
  • 뉴타닉스/VMware는 원화, AWS는 달러 기반 → 실시간 환율 적용되지 않음
  • 도메인 통일성/일관성 부족에 대한 불만족

---

❌ License

• 역할: Docker/K8s 기반 배포 라이선스 관리
• 개발 여부: 처음에는 2인 개발팀, 퇴사 이후 전담
• 특이사항:
  • 프로젝트 목적: 서버에 배포된 tar 파일과 버전(기능 레벨)에 따라 도메인 사용 권한 제한
    • 예: basic/plus/enterprise 같은 등급 체계
  • Docker: 등록된 tar 파일을 통해 실제 서버에 존재 여부 확인
  • K8s: 해당 정보를 기반으로 배포 시도 (K8s API 활용)
  • 치명적 문제: 라이선스 도메인이 스스로를 배포할 수 있는 구조 → 순환 참조 문제
  • 테스트 환경 구축 및 실데이터 적용이 어려워 버그가 자주 발생
  • 결과적으로 "개인적으로 실패한 도메인"이라고 판단

2편은 이정도로 하면 될거 같다. k8s와 도커를 공부해서 이 도메인에 대해 설명할 수 있으면 굉장히 경쟁력이 있을거라 생각한다. 
추후에 이 도메인을 가지고 프로젝트를 전회사에서 진행을 하였다.(나는 아님) 자책을 하면 만약 이 도메인을 잘 개발했다면 그 서비스는 내가 개발하고 있지 않았을까?? 적고나니 나는 다양한 도메인을 맡아왔지만 실질적으로 많이 기억이 나는 도메인은 하나였던거 같다.
메인이 되는 도메인은 하나고 나머지는 잘 기억이 나지 않는다. 이제 이 프로젝트말고 공공데이터 프로젝트에 대해 설명을 하면 될거 같다.