Lee의 개발 아키텍처 철학 — 바퀴가 주인공이 되는 순간을 대비하라
자동차의 바퀴가 주인공이 된다면?
1. 문제의 출발점: 전체와 부품 사이의 관계 재조명
디자이너 또는 개발자는 일반적으로 하나의 서비스(예: Q&A 플랫폼)를 만들 때, 이를 이루기 위한 각각의 조각즉, 엔진, 로직, UI 요소 등을 생각하게 된다. 이러한 사고방식에는 대부분 '서비스'라는 전반적인 목적이 우선된다.
예를들어,
바퀴는 자동차가 움직이도록 하는 중요한 구성요소지만,
그것이 단순히 "자동차"에게 필요한 일부라고 여김으로써 가치를 평가받게 된다.
그러나 기술 발전 속에서 이런 구조는 한계를 보임으로써 오히려 문제가 될 지도 모른다..
왜냐하면 우리가 만든 작은 컴포넌트들이 시간이 지남에 따라 원래 의도했던 범위를 훨씬 벗어난 새로운 의미를 갖추며 독립적이고 자기 주도적인 역할을 하게 될 가능성이 존재하기 때문이다.
이것을 정확히 설명한 개념이 바로 "주객전도의 역설"(The Wheel Paradox)이라 할 수 있다.
이는 우리가 먼저 '자동화된 서비스'를 위해 부품을 만드는 것이었으나,
실제로는 그 부품이 자신을 지닌 가치를 인정하며
시스템보다 더 큰 영향력을 행사하게 되는 것을 나타내는 것이다.
실제 적용 사례 중 하나는 다음과 같다:
- 초기 목적: 질문에 답변을 생성하기 위한 간단한 NLP 파싱 모듈.
- 이후 변화: 고객 피드백 데이터 수집 및 행동 패턴 분석을 수행함으로써 실시간 의사결정 지원 시스템의 핵심 동력으로 진화.
- 최종 상태: 조직 내 모든 데이터 프로세스에서 인사이트 제공과 권한 결정을 담당하여 전사 운영의 중심 역할을 맡음.
이는 단지 ‘Q&A’ 기능이라는 초점을 떠난 결과이며, 오히려 그 자체가 더 복잡하고 넓은 도메인에서 작용하는 핵심 요소가 되었다는 점에서 매우 중요하다.
2. 용접된 바퀴란 무엇인가?
“바퀴”가 “자동차 체계에 고착되어 있으면서 자유롭게 이탈하거나 사용되지 못한다”는 상황을 말한다. 이것은 코드 설계에서도 명확히 표현될 수 있으며, 일반적으로 특정 환경이나 플랫폼에 강하게 결합되는 경우를 가리킨다.
예를 들어 다음 형태의 코드는 대표적인 문제이다:
```python
def process_user_query():
s3_client = boto3.client('s3')
bucket_name = "user-data-bucket"
response = s3_client.get_object(Bucket=bucket_name, Key="query.json")
```
이 코드에서는 AWS S3 클라우드 저장소와 `boto3`라는 SDK를 직접 참조하고 있어,
다른 클라우드(예: Azure 또는 GCP),
혹은 로컬 파일 시스템 등으로 옮길 때마다 전체 구현체를 재구성해야 한다.
즉, 외부 의존성을 제거하지 않은 디자인이 결국 기술적 유연성과 재활용 가능성 속에서 실패한다는 의미가 된다.
이러한 상태는 공학적으로 잘못된 아키텍처라고 판단되며 경제적으로도 자본 낭비의 원천이 된다.
왜냐하면 어떤 작은 컴포넌트라도 장애 발생 후 이를 변경하려면 전체 서비스를 다시 개발해야 하기 때문이다.
즉, 만약 우리는 추론 엔진을 만들었고 그것이 AWS만 연결되면
그 엔진을 비행기에 적용하거나 공장 안의 독립 서버에 설치하려 할 때에는 반드시 새로운 구성이 필요해지고, 이것이 바로 '용접된 바퀴'로서 지속 가능한 성장을 방해한다.
따라서 중요한 질문은 다음과 같다:
우리가 만든 각 모듈들이, 자동차나 서비스가 사라져도 여전히 스스로 동작 가능하며 다양한 환경에서 가치를 창출할 수 있는지를 확인해야 하는데, 어떻게 그런 조건들을 설정할 것인가.
3. 진정한 모듈화란 무엇인가? → 독립적 생존
단순히 소프트웨어 내부에서 ‘코드를 쪼개는’ 것이 아니라 더 깊은 이해를 요구된다. 진정한 모듈화는 단지 논리적 분리를 넘어서야 하고, 그 부품이 얼마나 자기 자신에게 존재하는 값을 갖게 되느냐에 따라 평가되어야 한다.
이 개념을 정량적으로 설명하기 위해 아래 세 가지 핵심 요건을 도입한다.
1. 자체 실행 가능성
- 외부 API 호출 없이도, 입력 데이터를 받아 처리하여 출력 결과를 생성할 수 있다.
2. 다중 포맷 지원 능력
- JSON, CSV, Parquet, Protobuf 등의 다양하게 형식별로 제공되는 데이터를 모두 인식 및 변환 가능하다.
3. 오류 회복 메커니즘 포함
- 네트워크 장애나 리소스 과잉 상황에서도 작업 중간 상태를 저장하고 복구할 수 있어야 함.
4. 타임아웃 및 리소스 감시 시스템
- CPU 사용률이나 메모리 누수 등을 실시간으로 관찰하여 불안정성을 예방함.
이들 기준들은 특정 코드 라인이 아닌 ‘자신의 목적이 무엇이며, 어디서 작동할 수 있을까?’ 에 대한 설계 철학과 밀접하게 연관되며, 이걸 통해 모든 구성요소가 실제 운영 속에서 살아남을 수 있게 된다.
예컨대 추론 엔진이라는 컴포넌트가 다음처럼 설계될 경우이다:
- 초기: 문장을 파악해서 답변을 제시
- 이후 변화: 고객 행동 패턴을 식별하고 이를 기반으로 문제 유형 판별 수행
- 최종 역할: 조직 전체의 의사결정 투명성 확보와 대안 제안 등 전사적인 지능 플랫폼 중심 기술로서 발휘됨
이는 처음에는 Q&A용으로 만든 작은 함수였지만
시간이 가면서 자연스럽게 새로운 의미를 획득했음을 보여주는 사례다.
즉, 바퀴가 차체보다 먼저 주목받고 있는 순간,
이 설계가 빛을 발한다.
4. MAEUM AI OS의 구현 방향 — 현실 적용
MAEUM AI OS에서는 이러한 아키텍처 철학을 근본 원칙으로 삼으며
다음과 같은 디자인 규범들을 따르는 것을 목표로 한다.
1. 프로그래밍 언어 선택은 Python을 기본 스택으로 설정한다.
- 이유는 NLP 및 머신러닝 분야에 있어서 매우 우수한 생태계 존재하기 때문.
Hugging Face, LangChain, LlamaIndex 등과 직접 통합 가능하며
개발자가 쉽게 접근할 수 있음.
또한 간단하면서도 모듈화 된 학습/추론 사이클을 효율적으로 구축할 수 있다.
2. 의존성 최소화 정책 시행
- 외부 서비스(예: AWS S3) 또는 플랫폼 SDK에 직접 연결되지 않도록 하며,
입력 데이터만 받으면 처리 가능한 형태로 동작하도록 설계함.
각 컴포넌트는 인터페이스를 명확히 정해두고 독립적 실행이 되어야 함.
3. 입력 출력 인터페이스 표준화
어떤 형식인지 모르더라도 `read_input()` 메서드와 `write_output()`
메서드를 사용하여 작업을 진행해야 한다. 예를 들어 아래와 같이 코드를 작성한다:
```python
class ReasonerEngine:
def __init__(self):
self.memory = {} # 내부 상태 저장 공간 (외부 연관 없음)
def analyze(self, input_text: str) -> dict[str, any]:
return {
"intent": detect_intent(input_text),
"entities": extract_entities(input_text),
"confidence_score": compute_confidence()
}
def save_state(self, state_data: dict):
pass
def load_state(self, state_file_path: str):
pass
```
모든 로직은 문자열이나 딕셔너리 형태로 전달되므로
다양한 시스템에서 재사용 가능하고 환경 변화에도 민감하지 않은 특성을 갖춘다.
4. 독립적인 운영 가능성 확보
- 자동차 전체(서비스)가 사라져도
추론 엔진이나 라우팅 모듈이 공장 속에서도 작동하거나 비행기 안에서도 문제없이 수행되어야 한다.
5. 오류 회복 기능 포함
- 장애 발생 후 복구가 가능하게 하고, 중간 결과를 파일이나 임시 DB에 보관하는 방안을 마련해야 한다.
5. 대체 방법 평가 — 다른 아키텍처의 한계
1. 전체 서비스 중심 설계
초기부터 ‘전체 목적’을 달성하려는 방식으로 모든 구성 요소들을 강한 결합 관계로 묶어 만든 경우이다.
이 방식에서는 다음 문제가 나타난다.
- 미래 역할 변환 예측 불가 → 어느 순간 특정 부품이 핵심 성과를 책임지게 될지를 미리 알 수 없다.
- 리팩토링 어려움 → 작은 조각들이 체계에 고정되어 있어 분리나 이식이 어렵다.
- 경제적 낭비 유발 → 개별 부분에 대한 투자가 결국 전체 구조 실패로 연결될 위험 존재함.
2. 고성능 언어 활용 (Rust 또는 Go 등)
Rust나 Go는 처리 효율성이 매우 좋지만
자연언어 이해 및 머신러닝 적용 과정에서 다음과 같은 제약이 있다.
- 데이터 형변환 프로세스가 단순화되지 않아 실시간 인사이트 생성 작업에는 적합하지 않음.
- ML 모델 교육 이후 가중치와 벡터 등을 바로 사용하기 위해 Python 환경과 통합 필요.
- 파이프라인 내에서 상호작용이 많으니 유지보수 용이성 저하됨.
결국 이러한 이유들 때문에 성능보다 유연성이 더 중요하다고 판단된다.
즉, 어떤 환경에서든 동작 가능한 상태이며
스스로 의미 있는 가치를 창출할 수 있도록 하는 것이 진짜 중요한 목표인 것이다.
6. 최종 정리 및 메타 패턴 도입
Lee 의 “바퀴가 주인공이 되는 순간”이라는 철학은
소프트웨어 디자인이 아닌, 그 자체로서 시스템이 어떻게 변화하고 진화하며
자체적인 생명력을 갖도록 만들어져야 할 것인지라는 질문을 던진다.
우리는 처음엔 '서비스'를 위한 도구라고 생각했지만,
실제로는 우리가 만든 각 컴포넌트들이 시간이 지남에 따라
자신만의 기준과 가치를 가지며 독립적으로 작동할 수 있다.
따라서 아래와 같이 명확히 규정할 수 있겠다.
모든 소프트웨어 구성요소는 초기 목적이 아니라,
자기에게 내재된 가치를 갖고 살아남아야 한다.
그것이 무엇이고 어디서 사용되든,
자동차 없이도 공장 속에서 돌아갈 수 있어야 하고,
비행기에 장착돼도 문제없이 작동해야 한다.
MAEUM AI OS에서는 이를 바탕으로 다음 규범들을 실행한다:
1. 외부 의존성 최소화
2. 독립적 실행 가능성 확보
3. 다양한 포맷 지원과 오류 회복 메커니즘 포함
4. 데이터 처리 과정 중 간단한 인터페이스 중심 설계 유지
이것들은 단지 하나의 플랫폼 개발 방식 이상의 영향력이다.
앞으로의 혁신은 더욱 복잡하면서 다층적인 형태로 진행될 것이다.
어느 서비스나 플랫폼이 특정 목적을 달성하는 데 초점을 두더라도,
그 안쪽에 숨겨진 작은 알고리즘이 —
학습 능력이나 판단력을 가지고 있으면 —
스스로 성장을 거쳐 핵심 역할을 수행하도록 해야 한다.
마지막으로 말하고 싶은 것은 이렇다:
“우리는 서비스를 위해 만들어낸 코드가 아니라,
세상을 바꾸고 살아남는 도구로서 개발되어야 한다.”
바퀴가 차체를 넘어섰다는 사실이
우리의 기술이 진짜로 ‘활성’되고 있다는 증거가 될 수 있고,
바로 그 순간부터 우리는 더 나은 아키텍처를 추구하기 시작한다.
— 이것이 MAEUM AI가 제안하는 아주 본질적인 설계 철학이다.