한 장면을 가정해 보겠습니다. 사업부서의 PO가 있습니다. 시장을 읽고, 고객의 목소리를 듣고, "이런 서비스가 필요하다"를 가장 먼저 떠올리는 사람입니다. 그리고 IT부서의 BA가 있습니다. PO가 던진 비즈니스 요구를 받아 "그럼 이걸 어떻게 만들지"로 번역하는 사람입니다.

두 사람의 일은 대개 여기까지였습니다. 요구를 정리해 넘기면, 그 뒤 기능적인 요구사항을 기술적 요구사항으로 상세화하고 아키텍처를 설계하고 표준에 맞춰보는 일은 다른 손을 거쳐야 했습니다. 기술 역량도, 도구도, 시간도 필요한 일이었으니까요. 그러다 보면 처음 그렸던 그림과 최종 결과물 사이에 늘 미묘한 틈이 생겼습니다. "내가 원한 건 이게 아닌데..."

그런데 이번엔 설계까지 직접 끌고 가보기로 합니다. kode:crew와 함께.

BA가 kode:crew 웹페이지에 접속합니다. 설치도, 검은 터미널 창도, 개발자용 프로그램도 없습니다. 로그인 한 번. 그게 전부입니다.

프로젝트를 새로 만들면, 화면 옆에 여러 역할이 나타납니다. 분석가, PM, 아키텍트, UX 디자이너, 그리고 보안·아키텍처 리뷰 담당까지. 한 명의 만능 AI가 아니라, 역할이 다른 AI 전문가들이 한 팀처럼 붙습니다.

"오늘은 뭘 먼저 하면 되지?" 싶은 순간, 화면은 곧장 다음에 할 일을 짚어줍니다. 비즈니스 요구 정리 → 개발 요구사항 구체화 → PRD → 아키텍처 설계 → 표준·보안 검증. 순서가 이미 잡혀 있어 길을 잃을 걱정이 없습니다.

PO는 슬라이드도 표도 아니고, 그냥 말로 요구를 풀어놓습니다. 어떤 서비스를 만들고 싶은지, 무엇이 문제인지, 어떤 사용자가 쓸지. 분석가 AI가 받아 적더니 되묻습니다. "이 부분은 실시간이어야 하나요, 아니면 주기적 집계여도 되나요?" "연동해야 할 외부 시스템은 몇 개인가요?" 미처 생각 못 한 질문 앞에서 잠깐 멈추고, 답하면서 머릿속 그림이 또렷해집니다.

예전 같으면 기존에 다른 사람이 작성했던 문서를 뒤적이거나, 정해진 양식에 따라 한 글자씩 적어내려갔을 것입니다. 그런데 "작성해줘"를 누르면, PM 에이전트가 앞서 정리한 기획 메모와 올려둔 자료를 읽어 내려가며 요구사항정의서(PRD) 초안을 짜나갑니다. 빠진 건 없는지, 위험한 가정은 없는지도 같이 짚어줍니다.

잠시 후 하나로 정리된 요구사항정의서(PRD) 초안이 올라옵니다. BA는 그걸 통째로 받아쓰지 않습니다. 읽고, 몇 문단을 고치고, 우선순위를 다시 잡습니다. AI가 다 해주는 게 아니라, AI가 밑그림을 깔고 사람이 결정을 내린 것입니다.

이어서 아키텍트 에이전트와 아키텍처 상위 설계에 들어갑니다. 외부 연동이 여럿이고, 처리가 특정 시점에 몰릴 수 있는 구조라고 해보겠습니다. 아키텍트 에이전트가 비동기 처리와 메시지 큐를 제안하며 구조를 그립니다.

여기서 BA가 늘 불안하던 지점이 나옵니다. "이 설계, 우리 회사 표준에 맞는 걸까? 나중에 리뷰에서 다 뒤집히면 어쩌지?"

예전이었다면 이 질문의 답은 한참 뒤, 설계를 다 마치고 오프라인 리뷰에 올린 다음에야 돌아왔습니다. 그때 "이건 표준 SW가 아니다", "이 구성은 재검토하라" 같은 말을 들으면, 되돌리는 비용이 만만치 않았습니다.

그런데 kode:crew는 설계하는 바로 그 자리에서 표준의 눈으로 비춰줬습니다.

• 요구사항에 필요한 구성 요소가 설계에서 빠지지 않았는지
• 고른 SW 스택이 사내 표준이고 앞으로도 지원되는지(수명이 끝나가는 기술은 아닌지)
• 비즈니스 요건에 맞는 구조가 실제로 들어 있는지

몇 가지에 노란불이 들어옵니다. 다시 아키텍트 에이전트가 피드백을 바탕으로 설계를 수정합니다. 리뷰를 요청하고 기다릴 필요 없이 직접 해결할 수 있습니다.

민감한 데이터가 오가는 서비스라면 보안 준수는 필수입니다. kode:crew는 아키텍처 점검에 이어, 같은 공정 위에서 보안의 눈으로 한 번 더 훑습니다. 인증·인가 설계는 적절한지, 민감정보는 어떻게 암호화할지, 외부 시스템과 연동하는 경계에 위험한 가정이 없는지. 그 자리에서 "데이터 암호화"를 설계에 명시적으로 추가합니다. 표준과 보안이 따로 돌지 않고, 설계하는 한 흐름 안에서 함께 챙긴 것입니다.

PO와 BA 앞에는 기능만 나열되어 있는 흐릿한 요구명세 몇 장이 아니라 표준·보안 검증까지 거친 구체적인 설계 산출물이 놓입니다. 

이젠 "이런 기능을 원합니다."만으로 끝내는 게 아닙니다. 원하는 것을 자기 손으로 여기까지 그려서 넘기는 것입니다.

사실 이 하루에 담긴 일은 특별한 게 아닙니다. 원래도 PO·BA가 책임지던 일이었습니다. 다만 지금까지는 그걸 직접 끝맺을 도구가 없었을 뿐입니다. 이제 그 도구가 생겼습니다.

① 'AI 한 명'이 아니라 'AI 팀'이 일한다 - crew라는 이름

화면 옆에 나타난 분석가·PM·아키텍트·UX, 그리고 보안·아키텍처 리뷰 담당. kode:crew에는 6종의 전문 AI 에이전트가 있습니다. 이 중 분석가, 제품 관리자(PM), 아키텍트, UX 디자이너 에이전트는 검증된 AI 방법론 BMAD의 에이전트를 활용했고, 나머지 보안 검증, 아키텍처 리뷰 에이전트는 KT 표준에 맞게 직접 만든 에이전트입니다. 각자 고유한 역할과 관점을 가지고, 실제 프로젝트 팀처럼 앞 사람의 결과물을 이어받아 다음 단계를 진행합니다. 이름 그대로 crew(팀)입니다.

② 길을 잃지 않는 이유 - 정해진 워크플로우

"오늘은 뭘 먼저 하지?" 싶은 순간 화면이 곧장 다음 일을 짚어줄 수 있던 건, 각 단계마다 정해진 워크플로우가 있기 때문입니다. "지금은 이걸, 다음은 이걸." 각 전문 에이전트는 이 흐름 위에서 자신의 단계를 맡아, 사람이 큰 그림을 잃지 않고 따라갈 수 있도록 정돈되어 있습니다.

③ 설계하는 그 자리에서 표준을 비추다 

BA가 "이거 표준에 맞나요?"를 리뷰까지 미루지 않고 그 자리에서 확인할 수 있던 것, 이것이 kode:crew의 핵심 차별점입니다.

KT에는 아키텍처 설계 초안을 리뷰하는 ARB(Architecture Review Board)라는 것이 있습니다. 이 리뷰는 상위 설계를 어느 정도 마친 뒤 담당자에게 요청하면, 제출된 문서를 사내 표준에 맞게 설계되었는지 수동으로 검토하는 방식입니다. 

그래서 설계하는 동안에는 "내 설계가 표준에 맞는지"를 미리 알기 어렵고, 리뷰 단계에서야 수정 요청을 받곤 합니다.

kode:crew는 이 검토 관점을 앞으로 당겨 왔습니다. 초기 단계의 ARB가 실제로 보는 것은 "구현이 완벽한가"가 아니라 "요구사항에 비춰 구성이 타당한가"입니다. 

• 요구사항에 필요한 구성 요소가 설계에서 빠지지 않았는가 (요건 ↔ 구성 정합성)
• 채택한 SW 스택이 표준·지속성(EOS)·업무 적합성 관점에서 타당한가
• 비동기·대량 처리 등 비즈니스 요건에 맞는 구조(메시지 브로커·배치 등)가 들어 있는가
• AI 활용(AIDx) 계획이 공정별로 세워졌는가

여기에 더해 상세설계 시 챙길 부분은 '권고'로 미리 짚어줍니다. kode:crew는 이 판정·권고 관점과 KT 표준 SW 리스트·레퍼런스 아키텍처를 내장해, 설계를 진행하는 동안 미리 참고하고 ARB에 필요한 문서까지 정리해 줍니다.

설계하는 그 자리에서 "데이터 암호화"를 바로 설계에 넣을 수 있던 이유. kode:crew는 아키텍처 표준 점검에 이어, KT 보안 가이드를 연계한 보안 검증을 같은 공정 위에 올렸습니다. 인증·인가 설계가 적절한지, 민감정보 처리·암호화가 표준을 따르는지, 외부 연동·네트워크 경계에 위험한 가정이 없는지 등을 설계하는 그 순간 함께 알려줍니다. 즉 아키텍처 표준과 보안 표준이 따로 돌지 않고, 하나의 설계 공정 안에서 함께 검증하는 것입니다. 검증이 맨 뒤가 아니라 설계하는 단계로 당겨진 것, 이것이 오프라인 ARB·보안 리뷰 프로세스를 kode:crew가 개선한 지점입니다.

한 줄로 요약하면 이렇습니다. 

'비즈니스 기능적인 요구사항 위주로만 소통하던 PO·BA가, 상위 설계와 표준·보안 검증까지 스스로 완결했다.'

• 경계의 이동: PO/BA의 일이 '비즈니스 요구·구체화'에서 '상위 설계·표준·보안 검증'까지로 넓어집니다.
• 함께 하는 방식: AI가 대신하는 게 아니라, AI가 조사·초안·검토를 맡고 사람이 매 단계 판단·결정합니다.
• 핸드오프 품질의 상승: 기획·설계를 스스로 완결하니, 수행사와 소통하는 것은 구두 설명이 아니라 검증된 구체적 산출물입니다. 단계 사이 해석 차이에서 오는 오해와 재작업이 줄어듭니다.
• 검증의 전진 배치: 표준·보안 준수 여부를 맨 뒤가 아니라 설계하는 순간에 확인합니다.
• 진입장벽 제로: 도구 설치도, 명령어 학습도 필요 없습니다.

AI 시대에 좋은 서비스를 만드는 힘은 "얼마나 빨리 코드를 짜느냐"보다 "무엇을 만들지 얼마나 정확하게 정의하고 설계하느냐"에서 나옵니다. 그리고 그 일을 가장 잘할 수 있는 사람은, 사업과 요구를 가장 잘 아는 PO·BA입니다.

이 시나리오가 보여주는 것은 거창한 게 아닙니다. 원래도 PO·BA가 책임지던 일을, 이제는 손으로 끝까지 해낼 수 있게 됐다는 것. AI가 대신해 주는 게 아니라 AI와 함께 판단하며 해낸다는 것. PO·BA의 손끝이 닿는 범위가 넓어지는 것, 그것이 AIDx로 나아가는 우리의 변화이자, kode:crew가 만들고 싶은 모습입니다.