커네빈 프레임워크를 현대의 AI 에이전트 기반 개발 및 코드 결합도 관리 학습한것을 생각하고 정리하였습니다.
1. 커네빈 프레임워크의 본질
'Cynefin'은 서식지나 터전을 뜻하는 웨일스어입니다.
본 프레임워크의 핵심 목적은 주어진 컨텍스트에 따라 최적의 전략을 선택하는 것입니다.
이때 컨텍스트를 결정짓는 핵심 기준은 '문제에 대한 이해 가능성'입니다.
문제가 얼마나 명확하게 정의되고 파악되는지에 따라 5가지 영역으로 나뉘며, 각 영역별 문제 해결 전략과 비즈니스 및 개발 영역의 대응 방식이 달라집니다.
[Disorder] (상황 파악 불가 / 가시성 부재)
│
┌──────────────────────────┼──────────────────────────┐
│ │ │
▼ ▼ ▼
[Chaotic] [Complex] [Complicated] [Clear]
답의 부재 실험과 피드백 답의 예측 가능 정답의 존재 확신
(랜덤 시도) (도메인 솔루션) (전문가/AI 탐색) (문제 분류 및 적용)
컨텍스트별 특징 및 일반적인 주체
- Clear
- 특징: 답의 존재를 확신하는 영역입니다.
문제만 정확히 분류하면 정답을 바로 적용할 수 있습니다. - 주체: 일반적인 규칙 기반 업무, 매뉴얼화된 직무.
- Complicated
- 특징: 정답이 존재함을 알고 있으나 당장 내 머릿속에 없는 상태입니다.
전문가의 조언, 검색, 혹은 AI 분석을 통해 정답을 찾아낼 수 있습니다. - 주체: 과거 엔지니어링 영역, 특화된 기술 전문가.
- Complex
- 특징: 기성 정답이 존재하지 않지만, 논리적 가설을 바탕으로 도메인 내 솔루션을 만들어갈 수 있는 영역입니다.
가설 설정 후 반복적인 실험을 통해 답을 만들어내며, 고객과 시장의 수용 여부가 곧 정답이 됩니다. - 주체: 기획자, 기획/사업 개발 팀.
- Chaotic
- 특징: 답이 존재할지조차 예측할 수 없는 긴급 상황입니다.
방향성 있는 실험보다는 무작위 가설 검증과 기록을 통해 비즈니스 생존을 위한 대안을 발굴해 내야 합니다. - 주체: 성과 압박을 받는 C-Level, 사업부 책임자.
- Disorder
- 특징: 상황 파악 자체가 불가능한 상태입니다. 판단을 유보하고 관망하거나 기초적인 상황 가정이 우선되어야 합니다.
- 주체: 인수합병, 조직 개편, 프로젝트 전면 재검토 등 외부 충격에 노출된 조직.
2. 개발 생태계의 변화 바이브 코딩가 가져온 영역 확장
과거 개발자들은 불확실성을 극도로 경계하며 Clear 영역에만 머무르려 했습니다.
"백엔드 전문이라 프론트는 모릅니다", "CSS는 내 영역이 아닙니다"라는 스탠스는 Clear 영역 밖으로 나가지 않으려는 방어 기제였습니다.
Complicated 문제조차 조직에 인력 추가 모바일 개발자, 백엔드 개발자 채용 를 요구하며 Clear 영역으로 환원시켜 해결하려 했습니다.
그러나 LLM과 AI 에이전트가 도입되면서 개발자의 커버리지가 급격히 확장되었습니다.
[과거 개발자] : Clear (명확한 영역만 담당)
[현대 개발자] : Clear ──► Complicated ──► Complex (AI 파트너십을 통한 실험 영역 진출)
-
Complicated 영역 흡수: 모르는 프레임워크나 API라도 AI가 답을 찾아 해결해 주기 때문에, 개발자는 전문가 채용 없이도 즉시 타 영역 개발에 착수합니다.
-
Complex 영역 진출: AI를 '실험 파트너'로 삼아 가설을 빠르게 프로토타이핑하고, 기존 기획자의 전유물이던 도메인 탐색 및 실험 영역까지 개발자가 주도하기 시작했습니다.
3. 개발자 관점의 커네빈 코드 변경 영향도와 소프트웨어 품질
소프트웨어 엔지니어링 시각에서 '문제 이해력'은 곧 '코드 수정에 따른 여파의 이해력'으로 정의됩니다.
| 영역 | 변경 여파의 이해 가능성 | 테스트/검증 전략 | 결합도 | 유연성 |
|---|---|---|---|---|
| Clear | 명확함: 수정에 따른 여파가 전혀 없음을 확신함 | 격리된 구조, 안전한 직접 수정 | 매우 낮음 | 낮음 |
| Complicated | 예측 가능: 영향 범위 예측 가능, 컴파일 시점에 검증 가능 | 타 팀/영역과 사전 합의 후 수정, 강타입/컴파일 타임 검증 | 낮음~보통 | 보통 |
| Complex | 예측 불가: 런타임에만 파악 가능한 예외 발생 | 런타임 테스트 안전망 (Harness) 및 실패 시 롤백 | 높음 | 높음 |
| Chaotic | 파악 불가: 안전망 부재, 런타임 여파 복원 불가능 | QA 팀에 의존 또는 폐기 후 재작성 | 극도로 높음 | 극도로 높음 |
런타임 여파의 본질적 한계
Complex 이상부터 발생하는 런타임 에러는 특정 실행 스택만으로 원인 재현이 불가능한 경우가 많습니다.
제어할 수 없는 런타임 문제에 대응하기 위해 테스트 하네스를 구축하지만, 구조적 설계 없이 AI에 의존하여 수정과 테스트를 반복하면 "테스트는 롤백되나 정답 코드로 수렴하지 못하는 무한 루프"에 빠지게 됩니다.
4. 바이브 코딩의 함정과 아키텍처 결합도 전략
현재 대다수의 바이브 코딩 프랙티스가 저지르는 실수는 Chaotic 상태의 코드를 생산하면서도 이를 검증하는 테스트 코드조차 AI에게 맡겨 Chaotic에 머무르는 것입니다.
안전성 vs 유연성
- 하네스 및 격리의 극대화 :
- 모듈 간 결합도를 낮추고 촘촘한 제약 조건을 걸어두면 안전한 수정을 보장하지만, AI 모델이 발휘할 수 있는 창의성과 문제 해결의 유연성을 제약합니다.
- 제약의 완화:
- 결합도가 높아지고 코드가 유연해질수록 AI가 광범위하게 코드를 수정하며 의외의 문제 해결책을 제시하지만, 코드의 유지보수성은 붕괴합니다.
조직의 자원 구조에 따른 전략 선택
- 자원이 풍부한 대기업 / 리소스가 충분한 조직
- 서포트 조직, QA 인프라, 시니어의 코드 리뷰 자원이 풍부하므로, 유연성을 극대화하는 방향으로 빠르게 개발하고 사후에 인력과 시스템으로 받쳐주는 전략을 취할 수 있습니다.
- 소규모 조직 / 엔지니어링 리소스가 제한된 팀
- Chaotic 상태를 방치할 자원이 없으므로, 아키텍처 결합도를 강제로 낮추고 Chaotic 영역에 있는 코드를 최소한 Complicated, 최종적으로는 Clear 영역으로 끌어올리는 설계적 통제가 필수적입니다.
정리하며
AI 시대의 바이브 코딩은 개발자의 영역을 Complex 단계까지 극적으로 확장해 주었습니다.
그러나 프레임워크와 결합도에 대한 주체적인 설계 없이 AI에만 의존하면, 우리의 코드는 결국 관리 불가능한 Chaotic 영역에 갇히게 됩니다.
우리가 시스템을 아키텍처링하고 결합도를 관리해야 하는 이유는 명확합니다.
AI의 높은 유연성을 활용하되, 발생한 결과물을 제어 가능한 Complicated/Clear 영역으로 귀환시켜 지속 가능한 소프트웨어로 안착시키기 위함입니다.
