당신의 AI 코딩 설정은 Complicated(복잡한) 도구입니다. 당신의 코드베이스는 Complex(복잡계)입니다.
새로운 AI 코딩 도구들은 에이전트를 더 신뢰할 수 있게 만들겠다고 약속합니다. 스킬, 슈퍼파워, 그리고 명세 기반 개발(spec-driven development)을 위한 프레임워크들이 등장하고 있습니다. 이러한 도구들은 실제로 효과가 있습니다. 에이전트가 추측하는 대신 프로세스를 따르도록 도와줍니다.
하지만 함정이 있습니다. 사람들은 하나의 작업을 위한 더 나은 설정이 일관된 시스템을 만들어낼 것이라고 생각합니다. 그렇지 않습니다.
그 이유를 이해하려면 Cynefin 프레임워크를 활용해 보세요. 이 프레임워크는 문제를 두 가지 유형, 즉 Complicated(복잡한)와 Complex(복잡계)로 구분합니다.
Complicated(복잡한) 문제 이 유형은 알 수 있는 정답이 존재합니다. 분석과 기술을 사용하여 정답을 찾아낼 수 있습니다. 모듈 리팩터링이나 검증 함수 작성 등이 그 예입니다. 일단 정답을 찾으면, 이를 반복할 수 있습니다. 대부분의 AI 코딩 도구는 이 영역에 속합니다. 이들은 작업 단위(unit of work)에 집중하며, 작업을 반복 가능하고 검증 가능하게 만듭니다.
Complex(복잡계) 문제 이 유형은 예측 가능한 정답이 없습니다. 시스템은 여러 부분들이 얽혀 있는 거미줄과 같습니다. 결과는 행동을 취한 후에야 나타납니다. 40개의 병합된 변경 사항이 6개월 뒤에 아키텍처를 망가뜨릴까요? 에이전트 A가 에이전트 B와 모순되는 동작을 할까요? 이러한 답은 파일 하나를 본다고 해서 찾을 수 없습니다. 부분들이 어떻게 상호작용하느냐에 따라 결과가 창발(emerge)하기 때문입니다.
불일치는 Complicated 도구가 Complex 문제를 해결할 수 있을 것이라고 기대할 때 발생합니다.
어떤 도구가 에이전트로 하여금 완벽한 함수를 작성하게 할 수도 있습니다. 하지만 한 작업에서는 userId를 사용하고 다른 작업에서는 user_id를 사용한다면, 시스템은 깨집니다. 각각의 작업은 개별적으로는 "정확"했습니다. 실패는 창발적으로 발생합니다. 즉, 작업 단위가 아니라 상호작용 속에서 발생하는 것입니다.
거대한 컨텍스트 윈도우(context window)조차도 이 문제를 해결할 수는 없습니다. 윈도우가 커지면 더 많은 것을 볼 수는 있지만, 보는 것이 곧 추론하는 것은 아닙니다. 전체 코드베이스를 다 읽더라도 운영 환경의 부하 상황에서 데드락(deadlock)이 발생할지 여부는 알 수 없습니다. 그것은 런타임(runtime) 속성이기 때문입니다.
두 유형을 모두 다루는 방법:
- Complicated 레이어: 스킬, 명세(specs), 그리고 TDD를 사용하세요. 이는 에이전트의 개별 출력을 엄격하게 만듭니다.
- Complex 레이어: '탐색-감지-대응(probe-sense-respond)' 방식을 사용하세요. 무엇이 망가질지 예측할 수 없습니다. 병합하고, 배포하고, 관찰해야 합니다. 통합 테스트와 관측성(observability)을 활용하여 구성 요소들이 결합될 때 어떤 일이 일어나는지 감지하세요.
더 나은 명세가 시스템을 안정적으로 만들어줄 것이라는 약속에 속지 마세요. 명세는 작업 단위를 신뢰할 수 있게 만들 뿐, 시스템을 일관되게 만들지는 않습니다.
도메인에 맞는 방법을 선택하세요. 도구는 작업 단위를 완벽하게 만드는 데 사용하고, 실험은 시스템을 이해하는 데 사용하세요.
Optional learning community: https://t.me/GyaanSetuAi