WPAN과 WLAN은 연결 범위를 가리키지만 5G는 이동통신 방식이고 VPN은 기존 네트워크 위에 만드는 논리적 연결이다. 이름이 비슷하다고 범위를 한 줄로만 비교하면 서로 다른 분류 기준이 섞인다. 무선 용어가 나오면 거리, 접속 방식, 서비스 특성 중 무엇을 말하는지 먼저 확인한다. ## 핵심어 ![WPAN·WLAN·VPN·5G를 범위와 연결 방식으로 구분](/images/thumbnails/developer-vocabulary-network-scope-wireless-v3.png) WPAN과 WLAN은 통신 범위를, 5G는 이동통신 방식을, VPN은 기존 네트워크 위의 논리적 연결을 나타낸다. | 영단어 | 의미 | | --- | --- | | `Ad-hoc network` | 애드혹 네트워크란 네트워크의 구성 및 유지를 위해 기지국이나 액세스 포인트와 같은 기반 네트워크 장치를 필요로 하지 않고, 노드(node)들에 의해 자율적으로 구성되는 기반 구조가 없는 네트워크. | | `WPAN` | 단거리 무선망(Wireless Personal Area Network)이란 사용자 주변의 수 미터(m) 이내의 거리에서 휴대용 정보 단말기 등을 이용하여 필요한 정보를 처리할 수 있도록 구성한 무선 개인 영역 통신망. | | `WLAN` | 무선랜(Wireless Local Area Network)이란 무선 접속점(AP)이 설치된 곳을 중심으로 일정 거리 이내에서 무선랜 카드가 장착된 개인 휴대 정보 단말기를 통해 초고속 인터넷을 이용할 수 있는 무선 근거리 통신망. | | `WMAN` | 무선 대도시 통신망(Wireless Metropolitan Area Network)이란 고정 점대다점(Fixed Point-to-Multipoint) 연결중심의 광대역 무선 네트워크를 위한 대도시 영역을 커버하는 통신망. | | `WWAN` | 무선 광역 통신망(Wireless Wide Area Network)이란 유선 통신망을 설치하기 어려운 넓은 지역에서 무선 신호를 주고받을 수 있는 데이터 통신망. | | `ZigBee` | 지그비란 저속, 저비용, 저전력의 무선 망을 위한 기술. 주로 양방향 무선 개인 영역 통신망(WPAN) 기반의 홈 네트워크 및 무선 센서망에서 사용되는 기술. | | `Network Neutrality` | 망 중립성이란 모든 네트워크 사업자는 모든 콘텐츠를 동등하게 취급하고 어떠한 차별도 하지 않아야 한다는 원칙. | | `ISP (Internet Service Provider)` | 인터넷 서비스 제공자(Internet Service Provider)란 일반 사용자나 기업체, 기관, 단체 등이 인터넷에 접속하여 인터넷을 이용할 수 있도록 해 주는 사업자. | ## 함께 구분할 단어 | 영단어 | 의미 | | --- | --- | | `VPN` | 가상 사설 통신망(Virtual Private Network)이란 공중망 상에 사설망을 구축하여 마치 사설 구내망 또는 전용망 같이 이용하는 통신망. | | `ICMP` | 인터넷 제어 메시지 프로토콜(Internet Control Message Protocol)이란 TCP/IP 기반의 인터넷 통신 서비스에서 인터넷 프로토콜(IP)과 조합하여 통신 중에 발생하는 오류의 처리와 전송 경로의 변경 등을 위한 제어 메시지를 취급하는 무연결 전송(connectionless transmission)용의 프로토콜. | | `USIM` | 유심 카드(Universal Subscriber Identity Module Card)란 가입자 정보를 탑재한 심(SIM) 카드와 범용 IC 카드(UICC)가 결합된 형태로써 사용자 인증, 과금, 로밍 등 가입자 정보를 담고있는 이동통신 단말기에 삽입되는 스마트 카드. | | `Network Slicing` | 네트워크 슬라이싱이란 5G 네트워크의 새로운 기술로 하나의 물리적인 코어 네트워크 인프라(infrastructure)를 서비스 형태에 따라 다수의 독립적인 가상 네트워크로 분리하여 각각의 슬라이스를 통해 다양한 맞춤형 서비스를 제공하는 네트워크 기술. | | `eMBB` | 향상된 모바일 브로드밴드(enhanced Mobile BroadBand)란 5세대 이동 통신에서 사용자가 체감하는 대용량 데이터 전송 속도가 기존 모바일 브로드밴드보다 빠른 서비스. 초광대역 이동 통신. | | `URLLC` | 초고신뢰 저지연 통신(Ultra-Reliable and Low Latency Communications)이란 5세대 이동 통신(5G) 망에서 데이터 전송의 신뢰도가 매우 높고 지연 시간이 매우 짧은 통신. | | `mMTC` | 대규모 사물통신(massive Machine Type Communications)이란 IMT-2020(5G) 이동통신에서 비교적 저용량의 데이터를 저속으로 주고받는 다수의 사물 통신 기기가 서로 연결되어 정보를 주고받는 사물 통신을 일컫는 명칭. | | `NR` | 엔알(New Radio)이란 5세대(5G) 이동 통신에서 단말과 기지국 사이의 무선 접속(Radio Access 또는 무선 인터페이스) 기술. | ## 코드에서 만나는 단어 | 영단어 | 의미 | | --- | --- | | `GNSS` | 세계 위성 항법 시스템(Global Navigation Satellite System)이란 인공위성을 이용하여 위치를 파악하는 항법 시스템으로 위성에서 발신된 전파를 수신기에서 수신하여 위성과 수신기 간의 거리를 구하여 수신기의 위치를 결정. | | `SBAS` | 위성 기반 보정 시스템(Satellite-Based Augmentation System)이란 GNSS의 위치 오차를 보정한 정보를 위성을 통해 사용자에게 전달하는 광역(wide-area)의 위성 항법 보정 시스템. | | `SNG` | 에스엔지(Satellite News Gathering)란 야외에서 획득한 취재물을 위성을 통해 스튜디오로 전송하는 방식. | | `MNG` | 엠엔지(Mobile News Gathering)란 방송용 카메라에 엘티이(LTE), 와이브로(WiBro), 와이파이(Wi-Fi) 등에 접속할 수 있는 장비가 부착되어 촬영한 영상을 무선 통신망으로 전송하는 방식. | | `ENG` | 이엔지(Electronic News Gathering)란 녹화 기능이 탑재된 일체형 카메라 시스템으로 녹화 후 즉시 활용할 수 있기 때문에 뉴스 취재에서 기동성, 동시성, 경제성 등의 이점이 있음. | | `RFID` | Radio Frequency IDentification의 약어로 전파 신호를 통해 비접촉식으로 사물에 부착된 얇은 평면 형태의 태그를 식별하여 정보를 처리하는 시스템. | | `USN` | 유비쿼터스 센서 네트워크(Ubiquitous Sensor Network)란 각종 센서에서 감지한 정보를 무선으로 수집할 수 있도록 구성한 네트워크. | | `M2M` | 사물 통신(Machine to Machine)이란 기계, 센서, 컴퓨터 등 다양한 장치들이 유무선 통신 기술을 이용해 서로 정보를 교환하게 함으로써 개별 장치들의 기능이나 성능을 개선시켜 주고 개별 장치들이 제공하지 못했던 새로운 지능형 서비스를 제공함. | ## 실무 문서에서 만나는 장면 > WPAN부터 WWAN까지는 범위가 달라지고, eMBB·URLLC·mMTC는 5G가 노리는 서비스 특성이 다르다. 한 문장에 낯선 용어가 여러 개 보여도 전부 동시에 외울 필요는 없다. 먼저 주어와 동작을 찾고, 나머지는 범위·상태·도구를 보충하는 말로 나눈다. 단어가 길어 보여도 역할을 붙이면 문장이 작은 부품처럼 분해된다. 약어가 많아도 전부 새 기술은 아니다. 풀어 쓰고 역할을 붙이면 익숙한 구조가 보인다. ## 핵심 요약 **통신 범위, 접속 기술, 이동통신 서비스 특성을 나눠 본다.** - **Ad-hoc network** — 애드혹 네트워크란 네트워크의 구성 및 유지를 위해 기지국이나 액세스 포인트와 같은 기반 네트워크 장치를 필요로 하지 않고, 노드(node)들에 의해 자율적으로 구성되는 기반 구조가 없는 네트워크. - **eMBB** — 향상된 모바일 브로드밴드(enhanced Mobile BroadBand)란 5세대 이동 통신에서 사용자가 체감하는 대용량 데이터 전송 속도가 기존 모바일 브로드밴드보다 빠른 서비스. 초광대역 이동 통신. - **M2M** — 사물 통신(Machine to Machine)이란 기계, 센서, 컴퓨터 등 다양한 장치들이 유무선 통신 기술을 이용해 서로 정보를 교환하게 함으로써 개별 장치들의 기능이나 성능을 개선시켜 주고 개별 장치들이 제공하지 못했던 새로운 지능형 서비스를 제공함. 21:T1140, shell은 명령을 해석하고 pipeline은 한 명령의 출력을 다음 입력으로 잇는다. 한편 scheduling은 실행할 작업을 고르고 context switching은 CPU가 실행 대상을 바꾸며 상태를 저장·복원하는 과정이다. 명령의 흐름과 실행 주체의 전환을 나눠 읽으면 PCB의 역할도 분명해진다. ## 핵심어 ![스케줄링 선택과 문맥 교환을 PCB 상태와 연결](/images/thumbnails/developer-vocabulary-scheduling-unix-v3.png) 스케줄러는 실행할 작업을 고르고, 문맥 교환 때 PCB에 보관한 실행 상태를 다시 사용한다. | 영단어 | 의미 | | --- | --- | | `Scheduling` | 스케줄링. CPU나 입출력 장치 같은 자원을 어떤 작업에 어떤 순서로 배정할지 결정하는 과정이다. | | `Shell` | 사용자의 명령을 해석해 프로그램을 실행하고 입출력, 변수, 파이프라인 같은 기능을 제공하는 명령 해석 환경이다. | | `Pipeline` | 파이프라인이란 둘 이상의 명령을 함께 묶어 처리한 결과를 다른 명령의 입력으로 전환하는 기능. | | `Utility program` | 유틸리티 프로그램이란 컴퓨터의 여러 가지 처리 과정을 보조하여 시스템을 유지하고 성능을 개선하기 위하여 만든 프로그램. | | `macOS` | Apple이 Mac용으로 개발하는 운영체제의 현재 표기다. 과거의 Mac OS 표기와 구분한다. | ## 함께 구분할 단어 | 영단어 | 의미 | | --- | --- | | `UNIX` | 유닉스란 미국 벨(Bell) 연구소가 프로그래밍 연구와 개발을 촉진시킬 환경 조성을 목적으로 개발한 다수 사용자를 위한 운영 체계. | | `Linux` | Linux 커널과 이를 기반으로 한 운영체제 배포판을 가리킨다. 1991년 Linus Torvalds가 커널 개발을 시작했다. | | `Dispatch` | 디스패치란 준비 상태에서 대기하고 있는 프로세스 중 하나가 프로세서를 할당받아 실행 상태로 전이되는 과정. | | `Wake up` | 입출력 작업이 완료되어 프로세스가 대기 상태에서 준비 상태로 전이되는 과정. | | `Spooling` | 저속 주변 장치와 작업 처리 속도의 차이를 완화하기 위해 출력·입력 작업을 디스크 등의 대기열에 저장해 순차 처리하는 방식이다. | ## 코드에서 만나는 단어 | 영단어 | 의미 | | --- | --- | | `Context switching` | 문맥 전환이란 다중 프로그램 작성의 환경에서 어떤 프로그램의 실현을 중단하고 다른 프로그램의 실행을 재개할 때, 그 프로그램의 재개에 필요한 환경을 다시 설정하는 것. | | `Non-Preemptive scheduling` | 비선점 스케줄링이란 이미 할당된 CPU를 다른 프로세스가 강제로 빼앗아 사용할 수 없는 스케줄링 기법. | | `Preemptive scheduling` | 선점 스케줄링이란 하나의 프로세스가 CPU를 할당받아 실행하고 있을 때 우선순위가 높은 다른 프로세스가 CPU를 강제로 빼앗아 사용할 수 있는 스케줄링 기법. | | `PCB` | 프로세스 제어 블록(Process Control Block)이란 운영체제가 프로세스에 대한 중요한 정보를 저장해 놓는 곳. | ## 실무 문서에서 만나는 장면 > shell은 명령을 해석하고 pipeline은 출력을 다음 입력으로 잇는다. context switching은 CPU가 실행 대상을 바꾸는 비용을 동반한다. 한 문장에 낯선 용어가 여러 개 보여도 전부 동시에 외울 필요는 없다. 먼저 주어와 동작을 찾고, 나머지는 범위·상태·도구를 보충하는 말로 나눈다. 단어가 길어 보여도 역할을 붙이면 문장이 작은 부품처럼 분해된다. 용어가 몰려온다고 문서가 일부러 겁을 주는 것은 아니다. 대개는 분류가 아직 안 됐을 뿐이다. ## 핵심 요약 **작업 선택, 실행 전환, 명령 연결, 프로세스 기록을 나눠 본다.** - **Scheduling** — 스케줄링. CPU나 입출력 장치 같은 자원을 어떤 작업에 어떤 순서로 배정할지 결정하는 과정이다. - **Dispatch** — 디스패치란 준비 상태에서 대기하고 있는 프로세스 중 하나가 프로세서를 할당받아 실행 상태로 전이되는 과정. - **PCB** — 프로세스 제어 블록(Process Control Block)이란 운영체제가 프로세스에 대한 중요한 정보를 저장해 놓는 곳. 22:T1844, 주소를 알아내는 일과 데이터를 전송하는 일은 한 단계가 아니다. DNS는 이름을 IP 주소에 연결하고, ARP는 같은 링크에서 IP 주소에 대응하는 MAC 주소를 찾는다. 그 위에서 TCP·UDP는 포트로 대상을 구분하므로 오류가 난 위치에 따라 확인할 용어도 달라진다. ## 핵심어 ![DNS·ARP·TCP·UDP가 이름과 주소·포트를 잇는 흐름](/images/thumbnails/tcp-udp-ip-dns-arp-port-network-flow-v2.png) DNS는 이름을 IP 주소로 바꾸고, ARP는 같은 네트워크에서 IP 주소를 MAC 주소에 연결한다. TCP와 UDP는 포트로 통신 대상을 구분한다. | 영단어 | 의미 | | --- | --- | | `OSI 7 Layers` | OSI 7 계층 모델(Open system Interconnection 7 layer model)이란 국제 표준화 기구(ISO)가 1977년에 통신의 접속에서부터 완료하기까지의 과정을 7단계로 구분 정의한 국제 통신 표준 규약. | | `PDU` | 프로토콜 데이터 단위(Protocol Data Unit)란 OSI 기본 참조 모델에서의 정보 처리 단위의 하나로, 동일 계층 간에 교환되는 정보의 단위. | | `SDU` | 서비스 데이터 단위(Service Data Unit). 계층 간 서비스 접근점(SAP)을 통해 전달되는 데이터이며, 같은 계층끼리 교환하는 PDU와 구분한다. | | `SAP` | 서비스 접근점(Service Access Point)이란 개방형 시스템 간 상호 접속(OSI)의 인접하는 계층 간의 제어 동작에서 상위층이 하위층에서 제공하는 서비스를 받기 위해 하위층에 접근하는 점. | | `NIC` | 네트워크 인터페이스 카드(Network Interface Card)란 네트워크 카드, 이더넷 카드, LAN 어댑터, LAN 카드라고도 하며 컴퓨터와 컴퓨터 또는 컴퓨터와 네트워크를 연결하는 장치. | | `Protocol` | 프로토콜이란 서로 다른 기기들 간의 데이터 교환을 원활하게 수행할 수 있도록 표준화 시켜놓은 통신 규약. | ## 함께 구분할 단어 | 영단어 | 의미 | | --- | --- | | `TCP` | 전송 제어 프로토콜(Transmission Control Protocol)이란 OSI 기본 참조 모델을 기준으로 제4계층(전송 계층)에 해당되는 프로토콜로 인터넷 프로토콜(IP)과 함께 TCP/IP를 구성함. | | `UDP` | 사용자 데이터그램 프로토콜(User Datagram Protocol)이란 TCP/IP프로토콜 전송계층 통신 프로토콜중의 하나로서 비연결성이며 순서제어가 없음. | | `SNMP` | 간이 망 관리 프로토콜(Simple Network Management Protocol)이란 TCP/IP의 망 관리 프로토콜(RFC 1157). 라우터(router)나 허브(hub) 등 망 기기(network agent)의 망 관리 정보를 망 관리 시스템에 보내는 데 사용되는 표준 통신 규약. | | `IP` | 인터넷 프로토콜(Internet Protocol)이란 OSI 기본 참조 모델을 기준으로 하면 제3계층(네트워크 계층)에 해당되는 프로토콜로 IP 주소에 따라 다른 네트워크 간 패킷의 전송, 즉 경로 제어를 위한 규약으로 다른 네트워크 간의 데이터 전송을 가능하게 하는 것이 이 프로토콜의 특징. | | `FTP` | 파일 전송 프로토콜(File Transfer Protocol)이란 컴퓨터와 컴퓨터 또는 컴퓨터와 인터넷 사이에서 파일을 주고받을 수 있도록 하는 파일 전송 프로토콜. | | `SMTP` | 간이 전자 우편 전송 프로토콜(Simple Mail Transfer Protocol)이란 TCP/IP의 상위층 응용 프로토콜의 하나로, 컴퓨터 간에 전자 우편을 전송하기 위한 프로토콜. | ## 코드에서 만나는 단어 | 영단어 | 의미 | | --- | --- | | `ARP` | Address Resolution Protocol. 같은 IPv4 링크에서 대상 IPv4 주소에 대응하는 링크 계층 주소를 알아내는 프로토콜이다. | | `MAC Address` | 매체 접근 제어 주소(Media Access Control address)란 랜카드 제작사에서 대부분의 네트워크 인터페이스 어댑터(NIC)에 부여된 고유한 식별자. | | `MUX` | 다중화(Multiplexing)란 한 개의 통신 회선을 여러 가입자들이 동시에 사용하도록 하는 기능. | | `Sliding window` | 슬라이딩 윈도란 전송에서 송수신 동기 정보의 일반적인 관리 체계로 수신 측이 수신할 수 있는 최대 패킷의 수(윈도우 사이즈)를 정해서 수신 측으로부터 확인 신호를 받지 않더라도 정해진 패킷의 수만큼은 연속적으로 전송하는 방식. | | `OGSA` | 오픈 그리드 서비스 아키텍처(Open Grid Services Architecture)란 애플리케이션 공유를 위한 웹 서비스 표준과 인프라 자원의 공유를 위한 그리드 컴퓨팅 기술이 결합된 개방형 표준. (레거시 그리드 표준) | ## 실무 문서에서 만나는 장면 > IP는 주소와 전달을, TCP와 UDP는 전송 특성을, ARP는 같은 링크에서 주소 대응을 맡는다. 한 문장에 낯선 용어가 여러 개 보여도 전부 동시에 외울 필요는 없다. 먼저 주어와 동작을 찾고, 나머지는 범위·상태·도구를 보충하는 말로 나눈다. 단어가 길어 보여도 역할을 붙이면 문장이 작은 부품처럼 분해된다. 단어가 길다고 뜻까지 어려운 것은 아니다. 대상과 동작을 나누면 문장이 훨씬 얌전해진다. ## 핵심 요약 **계층마다 데이터 단위와 책임이 어떻게 달라지는지 본다.** - **OSI 7 Layers** — OSI 7 계층 모델(Open system Interconnection 7 layer model)이란 국제 표준화 기구(ISO)가 1977년에 통신의 접속에서부터 완료하기까지의 과정을 7단계로 구분 정의한 국제 통신 표준 규약. - **SNMP** — 간이 망 관리 프로토콜(Simple Network Management Protocol)이란 TCP/IP의 망 관리 프로토콜(RFC 1157). 라우터(router)나 허브(hub) 등 망 기기(network agent)의 망 관리 정보를 망 관리 시스템에 보내는 데 사용되는 표준 통신 규약. - **OGSA** — 오픈 그리드 서비스 아키텍처(Open Grid Services Architecture)란 애플리케이션 공유를 위한 웹 서비스 표준과 인프라 자원의 공유를 위한 그리드 컴퓨팅 기술이 결합된 개방형 표준. (레거시 그리드 표준) 23:T12d4, 서버에서 서비스를 켰는데 재부팅 뒤 다시 접속하니 멈춰 있다. `systemctl start`를 실행했으니 앞으로도 계속 켜질 거라고 생각하기 쉽다. 하지만 **지금 실행 중인지**와 **다음 부팅 때 자동으로 시작할지**는 서로 다른 상태다. 이 둘을 분리해서 확인하면 불필요한 재설치나 설정 변경을 피할 수 있다. ## systemctl start는 현재 실행 상태를 바꾼다 ![핵심 관계: 처음에 inactive·disabled인 서비스를 기준으로 start는 현재 실행을 active로 바꾸고, enable은 부팅 시 시작 설정을 enabled로 바꿉니다](/images/thumbnails/linux-systemctl-start-enable-difference-v10.png) 처음에 inactive·disabled인 서비스를 기준으로 start는 현재 실행을 active로 바꾸고, enable은 부팅 시 시작 설정을 enabled로 바꿉니다. enable만 적용하면 현재 실행은 inactive 그대로입니다. `start`는 해당 서비스를 지금 시작하도록 systemd에 요청한다. 다음 예제의 `demo-web.service`는 설명용 서비스 이름이다. 실제 환경에서는 관리하려는 서비스의 정확한 유닛 이름을 먼저 확인해야 한다. ```bash sudo systemctl status demo-web.service sudo systemctl start demo-web.service sudo systemctl status demo-web.service ``` 첫 `status`와 마지막 `status`를 비교해 현재 상태가 바뀌었는지 본다. `active (running)`이라면 프로세스가 지금 동작 중이라는 뜻이다. 반대로 시작 명령이 실패했다면 상태 화면의 오류 메시지부터 확인해야 한다. 자동 시작 설정을 바꾸는 것으로 실행 실패 자체가 해결되지는 않는다. `start`는 이미 실행 중인 서비스를 새 설정으로 다시 읽게 만드는 명령도 아니다. 서비스가 멈춰 있었다면 시작하고, 실행 중인 서비스에 변경된 설정을 적용하려면 그 서비스의 재시작이나 재적용 방식이 필요한지 별도로 판단한다. ## systemctl enable은 다음 부팅을 위한 설정이다 `enable`은 부팅 과정에서 서비스를 자동 시작할 수 있도록 유닛의 활성화 설정을 만든다. **지금 멈춰 있는 서비스를 곧바로 실행시키는 명령으로 읽으면 안 된다.** ```bash sudo systemctl enable demo-web.service sudo systemctl status demo-web.service ``` 두 번째 명령에서 여전히 비활성 상태가 보일 수 있다. 그때는 `enable`이 실패했다고 바로 결론 내리지 말고, 현재 실행 상태와 부팅 자동 시작 설정을 구분한다. 지금도 서비스가 필요하다면 `start`를 추가로 실행한다. 반대로 부팅 시 자동 시작만 예약하고 현재는 테스트를 멈춰 두고 싶다면 굳이 `start`를 하지 않아도 된다. 자동 시작이 필요 없어졌다면 `disable`로 그 설정을 해제한다. 이 역시 현재 실행 중인 프로세스를 즉시 정지시키는 명령과는 다르다. 당장 중지하려면 `stop`을 별도로 검토해야 한다. ## 재부팅 뒤 멈췄을 때는 무엇부터 확인할까? 먼저 `status`에서 현재 실행 상태와 표시된 자동 시작 설정을 나누어 읽는다. 서비스가 현재 실행 중이고 자동 시작만 빠져 있다면 `enable` 여부가 핵심이다. 자동 시작 설정은 있는데 서비스가 멈춰 있다면, 시작에 실패했을 가능성을 살펴야 한다. ```bash sudo systemctl status demo-web.service sudo journalctl -u demo-web.service ``` 서비스별 로그에서 오류가 발생한 시점과 내용을 확인한다. 실행 파일이 없거나 서비스가 참조하는 파일·작업 디렉터리·환경이 준비되지 않은 경우라면, `enable`을 반복해도 부팅 실패가 해결되지 않는다. 로그 확인은 원인을 좁히기 위한 단계이지, 이 두 명령만으로 모든 서비스 문제를 진단할 수 있다는 뜻은 아니다. 운영 서버에서는 무턱대고 `restart`하기 전에 이 서비스가 요청을 처리 중인지와 중단 가능 시간을 확인한다. 재부팅 테스트도 서비스 영향과 복구 경로를 확보한 뒤에 진행한다. `status`와 로그로 상태를 기록한 다음 한 가지 변경을 적용하고 다시 확인하면, 어떤 조치가 효과를 냈는지 알기 쉽다. ## 핵심 요약: 현재 실행과 부팅 자동 시작은 별개다 `systemctl start`는 **지금 실행**, `systemctl enable`은 **다음 부팅 때 자동 시작**을 위한 설정이다. 재부팅 뒤 서비스가 멈춘다면 현재 상태, 자동 시작 설정, 서비스 로그를 순서대로 확인한다. 실패 로그가 보이는데 `enable`만 반복하거나, 자동 시작 설정이 없는데 `start`만 반복하면 같은 문제를 다시 만날 수 있다. 24:T1859, 브라우저의 요청은 웹 계층과 WAS를 지나 데이터베이스에 닿을 수 있지만 각 층의 책임은 다르다. IaaS는 그 실행 기반을 제공하고 SLA는 약속한 서비스 수준을 설명한다. 장애 대비 문서에서는 RPO·RTO·HA가 각각 데이터 손실, 복구 시간, 가용성의 어느 목표를 가리키는지 구분한다. ## 핵심어 ![브라우저에서 WAS와 클라우드 인프라로 이어지는 경로](/images/thumbnails/developer-vocabulary-web-server-cloud-operations-v3.png) 브라우저의 요청은 웹 계층을 지나 WAS와 데이터베이스로 이어진다. IaaS는 이를 실행할 인프라를 제공한다. | 영단어 | 의미 | | --- | --- | | `availability` | 가용성. 필요할 때 시스템이나 서비스가 정상 기능을 제공할 수 있는 정도다. 보통 일정 기간의 정상 서비스 시간 비율과 복구 능력을 함께 본다. | | `WAS(Web Application Server)` | 웹 애플리케이션 서버. 동적 요청을 실행하고 세션, 트랜잭션, 데이터베이스 연동 같은 애플리케이션 서비스를 제공하는 서버 소프트웨어를 가리킨다. | | `SLA` | Service Level Agreement. 서비스 제공자와 이용자가 가용성, 응답 시간, 지원 범위, 측정 방법과 책임 등을 합의한 문서다. | | `PaaS` | Platform as a Service. 애플리케이션 개발·실행에 필요한 런타임, 배포 환경과 관리 기능을 서비스로 제공한다. | | `SaaS` | Software as a Service. 공급자가 운영하는 소프트웨어를 네트워크를 통해 사용하게 하는 서비스 모델이다. | | `IaaS` | Infrastructure as a Service. 컴퓨팅, 스토리지, 네트워크 같은 인프라 자원을 가상화해 필요에 따라 제공하는 서비스 모델이다. | | `SAN` | 스토리지 전용 네트워크(Storage Area Network)란 컴퓨터 간을 연결하는 근거리 통신망(LAN)과는 달리 하드디스크 등의 외부 저장 장치(스토리지)끼리 고속으로 연결된 통신망. | ## 함께 구분할 단어 | 영단어 | 의미 | | --- | --- | | `RPO` | Recovery Point Objective. 장애 후 복구할 데이터 시점을 뜻하며, 허용 가능한 데이터 손실량을 시간으로 나타낸다. | | `RTO` | Recovery Time Objective. 장애 발생 후 서비스를 복구해야 하는 목표 시간이다. | | `NAS` | 네트워크 연결 스토리지(Network-Attached Storage)란 개인용 컴퓨터(PC) 사용자가 네트워크를 통해 데이터를 전송 및 공유할 수 있도록 여러 개의 하드 디스크 드라이브(HDD)가 네트워크로 구성된 대용량 저장 장치. | | `DAS` | 직접 연결 저장장치(Direct Attached Storage)란 네트워크 경유 없이 전용 케이블로 서버나 컴퓨터에 직접 연결된 외장형 저장 장치로 서버 자체에 물리적으로 외부 저장 장치를 연결하는 것. | | `HA` | High Availability. 장애가 발생해도 서비스를 지속하거나 빠르게 복구하도록 구성해 가용 시간을 높이는 설계와 운영 특성이다. | | `ITSM` | 정보기술 서비스 관리(Information Technology Service Management)란 정보 시스템 사용자가 만족할 수 있는 서비스를 제공하고 지속적인 관리를 통해 서비스의 품질을 유지, 증진하기 위한 일련의 활동, 즉 기업 내부의 기존 정보 통신(IT) 관리 역할을 서비스 관점으로 바꿔 고객 중심의 IT 서비스를 관리하는 기법. | | `ITIL` | IT 서비스 관리의 모범 사례와 관리 체계를 정리한 프레임워크다. 특정 과거 소유 주체 설명보다 현재 적용 버전과 공식 지침을 확인한다. | ## 코드에서 만나는 단어 | 영단어 | 의미 | | --- | --- | | `APM` | 애플리케이션 성능 관리(Application Performance Management)란 최종 사용자에게 향상된 서비스를 제공하기 위해 애플리케이션의 흐름 모니터링과 성능 예측을 통해 최적의 애플리케이션 상태를 보장하고 관리하는 것. | | `Load balancer` | 로드 밸런서란 특정 서버에 집중되는 부하를 경감시키기 위해 여러 서버로 부하를 분산시키는 네트워크 서비스. | | `Session` | 세션이란 사용자 또는 프로세스 간의 데이터 교환을 위한 논리적인 연결. | | `Classic ASP (Active Server Pages)` | Microsoft IIS에서 서버 측 스크립트로 동적 페이지를 만드는 레거시 기술이다. Application Service Provider나 ASP.NET과 구분한다. (레거시 기술) | | `Jakarta Server Pages (JSP)` | Jakarta Server Pages. 서버에서 동적 웹 콘텐츠를 생성하는 Jakarta EE 기술이다. 과거에는 JavaServer Pages라는 이름을 사용했다. (현재 명칭으로 갱신) | ## 실무 문서에서 만나는 장면 > RPO는 얼마나 잃을 수 있는지, RTO는 얼마나 늦게 복구할 수 있는지 묻는다. HA는 그 목표를 돕는 구성이다. 한 문장에 낯선 용어가 여러 개 보여도 전부 동시에 외울 필요는 없다. 먼저 주어와 동작을 찾고, 나머지는 범위·상태·도구를 보충하는 말로 나눈다. 단어가 길어 보여도 역할을 붙이면 문장이 작은 부품처럼 분해된다. 외운 단어가 자꾸 섞이는 건 기억력보다 경계의 문제일 때가 많다. 짝 단어와 차이를 함께 보면 된다. ## 핵심 요약 **서비스 계층, 가용성 목표, 복구 목표와 운영 도구를 구분한다.** - **availability** — 가용성. 필요할 때 시스템이나 서비스가 정상 기능을 제공할 수 있는 정도다. 보통 일정 기간의 정상 서비스 시간 비율과 복구 능력을 함께 본다. - **NAS** — 네트워크 연결 스토리지(Network-Attached Storage)란 개인용 컴퓨터(PC) 사용자가 네트워크를 통해 데이터를 전송 및 공유할 수 있도록 여러 개의 하드 디스크 드라이브(HDD)가 네트워크로 구성된 대용량 저장 장치. - **Jakarta Server Pages (JSP)** — Jakarta Server Pages. 서버에서 동적 웹 콘텐츠를 생성하는 Jakarta EE 기술이다. 과거에는 JavaServer Pages라는 이름을 사용했다. (현재 명칭으로 갱신) 25:T11f2, 서버 한 대를 만들고 그 안에 웹 서버를 설치해야 한다. Terraform과 Ansible을 모두 쓰는 자료를 보면 “둘 중 하나만 써야 하나?”라는 질문이 생긴다. 두 도구는 겹치는 일을 할 수도 있지만, 이 예에서는 **클라우드 자원을 만들고 추적하는 일**과 **만들어진 서버의 소프트웨어를 설정하는 일**로 책임을 나누면 이해하기 쉽다. ## Terraform은 어떤 상태를 관리할까? ![핵심 관계: 이 예시에서는 Terraform이 VM과 네트워크 자원의 수명주기를, Ansible이 만들어진 VM 내부의 패키지·설정·서비스 구성을 담당하도록 책임을 나눕니다](/images/thumbnails/terraform-ansible-provision-config-boundary-v10.png) 이 예시에서는 Terraform이 VM과 네트워크 자원의 수명주기를, Ansible이 만들어진 VM 내부의 패키지·설정·서비스 구성을 담당하도록 책임을 나눕니다. 두 도구의 절대적인 기능 한계를 뜻하지는 않습니다. Terraform은 구성 파일에 원하는 인프라를 선언하고, 상태 데이터로 관리 중인 실제 자원과의 연결을 추적한다. 가상 예를 들면 VM, 네트워크, 방화벽 규칙을 만들고 변경 계획을 확인하는 역할이다. ```text Terraform 구성: VM 1대 + 네트워크 규칙 현재 클라우드: VM 0대 plan에서 확인할 질문: 어떤 자원이 새로 생기고 바뀌는가? ``` `terraform plan`은 변경을 **제안**하고 `apply`는 변경을 실행한다. 계획을 읽지 않고 적용하면 의도하지 않은 삭제나 재생성이 있을 수 있다. 상태 파일에는 인프라 정보가 담기므로 접근 권한과 보관 방식을 신중히 정해야 한다. 교육 자료의 `init → plan → apply` 순서는 이런 변경 흐름을 이해하는 출발점이다. ## 만들어진 서버에서 Ansible이 맡는 일 Ansible은 인벤토리에서 관리 대상을 정하고 Playbook의 작업으로 소프트웨어 설치·설정 같은 단계를 자동화한다. 예를 들어 Terraform이 VM을 만든 뒤, Ansible이 그 VM에 웹 서버 패키지와 설정 파일을 적용하는 식이다. ```text 관리 대상: 새로 만든 VM Playbook의 목표: 웹 서버 패키지 설치, 설정 파일 배치 다시 실행할 때 확인할 질문: 이미 맞는 설정도 불필요하게 바꾸는가? ``` Ansible의 많은 모듈은 원하는 상태가 이미 맞으면 변경하지 않도록 설계되지만, **모든 Playbook이 자동으로 멱등적인 것은 아니다.** 임의 셸 명령이나 외부 API 호출을 넣었다면 반복 실행 결과를 직접 확인해야 한다. 이 경계는 [Ansible Playbook 설명](https://docs.ansible.com/projects/ansible/latest/playbook_guide/playbooks_intro.html)과 대조했다. ## 경계를 나눈 뒤 어떤 실패를 점검할까? VM은 생성됐는데 Ansible 연결이 실패한다면 먼저 VM 주소·네트워크 규칙·접속 계정을 확인한다. 패키지는 설치됐는데 앱이 동작하지 않는다면 설정 파일, 서비스 상태와 로그를 본다. 두 단계의 오류를 한 덩어리로 취급하면 Terraform 구성을 다시 적용해야 할지, Playbook만 고쳐야 할지 판단하기 어렵다. 반대로 Terraform 밖에서 클라우드 자원을 수동 변경하면 상태와 실제 인프라가 어긋날 수 있다. `plan`으로 차이를 보고 수동 변경을 유지할지 되돌릴지 결정한다. Ansible도 대상 서버에 수동 변경이 쌓이면 반복 실행 시 덮어쓸 수 있으므로, 변경 책임과 소유자를 정해야 한다. 두 도구를 동시에 적용할 때는 출력값 전달, 실행 순서, 실패 후 재시도 범위를 명확히 한다. ## 도구 하나만 사용할 때의 경계 작은 실습에서 특정 도구 하나로 필요한 일을 모두 처리할 수는 있다. 이 글의 구분은 절대 법칙이 아니라 책임을 읽기 쉽게 나누는 설계 예다. 팀이 익숙한 도구, 관리 자원의 종류, 변경 승인·감사 요구에 따라 경계는 달라진다. 중요한 것은 **같은 자원을 서로 다른 도구가 경쟁해 덮어쓰지 않도록** 소유권을 정하는 것이다. ## 핵심 요약: 생성과 내부 구성을 책임별로 나눈다 Terraform은 클라우드 자원 구성과 상태 추적, Ansible은 서버 안의 소프트웨어·설정 적용에 적합한 경우가 많다. 먼저 변경 계획과 반복 실행 결과를 각각 확인하고, 두 도구가 같은 설정을 동시에 소유하지 않게 한다. 26:Tfcd, S3 콘솔에서 `logs` 폴더를 만들었다. 그런데 객체 목록을 코드로 읽으니 `logs/`라는 0바이트 객체가 나온다. '폴더를 만들었는데 파일이 생겼다고?' 파일 탐색기와 같은 모습이라 더 헷갈린다. 여기서는 **콘솔의 폴더 표시**와 **S3에 저장된 객체 키**를 같은 예제로 구분해 보자. ## S3 폴더는 왜 실제 디렉터리가 아닐까? 일반 목적 S3 버킷의 기본 저장 단위는 객체다. 각 객체에는 버킷 안에서 이름 역할을 하는 키(key)가 있다. 예를 들어 `logs/app.log`는 `logs` 디렉터리 안의 파일이라기보다, 슬래시(`/`)가 들어 있는 하나의 객체 키다. 콘솔은 공통으로 시작하는 `logs/` 부분을 모아 폴더처럼 보여 준다. ![핵심 관계: S3에 저장되는 것은 슬래시를 포함한 객체 키이고, 콘솔이 공통 접두사로 묶어 폴더처럼 보여 줍니다](/images/thumbnails/s3-folder-prefix-object-key-zero-byte-v10.png) S3에 저장되는 것은 슬래시를 포함한 객체 키이고, 콘솔이 공통 접두사로 묶어 폴더처럼 보여 줍니다. logs/ 0바이트 객체와 logs/app.log도 각각 별도 키이며 logs-old/는 다른 접두사입니다. ## 빈 폴더가 0바이트 객체로 보이는 이유 다음은 한 버킷에 있다고 가정한 객체 키 세 개다. - `logs/`: 콘솔에서 빈 `logs` 폴더를 만들 때 생성된 0바이트 표시 객체 - `logs/app.log`: 콘솔의 `logs` 안에 보이는 실제 로그 객체 - `logs-old/app.log`: `logs-old` 안에 보이는 별개의 객체 콘솔에서 ‘폴더 만들기’로 빈 `logs`를 생성하면 키가 `logs/`인 **0바이트 객체**를 만든다. [AWS의 S3 폴더 설명](https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-folders.html)도 일반 목적 버킷의 평평한 구조와 이 표시 객체를 구분한다. 반면 `logs/app.log`를 바로 업로드했다면 `logs/` 객체를 따로 만들지 않아도 콘솔에는 `logs` 폴더가 보일 수 있다. 폴더를 보여 주는 근거가 공통 접두사이기 때문이다. 따라서 `logs/` 표시 객체만 지워도 `logs/app.log`가 남아 있다면 폴더처럼 보이는 묶음은 남는다. 둘 다 없다면 그 이름의 빈 폴더를 유지할 실제 객체도 없다. **폴더 모양과 0바이트 객체를 같은 것으로 취급하지 않는 것**이 핵심이다. ## prefix로 조회할 때 `logs`와 `logs/`는 무엇이 다를까? 접두사 검색은 글자 그대로 ‘이 문자열로 시작하는 키’를 찾는다. 위 세 키에서 `logs`로 찾으면 `logs-old/app.log`까지 걸린다. `logs/`로 좁히면 `logs/` 표시 객체와 `logs/app.log`만 남는다. 슬래시 하나가 다른 작업의 로그를 섞지 않게 한다. ```python keys = ["logs/", "logs/app.log", "logs-old/app.log"] print([key for key in keys if key.startswith("logs")]) print([key for key in keys if key.startswith("logs/")]) print([key for key in keys if key.startswith("logs/") and key != "logs/"]) ``` ```text ['logs/', 'logs/app.log', 'logs-old/app.log'] ['logs/', 'logs/app.log'] ['logs/app.log'] ``` 이 짧은 코드는 S3에 접속하는 대신 **객체 키의 문자열 조건**만 검산한다. 실제 목록 API에서도 `Prefix`로 `logs/`를 지정할 때는 표시 객체 `logs/`가 결과에 포함될 수 있으므로, 파일만 처리할 때는 그 키를 한 번 더 구분해야 한다. 폴더를 정리하거나 경로별 파일 수를 셀 때 특히 유용한 차이다. ## 핵심 요약 일반 목적 S3 버킷의 ‘폴더’는 객체 키의 공통 접두사를 콘솔이 묶어 보여 준 것이다. 콘솔에서 빈 폴더를 직접 만들면 `logs/` 같은 0바이트 객체가 생길 수 있지만, 하위 객체가 있으면 그 표시 객체 없이도 폴더가 보인다. 목록을 `logs`로 검색하면 `logs-old`까지 섞일 수 있으니, 의도한 경계가 폴더라면 `logs/`로 조회하고 표시 객체와 실제 파일을 구분하자. 27:T117d, EBS 스냅샷을 만들었으니 그 순간의 모든 데이터가 안전하게 들어갔다고 생각하기 쉽다. 하지만 애플리케이션이 아직 메모리나 운영체제 버퍼에 쓰기를 보관하고 있었다면, **볼륨에 기록된 시점**과 **애플리케이션이 완료했다고 믿는 시점**이 다를 수 있다. 스냅샷은 유용한 복구 수단이지만, 생성 버튼을 눌렀다는 사실만으로 애플리케이션 데이터의 일관성이 보장되지는 않는다. ## EBS 스냅샷은 어느 데이터를 담을까? ![핵심 관계: 애플리케이션 버퍼에만 남은 쓰기는 볼륨 스냅샷에 포함된다고 볼 수 없다](/images/thumbnails/aws-ebs-snapshot-buffer-consistency-restore-v10.png) 애플리케이션 버퍼에만 남은 쓰기는 볼륨 스냅샷에 포함된다고 볼 수 없다. 쓰기를 정리해 볼륨에 반영하는 경계와, 복원 뒤 데이터를 검증하는 단계를 구분한다. 애플리케이션 버퍼와 볼륨 데이터의 차이를 고려하고 스냅샷 뒤 복원 시험까지 확인한다. EBS 볼륨 스냅샷은 볼륨의 특정 시점을 보존한다. 예를 들어 10시에 주문 데이터 쓰기가 시작돼 앱은 성공 응답을 준비했지만, 일부 데이터가 아직 버퍼에만 있다면 스냅샷이 그 데이터를 포함한다고 단정할 수 없다. 이 시간 예시는 원리를 설명하기 위한 가상 상황이다. | 시점 | 애플리케이션 쪽 | EBS 볼륨 쪽 | | --- | --- | --- | | 쓰기 요청 직후 | 버퍼에 변경 내용이 남을 수 있음 | 아직 반영되지 않았을 수 있음 | | 쓰기 정리 뒤 | 필요한 변경이 디스크로 전달됨 | 스냅샷 대상 상태에 가까워짐 | | 복원 뒤 | 앱의 데이터 구조 검사가 필요 | 볼륨 파일만 있다고 성공은 아님 | AWS도 [EBS 스냅샷 생성 설명](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-creating-snapshot.html)에서 애플리케이션이나 운영체제가 캐시한 데이터는 스냅샷에 포함되지 않을 수 있으며, 일관성과 완전성을 위해 쓰기를 일시 중지할 것을 권장한다. 교육 자료는 ‘특정 시점 볼륨 복사’까지 설명하지만 이 안전 경계는 따로 보완해야 한다. ## 쓰기 중인 서비스에서는 무엇을 준비할까? 읽기 전용 파일 보관용 볼륨과 계속 쓰는 데이터베이스 볼륨은 요구하는 일관성 수준이 다르다. 데이터베이스라면 해당 DB가 제공하는 백업·체크포인트 절차와 복구 가능 지점을 확인한다. 스냅샷 전후에 쓰기 중단, 버퍼 비우기, 파일시스템 동결 같은 조치를 사용할지는 애플리케이션과 운영 절차에 맞춰 결정해야 한다. **검증 없이 동결 명령을 운영 서버에 복사해 실행해서는 안 된다.** 동결을 했다면 풀리는 경로와 실패 시 복구 방법까지 준비해야 한다. 한 데이터가 여러 볼륨에 나뉘어 있다면 각 볼륨을 아무 때나 따로 캡처한 결과가 하나의 일관된 애플리케이션 상태인지 별도로 검토한다. 스냅샷이 ‘성공’으로 표시되는 것과 데이터베이스가 정상적으로 열리는 것은 다른 검사다. ## 복원 시험에서 무엇을 확인할까? 생성된 스냅샷으로 격리된 환경에 새 볼륨을 만들고 파일이 있는지만 보지 말고, 애플리케이션이 데이터를 실제로 읽는지 확인한다. 주문 같은 데이터라면 기준 시점의 건수와 중요한 키가 복원되는지, 쓰기 중이던 기록은 어떤 상태인지 비교한다. 복원 시험에 운영 고객 데이터를 사용할 경우 접근 권한과 개인정보 처리 범위를 먼저 정해야 한다. 보관 기간과 비용, 필요한 복구 시점도 함께 결정한다. 오래 보관한 스냅샷이 많아도 요구한 시점으로 복구할 수 없다면 계획이 부족한 것이다. 특정 AWS 계정에서 테스트했다거나 실제 운영 복구에 성공했다는 주장은 이 글에 포함하지 않는다. ## 핵심 요약: 스냅샷 성공과 데이터 복구 성공은 다르다 EBS 스냅샷은 볼륨의 시점을 담지만 앱·OS 버퍼의 미기록 데이터까지 자동으로 보장하지는 않는다. 쓰기 중인 서비스는 일관성 절차를 정하고, 스냅샷 생성 뒤에는 **격리된 복원 시험으로 실제 데이터 읽기**까지 확인해야 한다. 28:T10b2, Git에는 복제본 수가 2로 적혀 있는데 클러스터에서는 3개가 실행 중이다. 배포가 실패했다는 뜻일까, 누군가 급하게 수동 변경한 걸까? GitOps에서는 **Git에 기록한 원하는 상태**와 **클러스터의 현재 상태**를 비교한다. 두 상태가 다르면 Argo CD가 `OutOfSync`를 보여 줄 수 있다. 이 표시만 보고 곧바로 ‘동기화’ 버튼을 누르기 전에 차이가 생긴 이유를 확인해야 한다. ## GitOps에서 비교하는 두 상태는 무엇인가? ![핵심 관계: Git에 선언한 replicas는 2, 클러스터의 현재 값은 3이므로 차이가 OutOfSync로 표시된다](/images/thumbnails/argocd-gitops-outofsync-live-state-v10.png) Git에 선언한 replicas는 2, 클러스터의 현재 값은 3이므로 차이가 OutOfSync로 표시된다. Sync로 Git의 선언에 맞추는 일과 어느 값을 유지할지 판단하는 일은 별개이다. Git에 선언한 원하는 상태와 클러스터의 현재 상태를 비교해 차이를 찾는다. 교육 자료의 Argo CD 실습은 Git 저장소의 Guestbook 애플리케이션을 등록하고 수동으로 동기화하는 흐름을 다룬다. 여기서는 실제 저장소를 수정하지 않는 가상 복제본 수로 비교한다. ```yaml # Git에 기록한 Deployment 일부(설명용) spec: replicas: 2 ``` | 위치 | 복제본 수 | 의미 | | --- | ---: | --- | | Git 설정 | 2 | 다음에 맞추고 싶은 상태 | | 클러스터 현재 값 | 3 | 지금 실제로 관찰되는 상태 | 이 둘이 다르다는 사실과 어느 쪽이 **옳은 결정**인지는 별개다. 긴급 대응으로 3개를 수동 설정했다면 이를 그대로 유지할지, Git을 3으로 바꿀지, 원래의 2로 되돌릴지 팀이 판단해야 한다. Argo CD는 차이를 보여 줄 수 있지만 제품 요구와 장애 상황을 대신 결정하지는 않는다. ## Sync를 누르면 무엇이 바뀔까? 동기화는 Git의 원하는 구성과 클러스터의 실제 구성을 맞추는 작업이다. 위 예에서 단순히 Git의 2를 적용한다면 현재의 3이 2로 줄어들 수 있다. 사용자 요청을 처리 중인 인스턴스 수가 줄어도 되는지 확인하지 않고 버튼부터 누르면 긴급 대응을 되돌릴 수 있다. Argo CD가 [Git과 현재 상태 차이를 기준으로 동기화한다는 설명](https://argo-cd.readthedocs.io/en/stable/user-guide/auto_sync/)도 이 경계를 명확히 한다. 수동 동기화에서는 담당자가 차이를 읽고 반영 시점을 고른다. 자동 동기화를 켜면 차이가 발견될 때 반영이 더 빠를 수 있지만, 의도적인 임시 변경도 다시 맞춰질 수 있다. 자동 동기화 여부와 정리(prune) 같은 별도 옵션을 섞어 생각하지 말고 현재 애플리케이션 정책을 확인한다. 모든 `OutOfSync`가 같은 이유로 생기지는 않으며, 컨트롤러가 정상적으로 바꾸는 필드도 있을 수 있다. ## 차이를 조사할 때 어떤 순서가 안전할까? 먼저 Git에서 현재 선택된 브랜치·리비전과 경로가 의도한 것인지 확인한다. 그다음 Argo CD가 보여 주는 차이가 어떤 Kubernetes 리소스의 어떤 필드인지 읽는다. 마지막으로 그 필드가 배포 작업, 자동 확장, 수동 장애 조치 중 무엇 때문에 달라졌는지 확인한다. 원인을 알면 Git을 변경할지, 클러스터를 되돌릴지, 예상된 차이로 관리할지 선택할 수 있다. 운영 환경에서는 동기화가 삭제·축소를 수반할 수 있으므로 변경 범위와 되돌림 경로를 먼저 검토한다. 화면이 초록색으로 바뀌는 것보다 실제 서비스가 기대한 상태인지가 중요하다. 교육 자료의 실습 흐름을 실제 운영 장애 해결 경험으로 포장하지 않고, 여기서는 판단 순서만 설명한다. ## 핵심 요약: OutOfSync는 차이 신호이지 자동 정답이 아니다 `OutOfSync`는 Git에 적은 상태와 클러스터 현재 상태가 다르다는 신호다. 동기화 전에 **어떤 필드가 왜 달라졌는지**, 적용하면 무엇이 줄거나 바뀌는지 확인한다. 그다음 Git을 수정할지, 현재 상태를 되돌릴지 결정하자. 29:T11be, 장바구니 수량은 헤더와 상품 화면에서 함께 보여야 한다. 하지만 장바구니 패널이 열렸는지는 그 패널 버튼과 화면에서만 쓰인다. 둘 다 상태라는 이유로 한 스토어에 몰아넣으면 값의 책임이 흐려진다. **누가 그 값을 읽고 바꾸는지**를 먼저 보면 Zustand 스토어와 React 지역 상태의 경계를 잡기 쉽다. ## 여러 화면이 공유하는 값만 스토어 후보로 본다 ![핵심 관계: 패널 열림 open은 CartPanel 내부의 지역 상태로 남고, 장바구니 count는 공유 스토어에서 두 컴포넌트가 읽습니다](/images/thumbnails/zustand-store-vs-local-state-panel-cart-v10.png) 패널 열림 open은 CartPanel 내부의 지역 상태로 남고, 장바구니 count는 공유 스토어에서 두 컴포넌트가 읽습니다. 값을 누가 공유하는지에 따라 상태의 소유 경계를 나눕니다. 다음 예제는 장바구니 수량을 여러 컴포넌트가 공유한다는 가정이다. Zustand의 `create`로 스토어를 만들고, 컴포넌트에서는 필요한 값이나 동작만 선택한다. ```jsx import { create } from 'zustand'; import { useState } from 'react'; const useCartStore = create((set) => ({ count: 0, addOne: () => set((state) => ({ count: state.count + 1 })), })); function HeaderCount() { const count = useCartStore((state) => state.count); return 장바구니 {count}; } function CartPanel() { const [open, setOpen] = useState(false); const count = useCartStore((state) => state.count); const addOne = useCartStore((state) => state.addOne); return (

{open && }

); } ``` `count`가 바뀌면 헤더와 패널이 같은 수량을 읽는다. 반면 `open`은 패널의 표시 여부만 결정하므로 `useState`로 그 컴포넌트 가까이에 둔다. 이 값까지 무조건 전역 스토어로 옮기면 다른 화면과 공유할 필요가 없는 변경까지 공통 상태 설계에 끌어들이게 된다. 코드는 상태 위치를 설명하려는 작은 예제이며 실제 장바구니 결제 로직이 아니다. ## 선택자(selector)는 왜 필요한가? `useCartStore((state) => state.count)`는 스토어 전체가 아니라 `count`를 선택한다. 교육 자료도 필요한 상태와 액션만 고르는 패턴을 강조한다. 스토어 전체를 한 번에 읽는 컴포넌트는 다른 필드가 바뀔 때도 영향을 더 쉽게 받을 수 있다. 실제 리렌더 범위는 선택 값의 동일성·컴포넌트 구조에 따라 확인해야 하므로 ‘선택자 하나면 성능 문제가 모두 해결된다’고 보지 않는다. API의 기본 형태는 [Zustand 시작 문서](https://zustand.docs.pmnd.rs/learn/getting-started/introduction)와 맞춰 확인했다. 둘 이상의 값을 새 객체로 만들어 반환하는 선택자를 쓸 때는 반환 참조가 매번 바뀌는지도 점검한다. 성능을 이유로 모든 필드를 잘게 쪼개기 전에, 실제로 어느 컴포넌트가 자주 다시 그려지는지 측정하는 편이 낫다. ## 상태 위치가 잘못됐는지 어떻게 테스트할까? 상품 화면에서 수량을 올렸을 때 헤더 수량도 바뀌는지 확인한다. 패널을 닫고 다시 열어도 수량은 유지돼야 하지만, 다른 화면의 패널 열림 상태가 뜻밖에 따라 바뀌면 `open`의 범위가 너무 넓을 수 있다. 새로고침 뒤에도 수량을 보존해야 한다면 그것은 메모리 스토어만으로 해결되는지 별도 요구사항으로 정해야 한다. 공유와 영구 저장은 같은 개념이 아니다. 계정별 장바구니처럼 서버 데이터가 진짜 기준이라면 클라이언트 스토어만을 최종 원본으로 삼지 않는다. 서버 응답, 인증 경계, 동시 수정과 재조회 정책을 따로 설계한다. 모든 상태를 전역화하기보다, 데이터의 소유자와 수명을 먼저 정하는 것이 안전하다. ## 핵심 요약: 공유 범위와 수명을 먼저 정한다 여러 컴포넌트가 함께 읽는 수량은 Zustand 스토어 후보이고, 한 패널의 열림 여부는 지역 `useState`가 자연스럽다. 선택자로 필요한 값만 읽되, 서버 데이터와 새로고침 보존은 별개의 문제로 다룬다. 2a:T1010, `/settings/profile`로 이동했는데 공통 메뉴만 보이고 프로필 화면은 비어 있다. 자식 라우트를 `children`에 넣었다면, 부모 컴포넌트에는 그 자식이 들어갈 **자리**가 필요하다. React Router에서 그 자리가 ``이다. URL이 맞는지와 화면에 그릴 위치가 있는지를 따로 점검하자. ## children은 경로를, Outlet은 화면 자리를 정한다 ![핵심 관계: children의 profile 경로가 일치해도 부모 SettingsLayout에 Outlet 자리가 없으면 자식 화면이 표시되지 않습니다](/images/thumbnails/react-router-nested-route-outlet-missing-child-v10.png) children의 profile 경로가 일치해도 부모 SettingsLayout에 Outlet 자리가 없으면 자식 화면이 표시되지 않습니다. 경로 선택과 실제 렌더링 자리를 별도 경계로 읽어야 합니다. 다음 예제는 React Router Data Mode의 작은 라우트 트리다. 부모 경로 `/settings`에 공통 레이아웃을 두고, 자식 경로 `profile`에 프로필 내용을 둔다. ```jsx import { createBrowserRouter, Outlet } from 'react-router'; import { RouterProvider } from 'react-router/dom'; function SettingsLayout() { return (

설정

); } function Profile() { return

프로필 설정 화면

; } const router = createBrowserRouter([ { path: '/settings', element: , children: [{ path: 'profile', element: }], }, ]); export default function App() { return ; } ``` `/settings/profile`에서는 부모 레이아웃이 먼저 보이고, `` 위치에 `Profile`이 그려진다. `children`을 설정해도 부모에서 ``을 지우면 자식 화면을 표시할 자리가 없다. 반대로 ``만 있고 해당 URL에 맞는 자식 경로가 없다면 자식 내용이 비어 있는 것이 자연스럽다. 정확한 렌더링 계약은 [React Router의 Outlet 설명](https://reactrouter.com/api/components/Outlet)에서 확인할 수 있다. ## URL이 맞는데 화면이 비면 무엇부터 볼까? 첫째, 현재 URL이 부모 경로와 자식 경로를 합친 `/settings/profile`인지 확인한다. 둘째, `children` 배열에서 `profile`이 부모의 자식인지 본다. 셋째, 부모가 실제 렌더링하는 컴포넌트에 ``이 있는지 확인한다. 공통 레이아웃 코드만 보지 말고 조건부 렌더링 때문에 Outlet 자체가 사라지는지도 살펴본다. 예제의 자식 경로는 앞에 `/`를 붙이지 않은 상대 경로다. 팀 코드에서 절대 경로와 상대 경로를 섞어 쓰면 의도와 다른 라우트가 될 수 있으므로, 최종 URL을 기준으로 테스트한다. `/settings`만 열었을 때 기본 화면이 필요하다면 별도 인덱스 자식 라우트를 설계해야 한다. 빈 화면이 언제나 오류인 것은 아니다. ## 레이아웃을 나눌 때의 운영 판단 부모 레이아웃은 여러 자식 화면이 공유하는 제목·메뉴·경계에 적합하다. 자식 화면에만 필요한 데이터 로딩이나 오류 처리를 모두 부모에 몰아넣으면 작은 페이지 변경에도 공통 레이아웃이 복잡해진다. 먼저 어느 요소를 모든 자식이 공유하는지 정하고, 나머지는 자식 라우트에 둔다. 브라우저에서 `/settings/profile`로 직접 접근하는 테스트와 내부 링크로 이동하는 테스트를 모두 한다. 직접 접근만 실패한다면 Outlet 문제가 아니라 서버의 SPA 경로 처리일 수 있다. 같은 화면의 실패라도 라우터 매칭, 화면 자리, 서버 응답을 나눠 보면 원인을 더 빨리 찾는다. ## 핵심 요약: 중첩 경로에는 렌더링 자리도 필요하다 `children`이 자식 경로를 정의하고 ``이 부모 화면에서 자식이 들어갈 위치를 만든다. URL은 맞는데 부모만 보인다면 자식 경로 매칭과 Outlet 렌더링을 차례로 확인하자. 2b:Tfa6, ‘길게 눌러야 실행’이라고 적힌 버튼을 아주 짧게 누르고 뗐는데 잠시 뒤 작업이 실행된다. 누르기 시작할 때 `setTimeout`을 예약해 놓고, 손을 뗄 때 그 예약을 취소하지 않았기 때문이다. 길게 누르기는 **타이머를 시작하는 코드와 취소하는 코드가 한 쌍**이어야 한다. ## setTimeout은 누르기가 끝나도 자동으로 사라지지 않는다 ![핵심 관계: pointerdown에서 예약한 타이머는 콜백 실행 전 pointerup·pointercancel·pointerleave가 오면 같은 정리 함수로 해제한다](/images/thumbnails/javascript-press-hold-cleartimeout-pointercancel-v10.png) pointerdown에서 예약한 타이머는 콜백 실행 전 pointerup·pointercancel·pointerleave가 오면 같은 정리 함수로 해제한다. 예약 시간이 지난 콜백 경로와 취소 경로를 분리해야 한다. 누르기 타이머는 pointerup뿐 아니라 pointercancel 경로에서도 해제해야 한다. `setTimeout`은 지정한 시간이 지난 뒤 함수를 한 번 실행하도록 예약하고 타이머 ID를 돌려준다. 누르고 있는 동안에만 예약이 유효해야 한다면, 손을 떼거나 입력이 취소될 때 `clearTimeout(ID)`를 호출한다. 다음 예제는 실제 삭제나 결제를 하지 않고 상태 문구만 바꾸는 설명용 버튼이다. ```html

대기 중

``` 800밀리초는 동작을 설명하기 위한 예시일 뿐 보편적인 UX 기준은 아니다. 짧게 눌렀다 떼면 예약된 함수를 취소한다. 충분히 누르면 콜백이 먼저 실행되고 `timerId`가 다시 `null`이 된다. 누르는 중 다른 곳으로 포인터가 이동하거나 입력 자체가 취소돼도 정리한다. 누르기를 여러 번 시작했을 때 이전 예약이 남지 않도록 `pointerdown`에서 먼저 취소하는 이유도 여기에 있다. ## 타이머가 남는지 어떻게 재현하고 테스트할까? 먼저 짧게 누르고 800밀리초보다 길게 기다려 `확인 완료`가 나오지 않는지 본다. 다음에는 충분히 누른 뒤 한 번만 완료되는지 확인한다. 누르는 중 포인터를 버튼 밖으로 옮기거나 터치 입력이 취소될 때도 결과가 뒤늦게 바뀌지 않아야 한다. 느린 컴퓨터나 백그라운드 탭에서는 타이머 시각이 정확히 맞지 않을 수 있으므로 밀리초 단위의 정밀한 시계로 취급하지 않는다. 이 최소 예제는 **포인터 입력**만 보여 준다. 키보드 이용자를 위한 별도 조작이나 동등한 확인 수단 없이 실제 중요한 작업의 유일한 관문으로 사용하면 안 된다. 특히 계정 삭제나 결제처럼 되돌리기 어려운 작업을 클라이언트의 타이머만으로 승인하지 않는다. 서버 쪽 권한 확인과 별도의 확인 절차가 필요하다. ## 핵심 요약: 예약한 타이머의 종료 경로를 함께 설계한다 `setTimeout`으로 길게 누르기를 예약했다면 `pointerup`, `pointercancel`, 이탈처럼 누르기가 끝나는 경로에서 `clearTimeout`을 호출한다. 짧은 누르기, 긴 누르기, 입력 취소를 각각 테스트하고, 중요한 작업은 프런트엔드 타이머만 믿지 않는다. 2c:T11ff, 두 파일을 동시에 읽다가 첫 번째가 실패했다. `Promise.all`의 `catch`가 실행됐으니 두 번째도 멈췄을까? 로그를 조금 더 지켜보면 두 번째 작업은 끝난다. **묶음의 결과가 실패한 것**과 **이미 시작한 개별 작업을 취소한 것**은 다르다. ## Promise.all의 거부는 작업 취소가 아니다 ![핵심 관계: A가 10ms에 실패하면 묶음 Promise.all은 거부되지만, 이미 시작한 B는 계속 실행되어 30ms에 완료된다](/images/thumbnails/javascript-promise-all-rejection-pending-work-v10.png) A가 10ms에 실패하면 묶음 Promise.all은 거부되지만, 이미 시작한 B는 계속 실행되어 30ms에 완료된다. 묶음의 거부는 개별 작업의 자동 취소가 아니다. Promise.all은 한 작업의 실패로 거부되지만, 이미 시작된 다른 작업까지 자동 취소하지는 않는다. `Promise.all([a, b])`은 `a`와 `b`가 모두 이행되면 순서대로 값을 담은 배열로 이행한다. 둘 중 하나가 거부되면 반환한 묶음 Promise는 그 이유로 거부된다. 하지만 이 동작은 입력 Promise에 ‘중단’ 신호를 보내지 않는다. 아래 코드는 실제 파일이나 네트워크를 사용하지 않고, 서로 다른 시간에 끝나는 두 작업을 만든다. 첫 번째는 빠르게 실패하고 두 번째는 나중에 완료된다. ```javascript async function main() { const failed = new Promise((_, reject) => { setTimeout(() => { console.log("A failed"); reject(new Error("A unavailable")); }, 10); }); const slow = new Promise((resolve) => { setTimeout(() => { console.log("B finished"); resolve("B result"); }, 30); }); try { await Promise.all([failed, slow]); } catch (error) { console.log("all rejected:", error.message); } await slow; } main(); ``` ```text A failed all rejected: A unavailable B finished ``` 마지막 `await slow`는 두 번째 작업의 완료를 관찰하기 위해 넣었다. 이것이 작업을 다시 시작하는 것은 아니다. `slow`는 `Promise.all`에 전달하기 전에 이미 만들어졌다. 첫 번째 실패로 묶음의 결과는 사용할 수 없지만, 두 번째 타이머는 계속 살아 있다. ## 첫 실패 뒤에도 완료 로그가 나오는지 어떻게 확인할까? 실제 코드에서 ‘전체 실패’ 직후 완료 로그가 늦게 찍히면 재시도 로직이 중복 실행됐다고 오해하기 쉽다. 먼저 각 작업의 시작·성공·실패 로그에 **같은 요청 식별자**와 개별 작업 이름을 붙여 시간 순서를 확인하자. 민감한 응답 본문이나 인증 헤더를 로그에 남길 필요는 없다. 테스트에서는 빠른 실패와 느린 성공을 의도적으로 만들고, 묶음의 `catch`가 먼저 실행돼도 느린 작업의 완료 효과가 남는지 검사한다. 만약 느린 작업이 DB 수정이나 메시지 발송처럼 부작용을 가진다면, 첫 실패 뒤에도 그 부작용이 생길 수 있다는 점까지 테스트해야 한다. `catch` 안에서 다시 같은 묶음을 바로 재시도하면 이전 작업과 새 작업이 겹칠 수 있기 때문이다. ## 모든 결과가 필요한가, 실제 취소가 필요한가 성공·실패를 작업별로 모두 모아 보고 싶다면 `Promise.allSettled`를 검토한다. 하나가 거부되어도 나머지의 최종 상태를 기다려 `{ status: "fulfilled", value }` 또는 `{ status: "rejected", reason }` 형태로 받는다. 다만 이것도 **취소 기능은 아니다.** 반대로 한 작업이 실패하면 다른 작업도 멈춰야 하는 요구라면 각 작업이 지원하는 취소 방법을 별도로 설계해야 한다. 예를 들어 `fetch`는 신호를 받을 수 있지만, 이미 서버에서 처리된 요청까지 되돌리는 보장은 아니다. 서버 작업에는 중복 요청에 안전한 식별자와 보상·정리 정책이 필요할 수 있다. ‘빨리 오류를 알려 주기’와 ‘남은 작업을 멈추기’를 같은 요구로 취급하지 않는 것이 핵심이다. ## 핵심 요약: 묶음의 실패와 개별 작업의 종료를 나누자 `Promise.all`은 입력 중 하나가 거부되면 반환한 Promise를 거부하지만 다른 입력을 자동 취소하지 않는다. 작업별 최종 결과가 필요하면 `allSettled`를, 실제 중단이 필요하면 해당 작업의 취소 계약을 살펴야 한다. 부작용이 있는 병렬 작업을 재시도하기 전에는 이전 작업이 정말 끝났는지 확인하자. 4b:I[565,["6804","static/chunks/6804-6b8010ad786c8ca1.js","4340","static/chunks/4340-e63ccfe2c52fc43d.js","9408","static/chunks/app/%5Blang%5D/tags/%5Btag%5D/page-81afb6b55aae59ec.js"],"Image"] 5a:I[50678,["6804","static/chunks/6804-6b8010ad786c8ca1.js","4340","static/chunks/4340-e63ccfe2c52fc43d.js","9408","static/chunks/app/%5Blang%5D/tags/%5Btag%5D/page-81afb6b55aae59ec.js"],"HeaderSearch"] 5b:I[92622,["6804","static/chunks/6804-6b8010ad786c8ca1.js","4340","static/chunks/4340-e63ccfe2c52fc43d.js","9408","static/chunks/app/%5Blang%5D/tags/%5Btag%5D/page-81afb6b55aae59ec.js"],"ThemeToggle"] 80:I[55781,[],"IconMark"] 2d:T103c, 검색창 옆 ‘미리보기’를 누르자 페이지가 다시 열린다. 클릭 이벤트를 연결한 적도 없는데 폼이 제출된 것처럼 보인다. `

` 안에서 ` ``` 두 줄은 비슷하게 꾸밀 수 있지만 사용자에게 약속하는 동작은 다르다. `/help`는 설명용 주소다. 패널을 여는 버튼에는 별도 JavaScript 동작을 연결해야 하며, 이 HTML만으로 패널이 자동으로 열리지는 않는다. 주소가 바뀌는 탐색이라면 링크, 화면 상태를 바꾼다면 버튼을 먼저 생각하자. ## form 안에서 type을 생략하면 왜 제출될까? 다음 검색 폼에는 미리보기와 검색이라는 두 버튼이 있다. 각각의 목적을 `type`으로 명시한다. ```html 검색어

``` `type="button"`은 버튼 자체의 제출 동작을 막는다. 미리보기 기능을 만들려면 그 버튼에 클릭 핸들러를 추가한다. `type="submit"`은 검색어를 제출한다. `preview`의 `type`을 생략하면 일반적인 폼 맥락에서 제출 버튼이 되어, 미리보기 동작과 별도로 요청이 나갈 수 있다. 정확한 기본 동작의 조건은 [HTML 표준의 button 정의](https://html.spec.whatwg.org/dev/form-elements.html#the-button-element)에서 확인할 수 있다. 예제의 `method="get"`은 검색어가 URL에 보일 수 있다. 비밀번호나 비밀값을 입력받는 폼에 그대로 사용하면 안 된다. 버튼의 종류를 고르는 일과 전송되는 데이터의 보안 판단은 따로 해야 한다. ## 예상치 못한 제출을 어떻게 확인할까? 브라우저에서 미리보기 버튼을 누르고 주소 변경과 네트워크 요청이 있는지 본다. `type="button"`을 붙인 뒤 같은 입력으로 다시 시도해 미리보기 클릭으로는 제출되지 않는지 확인한다. 마지막으로 검색 버튼과 Enter 키의 원래 제출 흐름이 유지되는지도 테스트한다. 미리보기만 고치고 검색을 망가뜨리지 않기 위해서다. 모든 폼의 제출을 `preventDefault()`로 막으면 필요한 제출까지 사라질 수 있다. 먼저 버튼의 의미를 올바르게 표현하고, 진짜 제출은 서버에서 다시 입력값을 검증한다. 클릭이 한 번 잘 동작했다는 사실만으로 잘못된 값이나 권한 없는 요청이 차단된 것은 아니다. ## 핵심 요약: 버튼 역할을 type으로 분명히 쓴다 주소로 이동하면 ``, 현재 화면 동작은 `

#보안

암호·개인정보 용어: encryption·RSA·signature·TLS의 역할

보안 공격 용어: malware·ransomware·spoofing·XSS의 방식