서버 프로그램

• 로봇 한 대: 제어기와 티치 펜던트로 충분 / 여러 대 관리·데이터 수집·원격 서비스 → 서버(Server) 필요
• 서버 프로그램 = 로봇(클라이언트)들의 접속을 받아 상태 수집·작업 배분·데이터 저장·제공하는 중심 역할
• 출제 포인트: 서버-클라이언트 모델, TCP 서버 소켓의 함수 호출 순서(socket→bind→listen→accept), 동시성 처리 방식, HTTP/REST·WebSocket·MQTT 같은 응용 프로토콜의 특징

서버-클라이언트 모델

서버-클라이언트(Server-Client) 모델은 네트워크 소프트웨어의 가장 기본적인 역할 분담 구조다.

• 서버(Server): 서비스를 제공하는 쪽. 정해진 주소(IP)와 포트(Port)에서 기다리다가(Listen) 요청이 오면 응답한다. 항상 켜져 있어야 한다

• 클라이언트(Client): 서비스를 요청하는 쪽. 필요할 때 서버에 접속(Connect) 해서 요청하고 응답을 받는다 (→ 클라이언트 프로그램)

• 로봇 운영에서는 보통 로봇(또는 로봇 측 에이전트)이 클라이언트, 운영 센터의 컴퓨터가 서버

• 이유: 방화벽 안의 로봇이 바깥의 서버로 "먼저 접속해 나가는" 구조가 네트워크 설정상 유리하기 때문

로봇 운영 서버가 하는 일

• 로봇 등록·인증: 어떤 로봇이 접속했는지 식별하고 권한 확인 (→ 로봇 보안)
• 상태 수집·모니터링: 여러 로봇의 상태·알람을 모아 통합 대시보드 제공 (→ 로봇 모니터링 프로그램)
• 작업 관리(Task Management): 작업 지시 전달, 스케줄링, 다중 로봇 간 작업 배분
• 데이터 저장·분석: 주행 로그, 센서 데이터, 생산 실적을 DB에 축적하고 분석
• 소프트웨어 배포: 원격 업데이트(OTA, Over-The-Air) — 새 버전 프로그램·설정을 로봇들에 배포
• 외부 서비스 연계: 생산관리시스템(MES)·창고관리시스템(WMS)·클라우드와 연동

서버 프로그램의 계층 구조

일반적인 운영 서버는 3계층(3-Tier) 으로 구성된다.

계층을 나누면 각 부분을 독립적으로 개발·확장·교체할 수 있다 (→ 계층형 아키텍처).

TCP 서버의 소켓 프로그래밍 흐름

• 소켓(Socket) = 네트워크 통신의 프로그래밍 접점(끝점)
• TCP 서버는 다음 함수 호출 순서를 따른다 — 시험 단골이므로 순서를 암기한다.

1. socket() — 소켓 생성
2. bind() — 소켓에 자기 IP 주소·포트 번호를 결합
3. listen() — 접속 대기 상태로 전환 (대기 큐 준비)
4. accept() — 클라이언트의 접속을 수락 → 통신용 소켓이 새로 생성됨
5. send() / recv() — 데이터 송수신
6. close() — 연결 종료

• 클라이언트는 socket() → connect() → send()/recv() → close() 순서로 훨씬 단순
• TCP와 UDP의 차이는 로봇 구성 요소 간 통신 프로토콜 참조

동시성 처리 — 여러 클라이언트를 어떻게 받나

• 로봇 10대가 동시에 접속하는데 서버가 한 번에 하나씩만 처리하면 나머지는 기다려야 함 → 해결 방식:

• 반복(Iterative) 서버: 한 클라이언트를 끝까지 처리하고 다음을 받는다 — 간단하지만 동시 서비스 불가

• 멀티프로세스(Multi-process): 접속마다 프로세스를 복제(fork) — 격리성이 좋지만 생성 비용·메모리가 크다

• 멀티스레드(Multi-thread): 접속마다 스레드 할당 — 가볍지만 공유 자원 동기화 필요 (→ 미들웨어 프로세스 관리)

• I/O 멀티플렉싱(Multiplexing): select/epoll로 하나의 스레드가 여러 소켓을 감시 — 접속 수가 많을 때 효율적

• 비동기(Asynchronous) I/O: 요청을 걸어 두고 완료 통지를 받아 처리 — 이벤트 루프 기반 고성능 서버

응용 프로토콜 — HTTP/REST, WebSocket, MQTT

• REST(Representational State Transfer): "자원을 URI로 표현하고, HTTP 메서드로 행위를 표현"하는 API 설계 원칙. 예: GET /robots/7/status = 7번 로봇의 상태 조회
• MQTT의 브로커(Broker): 발행자와 구독자 사이의 중계 서버. 발행자와 구독자가 서로를 몰라도 되고(느슨한 결합), QoS 레벨(0: 최대 한 번, 1: 최소 한 번, 2: 정확히 한 번)로 전달 신뢰성을 선택한다

TCP 서버-클라이언트 소켓 흐름

sequenceDiagram
    participant C as 클라이언트 (로봇)
    participant S as 서버 (운영 센터)
    Note over S: socket() → bind() → listen()
    Note over C: socket()
    C->>S: connect() — 접속 요청
    S->>C: accept() — 수락 (통신용 소켓 생성)
    loop 데이터 교환
        C->>S: send() 상태 보고
        S->>C: send() 작업 지시
    end
    C->>S: close()

로봇 운영 서버 구조 (3계층 + 다중 로봇)

graph TD
    R1["로봇 1"] --> B["서버 접속 계층
(소켓·MQTT 브로커·REST)"]
    R2["로봇 2"] --> B
    R3["로봇 n"] --> B
    B --> APP["애플리케이션 계층
작업 배분·상태 판정·OTA"]
    APP --> DB[("데이터 계층
상태 이력·작업 기록")]
    APP --> WEB["프레젠테이션 계층
웹 대시보드"]
    WEB --> U["운영자 (브라우저)"]

1. TCP 서버 프로그램의 소켓 함수 호출 순서로 옳은 것은?

① socket → listen → bind → accept ② socket → bind → listen → accept ③ socket → accept → bind → listen ④ socket → connect → send → close

2. MQTT 프로토콜에 대한 설명으로 옳지 않은 것은?

① 발행-구독(Publish-Subscribe) 구조를 사용한다 ② 브로커가 발행자와 구독자 사이를 중계한다 ③ 발행자는 모든 구독자의 주소를 알고 있어야 한다 ④ QoS 레벨로 전달 신뢰성을 선택할 수 있다

3. 하나의 스레드가 select/epoll로 여러 소켓을 동시에 감시하며 처리하는 서버 동시성 기법은?

① 반복(Iterative) 서버 ② 멀티프로세스 서버 ③ 멀티스레드 서버 ④ I/O 멀티플렉싱

4. REST API 설계에서 "7번 로봇의 상태를 조회"하는 요청으로 가장 적절한 것은?

① POST /robots/7/status ② GET /robots/7/status ③ DELETE /robots/7/status ④ PUT /getRobotStatus?id=7

5. 웹 대시보드에서 로봇 상태 변화를 서버가 먼저 밀어서(push) 실시간 갱신하려 한다. 가장 적합한 프로토콜은?

① 단순 HTTP 요청-응답 ② FTP ③ WebSocket ④ SMTP

• 클라이언트 프로그램 — 접속하는 반대쪽의 구현
• 로봇 보안 — 서버 연동 시 인증·암호화
• 로봇 모니터링 프로그램 — 서버가 수집하는 모니터링 데이터
• 로봇 구성 요소 간 통신 프로토콜 — TCP/UDP 기초
• 로봇과 IoT디바이스 연동 — MQTT 기반 IoT 연동
• _MOC 로봇운영소프트웨어