제137회 정보관리기술사 4교시 참고답안
1. BPFdoor(Berkeley Packet Filter door) 악성코드
가. BPFdoor의 개념 및 기존 백도어 방식과의 차이점
1. 개념
BPFdoor는 리눅스(Linux) 시스템을 대상으로 하는 고도로 은밀한(Stealthy) 백도어 악성코드입니다. 이름에서 알 수 있듯이, 이는 리눅스 커널의 BPF(Berkeley Packet Filter) 기능을 악용합니다. BPF는 네트워크 패킷을 운영체제(OS)의 방화벽(iptables 등)보다 더 낮은 커널 레벨에서 필터링하고 처리할 수 있는 강력한 도구입니다.
BPFdoor는 이 BPF를 이용해 네트워크 트래픽을 감시하다가, 공격자가 보낸 특정한 '매직 패킷(Magic Packet)'이 감지되면, 방화벽 규칙을 우회하여 공격자에게 백도어(리버스 셸)를 열어주는 방식으로 동작합니다.
2. 기존 백도어 방식과의 차이점
| 특징 | 기존 백도어 (예: Port-opening Backdoor) | BPFdoor |
|---|---|---|
| 탐지 방식 | - 특정 포트(Port)를 열고 대기 (Listening). - 'netstat' 등의 명령어로 쉽게 탐지 가능. - 디스크에 실행 파일이 존재함. |
- 포트를 열지 않음 (Portless). - BPF를 이용해 모든 패킷을 '수동적(Passive)'으로 감시. - 'netstat'으로 탐지 불가. |
| 은닉 수준 | - 디스크에 악성 파일(Binary)이 존재. - 비교적 탐지가 용이함 (AV, HIDS) |
- In-Memory (Fileless) 방식으로 동작 가능. - 디스크에 흔적을 최소화하고 메모리에서만 실행. - 커널 레벨에서 동작하여 탐지가 매우 어려움. |
| 방화벽 관계 | - 방화벽(iptables, UFW)에서 해당 포트를 차단하면 무력화됨. | - BPF는 방화벽보다 먼저(낮은 레벨에서) 패킷을 수신. - 방화벽 규칙과 상관없이 매직 패킷을 감지하고 동작 가능. |
나. BPFdoor의 위협 요소와 기업 시스템에 미치는 영향
- 은밀한 장기 잠복 (APT): BPFdoor는 탐지가 극도로 어렵기 때문에, 공격자가 시스템에 침투한 후 수개월에서 수년간 발각되지 않고 잠복하며 지속적인 위협(APT)을 가할 수 있습니다.
- 방화벽 무력화: 기업이 신뢰하는 경계 보안 솔루션(방화벽)을 완벽하게 우회합니다. 방화벽 로그에는 공격자의 접속 시도가 남지 않아 보안 관제(SIEM)를 무력화시킵니다.
- 완전한 시스템 장악: 백도어가 활성화되면(리버스 셸 연결), 공격자는 해당 서버에 대한 루트(Root) 권한을 획득하여 모든 데이터를 유출, 변조, 삭제할 수 있습니다.
- 내부망 확산 (Lateral Movement): 공격자는 BPFdoor로 장악한 서버를 거점으로 삼아, 신뢰할 수 있는 내부 IP로 위장하여 다른 내부 중요 서버(DB서버, 인증서버)로 횡적 이동 공격을 수행합니다.
다. BPFdoor 위협 대응 방안
| 구분 | 대응 방안 | 세부 내용 |
|---|---|---|
| 기술적 방안 | BPF 사용 모니터링 및 제한 | - (최신 커널) BPF 사용 권한을 제한하고, 비정상적인 BPF 프로그램이 로드되는지 모니터링. - eBPF 기반의 보안 솔루션(예: Cilium)을 도입하여 BPF 행위 감시. |
| 메모리 포렌식 및 EDR | - 디스크 기반 AV가 아닌, 메모리(RAM)를 직접 스캔하여 비정상적인 프로세스나 커널 모듈을 탐지. - EDR(Endpoint Detection and Response) 솔루션을 통해 의심스러운 시스템 콜(Syscall)이나 네트워크 행위를 탐지. |
|
| 네트워크 트래픽 심층 분석 (DPI) | - 방화벽에서 감지 못하는 비정상적인 프로토콜 사용이나 '매직 패킷'의 고유 패턴을 탐지할 수 있는 NIDS/NTA 솔루션 활용.||
| 관리적 방안 | 최신 보안 패치 및 커널 업데이트 | - BPFdoor가 악용하는 커널 취약점이나 BPF 관련 취약점이 패치된 최신 리눅스 커널 버전을 유지. |
| 위협 인텔리전스(CTI) 활용 | - BPFdoor의 '매직 패킷' 시그니처, C&C 서버 IP 등 최신 침해지표(IoC)를 CTI로부터 구독하여, 침입 탐지 시스템에 즉시 반영. |
2. 벡터 데이터베이스(Vector Database)의 효율적 검색 (HNSW, IVF)
벡터 데이터베이스는 텍스트, 이미지 등의 비정형 데이터를 고차원의 벡터(Vector Embedding)로 변환하여 저장합니다. 이때 효율적인 검색은 '유사한 벡터'를 빠르게 찾는 것(ANN: 근사 근접 이웃 검색)이며, HNSW와 IVF는 이를 위한 대표적인 인덱싱 알고리즘입니다.
1. IVF (Inverted File Index) - 역파일 인덱스
가. 개념
IVF는 전체 벡터 공간을 K-Means 클러스터링과 같은 기법을 사용하여 여러 개의 작은 구역(Voronoi Cell)으로 미리 분할(Partitioning)하는 방식입니다. 각 구역의 중심점을 '센트로이드(Centroid)'라고 합니다.
나. 동작 원리
- [인덱싱]
- 1. K-Means 알고리즘으로 전체 벡터 데이터의 중심점(센트로이드) k개를 찾습니다. (예: k=100)
- 2. 모든 벡터는 자신과 가장 가까운 센트로이드가 대표하는 '클러스터(버킷)'에 할당되어 저장됩니다.
- 3. (Inverted File) '센트로이드 ID'를 Key로, 해당 클러스터에 속한 '벡터 ID 목록'을 Value로 하는 역파일(맵)을 생성합니다.
- [검색]
- 1. 사용자 질의(Query) 벡터가 들어오면, 이 벡터와 가장 가까운 센트로이드 n개(예: n=5)를 먼저 찾습니다.
- 2. 전체 100만 개 벡터를 모두 비교하는 대신, 질의 벡터와 가장 가까운 5개 클러스터에 속한 벡터들(예: 5만 개)하고만 거리를 비교(Exhaustive Search)합니다.
- 3. 이를 통해 검색 범위를 획기적으로 축소하여(Pruning) 속도를 높입니다.
2. HNSW (Hierarchical Navigable Small World) - 계층적 그래프
가. 개념
HNSW는 벡터 데이터를 '작은 세상(Small World)' 그래프(적은 링크로도 모든 노드에 빠르게 도달)로 연결하고, 이를 여러 계층(Hierarchical)으로 구성하여 탐색 속도를 극대화하는 방식입니다. (IVF보다 정확도와 속도가 우수하여 널리 사용됨)
나. 동작 원리
- [인덱싱] (계층적 그래프 구축)
- 1. 벡터 데이터(노드)를 무작위로 여러 계층(Layer)에 배분합니다. (Layer 0이 가장 촘촘하고, 상위 Layer로 갈수록 노드 수가 적음)
- 2. 각 노드는 같은 계층 내에서 자신과 '가까운' 이웃 노드들과 링크(Edge)를 맺습니다. (Small World 그래프 형성)
- [검색]
- 1. 검색은 항상 가장 상위 계층(Layer N, 가장 성긴)의 임의의 노드(진입점)에서 시작합니다.
- 2. 현재 계층에서 질의 벡터와 가장 가까운 이웃 노드를 탐욕적으로(Greedy) 따라 이동하며, 더 이상 가까운 노드가 없을 때까지 탐색합니다. (지역 최적점 도달)
- 3. 해당 노드에서 한 단계 아래 계층(Layer N-1)으로 내려와, 다시 가장 가까운 이웃을 따라 탐색을 반복합니다.
- 4. 이 과정을 가장 하위 계층(Layer 0, 원본 데이터)에 도달할 때까지 반복하여 최종적으로 가장 근접한 벡터(결과)를 찾습니다.
- (마치 고속도로(상위 계층)로 빠르게 이동한 뒤, 국도(하위 계층)를 통해 목적지에 접근하는 것과 유사)
3. 쿠버네티스 (Kubernetes)
가. 쿠버네티스의 개념 및 특징
1. 개념
쿠버네티스(Kubernetes, K8s)는 컨테이너화된 애플리케이션을 대규모 클러스터 환경에서 자동으로 배포, 확장(Scaling), 관리(운영)하기 위한 오픈소스 컨테이너 오케스트레이션(Orchestration) 플랫폼입니다.
이는 MSA(Microservice Architecture)로 개발된 복잡한 애플리케이션들이 여러 호스트(서버)에 분산되어 동작할 때, 이들의 상태를 관리하고 장애 시 자동 복구하는 등 복잡한 운영 작업을 자동화해주는 '컨테이너 관제탑' 역할을 합니다.
2. 특징
- 자동화된 롤아웃 및 롤백 (Automated Rollouts): '선언적(Declarative)' 설정(YAML 파일)을 통해 원하는 상태를 정의하면, 쿠버네티스가 현재 상태를 모니터링하여 자동으로 배포를 수행하고, 문제 발생 시 이전 버전으로 롤백합니다.
- 자동 확장 (Auto-Scaling): CPU 사용률 등 트래픽 부하에 따라 컨테이너(Pod)의 개수를 자동으로 늘리거나(Scale-out) 줄여(Scale-in) 자원을 효율적으로 사용합니다. (HPA)
- 자가 치유 (Self-Healing): 동작이 멈춘 컨테이너나 응답이 없는 노드(서버)를 감지하면, 자동으로 컨테이너를 재시작하거나 다른 정상 노드에 재배치하여 서비스 연속성을 보장합니다.
- 서비스 디스커버리 및 로드 밸런싱: 여러 개의 컨테이너(Pod)에 대해 고유한 DNS 이름을 부여하고(서비스 디스커버리), 이들 간의 트래픽을 자동으로 분산(Load Balancing)합니다.
- 이식성 (Portability): 온프레미스(사내구축형) 환경이든, 퍼블릭 클라우드(AWS, GCP, Azure) 환경이든 관계없이 동일하게 애플리케이션을 배포하고 운영할 수 있습니다.
나. 쿠버네티스의 주요 컴포넌트
쿠버네티스 클러스터는 전체를 관리하는 '컨트롤 플레인(마스터 노드)'과 실제 작업을 수행하는 '워커 노드'로 구성됩니다.
| 구분 | 컴포넌트 | 핵심 기능 |
|---|---|---|
| 컨트롤 플레인 (Control Plane / Master) |
kube-apiserver | - K8s의 두뇌(Front-end). 모든 컴포넌트와 사용자의 명령(kubectl)을 받는 유일한 창구(API). - 모든 상태를 'etcd'에 저장/조회. |
| etcd | - 클러스터의 '상태 저장소'. 모든 설정 정보, 리소스 상태를 저장하는 Key-Value DB. - (매우 중요, 고가용성 필수) |
|
| kube-scheduler | - 새로 생성된 파드(Pod)를 어느 워커 노드에 배치(할당)할지 결정. (리소스, 정책 고려) | |
| kube-controller-manager | - (레플리카 컨트롤러, 노드 컨트롤러 등) 클러스터의 '현재 상태'가 '원하는 상태'와 일치하도록 지속적으로 모니터링하고 조율하는 역할.||
| 워커 노드 (Worker Node / Data Plane) |
kubelet | - 각 노드의 '에이전트'. API서버의 명령을 받아, 컨테이너 런타임을 통해 파드(컨테이너)를 실행/관리. - 노드와 파드의 상태(Health Check)를 API서버에 보고. |
| kube-proxy | - 노드 내의 네트워크 규칙(iptables 등)을 관리. - 파드 간 통신, 외부 서비스로의 로드 밸런싱을 담당. |
|
| Container Runtime | - (예: Docker, containerd) - 컨테이너 이미지를 다운로드하고 실제로 컨테이너를 실행하는 엔진. |
다. HPA (Horizontal Pod Autoscaler)
HPA는 쿠버네티스의 핵심 자동 확장(Auto-Scaling) 기능입니다. 이는 부하가 증가할 때 서버(VM) 자체를 늘리는 수직 확장(VPA)과 달리, 동일한 파드(Pod)의 복제본(Replica) 개수를 수평적으로(Horizontally) 늘리거나 줄이는 방식입니다.
- 동작 원리:
- [1단계] 모니터링: HPA 컨트롤러는 메트릭 서버(Metrics Server)를 통해 파드들의 리소스 사용률(예: CPU, 메모리)을 주기적으로 수집합니다.
- [2단계] 목표 설정: 사용자는 HPA 설정에 '목표 CPU 사용률 80%', '파드 최소 3개/최대 10개'와 같이 원하는 상태를 선언합니다.
- [3단계] 계산: HPA는 현재 파드들의 평균 CPU 사용률이 90%로 목표치(80%)를 초과한 것을 감지합니다.
- [4단계] 확장 (Scale-Out): HPA는 현재 파드 개수(예: 3개)를 늘려야 한다고 판단하고, 디플로이먼트(Deployment)의 복제본(Replica) 개수를 자동으로 상향 조정합니다. (예: 4개로 변경)
- [5단계] 축소 (Scale-In): 반대로 부하가 줄어 평균 사용률이 30%가 되면, 복제본 개수를 다시 3개로 줄여 자원을 회수합니다.
4. UML 행위 다이어그램 (Behavior Diagram)
UML의 행위 다이어그램은 시스템이 '어떻게(How)' 동작하는지, 즉 시간의 흐름에 따른 시스템의 동적인(Dynamic) 측면을 모델링하는 데 사용됩니다. 정적(Static)인 구조 다이어그램(클래스 다이어그램 등)과 대비됩니다.
1. 활동 다이어그램 (Activity Diagram)
- 개념: 시스템 내부에서 수행되는 작업(Activity)의 처리 흐름(Flow)과 순서를 순서도(Flowchart)와 유사한 형태로 모델링하는 다이어그램입니다.
- 주요 목적:
- 복잡한 비즈니스 로직(업무 흐름)의 순서를 시각화합니다.
- 작업의 병렬 처리(Fork/Join), 조건부 분기(Decision/Merge)를 명확하게 표현합니다.
- 주요 구성요소:
- 액션/활동 (Action/Activity): 수행되는 작업 (둥근 모서리 사각형)
- 시작/종료 (Initial/Final Node): 흐름의 시작(●)과 끝(◉)
- 분기/병합 (Decision/Merge): 조건(◇)에 따라 흐름이 나뉘거나 합쳐짐.
- 포크/조인 (Fork/Join): 굵은 막대(Bar)로 표현하며, 여러 활동이 동시에 병렬로 수행(Fork)되거나, 병렬 수행이 완료되기를 기다렸다가(Join) 다음으로 진행.
- 스윔레인 (Swimlane): 각 활동을 수행하는 주체(부서, 액터)별로 영역을 나누어 표현.
2. 상태 다이어그램 (State Diagram / State Machine Diagram)
- 개념: 하나의 객체(Object)가 자신의 생명주기(Lifecycle) 동안 가질 수 있는 다양한 '상태(State)'와, 특정 '이벤트(Event)'에 의해 상태가 어떻게 '전이(Transition)'되는지를 모델링합니다.
- 주요 목적:
- 객체 지향 시스템에서 하나의 클래스(객체)가 가질 수 있는 복잡한 상태 변화를 명확하게 정의합니다.
- (예: '주문' 객체의 상태: 주문접수 → 결제대기 → 결제완료 → 배송중 → 배송완료/주문취소)
- 주요 구성요소:
- 상태 (State): 객체가 머무르는 조건 (둥근 모서리 사각형)
- 시작/종료 상태 (Initial/Final State): 시작(●)과 끝(X)
- 전이 (Transition): 하나의 상태에서 다른 상태로 이동하는 화살표.
- 이벤트 (Event): 상태 전이를 유발하는 사건 (예: '결제 버튼 클릭')
- 가드 (Guard): 전이가 발생하기 위해 만족해야 하는 조건 (예: [재고 있음])
3. 유스케이스 다이어그램 (Use-Case Diagram)
- 개념: 시스템의 전체적인 기능과 범위를 사용자(Actor)의 관점에서 모델링하는 다이어그램입니다.
- 주요 목적:
- 시스템이 무엇을(What) 하는지, 즉 시스템이 제공해야 할 주요 기능(유스케이스)들을 식별하고 목록화합니다.
- 이러한 기능을 누가(Actor) 사용하는지, 시스템과 사용자(외부 시스템 포함) 간의 상호작용(Interaction)과 경계(Boundary)를 정의합니다.
- 프로젝트 초기 단계에서 이해관계자 간의 의사소통과 요구사항 정의의 기초 자료로 활용됩니다.
- 주요 구성요소:
- 액터 (Actor): 시스템과 상호작용하는 사람 또는 외부 시스템 (졸라맨 모양)
- 유스케이스 (Use Case): 시스템이 액터에게 제공하는 기능 (타원형)
- 시스템 경계 (System Boundary): 시스템의 범위 (사각형 박스)
- 관계 (Relationship): (액터-유스케이스) 연관, (유스케이스 간) 포함(«include»), 확장(«extend»), (액터 간) 일반화(상속)
5. 유전 알고리즘 (Genetic Algorithm, GA)
가. 유전 알고리즘의 개념 및 절차
1. 개념
유전 알고리즘은 찰스 다윈의 자연선택(Natural Selection)과 적자생존(Survival of the Fittest)이라는 생물학적 진화론에 기반한 탐색(Search) 및 최적화(Optimization) 알고리즘입니다.
이는 해(Solution)의 후보 집단(Population)을 '염색체(Chromosome)'로 표현하고, 이 집단에 선택(Selection), 교차(Crossover), 변이(Mutation)와 같은 '진화 연산'을 반복적으로 적용하여, 세대를 거듭할수록 환경에 더 잘 적응하는(더 우수한) 해를 찾아가는 메타 휴리스틱 기법입니다.
2. 절차
- [1단계] 초기화 (Initialization):
- 문제의 해(Solution)를 표현하는 염색체(Chromosome) 구조를 정의합니다. (예: 이진 문자열 '01101...')
- 초기 집단(Population)을 무작위로 생성합니다. (예: 염색체 100개)
- [2단계] 적합도 평가 (Fitness Evaluation):
- 각 염색체(해)가 얼마나 우수한지를 적합도 함수(Fitness Function)를 이용해 정량적으로 평가(점수화)합니다. (이것이 최적화의 목표)
- [3단계] 선택 (Selection):
- 적합도 점수가 높은(우수한) 염색체들이 다음 세대에 살아남거나(Elite) 교차 대상(부모)으로 선택될 확률이 높아집니다. (예: 룰렛 휠 선택, 토너먼트 선택)
- [4단계] 교차 (Crossover):
- '선택'된 두 부모 염색체의 유전 정보(비트열)를 서로 교환하여 새로운 자손 염색체(Offspring)를 생성합니다. (예: 1점 교차, 2점 교차)
- 이는 전역적 탐색(Exploitation) 역할을 합니다.
- [5단계] 변이 (Mutation):
- 생성된 자손 염색체의 유전 정보 일부(특정 비트)를 아주 낮은 확률로 임의 변경합니다. (예: 0 → 1)
- 이는 지역 최적해(Local Optima)에 빠지는 것을 방지하고 다양성을 확보(Exploration)하는 역할을 합니다.
- [6단계] 종료 조건 검사 (Termination):
- 미리 정해진 세대(Generation) 수에 도달했거나, 만족할 만한 해를 찾았으면 종료하고 최적해를 반환합니다.
- 아니면, 생성된 새로운 집단으로 [2단계] 평가부터 다시 반복합니다.
나. 유전 알고리즘의 최적화 방법
유전 알고리즘의 성능은 '진화 연산자(Operator)'와 '파라미터'를 어떻게 설정(최적화)하느냐에 따라 크게 달라집니다.
| 단계 | 최적화 방법 (기법) | 설명 |
|---|---|---|
| 염색체 표현 | 해결 문제에 맞는 표현 | - 문제의 해를 어떻게 유전자로 표현할지 결정. (이진수, 정수, 실수, 순열(TSP) 등) |
| 적합도 함수 | 목적에 맞는 함수 설계 | - 성능에 가장 큰 영향을 미침. 해의 우수성을 정확히 변별(차등)할 수 있도록 설계.|
| 선택 (Selection) | 다양한 선택 기법 적용 | - 룰렛 휠 선택: 적합도에 비례하여 선택 확률을 부여. (우수 개체 편중 가능성) - 토너먼트 선택: 무작위로 k개를 뽑아 그중 가장 우수한 개체를 선택. (선택 압력 조절 용이) - 엘리트주의 (Elitism): 현 세대에서 가장 우수한 개체(엘리트)는 연산 없이 다음 세대로 무조건 생존시킴. (최적해 손실 방지) |
| 교차 (Crossover) | 다양한 교차 기법 적용 | - 1점/2점 교차: 1~2개의 절단점을 정해 유전자를 교환. - 균등 교차 (Uniform): 각 유전자를 확률적으로 부모 중 누구에게서 받을지 결정. (다양성 증대) |
| 변이 (Mutation) | 변이 확률(Pm) 조절 | - 변이 확률이 너무 높으면: 탐색이 무작위에 가까워져 수렴이 안 됨. - 변이 확률이 너무 낮으면: 다양성이 부족해져 지역 최적해(Local Optima)에 빠지기 쉬움. (보통 0.1~5%의 낮은 확률 사용) |
| 파라미터 튜닝 | 최적 파라미터 탐색 | - 집단 크기(Population Size), 교차 확률(Pc), 변이 확률(Pm)을 문제에 맞게 조절하여 수렴 속도와 해의 품질을 최적화. |
6. 소프트웨어 사업 대가산정 (소프트웨어 사업 대가산정 가이드 2025년 개정판 기준)
가. 소프트웨어 대가산정 가이드 목적
「소프트웨어 사업 대가산정 가이드」 (과기정통부 고시)의 목적은 소프트웨어(SW) 사업의 대가를 합리적이고 객관적으로 산정하기 위한 표준적인 방법과 기준을 제공하는 데 있습니다.
- 공정한 계약 환경 조성: 발주자가 SW의 가치를 정당하게 인정하고, "제값 받기" 문화를 정착시켜 불합리한 저가 발주를 방지합니다.
- 대가 현실화: 기술의 복잡성, 위험도, 창의성 등 SW의 무형적 가치를 대가에 반영하여 SW 산업의 발전을 도모합니다.
- 객관적 기준 제공: 발주자와 수주자 간의 대가 산정 분쟁을 예방하고, 예산 수립 및 계약의 근거 자료로 활용됩니다.
나. 인공지능(AI) 서비스 도입 사업유형과 사업비 산정 절차
2025년 개정판 가이드는 AI 기술의 특수성을 반영하여 AI 서비스 도입 사업의 대가 산정 기준을 새롭게 제시하고 있습니다.
1. AI 서비스 도입 사업유형
AI 도입 사업은 크게 3가지 유형으로 구분하며, 유형별로 대가 산정 방식이 다릅니다.
| 유형 | 개념 | 주요 활동 |
|---|---|---|
| 유형 1: AI 솔루션 도입 | - 상용(Commercial) AI 솔루션(SaaS, PaaS, API 등)을 구매하여 단순 연동하거나 최소한의 커스터마이징만 수행. | - 솔루션 라이선스 구매 - API 연동 개발 |
| 유형 2: AI 모델 커스터마이징 | - 상용 AI 솔루션(파운데이션 모델)을 기반으로, 기관의 고유 데이터를 추가 학습(파인튜닝)하거나 RAG 등을 적용하여 업무에 특화시킴. | - 데이터 준비/정제/가공 - 파인튜닝 / RAG 구축 - 프롬프트 엔지니어링 |
| 유형 3: AI 모델 자체 개발 | - 기관의 고유한 목적을 위해 AI 모델(알고리즘)을 처음부터(Scratch) 직접 개발하고 학습시킴. | - 모델 아키텍처 설계 - 모델 개발 및 학습 - 모델 평가 및 최적화 |
2. 사업비 산정 절차
AI 사업비는 '서비스 도입비'와 '운영비'로 구분하여 산정합니다.
[ 1. 서비스 도입비 산정 (구축/개발비) ]
- (유형 1: 솔루션 도입)
- 대가 = 상용 AI 솔루션 비용 + 커스터마이징 개발비 (기능점수(FP) 또는 투입공수(M/M) 방식 적용)
- (유형 2: 커스터마이징 / 유형 3: 자체 개발)
- 투입공수(M/M) 기반 방식을 원칙으로 함. (기능점수로 산정이 어려움)
- 대가 = (① AI 모델 개발비) + (② 응용 SW 개발비) + (③ 제경비) + (④ 기술료)
-
① AI 모델 개발비 = (데이터 준비 인력 공수 + 모델 학습/개발 인력 공수) × SW기술자 평균임금 ② 응용 SW 개발비 = (응용 서비스 개발 공수) × SW기술자 평균임금 (또는 FP 방식)
[ 2. 서비스 운영비 산정 ]
AI 서비스는 도입 후에도 지속적인 비용이 발생하므로, 운영비를 별도 산정해야 합니다.
- 주요 항목:
- (유형 1, 2) AI 솔루션 이용료: API 호출량, 토큰 사용량, 구독료 등 종량제(Pay-as-you-go) 또는 월정액 비용.
- 클라우드 인프라 비용: 모델 학습 및 추론을 위한 GPU/NPU 서버 이용료.
- 모델 유지보수 비용: 데이터 추가 학습, 모델 성능 모니터링, 재학습(Re-training)에 투입되는 운영 인력 공수 (M/M).
'정보관리기술사 > 2-4교시(서술)' 카테고리의 다른 글
| 제137회 정보관리기술사 3교시 기출문제&참고답안 (0) | 2025.11.05 |
|---|---|
| 제137회 정보관리기술사 2교시 기출문제&참고답안 (0) | 2025.11.05 |