- 흔히 오해되는 “AI-native”:
- 직원들이 ChatGPT에 사내 데이터를 물어보는 것
- Cursor 같은 툴로 코딩 생산성 향상
- AI SaaS 툴을 도입하는 것
- Borislav(CTO)의 정의:
- 회사 전체가 AI를 기반으로 조직·업무 프로세스를 재구성하는 것
- 개발자/비개발자의 경계가 무너지고, 모든 사람이 스스로 문제를 해결하는 조직으로 탈바꿈
“Ah-ha Moment”
- GPT-3.5 출시 직후, 운영팀의 백로그가 폭발적으로 쌓임
- “모든 직원이 SQL을 쓸 수 있다면, 왜 직접 문제를 해결하지 못할까?”라는 질문
- No-code/low-code 툴은 표현력이 부족했지만 LLM은 충분히 표현 가능
- 직원이 스스로 fraud detection rule을 만들고, API+Zapier/Make.com과 연결해 자동화 가능
CTO 역할의 변화
- 과거: 엔지니어링 팀이 요청을 받아 직접 해결
- 이후: CTO는 내부 PaaS(Platform as a Service) 제공자
- 회사 전체가 “신뢰할 수 없는 개발자”들로 구성되어 있고, 안전하게 쓸 수 있도록 primitive(기초 기능) 제공
- 예: SQL→API 변환, 트리거→웹훅, 모니터링, 알림, 보안/PII 관리
- 직원이 뭔가를 못 한다면 CTO 책임 → 제대로 된 primitive를 주지 않은 것
조직 문화 전환
- “비개발자는 코드를 못 짠다”는 심리적 장벽 깨기
- 전사적으로 LLM 이해 교육:
- Karpathy “Zero to Hero” 시리즈, Fei-Fei Li, 3Blue1Brown 등
- Learning Fridays: 강의 시청 & 토론
- 요청을 대신 해주는 대신, 직원이 직접 해결하도록 유도
- 초기에는 어렵지만, 신뢰 + 인프라 + 교육 3단계로 문화 전환 성공
- 현재: 개발자 + 반(半)개발자 + 소수의 진짜 비개발자 (~10%)
AI-Free 코딩의 필요성
- Borislav은 주 2일 AI 없이 순수 코딩:
- 이유: “LLM이 만들어내는 코드에 대한 감각을 잃지 않기 위해”
- AI 코드를 무비판적으로 받아들이면 복잡성(accidental complexity)이 쌓임
- Vanity Metric(“AI가 몇 % 코드 작성”)은 위험 지표
Theory of Mind와 LLM 코드 리뷰
- 인간 코드: 의도/맥락을 추론 가능 (“왜 이렇게 짰을까?”)
- LLM 코드: 단순 벡터 정렬 → 의도 없음 → 리뷰/리팩터링 시 disconnect 발생
- 해법: LLM 코드를 내 코드처럼 보고 책임과 소유감을 가져야 함
미래 전망
- 코드량이 기하급수적으로 증가 → 인간이 이해할 수 없는 블랙박스 위험
- AI가 아키텍처·컴파일러까지 설계할 경우 인간은 “호환성 레이어”조차 이해 불가
- 따라서 복잡성을 통제(conserve complexity) 하는 능력이 중요
- 프롬프트 설계 시에도 “토큰 압력” 이해 필요: binary 출력 대신 score, 단계별 reasoning 유도
https://www.sarahtavel.com/p/the-benefits-of-writing-code-two