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

난 참 욕심이 많은거 같다. 나는 지금까지 올해만 3개나 듣고 있다. 이제 겨우 6월인데 반년을 교육으로 도배를 하였다.

근데 왜 이렇게까지 교육을 듣는걸까?
난 스스로 부족하다고 생각하고 있었다. 이게 나쁜건 아닌데 마치 지금까지 했던것들을 부정하고 새로운것으로 뒤엎고 있었다.
이게 맞는걸까? 난 내 이력을 무시하고 있는걸까? 다만 아쉬운건 도메인적으로 개발을 열심히 했던거 같은데 특정 문제를 깊게 고민한 기억은 없었던거 같다. 지금 하는 교육으로 만약 그때로 돌아간다면 어떻게 고칠지도 고민해보자.
음... 내 이력에 대해 간략하게 소개하면

난 2021~2024년까지 근무를 했었다.
그리고 거기서 진행한 프로젝트는 총 2개로 클라우드 프로젝트와 공공 데이터 프로젝트를 진행하였다.
내가 맡았던 파트는 백엔드 개발를 맡았었다.

첫번째 프로젝트는 S사에서 진행했던 프로젝트였으며, 클라우드 관리에 대한 프로젝트를 진행하였다.
다시말하면 뉴타닉스, VMWARE, AWS등 여러 클라우드를 한곳에서 관리할 수 있게 만들어진 프로젝트라고 생각하면 된다. 
이 프로젝트가 나온 이유를 생각하면 각 클라우드 마다 용어가 혼재되있었고 그것을 통일 시킬 필요가 있었다.
그래서 만들어진 프로젝트로 알고 있다. 나는 iam, config, metering, billing, linece 이렇게 총 5개의 도메인을 개발하였다.
나는 이 프로젝트에서 주문이라고 할 수 있는 work를 제외에하고 모든 assert모듈을 담당하였다. 그러니까 이 프로젝트자체가 클라우드를 통합해서 쉽게 사용할 수 있게 하는 프로젝트인데 위 클라우드를 담당하는 모듈을 core모듈이라고 불렸다.
이 내용은 그리 크게 내 경력이랑 상관없으니까 넘어가자면
하나씩 어떤 도메인인지 정리를 해보자.

iam: 이 도메인은 계정, 조직, 프로젝트를 담당하는 도메인으로 계정 CRUD, 조직 CRUD, 프로젝트 CRUD를 담당하였다.
다만 특이한 점은 계정과 조직은 외부 DB에서 받아서 적용을 시킨다는 점이 특이하였다.
이렇게 하는 이유가 계정 DB는 S사쪽에서 관리가 되어지기 때문이다. 그래서 초창기에는 해당 DB는 오라클만 사용이 되었었다. 왜냐하면 S사에서 오라클을 사용했기때문이다. 아무튼 이것을 여기 용어로 AD 계정이라고 불렸다. AD계정은 쉽게 생각하면 사내주소록이라 생각하면 된다. 그런데 이게 S사뿐만아니라 여러 기업에서 사용하게 만들어야 했었다. 그래서 다양한 DB를 사용할 수 있게 적용하였다.
MSSQL,Mysql등등 하지만 모든 기업들이 DB로 계정을 관리하지는 않는다. 그런 기업들을 위해 엑셀을 통해 사내 계정들을 업로드하는 엑셀 업로드 기능을 만들었다. 이렇게 DB로도 엑셀로도 데이터를 넘기는게 가능해졌다. 그러면 이렇게 계정을 이 프로젝트에 넣으면 계정 가입이나 회원가입이 필요없는걸까? 그건 아니다. 왜냐하면 AD는 입사여부를 확인한다고 해도 이 프로젝트에 접근할 수 있는지는 다른 영역이기 때문에 AD계정와 계정을 분리를 했다. 아무튼 특정 계정을 통해 이 프로젝트를 사용할 수 있게 된다. 
그러면 회원가입 또는 계정 생성 같은 경우는 어떻게 하는 걸까? 계정가입시 AD계정에 존재하지 않을시 가입을 할 수 없었다. 즉, 입사를 하지 않으면 이 프로그램을 사용할 자격이 없다는 뜻이 된다. 계정은 이정도 말하면 될거 같구 그 다음은 조직에 대해 말해볼려구 한다.
조직도 마찬가지로 AD에서 데이터를 가져온다. 생각해보면 사내 데이터를 정할때 계정아이디 계정 조직이렇게 저장이 되어진다. S사에는 다양한 관계사와 조직들이 존재한다. 오래되어서 정확히 기억이 나지않지만 6만건정도 되는 관계사가 있었고 20만건이상의 조직들이 있었던걸로 기억한다. 이걸 조회하는 API가 있었는데 그거는 추후에 설명할 예정이다. 그전에 iam의 마지막 프로젝트에 대해 설명을 하려고 한다. 프로젝트에 대해 간략하게 설명하면 클라우드를 관리를 목적으로 하는 프로그램으로 프로젝트를 생성하게 되면 그 안에 다수의 자원들을 넣을 수 있다. 당연히 최초인 상태에서는 프로젝트는 존재하지 않는다.
즉, 프로젝트는 껍데기이며 그 안에 자원들을 넣을 수 있으며 만약 자원이 사용중이라면 프로젝트를 삭제를 할 수 가 없다.
이게 IAM이라는 모듈의 전반적인 내용이다. 각 계정별로 프로젝트를 조회할 수 있었는데 이게 초창기와 많이 달라졌다.
초장기에는 프로젝트를 조직단위로 만들어졌지만 중반기에는 추후에는 계정별로 생성 할 수 있는걸로 바뀌었다. 이유는 정확하게 어떤 이유인지 기억은 나지는 않지만, 내가 기억하기로는 고객사의 요청으로 바뀌었던걸로 기억한다. 하지만 말기에는 다시 조직별 조회로 바뀌었다.. 이유는 미스테리다.... 그렇게 하라그래서 다시 바꿨다는 기억밖에 없다. 아무튼 리스트별로 조직 하위에 소속된 계정을 확인할 수 있었는데 이게 초창기에는 전체 조회만 있었다. 관계사마다 조직의 갯수가 다른데 관계사 하위에 만건이 존재하는것도 있었던걸로 기억한다.
또한 관계사 - 조직 뿐만이 아니라 계정, 프로젝트, AD계정까지 조회를 할 수 있어야 했었다. 단순히 관계가 관계사 - 조직이 아니라 
최초의 조직는 관계사가 맞는데 그 하위에는 몇개의 조직이 있었는지는 알 수 없다. 즉, 관계사 - 조직1 - 조직2 - 조직3 이런 특징을 가진다. 계정 같은 경우는 조직3에만 존재하는게 아니라 조직1,조직2,조직3모두 존재가 가능하다. 그러니까 저 데이터들을 조회하기 위해서는 반복문을 통해 조회하는것이 가장 간단한 방법이었다. 여기까지 보면 알겠지만 이 API는 굉장히 느리다. 한번 조회하는데 10분이 넘어가는 경우도 많이 봤었다. 지금 생각해보면 이렇게 느리면 캐싱을 사용해서 처리하면 될거 같은데 아무래도 SI프로젝트였기때문에 힘들었는지도 모르곘다. 아무튼 처음에는 특정 관계사만 조회가 가능하게 변경을 했다. 변경을 하니 조회하는데 10분이라는 시간은 걸리지 않았다. 하지만 문제는 관계사 하위에 얼마나 많은 조직이 존재하는지는 알 수가 없다. 그래도 많은 2~3분으로 많이 줄일 수 있었다. 그래도 다행인건 이 API는 관리자 전용 API로 많이 사용이 되지 않는점은 다행이라 생각한다. 로그인 기능이 있었지만 관리자쪽에서 특정 사용자를 로그인을 가능하게 만들어달라고 부탁을 했었다. 그러니까 관리자쪽에서 사용자를 조작을 할수 있게 만들어달라는 건데 문제는 관리자는 사용자의 패스워드를 알수가 없다. 그래서 생각한 방법이 아이디와 암호화된 패스워드를 토큰으로 만들고 그것으로 확인하는 방법으로 이 문제를 해결하였다. 이렇게 하니 패스워드를 몰라도 토큰을 통해 확인할 수 있었기 때문에 로그인이 가능했던걸로 기억한다. 마지막으로 내가 기억하고 있는 기능중에 위수탁이라는 기능이 있었다. 위수탁은 특정 관계사 or 조직이 타 조직에게 프로젝트를 만들어달라고 요청하는 기능으로 이 기능을 만들때 용어가 굉장히 헷갈려서 힘들었다. 위탁조직이 뭔지 수탁조직이 뭔지 정확하게 아는것이 힘들었다. 아무래도 한자어라 힘들었던걸로 기억한다. 이 기능도 내가 만들었다. 이렇게 IAM 모듈에 대한 전반적인 내용을 설명하였다. 

생각보다 길어진거 같다. 간략하게 여기서 내가 개발했던 기능들을 소개하면 이렇게 된거 같다.

+) 내가 중요한걸 빼었다. 이 도메인에서 개발하기 어려웠던 부분은 권한을 설정하는 부분이 어려웠다. 조직별로 프로젝트를 구분을 지을 수 있었다. 권한은 
최고 관리자, 일반 관리자, 중간관리자, 커스텀 사용자, 멀티 사용자, 일반 사용자 이렇게 구분이 되있었다.
이들의 특징은 최고 관리자는 관리자로써 모든 권한을 갖는 관리자를 뜻하고
일반관리자는 특징은 관리자인데 정해진 역할만 사용이 가능한 관리자를 뜻한다. 즉, 이말이 뭐냐면 관리자 화면에서 특정 권한만 가능하다는뜻으로 해석하면 된다. 지금은 오래되서 기억이 잘 나지 않는다. 

그리고 나머지는 사용자다. 왜 중간관리자가 사용자인지는 이 권한은 관계사별로 존재하는 프로젝트를 모두 확인할 수 있는 권한이다.
즉, 사용자가 프로젝트를 만들어서 사용하기 때문에 중간관리자는 사용자입니다. 그냥 용어로 이해하면 될거 같다.
그리고 조금 헷갈리는 멀티 사용자와 커스텀 사용자이다. 이둘의 공통점은 다른 조직의 프로젝트도 확인이 가능하다는점이다. 하지만 차이점은 관계사에 있었는데 멀티 사용자는 같은 관계사의 조직의 프로젝트뿐만아니라 다른 관계사의 프로젝트도 확인이 가능하다는 점이다.
그러면 중간관리자와 뭐가 다르냐고 할 수 있다. 중간관리자는 관계사의 '모든'조직이고 멀티 사용자는 선택한 조직이라는 점이 다르다.
하지만 이론적으로 모든 조직을 선택한다면 중간관리자보다 많은 수의 프로젝트를 확인할 수 있다. 그러면 반대로 커스텀 사용자는 같은 관계사의 조직만 선택이 가능하다는 차이점을 가지고 있다.
하지만 이게 생각보다 복잡해서 추후에는 이러한 권한이 사라지고 위수탁으로 대체가 되었다.
워수탁을 통해 프로젝트를 전달하는 개념으로 변경되었고
추후에 계정단위로 프로젝트가 변경되었기때문에 특정 조직이 프로젝트를 초대하는 기능도 추가 되었다.

IAM 도메인 모듈 주요 개발 경험 요약

IAM 모듈은 계정, 조직, 프로젝트 세 가지 도메인을 중심으로 구성되며, 각 도메인의 CRUD 기능을 개발하고 유지보수하였습니다. 특히 이 시스템은 내부 계정·조직 정보를 외부 AD(Active Directory) DB와 연동하거나 엑셀 업로드로 유입받는 하이브리드 구조를 갖고 있어, 다양한 환경에서도 동일한 방식으로 적용될 수 있도록 유연성을 확보해야 했습니다.

---

개발 주요 기능 및 성과

1. 조직 조회 API 성능 최적화
   • 트리 구조로 구성된 관계사-조직 계층 데이터(최대 20만 건)를 대상으로 하던 전체 조회 로직을 관계사 단위 필터링으로 개선
   • 최대 10분 이상 걸리던 조회 시간을 2~3분 이내로 단축, 사용성 및 관리자 업무 효율 향상
2. 엑셀 기반 계정 업로드 기능 구현
   • AD DB가 존재하지 않는 외부 관계사에서도 시스템 도입이 가능하도록 엑셀 업로드 기능을 도입
   • MSSQL, MySQL 등 다양한 DB 포맷과 병행하여 유연한 계정 데이터 유입 경로 제공
3. 계정 단위 프로젝트 접근 구조로 전환
   • 기존에는 프로젝트 생성·조회가 조직 단위에 묶여 있었으나, 고객 요청에 따라 계정 단위 접근 방식으로 개선
   • 이후 다시 조직 단위로 회귀했지만, 이 과정에서 권한 정책과 데이터 구조 전환 작업 수행
4. 관리자용 강제 로그인 기능 개발
   • 관리자가 사용자의 비밀번호를 알 수 없는 상황에서, 암호화된 토큰 기반 인증 방식으로 로그인 처리 기능 구현
   • 비밀번호 없이도 특정 사용자의 접근 제어가 가능해짐
5. 중복 로그인 방지 기능 도입
   • 같은 계정으로 여러 세션에서 접근 시 중복 로그인 제한 기능을 구현하여 보안 및 자원 안정성 강화
6. 위수탁(委受託) API 설계 및 구현
   • 관계사 혹은 조직 간 프로젝트 생성 요청을 주고받는 구조(위탁자→수탁자)를 API로 구현
   • 위탁/수탁 개념이 모호한 사용자도 쉽게 사용할 수 있도록 명확한 역할 정의와 데이터 흐름 정립
7. 조직-계정 간 권한 모델 설계 및 구현
   • 6단계 권한 체계 설계 및 적용
     • 최고 관리자 / 일반 관리자 / 중간 관리자 / 일반 사용자 / 멀티 사용자 / 커스텀 사용자
   • 각 권한의 범위는 조직/관계사/계정 단위에 따라 상이하며,
     예:
     • 중간 관리자: 해당 관계사의 모든 조직에 접근 가능
     • 멀티 사용자: 다양한 조직(타 관계사 포함)의 프로젝트 접근 가능
     • 커스텀 사용자: 동일 관계사의 일부 조직에만 접근 가능
   • 복잡한 권한 구조로 인한 유지보수 문제로, 후속 버전에서는 위수탁 기능으로 통합 관리
8. 조직 간 프로젝트 초대 기능 추가
   • 위수탁 모델에서 발전된 구조로, 특정 조직이 외부 계정을 프로젝트에 초대할 수 있도록 기능 확장
   • 실제 조직 간 협업 구조를 반영한 실질적인 역할 관리 방식 도입

---

기술적 어려움과 해결 경험

• 복잡한 권한 체계와 계층 구조에서 오는 설계 난이도가 높았으며, 트리 구조 탐색 및 성능 병목 지점 해결이 핵심 과제였습니다.
• SI 프로젝트 특성상 캐싱이나 아키텍처 개선이 어려운 환경에서도, 데이터 범위 제한, 접근 제어 정책 재설계 등을 통해 문제를 우회하며 안정적인 운영을 가능하게 했습니다.

심층적인 내용은 추가적으로 생각해보고 일단 요정도만 하자.

나머지는 천천히 올려보고 이력서를 다시 변경할 예정이다. 
소개글부터 다시 써보자.