Ada를 쓰기로 마음먹었다면, 언젠가는 부딪혀야 할 가장 큰 장벽이자 가장 큰 짜증을 유발하는 문제가 있습니다.

Java나 C# 개발자라면, 같은 패키지(네임스페이스) 안에서 클래스들이 서로 상속받아 자연스러운 타입 계층을 만드는 것에 익숙합니다.

// Java/C# 스타일 의사 코드
// 'widget' 네임스페이스 안에서 타입들이 상속 관계를 형성
package com.example.widget;

public class Widget { /*...*/ }
public class Window extends Widget { /*...*/ }
public class Button extends Widget { /*...*/ }
public class ToggleButton extends Button { /*...*/ }
public class CheckedButton extends Button { /*...*/ }

Widget이라는 베이스 타입과 이를 상속받은 Window 타입이 widget 이라는 같은 이름 공간에 공존하는, 지극히 상식적인 구조입니다. Ada에서는 이처럼 직관적인 타입 계층을 이름으로 표현하는 데 근본적인 한계가 있습니다.

계층 구조 비교: 직관적인 Java/C# vs 어색한 Ada

GUI 툴킷을 만든다고 가정하고 두 언어의 계층 구조를 다이어그램으로 비교해 보겠습니다. ToggleButton과 CheckedButton은 Button을, Button과 Window는 Widget을 상속받는 관계입니다.

Java / C#의 방식: 상속 기반의 타입 계층

하나의 패키지(네임스페이스) 안에서, 클래스들이 상속을 통해 직관적인 타입 계층을 형성합니다. 타입의 이름이 곧 개념을 나타냅니다.

   Widget
   /     \
Window  Button
         /   \
        /     \
       /       \
ToggleButton  CheckedButton

Ada의 방식: 모듈 중심의 계층

Ada는 모든 것을 별개의 패키지(모듈)로 분리해야 합니다. Window가 Widget을 상속받는 개념을 표현하기 위해, Widget.Window라는 별도의 자식 패키지를 만들어야 합니다.

     Widget
       |
     Object
     /   \
    /     \
Window   Button
   |       |
Object   Object
         /    \
        /      \
ToggleButton  CheckedButton
     |              |
   Object         Object

-- Object가 뒤따를 수 밖에 없는 변수 선언 예시
-- 참고로 with, use를 사용하면 일부 네임 스페이스를 생략할 수 있습니다.
my_widget        : access Widget.Object;
my_window        : access Widget.Window.Object;
my_button        : access Widget.Button.Object;
my_toggle_button : access Widget.Button.ToggleButton.Object;

Widget.Window면 될 것을 Widget.Window.Object라고 써야 하는 이 모습은, 솔직히 말해 끔찍한 혼종처럼 보입니다.

결론: 울며 겨자 먹기로 Ada를 쓰는 이유

Ada의 이런 고집스러운 설계 철학은 정말 마음에 들지 않습니다. 코드는 장황해지고, 다른 언어의 직관적인 객체 지향 패턴을 포기해야 하는 대가를 치러야 합니다.

하지만 아이러니하게도, 저는 이 언어를 버릴 수 없습니다. 안전성/신뢰성을 보장해주는 선택지가 사실상 Ada가 유일하기 때문입니다. 컴파일 시점에는 컴파일러의 엄격한 검사를 하고 실행 시점에는 언어 자체에 내장된 강력한 런타임 검사가 실시간으로 오류를 검사하기 때문에, 저는 이 모든 불편함을 감수하는 것입니다.