제목: [System/Ada] POSIX errno 지옥에서 탈출하기: 통합 에러 핸들러와 이진 탐색 최적화

안녕하세요. 현재 Ada 언어로 고성능 비동기 I/O 라이브러리인 Clair를 개발하고 있습니다.

시스템 프로그래밍을 하거나 C 라이브러리를 래핑해 보신 분들은 공감하시겠지만, 에러 처리(Errno Handling)는 정말 끝없는 노가다의 연속입니다. 오늘은 이 과정을 획기적으로 줄인 경험을 공유하고자 합니다.

1. 고통의 시작: 함수마다 에러가 다르다?

처음에는 정석대로 구현했습니다. man 2 open, man 2 read를 일일이 찾아보며 각 시스템 콜이 리턴할 수 있는 에러 목록을 조사하고 switch/case 문을 작성했죠.

-- [기존 방식] 함수마다 case 문이 복붙됨...
procedure Open (...) is
begin
   res := c_open(...);
   if res < 0 then
      case errno is
         when EACCES => raise Permission_Denied;
         when ENOENT => raise Not_Found;
         when EISDIR => raise Is_A_Directory;
         -- ... open이 뱉는 에러 10개 나열 ...
      end case;
   end if;
end Open;

procedure Read (...) is
begin
   -- ...
   if res < 0 then
      case errno is
         when EACCES => raise Permission_Denied; -- 또 나옴
         when EAGAIN => raise Resource_Busy;     -- 새로운 에러 등장
         when EBADF  => raise Bad_Descriptor;
         -- ... read가 뱉는 에러 5개 나열 ...
      end case;
   end if;
end Read;

함수가 10개면 괜찮지만, socket, bind, listen, epoll_ctl... 함수가 늘어날수록 코드는 중복된 case 문으로 도배되고, 유지보수는 지옥이 되었습니다.

2. 발상의 전환: Superset 전략

문득 이런 생각이 들더군요. 굳이 open이 리턴하는 에러만 골라서 검사해야 하나? 어차피 다 errno 정수값 아닌가?

함수별로 에러를 필터링하지 말고, POSIX 표준이 정의한 모든 에러(Superset)를 처리하는 단 하나의 통합 핸들러를 만들면 어떨까?

• open이 EAGAIN을 뱉을 일이 없다고 해도, 핸들러에 EAGAIN 처리 로직이 있는 건 문제 되지 않는다.
• 어차피 errno가 발생했다면, 그건 우리가 아는 에러 중 하나일 것이다.

3. 해결책: 정렬된 테이블 + 이진 탐색 (Lookup Table)

if-else나 switch-case를 수백 줄 나열하는 대신, 데이터 기반(Data-driven)으로 접근했습니다.

1. 데이터 구조: (Errno, Exception_ID) 쌍을 저장하는 배열을 만듭니다.
2. 정렬: 프로그램 시작 시 Errno 값을 기준으로 정렬합니다. (OS마다 번호가 다를 수 있으므로)
3. 검색: 런타임에는 이진 탐색(Binary Search)으로 예외를 찾습니다.

-- [Clair.Error 패키지 내부]

-- 1. 모든 POSIX 에러를 때려 넣은 테이블
Error_Table : array (1 .. MAX_ERRORS) of Error_Entry :=
  ((EACCES, Permission_Denied'Identity),
   (EAGAIN, Try_Again'Identity),
   (EBADF,  Bad_File_Descriptor'Identity),
   -- ... (약 30~50개 표준 에러) ...
   (ENOMEM, Memory_Error'Identity));

-- 2. 통합 핸들러 (이진 탐색 O(log N))
procedure Raise_From_Errno (Errno : int; Message : String) is
   -- Binary Search 로직 ...
   -- 찾으면 해당 예외 발생 (Raise)
   -- 못 찾으면 Unknown Error 발생
end Raise_From_Errno;

4. 결과: 매뉴얼과의 이별

이제 시스템 콜 래퍼 함수들은 이렇게 변했습니다.

procedure Open (...) is
begin
   if c_open(...) < 0 then
      -- [끝!] 어떤 에러인지는 핸들러가 알아서 찾아서 던짐
      Clair.Error.Raise_From_Errno(errno, "Open failed on " & Path);
   end if;
end Open;

이득:

1. 생산성 폭발: 더 이상 man 페이지를 뒤지며 이 함수가 무슨 에러를 뱉지? 고민할 필요가 없습니다. 그냥 넘기면 됩니다.
2. 제로 할당 (Zero Allocation): 해시 맵(Hash Map) 대신 정적 배열을 썼기 때문에 힙 메모리 할당이 전혀 없습니다.
3. 성능: 50개의 에러가 있어도 이진 탐색은 최대 6번 비교면 끝납니다. 에러 상황에서의 오버헤드로는 완벽합니다.
4. 캐시 효율: 배열이라 메모리에 연속적으로 배치되어 CPU 캐시 히트율이 높습니다.

결론: 시스템 프로그래밍에서 변하지 않는 정적 데이터를 다룰 때는, 무거운 맵(Map) 자료구조보다 정렬된 배열(Sorted Array)이 깡패라는 걸 다시 한번 느꼈습니다.

혹시 비슷한 고민을 하시는 분들이 있다면 Superset 전략을 강력 추천합니다.

C 바인딩을 위해 Ada 예외를 C int 값으로 변환하는 핸들러도 마찬가지의 알고리즘으로 작성할 수 있습니다.