소켓 프로그래밍이란
한 줄 정의
소켓 프로그래밍: OS가 제공하는 소켓 API를 사용해, 서로 다른 프로세스/컴퓨터 간 데이터를 송수신하는 프로그래밍
소켓을 3가지 관점으로 보기
| 관점 | 핵심 설명 |
|---|
| API 관점 | socket, bind, listen, accept, connect, send, recv를 조합해 통신 구현 |
| 역할 관점 | 리스너 소켓(접속 받기) + 연결 소켓(클라이언트별 실제 송수신) |
| 시스템 관점 | 내부적으로 TCP/IP 스택, 버퍼, 스케줄링이 동작하지만 앱은 API 계약만 지키면 됨 |
최소 흐름 미리 보기(TCP)
SOCKET listenSock = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
bind(listenSock, ...);
listen(listenSock, SOMAXCONN);
SOCKET clientSock = accept(listenSock, ...);
recv(clientSock, ...);
send(clientSock, ...);
- 이 문서의 이후 Part들은 이 흐름을 단계별로 분해해 정확히 다룹니다.
초보자가 어려워하는 점
왜 어렵게 느껴지는가
- 지금까지는 "내가 만든 함수 호출" 중심이었고,
- 소켓은 "OS가 제공한 함수 계약을 정확히 사용하는 일"이 중심입니다.
- 그래서 로직 난이도보다 함수 개수/인자/에러 코드 때문에 먼저 압도됩니다.
극복 루틴(실무형)
| 루틴 | 확인 항목 |
|---|
| 함수 1개씩 문서 확인 | 인자 의미, 반환값, 실패 조건, 스레드/블로킹 특성 |
| 최소 예제 실행 | "정상 1회"부터 성공시킨 뒤 확장 |
| 로그 습관화 | 실패 시 WSAGetLastError()를 즉시 기록 |
| 체크리스트화 | 초기화(WSAStartup)와 정리(WSACleanup) 같은 쌍 함수 누락 방지 |
현업 현실
- 현업은 "모든 코드를 처음부터 작성"이 아니라 "검증된 API/라이브러리 조합"이 기본입니다.
- DirectX, 소켓, DB 드라이버 모두 API 계약 기반 개발이라는 점이 같습니다.
- 따라서 문서 읽기 능력과 실패 원인 추적 능력이 실력의 핵심입니다.
프로젝트 구성
3분할 구조
┌─────────────────────────────────────────────────────────────────┐
│ 프로젝트 구성 │
├─────────────────────────────────────────────────────────────────┤
│ Server → 게임 서버 실행체 (접속 수락, 세션 관리, 게임 로직) │
│ DummyClient → 대량 접속/송신 테스트용 클라이언트 │
│ NetworkCore → 공용 네트워크 레이어(유틸, 소켓 래퍼, 공통 타입) │
└─────────────────────────────────────────────────────────────────┘
역할과 의존 방향
| 구성요소 | 역할 | 실무 포인트 |
|---|
| 서버 | 리스너 관리, accept, 세션 수명 관리 | 동접이 늘수록 연결 소켓/세션 관리 비용 증가 |
| 더미 클라이언트 | 접속/송신 자동화로 재현 가능한 테스트 | 기능 테스트 + 부하 테스트 둘 다 가능 |
| 네트워크 코어 | 공통 API 래핑, 주소 변환, 에러 처리 공통화 | 중복 제거, 테스트/유지보수성 향상 |
동시 접속 수와 소켓 수
- 서버에는 보통 리스너 소켓 1개 + 클라이언트별 연결 소켓 N개가 존재합니다.
- 예: 동접 5000명이라면 최소 연결 소켓 5000개(추가로 리스너 1개) 관점으로 생각해야 합니다.
- 이 수치 감각이 있어야 이후 I/O 모델(Select/Event/IOCP)의 필요성이 자연스럽게 이해됩니다.
입문 단계에서 자주 하는 오해
| 오해 | 바로잡기 |
|---|
| 소켓 하나면 클라이언트 여러 명과 바로 통신 가능 | 리스너 소켓과 연결 소켓의 역할이 다름 |
send 한 번 = 상대가 한 번에 같은 단위로 받음 | TCP는 스트림이므로 경계가 보장되지 않음(후반 Part에서 상세) |
| API만 외우면 끝 | 실패 코드 해석/로그/재현 루틴이 더 중요 |
| 더미 클라이언트는 선택사항 | 네트워크 기능 검증에서 사실상 필수 도구 |
강의 시 유의사항
강조 포인트
- "복잡한 내부를 다 아는 것"보다 "API 계약을 정확히 지키는 것"이 시작점임을 강조하세요.
- 리스너 소켓 vs 연결 소켓을 반드시 분리해서 설명하세요.
- 프로젝트 3분할의 목적은 단순 분리가 아니라 테스트 가능성 확보입니다.
강의 운영 팁
- 첫 실습은 "서버 1개 + 더미 1개 연결 성공 로그 확인"만 목표로 좁히세요.
- 실패 시
WSAGetLastError()를 로그로 남기는 습관을 초반부터 강제하세요.
- 함수 나열식 설명보다 "왜 이 함수가 이 순서에 있는지"를 계속 연결해 주세요.
체크 질문 (스스로 답해보기)
- 리스너 소켓과 연결 소켓의 역할 차이를 설명할 수 있는가?
- 왜 DummyClient 프로젝트가 네트워크 학습에서 중요한가?
- 소켓 입문 단계에서 가장 먼저 습관화해야 할 디버깅 루틴은 무엇인가?
