정보시스템 하드웨어 규모산정 지침 (TTAK.KO-10.0292/R3)
1. 개요
가. 정의
정보시스템 구축 시 서버·스토리지·네트워크 등 하드웨어 용량을 업무량과 성능지표에 근거해 객관적·정량적으로 산정하기 위한 TTA(한국정보통신기술협회) 표준 지침으로, R3(2023.12 개정)는 클라우드·가상화 환경을 반영해 산정식과 참조표를 갱신했다.
규모산정(Sizing)은 "어느 정도 성능의 장비를, 얼마나 갖춰야 하는가"를 근거를 갖고 결정하는 활동이다. 이는 단순한 견적이 아니라, 장래의 업무량을 예측하고 그 업무량을 소화할 컴퓨팅 자원을 역산하는 수요-공급 정합 문제다. 경험이나 벤더 제안에만 의존하면 판단의 책임 소재가 불분명해지고 사업자 간 제안이 서로 비교 불가능해지는데, 이 지침은 공통의 계산 절차와 표준 성능지표(tpmC 등)를 규정함으로써 서로 다른 사업자·감리자·발주기관이 같은 방식으로 검증 가능한 근거를 만들도록 강제한다.
TTA 표준번호 TTAK.KO-10.0292는 여러 차례 개정되며 산정 대상과 지표를 확장해 왔다. 초기에는 서버 중심의 tpmC 산정이 골자였으나, 개정을 거치며 스토리지·네트워크·보안장비로 대상이 넓어지고, 가상화·클라우드 자원 공유를 전제로 한 보정 논리가 추가됐다. 즉 지침은 고정된 계산기가 아니라, 기술 환경 변화에 맞춰 산정 모델을 갱신해 온 살아있는 표준이라는 점을 이해하는 것이 중요하다.
이 지침의 성격을 요약하면 세 가지다. 첫째 객관성 — 산정 근거를 표준 지표와 계수로 명시해 누구든 되짚어 검증할 수 있다. 둘째 정량성 — 경험적 판단을 배제하고 업무량 수치에서 규모를 역산한다. 셋째 재현성 — 같은 입력이면 같은 결과가 나오도록 절차를 규정해, 사업자·감리자 간 결과를 비교 가능하게 한다. 이 세 성격이 공공 조달·감리 체계에서 지침이 사실상의 준거로 기능하는 근거다.
나. 등장 배경 및 필요성
하드웨어 산정은 양방향으로 실패한다. 과다 산정은 필요 이상의 장비를 사들여 예산과 상면(전산실 공간)·전력·냉방을 낭비하고, 감가상각이 끝나기도 전에 유휴 자원으로 남는다. 반대로 과소 산정은 피크 시 응답 지연·타임아웃·장애로 이어져 서비스 신뢰를 무너뜨리고, 급하게 증설하느라 추가 예산과 시스템 중단을 감수하게 만든다. 두 실패 모두 비용이지만, 특히 과소 산정은 개통 직후 대국민 서비스가 멈추는 형태로 드러나 사회적 파장이 크다.
특히 국민 세금이 투입되는 공공·대규모 사업에서는 "왜 이만큼의 장비가 필요한가"를 감리·예산심의·조달 과정에서 객관적으로 소명해야 한다. 예컨대 어느 공공기관이 차세대 시스템에 고성능 서버 수십 대를 제안했다면, 감리는 그 수량의 근거가 된 동시사용자 수·트랜잭션량·피크율·여유율을 요구한다. 표준 지침이 없으면 이 소명은 "벤더가 그렇게 제안했다"는 순환논리에 빠지지만, 지침이 있으면 산정식과 계수를 되짚어 결과의 타당성을 사후 검증할 수 있다.
또한 산정 근거의 표준화는 분쟁 예방 기능도 한다. 개통 후 성능 문제가 발생했을 때, 산정 시 반영한 업무량 가정과 실제 업무량을 비교하면 책임이 발주기관의 요구사항 부실인지, 사업자의 산정 오류인지, 예측 불가능한 수요 폭증인지 가릴 수 있다. 근거가 문서화돼 있어야 이런 사후 판단이 가능하다.
다. 규모산정 대상
산정 대상은 서버(WAS/DB/AP), 스토리지·백업, 네트워크(회선·스위치), 보안장비로 구분한다. 각 대상은 부하의 성격이 달라 지표도 다르다. 서버는 초당 처리량(TPS·tpmC)과 CPU·메모리를 중심으로, 스토리지는 데이터 총량·증가율과 IOPS(초당 입출력)를, 네트워크는 동시 세션과 대역폭(bps)을, 보안장비는 초당 처리 세션·스루풋을 기준으로 산정한다.
대상별로 지표가 다른 이유는 병목 지점이 다르기 때문이다. 트랜잭션이 아무리 빨라도 디스크 IOPS가 못 따라가면 DB가 병목이 되고, 서버가 여유로워도 회선 대역폭이 부족하면 대량 전송이 막힌다. 따라서 산정은 단일 지표가 아니라 자원별 병목을 함께 점검하는 다차원 작업이며, 어느 한 자원만 넉넉히 잡고 나머지를 방치하면 전체 시스템은 가장 약한 고리의 성능에 묶인다.
또한 대상은 계층(tier)별로 부하 성격이 달라진다는 점도 고려해야 한다. 3계층(웹-WAS-DB) 구조에서 웹 계층은 정적 처리·세션이 많아 수평 확장이 쉽고, WAS는 비즈니스 로직으로 CPU를 많이 쓰며, DB는 상태를 가진 단일 지점이라 수직 확장과 이중화 부담이 크다. 따라서 같은 트랜잭션이라도 계층마다 요구 자원이 다르게 산정되며, 특히 DB 계층은 확장이 어려워 산정 오류의 대가가 가장 크다.
2. 규모산정 절차와 전체 구조
flowchart LR
A["요구·업무량 분석"] --> B["산정 대상·방식 선정"]
B --> C["기준값·보정계수 적용"]
C --> D["규모 산출"]
D --> E["검증·조정"]
E -->|미달·과다| A
절차의 핵심 논리는 "수요를 먼저 정의하고, 그 수요를 장비 단위성능으로 나눈다" 는 것이다. 규모산정을 나눗셈으로 요약하면 필요 장비 = 총 요구 성능 ÷ 장비 1대 단위성능 이며, 이 식의 분자를 얼마나 정확히 세우느냐가 산정의 질을 좌우한다.
첫 단계인 업무량 분석에서는 동시사용자 수·트랜잭션(TPS)·데이터량과 피크(최대 부하) 시점을 파악한다. 규모산정은 평균이 아니라 피크를 견뎌야 하므로 피크 파악이 특히 중요하다. 예컨대 연말정산·수강신청·명절 예매처럼 특정 시점에 부하가 폭증하는 시스템은 평균 부하로 산정하면 반드시 실패한다. 이 단계에서 과거 로그·유사 시스템 통계·업무 담당자 인터뷰를 근거로 피크 시나리오를 구체적 수치로 확정한다.
다음으로 대상별 산정 방식을 정한다. 신규 대규모 시스템은 표준 성능지표 기반의 정량 산정이 적합하고, 기존 시스템 증설이나 유사 사례가 풍부한 경우는 참조 모델을 병행한다. 이어 성능·여유율·이중화·목표가용률 등 보정계수를 반영해 총 요구 성능을 부풀린 뒤 규모를 산출하고, 마지막에 벤치마크(BMT)·부하시험·타당성 검토로 검증·조정한다. 검증 결과 과다·과소가 드러나면 업무량 가정으로 되돌아가 재산정하는 반복 루프가 이 절차의 본질이다.
이 절차가 강조하는 것은 각 단계의 추적 가능성이다. 최종 장비 수량에서 거꾸로 업무량 프로파일까지 되짚어 갈 수 있어야 감리·심의에서 소명이 가능하다. 반대로 어느 단계의 가정이 문서화되지 않으면 그 지점이 검증의 사각지대가 되어, 개통 후 문제 발생 시 책임 규명이 불가능해진다. 따라서 절차의 산출물(업무량 프로파일·보정 근거표·산정 결과서)을 단계마다 남기는 것이 지침 준수의 실질적 요건이다.
| 단계 | 내용 | 산출물 |
|---|---|---|
| 업무량 분석 | 동시사용자·트랜잭션(TPS)·데이터량·피크 파악 | 업무량 프로파일 |
| 방식 선정 | 대상별 산정 방식(정량·참조) 결정 | 산정 방식서 |
| 보정 적용 | 성능·여유율·이중화·가용률 계수 반영 | 보정 근거표 |
| 산출·검증 | 규모 계산 후 타당성·벤치마크 검증 | 규모 산정 결과서 |
3. 규모산정 방식과 성능지표
flowchart TB
subgraph Demand["요구 성능(분자)"]
T1["기준 트랜잭션량"] --> M["총 요구 성능"]
T2["피크율"] --> M
T3["여유율·이중화·가용률"] --> M
end
subgraph Unit["단위 성능(분모)"]
U1["tpmC / OPS / SPECint"] --> U["장비 단위성능"]
end
M --> R["필요 장비 규모 = 요구성능 ÷ 단위성능"]
U --> R
산정 방식은 크게 세 가지 축으로 구성된다. 수치(정량) 기반은 TPC-C의 tpmC, 트랜잭션 처리량(OPS), SPEC의 SPECint 같은 표준 성능지표로 계산하는 방식이다. tpmC는 "분당 처리 가능한 신규 주문 트랜잭션 수"를 뜻하는 TPC-C 벤치마크 지표로, 서버 제조사가 공인 측정치를 공개하므로 이를 분모(단위성능)로 삼으면 근거가 명확해 대규모 신규 시스템에 적합하다. SPECint는 정수 연산 성능을 나타내 CPU 집약 업무 산정에 쓰인다.
참조 모델 기반은 유사한 기존 시스템의 실측치나 표준 구성을 비교·유추하는 방식이다. 신규 지표 산정이 어렵거나(예: 벤치마크가 없는 신기술 장비) 정량 산정 결과를 교차 검증해야 할 때 쓴다. 예를 들어 동급 기관의 동일 업무 시스템이 서버 4대로 운영 중이고 우리 업무량이 그 1.5배라면, 6대 안팎을 참조값으로 잡아 정량 산정치와 대조하는 식이다. 참조 모델은 현실 적합성이 높지만 참조 대상의 품질에 결과가 좌우되는 한계가 있다.
여기에 보정·여유율을 공통으로 적용해 현실의 불확실성을 흡수한다. 산출식의 골격은 필요 성능 = 기준 트랜잭션량 × 피크율 × 여유율 ÷ 장비 단위성능 이다. 구체 사례로, 평상시 초당 100 트랜잭션을 처리하는 시스템에서 피크 때 부하가 3배로 몰리고(피크율 3), CPU 사용률을 70%까지만 사용하도록 30% 여유(여유율 ≈ 1/0.7 ≈ 1.43)를 두면, 실제 확보해야 할 성능은 100 × 3 × 1.43 ≈ 429 TPS로 기준값의 4배를 웃돈다. 여기에 장애 대비 이중화(N+1)까지 더하면 확보 규모는 다시 늘어난다. 이렇게 계수를 명시적으로 곱해야 산정 근거가 투명해지고, 각 계수의 타당성을 개별적으로 심사할 수 있다.
| 방식 | 설명 | 적합 상황 |
|---|---|---|
| 수치(정량) 기반 | tpmC·OPS·SPECint 등 표준 성능지표로 계산 | 신규·대규모, 공인 근거 필요 |
| 참조 모델 기반 | 유사 시스템 사례·표준 구성과 비교 유추 | 증설·교차검증, 지표 산정 곤란 |
| 보정·여유율 | 피크율·증가율·이중화·목표가용성 반영 | 모든 산정에 공통 적용 |
보정계수를 얼마로 잡느냐는 트레이드오프의 핵심이다. 여유율을 크게 잡으면 안전하지만 과다 산정으로 흐르고, 작게 잡으면 경제적이지만 피크에 취약해진다. 지침은 이 계수를 자의적으로 정하지 않도록 업무 특성별 참조 범위와 근거 제시를 요구하며, 이것이 "감(感)에 의한 산정"과 "표준 산정"을 가르는 지점이다.
CPU·tpmC만이 아니라 메모리 산정도 별도로 중요하다. WAS는 동시 세션 수 × 세션당 힙 사용량으로 기본 메모리를 잡고, DB는 버퍼 캐시·정렬 영역·커넥션 풀을 합산해 산정한다. 메모리가 부족하면 스와핑·GC(가비지 컬렉션) 폭증으로 CPU가 남아도 응답이 급락하므로, "CPU는 넉넉한데 느린" 전형적 병목이 메모리 과소 산정에서 온다. 따라서 tpmC 기반 CPU 산정과 메모리 산정을 독립적으로 수행하고 교차 점검해야 한다.
여유율에는 피크 지속 시간이라는 변수도 숨어 있다. 순간적 스파이크는 큐잉·버퍼로 흡수할 수 있지만, 피크가 수십 분 이상 지속되면 자원이 실제로 그만큼 필요하다. 따라서 같은 피크율이라도 "짧고 뾰족한 부하"와 "길고 완만한 부하"는 요구 성능이 달라지며, 업무량 분석에서 부하의 형태(지속 시간·분포) 까지 파악해야 여유율을 합리적으로 결정할 수 있다.
4. 산정 실무 사례와 비교
정량 산정과 참조 산정은 배타적이지 않고 상호 보완적이다. 실무에서는 정량식으로 1차 규모를 뽑고, 참조 모델로 그 값이 상식적인 범위인지 교차 검증한 뒤, 최종적으로 BMT(벤치마크 테스트)로 실증하는 3단 구조를 흔히 쓴다. 세 방법의 결과가 크게 어긋나면 업무량 가정이나 계수 중 하나가 잘못된 것이므로 재검토 신호가 된다.
이 교차 검증이 중요한 까닭은 각 방법이 놓치는 오차가 서로 다르기 때문이다. 정량식은 계수 가정이 틀리면 조용히 크게 빗나가지만 현실 감각이 없고, 참조 모델은 현실적이되 참조 대상과 업무 특성이 다르면 왜곡된다. BMT는 가장 신뢰도가 높지만 시간·비용이 들고 실제 데이터 확보가 어렵다. 세 방법을 겹쳐 쓰면 한 방법의 오차를 다른 방법이 잡아내므로, 어느 하나에만 의존할 때보다 산정의 강건성이 높아진다.
구체 사례로 대민 포털을 생각해 보자. 평상시 동시접속 1만 명, 사용자당 초당 0.2 트랜잭션이면 기준 부하는 2,000 TPS다. 그러나 특정 정책 발표일에 접속이 5배로 몰린다면 피크율 5를 적용해 1만 TPS가 요구된다. 여기에 여유율 1.43과 무중단을 위한 이중화를 더하면 확보해야 할 성능은 2만 TPS를 넘어서고, 서버 1대의 단위성능이 tpmC 환산 일정 수준이라면 필요한 서버 대수가 산출된다. 이 계산이 없으면 "서버 몇 대면 충분하다"는 주장은 검증 불가능한 선언에 불과하다.
스토리지 산정은 서버와 논리가 다르다. 데이터 총량뿐 아니라 증가율과 IOPS를 함께 봐야 한다. 예컨대 초기 데이터 10TB에 연 30% 증가를 가정하면 3년 뒤 약 22TB가 필요하고, 여기에 백업·스냅샷·인덱스 오버헤드와 여유 공간(통상 20~30%)을 더해 실제 확보 용량을 잡는다. 동시에 트랜잭션이 요구하는 IOPS를 디스크 구성(SSD/HDD·RAID)이 감당하는지 별도로 확인해야, 용량은 충분한데 입출력이 병목이 되는 상황을 피한다.
증가율 가정은 복리로 누적되므로 작은 오차도 장기적으로 크게 벌어진다. 위 예에서 증가율을 30%가 아닌 50%로 잘못 낮잡으면 3년 뒤 실제 필요량은 약 34TB로 치솟아 산정치를 크게 초과한다. 따라서 스토리지는 서버보다 재산정·증설이 잦은 자원임을 전제로, 온라인 증설이 가능한 구조(스케일아웃 스토리지·볼륨 확장)를 함께 설계하는 것이 실무적이다. 이것이 서버는 초기에 넉넉히, 스토리지는 확장성 위주로 접근하는 이유다.
| 구분 | 서버 | 스토리지 | 네트워크 |
|---|---|---|---|
| 핵심 지표 | TPS·tpmC·SPECint | 총량·증가율·IOPS | 동시세션·대역폭 |
| 병목 요인 | CPU·메모리 | 용량·입출력 | 회선·스위치 |
| 여유 반영 | CPU 사용률 상한 | 여유 공간 20~30% | 피크 대역폭 |
공공 부문의 실제 감리 현장에서는 이 표의 각 항목마다 "가정값-근거-계산-결과"가 한 줄씩 맞아떨어지는지 점검한다. 예컨대 서버 산정에서 피크율 3의 근거가 과거 3년 트래픽 로그인지, 여유 공간 25%가 백업·인덱스 오버헤드를 반영한 값인지를 확인한다. 근거 없이 큰 계수를 넣으면 과다 산정으로 감액 조정되고, 반대로 성장률을 누락하면 조기 증설 위험으로 지적된다. 이처럼 지침은 산정을 감사 가능한 형태로 만들어 예산의 정당성을 확보한다.
세 자원의 산정 논리가 다른 이유는 앞서 짚은 병목의 위치가 다르기 때문이며, 실무적 함의는 "자원을 균형 있게 확보해야 한다"는 것이다. 어느 한 자원만 과투자하면 비용은 늘되 전체 성능은 최약 자원에 묶여 개선되지 않는다. 이 균형 감각이 규모산정을 단순 나눗셈이 아니라 설계 활동으로 만든다.
네트워크 산정 역시 단순 대역폭 곱셈으로 끝나지 않는다. 동시 세션 수, 세션당 평균/피크 트래픽, 보안장비(방화벽·IPS)의 세션 처리 한계를 함께 봐야 한다. 예컨대 대역폭은 여유로운데 방화벽의 동시 세션 테이블이 가득 차면 신규 접속이 거부되는데, 이는 회선을 늘려도 해결되지 않는 별도의 병목이다. 이처럼 각 자원의 "가장 먼저 고갈되는 한계값"을 식별하는 것이 정확한 산정의 요체다.
5. 심화: 클라우드·FinOps 시대의 사이징 변화
기술사 관점에서 주목할 최신 변화는 클라우드 전환이 사이징의 패러다임을 바꾸고 있다는 점이다. 온프레미스 시대의 사이징은 "미래 피크까지 견딜 장비를 초기에 다 사두는" 고정 확보(정점 대비 프로비저닝) 모델이었다. 그러나 온디맨드·오토스케일 환경에서는 평상시 최소 자원만 두고 부하가 오를 때 자동으로 늘리므로, 무게중심이 "정점 대비 고정 확보"에서 "탄력 확보 + 비용 최적화(FinOps)"로 옮겨간다.
그럼에도 규모산정 지침은 여전히 유효하며, 오히려 역할이 재정의된다. 오토스케일도 최소·최대 용량과 예산 상한을 정해야 폭주하는 비용을 막을 수 있고, 그 경계값을 정하려면 업무량 기반의 정량 근거가 필요하다. 예약 인스턴스(RI)·세이빙 플랜처럼 장기 약정으로 단가를 낮추는 결정도 "기저 부하가 얼마인가"라는 사이징 판단 위에 선다. 즉 클라우드는 사이징을 없앤 것이 아니라, 1회성 초기 산정에서 지속적 용량·비용 관리로 성격을 바꾼 것이다.
또한 컨테이너·쿠버네티스 환경에서는 파드의 requests/limits, HPA(수평 파드 오토스케일러)의 임계치 설정이 새로운 사이징 대상이 된다. requests를 너무 크게 잡으면 노드 자원이 낭비되고, 너무 작게 잡으면 OOM(메모리 부족)·스로틀링으로 성능이 무너진다. 결국 "요구 성능을 측정해 단위 자원으로 나눈다"는 지침의 근본 논리는 물리 서버에서 파드로 단위만 바뀌었을 뿐 그대로 작동한다.
실무 사례로, 대규모 이커머스는 평시 대비 대형 세일 당일의 부하가 수십 배로 뛰는 극단적 피크를 겪는다. 이들은 고정 확보로는 감당이 불가능해, 평시엔 최소 자원으로 운영하다 이벤트 전 예측 부하에 맞춰 사전 스케일업하고 오토스케일로 잔여 변동을 흡수한다. 이때도 "얼마까지 늘릴 것인가(최대 용량)"와 "예산 상한"은 사이징 계산으로 미리 정하며, 여기서 규모산정 지침의 논리가 클라우드 비용 통제의 뼈대로 재활용된다.
관측 가능성(Observability)의 발전은 사이징의 근거를 사전 예측에서 실측 기반 지속 보정으로 이동시킨다. APM·메트릭 수집으로 실제 부하를 상시 관찰하면, 산정 시 가정한 피크율·여유율이 현실과 맞는지 검증하고 다음 증설 판단에 반영할 수 있다. 이는 지침이 요구하는 "검증·조정" 루프를 운영 단계까지 연장한 것으로 볼 수 있다.
예상 출제 방향 측면에서, 하드웨어 규모산정은 "산정식과 계수를 정확히 서술"하는 단답형을 넘어 클라우드·오토스케일과의 관계, FinOps 관점의 비용 최적화, 가용성 설계와의 연계를 묻는 방향으로 심화될 가능성이 크다. 따라서 답안에서는 tpmC 산정식이라는 고전적 근거와, 탄력 확보·지속적 용량 관리라는 최신 흐름을 함께 엮어 서술하는 것이 고득점 전략이다. 지침의 존재 이유(객관적 근거 확보)를 온프레·클라우드를 관통하는 원리로 제시하면 설득력이 높아진다.
6. 고려사항 및 시사점
미래·성장 반영: 산정은 개통 시점의 스냅샷이 아니라 향후 3~5년의 데이터·사용자 증가를 포괄해야 한다. 성장률을 빼먹으면 조기 증설로 추가 비용과 중단이 발생하고, 과도하게 잡으면 초기 과투자가 된다. 성장 곡선의 근거(사업계획·과거 추세)를 명시하는 것이 관건이다.
가용성·이중화 설계와의 연계: 목표 가용률(예: 99.9%)은 곧 이중화·DR(재해복구) 용량을 결정하므로 사이징과 분리할 수 없다. 무중단을 요구하면 N+1 이상 여유 노드가 필요하고, 이는 확보 규모를 그만큼 키운다. 가용성 요구를 정량 목표로 먼저 확정한 뒤 사이징에 반영해야 한다.
검증 없는 산정의 위험: 계산식만으로 끝내지 말고 BMT·부하시험으로 실증해야 한다. 벤더 공인 tpmC는 이상적 조건의 값이라 실제 업무에서는 그대로 나오지 않는 경우가 많으므로, 실제 데이터·쿼리로 측정한 값과의 괴리를 보정해야 산정치가 신뢰를 얻는다.
클라우드·FinOps로의 전략 전환: 온프레-클라우드 혼합(하이브리드) 환경에서는 기저 부하는 온프레·RI로, 변동 부하는 온디맨드·오토스케일로 나누는 전략적 배치가 유효하다. 사이징은 이 배치의 경계를 정하는 근거가 되며, 초기 용량뿐 아니라 지속적 비용 최적화의 기준선으로 활용된다.
표준·감리 정합성: 공공사업이라면 산정 근거가 TTA 지침·감리 기준과 정합해야 예산심의·감리를 통과한다. 산정 방식·계수·참조 근거를 문서화해 사후 검증 가능성을 확보하는 것이 기술사가 챙겨야 할 실무 포인트다.
자원 균형과 계층별 확장성: CPU·메모리·IOPS·대역폭을 균형 있게 확보하되, DB처럼 수평 확장이 어려운 단일 지점은 초기부터 여유와 이중화를 넉넉히 잡아야 한다. 확장이 쉬운 계층과 어려운 계층을 구분해 여유율을 차등 적용하는 것이 비용 대비 효과가 크다.
지속 가능성·전력 효율(그린 IT): 최근 데이터센터는 전력·탄소 제약이 커져, 과다 산정은 예산뿐 아니라 전력·냉방·탄소 측면에서도 부담이다. 산정 시 성능당 전력(와트당 성능)과 PUE를 함께 고려해 지속 가능한 규모를 선택하는 관점이 요구된다.
불확실성 하의 의사결정: 미래 업무량은 본질적으로 예측이므로, 단일 시나리오가 아니라 낙관·기준·비관의 다중 시나리오로 산정하고 그 폭을 의사결정자에게 제시하는 것이 바람직하다. 클라우드의 탄력성은 이 불확실성을 흡수하는 수단이 되므로, 예측 신뢰도가 낮은 신규 서비스일수록 고정 확보보다 탄력 확보의 가치가 커진다.
참고자료
- 한국정보통신기술협회(TTA) 표준화 자료실: https://www.tta.or.kr
- TPC-C 벤치마크(tpmC) 공식 사이트: https://www.tpc.org/tpcc/
- SPEC(Standard Performance Evaluation Corporation): https://www.spec.org
한 줄 요약: TTAK.KO-10.0292/R3은 업무량 분석→방식 선정→보정 적용→산출·검증 절차로 HW 용량을 tpmC 등 표준 성능지표 기반으로 객관 산정하는 지침으로, 요구성능 = 기준량 × 피크율 × 여유율 ÷ 단위성능 논리로 과다·과소 산정을 막고 공공사업의 감리 근거를 제공하며, 클라우드·FinOps 시대에는 초기 용량 산정을 넘어 탄력 확보와 지속적 비용 최적화의 기준선으로 그 역할이 재정의된다.