AI 1년 써본 스타트업, 워크플로우를 다시 짜고 싶어진 4가지 이유

팀 단위로 AI 도구를 쓰기 시작한 지 1년이 넘었어요. 솔직히 좋아진 것도 분명히 있고, 눈에 거슬리는 그림자도 생겼습니다. 이 글은 “도입하고 보니 좋더라”는 회고가 아니에요. 아직 팀에 새 워크플로우를 제안하기 직전인데, 그 전에 제가 머릿속으로 정리한 분석 기록입니다.

저 혼자 일하는 게 아니라 5인팀 스타트업이라는 맥락이에요. 기획 1명·디자이너 1명·개발 2명·영업 1명. 구조가 작으니 한 명이 무너지면 팀 전체가 흔들립니다. 그래서 AI 도구를 어떻게 쓸지가 개인 생산성 문제가 아니라 팀 워크플로우 문제가 돼요. 이건 어디까지나 제 맥락에서의 분석이고, 제 제안입니다.

AI로 좋아진 건 분명히 있어요

코드 구현 속도는 확실히 빨라졌어요. 반복적인 보일러플레이트, 테스트 초안, 간단한 문서 정리 같은 작업이 눈에 띄게 줄었습니다. Claude Code를 직접 써본 이야기는 따로 정리한 적 있는데, 개인 작업 효율 측면에서는 진짜로 좋아요. 이건 인정하고 가야 다음 이야기가 설득력이 생깁니다.

그런데 이런 일도 생기더라고요

좋아진 것이 있으면 그림자도 생기는 법이에요. 팀에서 실제로 관찰한 네 가지 패턴을 꺼내볼게요. 앞 세 개는 직무별 장면, 마지막 하나는 직무 횡단 패턴입니다.

영업 — “이거 AI 돌린 거 아니에요?”

1차 미팅 회의록을 꼼꼼히 보지 않고, AI가 자동으로 정리한 일반화된 텍스트를 그대로 가져다가 2차 미팅을 준비한 적이 있었어요. 문제는 그 텍스트가 “그 고객사만의 맥락”이 빠진 채 범용 요약이 되어 있었다는 점입니다.

“

이거 AI로 돌린 거 아니에요?

고객이 직접 그렇게 물었다는 후일담을 들었어요. “잘못 쓴 사람의 문제”라고 할 수도 있는데, 팀 곳곳에서 비슷한 일이 있었다는 게 포인트예요. 개인 문제가 아니라 구조 문제로 보입니다.

기획 — 개발자 대신 AI에게 묻기 시작했어요

“이 기능이 되나? 얼마나 걸리지?”를 개발자에게 묻기보다 AI에게 먼저 묻는 경우가 생겼어요. 매번 개발자에게 묻기 눈치 보이고, 사실 개발자도 비슷한 질문이 연속으로 들어오면 피로한 게 맞아요. 저도 그럴 때가 있고, 한 명 탓이 아닙니다.

문제는 그 답이에요. AI는 우리 코드베이스도, 우리 도메인도, 현재 기술 부채도 몰라요. 그래서 우리 제품 맥락이 빠진 채 “비슷한 일반적인 기능은 이렇게”라는 일반화된 답을 줍니다. 가끔은 할루시네이션도 섞이고요. 그 답을 그대로 받아들여 결정을 내리면 기능 자체나 제품 방향이 우리 사용자에게 맞지 않는 쪽으로 조금씩 기울어요.

개발 — “다 된 거지?” 한 마디로 결과 떠넘기기

시간에 쫓기다 보면 코드 검수를 줄이고 AI가 짜준 테스트 코드에 기대게 됩니다. 저도 예외가 아니에요. 사실 AI가 짠 코드를 전부 검수하기는 어려워요. 과거에 어떻게 다 손으로 쳤나 싶을 정도로 속도가 달라졌거든요.

더 무서운 건 확인 습관이에요. “AI에 맡기면 다 된 거지?”, “완벽해?” 같은 가벼운 확인 한두 마디로 결과를 다음 사람에게 그대로 던지는 패턴이 생기더라고요. 테스트가 통과하니까 괜찮다고 믿었는데, 정작 그 테스트가 엣지 케이스를 검증하지 않고 있었던 경우입니다. 소규모 팀에서 이런 일이 반복되면 QA 비용이 예상보다 많이 올라가요.

직무 횡단 — AI로 양 늘리고 정리는 떠넘기기

이건 직무를 가리지 않고 보이는 패턴이에요. AI로 텍스트·문서·코드를 너무 쉽게 양산하다 보니, 정리되지 않은 산출물이 그대로 다음 사람에게 넘어갑니다. 분량은 많고 모양은 그럴듯한데, 받는 쪽이 뜯어보면 핵심이 빠져 있거나 정리가 안 된 상태예요.

겉보기엔 “일을 많이 한 것처럼” 보이는데, 실제로는 받는 쪽이 정리 부담을 떠안아요. 팀 전체로 보면 일이 줄어든 게 아니라 자리만 옮겨간 거고요. 이게 쌓이면 신뢰가 빠르게 깎입니다.

---

왜 이런 일이 자꾸 생길까

네 가지 패턴 뒤에 깔린 구조적 원인을 정리해보면 이래요.

AI는 우리 맥락을 모른다

AI가 매번 좋은 품질의 답을 주지는 않아요. 우리 도메인·우리 팀 맥락이 빠진 채 일반화된 답변을 줄 때가 많고, 그걸 검증 없이 쓸 때 문제가 생깁니다. 2025년에 나온 AI 코드 생성 버그 서베이 논문(Gao et al.)에서도 생성 코드의 상당 비율에서 보안 취약점이 보고됐다는 정리가 있어요.

빠른 답을 받으면 검증을 줄이게 돼요

스타트업은 속도가 생명이라 빠른 답을 받으면 검증을 줄이게 돼요. AI가 속도를 줘서 좋은데, 그 속도 때문에 검증 습관이 무너지는 아이러니입니다.

”내가 AI에 대체될까봐”

이게 가장 다루기 어려운 부분이에요. “AI에 대체될까봐” 자기가 할 수 있는 일도 천천히 하거나, 알고 있는 정보를 팀에 공유하지 않는 자기 검열이 생기는 것 같아요. 이건 글 후반에서 다시 얘기할게요.

---

그림자와 제 워크플로우, 한 줄로

---

저라면, 직무별로 이렇게 짜겠어요

이건 제가 팀에 곧 제안하려고 정리한 워크플로우예요. 모든 팀에 권장하는 게 아니고, 5인팀 스타트업인 저희 맥락에서의 제안입니다.

영업 — “AI는 내용만, 사람은 분위기·반응”

흐름은 이렇게 그리고 있어요.

도구가 바뀌는 게 아니라 신경 쓸 포인트가 줄어드는 게 목적이에요. 영업팀은 정리에 시간 안 쓰고, 기획·개발은 일관된 양식으로 받아 보고요.

기획 — “NotebookLM은 참고, 판단은 사람”

NotebookLM은 등록된 소스 안에서 검색해 답변을 만들고 인라인으로 인용을 표시하는 구조라(흔히 RAG로 부르는 방식이죠), 일반 채팅 AI보다 우리 맥락에 맞는 답을 받기가 쉬워요. 공식 문서에서도 “소스에 기반한 답변”이라는 점을 분명히 밝히고 있고요.

핵심은 참고용으로만 쓰는 거예요. AI 일반화 답변이 제품 방향을 기울게 하는 걸 막기 위한 구분입니다.

개발 — “AI는 구현, 사람은 도메인·테스트”

솔직히 저희도 예전엔 테스트 코드를 잘 안 썼어요. “시간 없다”는 핑계로 미루는 분위기가 있었고, 거기에 AI가 들어오니 위에서 말한 “다 된 거지?” 식의 가벼운 확인 습관이 더 굳어지는 느낌이었어요. 그래서 저라면 방향을 뒤집고 싶어요.

예전엔 속도 때문에 TDD가 과하다고 봤는데, 이제는 구현 속도가 AI로 해결되니 TDD가 오히려 효율적으로 보여요. 개발자는 모든 코드를 검수하는 일을 줄이는 대신 도메인 지식과 테스팅에 집중하는 분업이에요.

단, 이건 저희 도메인이 그렇게 복잡하지 않기 때문에 가능한 선택이에요. 도메인 복잡도가 높은 팀에는 그대로 적용하기 어려울 수 있습니다.

---

워크플로우로도 못 푸는 것 — AI 대체 불안

위의 3축은 일하는 방식 워크플로우예요. 그런데 솔직히 가장 다루기 어려운 문제가 하나 있어요. AI 대체 불안에서 오는 정보 감춤과 자체 속도 조절입니다.

이건 워크플로우만으로는 풀리지 않을 것 같아요. 팀원이 알고 있는 것을 공유하지 않거나, 할 수 있는 일을 의도적으로 늦추는 패턴은 회사 시스템과 팀 문화가 같이 움직여야 풀린다고 생각해요.

솔직히 저도 답을 모르겠어요. 지금 제 답은 노력해서 나만의 무기를 만드는 것뿐이에요. AI가 대체할 수 없는 도메인 지식, 판단력, 팀과의 신뢰를 쌓아두는 것이 지금 제가 할 수 있는 전부라고 생각해요.

이래서 AI 발전 속도만큼 팀 문화와 회사 시스템 성숙도 같이 가야 하지 않을까 싶어요. 도구만 바뀌면 괜찮은 게 아니라, 그 도구를 쓰는 사람들 사이의 관계와 구조가 같이 바뀌어야 하지 않을까 생각합니다.

---

이 글의 한계

레스덕의 정리

이 글은 “적용 직전의 생각정리”라기보다, 끊임없이 효율성과 발전을 고민하면서 공부하고 물어보고 정리하는 과정의 한 컷이에요. 5인팀에서 AI 도구가 1년 넘게 쌓이며 만든 그림자 4가지를 분해하고, 그 위에 직무별 워크플로우 3축을 얹어봤습니다. 곧 팀에 제안할 예정이고, 제안한 뒤 실제로 어떻게 흘러가는지는 회고 글로 잇겠습니다. 그 사이에 지금 생각이 바뀌어 있을 수도 있어요. 그게 자연스럽다고 보고, 저는 계속 고민하고 물어보고 정리하면서 가려고 합니다.