컴퓨터 네트워크, 한 번에 이해하기
우리가 매일 쓰는 인터넷, 카톡, 유튜브 전부 컴퓨터들이 서로 데이터를 주고받아서 돌아간다. 근데 컴퓨터끼리 어떻게 "말이 통하는" 걸까? 그걸 다루는 게 컴퓨터 네트워크. 핵심부터 한 줄로 정리하면 이렇다.
컴퓨터 네트워크 = 컴퓨터들을 연결해서, 정해진 약속(프로토콜)대로 데이터를 주고받게 하는 시스템
쉽게 비유하면
우편/택배 시스템이라고 생각하면 됨! 편지(데이터)를 봉투(패킷)에 담아서, 받는 사람 주소(IP 주소)를 적고, 우체국(라우터)들을 거쳐 배달된다. 주소가 틀리면 못 가고, 봉투가 너무 크면 여러 개로 쪼개서 보냄.
핵심은 "약속(프로토콜)" 이다. 전 세계 우체국이 다 다른 규칙으로 일하면 편지가 도착을 못 하잖아? 그래서 "주소는 이렇게 쓰고, 우표는 여기 붙이고" 하는 공통 규칙이 있는 거다. 네트워크의 프로토콜이 딱 그 역할 같음!
자세히
네트워크의 종류
- LAN (Local Area Network) — 집·사무실처럼 좁은 범위. 와이파이 공유기에 물린 기기들이 한 LAN.
- WAN (Wide Area Network) — 도시·국가를 넘는 넓은 범위.
- 인터넷 — 이 LAN·WAN들이 전 세계적으로 다 연결된 "네트워크들의 네트워크".
프로토콜 (통신 약속)
데이터를 주고받는 규칙들이다. 대표적으로:
- IP — 주소 체계. "누구한테 보낼지" 정함 (예: 192.168.0.1)
- TCP — 데이터를 안전하게, 빠짐없이, 순서대로 전달. (편지 받았다고 확인서 주는 방식)
- UDP — 확인 안 하고 일단 빠르게 쏨. 좀 빠져도 됨 (게임·영상 스트리밍에 유리)
- HTTP/HTTPS — 웹에서 쓰는 약속. 브라우저랑 서버가 대화하는 방식
- DNS — 도메인 이름(google.com)을 실제 IP 주소로 바꿔주는 "전화번호부"
계층 구조 (OSI 7계층 / TCP-IP 4계층)
네트워크는 한 덩어리가 아니라 여러 층으로 나눠서 동작한다. 택배로 치면 "물건 포장 → 송장 붙이기 → 트럭 배차 → 도로 주행"처럼 단계가 나뉜 거다. 각 층이 자기 일만 하니까, 한 군데가 바뀌어도 전체를 안 갈아엎어도 됨. 면접에서 자주 나오는 게 OSI 7계층(물리/데이터링크/네트워크/전송/세션/표현/응용)인데, 실무에선 TCP/IP 4계층으로 단순화해서 많이 본다.
TCP vs UDP (단골 비교)
| TCP | UDP | |
|---|---|---|
| 특징 | 신뢰성 ↑, 순서 보장 | 속도 ↑, 가벼움 |
| 비유 | 등기우편(수령 확인) | 전단지 뿌리기 |
| 용도 | 웹, 파일전송, 메일 | 실시간 게임, 영상통화 |
실사용 예
브라우저에 google.com 치고 엔터 누르면 이 일이 순식간에 일어난다.
- DNS가
google.com→ 실제 IP 주소로 변환 - 그 IP로 TCP 연결을 맺음 (서로 "연결할게~" "ㅇㅋ" 악수)
- HTTP 요청을 보냄 ("이 페이지 줘")
- 서버가 HTTP 응답으로 HTML을 돌려줌
- 브라우저가 그걸 화면에 그림
"주소창에 입력하고 엔터 치면 무슨 일이 일어나나요?"는 개발자 면접 단골 질문인데, 그게 통째로 컴퓨터 네트워크 이야기다!
실시간 기능도 마찬가지다. 예를 들어 실시간 투표 결과를 화면에 계속 밀어주는 SSE(Server-Sent Events) 같은 것도, 결국 서버랑 브라우저가 HTTP 연결을 유지하면서 데이터를 흘려보내는 네트워크 위에서 동작하는 거다. 와이파이가 끊기면 이런 실시간 연결이 툭 끊기는 것도 같은 맥락 같음!
한 방 정리
| 구분 | 내용 |
|---|---|
| 한 줄 정의 | 컴퓨터끼리 약속대로 데이터 주고받는 시스템 |
| 비유 | 우편/택배 (주소·봉투·우체국) |
| 핵심 약속 | IP, TCP/UDP, HTTP, DNS |
| 왜 계층화? | 층별로 일을 나눠서 유연하게 |
| 단골 면접 | 주소창 엔터 → 화면까지의 과정 |
쉽게 외우면 "데이터를 안전하게 목적지까지 배달하는 약속의 집합" — 이렇게 보면 감 잡힐 듯!
소프트웨어 공학, 한 번에 이해하기
"코딩 잘하면 됐지 무슨 공학이야?" 싶을 수 있는데, 혼자 작은 거 만드는 거랑 여러 명이 큰 서비스를 몇 년씩 굴리는 건 완전히 다른 게임이다. 그 "제대로 만드는 방법"을 다루는 게 소프트웨어 공학. 핵심부터 한 줄로 정리하면 이렇다.
소프트웨어 공학 = 소프트웨어를 체계적으로 설계·개발·운영·유지보수하는 방법론과 원칙
쉽게 비유하면
건축이라고 생각하면 됨! 강아지집 하나 뚝딱 만드는 건 그냥 망치질만 잘하면 된다(= 혼자 하는 취미 코딩). 근데 63빌딩을 지으려면? 설계도 그려야 하고, 공정 관리해야 하고, 여러 팀이 협업해야 하고, 안전 검수도 받아야 한다.
소프트웨어 공학이 딱 이 "건축의 노하우"다. 코드를 짜는 건 망치질이고, 설계·협업·일정관리·테스트·유지보수까지 챙기는 게 소프트웨어 공학인 거다. 그냥 만드는 거랑 "무너지지 않게, 고치기 쉽게, 여럿이서" 만드는 건 다른 차원의 일 같음!
자세히
소프트웨어 개발 생명주기 (SDLC)
소프트웨어를 만드는 데도 정해진 흐름이 있다.
- 요구사항 분석 — 뭘 만들 건지, 누가 왜 쓸 건지 정리
- 설계 — 구조랑 화면, 데이터 흐름을 그림
- 구현(개발) — 실제 코드 작성
- 테스트 — 버그 잡고 의도대로 동작하는지 검증
- 배포 — 사용자에게 출시
- 유지보수 — 출시 후 고치고 개선 (사실 여기가 제일 길고 비중 큼!)
개발 방법론 (어떻게 일할 거냐)
- 워터폴(폭포수) — 1번부터 6번까지 순서대로 쭉. 단계가 끝나면 안 돌아감. 계획이 명확할 때 좋지만 변화에 약함.
- 애자일(Agile) — 짧게 끊어서(스프린트) 만들고 → 피드백 받고 → 또 개선. 요즘 대세. 대표적으로 스크럼, 칸반이 있음.
- 비유: 워터폴은 "완벽한 설계도 다 그리고 한 번에 짓기", 애자일은 "방 하나 만들어보고 살아보고 고치기"
챙겨야 하는 것들
- 요구사항/설계 — 잘못 만들면 코드 아무리 깔끔해도 헛수고
- 디자인 패턴 & 아키텍처 — 검증된 구조를 써서 유지보수하기 쉽게 (예: FSD, 아토믹 디자인, MVC)
- 형상관리(Git) — 누가 뭘 언제 바꿨는지 추적, 협업의 핵심
- 테스트 — 단위/통합/E2E 테스트로 품질 보장
- CI/CD — 빌드·테스트·배포를 자동화
- 문서화 & 코드 리뷰 — 나중의 나, 그리고 동료를 위한 투자
핵심 진실 하나
소프트웨어 비용의 대부분은 "처음 만들 때"가 아니라 "만든 다음 고치고 유지할 때" 나간다. 그래서 소프트웨어 공학은 "처음에 빨리 만들기"보다 "나중에 고치기 쉽게 만들기" 를 훨씬 중요하게 본다.
실사용 예
팀 프로젝트 한 번 해보면 이게 왜 중요한지 바로 와닿는다.
- 혼자 만들 땐 머릿속에 다 있으니까 막 짜도 됨. 근데 팀원이 생기는 순간 "내 코드를 남이 이해할 수 있게" 짜야 하고, 그게 소프트웨어 공학의 시작이다.
- Git으로 브랜치 나눠서 작업하고, 충돌(conflict) 해결하고, 코드 리뷰 받고 머지하는 게 형상관리의 실전이다.
- 애자일 스프린트로 "이번 주는 로그인, 다음 주는 투표 기능" 이렇게 끊어서 개발하고, 끝나면 회고하면서 개선함.
- 화면이 많아지고 컴포넌트가 늘어나면 아토믹 디자인이나 FSD 같은 아키텍처로 폴더 구조를 잡아야 나중에 안 꼬인다.
- 기능 추가할 때마다 손으로 배포하면 실수가 나니까 CI/CD로 자동화해두는 거다.
요구사항부터 보면 흐름이 이렇다. 사용자가 원하는 걸 듣고 → 요구사항/PRD 정리 → 화면·구조 설계 → 개발 → 테스트 → 배포 → 피드백 받고 다시 개선. 이 사이클을 잘 굴리는 게 PM·PO·개발자가 같이 하는 일이고, 그 판 전체를 설명하는 게 소프트웨어 공학 같음!
한 방 정리
| 구분 | 내용 |
|---|---|
| 한 줄 정의 | SW를 체계적으로 만들고 유지하는 방법론 |
| 비유 | 강아지집 vs 63빌딩 (혼자 vs 협업) |
| 핵심 흐름 | 요구분석 → 설계 → 개발 → 테스트 → 배포 → 유지보수 |
| 방법론 | 워터폴(순차) vs 애자일(반복) |
| 핵심 진실 | 비용의 대부분은 "유지보수"에서 나옴 |
쉽게 외우면 "코딩이 망치질이라면, 소프트웨어 공학은 건축 전체" — 이렇게 보면 감 잡힐 듯!
