라이선스를 몇 개 사야 할까? (Arm 플로팅 vs UBL 가격 정책 비교)

mdstech
4시간 전
3분 분량

라이선스를 몇 개 사야 하죠?

플로팅 라이선스와 UBL(User-Based License)은 공유 방식과 병렬 사용에 있어서 라이선스를 소비하는 방식이 다릅니다. UBL은 플로팅 대비 하드웨어 코어/메모리를 더 적극적으로 활용하게 설계되어, 비용을 크게 늘리지 않으면서도 성능을 끌어올리는 방향을 목표로 합니다.

다만 동작 방식이 다르므로 필요 라이선스 수를 계산하는 방식도 달라져야 합니다.

이 글에서는 플로팅 라이선스에서 어떤 요인들이 라이선스 수를 좌우하는지 먼저 설명한 뒤, 플로팅과 비교하여 UBL이 몇 개 필요할지 산정해 보도록 하겠습니다. (시간이 없는 분들은 결론만 보셔도 됩니다.)

최근 개발 트렌드

요즘 개발팀들은 빌드/시뮬레이션을 최대한 빨리하는 것에 올인합니다. 이유는 간단합니다.

개발자 피드백이 빨라져 컨택스트 스위칭 없이, 반복 개발이 빨라짐
통합이 쉬워지고 에러를 빨리 발견
회귀 테스트를 자주/빠르게 돌려 문제를 즉시 감지
처리량(throughput) 증가
개발자가 기다리는 시간이 줄어들어 생산성이 증가함

이는 멀티코어·대용량 메모리 호스트에서 빌드/테스트를 병렬 처리하여 코어를 꽉 채울 때 나오는 속도입니다. 호스트는 물리 서버일 수도 있지만, 최근에는 클라우드 가상 서버가 많아지는 추세입니다.

그런데 클라우드는 시간 과금이므로, 라이선스 대기 때문에 코어가 유휴 상태가 되면 비용이 그대로 새어 나가게 됩니다.

특히 Arm Compiler에서 플로팅 vs UBL 비용 차이가 가장 크게 나타나므로 Arm Compiler 중심으로 설명하고, 마지막에 다른 도구/모델에도 다뤄보겠습니다.

플로팅 라이선스: 인원이 늘면 계산이 복잡해짐

가정: 개발자 1명당 16코어 PC를 쓰고, 빌드는 16코어를 최대한 사용할 수 있도록 병렬화되어 있음.

개발자 1명이 병목 없이 16코어를 다 쓰려면 라이선스 16개가 필요합니다. 더 적으면 컴파일이 라이선스 대기열에 걸려 코어를 다 쓰지 못하고 빌드가 느려집니다.
개발자 2명이 라이선스 16개 풀을 공유하면, 둘이 동시에 빌드할 때, 충돌이 발생합니다. 빌드 수행이 전체 시간의 5%라고 가정하면 대략 충돌 6% / 빌드 시간 3% 정도 증가할 것으로 추정합니다.
인원이 늘면 충돌이 크게 늘어납니다. (빌드 수행 동일하게 5% 가정)
- 4명: 충돌 15% 증가, 빌드 8% 느려짐
- 8명: 충돌 35% 증가, 빌드 25% 느려짐
- 16명: 충돌 75% 증가, 빌드 2배 이상(100%+) 느려질 수 있음
- 32명: 사실상 어려움(다른 빌드가 완료되기도 전에 빌드가 시작됨). 라이선스 재시도 트래픽으로 네트워크 부담이 증가, 결국 라이선스 서버에 장애 발생

사용률이 더 낮은(2%) 경우를 가정해도 16명/32명 규모에서 충돌과 지연이 꽤 커질 수 있습니다.

정리하면, 플로팅은 비용이 개발자 수와는 별개로 더 많이 들 수 있고, 변수와 랜덤성이 많아 산정이 어렵습니다. 인원 증가, 빌드 병렬화 개선, 더 많은 코어/메모리의 신규 서버 도입 같은 환경 개선에 따라, 필요한 라이선스 수를 더 늘릴 수 있습니다. (서버가 좋아질수록 라이선스를 더 필요로 합니다.)

UBL: 하나의 원칙, 개발자 수 = 라이선스 수

UBL은 기본적으로 필요한 라이선스 수 = 개발자 수입니다.

항상 코어를 최대로 활용하여 빌드할 수 있습니다. 라이선스 때문에 코어가 유휴 상태가 되거나 성능이 떨어지는 일이 없습니다. 빌드를 더 병렬화하거나 서버 코어를 늘려도 필요한 라이선스 수는 변하지 않습니다.

다만, 라이선스가 최소 7일 로컬 캐시되기 때문에 예외적으로 고려할 점이 있습니다.

가끔만 빌드하는 라이트 유저라도 라이선스 1개는 그대로 필요

플로팅 라이선스는 이런 상황을 빌드 속도가 느려지는 대가로 수용할 수 있지만, UBL은 빌드 거부를 피하려면 추가(정규 또는 단기) 라이선스를 마련하는 편이 안전합니다.

그러므로 이러한 현실을 고려하여 플로팅 대비 총비용이 증가하지 않을 수 있도록 가격 정책에 반영했습니다.

다른 툴과 모델들 (실행 시간과 라이선스 소비 방식의 차이)

Arm Compiler는 라이선스를 즉시 확보하지 못하더라도 작업이 곧바로 실패하지 않고 대기(Queue) 상태로 전환됩니다. 이는 컴파일러의 개별 실행 시간이 평균적으로 수 초 이내로 매우 짧아, 라이선스 대기 시간이 전체 빌드 시간에 미치는 영향이 제한적이기 때문입니다.

반면, 다른 개발 도구나 모델은 실행 시간이 수 분에서 길게는 수 시간까지 소요되는 경우가 많아, 라이선스 확보 시점까지 작업을 대기 상태로 유지하는 방식은 효용성이 떨어집니다. 이러한 특성으로 인해 Arm Compiler를 제외한 대부분의 제품군에서는 빌드 거부나 병목 발생을 방지하기 위해, 실제 사용자 수에 상응하는 충분한 라이선스를 사전에 확보하는 것이 사실상 필수 요건으로 간주합니다.

이와 달리 Arm Compiler는 성능 저하와 일정 수준의 지연을 감수하는 조건하에서, 플로팅 라이선스 수를 제한하여 운영할 수 있는 유일한 도구라고 할 수 있습니다.

한편, Arm 모델(Fast Models, Performance Models)은 병렬 실행 시 여러 개의 플로팅 라이선스를 동시에 소비한다는 점에서 Arm Compiler와 유사한 특성을 보입니다. 이로 인해 필요한 플로팅 라이선스 수량을 사전에 정확히 산정하는 것은 쉽지 않으며, 하드웨어 자원을 최대한 활용하고 시뮬레이션 시간을 최소화하려는 경우 상당한 수의 플로팅 라이선스가 요구될 수 있습니다.

디버거의 경우에는 플로팅 라이선스와 UBL간의 동작 방식 차이가 상대적으로 크지 않습니다. 디버깅 작업은 실행 시간이 길기 때문에 여러 개발자가 플로팅 라이선스를 효율적으로 공유하기 어렵고, 병렬 실행을 통해 얻을 수 있는 성능상의 이점 또한 거의 없습니다.

이러한 특성으로 인해 디버거 환경에서는 플로팅 라이선스와 UBL이 본질적으로 유사한 운영 형태를 가지며, 빌드 거부나 작업 중단을 방지하기 위해 충분한 수량의 라이선스를 확보하는 것이 핵심적인 운영 요건이 됩니다. 성능 저하를 감수하는 방식으로 라이선스 사용을 제한하는 운영은 사실상 적용이 어렵습니다. 이러한 특성은 Socrates를 포함한 Arm의 기타 제품군에도 동일하게 적용됩니다.

결론

플로팅의 한계: 동시에 빌드할 파일이 많을수록 라이선스를 더 사야 합니다. 라이선스가 부족하면 아무리 좋은 PC라도 자원을 100% 활용하지 못하게 되고 빌드 시간이 지연됩니다.
UBL의 장점: 한 번에 수많은 파일을 처리해도 추가 라이선스가 필요 없습니다. 어떤 환경에서든 PC 자원을 최대한 활용해 빌드 시간을 단축합니다.
결론: 장비가 좋아지고 작업량이 늘어날수록, 수량 산정이 복잡한 플로팅보다 사용자 수만 맞추면 되는 UBL이 더 효율적이고 경제적입니다.