Simplex·Half Duplex·Full Duplex로 이해하는 데이터의 양방향 통신

1. 현장에서 시작하는 질문#

새로 설치한 주차장 차단기가 중앙 서버의 명령을 받아 열리고 닫혀야 한다고 가정해보겠습니다.

서버 로그에는 다음과 같은 기록이 남았습니다.

10:32:15 OPEN command sent

그런데 실제 차단기는 움직이지 않습니다.

이 상황에서 단순히

서버가 명령을 보냈으니 차단기 문제다.

라고 결론 내려도 될까요?

그렇지 않습니다.

실제 통신 과정은 다음처럼 여러 단계로 나누어 볼 수 있습니다.

서버
 ↓
명령 생성
 ↓
통신 인터페이스
 ↓
전송 매체
 ↓
컨트롤러
 ↓
명령 해석
 ↓
물리적 장비 동작
 ↓
상태 응답

서버에서 명령을 보냈다는 기록은 송신 동작이 시작됐다는 사실만 알려줄 뿐입니다.

상대 장비가 명령을 실제로 받았는지, 처리했는지, 물리적인 동작까지 완료했는지는 별도의 확인이 필요합니다.

이 문제를 이해하려면 먼저 두 장비가 어떤 방식으로 서로 데이터를 주고받는지 알아야 합니다.

대표적인 방식이 바로 다음 세 가지입니다.

Simplex
Half Duplex
Full Duplex

이 세 개념은 단순히 네트워크 용어가 아니라 장비 통신 구조를 이해하는 기본 개념입니다.

2. 통신 방향을 결정하는 세 가지 방식#

먼저 전체적인 차이를 살펴보겠습니다.

통신 방식	데이터 방향	동시 송수신	쉬운 비유
Simplex	한 방향	불가능	방송
Half Duplex	양방향	불가능	무전기
Full Duplex	양방향	가능	전화

핵심 차이는 양쪽이 데이터를 보낼 수 있는가, 그리고 동시에 보낼 수 있는가입니다.

3. Simplex란 무엇인가#

Simplex는 데이터가 한 방향으로만 이동하는 통신 방식입니다.

구조는 매우 단순합니다.

송신 장치 ─────────→ 수신 장치

수신 장치는 데이터를 받을 수 있지만 같은 통신 경로를 이용해 송신 장치로 응답하지 않습니다.

대표적인 비유가 방송입니다.

방송국
  ↓
라디오

방송국은 데이터를 보내지만 라디오가 같은 방송 채널을 이용해 방송국에 응답하지는 않습니다.

3.1 Simplex의 특징#

장점은 구조가 단순하다는 점입니다.

송수신 제어가 간단함
충돌 제어가 거의 필요 없음
구현 비용을 낮출 수 있음

반대로 단점도 분명합니다.

수신 여부 확인이 어려움
오류가 발생해도 즉시 알기 어려움
장비 상태 피드백에 적합하지 않음

따라서 단순 표시 장치나 일방적인 정보 전달에는 사용할 수 있지만, 상태 확인이 중요한 제어 시스템에는 제약이 있습니다.

4. Half Duplex란 무엇인가#

Half Duplex는 양쪽 모두 데이터를 보낼 수 있지만 동시에 보낼 수는 없는 방식입니다.

구조를 단순하게 표현하면 다음과 같습니다.

장치 A ─────→ 장치 B

또는

장치 A ←───── 장치 B

어느 한쪽이 전송하고 있을 때 다른 쪽은 기다립니다.

가장 이해하기 쉬운 예가 무전기입니다.

한 사람이 버튼을 누르고 말하는 동안 상대방은 듣습니다.

말이 끝나면 상대방이 송신 권한을 얻어 대답합니다.

A: 송신
B: 수신

↓

A: 수신
B: 송신

이런 방식이 Half Duplex입니다.

5. Half Duplex에서는 왜 순서가 중요한가#

하나의 통신 채널을 여러 장치가 공유한다면 동시에 여러 장치가 데이터를 보내려고 할 수 있습니다.

예를 들어:

장치 A ──┐
         ├── 같은 통신선
장치 B ──┤
장치 C ──┘

장치 A와 장치 B가 동시에 데이터를 전송하면 정상적인 통신이 어려워질 수 있습니다.

그래서 Half Duplex 환경에서는 누가 언제 송신할 것인지 결정하는 규칙이 중요합니다.

대표적인 방식으로는:

Master/Slave
Client/Server
Polling
Token
Collision Avoidance

등이 있습니다.

산업 현장에서는 한 장치가 순서대로 다른 장치를 조회하는 Polling 방식이 흔히 사용됩니다.

Master
  ↓
Device 1 요청
  ↓
Device 1 응답
  ↓
Device 2 요청
  ↓
Device 2 응답

이 방식이면 여러 장치가 동시에 송신하는 문제를 줄일 수 있습니다.

6. RS-485와 Half Duplex#

RS-485는 산업 장비 통신에서 매우 많이 사용되는 인터페이스입니다.

특히 두 선을 사용하는 2-Wire RS-485 구성은 Half Duplex 방식으로 사용하는 경우가 많습니다.

Device A
   │
   ├──── A
   └──── B
          │
Device B──┤
Device C──┘

같은 A/B 선로를 송신과 수신에 함께 사용하기 때문에 한 장치가 송신하는 동안 다른 장치는 일반적으로 기다려야 합니다.

이런 구조에서는 다음 항목이 중요합니다.

송신 권한
응답 대기시간
Polling 주기
Timeout
장치 주소
종단저항
배선 상태

RS-485 자체가 통신 프로토콜을 정의하는 것은 아닙니다.

그 위에서 Modbus RTU나 제조사 자체 프로토콜 같은 규칙을 사용할 수 있습니다.

7. RS-485는 항상 Half Duplex인가#

그렇지는 않습니다.

RS-485는 구성 방식에 따라 4-Wire 방식으로 구현할 수도 있습니다.

예를 들어 송신과 수신을 서로 다른 선로로 분리하면 다음과 같은 형태가 가능합니다.

TX+ ─────────→ RX+
TX- ─────────→ RX-

RX+ ←───────── TX+
RX- ←───────── TX-

이런 구성에서는 양방향 통신을 보다 독립적으로 처리할 수 있습니다.

따라서 현장에서

RS-485니까 무조건 Half Duplex다.

라고 단정하면 안 됩니다.

장비의 실제 배선 구조와 제조사 문서를 확인해야 합니다.

8. Full Duplex란 무엇인가#

Full Duplex는 양쪽 장치가 동시에 데이터를 송수신할 수 있는 방식입니다.

구조는 다음과 같습니다.

장치 A ─────→ 장치 B
장치 A ←───── 장치 B

양쪽 방향의 통신이 동시에 이루어질 수 있습니다.

전화 통화를 생각하면 쉽습니다.

두 사람이 동시에 말하거나 들을 수 있습니다.

Half Duplex 무전기처럼 상대방이 말을 끝낼 때까지 기다릴 필요가 없습니다.

9. Full Duplex는 어떻게 구현하는가#

Full Duplex를 구현하는 방법은 여러 가지입니다.

9.1 송수신 경로 분리#

송신과 수신용 물리 경로를 따로 두는 방식입니다.

TX ─────────→ RX
RX ←───────── TX

9.2 서로 다른 주파수 사용#

무선 통신에서는 송신과 수신 주파수를 나누는 방법을 사용할 수도 있습니다.

이를 FDD, Frequency Division Duplex라고 합니다.

9.3 신호 처리 기술 사용#

일부 시스템에서는 같은 매체를 사용하면서 신호 처리 기술을 이용해 동시에 송수신할 수도 있습니다.

따라서 Full Duplex라고 해서 반드시 케이블을 두 배로 사용한다는 의미는 아닙니다.

10. Ethernet은 Full Duplex인가#

현대적인 Switch 기반 Ethernet 환경에서는 Full Duplex가 일반적입니다.

예를 들어 PC와 Switch가 연결되어 있다면:

PC
↕
Switch

PC가 데이터를 보내는 동안 동시에 데이터를 받을 수도 있습니다.

과거 Hub를 사용하던 Ethernet 환경에서는 Half Duplex와 충돌 감지가 중요했지만, 현재의 Switch 기반 Ethernet에서는 이러한 구조를 거의 사용하지 않습니다.

그래서 일반적인 현대 Ethernet 환경에서는 Full Duplex를 기본적으로 생각해도 됩니다.

다만 실제 링크 상태는 운영체제나 네트워크 장비에서 확인할 수 있습니다.

Speed: 1000Mb/s
Duplex: Full

처럼 표시되는 경우가 대표적입니다.

11. Simplex·Half Duplex·Full Duplex 비교#

세 방식을 한 번에 비교하면 다음과 같습니다.

구분	Simplex	Half Duplex	Full Duplex
송신 방향	한 방향	양방향	양방향
동시 송수신	불가능	불가능	가능
구조	가장 단순	중간	상대적으로 복잡
채널 공유	단순	송신 순서 필요	동시 사용 가능
대표 사례	방송	무전기, 2-Wire RS-485	현대 Ethernet
상태 응답	제한적	가능	가능
실시간 양방향 통신	부적합	제한적	유리

12. 주차관제 시스템에서는 어떻게 사용될까#

주차관제 시스템에서는 다양한 통신 방식이 동시에 존재할 수 있습니다.

예를 들어:

주차관제 서버
      │
      │ Ethernet
      ↓
현장 Controller
      │
      │ RS-485
      ↓
차단기 / 센서

서버와 현장 컨트롤러 사이에는 Ethernet을 사용하고, 컨트롤러와 현장 장비 사이에는 RS-485를 사용할 수 있습니다.

이 경우 하나의 시스템 안에서도:

Ethernet
→ Full Duplex

RS-485 2-Wire
→ Half Duplex

처럼 서로 다른 통신 방식이 동시에 존재합니다.

그래서 장애를 분석할 때는 시스템 전체를 하나의 통신 방식으로 생각하면 안 됩니다.

13. 차단기 OPEN 명령은 어떻게 전달될까#

서버가 차단기에 OPEN 명령을 보내는 상황을 보겠습니다.

개념적으로는 다음과 같은 흐름이 가능합니다.

Server
   ↓
OPEN 요청
   ↓
Controller
   ↓
차단기 동작
   ↓
상태 확인
   ↓
ACK 또는 상태 응답
   ↓
Server

예를 들어:

Server → OPEN gate01

컨트롤러가 명령을 정상적으로 받았다고 응답할 수 있습니다.

Controller → ACK gate01

그리고 실제 차단기가 열린 이후에는 다시:

Controller → STATUS gate01 OPEN

처럼 상태를 보고할 수도 있습니다.

여기서 중요한 점이 있습니다.

ACK와 실제 동작 완료는 같은 의미가 아닐 수 있습니다.

14. ACK를 받았다고 차단기가 열린 것은 아니다#

ACK는 일반적으로 수신 확인이나 명령 접수를 의미합니다.

예를 들어:

OPEN 명령
   ↓
ACK

라고 해서 실제 모터가 움직이고 차단기 암이 완전히 올라갔다는 뜻은 아닐 수 있습니다.

실제 시스템에서는 상태를 나눠 관리하는 것이 좋습니다.

Command Sent
      ↓
Command Received
      ↓
Motor Started
      ↓
Opening
      ↓
Opened

즉 다음을 구분해야 합니다.

명령을 보냈는가
명령을 받았는가
실행을 시작했는가
실제 동작이 완료됐는가

이 구분은 산업 장비 장애를 분석할 때 매우 중요합니다.

15. Polling은 왜 사용하는가#

Half Duplex 환경에서는 장비가 마음대로 동시에 데이터를 보내기 어려울 수 있습니다.

그래서 중앙 장치가 순서대로 상태를 물어보는 Polling 구조를 사용할 수 있습니다.

예를 들어:

Controller → Gate 1 상태?
Gate 1     → CLOSED

Controller → Gate 2 상태?
Gate 2     → OPEN

Controller → Gate 3 상태?
Gate 3     → CLOSED

이 방법은 통신 순서를 명확하게 관리할 수 있다는 장점이 있습니다.

반면 장치 수가 지나치게 많거나 Polling 주기가 길어지면 상태 변경을 늦게 감지할 수도 있습니다.

따라서:

Polling 주기
+
장치 수
+
응답시간

을 함께 고려해야 합니다.

16. TCP는 Full Duplex인가#

TCP 연결은 논리적으로 Full Duplex 통신을 제공합니다.

TCP 연결이 만들어지면 양쪽 애플리케이션은 동시에 데이터를 보내고 받을 수 있습니다.

Client ─────→ Server
Client ←───── Server

예를 들어 서버가 차단기에 명령을 보내는 동시에 컨트롤러가 상태 이벤트를 서버로 보낼 수도 있습니다.

하지만 여기서 주의해야 합니다.

TCP가 Full Duplex라고 해서 애플리케이션 프로토콜까지 반드시 동시에 양방향 통신하도록 설계해야 하는 것은 아닙니다.

애플리케이션이:

요청
↓
응답 대기
↓
다음 요청

구조로 만들어져 있다면 논리적으로는 Half Duplex처럼 동작할 수도 있습니다.

17. 물리적 Duplex와 논리적 Duplex를 구분하자#

매우 중요한 개념입니다.

통신에는 물리적인 통신 방식과 애플리케이션의 대화 방식이 별도로 존재할 수 있습니다.

예를 들어:

Ethernet
→ 물리적으로 Full Duplex

애플리케이션
→ Request → Response 방식

일 수 있습니다.

반대로 통신 매체가 양방향을 지원하더라도 프로그램이 한 번에 하나의 요청만 처리하도록 설계되어 있다면 실제 체감 동작은 제한적일 수 있습니다.

따라서 장애 분석에서는 다음 두 가지를 구분해야 합니다.

물리 통신 방식
+
프로토콜 대화 방식

18. MQTT는 어디에 해당할까#

MQTT는 Simplex, Half Duplex, Full Duplex라는 물리 통신 분류와는 조금 다른 계층의 개념입니다.

MQTT는 Publish/Subscribe 구조를 사용하는 애플리케이션 프로토콜입니다.

예를 들어:

Gate Controller
      ↓ Publish
MQTT Broker
      ↓
Parking Server

컨트롤러가 상태를 발행할 수 있고 서버는 이를 구독합니다.

반대로 서버가 제어 Topic에 명령을 발행하도록 설계할 수도 있습니다.

Server
  ↓
parking/gate/01/command
  ↓
MQTT Broker
  ↓
Gate Controller

따라서 MQTT 자체를 단순히 Half Duplex나 Full Duplex라고 분류하기보다는 MQTT가 동작하는 아래쪽 TCP 연결과 애플리케이션 메시지 구조를 따로 이해하는 것이 좋습니다.

19. 통신 모드가 맞지 않으면 어떤 문제가 생길까#

대표적인 문제는 다음과 같습니다.

19.1 송신 충돌#

Half Duplex 공유 버스에서 여러 장치가 동시에 송신하면 정상적인 데이터를 읽지 못할 수 있습니다.

19.2 Timeout#

서버가 너무 빨리 응답을 기다리면 아직 송신 권한을 얻지 못한 장치가 응답하기 전에 Timeout이 발생할 수 있습니다.

19.3 응답 누락#

Polling 구조를 이해하지 못하면 장비가 자발적으로 상태를 보내지 않는 것을 장애라고 잘못 판단할 수 있습니다.

19.4 데이터 혼선#

여러 장치의 응답 순서를 제대로 관리하지 않으면 어느 요청에 대한 응답인지 구분하기 어려워질 수 있습니다.

20. 차단기가 반응하지 않을 때 점검하는 순서#

서버에는 OPEN 명령 전송 기록이 있는데 차단기가 움직이지 않는다고 가정해보겠습니다.

다음 순서로 범위를 좁혀볼 수 있습니다.

20.1 전원 확인#

먼저 차단기와 컨트롤러가 정상적으로 동작하고 있는지 확인합니다.

20.2 물리 링크 확인#

Ethernet이라면:

Link Up?
Switch Port 정상?

Serial이라면:

TX/RX
A/B
GND

배선을 확인합니다.

20.3 통신 설정 확인#

예:

Baud Rate
Data Bits
Parity
Stop Bits
IP
Port

20.4 Duplex 방식 확인#

장비가 Half Duplex인지 Full Duplex인지 확인합니다.

특히 RS-485에서는 실제 배선 방식과 장비 설정을 확인해야 합니다.

20.5 실제 데이터 도착 확인#

서버 로그만 보지 말고 실제 패킷이나 Serial 데이터를 확인합니다.

20.6 ACK 확인#

명령을 수신했다는 응답이 있는지 확인합니다.

20.7 실제 상태 확인#

ACK가 있더라도 물리 장비가 실제로 움직였는지 센서나 상태값을 통해 확인합니다.

이렇게 하면:

서버 문제
통신 문제
프로토콜 문제
컨트롤러 문제
물리 장비 문제

중 어느 구간에서 장애가 발생했는지 좁혀갈 수 있습니다.

21. TCP 명령·응답 구조를 시험해보기#

시험망에서는 간단한 TCP 메시지를 이용해 Request/Response 구조를 이해할 수 있습니다.

예를 들어 테스트 서버에 다음 메시지를 전송한다고 가정합니다.

echo '{"cmd":"open","id":"gate01"}' | nc 192.168.100.50 5000

서버가 다음과 같은 응답을 반환할 수 있습니다.

{
  "id": "gate01",
  "result": "accepted"
}

여기서 accepted는 명령이 접수됐다는 의미일 뿐 실제 차단기가 완전히 열렸다는 뜻으로 설계해서는 안 됩니다.

실제 상태는 별도 이벤트로 전달할 수 있습니다.

{
  "id": "gate01",
  "status": "opened"
}

이렇게 명령 접수와 실제 상태를 나누면 장애 분석도 쉬워집니다.

22. 안전한 장비 통신을 위해 고려할 것#

차단기나 출입문처럼 실제 물리 장비를 제어하는 시스템은 일반적인 웹서비스보다 안전 요구가 높습니다.

예를 들어 공격자가 다음 명령을 보낼 수 있다면 문제가 됩니다.

OPEN

따라서 실제 시스템에서는 필요에 따라 다음을 고려해야 합니다.

장비 인증
서버 인증
TLS
접근 제어
Firewall
VLAN
명령 권한 관리
감사 로그
네트워크 분리

특히 원격 제어 명령은 누가 언제 어떤 명령을 실행했는지 기록하는 것이 중요합니다.

23. 실습은 반드시 시험 환경에서 진행한다#

물리 장비 제어 테스트를 운영 중인 차단기나 출입문에서 바로 실행하는 것은 위험할 수 있습니다.

가능하면 다음 구조의 테스트베드를 만드는 것이 좋습니다.

테스트 Server
      ↓
통신 Simulator
      ↓
가상 Controller

이 환경에서 먼저:

OPEN
↓
ACK
↓
OPENING
↓
OPENED

흐름을 구현해봅니다.

다음으로 일부러 응답을 지연시키거나 패킷을 누락시키면서:

Timeout
Retry
Duplicate Command
Late Response

상황을 테스트해볼 수 있습니다.

24. Simplex·Half Duplex·Full Duplex 선택 기준#

어떤 방식이 항상 가장 좋은 것은 아닙니다.

시스템 요구사항에 따라 달라집니다.

Simplex가 적합할 수 있는 경우#

단순 방송
표시 정보
일방향 센서 데이터
응답이 필요 없는 정보 전달

Half Duplex가 적합할 수 있는 경우#

배선을 단순화해야 하는 산업 현장
여러 장비가 하나의 버스를 공유하는 환경
데이터량이 크지 않은 제어 통신
Master 중심 Polling 시스템

Full Duplex가 유리한 경우#

실시간 상태 이벤트
빈번한 양방향 데이터 교환
서버와 장비가 동시에 데이터를 생성하는 환경
높은 반응성이 필요한 시스템

25. 세 가지 방식을 한 문장으로 기억하기#

복잡하게 생각할 필요는 없습니다.

Simplex
→ 한쪽만 말한다.

Half Duplex
→ 양쪽이 말할 수 있지만 번갈아 말한다.

Full Duplex
→ 양쪽이 동시에 말할 수 있다.

이 세 문장만 정확하게 이해해도 기본 개념은 충분히 잡힙니다.

26. 자기 점검#

Q1. Simplex와 Half Duplex의 가장 큰 차이는 무엇인가?#

Simplex는 데이터가 한 방향으로만 이동하지만 Half Duplex는 양방향 통신이 가능합니다. 다만 동시에 송신할 수는 없습니다.

Q2. RS-485는 항상 Half Duplex인가?#

아닙니다. 2-Wire 구성에서는 Half Duplex로 많이 사용하지만 4-Wire 구성을 사용할 수도 있으므로 실제 장비 규격을 확인해야 합니다.

Q3. TCP는 Full Duplex인가?#

TCP 연결 자체는 양쪽이 동시에 데이터를 주고받을 수 있는 Full Duplex 통신을 제공합니다. 다만 애플리케이션 프로토콜이 Request/Response 방식으로 제한적으로 동작할 수 있습니다.

Q4. ACK를 받았다면 장비 동작이 완료됐다는 뜻인가?#

반드시 그렇지는 않습니다. ACK가 명령 수신만 의미하는지 실제 작업 완료까지 의미하는지는 프로토콜 설계에 따라 다릅니다.

Q5. Half Duplex 시스템에서 가장 중요한 설계 요소는 무엇인가?#

여러 장치가 같은 채널을 사용하는 경우 누가 언제 송신할 것인지 결정하는 통신 순서와 권한 관리가 중요합니다.

27. 이 글을 마치며#

Simplex, Half Duplex, Full Duplex는 단순히 시험 문제를 풀기 위한 용어가 아닙니다.

실제 시스템에서:

누가 데이터를 보내는가
↓
누가 받을 수 있는가
↓
동시에 송수신할 수 있는가
↓
응답은 언제 가능한가

를 결정하는 중요한 통신 구조입니다.

특히 산업 장비에서는 Half Duplex와 Full Duplex의 차이를 모르고 장애를 분석하면 정상적인 동작을 오류로 오해할 수도 있습니다.

따라서 통신 장애를 확인할 때는 단순히:

데이터가 안 온다.

라고 생각하지 말고,

물리 인터페이스
↓
Duplex 방식
↓
송신 권한
↓
프로토콜
↓
명령
↓
ACK
↓
실제 상태

순서로 나누어 보는 것이 좋습니다.

결국 가장 중요한 것은 서버가 명령을 보냈다는 사실과 장비가 실제로 동작했다는 사실을 서로 구분하는 것입니다.

Simplex·Half Duplex·Full Duplex로 이해하는 데이터의 양방향 통신

1. 현장에서 시작하는 질문#

2. 통신 방향을 결정하는 세 가지 방식#

3. Simplex란 무엇인가#

3.1 Simplex의 특징#

4. Half Duplex란 무엇인가#

5. Half Duplex에서는 왜 순서가 중요한가#

6. RS-485와 Half Duplex#

7. RS-485는 항상 Half Duplex인가#

8. Full Duplex란 무엇인가#

9. Full Duplex는 어떻게 구현하는가#

9.1 송수신 경로 분리#

9.2 서로 다른 주파수 사용#

9.3 신호 처리 기술 사용#

10. Ethernet은 Full Duplex인가#

11. Simplex·Half Duplex·Full Duplex 비교#

12. 주차관제 시스템에서는 어떻게 사용될까#

13. 차단기 OPEN 명령은 어떻게 전달될까#

14. ACK를 받았다고 차단기가 열린 것은 아니다#

15. Polling은 왜 사용하는가#

16. TCP는 Full Duplex인가#

17. 물리적 Duplex와 논리적 Duplex를 구분하자#

18. MQTT는 어디에 해당할까#

19. 통신 모드가 맞지 않으면 어떤 문제가 생길까#

19.1 송신 충돌#

19.2 Timeout#

19.3 응답 누락#

19.4 데이터 혼선#

20. 차단기가 반응하지 않을 때 점검하는 순서#

20.1 전원 확인#

20.2 물리 링크 확인#

20.3 통신 설정 확인#

20.4 Duplex 방식 확인#

20.5 실제 데이터 도착 확인#

20.6 ACK 확인#

20.7 실제 상태 확인#

21. TCP 명령·응답 구조를 시험해보기#

22. 안전한 장비 통신을 위해 고려할 것#

23. 실습은 반드시 시험 환경에서 진행한다#

24. Simplex·Half Duplex·Full Duplex 선택 기준#

Simplex가 적합할 수 있는 경우#

Half Duplex가 적합할 수 있는 경우#

Full Duplex가 유리한 경우#

25. 세 가지 방식을 한 문장으로 기억하기#

26. 자기 점검#

Q1. Simplex와 Half Duplex의 가장 큰 차이는 무엇인가?#

Q2. RS-485는 항상 Half Duplex인가?#

Q3. TCP는 Full Duplex인가?#

Q4. ACK를 받았다면 장비 동작이 완료됐다는 뜻인가?#

Q5. Half Duplex 시스템에서 가장 중요한 설계 요소는 무엇인가?#

27. 이 글을 마치며#

이 페이지의 목차