창업자 저널 #4 — 왜 더 나은 모델만으로는 소프트웨어 엔지니어링을 해결할 수 없는가

"AI의 모든 세대는 점점 더 지능적이 됩니다. 하지만 엔지니어링이 없는 지능은 여전히 불완전합니다."

우리는 계속해서 더 나은 AI를 구축하고 있습니다

몇 달마다 새로운 모델이 등장합니다.

더 나은 추론을 수행합니다.

더 깔끔한 코드를 작성합니다.

지시 사항을 더 정확하게 따릅니다.

더 큰 컨텍스트 (Context)를 이해합니다.

자연스럽게, 많은 사람들은 이러한 개선이 결국 소프트웨어 엔지니어링을 해결할 것이라고 가정합니다.

저는 그렇게 되지 않을 것이라고 생각합니다.

모델이 충분히 좋지 않기 때문이 아닙니다.

우리가 모델에게 잘못된 문제를 해결하라고 요구하고 있기 때문입니다.

현재의 AI 워크플로우 (Workflow)

오늘날 대부분의 AI 보조 개발은 다음과 같은 모습입니다:

Developer
    │
    ▼
...

이 워크플로우는 단순합니다.

빠릅니다.

하지만 취약하기도 합니다.

모든 중요한 엔지니어링 결정은 어떻게든 대화(Conversation) 안에 담겨야 합니다.

대화 내용이 바뀌면, 엔지니어링 컨텍스트 (Engineering context)도 함께 바뀝니다.

소프트웨어 엔지니어링은 대화 그 이상입니다

새로운 시니어 소프트웨어 엔지니어를 채용한다고 상상해 보십시오.

첫날에 당신은 단순히 이렇게 말하겠습니까?

"우리의 결제 플랫폼을 구축하세요."

물론 아닙니다.

당신은 그들에게 다음을 제공할 것입니다:

• 시스템 아키텍처 (System architecture)
• 비즈니스 요구사항 (Business requirements)
• 엔지니어링 핸드북 (Engineering handbook)
• 코딩 표준 (Coding standards)
• 보안 정책 (Security policies)
• 팀 워크플로우 (Team workflows)
• 이전의 설계 결정 사항 (Previous design decisions)
• API 계약 (API contracts)
• 리포지토리 구조 (Repository structure)
• 제품 로드맵 (Product roadmap)

그제서야 그들은 코드 작성을 시작할 것입니다.

왜일까요?

엔지니어링에는 컨텍스트 (Context)가 필요하기 때문입니다.

AI도 다르지 않아야 합니다.

존재하지 않는 계층

개발자와 AI 사이에는 무언가가 빠져 있습니다.

또 다른 언어 모델 (Language model)이 아닙니다.

또 다른 IDE가 아닙니다.

또 다른 프롬프트 라이브러리 (Prompt library)도 아닙니다.

빠져 있는 것은 엔지니어링 계층 (Engineering layer)입니다.

프로젝트 지식을 AI가 일관되게 이해할 수 있는 무언가로 변환하는 책임을 지는 계층 말입니다.

이것 대신에:

Developer
    │
    ▼
...

이것을 상상해 보십시오:

Developer
    │
    ▼
...

그 중간 계층이 모든 것을 바꿉니다.

엔지니어링 계층(Engineering Layer) 내부에는 무엇이 있는가?

이 계층은 코드가 아닙니다.

그것은 엔지니어링 지식(Engineering knowledge)입니다.

예를 들어:

아키텍처 (Architecture)

• 시스템 경계 (System boundaries)
• 도메인 설계 (Domain design)
• 계층별 책임 (Layer responsibilities)
• 서비스 상호작용 (Service interactions)

표준 (Standards)

• 명명 규칙 (Naming conventions)
• 폴더 구조 (Folder structures)
• 코드 품질 규칙 (Code quality rules)
• 문서화 요구사항 (Documentation requirements)

거버넌스 (Governance)

• 보안 정책 (Security policies)
• 승인 워크플로우 (Approval workflows)
• 컴플라이언스 요구사항 (Compliance requirements)
• 품질 게이트 (Quality gates)

컨텍스트 (Context)

• 비즈니스 목표 (Business goals)
• 제품 비전 (Product vision)
• 사용자 요구사항 (User requirements)
• 기술적 제약 사항 (Technical constraints)

메모리 (Memory)

• 이전 엔지니어링 결정 사항 (Previous engineering decisions)
• 아키텍처 결정 기록 (Architecture Decision Records, ADRs)
• 학습된 교훈 (Lessons learned)
• 과거의 트레이드오프 (Historical trade-offs)

워크플로우 (Workflow)

• 개발 라이프사이클 (Development lifecycle)
• 리뷰 프로세스 (Review process)
• 릴리스 전략 (Release strategy)
• 배포 자동화 (Deployment automation)

이 요소들이 모여 단순한 대화가 아닌, 하나의 엔지니어링 환경을 형성합니다.

더 나은 프롬프트가 더 나은 시스템을 대체할 수는 없다

많은 팀이 더 긴 프롬프트를 작성함으로써 일관성 문제를 해결하려 노력합니다.

어떤 프롬프트는 수백, 심지어 수천 줄에 달하기도 합니다.

결국, 프롬프트는 지시문(Instruction)이라기보다는...

...운영 매뉴얼(Operating manual)에 가까워지기 시작합니다.

그것은 하나의 신호입니다.

그 지식은 채팅창보다 더 영구적인 어딘가에 속해야 한다는 의미입니다.

엔지니어링 시스템은 재사용 가능해야 합니다.

프롬프트는 가벼운 상태로 유지되어야 합니다.

운영체제(Operating System) 비유

개인용 컴퓨터를 생각해 보십시오.

애플리케이션은 하드웨어와 직접 상호작용하지 않습니다.

운영체제(Operating system)는 다음을 제공합니다:

• 리소스 관리 (Resource management)
• 메모리 관리 (Memory management)
• 보안 (Security)
• 프로세스 조정 (Process coordination)
• 표준 인터페이스 (Standard interfaces)

운영체제가 없다면, 모든 애플리케이션은 이러한 문제들을 독립적으로 해결해야 할 것입니다.

오늘날의 소프트웨어 엔지니어링도 유사한 도전에 직면해 있습니다.

모든 AI 프로젝트는 다음을 반복해서 다시 구축합니다:

• 컨텍스트 (Context)
• 표준 (Standards)
• 워크플로우 (Workflows)
• 규칙 (Rules)
• 문서화 (Documentation)
• 메모리 (Memory)

계속해서 반복합니다.

만약 엔지니어링 자체를 위한 운영 계층(Operating layer)이 있다면 어떨까요?

CPU를 위한 것이 아니라.

서버를 위한 것도 아닌 말입니다.

하지만 AI 보조 소프트웨어 개발 (AI-assisted software development)을 위한 것이라면 어떨까요.

그 질문이 NAEOS의 토대가 되었습니다.

AI 엔지니어링 계층 (AI Engineering Layer) 소개

NAEOS는 그 누락된 계층이 되도록 설계되었습니다.

그 목적은 AI 모델을 대체하는 것이 아닙니다.

대신, AI가 작동하는 환경을 제공합니다.

그 관계를 다음과 같이 생각할 수 있습니다:

• AI 모델은 지능 (intelligence)을 제공합니다.
• 개발자는 창의성 (creativity)과 판단력 (judgment)을 제공합니다.
• NAEOS는 엔지니어링 규율 (engineering discipline)을 제공합니다.

각각은 서로 다른 역할을 수행합니다.

이들이 모여 하나의 완전한 엔지니어링 시스템을 형성합니다.

개별 도구를 넘어선 미래

오늘날 개발자들은 종종 AI 도구들을 비교합니다:

• 어떤 모델이 코드를 더 잘 작성하는가?
• 어떤 IDE가 더 나은 자동 완성 (autocomplete) 기능을 갖추었는가?
• 어떤 코딩 에이전트 (coding agent)가 더 빠른가?

이것들은 유용한 질문들입니다.

하지만 가장 중요한 질문은 아닙니다.

더 중요한 질문은 다음과 같습니다:

모든 AI 도구가 동일한 엔지니어링 기반 위에서 작동할 수 있는가?

만약 대답이 '예'라면, 모델 간의 전환은 훨씬 쉬워질 것입니다.

기저의 AI가 진화하더라도 엔지니어링 지식은 안정적으로 유지됩니다.

그것이 더 지속 가능한 미래입니다.

엔지니어링은 이식 가능해야 한다

하나의 AI 모델에서 다른 모델로 변경하는 상황을 상상해 보십시오.

그 외의 다른 것은 아무것도 변하지 않습니다.

당신의 아키텍처 (architecture)는 온전하게 유지됩니다.

당신의 문서화 (documentation)는 권위를 유지합니다.

당신의 엔지니어링 정책 (engineering policies)은 강제력을 유지합니다.

당신의 AI는 이미 정의된 환경에 그저 적응할 뿐입니다.

이것이 이식성 (portability)입니다.

코드의 이식성이 아니라,

엔지니어링 지식의 이식성 말입니다.

향후 계획

다음 기사에서는 더 큰 아이디어를 탐구할 것입니다:

AI에게 운영 체제 (Operating System)가 있다면 어떨까?

우리는 왜 운영 체제라는 비유가 단순한 브랜딩 그 이상인지, 그리고 그것이 어떻게 NAEOS 이면의 아키텍처와 철학을 형성하는지 살펴볼 것입니다.

토론

오늘날 AI 보조 소프트웨어 개발에서 가장 큰 한계는 무엇이라고 생각하십니까:

• AI 모델?
• 프롬프트 (prompts)?
• 엔지니어링 프로세스 (engineering process)?
• 공유된 프로젝트 지식의 부족?
• 아니면 완전히 다른 무언가?

여러분의 관점을 듣고 싶습니다.