콘솔과 로그 연습문제 정답
시행일·최종 수정일: 2026년 9월 1일
정답을 보기 전에
먼저 각 문제에 자신의 말로 답해본 뒤 해설과 비교해 보세요. 표현이 달라도 핵심 개념과 계산 과정이 맞으면 정답으로 볼 수 있습니다.
1. rosbag2, Log, Diagnostics와 Metric이 각각 답하는 질문을 설명하세요.
정답과 해설
Bag은 실제 어떤 Message가 오갔는지, Log는 특정 순간 왜 그렇게 판단했는지 보여 줍니다. Diagnostics는 현재 Component Health, Metric은 시간에 따른 Latency·Drop·자원 사용 Trend를 표현합니다.
2. DEBUG·INFO·WARN·ERROR·FATAL을 Battery Monitor 상황에 맞춰 구분하세요.
정답과 해설
개별 Sample 값은 DEBUG, Monitor 시작과 정상 복귀는 INFO, 저전압은 WARN, 안전 정지가 필요한 임계전압은 ERROR로 기록할 수 있습니다. 필수 Battery Interface 초기화 실패로 계속할 수 없다면 FATAL입니다.
3. 고주파 Callback에서 조건 없는 INFO가 Robot 동작에 미치는 영향을 설명하세요.
정답과 해설
Format과 Console Rendering, Lock, rosout Publish와 Disk I/O가 Callback마다 발생해 CPU·Disk를 소비하고 Jitter를 키웁니다. 중요한 Error가 반복 Message에 묻히고 보존 용량도 빠르게 소진됩니다.
4. Throttle, Once와 상태 전이 Log를 각각 어떤 상황에 사용하나요?
정답과 해설
Throttle은 반복 가능한 Sensor Stale 경고, Once는 실행 중 한 번만 필요한 사용 중단 안내에 적합합니다. 상태 전이 Log는 정상→고장, 주행→정지처럼 값이 바뀌는 사건만 남겨 연대기를 만듭니다.
5. 좋은 사건 Log에 포함해야 할 Context Field를 쓰세요.
정답과 해설
안정된 Event 이름, Node·Component, 관련 Mission·Request ID, 입력값과 단위, 기준값, 이전·현재 상태, 수행한 대응과 Error Code를 포함합니다. Timestamp와 Severity는 Logging Backend 형식으로 제공합니다.
6. Console, /rosout, Launch Log와 systemd Journal의 차이를 설명하세요.
정답과 해설
Console은 현재 Process 표준 출력·오류, /rosout은 활성화된 ROS Node Log Topic입니다. Launch Log는 Launch가 Capture한 실행 출력이고 Journal은 systemd가 Service 표준 Stream과 Metadata를 보존하는 OS 계층 저장소입니다.
7. Logger Level Service 사용 전에 확인해야 할 사항은 무엇인가요?
정답과 해설
대상 Node에서 Service가 활성화되어 실제로 존재하는지, Logger 이름과 요청 Level이 맞는지 확인합니다. 운영 Network의 인증·권한, DEBUG로 인한 Timing·Disk 영향과 원래 Level로 되돌릴 절차도 준비합니다.
8. RCUTILS_CONSOLE_OUTPUT_FORMAT에 시간·Logger 이름·Severity를 넣어야 하는 이유를 설명하세요.
정답과 해설
여러 Process의 사건 순서를 맞추고 발생 Component와 심각도를 즉시 구분하기 위해서입니다. 기본 형식에 이미 포함된 Field도 있지만 중앙 Parser와 팀 정책에 맞춰 일관성을 유지하고 필요하면 Source 위치를 추가합니다.
9. DEBUG가 꺼졌는데도 무거운 문자열 계산이 성능을 낮출 수 있는 이유와 방지 방법을 쓰세요.
정답과 해설
Log 함수가 Level을 검사하기 전에 f-string의 함수 호출과 Format이 평가될 수 있습니다. is_enabled_for(LoggingSeverity.DEBUG)로 Guard한 안에서만 비싼 계산과 문자열 생성을 수행합니다.
10. Launch에서 output, emulate_tty와 Node별 Log Level을 구성하는 방법을 설명하세요.
정답과 해설
Node(output='screen|log|both')로 목적지를 명시하고 필요하면 emulate_tty=True를 사용합니다. Launch Argument를 arguments=['--ros-args','--log-level', level]로 전달해 환경별 Level을 선택합니다.
11. Correlation ID가 여러 Node의 장애 조사에 필요한 이유는 무엇인가요?
정답과 해설
동시에 여러 Goal이 처리되면 Node별 시작과 실패만으로 같은 임무의 사건인지 구분할 수 없습니다. 공통 Mission·Trace ID로 검색하면 Planner, Controller와 Safety를 지나간 한 요청의 시간 순서를 복원할 수 있습니다.
12. 평균 300 Byte Log가 초당 20줄 발생할 때 하루 Payload 용량을 계산하세요.
정답과 해설
300 × 20 × 86,400 = 518,400,000 Byte이므로 약 518 MB, 십진 GB로 약 0.52 GB입니다. 실제 저장량에는 Timestamp·Metadata, File System Overhead, 중복 목적지와 압축률을 반영합니다.
13. Log에 남기면 안 되는 개인정보·기밀정보와 안전한 대체 Field를 예로 드세요.
정답과 해설
Password, Token, 인증 Header, 이메일·주소·정확한 위치와 원본 사용자 입력을 기록하지 않습니다. 최소화된 Request ID, Error Code, HTTP Status와 필요한 경우 짧고 재식별 위험을 평가한 가명 Identifier를 사용합니다.
14. 여러 Computer의 Clock이 맞지 않으면 Log 분석에 어떤 문제가 생기나요?
정답과 해설
각 Node의 사건 Timestamp 순서가 실제 인과관계와 달라져 원인과 결과가 뒤집혀 보일 수 있습니다. NTP·PTP 상태, Timezone, ROS Time과 System Time 사용 여부를 Incident 자료에 함께 남겨야 합니다.
15. 실제 Robot 사고 후 Log·Bag·Parameter를 이용한 표준 진단 순서를 설명하세요.
정답과 해설
Clock과 실행 환경을 확인하고 ERROR·FATAL 및 직전 WARN을 찾습니다. 시작 Log와 Parameter Dump로 구성을 복원하고 의심 Node만 DEBUG로 올립니다. 같은 시간대 Bag의 Sensor·TF·Command·Diagnostics와 rosout을 대조해 원인을 검증합니다.
학습 마무리
틀린 문제는 강의의 관련 장을 다시 읽고, 용어뿐 아니라 각 개념이 실제 로봇에서 어떤 역할을 하는지 설명해 보세요.