모든 것은 조용한 터미널에서 시작된다
처음 ROS2를 설치하고 터미널을 여는 순간은 이상할 만큼 평온하다. 아직 로봇은 움직이지 않고, 바퀴도 돌지 않으며, 센서도 아무것도 말하지 않는다. 화면에는 커서 하나가 깜박일 뿐이다. 하지만 로봇 개발에서 가장 많은 문제가 시작되는 곳은 대개 이 조용한 순간이다.
지난 장에서 우리는 ROS2가 여러 노드의 대화를 엮어 하나의 로봇 시스템을 만든다는 사실을 살펴보았다. 이제부터는 그 대화가 실제로 어떻게 시작되는지 확인해야 한다. 그런데 여기서 중요한 점이 있다. ROS2를 배운다는 것은 단순히 명령어를 성공시키는 일이 아니다. 명령어가 실패했을 때, 또는 성공한 것처럼 보이지만 아무 일도 일어나지 않을 때, 그 침묵이 무엇을 뜻하는지 읽는 일이다.
로봇 시스템은 겉으로는 멀쩡해 보여도 내부에서 이미 어긋나 있을 수 있다. 한 터미널은 ROS2 환경을 알고 있지만, 다른 터미널은 모른다. 어떤 노드는 데이터를 보내고 있지만, 구독자는 다른 통신 영역을 바라보고 있다. 빌드는 성공했지만 새로 만든 패키지가 실행 목록에 나타나지 않는다. 이런 작은 어긋남은 지금 당장은 사소한 불편처럼 보인다. 그러나 나중에 센서, 지도, 내비게이션, 실제 모터 제어가 붙으면 문제의 그림자는 훨씬 길어진다.
그래서 이번 장의 주인공은 로봇이 아니라 터미널이다. 정확히는 터미널에 남는 작은 흔적들이다. 명령어의 응답, 보이지 않는 환경 변수, 조용히 생성되는 폴더, 아무 말 없이 비어 있는 토픽 목록. 우리는 그 흔적을 따라가며 ROS2의 첫 실행과 작업공간의 감각을 익힐 것이다.
설치가 끝났다는 말의 함정
많은 입문자는 ROS2 설치를 하나의 문장으로 생각한다. "ROS2를 설치했다." 하지만 이 문장은 생각보다 많은 것을 숨기고 있다. 어떤 운영체제에 설치했는지, 어떤 배포판을 설치했는지, 바이너리 패키지로 설치했는지, 소스에서 빌드했는지, 터미널 환경 설정을 적용했는지에 따라 결과가 달라질 수 있다.
ROS2 공식 문서는 설치 방식이 여러 가지일 수 있으며, 바이너리 패키지 설치와 소스 빌드 모두 제대로 구성하면 사용할 수 있는 ROS2 환경을 만든다고 설명한다. 다만 입문 단계에서는 보통 운영체제와 ROS2 배포판의 조합을 맞추고, 검증된 패키지 설치 방식을 따르는 편이 안전하다.1
여기서 배포판이라는 말이 나온다. ROS2의 배포판은 ROS2 생태계의 특정 버전 묶음이라고 생각하면 된다. 예를 들어 Humble, Iron, Jazzy 같은 이름이 붙는다. 각 배포판은 지원하는 운영체제 버전과 패키지 구성이 다르다. 이 조합이 맞지 않으면 설치는 어찌어찌 되었는데 예제가 제대로 동작하지 않거나, 특정 패키지를 찾지 못하는 일이 생긴다.
초반에는 다음 세 가지를 분명히 확인하는 습관이 필요하다.
내가 사용하는 운영체제 버전
설치한 ROS2 배포판 이름
현재 터미널에 ROS2 환경이 적용되었는지 여부
이 세 가지는 단순한 체크리스트가 아니다. 나중에 "왜 내 컴퓨터에서는 안 되지?"라는 질문을 만났을 때 가장 먼저 돌아와야 할 지점이다. 로봇 개발의 많은 불길한 전조는 복잡한 알고리즘이 아니라, 서로 맞지 않는 버전과 적용되지 않은 환경 설정에서 시작된다.
첫 번째 이상 징후: 명령어를 모르는 터미널
설치를 마친 뒤 가장 먼저 확인하고 싶은 것은 ros2 명령어다.
ros2 --help정상이라면 ROS2 명령어에서 사용할 수 있는 여러 하위 명령이 나타난다. run, node, topic, service, param, launch 같은 단어들이 보이면 이제 터미널이 ROS2의 존재를 알고 있다는 뜻이다.
하지만 종종 이런 반응을 만난다.
ros2: command not found처음 보면 설치가 망가진 것처럼 느껴진다. 하지만 이 메시지는 대개 더 단순한 사실을 말한다. 현재 터미널이 ROS2 명령어의 위치를 모른다는 뜻이다. ROS2를 설치했다고 해서 모든 터미널이 자동으로 ROS2 환경을 기억하는 것은 아니다. 터미널마다 필요한 환경 설정을 읽어야 한다.
보통 ROS2 환경은 다음과 같은 명령으로 적용한다. 배포판 이름은 설치한 버전에 맞게 바꾸어야 한다.
source /opt/ros/humble/setup.bash이 명령에서 source는 파일에 적힌 환경 설정을 현재 터미널에 적용하라는 뜻이다. /opt/ros/humble/setup.bash는 Humble 배포판이 설치된 위치의 설정 파일이다. 이 파일을 읽으면 터미널은 ROS2 명령어가 어디에 있는지, 패키지를 어디에서 찾아야 하는지, 실행할 때 어떤 경로를 참고해야 하는지 알게 된다.
다시 확인해 보자.
ros2 --help이번에는 명령어 목록이 나타날 것이다. 작은 변화지만 의미는 크다. 방금 전까지 터미널은 ROS2의 이름조차 몰랐다. 이제는 ROS2의 도구들을 호출할 수 있다. 로봇 시스템의 첫 문이 열린 셈이다.
그러나 여기서 또 하나의 질문이 남는다. 새 터미널을 열 때마다 이 명령을 매번 입력해야 할까? 꼭 그럴 필요는 없다. 자주 쓰는 환경 설정은 사용자의 셸 설정 파일에 추가할 수 있다. bash를 사용한다면 보통 ~/.bashrc 파일에 다음 줄을 넣는다.
echo "source /opt/ros/humble/setup.bash" >> ~/.bashrc
source ~/.bashrc~/.bashrc는 새 bash 터미널이 열릴 때 자동으로 읽는 설정 파일이다. 이곳에 ROS2 환경 설정을 추가하면 새 터미널도 ROS2를 자연스럽게 알아본다.
하지만 여기에는 조심할 점이 있다. 여러 ROS2 배포판을 함께 설치했거나, 프로젝트마다 다른 환경을 사용한다면 무조건 자동 설정하는 것이 오히려 혼란을 만들 수 있다. 자동으로 편해진 만큼, 지금 어떤 환경을 보고 있는지 감각을 잃기 쉽다. 편리함은 좋지만, 편리함이 흔적을 숨기기 시작하면 디버깅은 어려워진다.
두 개의 목소리: talker와 listener
ROS2가 제대로 동작하는지 확인하는 가장 간단한 방법은 예제 노드 두 개를 실행해 보는 것이다. 하나는 메시지를 보내고, 다른 하나는 그 메시지를 듣는다. 이름도 직관적이다. talker와 listener다.
먼저 첫 번째 터미널을 열고 ROS2 환경이 적용되어 있는지 확인한다. 필요하다면 다음 명령을 실행한다.
source /opt/ros/humble/setup.bash그리고 C++ 예제의 talker를 실행한다.
ros2 run demo_nodes_cpp talker정상적으로 실행되면 talker는 일정한 간격으로 문장을 발행한다. 발행한다는 것은 토픽이라는 통로에 데이터를 내보낸다는 뜻이다. 지난 장에서 신문사와 구독자의 비유를 떠올리면 된다. talker는 신문사처럼 메시지를 계속 찍어 낸다.
이제 두 번째 터미널을 연다. 여기서 중요한 장면이 나온다. 두 번째 터미널도 별개의 터미널이다. 첫 번째 터미널에 ROS2 환경을 적용했다고 해서 두 번째 터미널까지 자동으로 알고 있는 것은 아니다. 그러므로 두 번째 터미널에서도 환경을 적용한다.
source /opt/ros/humble/setup.bash그다음 listener를 실행한다.
ros2 run demo_nodes_py listener정상이라면 listener가 talker의 메시지를 받아 출력한다. 두 노드는 서로 직접 연결된 것처럼 보이지만, 실제로는 ROS2의 통신 구조 안에서 같은 토픽을 통해 만난다. talker는 자신을 듣는 노드가 누구인지 자세히 알 필요가 없다. listener도 talker 내부 코드가 어떻게 생겼는지 몰라도 된다. 둘은 같은 약속을 공유하기 때문에 만난다.
이 장면은 작지만 중요하다. 로봇의 LiDAR 노드와 장애물 회피 노드, 위치 추정 노드와 내비게이션 노드도 결국 이 원리의 확장 위에 있다. 지금은 단순한 문자열이 오가지만, 나중에는 거리 데이터, 위치 정보, 속도 명령, 지도 정보가 같은 방식으로 흐른다.
침묵하는 listener가 말해 주는 것
예제가 항상 한 번에 성공하면 좋겠지만, 현실은 조금 다르다. talker는 무언가를 계속 출력하는데 listener가 아무것도 받지 못할 수 있다. 또는 listener를 실행하려는 순간 패키지를 찾을 수 없다고 말할 수도 있다. 이때 중요한 것은 당황하지 않는 것이다. 침묵은 실패가 아니라 단서다.
먼저 가장 단순한 가능성을 확인한다. 두 터미널 모두 ROS2 환경을 읽었는가?
ros2 --help한쪽 터미널에서 이 명령이 실패한다면 그 터미널은 아직 ROS2 환경을 모른다. 다시 source /opt/ros/humble/setup.bash를 실행한다.
다음으로 확인할 것은 노드 목록이다.
ros2 node list이 명령은 현재 ROS2 네트워크에서 발견되는 노드들을 보여 준다. talker가 실행 중이라면 관련 노드 이름이 나타나야 한다. listener도 실행 중이면 함께 보인다. 아무것도 보이지 않는다면 노드가 실행되지 않았거나, 현재 터미널이 같은 통신 영역을 바라보지 못하고 있을 수 있다.
토픽 목록도 확인해 보자.
ros2 topic list정상적인 talker 예제에서는 /chatter 같은 토픽이 보인다. /chatter는 talker가 메시지를 내보내는 통로다. 토픽이 보인다면 이번에는 실제로 어떤 데이터가 흐르는지 엿볼 수 있다.
ros2 topic echo /chatterecho는 토픽으로 흘러가는 메시지를 터미널에 그대로 보여 주는 명령이다. 이 명령은 ROS2를 배울 때 매우 자주 쓰인다. 로봇이 이상하게 움직일 때도 같은 방식으로 접근한다. 먼저 데이터가 흐르는지 본다. 흐른다면 내용이 정상인지 본다. 내용이 정상이라면 그 데이터를 받는 노드가 제대로 처리하는지 본다. 이렇게 문제를 한 단계씩 좁혀 간다.
겉으로 보기에는 단순한 예제지만, 여기에는 ROS2 디버깅의 기본 자세가 들어 있다. 막연히 "안 된다"고 말하는 대신, 다음 질문으로 나누어 보는 것이다.
노드는 실행 중인가
토픽은 존재하는가
메시지는 실제로 흐르는가
메시지를 받아야 할 노드가 같은 통신 영역에 있는가
메시지 형식은 서로 맞는가
이 질문들은 앞으로 계속 반복된다. 자율주행 로봇이 목표 지점으로 가지 못할 때도, LiDAR가 RViz에 보이지 않을 때도, Nav2가 경로를 만들지 못할 때도 출발점은 비슷하다. 로봇의 침묵을 작은 질문으로 나누는 것. 그것이 ROS2를 배우는 첫 번째 감각이다.
숨겨진 기록: 환경 변수
터미널에는 보이지 않는 기록이 있다. 바로 환경 변수다. 환경 변수는 프로그램이 실행될 때 참고하는 설정값이다. 사용자가 매번 말하지 않아도 시스템이 알고 있어야 하는 정보가 여기에 들어간다.
ROS2에서 특히 자주 마주치는 환경 변수 중 하나가 ROS_DOMAIN_ID다. ROS2는 DDS 기반의 분산 통신을 사용하며, 같은 네트워크 안에서 노드들이 서로를 발견할 수 있다. 이때 ROS_DOMAIN_ID는 통신 영역을 나누는 번호처럼 사용할 수 있다. 쉽게 말해 같은 방에 있는 노드들끼리만 대화하게 만드는 표식이다.
현재 값을 확인하려면 다음 명령을 사용한다.
echo $ROS_DOMAIN_ID아무것도 출력되지 않을 수도 있다. 그렇다고 반드시 문제가 있는 것은 아니다. 값이 설정되지 않았으면 기본값을 사용하는 경우가 많다. 하지만 여러 사람이 같은 네트워크에서 ROS2 실습을 하거나, 한 컴퓨터에서 여러 실험을 동시에 돌릴 때는 이 값이 중요해진다.
예를 들어 첫 번째 터미널에서는 다음과 같이 설정했다고 해 보자.
export ROS_DOMAIN_ID=7그런데 두 번째 터미널에서는 다른 값을 사용한다.
export ROS_DOMAIN_ID=11이 경우 두 터미널의 노드는 서로를 발견하지 못할 수 있다. talker는 분명히 말하고 있는데 listener는 듣지 못한다. 같은 컴퓨터 안에서 실행했는데도 마치 서로 다른 방에 갇힌 것처럼 조용해지는 것이다.
이런 문제는 무섭게 보이지만 원리는 단순하다. 대화하려는 노드들이 같은 통신 영역에 있어야 한다. 그러므로 이상이 생기면 환경 변수를 확인해야 한다. 터미널은 거짓말을 하지 않지만, 모든 것을 먼저 말해 주지도 않는다. 개발자가 질문해야 답한다.
환경 변수 전체를 보고 싶다면 다음 명령을 사용할 수 있다.
printenv | grep ROS이 명령은 현재 환경 변수 중 ROS라는 글자가 들어간 항목을 찾아 보여 준다. grep은 특정 문자열을 걸러 내는 도구다. 처음에는 낯설 수 있지만, 터미널에서 단서를 찾을 때 매우 유용하다.
작업공간이라는 낡은 서랍
예제 노드를 실행해 보았다면 이제 자연스럽게 다음 질문이 떠오른다. "내 노드는 어디에 만들어야 할까?"
ROS2 프로젝트는 보통 작업공간, 즉 워크스페이스 안에서 관리한다. 워크스페이스는 여러 패키지를 담는 큰 폴더다. 패키지는 하나의 기능 묶음이라고 생각하면 된다. 센서 드라이버 패키지, 제어 패키지, 메시지 정의 패키지, 시뮬레이션 패키지처럼 역할에 따라 나눌 수 있다.
ROS2에서 패키지를 빌드할 때 자주 사용하는 도구가 colcon이다. 공식 튜토리얼에서도 colcon을 사용해 ROS2 워크스페이스를 빌드하는 흐름을 입문 과정으로 다룬다.2 colcon은 여러 패키지의 의존 관계를 파악하고, 필요한 순서대로 빌드해 주는 도구다. 의존 관계란 어떤 패키지가 다른 패키지의 기능이나 메시지를 필요로 하는 관계를 말한다.
워크스페이스는 보통 다음과 같은 구조를 가진다.
ros2_ws/
src/ros2_ws는 워크스페이스 폴더 이름이다. 꼭 이 이름이어야 하는 것은 아니지만 입문 단계에서는 관례를 따르는 편이 이해하기 쉽다. src 폴더는 소스 코드가 들어가는 곳이다. 앞으로 직접 만들거나 외부에서 가져온 패키지는 대개 이 안에 둔다.
다음 명령으로 워크스페이스를 만들 수 있다.
mkdir -p ~/ros2_ws/src
cd ~/ros2_wsmkdir -p는 폴더를 만들라는 뜻이다. 중간 폴더가 없으면 함께 만든다. ~는 현재 사용자의 홈 디렉터리를 뜻한다. 그래서 ~/ros2_ws는 홈 디렉터리 아래의 ros2_ws 폴더다.
아직 src 안에는 아무 패키지도 없다. 하지만 이 비어 있는 구조 자체가 중요하다. ROS2 프로젝트는 파일을 아무 곳에나 흩뿌리는 방식으로 자라지 않는다. 워크스페이스 안에 패키지를 모으고, 빌드하고, 환경을 적용한 뒤 실행한다. 이 질서를 지키지 않으면 나중에 파일은 있는데 ROS2가 패키지를 찾지 못하는 일이 생긴다.
colcon build가 남기는 흔적
이제 워크스페이스 루트에서 빌드를 실행해 보자.
cd ~/ros2_ws
colcon build아직 src 폴더가 비어 있다면 빌드할 패키지가 없다는 식의 담담한 결과가 나올 수 있다. 이것은 실패가 아니다. 단지 아직 만들 것이 없다는 뜻이다.
나중에 패키지가 들어 있는 상태에서 colcon build를 실행하면 워크스페이스 안에 몇 개의 폴더가 생긴다.
ros2_ws/
build/
install/
log/
src/이 폴더들은 그냥 부산물이 아니다. 각각의 폴더는 빌드 과정의 흔적을 담고 있다.
build 폴더에는 빌드 중간 결과가 들어간다. 소스 코드가 실행 가능한 형태로 변환되는 과정에서 필요한 파일들이 이곳에 쌓인다. 일반적으로 사용자가 직접 수정하는 곳은 아니다.
install 폴더에는 빌드가 끝난 뒤 실행에 필요한 결과물이 정리된다. ROS2가 새로 만든 패키지를 찾게 하려면 이 안의 설정 파일을 현재 터미널에 적용해야 한다.
source ~/ros2_ws/install/setup.bash이 명령은 매우 중요하다. 패키지를 만들고 빌드까지 성공했는데도 ros2 run에서 패키지를 찾지 못하는 일이 있다면, 상당수는 이 과정을 잊었기 때문이다. 설치된 ROS2 환경을 읽는 것과 내가 만든 워크스페이스의 결과를 읽는 것은 별개의 단계다.
log 폴더에는 빌드 과정의 기록이 남는다. 빌드가 실패했을 때 터미널에 보인 마지막 줄만 보고 판단하면 단서를 놓치기 쉽다. 로그에는 더 자세한 정보가 남아 있을 수 있다. 로봇 개발에서 로그는 사건 현장에 남은 발자국과 같다. 눈앞의 오류 메시지가 모든 진실은 아니다.
새 패키지가 보이지 않는 밤
입문자가 자주 겪는 장면을 하나 상상해 보자. 새 패키지를 만들고, 코드를 작성하고, colcon build도 성공했다. 그런데 실행하려고 하면 ROS2가 차갑게 말한다. 그런 패키지는 모른다고.
그 순간 머릿속에 많은 의심이 스친다. 패키지 이름을 잘못 만들었나? 코드가 틀렸나? 빌드가 사실 실패했나? 하지만 가장 먼저 확인할 것은 따로 있다. 현재 터미널이 방금 빌드한 워크스페이스의 install/setup.bash를 읽었는가?
source ~/ros2_ws/install/setup.bash그다음 패키지 목록에서 이름을 찾아본다.
ros2 pkg list | grep 패키지이름ros2 pkg list는 현재 ROS2 환경에서 찾을 수 있는 패키지 목록을 보여 준다. 여기에 내가 만든 패키지가 나오면 ROS2는 그 패키지의 존재를 알고 있다. 나오지 않는다면 아직 환경 적용이 되지 않았거나, 빌드 결과가 제대로 만들어지지 않았거나, 패키지 구조에 문제가 있을 수 있다.
이 문제는 작은 것처럼 보이지만 매우 중요한 사고방식을 가르쳐 준다. ROS2에서 "파일이 존재한다"와 "ROS2가 패키지로 인식한다"는 같은 말이 아니다. 소스 폴더에 코드가 있어도, 빌드되지 않았거나, 빌드 결과가 환경에 적용되지 않았으면 ROS2 명령어는 그 패키지를 찾지 못한다.
이 차이를 이해하지 못하면 나중에 더 큰 프로젝트에서 길을 잃는다. 패키지는 있는데 실행이 안 되고, 노드는 있는데 목록에 보이지 않고, 설정 파일은 수정했는데 결과가 바뀌지 않는 일들이 이어진다. 그때마다 문제는 코드 깊은 곳에 있는 것이 아니라, 작업공간과 환경 설정의 경계에 숨어 있을 수 있다.
노드 목록은 거짓말하지 않는다
이제 다시 노드와 토픽으로 돌아가 보자. ROS2 시스템을 관찰할 때 가장 먼저 사용할 수 있는 명령은 node list와 topic list다.
ros2 node list
ros2 topic list이 두 명령은 로봇 시스템의 현재 상태를 훑어보는 창문이다. 어떤 노드가 살아 있는지, 어떤 토픽이 열려 있는지 알려 준다. 실제 로봇이 붙으면 이 목록은 훨씬 복잡해진다. LiDAR 드라이버 노드, 카메라 노드, 로봇 상태 발행 노드, 조이스틱 노드, 내비게이션 관련 노드, 지도 서버, 위치 추정 노드가 한꺼번에 나타난다.
그때도 기본은 같다. 우선 존재하는지 본다. 존재한다면 연결을 본다. 연결되어 있다면 데이터 내용을 본다.
토픽의 메시지 형식을 확인하려면 다음 명령을 사용할 수 있다.
ros2 topic info /chatter더 자세한 정보를 보고 싶다면 옵션을 붙일 수 있다.
ros2 topic info /chatter -v여기서는 발행자와 구독자 수, 사용하는 메시지 타입 같은 정보를 볼 수 있다. 메시지 타입은 그 토픽에 어떤 구조의 데이터가 흐르는지를 나타낸다. 예를 들어 문자열이면 문자열 메시지 타입을 사용하고, 속도 명령이면 선속도와 각속도를 담는 메시지 타입을 사용한다.
처음에는 이런 명령들이 단순한 확인 도구처럼 보인다. 하지만 실제로는 ROS2 시스템을 읽는 문법이다. 소설을 읽을 때 문장의 주어와 서술어를 찾아야 의미가 보이듯, ROS2 시스템을 읽을 때는 노드와 토픽, 메시지 타입을 찾아야 흐름이 보인다.
작은 단서를 따라가기로 하다
여기까지 오면 이상한 감각이 생긴다. 처음에는 ROS2가 거대한 도구처럼 보였지만, 실제로는 작은 단서들의 연속이다. 터미널이 명령어를 아는가. 노드가 떠 있는가. 토픽이 보이는가. 메시지가 흐르는가. 워크스페이스의 설정을 읽었는가. 환경 변수가 다른 방을 가리키고 있지는 않은가.
이 단서들은 모두 사소해 보인다. 하지만 사소한 것들이 쌓여 시스템의 운명을 바꾼다. 로봇 개발에서 큰 문제는 대개 갑자기 나타나지 않는다. 그보다 훨씬 전부터 작은 경고가 있었다. 누군가는 그것을 무시했고, 누군가는 기록하지 않았고, 누군가는 "일단 넘어가자"고 말했다. 그러다 어느 날 로봇이 움직이지 않거나, 움직여서는 안 될 때 움직이려 하거나, 지도 위에서 자기 위치를 잃는다.
그러므로 지금부터 가져야 할 태도는 분명하다. 작은 단서를 따라간다. 명령어 하나가 남기는 출력도 그냥 넘기지 않는다. 아무것도 출력되지 않는 침묵조차 의미가 있을 수 있다고 생각한다. 이 태도는 단순히 ROS2 입문을 위한 요령이 아니다. 복잡한 로봇 시스템을 다루는 개발자의 기본 감각이다.
다음 단계에서는 직접 노드를 만들고, 토픽을 통해 메시지를 주고받게 할 것이다. 그때 우리는 더 이상 예제 노드의 말소리를 듣는 관찰자에 머물지 않는다. 직접 말하는 노드를 만들고, 듣는 노드를 만들고, 두 노드 사이에 흐르는 데이터를 확인하게 된다.
하지만 그 전에 기억해야 한다. 노드는 혼자서는 의미가 약하다. 토픽이 연결되고, 메시지가 흐르고, 환경이 같은 방향을 바라볼 때 비로소 시스템이 된다. 그리고 시스템이 된 순간부터 작은 어긋남은 더 이상 작은 문제가 아닐 수 있다.
터미널의 커서는 여전히 조용히 깜박인다. 방금 전과 다를 것이 없어 보인다. 그러나 이제 우리는 알고 있다. 그 조용한 화면 뒤에는 노드들이 서로를 찾고, 토픽이 열리고, 환경 설정이 경계를 만들고, 로그가 흔적을 남긴다. 불길한 전조는 언제나 요란하게 오지 않는다. 대개는 한 줄의 메시지, 비어 있는 목록, 적용하지 않은 설정 파일처럼 아주 작은 모습으로 먼저 도착한다.
참고
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.