배포는 됐다. 그런데 팀원은 괜찮은가?
Ollama와 FastAPI를 조합하면 로컬 LLM 기반 AI 에이전트를 한 시간 안에 프로덕션 엔드포인트로 올릴 수 있다. phi3 모델을 풀하고, Python 래퍼 하나 씌우고, Kubernetes HPA로 스케일 아웃까지 붙이면 그럴듯한 AI 서비스가 완성된다. 기술적으로는 맞는 말이다. 그런데 나는 요즘 이 지점에서 질문 하나를 먼저 꺼낸다. 이 에이전트를 매일 쓰는 팀원들은 6개월 후에도 지금만큼 스스로 생각할 수 있을까?
'인지 부채'라는 불편한 청구서
MIT 연구진이 제시한 인지 부채(cognitive debt) 개념은 AI-First 팀을 설계하는 사람이라면 반드시 읽어야 할 경고다. 연구에 따르면 ChatGPT로 에세이를 작성한 참가자들은 뇌 연결성이 낮게 나타났고, AI 없이 다시 같은 작업을 수행했을 때 성과가 유의미하게 떨어졌다. 의료진 실험에서도 AI 보조 시스템을 제거하자 종양 탐지율이 감소했다. 단기 효율을 빌려 쓴 대가가 장기 역량 손실로 청구되는 구조다.
재정적 부채와 닮았다는 비유가 정확하다. 문제는 이 부채가 조용히 쌓인다는 점이다. 팀원이 AI 덕분에 PR을 더 빠르게 올리는 동안, 리뷰어가 눈치채지 못한 채 근육이 빠진다.
속도 향상과 이해도 저하는 동시에 일어난다
교육 연구에서도 패턴은 반복된다. AI의 도움을 받은 학습자는 문제 해결 속도와 정확도가 올라갔지만, 이후 독립 평가에서는 성과가 떨어졌다. '정답을 얻는 능력'은 향상되고 '이해하는 능력'은 약화되는 분리 현상이다. AI가 요약해 준 정보로 학습한 그룹은 스스로 조사한 그룹보다 피상적인 이해를 보였고, 타인에게 실용적인 조언을 제공하는 능력도 낮았다.
이걸 개발팀에 대입하면 어떻게 되는가. Cursor나 Claude Code가 생성한 코드를 반복적으로 머지하는 팀원은 코드를 빠르게 '통과'시킬 수는 있지만, 6개월 뒤 그 코드베이스를 AI 없이 디버깅해야 하는 상황에서 어떤 역량을 꺼낼 수 있을까.
문제는 AI가 아니라 '어떻게 쓰느냐'다
다행히 연구는 일방적인 비관론으로 끝나지 않는다. AI를 대체자가 아닌 협력자로 쓴 참가자들은 정반대 결과를 보였다. 먼저 스스로 사고한 뒤 AI를 활용한 그룹은 더 창의적이고 논리적인 결과물을 만들었으며, 자신의 관점도 유지했다. AI를 정답 제공자가 아니라 힌트 제공자로 사용한 학습자는 도구 없이도 높은 성과를 유지했다.
이 차이는 워크플로우 설계의 문제다. 그리고 그 설계는 팀원 개인이 아니라 테크 리드가 해야 할 일이다.
AI-First 팀 설계에서 놓치기 쉬운 레이어
Ollama+FastAPI 스택을 프로덕션에 올리는 가이드는 이미 넘쳐난다. 모델 샤딩, 리버스 프록시, HPA 설정, 지수 백오프 재시도—기술 레이어는 잘 정리돼 있다. 그런데 나는 그 위에 반드시 올라가야 하는 레이어가 하나 더 있다고 본다. 팀원의 인지 역량 설계다.
구체적으로 말하면 이렇다:
- AI 사용 전 사고 강제 구간 설계: 코드 리뷰 요청 전 팀원이 먼저 문제를 직접 분석하는 단계를 워크플로우에 박아넣는다. AI를 첫 번째 도구가 아니라 두 번째 도구로 쓰는 순서를 팀 컨벤션으로 만든다.
- AI 생성 코드의 설명 의무화: 팀원이 AI가 만든 코드를 PR에 올릴 때 '이 코드가 왜 이렇게 동작하는지'를 자신의 언어로 설명하도록 리뷰 프로세스에 명시한다. 설명 못 하면 머지 없다.
- AI 없는 구간을 의도적으로 만든다: 특정 레거시 디버깅이나 설계 세션은 AI 도구 없이 진행하는 것을 팀 루틴으로 넣는다. 근육은 쓰지 않으면 빠진다.
- 도구 의존도 모니터링: 팀원별 AI 도구 사용 패턴을 추적하고, 특정 영역에서 AI 없이 작업하는 빈도가 지나치게 낮아지면 조기에 인터벤션한다.
테크 리드가 실제로 해야 할 설계 결정
Ollama 에이전트를 프로덕션에 올릴 때 LLM 출력이 비결정론적이기 때문에 프롬프트 계약 테스트와 통합 테스트를 이중으로 구성하는 것이 권장된다. 이 원칙을 팀 역량 설계에도 그대로 적용할 수 있다.
팀원의 역량도 비결정론적으로 퇴화한다. 어느 날 갑자기 드러나는 게 아니라, 측정하지 않는 동안 조용히 빠진다. 따라서 역량 테스트를 팀 워크플로우에 구조적으로 넣어야 한다. 분기에 한 번이라도 AI 없이 아키텍처 설계를 해보는 세션, 핵심 도메인 로직을 팀원이 직접 설명하는 리뷰 미팅, 신규 입사자 온보딩 초기 2주는 AI 코딩 어시스턴트 없이 코드베이스를 탐색하게 하는 규칙—이런 장치들이 인지 부채를 통제하는 회로 차단기다.
낙관적이되, 냉정하게
AI 도구의 생산성 향상 효과는 실재한다. Ollama로 로컬 LLM 에이전트를 돌리고, FastAPI로 REST 엔드포인트를 붙이고, 자동화 테스트로 품질을 잡는 워크플로우는 팀 속도를 실질적으로 높인다. 나는 이걸 부정하지 않는다.
다만 MIT 연구가 드러낸 것처럼, 핵심 인지 능력은 '사용하는 빈도와 방식'에 따라 달라진다. AI가 사고를 대신하는 팀은 빠르게 달리다가 어느 순간 혼자 설 수 없게 된다. AI가 사고를 확장하는 파트너가 되는 팀은 도구를 빼도 여전히 작동한다.
그 차이를 만드는 것은 모델 선택도, 배포 아키텍처도 아니다. 테크 리드가 팀 워크플로우에 어떤 인지 설계를 심어두었느냐다. AI를 도입하기 전에 이 질문에 먼저 답해야 한다.