창업자 저널(Founder Journal) #7 — 더 나은 프롬프트 작성을 넘어 더 나은 엔지니어링 시스템 구축으로

"훌륭한 프롬프트는 오늘의 과제를 해결할 수 있습니다. 훌륭한 엔지니어링 시스템은 내일의 과제 또한 해결할 수 있습니다."

프롬프트 엔지니어링(Prompt Engineering)의 부상

대규모 언어 모델(Large Language Models, LLM)이 처음 널리 보급되었을 때, 프롬프트 엔지니어링(Prompt Engineering)은 빠르게 필수적인 기술로 떠올랐습니다.

개발자들은 AI 출력의 품질이 지시 사항을 어떻게 작성하느냐에 크게 좌우된다는 것을 발견했습니다.

단어 선택의 작은 변화만으로도 극적으로 다른 결과를 만들어낼 수 있었습니다.

자연스럽게 팀들은 다음과 같은 항목에 투자하기 시작했습니다:

• 프롬프트 라이브러리 (Prompt libraries)
• 프롬프트 템플릿 (Prompt templates)
• 시스템 프롬프트 (System prompts)
• 역할 기반 프롬프팅 (Role-based prompting)
• 퓨샷 예시 (Few-shot examples)
• 생각의 사슬(Chain-of-thought)에서 영감을 받은 워크플로우
• 재사용 가능한 프롬프트 컬렉션 (Reusable prompt collections)

프롬프트 엔지니어링은 중요한 학문 분야가 되었습니다.

그리고 여전히 그렇습니다.

하지만 점점 더 복잡해지는 소프트웨어 프로젝트를 수행하면서, 저는 중요한 사실 하나를 깨달았습니다.

프롬프트 엔지니어링(Prompt Engineering)만으로는 소프트웨어 엔지니어링(Software Engineering)으로 확장될 수 없다는 점입니다.

프롬프트의 한계

다음과 같은 프롬프트를 상상해 보세요:

"시니어 소프트웨어 엔지니어로서 행동하세요. 클린 아키텍처(Clean Architecture)를 사용하여 Go 언어로 확장 가능한 REST API를 구축하고, 단위 테스트(Unit tests)를 작성하며, 베스트 프랙티스(Best practices)를 따르고, 모든 것을 문서화하며, 성능을 최적화하고, 보안을 보장하며, 프로덕션(Production) 환경을 준비하세요."

포괄적으로 들립니다.

하지만 이는 즉시 몇 가지 질문을 던지게 만듭니다.

이 조직에서 **클린 아키텍처(Clean Architecture)**란 무엇을 의미하는가?

어떤 로깅 라이브러리(Logging library)가 표준인가?

어떤 보안 요구 사항이 필수적인가?

설정(Configuration)은 어떻게 관리되어야 하는가?

어떤 문서화 형식이 기대되는가?

어떤 API 버전 관리 전략이 이미 채택되었는가?

에러(Errors)는 어떻게 표현되어야 하는가?

모든 프로젝트별 결정 사항이 프롬프트 내에 포함되어 있지 않는 한, 프롬프트는 이러한 질문에 답할 수 없습니다.

결국, 프롬프트는 채팅 메시지로 위장한 엔지니어링 매뉴얼이 되어버립니다.

이는 지속 가능하지 않습니다.

프롬프트는 인프라가 아니라 인터페이스입니다

프롬프트는 인간과 AI 모델 사이의 인터페이스(Interface)입니다.

그것은 엔지니어링 시스템(Engineering system) 그 자체가 아닙니다.

API를 생각해 보십시오.

API는 기능(Functionality)에 대한 접근을 제공합니다.

하지만 API가 비즈니스 그 자체를 정의하지는 않습니다.

마찬가지로, 프롬프트(Prompts)는 의도(Intent)를 전달합니다.

프롬프트가 엔지니어링 지식의 주요 저장소(Repository)가 되어서는 안 됩니다.

엔지니어링 지식은 더 영구적인 보금자리를 가질 자격이 있습니다.

소프트웨어 엔지니어링(Software Engineering)은 공유된 지식을 필요로 합니다

모든 성숙한 엔지니어링 조직은 시간이 흐름에 따라 조직적 지식(Institutional knowledge)을 구축합니다.

여기에는 다음이 포함됩니다:

• 아키텍처 원칙 (Architectural principles)
• 코딩 표준 (Coding standards)
• 디자인 패턴 (Design patterns)
• 보안 관행 (Security practices)
• 명명 규칙 (Naming conventions)
• 문서화 형식 (Documentation formats)
• 리뷰 프로세스 (Review processes)
• 배포 워크플로 (Deployment workflows)

이것들은 일시적인 지침이 아닙니다.

이것들은 조직의 자산(Organizational assets)입니다.

만약 AI가 엔지니어링 팀과 함께 작동하기를 기대한다면, AI는 매 대화마다 지식을 재창조하는 것이 아니라 이러한 공유된 자산을 사용하여 작동해야 합니다.

프롬프트 엔지니어링(Prompt Engineering)과 AI 엔지니어링(AI Engineering)의 차이

프롬프트 엔지니어링은 상호작용(Interactions)을 개선하는 데 집중합니다.

AI 엔지니어링은 시스템(Systems)을 개선하는 데 집중합니다.

프롬프트 엔지니어링은 다음과 같이 답합니다:

"어떻게 질문해야 하는가?"

AI 엔지니어링은 다음과 같이 질문합니다:

"AI가 어떤 엔지니어링 환경 내에서 작동해야 하는가?"

그 차이가 모든 것을 바꿉니다.

프롬프트보다 엔지니어링 시스템이 더 중요합니다

동일한 AI 모델을 사용하는 두 팀을 상상해 보십시오.

팀 A

• 뛰어난 프롬프트
• 문서 없음
• 아키텍처 없음
• 코딩 표준 없음
• 거버넌스(Governance) 없음

팀 B

• 적절한 수준의 프롬프트
• 강력한 아키텍처
• 엔지니어링 표준
• 살아있는 문서(Living documentation)
• 결정 기록(Decision records)
• 워크플로 자동화(Workflow automation)

어느 팀이 향후 3년 동안 더 신뢰할 수 있는 소프트웨어를 생산할 가능성이 높을까요?

거의 확실히 팀 B입니다.

소프트웨어 품질은 대화 기술보다 엔지니어링 시스템에 더 많이 의존하기 때문입니다.

더 나은 멘탈 모델(Mental Model)

다음과 같이 생각하는 대신:

개발자 (Developer)
      │
      ▼
...

대신 이것을 고려해 보십시오:

Developer
      │
      ▼
...

프롬프트(Prompt)는 여전히 존재합니다.

하지만 그것은 훨씬 더 거대한 엔지니어링 생태계(Engineering Ecosystem) 내부의 하나의 구성 요소가 될 뿐입니다.

NAEOS가 프롬프트로 시작하지 않는 이유

NAEOS의 설계 결정 중 하나는 의도적으로 프롬프트 우선(Prompt-first) 아키텍처를 피하는 것이었습니다.

대신, NAEOS는 다음 요소들로부터 시작합니다:

• 참조 아키텍처 (Reference Architecture)
• 엔지니어링 헌장 (Engineering Constitution)
• 문서화 표준 (Documentation Standards)
• 컨텍스트 관리 (Context Management)
• 정책 엔진 (Policy Engine)
• 지식 베이스 (Knowledge Base)
• 메모리 레이어 (Memory Layer)
• 워크플로 런타임 (Workflow Runtime)

프롬프트는 이러한 시스템들과 상호작용합니다.

프롬프트가 시스템을 대체하는 것이 아닙니다.

그 결과, AI 에이전트(AI agents)는 코드를 생성하기 시작하기 전에 엔지니어링 컨텍스트(Engineering context)를 전달받습니다.

이는 점점 더 복잡해지는 프롬프트를 요구하지 않고도 일관성(Consistency)을 향상시킵니다.

엔지니어링 지식은 재사용 가능해야 합니다

새로운 개발자를 온보딩(Onboarding)하는 상황을 상상해 보십시오.

당신은 그들에게 다음과 같은 제목의 단일 문서를 건네주지는 않을 것입니다:

"당신이 알아야 할 모든 것."

대신, 당신은 구조화된 환경을 제공합니다:

• 아키텍처 문서 (Architecture documentation)
• 코딩 가이드라인 (Coding guidelines)
• 개발 워크플로 (Development workflows)
• 결정 이력 (Decision history)
• 팀 컨벤션 (Team conventions)
• 기술 참조 (Technical references)

AI도 동일한 환경을 누릴 자격이 있습니다.

재사용 가능한 엔지니어링 지식은 재사용 가능한 프롬프트보다 훨씬 더 잘 확장(Scale)됩니다.

프롬프트 엔지니어링을 넘어

프롬프트 엔지니어링(Prompt engineering)이 사라지는 것은 아닙니다.

그것은 여전히 중요한 기술로 남을 것입니다.

하지만 저는 그것이 점차 더 넓은 학문 분야 내의 하나의 레이어(Layer)가 될 것이라고 믿습니다.

SQL을 작성하는 것이 데이터베이스 엔지니어링(Database engineering)의 일부일 뿐인 것처럼.

코드를 작성하는 것이 소프트웨어 엔지니어링(Software engineering)의 일부일 뿐인 것처럼.

프롬프트를 작성하는 것은 AI 엔지니어링(AI Engineering)의 한 부분이 될 것입니다.

프롬프트가 아닌, 엔지니어링 시스템이 장기적인 성공을 정의할 것입니다.

향후 전망

만약 프롬프트가 AI 엔지니어링의 한 레이어에 불과하다면, 그렇다면 무엇이 주요한 진실의 원천(Source of truth)이 될까요?

제 대답은 놀랍게 들릴지도 모릅니다:

문서화 (Documentation).

다음 기사에서는 왜 문서화가 수동적인 참조 자료에서 능동적인 엔지니어링 인프라(Engineering infrastructure)로 진화하고 있는지, 그리고 왜 AI가 개발자보다 문서를 더 자주 읽게 될 수도 있는지에 대해 탐구해 보겠습니다.

토론 (Discussion)

귀하의 팀은 현재 엔지니어링 지식(engineering knowledge)을 어떻게 보존하고 있습니까?

• 프롬프트 라이브러리 (Prompt libraries)
• 문서화 (Documentation)
• 위키 (Wikis)
• 아키텍처 결정 기록 (Architecture Decision Records)
• 소스 코드 (Source code)
• 조직적 지식 (Institutional knowledge)
• 기타?

시간이 흐르면서 어떤 방식이 가장 효과적이었습니까?