사내 블로그에 지난 AX 경험기를 정리하려다가, 먼저 초안을 공유하고 그걸 본 분들이 궁금해하시는 내용 위주로 좀 더 보강하자는 생각에 초안을 먼저 공유합니다.
(아직 다 정리된 건 아니에요!)
AX 전환에 대한 인사이트를 나누는 글들을 보면, 정작 그 인사이트가 어떤 맥락과 환경에서 나온 것인지에 대한 자세한 설명이 부족한 경우가 많다고 느낍니다.
조직마다 규모, 예산, 인프라가 다 다른데 그 전제가 빠지면 좋은 인사이트도 내 상황에 그대로 옮기기 어렵습니다.
작은 조직일수록 AI 네이티브한 일하는 방식을 훨씬 빠르고 과감하게 실험해 볼 수 있다고 생각합니다.
실제로 그런 실험적인 시도를 앞장서서 보여주는 쪽은 인디해커나 소규모 스타트업인 경우가 많습니다.
다만 그 경험을 300명, 500명, 2,000명 규모의 조직에 옮기려면 조직 구조, 의사결정 방식, 인프라의 복잡도가 달라져서 손봐야 할 지점이 꽤 있을 겁니다.
반대로 큰 조직의 경험을 작은 조직에 그대로 옮기면 과한 프로세스가 되기 쉽습니다.
결국 어느 쪽 경험이든 규모가 다른 조직에 그대로 이식하기는 어렵고, 그만큼 서로의 맥락을 참고하는 게 중요하다고 생각합니다.
사업 규모나 형태도 다를 테고, 보안 레벨도 다르고, 사용할 수 있는 AI 플랜과 할당된 AI 예산도 다르기도 합니다.
(전해 들은 어떤 대기업 사례인데, 엔터프라이즈 플랜을 쓸 수밖에 없어서 월 15억을 AI 예산으로 잡았는데 40억 이상이 사용돼 AI 사용 전체를 재점검했다고 하더라고요.)
구축된 시스템 레벨, 연관된 저장소의 수, 크기, 흩어진 조직 맥락의 크기 등도 서로 너무 다릅니다.
그래서 어떤 조직의 여정이 공유될 때는 항상 그 조직의 맥락도 함께 봐야 한다고 생각하기 때문에 저희의 맥락을 먼저 이야기해 드립니다.
누적 가입자 수 165만 명, MAU 54만 명의 교육/채용 플랫폼인 인프런/랠릿 서비스를 운영하는 저희는 56명의 팀원이 함께하고 있습니다.
이 안에서 제품 조직은 26명, 운영/사업은 30명으로 운영되고 있으며, 각 제품 스쿼드는 4-6명으로 구성되어 있고, 요즘은 1-4인 스쿼드를 실험적으로 도입 중입니다.
엔지니어링 헤드, 데브옵스 팀장 등 명시적 리더 없이 CTO와 다이렉트로 일하고 있으며, 데브옵스 조직은 제 직속이고 각 스쿼드의 PM 분들이 매니저로서 일하고 있습니다.
비슷한 조직이시라면 도움이 되실 것 같고, 규모가 다르시다면 참고용으로만 보시면 좋을 것 같습니다.
저희 조직은 AI 도구를 작년 11월부터 본격적으로 사용하기 시작했습니다.
저희 팀의 경험을 돌이켜보면
1. 효율은 증명됐지만, 효과는 아직
AX를 통해 효율을 증명하더라도, 구체적인 일정 규모 이상의 회사의 성과를 달성했는지는 아직 시간이 필요한 것 같음.
"효율이 좋아진 것"과 "효과가 좋아진 것"은 다른 얘기임.
연매출 100억(거래액 말고 순매출) 이상 규모에서 AX로 50%, 100%, 200% 성장했다는 회사는 주변에서 못 봤음.
이 규모에서 지금까지 증명된 건 "예전 성과를 더 적은 사람으로 낼 수 있다"까지고, "더 큰 성과를 낸다"는 사례는 아직 못 봤음.
2. 형식지가 먼저, 자동화는 그다음
"A->B->C로 일하면 100의 성과를 낼 수 있다"처럼 어떤 방식으로 하면 어느 정도 성과가 난다는 형식지가 이미 구축되어 있으면, AI가 빠르게 자동화하고 효율을 높이는 데 도움을 줌.
다만 500의 성과를 한 번도 내 본 적 없는 조직이 AI로 500을 내는 건 아직 어려워 보임.
(테슬라 모델 3 사례가 그랬음.
초기에 완전 자동화를 밀어붙였다가 생산이 막혔고, 머스크도 2018년 4월 "과도한 자동화는 실수였다. 정확히는 내 실수다. 인간은 저평가됐다"고 인정함.
이후 로봇이 좌석을 옮기기만 하고 나사 조립과 배선은 사람이 마무리하는 식으로 공정을 다시 나눴음.
머스크가 나중에 정리한 원칙인 "요구사항에 의문을 제기하고, 불필요한 단계를 지우고, 단순화하고, 속도를 높인 다음 마지막에 자동화하라" 도 결국 검증 안 된 프로세스부터 자동화하면 실패한다는 같은 얘기임.)
3. 동기부여가 관리 대상
AI로 성과를 더 내기 위해서 관리해야 할 대상은 동기부여임.
의지 없는 팀원에게 AX 하라고 하면 딱 시키는 대로만 AI를 씀.
회사가 정해 놓은 규칙대로만 쓰고, 결과는 책임지지 않음.
리더가 시키는 대로는 다 했으니까.
근데 이러면 AI는 최악의 도구가 됨.
AI는 비결정적 도구라서 세 번, 다섯 번 한다고 원하는 결과가 나온다는 게 보장 안 됨.
즉 능동적인 사람에게는 유효하지만 수동적인 사람에게는 전혀 도움이 안 됨.
회사가 빡빡한 가이드라인을 만들면 결국 구성원들은 그 가이드대로 시키는 대로만 하는데, 원하는 결과가 안 나올 때 더 주도적으로 방법을 바꿔가며 노력해야 하는 게 거의 불가능해짐.
결국 요즘 시대에 리더에게 가장 요구되는 것은 팀원들의 동기부여임.
4. 같은 AI를 쓰는 기업간의 경쟁
돈만 내면 누구나 최고급 모델(Fable 5, GPT 5.6 xhigh 등)을 쓸 수 있다면, 조직 간 경쟁력과 해자는 뭐가 될까 고민하게 됨.
잊으면 안 되는 건, 이게 인간 vs AI 경쟁이 아니라 "같은 AI 도구를 쓰는 조직 대 조직" 의 경쟁이라는 점임.
경쟁사도 나랑 똑같은 도구를 쓰는데, 그럼 우리는 뭘로 격차를 벌리고 경쟁력을 키우느냐가 남는 질문임.
같은 도구를 쓴다고 같은 결과물이 나오지 않는다는 건 다들 이미 알고 있음.
결국 예전과 비슷하게, 그 도구를 쓰는 조직 구성원의 역량, 그리고 그 역량을 채용하고 키워내는 조직의 미션, 비전, 문화, 프로세스가 경쟁력이 됨.
5. 더 낮은 모델을 가지고 경쟁해야한다면
그런데 최근 보면 "돈만 내면 누구나"라는 전제 자체가 흔들리고 있긴 함.
Fable 5 같은 최고급 모델이 정액제에서는 못 쓰고 종량제에서만 쓸 수 있게 바뀌는 중임.
지금까지는 작은 회사가 팀플랜이나 개인 정액제로 거의 무한에 가까운 토큰을 아주 저렴하게 쓰고, 큰 회사는 엔터프라이즈 플랜을 쓸 수밖에 없어서 인당 200-300만 원씩 지원하면서도 개인당 토큰량은 Max 5x에도 못 미치는 경우가 있어서, 오히려 이 영역이 작은 회사가 가지는 경쟁력이였음.
근데 최고급 모델이 정액제에서 빠지면 얘기가 달라짐.
종량제 비용을 감당할 수 있는 회사와 감당하지 못하는 회사로 나뉘게 됨.
즉, 고급 모델을 쓰는 회사 vs 중-저급 모델을 쓰는 회사의 경쟁 구도도 가능함.
이 격차는 더 벌어질 것 같음.
(팀플랜도 결국 종량제로 바뀔까 걱정임.)
즉 구성원 역량 격차에 더해 모델 접근성 격차까지 새로운 경쟁 축으로 얹히는 셈임.
우리가 갖고 있는 많은 전제에서 "모델이 계속 발전하는 것" 을 우리 모두가 "충분히 사용" 할 수 있다는 전제위에서 AI 네이티브 논의가 많은데,
우리 회사가 그 좋은 모델을 쓸 수 있는 여력이 있는가,
쓸 수 있다고 해도 얼마나 많이 사용할 수 있느냐,
이에 따라 회사의 운영 방식이 크게 달라짐.
우리가 사용중인 월 $125의 프리미엄 시트, 월 $200의 Max 20x에서는 Fable과 같은 고급 모델을 사용하지 못하고, 대기업 혹은 그에 준하는 큰 투자를 받은 회사들에서는 그걸 적극적으로 쓴다면 무엇으로 경쟁할 것인가? 라는 질문이 남음.
타사보다 낮은 모델을 사용하면서도 타사와 경쟁한다면, 우리는 무엇을 해야 할까? 같은 고민을 시작하게 됨.
최근 로이터가 소식통을 인용해 보도한 바에 따르면, 중국도 Qwen, Doubao, GLM 5.2 같은 자국 플래그십 모델의 해외 접근 제한을 검토 중이라고 함. 아직 논의 단계일 뿐 결정된 건 없고, 시행 여부와 시점, 이미 해외에 풀린 기존 모델까지 소급 적용될지도 전부 불투명한 상태임. 낯설지 않은 패턴인 게, 작년 미국도 앤트로픽의 최상위 모델 Fable과 Mythos에 대해 외국인 접근을 차단하라고 명령했고, 그 여파로 앤트로픽이 전 세계 모든 사용자를 대상으로 두 모델을 일시 비활성화한 적이 있음(이후 Fable은 안전장치를 보강해 전체 사용자에게 복원됐지만, Mythos는 여전히 미국 내 일부 신뢰 기관으로만 제한돼 있음). 결국 모델 접근성 격차는 이제 가격 문제만이 아니라, 그 모델이 어느 나라 소속이냐는 지정학적 요인으로도 벌어질 수 있다는 얘기임.
[지적 자산]
6. 쌓아온 데이터 == 퍼포먼스
그동안 팀이 어떤 데이터를 쌓아 왔느냐에 따라 퍼포먼스 차이가 많이 남.
팀 컨벤션 문서가 이미 관리되고 있는지, 테스트 코드를 이미 작성하고 있는지, Jira나 컨플루언스 등에 의사결정 과정을 계속 기록해두고 있는지 등, 팀의 암묵지와 형식지가 얼마나 쌓여 있느냐에 따라 결과가 다름.
7. 모든 사내 회의 녹음부터
회사의 암묵지가 뭔지조차 모르겠다면, 모든 사내 회의를 녹음하는 것부터 시작하면 좋음.
문서로 정리된 것들에는 결과와 후속 액션 정도만 남고, 회사의 진짜 암묵지, 지적 자산은 "의사결정 과정" 그 자체임.
구글의 아키텍처 결정 레코드처럼 의사결정 과정 자체를 기록으로 남기는 프레임워크가 있어야 함(여기서 프레임워크는 특정 기술을 의미하는 게 아님).
그때 왜 그런 의사결정을 내렸는지 맥락이 남지 않으면, 조금만 응용된 상황이 와도 성공 경험을 전혀 활용하지 못하고 전혀 다른 의사결정이 나오게 됨.
그러면 AI도 완전히 다른 맥락을 갖게 됨.
8. AX는 전담인력을 팀 안으로
녹음 말고 암묵지를 형식지로 만드는 또 다른 방법은, 전담 인력을 그 팀 안에 제대로 밀어 넣고 한 팀으로 일하게 하는 것임.
그 인력이 옆에서 팀원들이 일하는 걸 보면서, AI가 참고할 수 있는 형식지를 계속 뽑아내게 하는 방식임.
[도구]
9. KB(Knowledge Base), MCP, FDE
전사 업무 생산성을 크게 높여준 건 KB(Knowledge Base), 각종 MCP(아틀라시안, 구글 캘린더, 지메일, 빅쿼리, 믹스패널, 데이터독, 깃허브), FDE의 침투(백엔드 엔지니어 한 명이 마케팅 팀 소속의 AX 엔지니어로 옮겨서 일하는 것)였음.
10. 전사 AI 도구는 하나로 통일
AI 도구는 파편화하지 않고 단일 도구로 통일하는 게 좋음. Claude, OpenAI, Gemini 등을 다 같이 쓰게 하기보다는, 전사 AI 도구는 이걸로 간다고 하나를 확정하고 그 안에서 개개인의 노하우를 공유하면 다 같이 효과를 보는 형태로 가야 함.
도구가 파편화되면 노하우도 분산됨.
예전에는 각자 자기한테 가장 잘 맞는 도구를 쓰게 뒀는데, 노하우를 한곳에 모으는 것보다 개개인에게 맞는 도구를 쓰는 게 전체 합이 더 컸기 때문임.
그런데 AI는 가능성과 확장성이 거의 무한대라 한계효용의 법칙이 잘 안 통함.
그래서 수십에서 수백 명이 하나의 도구를 쓰면서 플러그인, 스킬, MCP, 프롬프트 가이드 같은 노하우를 거기에 집중시키는 게, 개개인 입맛에 맞는 도구를 따로 쓰게 하는 것보다 훨씬 나은 조직 성과를 냄.
11. LLM 성능보다 문서 도구의 검색 품질
MCP를 연결해도 문서 탐색은 결국 문서 도구의 검색 결과에 의존함.
LLM이 전사 데이터를 다 들고 있는 게 아니라, 우리가 자연어로 질의하면 그걸 문서 도구의 검색 스펙에 맞는 조건으로 바꿔서 대신 호출하는 구조임.
그러니 아무리 데이터를 연결해도, 내가 찾는 그 데이터를 실제로 가져오는 건 LLM 성능보다 문서 도구의 검색 품질이 더 중요함.
그래서 검색 품질이 좋은 도구를 써야 하고, 잘 지원되는 문서 도구에 사내 문서와 데이터를 모아둬야 함(아틀라시안 제품 등).
[인프라]
12. 버전 관리부터
AI 환경에서 가장 안전한 방법은 데이터와 환경을 버전 관리가 되도록 관리하는 것임.
즉 Git을 도입해야 함. 회의록, PRD도 버전관리가 되는 환경에서 작성돼야 함.
AI는 비결정적 도구라 여러 번 작업한다고 항상 더 나은 결과가 나온다는 보장이 없고, 잘못 실행돼서 결과물이 날아가는 경우도 많기 때문임.
git 도입이 어렵다면 최소한 전사 문서 도구만큼은 항상 버전 관리가 되는 걸 써야 함.
13. IaC & GitOps
IaC & GitOps를 꼭 구축하기를 권장함.
GitOps 환경이 되면 개발팀이 인프라팀에 Jira 티켓으로 요청하는 대신 PR로 직접 인프라를 바꾸고 인프라팀은 리뷰만 하면 돼서, 요청 하나하나의 세부 맥락을 인프라팀이 다 짊어지는 부담이 크게 줄어듦.
본인이 Pulumi로 인프라를 직접 수정해보고 테스트 코드를 돌려서 깨지는 게 있는지 확인하고, 인프라 수정이 올라올 때 AI가 리뷰해서 코멘트를 남기는 도구까지 갖춰지고 나면 이런 환경이 주는 심리적 안정감과 속도감은 차이가 큼.
(물론 이건 리소스 설정값 수준의 검증이고, 실제 클라우드 동작까지 확인하려면 별도 통합 테스트가 필요함.)
롤백도 쉬움.
비슷하게 데이터베이스 테이블 관리도 flyway 같은 마이그레이션 도구의 필요성이 예전부터 강조돼 왔지만, 이젠 그게 더 커짐.
버전 관리가 가능한 데이터여야 AI가 의도와 맥락을 이해하고, 혹시 AI가 실수해도 되돌아가서 수정할 수 있음.
[보안]
14. AISecOps
DevSecOps가 대두되듯이 AISecOps도 필요하다고 느낌. DevOps 시대가 오면서 개발과 운영을 함께 보는 문화가 됐는데, 그 안에서 보안팀이 결국 병목이 되는 문제가 있음.
"덮어놓고 안 된다고만 하면 오히려 음지에서 AI를 쓰게 되고, 이게 더 큰 문제를 만듦".
팀의 생산성과 변화는 충분히 주면서 보안도 챙기려면, 보안팀이 AI를 더 잘 이해하거나 AI를 쓰는 사람이 보안을 공부하거나 둘 중 하나는 해야 함.
AI와 보안이 따로 있고 책임이 분리되어 있으면 서로 자기 시야로만 프로세스를 세우게 되는데, 이게 문제를 더 키움.
우리 팀은 원래 데브옵스가 보안을 같이 책임지는 구조라 AI도 이 조직을 중심으로 두고, 데브옵스와 AI와 보안을 한 조직에서 관리함. 편하게 쓰고 싶은 마음과, 최소한 지켜야 할 선이 어디까지인지는 항상 같이 고민할 수밖에 없음.
15. 개인 구독 AI 도구 금지
토큰 비용이 아깝다고 AI 도구를 개인 계정으로 쓰게 해서는 안 됨.
클로드는 팀플랜(150명 이하)에서 정액제로 지원하니까 최대한 이 플랜부터 활용해야 함.
보안팀이 관리하지 못하는 형태로 AI를 쓰게 해서는 안 됨.
MCP를 통한 보안 사고가 너무 많아서 사내에서 화이트리스트로 MCP를 관리해야 하고, 특히 사내 데이터 접근을 AI에 열어줄 거면 절대 개인 계정에 열어두는 방식으로 가면 안 됨.
16. AI Proxy 게이트웨이
LLM API는 항상 AI Proxy 게이트웨이를 통과하도록 구축해야 함.
기존 API 모니터링은 요청 수(count) 기반으로 이상 패턴을 감지하고 알림을 보내고 추적했는데, AI API는 요청 수가 같아도 토큰 사용량에 따라 비용이 천문학적으로 차이가 날 수 있어서 count만 보는 기존 방식으로는 이 비용 이상을 못 잡음.
그래서 로깅, 알림, 모니터링을 토큰/비용 기준으로 따로 구축해야 하고, 이걸 하려면 중간에 게이트웨이가 필수적임.
구축된 것과 아닌 것의 차이가 큼.
서비스 개발 단계뿐 아니라 실제 서비스에서 나가는 AI 호출도 어디서, 얼마나, 왜 이렇게 나가는지 트래킹해야 함.
17. 구글 워크스페이스를 Primary 계정으로
구글 워크스페이스 계정이 사내에서 사용하는 서비스들의 Primary 계정이자 권한 단위가 되는 게 맞는 방향인 것 같음.
AI 도구, AWS, 데이터독, 아틀라시안, VPN(Tailscale) 등 대부분은 구글 워크스페이스를 SSO/IdP로 붙일 수 있음.
이후 결국 그 팀원에게 수많은 사내 서비스들의 권한이 어떻게, 어디까지 할당되어 있느냐를 추적/관리하기 위함임.
18. DB 접속은 IAM 임시 자격 증명으로
DB 접속 정보는 정적인 id/pw가 아니라 IAM 기반의 임시 자격 증명으로 관리해야 함.
Secrets Manager 자동 로테이션도 좋지만 그건 오래 사는 비밀번호를 주기적으로 교체하는 것이라, 유출되면 다음 로테이션까지 몇십 일을 살아있고 앱 메모리나 환경변수 어딘가에 항상 정적인 값으로 존재해서 AI 에이전트에게 DB를 열어줄수록 그 값이 그대로 유출 경로가 됨.
반면 RDS나 Cloud SQL의 IAM DB 인증은 접속할 때마다 15분짜리 토큰을 새로 발급받는 방식이라 저장해 둘 비밀 자체가 없고, 사람/서비스/에이전트별로 계정을 쪼개 권한을 좁힌 뒤 사고가 나면 전체 로테이션 없이 그 주체의 IAM 정책만 떼서 몇 초 만에 끊을 수 있음.
다만 지원 엔진이 제한적이고 신규 커넥션이 아주 많은 워크로드엔 부담이라, IAM 인증이 안 되는 DB는 Secrets Manager 자동 로테이션이 차선임.
19. 환경변수는 별도 저장소에서 런타임 주입
모든 환경변수도 버전관리, 수정 이력, 권한 관리가 가능한 별도의 private 저장소에서 관리하고 런타임에 가져오는 구조로 가야 함.
코드 저장소에 그대로 박아두거나 개인 메모, 메신저로 공유하면 누가 언제 무엇을 바꿨는지 추적도 안 되고 권한 회수도 안 됨.
20. 데이터는 권한 관리가 되는 DW로
AI를 통해 누구나 자연어로 쉽게 비즈니스, 퍼널 데이터를 보게 만들고 싶다면 계정 단위로 테이블/컬럼 권한 관리가 가능한 도구에 데이터를 모아야 함.
예를 들어 빅쿼리 같은 전문 DW(데이터 웨어하우스) 도구.
단순히 조회용 RDB를 연결하는 방식도 있지만, 개인정보나 민감 정보를 컬럼/계정 단위로 세밀하게 막으려면 계정마다 개별 GRANT를 반복해야 해서 수백 명 규모로는 관리가 너무 복잡함.
조회용 RDB보다 빅쿼리 같은 전문 DW 도구가 유리함.
구글 계정과 바로 통합되고 정책 하나(정책 태그)로 여러 테이블에 걸쳐 컬럼 단위 접근을 관리할 수 있고, 행 단위 보안도 지원함.
DB 테이블, 마케팅 데이터(믹스패널 등), 프로덕트 릴리즈 데이터(서비스 출시 기록, DORA 메트릭 등)가 빅쿼리에 모여있고 계정 단위로 권한 관리까지 되면, MCP로 연결한 뒤 예전부터 이야기하던 "데이터가 흐르는 조직"을 AI의 도움으로 가능하게 할 수 있을 것 같음.
단, 온디맨드 과금은 쿼리가 스캔하는 데이터 크기만큼 부과되는 구조라 로그성 데이터까지 모두 담으면 비용이 늘 수 있음.
정액형(Editions/슬롯 예약) 과금이나 파티셔닝, 클러스터링으로 스캔량을 줄이는 방법을 함께 고려하는 게 좋음.
21. 해커도 AI를 씀
해커도 AI를 사용하고, AI와 함께하는 해커는 우리가 쓰는 범용 AI보다 더 뛰어나다는 점을 잊으면 안 됨.
데이터독 같은 모니터링 도구를 잘 활용하면, 장애 로그를 AI가 분석해서 문제 해결 코드를 만들고 PR까지 올리는 과정을 자동화할 수 있음.
다만 브라우저나 앱 같은 클라이언트 사이드 에러를 수집하는 SDK를 통해 오히려 공격이 들어오는 경우가 있음.
2026년 6월 공개된 사례가 그런 경우인데, 정확히는 SDK 자체의 결함이 아니라 공개된 에러 수집 키에 조작된 데이터를 주입하고 AI 코딩 에이전트가 MCP를 통해 그걸 신뢰할 수 있는 지시로 착각해서 실행하는 방식임.
(예: 관련 사례)
버그 수정까지 사람 개입 없이 완전 자동화하겠다는 건 둘 중 하나임.
우리 서비스가 해커 입장에서 공격할 만한 가치가 없을 만큼 작거나, 보안팀이 완벽하게 다 막아주고 있거나.
여러 모니터링 도구를 MCP로 연결해서 개발자가 버그를 쉽게 해결하도록 효율화하는 건 좋지만, 사람이 전혀 개입하지 않는 방향으로 완전히 넘어갈 수는 없음.
특히 프론트엔드는 UI 변경이 잦아서 자동화해도 괜찮을 거라 생각하기 쉬운데, 그러다 큰일 날 수 있음.
깃헙 저장소의 시크릿이나 CI 환경 같은 인프라가 백엔드와 프론트엔드로 완전히 격리돼 구현되는 경우가 거의 없어서, 프론트엔드 프로젝트가 오염되면 서비스 전체가 영향을 받을 수 있음.
[마치며]
쓰고 나서 다시 읽어보니 새로운 이야기가 많지 않습니다.
문서화, 테스트 코드, 버전 관리, 권한 관리처럼 예전부터 중요하다고 하던 것들이 대부분입니다.
"피닉스 프로젝트"와 "유니콘 프로젝트"가 그리던 암묵지의 문서화와 병목 없는 보안, 데이터가 흐르는 조직, "코드로 인프라 관리하기"가 말한 버전 관리와 IaC, "Release의 모든 것"이 말한 사람의 개입 지점을 남겨둔 자동화는 전부 AI가 나오기 전부터 있던 이야기입니다.
지난 9개월 동안 저희가 확인한 것도 그 이야기들이 AI 시대에 여전히 유효하고, 몇몇은 더 절실해졌다는 것이었습니다.
그래서 지난 9개월은 AI 도구를 배우는 시간이기도 했지만, 미뤄뒀던 숙제들을 더는 미룰 수 없게 된 시간에 가까웠습니다.
