최근 AI 기술은 눈부시게 발전하고 있습니다. 더 크고 강력한 모델들이 등장할 때마다 “이제 AI가 개발을 완전히 대신할 것 같다”는 기대감도 커지고 있습니다. 하지만 실제 개발 현장에서 AI를 활용해보면, 화려한 성능 지표와는 다르게 AI가 곧바로 생산성을 보장해주지는 않는다는 사실을 느끼게 될 때가 많은 것 같습니다.
11월에 진행된 슬렉슨 웨비나: “컨텍스트 엔지니어링 전후로 살펴보는 CodeCenter 생산성 실험”에서는 AI의 언어 능력이 아무리 뛰어나도 실제 개발 흐름 안에 녹여 넣기 위해서는 적절한 컨텍스트 엔지니어링이 필수적이며, 계획된 개발 프로세스가 있어야 생산성이 뚜렷하게 향상된다는 점을 간단한 비교 실험을 통해 보여드린 바 있습니다. 이번 글에서는 웨비나의 내용을 전체적으로 요약하여 살펴보고 웨비나에서 전달하려는 메시지를 다시한번 짚어 보도록 하겠습니다.
| Parameter vs Context Window - AI의 지식과 기억력
웨비나는 먼저 최근 AI 모델들이 가진 구조적 한계를 소개하며 시작했습니다.
대부분 단순히 파라미터가 큰 모델이 곧 좋은 모델이라고 생각하기 쉽지만, 실제 개발에서는 파라미터 외에도 결과에 중요한 영향을 미치는 다양한 요소가 존재할 수 있습니다.
Parameter(파라미터)는 AI의 지식량이라고 말할 수 있습니다. 규모가 큰 모델일수록 더 많은 정보를 알고 있고, 더 깊은 추론 능력을 보이며, 다양한 주제를 폭넓게 처리합니다. 즉, 파라미터는 AI가 얼마나 ‘똑똑한가’를 나타내는 지표입니다.
Context Window는 AI의 단기 기억력이라고 볼 수 있습니다. 개발 업무는 단순히 “질문–답변”으로 해결되지 않고, 설계부터 구현, 테스트까지 많은 맥락을 유지한 상태로 이어지는 과정이기 때문에 파라미터보다 컨텍스트 윈도우의 크기와 관리 방식이 오히려 중요한 요소로 작용할 수 있습니다.
Context Window 란 :
- 한 세션 안에서 기억할 수 있는 정보의 양
- 세션이 길어질수록 내용을 잊어버리는 구조적 이유
- 대화가 길어지면 일관성이 떨어지는 근본 원인
| Chat Bot vs Agentic AI – 개발 생산성 관점에서의 명확한 차이
웨비나에서는 Chat Bot AI와 Agentic AI의 차이를 개발 생산성 관점에서 설명했습니다.
1) Chat Bot
- 사용자의 질문에 답변하는 데 최적화
- 대화창 내부의 상호작용에 머무름
- 텍스트·이미지 생성 같은 정보 제공 중심
2) Agentic AI
- 목표를 완수하는 데 최적화
- 계획 수립(Planning) → 도구 사용(Tool Use) → 실행까지 수행
- 외부 API·앱·웹사이트와 직접적으로 상호작용
- 개발·테스트·빌드 작업까지 자동으로 수행
결국 생산성 향상은 단순 텍스트 생성이 아니라, AI가 직접 작업을 수행할 수 있는 Agentic 구조에서 완성된다는 점이 강조되었습니다.
| CodeCenter – 모델, IDE, 도구, 환경을 모두 아우르는 개발 중심 AI 코딩 플랫폼
CodeCenter는 이러한 Agentic 구조를 실전에서 활용할 수 있도록 돕는 플랫폼입니다. 웨비나에서는 다음과 같은 장점이 소개되었습니다.
- 다양한 AI 모델 지원
- VSCode, JetBrains 등 IDE 플러그인 연동
- Air-gap 환경 지원 : 내부망에서도 사용 가능
- MCP(Modular Command Protocol) 기반의 도구 확장
- (빌드, 테스트, 파싱, UI 테스트 등 자동화)
한마디로 단순히 AI와 대화를 주고받는 수준을 넘어 개발 환경을 활용해 AI가 실제 작업을 수행할 수 있도록 지원하는 플랫폼이라고 볼 수 있겠습니다.
| 생산성을 결정하는 설계, 구현, 테스트의 구조화된 흐름
웨비나에서는 CodeCenter의 생산성 향상 전략을 실제 개발 과정에 맞춰 다음 세 단계로 정리해 설명했습니다.
1) 설계 단계
웨비나에서는 CodeCenter의 생산성 향상 전략을 실제 개발 과정에 맞춰 다음 세 단계로 정리해 설명했습니다.
- 프로그램 목표 정의
- Tech Stack 정의
- 기능·비기능 요구사항 정의
- API Endpoint 구조 정의
- 코드 컨벤션 지정
- 코드 컨벤션 지정
이 단계가 명확할수록 구현에서 발생하는 AI의 확률적 추측을 크게 줄일 수 있습니다.
2) 구현 단계 – 설계를 기반으로 안정적인 개발
웨비나에서는 CodeCenter의 생산성 향상 전략을 실제 개발 과정에 맞춰 다음 세 단계로 정리해 설명했습니다.
- .ignore 파일등을 활용해 불필요한 파일들을 컨텍스트에서 제외
- 요구사항 단위로 분리된 세션 운영
- 각 세션 종료 전에 작성된 내용을 문서로 자동 요약해 재사용성 확보
- 설계 문서를 기반으로 코드 생성
즉흥적으로 프롬프트를 사용하지 않고 설계를 기반으로 코드를 안정적으로 만들 수 있는 구조를 먼저 만든다는 점을 강조하였습니다.
3) 테스트 단계 – MCP 기반 자동 검증 시스템
마지막으로 테스트 단계에서는 AI가 직접 테스트를 생성하고 실행하는 자동화 과정이 포함되었습니다.
- Unit Test 생성
- 빌드·실행·보안 점검
- Playwright MCP를 활용한 UI 자동화 테스트
이 과정 덕분에 개발자 개입 없이도 오류를 빠르게 탐지하고 수정할 수 있습니다.
데모: 즉흥적 개발과 계획적 개발의 차이 비교
웨비나에서는 다음 두가지 데모를 차례대로 진행하여 각각의 방식에 따른 결과의 차이를 보여주었습니다.
- A 데모 : 추상적이고 즉흥적인 프롬프트를 사용한 개발
- B 데모 : 계획 기반으로 각단계를 체계적으로 분리하여 진행한 개발
먼저 A 데모에서는 추상적인 프롬프트로 요구사항을 즉석에서 추가하며 구현을 시도하여 즉흥 프롬프트 기반 개발의 한계를 보여주었습니다.
- 기술 스택이 매번 달라짐
- 파일 업로드, 이미지 생성 과정에서 반복적인 오류 발생
- 작은 버그(이벤트 중복 등)조차 해결하지 못함
- 테스트 도구 없이 사람이 직접 시행착오 반복
B 데모에서는 설계, 구현, 테스트를 체계적으로 분리하여 계획 기반 Agentic 개발의 이점을 보여주었습니다.
- 아키텍처·API Spec·데이터 흐름 등 설계 완비
- 설계를 기반으로 안정적인 Backend·Frontend 구현
- Playwright MCP로 UI까지 자동 검증
- 오류 최소화 및 인적 개입 최소화
결론 – AI 시대의 생산성은 프롬프트를 적절히 활용하는 능력에서 비롯됩니다
두가지 데모의 결과를 비교해보면 AI개발 도구를 적절히 사용하기 위해서는 구조화된 프롬프트 엔지니어링 과정이 반드시 필요하다는 점을 보다 명확하게 확인할 수 있습니다.
|
항목
|
A 데모
|
B 데모
|
|---|---|---|
|
총 요청
|
57회
|
44회
|
|
사용 토큰
|
3,005,869
|
2,078,185
|
|
구현 시간
|
60분
|
25분
|
|
기능 완성도
|
낮음
|
높음
|
이번 웨비나의 핵심 메시지는 AI가 개발자를 완전히 대체하는 것을 기대하기 보다는 개발 프로세스 전반을 함께 수행하는 방식으로 활용하는 것이 더욱 중요하다는 점입니다.
이때 생산성의 차이를 만드는 요소는 설계, 구현, 테스트로 이어지는 구조화된 흐름을 AI가 이해하고 따를 수 있도록 안내하는 역량이라고 볼 수 있겠습니다.
CodeCenter는 이러한 구조적 접근을 실질적으로 구현할 수 있는 플랫폼이며, Agentic AI 기반 기능을 통해 개발 생산성을 실질적으로 향상시킬 수 있다는 점을 이번 실험 사례를 통해 확인할 수 있었습니다.
