OSGI 프레임워크 - 전직장에서 사용한 프레임워크

📌 전 직장의 경험담

지난 포스팅에서는 현 직장에서 다뤘던 SIEM 보안 솔루션 시스템에 대해 간단히 정리했었다.
그리고 이제, 어느덧 그 직장은 전직장이 되었다.

사실 조금 더 다닌다면 SIEM 시스템에 대해 깊이 다뤄보고 싶었지만,
심상치 않았던 회사 분위기와 잦은 퇴사 소식 속에 결국 나와 내 부사수도 퇴사를 결정하게 되었다.

이번 글에서는 마지막으로, 해당 회사에서 처음 접하게 된 특이한 프레임워크 – OSGi에 대해 정리해보고자 한다.

---

🌐 일반적인 웹 개발 프레임워크는?

보통의 기업에서는 Spring Framework 혹은 Spring Boot를 기반으로 웹 개발을 진행한다.
공공기관이나 정부 사업을 수행하는 SI 업체라면 전자정부프레임워크를 사용하는 경우도 있다.

이러한 프레임워크들은 단일 어플리케이션 구조로 잘 설계된 웹 시스템을 구성하는 데 효과적이다.
그러나 모든 상황에 적합한 것은 아니다.

---

🛡️ 보안 솔루션 회사에서 만난 OSGi

이전 회사는 보안 솔루션 전문 기업이었으며, 주요 업무는 관제 시스템 운영이었다.
이 관제 시스템에서는 다양한 네트워크 장비 및 보안 장비에서 발생하는 로그 수집이 필수적이며,
수집된 로그를 분석해 침입 탐지 및 보안 대응을 수행하는 것이 핵심 업무였다.

이러한 구조에서는 하나의 장비만 다루는 것이 아니라,
수많은 종류의 보안 장비를 동시에 다루며,
각 장비는 서로 독립적으로 운영되어야 한다는 특성을 갖고 있다.

---

🔄 장비 간의 독립성 유지가 중요한 이유

보안 장비는 다음과 같은 특성을 갖는다:

• 서로 간섭해서는 안 된다.
• 업데이트 주기가 다르다.
• 각 장비별 로그 포맷 및 대응 방식이 상이하다.

이러한 환경에서 Spring 기반의 단일 구조 시스템을 사용하면 다음과 같은 문제점이 발생한다:

• 한 장비의 로직이 바뀌면 전체 시스템을 재배포해야 한다.
• 버전 충돌이 잦고, 의존성 수정이 어렵다.
• 빠른 대응이 어려우며, 개발 공수가 과도하게 증가한다.

특히 전체 시스템을 재배포해야 하는 상황에서는 시간과 리소스 모두 큰 부담이 된다.

 

---

🧩 OSGi 프레임워크의 도입 배경

이러한 문제를 해결하기 위해 선택한 것이 바로 OSGi 프레임워크였다.
OSGi는 모듈형 시스템을 구축하는 데 특화된 자바 기반 프레임워크다.

• 각 장비별 기능을 **독립적인 번들(Bundle)**로 분리할 수 있다.
• 번들마다 자체 ClassLoader를 가지고 있어, 라이브러리 충돌을 방지할 수 있다.
• 실행 중인 시스템에서도 번들을 설치, 교체, 제거할 수 있어, **핫디플로이(Hot Deploy)**가 가능하다.
• 전체 시스템이 아닌, 해당 모듈만 업데이트하면 되므로 운영 부담이 크게 줄어든다.

---

🕰️ OSGi의 역사 – 모듈화를 향한 진화의 기록

지금은 다양한 모듈 시스템과 마이크로서비스 아키텍처가 보편화된 시대다.
그러나 Java 생태계에서 가장 먼저 모듈화를 강력하게 실현한 기술 중 하나는 바로 OSGi였다.

 

OSGi(Open Services Gateway initiative)

 

1999년, IBM, Sun Microsystems, Ericsson 등 주요 기업들이 주도하여 설립한 OSGi Alliance에서 시작되었다.

OSGI의 시작은 스마트홈, 통신 장비 등 임베디드에 동적으로 서비스를 배포할 수 있는 표준을 만드는 것이었다.
즉, 재부팅 없이 새로운 기능을 추가하거나, 서비스 로직을 교체할 수 있는 플랫폼을 만들고자 했다.

 

당시, 유비쿼터스 컴퓨팅이라는 단어와 RTOS(Real Time Operation System)등의 용어가 유행이었다.

특히 2000년대 후반은 더더욱 그랬던거 같다. (내 대학 입학시절 ㅎㅎ)

 

IOT 기술 및 RFID  등 하드웨어적으로 우선 소형화 및 모듈화 형태의 기술들이 개발되고 출시되었다.

그렇다 보니, 소프트웨어에서 모듈화 형식 개발을 기반으로 한 OSGI 프레임워크도 같이 성장하게 됐다고 한다.

(2000~2010년까지 Java버전으로 확장되고, Eclipse의 내부 플러그인으로 확장되는 등 많은 발전이 있었다.)

 

전직장의 경우 회사 설립일이 1999년도 초반이라고 한다.

보안관제, 특히 장비별 독립적인 로그 수집이 중요한 업무였던 회사의 경우 OSGI만한 기술이 없었던것 같다.

Java버전으로 확장된 시기와 회사 솔루션 개발시기가 딱 맞아 떨어진것도 한몫한것으로 보인다.

---

아래는 GPT의 검색으로 얻어낸 정보이다.

이 정보만 봐도 SIEM 회사인 전직장이 왜 도입했는지를 알 수 있다.

🚀 전성기: 보안, 통신, SIEM 시스템으로의 확장

이후 OSGi는 단순한 임베디드 프레임워크를 넘어,
엔터프라이즈 보안 시스템, SIEM 솔루션, 통신 서버, IoT 게이트웨이 등으로 활용 영역을 넓혀갔다.

특히 다음과 같은 이유로 OSGi는 이들 분야에 적합했다:

• 핫디플로이 지원: 시스템 중단 없이 모듈 추가·교체 가능
• 모듈 독립성: 보안 장비 간 간섭 없이 독립적 개발·배포 가능
• 버전 충돌 회피: 번들 단위 ClassLoader를 통해 라이브러리 충돌 방지

---

 

🔍 Spring과 OSGi의 비교

현재 가장 많이 쓰이는 Spring FrameWork와 OSGi 기반 시스템을 비교한 표이다.

모듈 독립성	낮음	매우 높음
핫 디플로이	어렵다 (거의 불가)	가능
버전 충돌 방지	ClassLoader 공유로 충돌 가능	번들 단위 분리로 방지
확장성	구조 설계에 따라 달림	기본 지원
운영 안정성	재시작 필요	무중단 업데이트 가능

 

OSGi는 복잡하고 동적인 시스템, 특히 보안이나 통신 같은 분야에서 진가를 발휘하는 프레임워크다.

실제 개발을 하면서 사용을 해보아도, 나쁘지 않고 오히려 괜찮은 프레임워크라는 생각이 많이 들긴 했다.

다만, 너무나도 오래되고 쓰이지 않은 기술이었기에, 정보를 찾는데에 많은 시간이 필요했다.

[GPT와 같은 AI의 초기 시절이라 구글링 위주 검색, 보안회사다보니 사용도 제한적이라 정보 검색에 문제가 많았음.]

그렇다 보니, 정말 어이 없는 실수들도 생기기도 했다. (팀원 전체적으로)

 

그리고 기본 개발적인 자바 소스코드는 스프링 프레임워크를 사용하고 있었다.

왜 Spring으로 아예 갈아타지 않을까??

 

나름 200명 이상의 회사이며, 여러 대기업들의 고객사를 가지고 있는 회사이긴하다.

그러니 변화에 보수적일수밖에...

 

특히 스프링 하나만 가지고 OSGI가 가지고 있는 장점 자체를 극복하긴 어렵다는 생각도 들었다.

다만, OSGI가 가진 한계점도 참 많은데.. 왜 안고 가는것일까??? 하는 생각이 떠나질 않았다.

그렇게 회사를 다니며 느낀 OSGI의 한계점은 아래와 같다.

---

⚠️ 한계와 변화 – OSGi의 현재 위치

하지만 시간이 지나면서 OSGi도 몇 가지 한계를 드러내기 시작했다:

• 개발 진입 장벽이 높고, 구조가 복잡해 신규 개발자가 진입하기 어렵다.
• Spring Boot 생태계의 압도적인 성장과 마이크로서비스 아키텍처의 대중화로 인해 입지가 약해졌다.
• 결정적으로, 2020년 OSGi Alliance가 해체되면서 기술적 진보가 사실상 정지되었다.
• 현재는 Eclipse Foundation 산하 OSGi Working Group이 사양을 유지하고 있으나,
  신규 기능 도입이나 활발한 커뮤니티 활동은 예전 같지 않다.

결론적으로, 현 OSGI 프레임워크 자체의 버전 업그레이드는 불가능한 상황이라 봐야한다.

앞으로는 더욱 더 많은 장비들이 들어오고 업그레이드가 되는것은 불가피한 상황이다.

그렇다 보니, 프레임워크를 계속 가지고 가는 것이 맞는것인가.. 의문이 들기 시작했다.

 

또한 Eclipse가 아닌 Intellij를 쓰는 방향으로 바뀌고 있는 상황인것은 대부분의 개발자들은 공감하는 부분일것이다.

 

가장 큰 한계는 바로 현재 사용되는 다양한 기술들오 대체가 가능하다는것이다.

• Spring boot나 Spring FrameWork의 기술
• Docker & KuberNetes 기술

---

🧑‍💻 인프라 과장님과의 대화 – 컨테이너를 알게 되다

개발팀의 분위기는 그렇게 흘렀지만, 인프라팀 과장님과의 대화를 통해 또 다른 배움을 얻을 수 있었다.

그 과장님과의 회의에서 처음으로 Docker와 Kubernetes라는 말을 들었다.
당시에는 정말 도커가 뭔지도, 쿠버네티스가 뭔지도 모르는 바보였다.

하지만 회의 중 약 1~2시간 동안 기술 이야기를 들으며 관심이 생겼고,
이후 따로 커피를 마시며 컨테이너 기술에 대해 이것저것 물어보았다.

결국 하나의 가능성이 떠올랐다.

---

🐳 컨테이너 기술의 대두 – OSGi를 대체할 수 있을까?

최근 Docker, Kubernetes, Spring Boot로 OSGi의 기술을 해결할 수 있게 되었다.

모듈 격리	번들 단위 ClassLoader	서비스별 컨테이너 분리
핫디플로이	번들 동적 로딩	롤링 업데이트, Canary 배포
운영 확장성	번들 추가	Kubernetes 오토스케일링
배포	JAR + 번들 관리	컨테이너 이미지 배포

 

과거에는 OSGi가 유일한 선택지였다. 그래, 이것까지는 이해를 한다.

다만, 현재는 컨테이너 기술과 마이크로서비스 설계로 동일한 문제를 더 유연하게 해결할 수 있게 되었다.

따라서,이 이상의 OSGI에 대한 공부나 조사는 불필요하다는것이 내 결론이다.

---

😮‍💨 그런데 왜 그렇게 싫어했을까?

솔직히 아직도 의문이다.

• 왜 그 좋은 아키텍처 개선안을 거부한 걸까?
• 왜 도입을 미루는 걸까?
• 왜 더 이상 누구도 책임지지 않는 오래된 프레임워크를 붙잡고 있는 걸까?
• 또한 아키텍처 변화는 그렇다 쳐도 왜 기본적인 문제 중 하나인 분산 수집에 대한 변화는 거부한것일까?

내가 뭘 몰라서 그럴 수도 있지만, 현재 내가 아는 OSGi는 거기까지였다.
그래서 나는 오히려 그 한계를 통해 새로운 대안을 발견할 수 있었다.

---

✅ 결론 – 늦었지만, 그래도 깨달음은 소중하다

어쩌면 조금만 더 일찍 도커와 쿠버네티스, 그리고 스프링 기반의 모듈화 설계에 대해 알았더라면,
더 적극적으로 제안하고, 설득하고, 뭔가 다른 길을 만들 수 있지 않았을까 하는 생각도 든다.

하지만 이미 회사를 떠났고, 이제는 그때의 경험을 바탕으로 더 나은 시스템 설계와 선택을 할 수 있게 되었다.

기술은 결국 배우고 나서 더 나은 방향을 찾는 것이 아닐까.

 

---

다음 포스팅에서는 실제로 Spring + Docker 환경에서 어떻게 모듈화를 구성할 수 있을지를 고민해보려 한다.

이와 더불어 Docker 책도 하나 샀다. (정리 예정)
또는 OSGi에서 마이그레이션할 때 고려할 점에 대해 정리해보려고 한다.

전직장에게 하고 싶은 말이 있다면....

지금이라도 늦지 않았으니 눈에 보이는 UI나 변경하는 어리석은 일을 조금 미루었으면 한다.

또한 스프링 + 컨테이너 개발로써 쉬운 변화부터 시작해보기를 바란다고 말하고 싶다.

 

뭐.. 그래봤자.. 그렇게 말하고 있던 사람이 거부 당하고 퇴사를 해버렸으니... 

이렇게 써봤자 푸념일 뿐.. ㅎㅎ