언어 패러다임·타입·메모리 모델의 선택

1. 어떤 언어가 가장 빠른지가 첫 질문이 아닌 이유

장치 드라이버, 금융 규칙 엔진, 웹 API, 데이터 분석 코드는 실패 방식과 변경 속도가 다르다. 한 벤치마크에서 빠른 언어가 모든 시스템에서 좋은 선택은 아니다. 실행환경·타입 안전성·메모리 제어·동시성·생태계·운영 인력·장기 유지보수를 함께 본다.

문법의 기초는 이미 배웠다

앞의 값·변수·자료형·연산, 조건·반복·함수·스코프, 모듈·캡슐화·객체·인터페이스, 오류·예외·동시성에서 최소 문법을 배웠다. 이번 절은 같은 개념을 다시 정의하지 않고 요구에 따라 언어 기능을 선택하는 판단으로 확장한다.

실행환경의 제약은 앞 절에서 내려온다

임베디드 요구·실시간성·HW/SW 공동설계는 장치의 마감·메모리·전력·하드웨어 경계를 요구로 만들었다. 언어는 그 요구를 만족하도록 도구체인·ABI·메모리·동시성 기능을 제공해야 하며 언어 선호가 요구를 바꾸지는 않는다.

프로그래밍 언어 활용의 담당 경계

프로그래밍 언어 활용은 문제의 계산·상태·자원·안전·변경 요구에 맞춰 언어의 패러다임·타입 규칙·메모리와 동시성 모델을 선택하고 그 제약을 구현과 검증에 적용하는 활동이다.

문법 기능의 목록을 많이 아는 것보다 어떤 오류를 컴파일 시점·실행 시점·운영 통제로 잡을지 설명할 수 있어야 한다. 실제 코딩·빌드·패키징·API 구현은 다음 절이 담당한다.

언어 선택은 요구를 구현 규칙으로 내려보내는 과정이다

2. 패러다임은 문제를 분해하는 기본 방법을 바꾼다

절차형은 상태와 명령의 순서를 직접 표현하기 쉽고, 객체지향은 상태와 행동의 책임을 객체·인터페이스로 묶는다. 함수형 스타일은 불변 값과 함수 합성을 활용해 공유 상태를 줄이는 데 도움을 줄 수 있다. 선언형은 원하는 결과나 제약을 쓰고 실행 계획의 일부를 런타임·엔진에 맡긴다.

언어 이름을 패러다임 하나와 동일시하지 않는다

현대 언어는 여러 패러다임을 함께 지원하는 경우가 많다. Java에서 함수형 스타일을 쓸 수 있고 Python에서도 객체지향·함수형·절차형 스타일을 섞을 수 있다. 따라서 “객체지향 언어라서 유지보수성이 높다”처럼 이름만으로 품질을 단정하지 않고 실제 코드 구조와 팀 규칙을 본다.

패러다임 비교는 책임과 상태 관리 관점에서 한다

도메인 규칙과 장치 제어는 다른 표현을 요구할 수 있다

금액 계산은 불변 값과 명확한 도메인 타입이 유리할 수 있고, 레지스터를 순서대로 조작하는 드라이버는 저수준 메모리·명령 순서가 중요할 수 있다. 한 프로젝트 안에서도 모듈별 표현 전략이 다를 수 있으므로 경계를 명시한다.

3. 타입 시스템은 허용할 상태와 오류 발견 시점을 바꾼다

정적 타입은 많은 타입 불일치를 실행 전에 탐지할 수 있고, 동적 타입은 값의 타입을 실행 흐름에서 확인한다. 어느 방식도 논리 오류를 자동 제거하지 않는다. 중요한 것은 어떤 불가능한 상태를 표현하지 못하게 만들고 어떤 검사를 테스트·런타임으로 넘길지다.

PL-1: 둘 다 정수여도 같은 값이 아니다

userId=1001, amount=1001이 둘 다 정수형이면 함수 인자 순서를 바꿔도 기본 타입 검사는 통과할 수 있다. UserId, Money처럼 의미가 다른 도메인 타입을 분리하면 같은 비트 폭의 값도 잘못 섞이는 경로를 줄일 수 있다.

이를 학습용 호출 pay(사용자, 금액)으로 따라가 보자. 두 인자를 모두 정수로 받으면 사용자 값을 금액 자리에 넣어도 정수 1001이라는 사실은 같아 검사에서 구별하지 못한다. 이제 첫 자리는 UserId 값만, 둘째 자리는 Money 값만 받으며 두 타입 사이의 암묵적 변환은 금지한다고 계약을 정한다. 올바른 호출은 UserId로 포장한 사용자 값과 Money로 포장한 금액을 전달한다. 이미 포장한 두 값을 반대로 넘기면 첫 자리에서 Money와 UserId가 맞지 않아 실행 전에 거부하는 것이 기대 결과다. 숫자가 같으므로 타입도 같다는 답은 값과 의미 타입을 혼동한 것이므로 3. 타입 시스템은 허용할 상태와 오류 발견 시점을 바꾼다의 허용 상태로 돌아간다. 사용자의 권한이나 실제 잔액이 충분한지는 이 타입 검사로 확인되지 않으며 정적·동적 검사의 선택의 실행 검사와 연결해야 한다. 이 표기는 특정 언어의 실행 코드가 아니라 선언한 타입 계약의 동작 예다.

null·옵션·결과를 정상 상태와 분리한다

값이 없을 수 있는 상태, 실패할 수 있는 계산을 타입이나 명시적 반환 규칙으로 표현하면 호출자가 성공 경로만 가정하는 실수를 줄일 수 있다. 하지만 호출자가 오류 분기를 무시하거나 잘못 복구하면 타입만으로 업무 실패가 사라지지는 않는다.

정적·동적 검사의 선택

검사 위치를 옮기는 것이지 불확실성을 없애는 것은 아니다.

4. 메모리 관리는 수명·자원·실패 방식의 계약이다

수동 메모리 관리는 할당·해제 시점을 세밀하게 통제할 수 있지만 이중 해제·해제 후 사용·누수 위험을 개발자가 관리해야 한다. 가비지 컬렉션은 많은 객체 수명을 자동 처리하지만 힙 사용량과 런타임 정지 특성을 고려해야 한다. 소유권·대여 규칙을 컴파일러가 검사하는 방식은 일부 수명 오류를 실행 전에 막는 대신 언어 규칙에 맞는 설계가 필요하다.

자동 메모리 관리도 무제한 메모리를 주지 않는다

GC가 있는 언어도 참조가 계속 살아 있으면 메모리 사용량이 커질 수 있고, 대량 할당은 수집 비용과 지연을 만들 수 있다. 임베디드처럼 메모리 상한과 지연 상한이 중요한 환경에서는 할당 시점·풀 크기·최악 사용량을 요구와 함께 정한다.

PL-2: 1 KB 누수도 장시간 서비스에서는 누적된다

이 계산에서는 1 KB=1000바이트, 1 MB=1000 KB라는 십진 단위를 사용한다. 요청 한 번마다 1 KB가 회수되지 않고 초당 10개의 요청을 처리하면 초당 10KB, 한 시간에 약 36 MB, 하루에 약 864 MB가 누적된다. 작은 단위 누수라는 말만으로 운영 영향을 무시할 수 없다. 실제 할당기 오버헤드와 요청량은 별도 측정한다.

실시간 경로에서는 동적 할당 자체를 제한할 수 있다

마감시간이 엄격한 제어 루프에서는 실행 중 예측하기 어려운 할당·수집을 피하고 사전 할당된 버퍼나 풀을 사용할 수 있다. 그러나 사전 할당도 크기 산정 오류와 고갈 처리가 필요하므로 “동적 할당 없음=안전”으로 끝내지 않는다.

5. 동시성 메모리 모델은 여러 실행흐름이 값을 보는 규칙이다

여러 스레드가 같은 메모리를 읽고 쓸 때 소스 코드의 줄 순서만으로 다른 스레드가 관찰하는 순서를 단정할 수 없다. 컴파일러 최적화·CPU 실행·캐시·원자 연산·동기화 규칙이 언어와 플랫폼의 메모리 모델에 의해 제약된다.

happens-before는 언어별 정식 규칙을 확인해야 한다

일부 언어 명세는 동기화 동작 사이의 순서를 happens-before 관계로 정의하여 어떤 쓰기가 어떤 읽기보다 먼저 보장되는지 설명한다. 그러나 세부 규칙은 언어마다 다르므로 Java의 규칙을 C++·Rust 등에 그대로 옮기지 않는다. 따라서 이 절의 공통 설명만으로 특정 언어의 동작을 확정하지 않고 해당 언어·판본의 정식 규칙을 확인한다.

volatile 하나로 동시성 문제를 해결하지 않는다

volatile의 의미도 언어마다 다르며 원자성·상호배제·복합 연산의 일관성을 자동 보장한다고 가정할 수 없다. 공유 상태에는 해당 언어의 mutex·atomic·channel 등 정식 동시성 원시기능과 메모리 모델을 사용한다.

PL-3: count++는 하나의 원자 연산이라고 가정하지 않는다

증가 한 번을 읽기·계산·쓰기로 나눈 교육용 모형을 생각해 보자. 두 실행흐름이 각각 옛 값 10을 읽고 11을 계산한 뒤 둘 다 11을 쓰면, 두 번 증가시켰는데도 최종값은 11이다. 이처럼 갱신 하나가 사라지는 현상을 갱신 유실(lost update)이라고 한다. 읽기와 쓰기를 각각 원자적으로 수행해도 그 사이의 계산까지 한 번의 원자적 증가로 묶지 않으면 같은 문제가 생길 수 있다.

이 모형을 특정 언어의 허용 결과 전체로 읽지는 않는다. C++에서 같은 비원자 변수에 동기화 없이 충돌하는 접근이 일어나 data race가 성립하면 정의되지 않은 동작(undefined behavior)이므로 결과를 11 또는 12로 한정할 수 없다. Java의 volatile 필드도 읽기·쓰기의 가시성 규칙과 증가 전체의 원자성은 별개다. 실제 코드는 해당 언어의 원자적 증가 기능을 사용하거나 읽기부터 쓰기까지 같은 잠금으로 보호한다. 어떤 변수를 원자로 선언했는지와 어떤 연산을 한 덩어리로 수행했는지를 함께 확인해야 한다.

6. 실행환경과 상호운용성이 언어의 가능 범위를 정한다

기존 C ABI 드라이버를 호출해야 하는지, 브라우저·JVM·네이티브 바이너리 중 어디에서 실행하는지, 하드웨어 레지스터에 접근해야 하는지, 어떤 아키텍처와 운영체제를 지원하는지 확인한다. 언어 기능이 좋아도 목표 플랫폼의 안정된 도구체인과 라이브러리가 없으면 선택할 수 없다.

다음 표의 FFI(Foreign Function Interface)는 다른 언어로 만들어진 함수를 호출하는 연결을 가리킨다. 센서 모듈의 C 함수를 분석 언어에서 부르는 경우 함수 이름뿐 아니라 인자의 이진 배치·버퍼를 누가 해제하는지·오류 반환 규칙도 맞아야 한다. ABI는 앞 시스템 프로그래밍에서 배운 바이너리 규약을 재사용하고, 언어 사이 연결은 그 규약과 자원 수명 계약을 지키는지 확인한다.

언어 선택표는 요구에서 시작한다

벤치마크 숫자를 다른 실행환경에 그대로 옮기지 않는다

마이크로벤치마크가 측정한 CPU 시간, 실제 서비스의 I/O 지연, 런타임 정지, JIT 예열, 네트워크 비용은 서로 다른 조건이다. 같은 언어도 컴파일러·옵션·라이브러리·입력에 따라 결과가 바뀐다. 측정 환경과 목표 지표를 기록하고 실제 워크로드에 가까운 시험으로 확인한다.

PL-4: 계산이 두 배 빨라도 전체 응답시간은 거의 같을 수 있다

기존 요청이 CPU 10 ms + DB 90 ms로 총 100 ms라고 하자. 언어·컴파일러 변경으로 CPU가 5 ms가 되어도 총 시간은 약 95 ms다. CPU 부분은 2배 빨라졌지만 전체 응답시간은 5% 감소했다. 병목과 목표 지표를 먼저 본다.

팀과 운영의 비용도 기술 제약이다

문서·디버거·프로파일러·패키지 생태계, 채용·교육 가능성, 취약점 대응과 장기 지원을 비교한다. 낯선 언어가 이론적으로 안전해도 팀이 검증·운영할 역량과 계획이 없다면 즉시 위험이 될 수 있다. 반대로 익숙함만으로 노후 도구체인을 계속 선택하지 않는다.

공식 범위 연결 — 프로그래밍 언어 활용

프로그래밍 언어 활용에서는 문법 암기보다 요구에 맞는 패러다임·타입·메모리·동시성 모델을 선택하고 오류 가능성과 검증 방법까지 설명하는 범위를 다룬다. 다음 절의 코딩·빌드·패키징·API 구현이 이 선택을 실제 산출물로 옮긴다.

출처와 적용 경계

프로그래밍 언어·컴파일·런타임의 정의와 원자성·가시성·메모리 순서는 앞의 기초 설명과 연결한다. PL-3의 언어별 경계는 2026-10-06에 Java SE 25 JLS §17.4.5와 공개 C++ 작업초안의 data race 규칙을 확인해 독립적으로 설명했다. Java SE 25는 확인한 판본이며 최신판이라는 주장은 하지 않는다. 공개 C++ 작업초안은 발행된 ISO 표준 원문과 구별한다. Rust의 소유권이나 각 언어의 모든 메모리 규칙까지 전수 대조한 것은 아니므로 다른 언어에 그대로 일반화하지 않는다.

7. 한 장으로 정리하기

1. 언어 선택은 요구·실행환경에서 시작한다.
2. 패러다임은 상태와 책임을 표현하는 방법을 바꾼다.
3. 타입은 잘못된 상태를 줄이고 오류를 더 일찍 발견하도록 돕는 도구다.
4. 메모리 관리는 수명·자원·지연·실패 방식의 계약이다.
5. 동시성은 언어별 메모리 모델과 정식 동기화 규칙을 확인한다.
6. 벤치마크·생태계·운영 역량까지 실제 선택 비용에 포함한다.

독립 연습 — 두 배 빨라진 부분과 전체를 구분한다

다음은 본문 사례의 조건을 적용하거나 바꾼 자체 연습이다. 먼저 판단과 근거를 적고 풀이를 펼친다.

PL-4의 순차 요청에서 CPU 10 ms와 DB 90 ms를 유지한다. 새 도구체인은 CPU를 5 ms로 줄인다. 별도 대안은 언어를 그대로 두고 DB 경로를 45 ms로 줄이며 CPU는 10 ms다. 둘은 독립적인 교육용 계산이고 실제 벤치마크 결과가 아니다.

• 각 대안의 전체 응답시간과 원래 100 ms 대비 감소율을 구하라.
• 시간 계산만으로 언어 선택을 완료할 수 없는 이유를 두 가지 적어라.

풀이와 오답 교정 보기

도구체인 대안은 5+90=95 ms로 전체 5% 감소다. DB 대안은 10+45=55 ms로 45% 감소다. CPU만의 2배 향상을 전체 2배 향상으로 바꾸지 않는다. 이 순차 가정의 계산은 실제 부하·런타임 정지·메모리 수명·ABI·운영 인력·유지보수 조건을 확인한 것이 아니다. 필수 실행환경과 안전·변경 요구를 만족하는지 별도로 검토한다.

부분 속도를 전체로 옮겼다면 PL-4의 경계, 한 숫자로 언어를 골랐다면 같은 실행환경의 비교에서 선택 조건을 되찾는다.

8. 자체 10점 문제

프로그래밍 언어 선택 시 패러다임, 타입 시스템, 메모리 관리와 동시성 모델을 함께 고려해야 하는 이유를 설명하시오.

요구어는 설명이다. 네 기능을 따로 나열하지 말고 오류·자원·변경 요구에 연결한다.

10점 풀이와 답안 구성 보기

10점 답안 목차

1. 요구·실행환경
2. 패러다임과 상태·책임
3. 타입과 잘못된 상태
4. 메모리 수명·자원
5. 동시성 메모리 모델·검증

10점 답안 도식

요구를 구현 규칙으로 옮길 관점	연결할 결과	공통 확인
패러다임	구조·책임	검증·운영
타입	허용 상태·오류	검증·운영
메모리	수명·자원	검증·운영
동시성	원자성·가시성·순서	검증·운영

10점 모범답안

프로그래밍 언어는 문법보다 시스템 요구를 구현하는 실행 규칙으로 선택한다. 패러다임은 상태와 책임의 분해 방식을, 타입 시스템은 허용할 값과 오류 발견 시점을, 메모리 관리 방식은 객체 수명·메모리 상한·런타임 지연을 바꾼다. 여러 실행흐름이 공유 상태를 다루면 원자성·동기화·가시성 규칙을 해당 언어의 메모리 모델로 확인해야 한다. 따라서 하드웨어 접근·실시간성·안전·변경성·도구체인과 팀의 검증 역량을 함께 비교하여 선택한다.

9. 자체 25점 문제

실시간 센서 수집 모듈과 클라우드 분석 API를 함께 개발하는 프로젝트에서 프로그래밍 언어 선택 기준을 설계하시오. 패러다임·타입·메모리 관리·동시성·상호운용·성능·운영 생태계를 포함하고, 하나의 언어로 전체를 통일할 때의 위험도 설명하시오.

요구어는 설계, 포함, 설명이다. 모듈별 제약이 다르다는 점을 중심으로 선택표를 만든다.

25점 풀이와 답안 구성 보기

25점 답안 목차

1. 모듈별 요구·실행환경 분리
2. 센서 모듈: ABI·메모리·마감·동시성
3. API 모듈: 생산성·타입·생태계·I/O
4. 패러다임·타입·오류모델 비교
5. 메모리·동시성 모델 검증
6. FFI/API 상호운용 경계
7. 실제 워크로드 벤치마크와 운영 비용
8. 단일언어 강제의 장단점과 최종 결정

25점 답안 도식

화살표의 방향과 조건을 따라 연결을 읽습니다.

A·B는 결정된 제품명이 아닌 언어 후보다. 선은 요구·계약·검증 연결이며 실제 데이터 전송 순서가 아니다. 명시 인터페이스에는 ABI·FFI 또는 API의 데이터 소유권·오류·시간초과 계약을 둔다.

25점 모범답안

먼저 센서 수집 모듈과 클라우드 API의 실행환경을 분리한다. 센서 모듈은 장치 ABI·메모리 상한·마감시간·인터럽트와 공유상태 통제가 중요하므로 예측 가능한 자원 관리와 정식 동시성 규칙, 안정된 크로스컴파일 도구체인을 우선한다. API는 네트워크·DB I/O, 변경 빈도, 타입을 통한 계약, 라이브러리·배포·관찰 생태계를 비교한다. 두 영역 모두 패러다임 이름보다 실제 상태 관리, null·오류 표현, 객체 수명, 동시성 메모리 모델과 테스트 도구를 확인한다. 상호운용은 C ABI·FFI 또는 버전이 명확한 API로 경계를 만들고 데이터 소유권·오류·타임아웃을 계약화한다. 성능은 마이크로벤치마크가 아니라 실제 워크로드에서 병목별로 측정한다. 하나의 언어로 통일하면 교육·빌드가 단순해질 수 있지만 한 모듈의 제약을 다른 모듈에 강요하거나 적합한 하드웨어·운영 생태계를 포기할 수 있으므로 모듈 경계의 총복잡도를 기준으로 결정한다.

직접 연습: 타입에 담은 의미와 실행 시 확인할 조건을 나눈다.

다음은 언어 선택의 판단을 연습하는 별도 조건이다. 타입 계약의 기대 동작, 단순 용량 계산, 후보 비교를 실제 컴파일·GC·장치 시험과 구별한다.

1. PL-T. pay(UserId, Money)는 두 의미 타입을 구별하고 암묵적으로 섞지 않는다고 가정한다. 외부 금액은 정수로 해석할 수 있고 1~5,000일 때만 Money로 만든다. 이 연습의 실행 정책은 ‘인증된 호출자 ID가 대상 UserId와 같고, 현재 잔액이 금액 이상이어야 한다’이다. 아래 네 입력에서 최초로 막아야 할 조건을 각각 쓰라. 이 사례는 금융 업무의 실제 권한·결제 계약을 정의한 것이 아니다. ① 금액 문자열 ten ② 대상 1001·금액 1001·호출자 1002·잔액 2,000 ③ 대상 1001·금액 6,000·호출자 1001·잔액 10,000 ④ 대상 1001·금액 1001·호출자 1001·잔액 500. 두 의미 타입에 맞게 포장됐다는 사실로 네 경우를 모두 허용해도 되는가?
2. PL-M. 십진 단위 1 KB=1,000바이트, 1 MB=1,000,000바이트를 쓴다. 서비스가 요청마다 2 KB 객체를 전역 목록에 계속 붙여 참조를 유지하며 초당 정확히 25개의 요청을 처리한다. 초기 사용량은 20 MB, 허용 상한은 90 MB이고 다른 할당·해제·오버헤드는 없다고 가정한다. 10분 뒤 사용량과 상한에 정확히 도달하는 요청 수·경과 시간을 구하라. 상한 도달 뒤 요청 하나를 더 보존하면 얼마가 되는가? GC가 있다는 이유로 이 참조 누적이 자동 해결된다고 할 수 있는가?
3. PL-A. 센서 모듈의 필수 조건은 목표 C ABI와 연결 가능하고, 지정된 자료 영역이 64,000바이트 이하인 것이다. 다른 요구는 아직 검증하지 않았다. 가상 후보 A는 계산 3 ms·ABI 연결 불가·자료 40,000바이트, B는 4 ms·연결 가능·48,000바이트, C는 2 ms·연결 가능·80,000바이트이다. 주어진 두 필수 조건을 만족하는 후보와 제외 이유를 쓰라. 후보가 A와 C뿐이라면 계산 시간이 짧은 C를 확정해도 되는가? B가 이 두 조건을 만족한다는 사실은 전체 언어 선택이 끝났다는 뜻인가?

의미 타입·참조 누적·실행환경 필수 조건 풀이

1. PL-T — 외부 입력과 현재 실행 상태는 타입 이름만으로 확인되지 않는다. ① ten은 정수 금액으로 해석할 수 없으므로 Money 생성 전에 입력을 거부한다. ② 금액 1001은 범위 안이고 의미 타입의 자리도 맞지만, 인증된 호출자 1002가 대상 1001과 달라 주어진 실행 정책의 소유자 조건에서 막는다. 호출자 ID를 외부 요청이 주장한 값으로 대신하지 않는다.

③ 금액 6,000은 Money 생성 조건 1~5,000 밖이므로 도메인 값 생성 전에 거부한다. ④ 금액·대상·호출자 조건은 맞아도 현재 잔액 500이 금액 1001보다 작으므로 잔액 조건에서 막는다. 이미 포장한 Money와 UserId를 바꿔 넘기는 오류는 선언한 타입 계약이 줄일 수 있지만, 외부 입력의 해석·범위 검증이나 현재 권한·잔액 확인을 대신하지 못한다. 실제 구현은 검증된 값을 생성하는 경로와 실행 중 상태가 바뀔 때의 처리도 정해야 한다.

2. PL-M — 사용하지 않아도 참조가 남아 있으면 회수 대상이 아닐 수 있다. 증가량은 2,000×25=50,000바이트/초이다. 10분은 600초이므로 30,000,000바이트가 늘어 총 사용량은 50,000,000바이트, 즉 50 MB이다. 상한까지 남은 70 MB를 요청당 2,000바이트로 나누면 35,000회의 요청이며, 35,000/25=1,400초=23분 20초에 90 MB에 도달한다.

그 뒤 요청 하나를 더 보존하면 90,002,000바이트로 상한을 넘는다. 전역 목록의 참조가 계속 살아 있으므로 GC가 있다는 이유만으로 필요한 메모리가 회수된다고 가정하지 않는다. 보존 개수·기간의 요구를 정하고 참조를 제거하는 수명 정책과 상한 도달 시 처리를 설계해야 한다. 참조 제거도 특정 시각의 즉시 회수나 지연 상한을 보장하지 않는다. 위 수치는 오버헤드를 제외한 단순 증가 모형이며 실제 힙·GC 정지·부하는 별도로 측정한다.

3. PL-A — 필수 실행환경을 만족하는 후보부터 비교한다. B만 주어진 두 조건을 만족한다. A는 자료 크기가 작아도 필요한 ABI 연결이 없고, C는 계산이 가장 빨라도 자료 영역 80,000바이트가 상한 64,000바이트를 넘는다. A와 C만 있다면 조건을 만족하는 후보가 없으므로 C를 임의로 확정하지 않는다. 연결 방법·자료 구조를 바꾸거나 다른 후보를 만들고 변경된 조건을 다시 확인한다.

B에 대해서도 아직 마감시간, 최악 지연, 메모리 수명, 동시성, 오류 처리, 목표 플랫폼 도구체인과 운영 역량 등의 근거가 필요하다. 계산 시간·자료 크기는 이 문제에서 준 가상 값이다. 두 조건 통과는 후보 비교의 한 단계이며 실제 센서 모듈의 전체 요구나 전체 언어 선택을 검증한 결과가 아니다.