편집한 프로젝트와 실행된 프로그램을 연결한다
로봇 수집기가 실행되지 않을 때 소스 문법보다 먼저 확인할 것은 어떤 실행 파일이 어떤 환경과 입력으로 시작됐는지다. 같은 명령 이름이라도 셸·IDE·서비스·컨테이너가 선택한 경로는 다를 수 있다. 실행 환경은 명령을 찾는 경로, 라이브러리·패키지 검색 경로, 작업 디렉터리와 장치·네트워크 접근 범위를 포함한다. 편집한 파일이 있다고 그 파일을 현재 프로세스가 사용했다는 뜻은 아니다.
이 단위는 일반 코딩 경험을 전제로 한다. 셸 인용이나 변수 문법을 연습하는 대신 작업을 시작한 주체와 실제 해석된 경로를 로그로 확인한다. 절대 경로·상대 경로의 의미는 알고 있다고 가정하되, 수집기 오류에서는 실행 시 작업 디렉터리와 입력 인수의 조합을 다시 대조한다. 공백이 있는 파일명도 셸 화면 문자열보다 프로그램에 전달된 인수 경계를 확인하는 대상이다.
예를 들어 저장소는 /work/project인데 프로세스의 작업 위치가 /work이고 입력은 data/run.csv라면 실제 대상은 /work/data/run.csv다. 기대한 /work/project/data/run.csv와 다르다. 이 오류는 데이터가 존재하지 않는다는 전역 결론이 아니라 그 실행이 찾은 경로의 실패다. 컨테이너 안이라면 호스트에 있는 파일이 해당 경로로 연결됐는지도 추가 확인한다. 경로를 고친 뒤에는 같은 입력을 실제로 처리했는지 결과 기록까지 확인한다.
Underlay와 overlay는 실행 검색 환경의 층이다
ROS workspace는 패키지들을 모아 빌드·설치하는 작업 공간이다. 이미 설치된 패키지와 의존성을 제공하는 기반 환경을 underlay, 그 위에서 개발 패키지를 추가하거나 같은 패키지를 대체하는 환경을 overlay라고 한다. Jazzy 공식 workspace 설명은 이 층과 환경 설정의 관계를 설명한다. overlay가 요구하는 의존성이 underlay에 있어야 하며 검색 환경의 선택이 실제 패키지 선택에 영향을 준다.
예를 들어 같은 sensor_bridge 패키지의 설치본이 /ws_old/install과 /ws_new/install에 모두 있다고 하자. 소스는 새 공간에서 수정했어도 실행 로그의 패키지 설치 위치가 /ws_old/install이면 새 결과를 확인했다고 할 수 없다. 이 문제는 소스 문법을 고쳐도 남는다. 선택한 underlay·overlay와 순서, 패키지의 실제 설치 위치, 실행 파일과 공유 라이브러리 경로를 함께 기록한다. 헤더와 실행 라이브러리가 서로 다른 workspace에서 선택되는 문제는 뒤의 빌드·ABI 단위에서 더 다룬다.
환경 설정은 해당 프로세스가 시작할 때 받은 환경과 연결된다. 한 터미널에서 환경을 바꾸었다고 이미 실행 중인 수집기나 별도 서비스의 환경까지 바뀐 것은 아니다. 새로운 셸에서 의도한 기반과 overlay를 선택하고 실제 해석 결과를 비교하는 방식으로 가설을 분리한다. 설정 스크립트를 무작정 여러 번 덧씌워 우연히 실행되게 만들기보다 어떤 층이 선택됐는지 확인한다. 여기서는 실제 source·빌드를 실행하지 않는다.
PID와 종료 코드, 준비 완료는 다른 근거다
PID는 실행 인스턴스를 식별한다. 동일한 이름의 프로세스가 여러 개라면 PID뿐 아니라 실행 경로·인수·작업 위치와 로그의 run ID를 연결한다. PID가 살아 있다는 사실은 파일 처리 완료나 USB 수신, 추론 모델 로딩, socket 대기까지 증명하지 않는다. 이전 프로세스의 성공 문구를 새 실행의 결과로 섞지 않도록 시작 시각과 출력 경로도 남긴다.
종료 코드 0은 일반적으로 성공 관례지만 정확한 의미는 프로그램의 계약에 달려 있다. 코드 2와 파일 오류가 함께 있으면 그 실행에서 입력 처리가 실패했다는 근거로 읽는다. 모든 프로그램의 2가 같은 원인이라는 뜻은 아니다. 계속 운용 중인 서버에는 아직 최종 종료 코드가 없을 수 있다. 생존·준비·작업 결과·종료를 구분하면 재설치보다 작은 확인으로 실패 층위를 좁힐 수 있다.
USB는 장치 식별과 실행 주체를 함께 확인한다
장치 인식, driver 연결, 장치 노드 생성, 프로그램의 열기와 유효한 표본 수신은 다른 단계다. /dev/ttyACM0이라는 이름은 합성 사례이며 모든 USB 장치가 이 경로를 쓰지 않는다. 번호가 재연결 뒤 바뀔 수 있어 장치 식별과 기대 센서의 대응을 확인한다. 경로 존재만으로 측정 정확도나 통신 설정이 맞았다고 판정하지 않는다.
합성 권한이 crw-rw---- root dialout이면 소유자와 해당 그룹에 읽기·쓰기 권한이 있고 기타에는 없다. 비관리자 learner의 그룹이 learner뿐이면 이 기본 권한표에서는 접근 허용 조건을 만족하지 않는다. 실제 정책·ACL이나 장치 접근 제한 등도 확인해야 하므로 표 하나로 모든 원인을 확정하지 않는다. 컨테이너라면 장치 전달과 숫자 사용자·그룹 ID의 대응도 점검한다. 호스트의 그룹 이름이 보인다는 사실만으로 컨테이너 프로세스의 접근 권한을 보장할 수 없다.
Ubuntu 사용자 관리 안내를 참고해 실제 실행 주체와 필요한 접근 범위를 검토한다. 무차별 관리자 실행이나 전체 쓰기 권한은 기본 진단 절차가 아니다. 권한 조건을 고친 뒤에도 다른 프로세스 점유·통신 설정·표본 오류가 남을 수 있다. 이 활동은 권한 변경이나 장치 동작을 수행하지 않는다.
Endpoint는 어느 네트워크 환경의 주소인가
TCP endpoint는 주소와 포트 및 해당 네트워크 환경을 함께 지정한다. 같은 호스트에서 서버가 127.0.0.1:5000에 대기하고 클라이언트가 5001로 연결하면 우선 포트 불일치다. 서버 PID만 보고 USB 권한부터 바꿀 근거는 없다. 실제 대기 socket, 연결 대상과 전송 종류를 대조한다.
127.0.0.1은 해당 network namespace의 loopback이다. 별도 컨테이너 네트워크나 다른 컴퓨터의 같은 숫자는 원래 서버를 가리키지 않을 수 있다. Docker 네트워크 공식 설명처럼 bridge·host 등 연결 방식이 경계를 바꾸므로 컨테이너면 언제나 같거나 언제나 다르다고 일반화하지 않는다. 어떤 실행 위치와 연결 설정을 사용했는지 확인한다.
TCP 접속 성공도 기대한 데이터 스키마·단위·신선도를 받은 성공과는 다르다. ROS에서는 추가로 선택한 통신 구현·발견 설정·타입·QoS 등의 계약을 후속 단위에서 확인한다. 연결 거부와 timeout은 가설을 좁히는 단서이지만 오류 문자열 하나가 방화벽·라우팅·서버 상태를 모두 확정하지는 않는다. 실행 경계→실제 경로·장치→프로세스 준비→대기 endpoint→응답 내용 순서로 근거를 모으자.