워크플로우

[JM-220]

📆 일자: 26년 9월 7일(월)

발제 의도

개발 워크플로우는 그동안 사람이 각 단계를 직접 밟아 나가는 방식으로 굳어져 왔습니다. 그런데 AI가 개발 현장에 들어오면서 그 흐름 자체가 빠르게 바뀌고 있습니다. 이번 스터디에서는 기존 워크플로우가 어떤 모습이었는지 정리해보고, AI 발전에 따라 그 방향이 어디로 향하고 있는지 각자의 시선으로 이야기해보려 합니다.

🤔오늘의 질문

1. 기존 개발 씬에서 진행되던 워크플로우 방식은 어떤 모습이었나요?
2. AI 발전에 따라 워크플로우는 어떤 방향으로 변화해 가고 있다고 보시나요?
3. 기존 방식 중 AI로 빠르게 진행할 수 있게 된 부분과, 아직은 사람의 개입이 필요해 보이는 부분은 각각 무엇인가요?

정답이 정해진 주제는 아니니 자유롭게 적어주세요.

[9ga0]

1. 기존 개발 씬에서 진행되던 워크플로우 방식은 어떤 모습이었나요?

제가 알기로는 작년까지만 해도 개발자가 개발 과정의 대부분을 직접 처리해야했습니다. 보통 요구사할을 정리하고, 설계하고, 코드 작성하고, 리뷰와 테스트를 거쳐 배포하는 흐름이었습니다. 개발하다가 모르는 부분이나 오류가 생기면 공식문서나 검색을 통해 해결 방법을 찾아보고 직접 코드에 적용하는 식이었습니다.
물론 Git이나 CI/CD처럼 이미 자동화가 진행된 부분도 있었지만, 결국 어떤 작업을 해야 하는지 판단하고 실제로 진행하는 주체는 사람이었습니다.
따라서 기존 워크플로우를 한마디로 표현하면, 개발자가 다 알아야하고, 직접 작업을 주도해야하고 여러 도구가 그 과정을 보조하는 방식이었다고 생각합니다.

2. AI 발전에 따라 워크플로우는 어떤 방향으로 변화해 가고 있다고 보시나요?

요즘은 개발자가 모든 작업을 직접 하는 방식에서 -> ai에게 일부 작업을 맡기고 개발자는 결과를 확인하는 방식으로 바뀌었습니다. 예전에는 ai라고 해도 코드 자동완성이나 간단한 문제풀이 정도가 중심이었다면, 지금은 코드베이스를 읽고 한번에 여러 파일을 수정하거나 테스트를 실행하고 오류를 고치는 일까지 스스로 할 수 있게 되었습니다.
그래서 앞으로는 개발자가 직접 코드를 많이 작성하기보다 어떤 문제를 해결해야 하는지 명확하게 정의하고 AI가 만든 결과가 정확한지 판단하는 능력이 더 중요해진 것 같습니다.
개발자가 개발에서 빠지는 형태라기보다는, 일부를 AI에게 넘기고 개발자는 설계나 판단, 검증에 더 집중하는 방향에 가깝다고 생각합니다.

3. 기존 방식 중 AI로 빠르게 진행할 수 있게 된 부분과, 아직은 사람의 개입이 필요해 보이는 부분은 각각 무엇인가요?

ai를 활용했을 때 가장 빨라진 부분은 반복적인 작업이나 버그 발견 작업, 다른 사람의 코드 이해 등이라고 생각합니다. 예를 들면 기본적인 코드 작성이나 테스트 코드 생성, 코드 설명, 문서화, 단순한 리팩토링 같은 작업은 AI를 활용하면 시간을 많이 줄일 수 있습니다. 또한 길게 작성된 코드에서 오류가 났을 때 빠르게 발견할 수 있고, 다른 사람의 코드를 이해해야할 때도 도움이 됩니다.
반면에 요구사항을 정하거나 시스템 구조를 설계하는 일처럼 정답이 하나로 정해져있지 않고, 기획자,개발자,사용자 등 여러 이해관계자와의 의사소통을 통해 결정해야 하는 사안은 잘못된 방향으로 개발되는 것을 막기 위해 사람의 판단이 중요합니다. 특히 실제 서비스에서는 단순히 코드가 돌아가는 것만 중요한 게 아니라 보안, 비용, 유지보수성이나 비즈니스 요구사항도 같이 고려해야합니다.

ai는 잘 동작하는 코드를 작성해줄지 몰라도, 책임은 결국 사람이 져야하기 때문에, 신중하게 잘 알고 사용해야합니다. 앞으로의 개발 워크플로우는 ai가 실행을 많이 담당하고, 사람은 방향을 정하고 판단하고 검증하는 형태로 바뀔 것입니다. 즉 ai 때문에 개발자가 필요 없어지는 게 아니라, 개발자가 직접 해야하는 일의 종류가 바뀌고 있다고 생각합니다.

1,2,3 요약)

기존 개발 워크플로우에서는 개발자가 요구사항 정리, 설계, 코드 작성, 리뷰, 테스트, 배포 과정 모두 직접 작업하고 여러 도구가 그 과정을 보조하는 방식이었습니다. AI에이전트가 이 모든 과정에 개입 가능하게 되면서, 개발자는 문제를 명확하게 정의하고 ai가 만든 결과를 검증하는 능력이 중요해졌습니다. 이처럼 개발워크플로우에 ai를 도입되자 반복적인 작업, 버그 발견, 낯선 코드 이해 등 작업이 빨라졌습니다. 그러나 ai만 사용했을 때는 실서비스에서 중요한 보안, 비용, 유지보수성, 비즈니스 요구사항을 모두 고려한 결과를 내지 못한다는 평이 많습니다. 따라서 ai로 인해 개발자가 필요없어지는 게 아니라, 개발자가 직접 해야하는 일의 종류가 바뀌고 있다고 생각합니다.

[paiwhy]

1. 기존 개발 씬에서 진행되던 워크플로우 방식은 어떤 모습이었나요?

→ 기존 개발씬에서는 요구사항 정의 → 설계 → 코드 작성 → 코드 리뷰 → 테스트 → 배포까지 각 단계별로 사람이 순차적으로 직접 수행하는 형태였습니다.
코드 작성은 개발자가 문서와 인터넷 데이터들을 참고해 직접 타이핑했고 반복적인 마이그레이션 작업도 대부분 간단한 스크립트로 처리했습니다. 협업은 git 기반 pr코드리뷰 중심이고 검색은 주로 공식 문서나 스택오버플로우 같은 외부 자료에 의존했습니다.

2. AI 발전에 따라 워크플로우는 어떤 방향으로 변화해 가고 있다고 보시나요?

→ 개발자는 코드를 한 줄씩 작성하는 사람이 하는 역할에서와 또 다르게 AI에게 개발할 의도를 정확히 전달하고 AI가 만든 결과물을 검증과 조율을하는 사람으로 변화되고 있다고 생각합니다.
반복적이고 패턴화된 작업은 AI가 초안을 만들고 사람이 확인하는 구조가 되며 PR 단위가 아니라 자연어 요청 단위로 작업이 되는 경우, 바이브 코더의 영역도 늘고 있습니다.
AI 기반의 코드리뷰나 자동 수정단계가 결합되는 방향으로도 발전하고 있습니다.

3. 기존 방식 중 AI로 빠르게 진행할 수 있게 된 부분과, 아직은 사람의 개입이 필요해 보이는 부분은 각각 무엇인가요?

→ AI로 빨라진 부분으로는 코드를 보며 탐색하거나 이해하고 알려주는 것, 단순 리팩토링, 테스트 코드 초안 작성, 에러 메시지 기반 디버깅, 문서와 주석 작성, 반복적인 마이그레이션 작업을 예로 들어 빠르게 진행할 수 있다고 생각합니다
아직은 사람 개입이 필요한 부분은 비즈니스 요구사항의 우선순위 판단과 조직 내 이해관계자 간 커뮤니케이션 혹은 사람마다 엇갈리는 요구사항의 최종 의사결정, AI가 생성한 코드가 실제 비즈니스 맥락에 맞는지에 대한 최종 판단은 아직 사람의 개입이 필요로 하는 영역이라고 생각합니다

[k9425mino]

1. 기존 개발 씬에서 진행되던 워크플로우 방식은 어떤 모습이었나요?

AI 에이전트 도입 이전 (전통적 워크플로우)

• 요구사항 → 설계 → 구현 → 테스트 대체로 선형적/순차적으로 진행됐다. 스프린트 단위로 기능을 쪼개고, 개발자가 직접 보일러플레이트부터 로직까지 한 줄 한 줄 작성했다.
• 검색 기반 학습: 모르는 API나 에러는 Stack Overflow, 공식 문서, 사내 위키를 뒤져가며 해결. 컨텍스트 스위칭 비용이 컸다.
• 코드 리뷰는 사람이 전담: PR을 올리면 시니어가 로직/스타일/버그를 검토. 리뷰 대기 시간이 병목이 되는 경우가 많았다.
• 반복 작업의 수작업 처리: 마이그레이션, 리팩토링, 테스트 코드 작성 같은 기계적 작업도 개발자가 직접 스크립트를 짜거나 손으로 처리.
• 디버깅은 경험과 로그 분석에 의존: 에러 스택트레이스를 읽고, 브레이크포인트를 걸고, 가설을 세워 하나씩 검증하는 방식.
• 문서화는 후순위: 기능 구현이 끝난 뒤 시간이 남으면 문서를 쓰는 경우가 많아 문서-코드 싱크가 자주 깨졌다.

AI 에이전트 도입 이후

• 명세 → 실행의 위임 구조로 전환: 개발자는 "무엇을(what) 정의하고 에이전트가 "어떻게(how)"의 상당 부분을 처리. 개발자 역할이 타이핑에서 검토·판단으로 이동.
• 병렬 작업 확대: 에이전트에게 작업을 위임하고 다른 작업을 동시에 진행하거나, 여러 에이전트를 서브태스크별로 분산 실행하는 방식이 가능해짐.
• 검색이 대화로 대체: 문서를 뒤지는 대신 에이전트에세 질문 → 즉시 컨텍스트에 맞는 답변. Context7 같은 최신 문서 조회 도구까지 결합되면서 학습 곡선이 완만해짐.
• 리뷰 단계 이중화: AI가 1차 코드 리뷰(버그, 스타일, 보안)를 수행하고 사람은 아키텍처/비즈니스 로직 판단에 집중.
• 테스트/리팩토링/마이그레이션의 자동화 비중 증가: 반복적이고 명세가 명확한 작업은 에이전트가 처리하고, 사람은 검증 기준(성공 조건)을 정의하는 역할로 이동.
• 문서화 비용 감소: 코드 변경과 동시에 문서를 생성/갱신하기 쉬워짐.
• 새로운 리스크 등장: 에이전트의 "그럴듯하지만 틀린" 코드(hallucination), 컨텍스트 부족으로 인한 과도한 변경, 보안 취약점 도입 가능성 등을 검토하는 게 새로운 필수 역량이 됨.

핵심적인 변화를 한 줄로 요약하면, "코드를 직접 작성하는 사람"에서 "무엇을 만들지 정의하고 결과를 검증하는 사람"으로 개발자의 역할이 이동했다는 점이다.

2. AI 발전에 따라 워크플로우는 어떤 방향으로 변화해 가고 있다고 보시나요?

1. 단발성 도구 → 지속적 에이전트로: 한 번의 프롬프트-응답이 아니라, 세션 간에 메모리와 컨텍스트를 유지하며 장기 과제를 이어가는 방향으로 가고 있다. (예: 지금 이 대화도 프로젝트별 메모리를 축적하는 구조) 개발자가 매번 배경 설명을 반복할 필요가 줄어든다.
2. 동기적 대화 → 비동기적 위임으로: "질문하고 기다리는" 방식에서 "작업을 맡기고 다른 일을 하다가 결과를 받는" 방식으로 이동 중이다. 백그라운드 에이전트, 서브에이전트 병렬 실행, 예약 실행(cron) 등이 이를 뒷받침한다. 개발자의 시간 단위가 "명령 하나"에서 "목표 하나"로 커진다.
3. 개별 작업 → 오케스트레이션으로: 단일 에이전트가 코드를 짜는 단계를 넘어, 여러 전문화된 에이전트(탐색, 리뷰, 보안, 디자인 등)를 조합해 하나의 파이프라인처럼 운용하는 방향. 사람은 오케스트레이터/의사결정자 역할로 한 단계 더 위로 이동한다.
4. 검증 방법론이 핵심 역량으로 부상: 코드를 사람이 한 줄씩 안 읽어도 되는 대신, "성공 기준을 어떻게 정의하고 자동 검증할 것인가"(테스트, 타입체크, 명세 기반 검증)가 개발자의 핵심 스킬이 된다. 신뢰는 "읽어봤다"가 아니라 "검증 파이프라인이 통과했다"로 옮겨간다.
5. 텍스트/코드 중심 → 멀티모달·실제 환경 개입으로: 브라우저 자동화, UI 스크린샷 검증, 실제 앱 구동 테스트처럼 에이전트가 코드뿐 아니라 실행 환경 자체와 상호작용하는 방향으로 확장되고 있다.
6. 신뢰의 범위가 점진적으로 확대: 초기엔 사람이 모든 변경을 승인해야 했다면, 점점 "가역적이고 로컬한 작업은 자율 처리, 비가역적/공유 영향 작업만 확인받는" 식으로 자율성의 경계가 세분화되는 추세이다. 완전 자율이 아니라 리스크 기반 위임이다.

워크플로우는 "사람이 도구를 조작"하는 모델에서 "사람이 목표와 기준을 설계하고, 에이전트 시스템이 실행하며, 사람은 리스크 지점에서만 개입""하는 모델로 수렴하고 있다.

3. 기존 방식 중 AI로 빠르게 진행할 수 있게 된 부분과, 아직은 사람의 개입이 필요해 부분은 각각 무엇인가요?

AI로 빠르게 처리 가능해진 부분

• 보일러플레이트/반복 코드 작성: CRUD, API 클라이언트, 폼 검증, 타입 정의 등 패턴이 명확한 코드는 즉시 생성 가능.
• 코드 탐색/이해: "이 함수는 어디서 호출되나", "이 버그는 어디서 발생하나" 같은 대규모 코드베이스 탐색이 수 분에서 수 초로 단축.
• 리팩토링/마이그레이션: 명확한 규칙이 있는 변환(API 버전 업그레이드, 네이밍 통일, 프레임워크 마이그레이션)은 자동화 가능.
• 테스트 코드 생성: 기존 로직에 대한 단위 테스트 초안 작성.
• 문서화: 코드에서 문서를 추출/생성, 최신 상태로 동기화.
• 1차 코드 리뷰: 스타일, 명백한 버그, 보안 취약점 패턴(OWASP 등) 스캔.
• 디버깅 초기 단계: 에러 메시지/스택트레이스 기반 원인 후보 좁히기.
• 여러 언어/프레임워크 간 컨텍스트 전환: 낯선 스택에서도 문서 검색 없이 바로 작업 가능.

아직 사람의 개입이 필요한 부분

• 비즈니스 맥락과 우선순위 판단: "왜 이 기능이 필요한가", "이 트레이드오프를 감수할 가치가 있는가"는 조직/시장 맥락을 아는 사람만 판단 가능.
• 모호한 요구사항의 해석: 명세가 불완전하거나 이해관계작마다 의도가 다를 때 조율.
• 아키텍처 수준의 설계 결정: 장기적 확장성, 팀 구조, 기술 부채 감수 여부 같은 큰 그림 판단.
• 비각역적/고위험 액션의 최종 승인: 프로덕션 배포, DB, 마이그레이션, force push, 결제/보안 관련 변경.
• 미묘한 버그의 근본 원인 규명: 동시성 문제, 특정 환경에서만 재현되는 이슈처럼 가설-검증 반복이 필요한 디버깅.
• AI 결과물의 사실 검증(hallucination 체크): 그럴듯하지만 틀린 코드/설명을 걸러내는 최종 게이트.
• 팀 내 커뮤니케이션과 함의 형성: 리뷰 코멘트에 대한 논쟁 ㅎ새소, 이해관계자 설득.
• 윤리/보안/컴플라이언스 판단: 법적 요구 사항, 사용자 프라이버시처럼 규범적 기준이 걸린 결정.
• 품질에 대한 최종 취향/기준 설정: "이 정도면 충분히 단순한가", "이 UX가 실제로 좋은가"는 사람의 감각이 필요.

"정답이 명확하고 검증 가능한 기계적 작업"은 AI가 빠르게 처리하고, "정답이 맥락에 의존하거나 판단·책임이 따르는 작업"은 여전히 사람이 개입해야 한다.

[dnnals]

기본 질문

1. 기존 개발 씬에서 진행되던 워크플로우 방식은 어떤 모습이었나요?

레거시 SDLC(Software Development Life Cycle)는 주로 요구사항 분석, 설계, 구현, 검증, 배포 순으로 진행되거나 해당 6개의 축에서 어떠한 변형으로 진행됩니다. 이 흐름에서는 가장 큰 병목은 구현 단계였습니다.

2. AI 발전에 따라 워크플로우는 어떤 방향으로 변화해 가고 있다고 보시나요?

레거시 방식에서는 모든 것을 사람이 처리, 관리하기 때문에 구현 단계의 병목도 자연스러웠으며 또한 검증의 코드 리뷰 단계에서 구현 단계의 병목이 오히려 작업을 원활하게 할 수 있도록 했습니다. 하지만 AI가 발전하면서 더 이상 구현은 병목이 아니고 미친듯한 생산성으로 PR이 뿜어져 나오기 시작했습니다. 그런데 AI의 발전으로 레거시 SDLC에서의 최대 병목이었던 구현이 엄청나게 단축되었음에도 다른 단계는 전부 사람의 속도에 맞춰져 있던 방식이기에 구현 시간 단축으로 얻는 이점을 제대로 활용 못하고 있습니다. 특히 검증 단계의 코드 리뷰가 미친듯이 PR이 뿜어져 나오며 병목이 되었고 심지어 코드를 꼼꼼하게 리뷰하지 않는다던지, 코드를 아예 검증하지도 않고 머지하는 문제가 생겨나기도 했습니다. 그래서 AI가 단축시킨 구현 단계를 어떻게 해야 잘 활용할 수 있을지에 대한 방법이 끊임없이 나오고 있습니다.

3. 기존 방식 중 AI로 빠르게 진행할 수 있게 된 부분과, 아직은 사람의 개입이 필요해 보이는 부분은 각각 무엇인가요?

기존 방식에서 AI로 빠르게 진행할 수 있게 된 부분은 당연 구현 단계입니다. AI는 자연어로 잘 짜여진 요구사항을 코드로 1:1로 옮기는데 강점이 있습니다. 그리고 요구사항 분석, 설계 또한 AI와 함께 진행하면 다같이 모여 회의하는 것보다 더 높은 생산성을 가질 수 있게 되었습니다. 그러면서 사람은 취향이 들어간 판단이 필요한 지점에서 판단하고 또한 AI가 위험한 행위를 하지 못하도록 AI를 관리하는 곳으로 집중을 옮겼습니다. 그래서 전체적인 SDLC의 축을 보면 다같이 회의로 요구사항 분석, 설계를 하는것이 아닌 AI와 함께 요구사항 분석, 설계하고 이를 문서화하여 PO (Product Owner)가 리뷰하여 승인하고, 그 문서들로 AI에게 구현을 위임하며 코드 리뷰 또한 잘 정리된 규칙에 맞게 리뷰하도록 AI에게 위임하고 사람은 취향의 영역에서 판단하고, AI가 위험한 행위를 하려고 하는것에 대해서만 개입해 관리합니다.

[eunji719]

1. 기존 개발은 사람이 지식을 검색하고, 직접 타이핑하고, 검증하는 구조였다. 기획자가 요구사항을 정리하면 개발자가 아키텍처와 설계를 잡고, 실무 개발자는 그 설계에 맞춰 코드를 한 줄씩 작성한다. 모르는 부분은 스택오버플로우나 공식문서,블로그를 뒤져가며 답을 짜맞췄고 완성된 코드는 사람의 코드 리뷰를 거쳤다. 테스트 케이스 또한 개발자가 직접 설계하여 작성했고, 버그가 생기면 로그를 찍거나 브레이크 포인트를 걸어 원인을 하나씩 추론했다. 문서화는 실제로는 후순위로 밀리는 경우가 많았고 근본적인 병목은 결국 사람의 타이핑 속도와 개인이 가진 지식의 폭이 결정하였다.

2. 가장 큰 변화는 개발자는 ai가 만든 결과를 검토하고 방향을 잡아주는 사람으로 이동하고 있다. 자연어로 요구사항을 설명하면 곧바로 초안 코드와 설계안이 나오는 흐름이 보편화 되고 있고, ai가 다루는 작업의 단위도 예전의 챗봇 시절을 넘어서 여러 파일을 오가며 기능 하나를 통째로 구현하는 수준으로 확장되었다. 테스트 코드 생성, 리팩토링, 마이그레이션, 문서화처럼 명확한 패턴이 있는 반복 잡업은 ai가 대부분 처리하는 쪽으로 넘어가고 있고, 그 결과 예전에는 코드를 짜는 속도 자체가 병목이었다면 이젠 코드를 검증하는 것과 신뢰의 절차가 새로운 병목으로 떠오르고 있다. 또한 ai의 개입 범위도 코드 작성을 넘어 PR,이슈,CI실패 원인 분석 같은 팀 단위 프로세스 전반으로 확대되는 추세이다.

3.ai로 빠르게 처리할 수 있게 된 부분은 패턴이 명확한 영역이다. 명확한 영역으로는 보일러플레이트코드,CRUD로직, API연동 코드 작성, 특정 언어와 프레임워크 문법 검색 , 스니펫 생성, 단위테스트 케이스 초안 작성, 코드 스타일 변환,리팩토링,언어 간 마이그레이션, 에러 메시지 해석과 원인 분석, 각종 문서 작성, 레거시 코드 분석/요약 하는 작업이 해당한다. 사람의 개입이 꼭 필요한 부분은 이 기능이 정말 필요한지, 어떤 것을 우선순위에 둘지 같은 비즈니스 맥락과 우선순위 판단은 사람의 몫이다. 또 ai가 만든 코드가 실제 요구사항과 부합하는지 최종적으로 판단하는 검증 책임, 애매하고 모호한 요구사항을 구체적인 스펙으로 다듬어내는 작업은 아직 사람이 주도적으로 해야 하는 영역으로 남아있다.

[JM-220]

1. 기존 개발 씬에서 진행되던 워크플로우 방식은 어떤 모습이었나요?
   핵심을 먼저 적고 가보자면,

• AI 이전 : 코드를 “만드는 것”이 비쌌다. 프로세스 전체가 구현 시간을 아끼도록 설계됨. 꼼꼼한 사전기획, 공수 산정, 역할 분업, 인수인계 문서
• AI 이후 : 코드를 “만드는 것”은 싸졌다. 병목이 “무엇을 만들지 정하는 것”과 “만든 게 맞는지 확인하는 것”으로 이동함.

그렇다면 이러한 변화가 기존 워크플로우에 어떻게 적용이 되는지 보자

1. 요구사항 - 기획

AI 이전 : 기획서 → 와이어프레임 → 회의 → 확정 → 개발.
코드를 만드는 것이 비싸 틀리지 않게 미리 다 정해야 했다.

AI 이후 : 대략적인 요구 → AI로 프로토타입을 바로 생성 → 보면서 수정.
기획 순서가 “명세 먼저” 에서 “시제품 먼저” 로 바뀌었다.

왜? 만들어 보는 비용이 문서로 합의하는 비용보다 싸졌기 때문이다. 그러면 구현은 AI 가 하니까 사람은 어떻게 해야할까? 무엇이 가치있는지 누구를 위한 것인지 정하는 일.

2. 설계 - 아키텍처

AI 이전 : 시니어가 설계 문서를 쓰고 리뷰함

AI 이후 : AI 가 여러 설계안과 트레이트오프를 빠르게 제시함. 사람은 비교하고 선택.

왜? 알려진 패턴의 조합은 ai 가 잘 알고있기 때문이다. 그럼 사람은 뭘 해야할까? 장기적인 결정을 해야한다. DB선택, 서비스 경계, 벤더 종속 등 되돌리기 어렵고, 팀 역량, 예산, 조직 구조 같은 코드 밖 제약이 걸려있기 때문이다.

3. 구현

AI 이전 : 개발자 시간의 대부분이 타이핑, 문서 검색, 보일러플레이트 작성에 쓰였다.

AI 이후 : “이 기능을 이 패턴으로 만들어줘” 라고 지시하면 에이전트가 여러 파일을 수정함

이건 대체될 가능성이 굉장히 높다. 패턴이 풍부하고(CRUD, API 연동, UI 컴포넌트 는 수없이 반복된 형태임) 맥락이 코드 안에 있어 에이전트가 레포를 직접 읽을 수 있고, 컴파일, lint, test 과정을 통해 스스로 확인하고 고칠 수 있음. 사람은 이에 맞춰 작업을 적절한 크기로 나누고 명확하게 지시하여야 한다.

4. 테스트

AI 이전 : 테스트 작성이 귀찮아서 자주 생략되었음

AI 이후 : AI 가 테스트를 대량으로 생성함. TDD 의 진입장벽이 크게 낮아짐.

테스트가 기존 기능 검수에서 AI의 출력을 검증하는 핵심 장치가 되며 중요성이 기존보다 더 높아졌다. 사람은 무엇을 테스트해야 하는지, 엣지 케이스 와 비즈니스 규칙 정하기. AI가 코드와 테스트를 둘 다 쓰면 같은 오해를 양쪽에 똑같이 심을 수 있음. 구현과 테스트를 한 놈이 하면 둘다 틀릴 수 있다는 것.

5. 코드 리뷰 ← 병목

AI 이전 : 동료가 작성한 적당한 크기의 PR을 리뷰

AI 이후 : 코드 생산량이 폭증하여 리뷰가 병목이 되었다. 그래서 AI가 1차 리뷰를 하고 사람은 최종 판단만 하는 2단계 구조가 생기고 있음.

사람의 몫은 “이 변경이 우리 시스템에 맞는가”, “요구를 제대로 이해했는가”. 그리고 책임이다. 병합한 사람이 책임을 지게 된다.

6. 디버깅 - 운영

AI 이전 : 로그를 읽고 재현하고, 가설을 세우고 수정하는 과정을 전부 사람이 했음

AI 이후 : 에러 로그와 스택 트레이스를 보여주면 AI가 원인을 추적하고 수정안을 냄. 모니터링 알림에서 자동으로 수정 pr 을 만드는 흐름도 생기고 있음.

사람의 몫은 프로덕션 장애 대응, 롤백 결정, 데이터 복구처럼 되돌릴 수 없는 행동임. 재현이 어려운 버그도 여기에 들어감.

7. 문서화

AI 이전 : 항상 뒤처지고 낡았음

AI 이후 : 코드에서 자동으로 생성하고 갱신함. 문서의 독자가 바뀜. 사람이 아니라 AI에게 맥락을 전달하는 문서가 새로운 핵심 산출물이 됨.
2. AI 발전에 따라 워크플로우는 어떤 방향으로 변화해 가고 있다고 보시나요?
1번에 카테고리 별로 적는 게 나을 것 같아서 위에 적음.
3. 기존 방식 중 AI로 빠르게 진행할 수 있게 된 부분과, 아직은 사람의 개입이 필요해 보이는 부분은 각각 무엇인가요?
검증 가능하고, 맥락이 안에 있고, 되돌릴 수 있는 일은 빠르게 AI에게로 넘어간다. 이에 해당하지 않는 부분은 사람이 개입해야 한다. 예를 들어서 문제가 코드 밖에 있는 경우(고객 대응이나, 조직 정치, 규제, 등), 되돌리기 어려운 문제인 경우(배포, 데이터 삭제, 외부 발송), 누군가 책임져야 하는 문제(보안, 법, 계약), 추가로 가치 판단이 필요한 부분 “무엇을, 왜” 의 문제 등이 될 수 있다.