AI로 더 빨리 만들수록, 더 깊게 이해해야 한다

AI와 개발에 대해 이야기하는 구름 커밋 세션을 들었다. 요즘 워낙 "AI로 개발자가 대체된다", "바이브 코딩이면 혼자 서비스도 만든다" 같은 말이 많아서 조금은 뻔한 이야기일 줄 알았는데, 실제 현장에서 부딪힌 사례들이 꽤 구체적이었다.

듣고 나서 제일 크게 남은 건 하나였다. AI가 코드를 잘 짜는 시대가 됐지만, 그 코드를 이해하지 못한 책임은 결국 사람에게 돌아온다.

---

AI가 만든 코드는 빠르게 부채가 된다

가장 인상 깊었던 사례는 STT 모델 이야기였다. 비개발자가 "음악을 텍스트로 바꿔줘"라고 요구했는데, AI가 서버에 무거운 STT 모델을 직접 올리는 방식으로 구현해버렸다고 한다. 요구사항만 보면 틀린 건 아닌데, 운영 관점에서는 서버 성능을 크게 갉아먹는 선택이었다.

 

문제는 이런 일이 한 번으로 끝나지 않는다는 점이다. 코드베이스는 점점 복잡해지고, 사람은 바쁘고, 리뷰는 느슨해진다. 그러다 보면 어느 순간 "왜 서비스가 느려졌지?", "왜 이 구조가 들어왔지?"를 뒤늦게 추적하게 된다.

 

AI가 잘못했다기보다는, 사람이 개입해야 할 지점을 놓친 결과에 가까워 보였다. 특히 인프라, 보안, 결제, 성능처럼 한번 잘못 들어가면 나중에 비용이 커지는 영역은 AI에게 맡기더라도 사람이 게이트를 잡고 있어야 한다.

 

나도 이 부분이 제일 크게 남았다. AI를 쓰면서 가장 무서운 건 단순히 버그가 생기는 게 아니라, 내가 이해하지 못한 결정들이 코드베이스 안에 조용히 쌓이는 일인 것 같다. 겉으로는 기능이 돌아가니까 넘어가지만, 나중에 다시 보면 왜 이렇게 설계됐는지 설명하기 어려운 부분들이 생긴다. 이게 결국 인지 부채라는 말로 가장 잘 설명되는 문제였다.

---

바이브 코딩은 MVP까지는 빠르다

뉴스 브리핑 서비스를 바이브 코딩으로 시작했다는 이야기도 나왔다. 원하는 사이트를 구독하면 매일 아침 데이터를 가져와 요약 리포트를 보내주는 서비스였고, 실제로 수익화도 되고 있었다.

 

초기에는 AI로 빠르게 만들 수 있다. 문제는 사용자가 늘어난 다음이다. 크롤링하고, 요약하고, 정해진 시간에 메일을 보내야 하는 플로우는 사용자가 천 명 단위로 넘어가면 전혀 다른 문제가 된다. 7시에 메일이 가야 하는데 절반 정도가 못 받는다면, 그건 단순한 버그가 아니라 유료 고객에게 직접 영향을 주는 장애다.

 

이 지점이 AI 개발의 현실적인 경계처럼 느껴졌다. MVP 검증 단계에서는 문제를 가장 잘 아는 사람이 AI로 빠르게 만드는 게 훨씬 효율적일 수 있다. 하지만 운영 수준으로 올라가는 순간부터는 구조, 성능, 장애 대응, 책임 소재가 중요해진다. 그때는 결국 소프트웨어를 책임지는 사람이 필요하다.

---

모든 코드를 이해해야 할까

세션에서 나온 질문 중 가장 핵심은 이거였다. AI가 만든 코드를 사람이 전부 이해해야 할까, 아니면 스펙과 테스트로 충분할까.

답은 생각보다 단순했다. 영역마다 다르다.

 

개인정보, 결제, 권한, 보안, 프로덕션 장애처럼 문제가 터졌을 때 영향 범위가 큰 영역은 사람이 깊게 봐야 한다. 반대로 내부 대시보드나 위험도가 낮은 자동화 작업은 스펙과 테스트 중심으로 위임할 수 있다.

 

결국 기준은 "장애가 났을 때 어디까지 번지는가"였다. 영향 범위가 크면 사람의 이해가 필요하고, 영향 범위가 작으면 높은 수준의 스펙과 테스트로도 충분히 갈 수 있다.

 

이 관점이 꽤 현실적이었다. AI를 무조건 믿자는 것도 아니고, 모든 코드를 사람이 붙잡고 있어야 한다는 이야기도 아니다. 중요한 건 어디에서 사람이 핸들을 잡아야 하는지 판단하는 능력이다.

---

이제 스펙은 코드처럼 관리해야 한다

AI에게 일을 시킬 때 남는 것은 결국 의도다. 그 의도는 PRD가 되기도 하고, 스펙이 되기도 하고, 테스트가 되기도 한다.

코드 생성량이 많아질수록 스펙의 중요도는 더 올라간다. AI가 수백 줄, 수천 줄 코드를 만들어놓은 뒤 문제가 생기면 사람이 전체를 즉시 이해하기 어렵다. 그래서 처음에 무엇을 만들려고 했는지, 어떤 조건을 만족해야 하는지, 무엇은 절대 깨지면 안 되는지를 남겨둬야 한다.

 

특히 인상 깊었던 건 스펙도 버전 관리해야 한다는 말이었다. 코드가 바뀌듯 의도도 바뀐다. 그런데 의도는 기록하지 않으면 사라진다. 나중에 "왜 이렇게 만들었지?"가 되는 순간부터 유지보수 비용이 올라간다.

 

나도 스펙과 PRD의 중요성은 꽤 체감하고 있었다. superpowers, speckit, gstack 같은 도구를 쓰면서 작업 전에 요구사항을 정리하고, 에이전트가 바로 구현으로 달려가지 않게 막는 방식은 어느 정도 익숙해졌다. 그런데 요즘은 그다음 단계로 ADR의 필요성을 느낀다. 무엇을 만들지뿐 아니라, 왜 이 선택을 했고 어떤 대안을 버렸는지까지 남겨야 나중에 컨텍스트를 잃지 않는다.

AI 시대의 문서는 보여주기용 산출물이 아니라, 다음 작업을 위한 실행 컨텍스트에 가까워지는 것 같다.

---

그래도 AI가 확실히 좋은 영역

물론 AI를 경계해야 한다는 말이 AI를 덜 쓰자는 뜻은 아니다. 오히려 잘 맞는 영역에서는 이미 확실히 도움이 된다.

내가 특히 효용을 느끼는 건 초안 작성과 테스트 작성이다. 빈 문서에서 시작할 때보다 AI가 초안을 만들어주면 훨씬 빨리 생각을 정리할 수 있다. 테스트도 마찬가지다. 예전에는 귀찮아서 미루던 케이스들을 AI에게 먼저 뽑게 하면, 내가 놓친 경계 조건을 다시 생각해보게 된다.

 

다만 여기서도 중요한 건 그대로 믿지 않는 것이다. 초안은 초안이고, 테스트도 결국 내가 검증해야 한다. AI가 만들어준 결과물을 내 판단 없이 받아들이는 순간 다시 인지 부채가 쌓인다.

---

주니어에게 문법보다 중요한 것

주니어 개발자 이야기도 꽤 많이 나왔다. 예전에는 직접 부딪히고 디버깅하면서 성장했다. 그런데 이제는 그 시행착오를 AI가 대신 겪는다. 생산성은 올라가지만, 사람이 배울 기회는 줄어들 수 있다.

 

그래서 더 의식적으로 봐야 한다. AI가 어디서 막혔는지, 왜 다른 설계를 제안했는지, 어떤 에러를 어떻게 풀었는지를 그냥 넘기면 안 된다. 에이전트의 시행착오를 내 경험으로 흡수해야 한다.

 

문법 자체의 가치는 점점 낮아진다. 대신 정확한 용어를 알고, 왜 이 기술을 선택했는지 설명하고, 언어와 시스템의 장단점을 엔지니어링 관점에서 이해하는 능력이 중요해진다.

 

결국 좋은 개발자는 코드를 많이 외운 사람이 아니라, 문제를 정확히 설명하고 적절한 기술적 판단을 내릴 수 있는 사람에 가까워지는 것 같다.

---

산출물이 많아지는 것도 문제다

AI를 쓰면 코드도 늘고 문서도 늘어난다. 예전에는 개발 비용이 높아서 자연스럽게 가성비를 따졌는데, 이제는 만들기 쉬워지다 보니 굳이 필요 없는 구조까지 만들어지는 경우가 많아진다.

 

겉으로는 아키텍처가 예뻐지고 문서가 체계적으로 보일 수 있다. 그런데 너무 많아지면 결국 아무도 안 본다. 이건 기술 부채라기보다 인지 부채에 가깝다.

 

이 문제에 대한 답도 결국 단순함이었다. 처음 설계할 때부터 최대한 단순하게 만들도록 요구해야 한다. AI에게도 "좋은 구조"만 말할 게 아니라 "필요 이상으로 벌리지 말라"는 기준을 줘야 한다.

 

나도 AI가 오버엔지니어링하는 경우를 자주 봤다. 작은 기능 하나를 부탁했는데 폴더 구조를 새로 만들고, 추상화를 추가하고, 지금 당장 필요 없는 확장성까지 챙기려는 식이다. 처음에는 그럴듯해 보이지만, 내가 컨텍스트를 놓친 상태에서 그런 구조가 들어오면 나중에는 오히려 작업 속도를 떨어뜨린다.

 

그리고 더 중요한 질문은 이거다. 이 일이 정말 팀의 목표와 맞는가. KPI나 OKR, 매출, 운영 비용 절감, 사용자 가치와 연결되는가. AI가 일을 쉽게 만들어줄수록, 오히려 이 질문은 더 자주 해야 한다.

---

조직의 컨텍스트가 AI의 성능이 된다

팀 단위 AI 활용에서 반복해서 나온 말은 기록이었다. 회의록, PRD, ADR, 커밋 로그, 세션 로그가 잘 남아 있으면 AI가 읽을 컨텍스트가 생긴다.

 

정보가 흩어져 있거나 사람 머릿속에만 있으면 AI도 제대로 일하기 어렵다. 반대로 의사결정과 맥락이 구조화되어 있으면, 새로운 작업을 시작할 때 훨씬 빠르게 이어갈 수 있다.

 

실제로 어떤 조직에서는 로컬에 남는 에이전트 세션 로그를 중앙 저장소나 원격 환경으로 동기화해 관리한다고 했다. 물론 그대로 다 올리면 보안 문제가 생기니, 민감한 정보는 마스킹하고 필요한 부분만 모아 분석하는 식이다. 팀원들이 어떤 식으로 AI를 쓰는지 보고, 자주 막히는 지점이나 반복되는 실수를 찾아 스킬과 워크플로우를 개선한다는 이야기도 나왔다.

 

이제 문서화는 단순히 사람끼리 공유하기 위한 일이 아닌 것 같다. 에이전트가 팀의 맥락을 이해하도록 만드는 인프라에 가깝다. 앞으로는 에이전트 옵스, 세션 로그 중앙화, 민감 정보 마스킹, 워크플로우 자동화 같은 것들이 팀 생산성의 중요한 축이 될 것 같다.

---

많이 돌리는 것보다 정확히 맡기는 것

개인적으로 가장 공감한 부분은 에이전트 탭을 많이 띄워놓는 이야기였다. 여러 개를 동시에 돌리면 겉으로는 생산성이 엄청나 보인다. 그런데 결국 사람이 따라가지 못하면 인지 부하만 쌓인다.

 

나도 비슷한 문제를 겪었다. 에이전틱 코딩이 처음 바이럴되기 시작했을 때, 잘 쓰는 사람들을 따라 해보려고 여러 개의 탭을 켜두고 동시에 여러 프로젝트를 돌리거나, 하나의 프로젝트 안에서도 여러 기능을 병렬로 개발하려고 했다. 겉으로는 뭔가 많이 진행되는 것처럼 보였지만, 정작 내가 각 작업의 컨텍스트를 충분히 붙잡고 있지 못했다. 결국 어느 탭에서 무슨 결정을 했는지 다시 따라가느라 시간이 들었고, 작업 능률도 생각보다 떨어졌다.

 

패널 중 한 분은 오히려 탭을 줄이고, 하나의 문제에 더 집중한다고 했다. 처음에 의도를 명확히 하고, 모르는 부분을 AI가 질문하게 만들고, PRD를 잘 만드는 데 시간을 더 쓴다는 이야기였다.

 

이게 지금 AI 개발을 대하는 꽤 좋은 태도처럼 느껴졌다. AI를 많이 쓰는 것보다 무엇을 왜 시키는지 명확히 하는 게 더 중요하다. 처음에 의도를 잘못 주면, AI는 그 잘못된 방향으로도 아주 빠르게 달려간다.

---

이번 세션을 듣고 나서 AI 개발에 대한 생각이 조금 정리됐다. AI는 분명 개발을 빠르게 만든다. 하지만 속도가 올라간 만큼 검증, 스펙, 테스트, 운영 책임의 중요도도 같이 올라간다.

 

앞으로 개발자에게 중요한 건 단순히 코드를 치는 능력이 아닐 수 있다. 문제를 정의하고, 의도를 구조화하고, 위험한 영역을 구분하고, AI가 만든 결과를 운영 가능한 소프트웨어로 책임지는 능력.

 

나는 여기에 꽤 동의한다. 앞으로는 기획, 디자인, 개발, 셀링을 완전히 나눠서 생각하기 어려워질 것 같다. AI가 각 영역의 실행 비용을 낮춰버리면, 결국 살아남는 사람은 자기 영역만 잘하는 사람이 아니라 문제를 정의하고, 만들고, 보여주고, 팔 수 있는 사람에 가까워질 것 같다.

 

그래서 이 세션은 낙관보다 경각심에 가까웠다. AI를 쓰면 더 많은 걸 할 수 있다는 기대도 있지만, 동시에 준비하지 않으면 더 빠르게 뒤처질 수 있다는 불안도 생긴다. 결국 AI 시대에도 본질은 비슷한 것 같다. 더 빨리 만들 수 있게 됐을 뿐, 무엇을 만들지와 왜 그렇게 만들어야 하는지는 여전히 사람이 답해야 한다.