구조화된 워크플로우, 컨텍스트 엔지니어링 (Context Engineering), 그리고 인간의 감독이 어떻게 AI를 단순한 코딩 보조 도구에서 진정한 엔지니어링 파트너로 변화시킬 수 있는지에 대하여.

서론

생성형 AI (Generative AI)는 소프트웨어가 구축되는 방식을 빠르게 변화시키고 있습니다. 많은 개발 팀이 AI 기반 코딩 도구들을 실험해 왔지만, 진정한 과제는 코드를 생성하는 것이 아니라 신뢰할 수 있는 고품질의 결과물을 만들어내는 반복 가능한 프로세스를 구축하는 것입니다.

최근 우리는 AI가 전체 소프트웨어 개발 생명주기 (Software Development Lifecycle)를 어떻게 지원할 수 있는지 탐구하기 위해 실습 워크숍을 진행했습니다. 단순한 예제(Toy examples)를 사용하는 대신, 이번 세션은 구조화된 AI 지원 개발 워크플로우를 적용하면서 실제 비즈니스 문제를 해결하는 데 집중했습니다.

그 결과는 단순히 작동하는 소프트웨어 그 이상이었습니다. 우리는 엔지니어가 AI 에이전트 (AI agents)와 효과적으로 협업하고, 생산성을 향상하며, 엔지니어링 품질을 유지할 수 있도록 돕는 실질적인 프레임워크를 발견했습니다.

준비의 중요성

워크숍 전 전달된 핵심 메시지 중 하나는 간단했습니다:

코드로 시작하지 마세요. 이해부터 시작하세요.

개발자들은 코딩 에이전트와 협업하기 전에 비즈니스 요구사항을 미리 검토하고 문제 도메인 (Problem domain)에 익숙해지도록 권장받았습니다.

목표는 단순히 코드를 더 빠르게 생성하는 것이 아니라 다음과 같았습니다:
• 비즈니스 문제 이해
• AI가 생성한 출력물 검증
• 구현 계획에 대한 비판적 검토
• 구현 전 테스트 케이스 (Test cases) 확인

워크숍은 다음과 같은 중요한 원칙을 재확인시켜 주었습니다:

AI는 개발을 가속화할 수 있지만, 비즈니스 의도를 이해하는 책임은 여전히 인간에게 있습니다.

프롬프트 엔지니어링 (Prompt Engineering)에서 컨텍스트 엔지니어링 (Context Engineering)으로의 전환

AI에 관한 많은 논의는 완벽한 프롬프트 (Prompt)를 작성하는 데 집중합니다.
워크숍은 그보다 더 중요한 것을 강조했습니다:
컨텍스트 엔지니어링 (Context Engineering).
가장 좋은 결과는 엔지니어가 다음과 같은 사항을 제공했을 때 나타났습니다:
• 비즈니스 목표 (Business objectives)
• 기능적 요구사항 (Functional requirements)
• 수락 기준 (Acceptance criteria)
• 시스템 컨텍스트 (System context)
• 통합 의존성 (Integration dependencies)
• 아키텍처 제약 사항 (Architectural constraints)
• 신뢰할 수 있는 정보원 (Source-of-truth) 고려 사항

AI 에이전트에게 즉시 코드를 생성하라고 요청하는 대신, 팀은 먼저 포괄적인 컨텍스트를 제공하고 에이전트가 문제를 완전히 이해하도록 요구했습니다.
예를 들어:

"판매 플랫폼을 위한 새로운 Spring Boot 애플리케이션을 만들고 싶습니다. 요구사항을 검토하고, 수락 기준을 이해한 뒤, 구현 계획을 세우기 전에 저에게 요구사항에 대해 질문(Grill)하여 확인해 주세요."

비즈니스 요구사항은 판매자가 기존 시스템을 신뢰할 수 있는 정보원 (Source of truth)으로 활용하고 플랫폼 간의 불필요한 데이터 중복을 피하면서, 고객에게 서비스를 제공할 수 있는 간소화된 방법을 필요로 한다는 점을 설명했습니다.
이 정도 수준의 컨텍스트를 제공하는 것은 AI가 생성한 계획, 테스트 케이스 (Test cases), 그리고 구현 권장 사항의 품질을 극적으로 향상시켰습니다.

"질문하기 (Grill Me)" 접근 방식
워크숍에서 소개된 가장 가치 있는 개념 중 하나는 "Grill Me" 기법이었습니다.
AI 에이전트에게 즉시 솔루션을 제안하는 대신, 가정을 검증하고 요구사항을 철저히 이해할 때까지 후속 질문을 던지도록 지시하는 것입니다.
이는 에이전트를 단순한 코드 생성기에서 비즈니스 분석가 (Business analyst)로 변화시킵니다.
AI는 추측하는 대신 다음과 같은 질문을 던집니다:
• 우리가 달성하려는 비즈니스 결과는 무엇인가?
• 현재 어떤 시스템이 데이터를 소유하고 있는가?
• 통합 제약 사항은 무엇인가?
• 예외 케이스 (Edge cases)는 무엇인가?
• 성공을 구성하는 요소는 무엇인가?

목표는 계획이나 구현이 시작되기 전에 모호함을 제거하는 것입니다.
이는 개발이 시작되기 훨씬 전부터 요구사항의 공백을 발견해내는 경우가 많습니다.

구조화된 AI 개발 워크플로 (Structured AI Development Workflow)

워크숍은 엔지니어링 규율 (Engineering Discipline)을 유지하면서 AI의 효과를 극대화하도록 설계된 반복 가능한 워크플로 (Workflow)를 따랐습니다.

1단계: 요구사항 발견 (Requirement Discovery)

AI 에이전트 (AI Agent)에게 비즈니스 요구사항을 제공하고, 솔루션을 제안하기 전에 요청 사항을 완전히 이해하도록 요청합니다.
에이전트는 가용한 컨텍스트 (Context)를 검토하고 요구사항이 충분히 이해될 때까지 명확한 질문을 던져야 합니다.
결과: 문제에 대한 명확한 이해.

2단계: 구현 계획 (Implementation Planning)

요구사항이 이해되면, AI는 다음을 생성합니다:
• 솔루션 아키텍처 (Solution Architecture)
• 기술적 접근 방식 (Technical Approach)
• 작업 세분화 (Task Breakdown)
• 리스크 및 가정 (Risks and Assumptions)
결과: 실행 가능한 구현 계획.

3단계: 인간 검토 (Human Review)

개발자는 제안된 계획을 검토하고 가정을 검증합니다.
이는 프로세스에서 가장 중요한 단계 중 하나입니다.
목표는 계획을 맹목적으로 승인하는 것이 아니라 다음 사항을 확인하는 것입니다:
• 아키텍처 결정 (Architectural Decisions)
• 비즈니스 정렬 (Business Alignment)
• 누락된 요구사항 (Missing Requirements)
• 기술적 타당성 (Technical Feasibility)

결과: 검증된 구현 전략.

4단계: 테스트 주도 개발 (Test-Driven Development, TDD)

코드를 작성하기 전에 AI는 테스트 케이스 (Test Cases)를 생성합니다.
구조화된 TDD 접근 방식은 엔지니어가 구현을 시작하기 전에 예상되는 시스템 동작을 정의하도록 장려합니다.
이점은 다음과 같습니다:
• 더 나은 요구사항 검증
• 품질 향상
• 결과에 대한 높은 신뢰도
• 요구사항 공백의 조기 발견
결과: 비즈니스 요구사항에 부합하는 포괄적인 테스트 커버리지 (Test Coverage).

5단계: 테스트 케이스 검토 (Review Test Cases)

개발자는 생성된 테스트를 검토하여 다음을 보장합니다:
• 요구사항이 완전히 반영되었는지
• 엣지 케이스 (Edge Cases)가 포함되었는지
• 수락 기준 (Acceptance Criteria)이 충족되었는지
강력한 테스트 케이스는 구현이 시작되기 전에 요구사항의 공백을 빈번하게 드러냅니다.
결과: 신뢰할 수 있는 검증 기준.

6단계: 코드 구현 (Code Implementation)

요구사항, 계획, 테스트가 검증된 후, AI는 구현 코드(implementation code)를 생성합니다.
이전 단계에서 강력한 가드레일(guardrails)을 구축했기 때문에, 구현 품질이 크게 향상됩니다.
결과: 더 빠르고 정확한 개발.

7단계: 검증 및 개선 (Validation and Refinement)

AI가 생성한 코드는 기본적으로 프로덕션 준비가 완료된 것으로 간주해서는 안 됩니다.
엔지니어는 여전히 다음 작업을 수행해야 합니다:
• 코드 리뷰 (Code reviews)
• 기능 검증 (Functional validation)
• 성능 검증 (Performance verification)
• 보안 점검 (Security checks)
• 개선 및 최적화 (Refinement and optimization)
결과: 프로덕션 품질의 소프트웨어.

이 접근 방식이 효과적인 이유
워크숍을 통해 몇 가지 중요한 교훈이 도출되었습니다.

요구사항의 품질이 AI의 품질을 결정한다
출력물의 품질은 제공된 요구사항의 품질과 직접적으로 연관되어 있습니다.
명확한 비즈니스 요구사항은 일관되게 다음을 생성합니다:
• 더 나은 구현 계획
• 더 나은 테스트 커버리지 (test coverage)
• 더 나은 코드 품질

인간의 감독은 여전히 결정적이다

AI는 분석, 계획, 테스트 및 코딩을 가속화할 수 있습니다.
하지만 엔지니어링적 판단 (engineering judgment)을 대체할 수는 없습니다.

개발자는 여전히 다음 사항에 대한 책임을 집니다:
• 비즈니스 의도 이해
• 가설에 대한 의문 제기
• 아키텍처 (architecture) 평가
• 품질 보장

TDD는 AI와 매우 잘 보완된다

구현 전에 테스트를 생성하는 것은 개발자와 AI 에이전트 (AI agents) 사이에 강력한 파트너십을 형성합니다.
테스트는 구조를 제공하고, 기대치를 정의하며, 모호함을 줄여줍니다.
AI가 생성한 테스트와 인간의 리뷰를 결합하는 방식이 특히 효과적임이 증명되었습니다.

모델보다 프로세스가 더 중요하다

가장 놀라운 교훈 중 하나는 성공 여부가 사용 중인 특정 AI 모델보다는 그 모델을 둘러싼 워크플로 (workflow)에 더 많이 달려 있다는 점이었습니다.
팀들은 종종 "최고의" 모델을 찾는 데 집중합니다.
하지만 실제로 규율 있는 프로세스는 모델의 능력에만 의존하는 것보다 일관되게 더 나은 결과를 전달했습니다.

진화하는 개발자의 역할

아마도 가장 중요한 시사점은 소프트웨어 엔지니어링이 진화하고 있다는 점일 것입니다.
개발자들은 반복적인 코드를 작성하는 데 쓰는 시간은 줄이고, 다음과 같은 일에 더 많은 시간을 할애하고 있습니다:
• 비즈니스 문제 이해하기
• 솔루션 평가하기
• AI가 생성한 결과물 검토하기
• 시스템 설계하기
• 품질 표준 정의하기
• 아키텍처 결정 내리기
가장 가치 있는 엔지니어링 기술은 더 이상 코드를 빠르게 타이핑하는 것이 아닙니다.
그것은 적절한 컨텍스트 (Context)를 제공하고, 올바른 질문을 던지며, 올바른 결과물을 검증하는 것입니다.

결론

소프트웨어 개발의 미래는 엔지니어를 AI로 대체하는 것이 아닙니다.
그것은 인간의 전문 지식과 AI의 역량 사이에 효과적인 파트너십을 구축하는 것입니다.
이번 워크숍은 성공적인 AI 도입이 코드 생성 훨씬 전부터 시작된다는 것을 보여주었습니다. 그것은 요구사항을 이해하고, 풍부한 컨텍스트 (Context)를 제공하며, 가설에 의문을 제기하고, 계획을 검토하고, 테스트를 검증하며, 개발 라이프사이클 (Lifecycle) 전반에 걸쳐 품질에 대한 소유권을 유지하는 것에서 시작됩니다.
규율 있는 워크플로 (Workflow)와 결합될 때, AI는 단순한 생산성 도구 그 이상이 됩니다. 즉, 엔지니어링 팀을 위한 포스 멀티플라이어 (Force Multiplier, 승수 효과)가 됩니다.