운영체제 미드레벨 테스트·코드품질 기술면접

멀티스레드 테스트의 가장 큰 어려움은 Race Condition이 비결정적으로 발생한다는 점입니다. 단위 테스트에서는 CountDownLatch, CyclicBarrier 등을 사용해 여러 스레드를 동시에 실행시키고 충분한 반복 횟수로 문제를 재현합니다. Thread Sanitizer나 Helgrind 같은 도구를 사용하면 잠재적 동시성 버그를 정적으로 탐지할 수 있습니다. 실무에서는 스트레스 테스트와 함께 코드 리뷰에서 동기화 메커니즘의 올바른 사용을 확인하는 것이 중요합니다. 또한 불변 객체 사용, Thread-safe 자료구조 활용 등 애초에 동시성 문제가 발생하지 않도록 설계하는 것이 가장 효과적입니다.

코드 리뷰 체크리스트에는 먼저 모든 malloc/new에 대응하는 free/delete 존재 여부, RAII 패턴 적용 여부, 스마트 포인터 사용 여부를 확인합니다. 포인터 소유권이 명확히 문서화되어 있는지, 댕글링 포인터 가능성은 없는지, 배열 경계 검사가 적절한지 검토합니다. 정적 분석 도구로는 Clang Static Analyzer, Cppcheck를 빌드 단계에 통합하고, 동적 분석으로는 Valgrind, AddressSanitizer를 테스트 실행 시 활성화합니다. CI 파이프라인에서 이들 도구의 결과를 파싱하여 임계값 초과 시 빌드를 실패시키고, 리포트를 PR 코멘트로 자동 게시하도록 설정합니다. 정기적으로 메모리 프로파일링을 수행하여 장기 실행 시 누수 여부를 모니터링하는 것도 중요합니다.

IPC 테스트에서는 먼저 프로세스 생성과 종료를 제어하는 테스트 하네스가 필요하며, 각 테스트는 격리된 환경에서 실행되어야 합니다. 파이프는 단방향 통신으로 비교적 테스트가 단순하지만, 버퍼 오버플로우와 블로킹 상황을 검증해야 합니다. 공유 메모리는 동기화 메커니즘(세마포어, 뮤텍스)과 함께 테스트해야 하며 Race Condition 검증이 필수적입니다. 메시지 큐는 메시지 순서 보장, 큐 오버플로우, 타임아웃 처리를 테스트해야 합니다. 통합 테스트에서는 실제 프로세스를 fork하거나 exec하여 실행하고, 타임아웃을 설정해 데드락이나 무한 대기를 방지합니다. Mock을 사용한 단위 테스트보다는 실제 IPC를 사용하는 통합 테스트가 더 중요합니다.

파일 시스템 작업은 I/O로 인해 느리고, 테스트 간 상태가 공유되어 격리성이 떨어지며, 권한이나 디스크 상태에 따라 재현성이 보장되지 않습니다. 이를 해결하기 위해 먼저 파일 시스템 인터페이스를 추상화하여 의존성 주입이 가능하도록 설계합니다. 단위 테스트에서는 메모리 기반 가상 파일 시스템이나 Mock 객체를 사용하여 빠르고 격리된 테스트를 작성합니다. 통합 테스트에서는 임시 디렉토리를 생성하여 실제 파일 시스템을 사용하되, setUp에서 생성하고 tearDown에서 정리하여 격리성을 확보합니다. 테스트 더블 사용 시에도 실제 파일 시스템의 에러 케이스(권한 거부, 디스크 풀 등)를 시뮬레이션할 수 있도록 설계해야 합니다. 이러한 접근으로 빠른 피드백 루프를 유지하면서도 실제 환경의 문제를 검증할 수 있습니다.

먼저 현재 사용 중인 시스템 콜들을 조사하여 목록화하고, 각각의 호출 지점을 파악합니다. 그 다음 시스템 콜을 감싸는 얇은 Adapter 계층을 도입하여 OS별 구현을 캡슐화합니다. 기존 코드를 한 번에 바꾸지 않고 Strangler Fig 패턴으로 새로운 기능이나 수정이 필요한 부분부터 점진적으로 Adapter를 사용하도록 변경합니다. 각 단계마다 기존 동작과 동일함을 검증하는 회귀 테스트를 작성하고 실행합니다. Adapter 인터페이스가 안정화되면 Mock 구현을 만들어 단위 테스트를 추가합니다. 최종적으로 모든 직접 시스템 콜 사용을 Adapter로 교체한 후, 정적 분석 도구나 린터 규칙을 추가하여 새로운 직접 호출을 방지합니다. 이 과정에서 지속적인 코드 리뷰와 팀 내 가이드라인 공유가 중요합니다.