아침 9시, 노트북을 열자마자 IDE 대신 요구사항 문서부터 켜는 개발자가 있어요. 오늘 만들 기능이 무엇인지, 입력은 어떤 형식인지, 예외는 어디서 터질지를 먼저 글로 적습니다. 코드 초안은 그다음에 AI가 씁니다. 신세계I&C 개발자 AI 기획자 전환은 딱 이 장면에서 시작해요.
신세계I&C는 2025년 9월 15일 자체 생성형 AI 개발 플랫폼 ‘스파로스 데브엑스(Spharos DevX)’를 IT서비스 전 과정에 적용한다고 발표했습니다. 그로부터 1년이 지난 2026년 9월, 현장 엔지니어의 하루는 “코드 짜는 시간이 대부분”에서 “무엇을 만들지 고민하는 시간이 더 긴” 쪽으로 옮겨갔어요. 다만 ‘요구사항만 쓴다’는 말은 절반만 맞습니다. 빈자리를 검증이라는 일이 채웠거든요.
목차
- 한눈에 보기
- 신세계I&C가 개발자를 ‘기획자’로 바꾼 이유
- 실제 하루 일과, 전과 후 시간표 비교
- 요구사항 작성법, 프롬프트가 아니라 명세
- 성과와 수치, 생산성은 정말 올랐나
- 개발자 커리어, 무엇이 달라지나
- 우리 회사도 가능할까, 적용 조건 체크리스트
- 마무리하며
한눈에 보기
- 신세계I&C는 2025년 9월 스파로스 데브엑스를 도입하면서 개발 생산성 30% 이상 향상을 목표로 내걸었습니다.
- 2026년 9월 기준 12년 차 SM본부 엔지니어는 개발 시간이 체감상 30~40% 줄고, 매뉴얼 작성 시간은 절반 이상 단축됐다고 밝혔어요.
- 코드 초안은 AI가 쓰지만 예외 처리 누락과 사내 규칙 위반을 잡아내는 일은 사람 몫이라, ‘기획 + 검수’가 새 일과의 뼈대가 됐습니다.
신세계I&C가 개발자를 ‘기획자’로 바꾼 이유
신세계I&C의 공식 목표는 개발자를 코드 구현자가 아니라 AI 에이전트를 조율하는 ‘AI의 리더’로 재정의하는 것이었습니다. 양윤지 대표는 발표 당시 “AX시대의 개발자는 더 이상 코드를 구현하고 분석하는 데 머물지 않는다”고 말했어요. 원문은 신세계그룹 뉴스룸 보도자료에서 볼 수 있습니다.
사진 출처: www.businesspost.co.kr
스파로스 데브엑스는 도구 하나가 아니라 여러 에이전트를 묶은 플랫폼이에요. 코딩 에이전트 외에 시스템 분석, 설계, 개발, 테스트, 품질점검, 운영까지 여섯 단계를 지원합니다. 챗GPT와 제미나이, 클로드 등 여러 모델을 함께 쓰고, MCP라는 표준 통신 규약으로 사내 시스템을 안전하게 연결하는 구조라고 밝혔어요.
유통 그룹의 IT 자회사라는 점이 이 방식과 잘 맞았다고 봅니다. 신세계I&C 일감의 상당 부분은 그룹 내부 시스템 개발과 유지보수(SM)예요. 요구사항이 사내에서 나오고 기술 스택이 어느 정도 표준화된 환경이라, 요구사항을 글로 정리해 AI에게 넘기는 흐름이 외부 SI보다 자리 잡기 쉬웠을 겁니다.
실제 하루 일과, 전과 후 시간표 비교
블로터가 2026년 9월 5일 보도한 박정철 SM본부 엔지니어의 하루는 코드 작성이 아니라 요구사항 검토와 결과물 검증으로 채워져 있습니다. 챗봇관리시스템과 AI컨택센터(AICC)를 운영하는 12년 차 엔지니어예요. 아래 표는 기사에 나온 업무 변화를 바탕으로 하루 흐름을 재구성한 예시입니다. 시간대는 이해를 돕기 위한 배치이고 실제 근무표는 아니에요.
| 시간대 | 전환 전(2025년 이전) | 전환 후(2026년 9월 기준) |
|---|---|---|
| 오전 | 티켓 확인 후 바로 코드 작성 | 요구사항 검토, 입출력·예외 조건 문서화 |
| 점심 전후 | 기존 코드 분석에 시간 소모 | 코드 어시스턴트가 기존 코드 분석·초안 생성 |
| 오후 | 구현 계속, 디버깅 | 초안 검증, 엣지 케이스 직접 테스트, 사내 규칙 점검 |
| 퇴근 전 | 매뉴얼·문서 작성 | 매뉴얼 초안 작성 후 ‘놀리지(Knowledge)’에 등록 |
가장 크게 줄어든 일은 문서 작업이에요. 매뉴얼 작성 시간이 50% 이상 줄었다고 하니, 하루 2시간 걸리던 일이 1시간 안쪽으로 들어온 셈입니다. 개발 시간 전체로는 체감 30~40% 단축이라고 했어요. 주 5일 가운데 하루 반 정도가 비는 크기라고 보면 감이 옵니다.
그 시간이 고스란히 남는 건 아닙니다. 박 엔지니어는 “AI가 만든 결과물을 100% 신뢰할 수는 없다”고 했고, 경우에 따라서는 검증에 이전보다 많은 시간을 쓴다고도 했어요. 여러 AI 도구가 서로 다른 답을 내놓으면 어느 쪽이 맞는지 확인하는 시간이 따로 붙습니다. 코드를 안 짜는 대신 코드를 읽는 시간이 늘어난 거예요.
제가 AI 코딩 도구로 일하면서 느끼는 것도 비슷합니다. 요구사항을 두루뭉술하게 넘기면 AI는 빈칸을 알아서 채워요. 그 ‘알아서’가 문제입니다. 없어도 될 예외 처리를 넣기도 하고, 꼭 있어야 할 예외 처리를 빼기도 하거든요. 결국 요구사항을 고쳐 쓰고 초안을 다시 받는 왕복이 생깁니다.
요구사항 작성법, 프롬프트가 아니라 명세
AI에게 넘기는 요구사항은 채팅 한 줄이 아니라 명세서에 가까워야 재작업이 줄어듭니다. 블로터 기사에서 실제 문제로 지목된 것이 예외 처리 누락, 사내 코딩 규칙 미준수, 특정 조건에서만 터지는 엣지 케이스였어요. 셋 다 요구사항 단계에서 적어 주지 않으면 AI가 임의로 결정하는 항목입니다.
- 입력과 출력의 형식, 빈 값과 최대 길이 같은 경계 조건
- 실패했을 때의 동작(재시도, 로그, 사용자 메시지)
- 따라야 할 사내 코딩 규칙과 참고할 기존 모듈의 위치
- 성능 기준(응답 시간, 처리 건수)과 보안 제약
- 완료 판정 기준, 즉 어떤 테스트가 통과해야 끝인지
흔한 실수는 ‘기존 코드처럼 만들어 줘’라고만 쓰는 거예요. AI는 어떤 기존 코드인지 모르니 비슷해 보이는 것을 골라 흉내 냅니다. 파일명이나 함수명을 콕 집어 주는 편이 훨씬 안전해요. 완료 기준을 안 적는 것도 자주 보입니다. 기준이 없으면 ‘일단 돌아가는 코드’에서 멈추고, 검수하는 사람이 뒤늦게 구멍을 찾게 되거든요.
여담인데, 저는 이 역할을 ‘기획자’라고 부르는 게 조금 아쉽습니다. 실제로 하는 일은 요구사항을 검증 가능한 문장으로 바꾸고 결과물을 판정하는 일이라, ‘요구사항 엔지니어’에 더 가깝다고 봐요. 기획자라는 말이 주는 인상보다 훨씬 기술적인 일입니다.
성과와 수치, 생산성은 정말 올랐나
공식 목표는 개발 생산성 30% 이상 향상이었고, 1년 뒤 현장 체감치는 30~40% 시간 단축으로 목표선 언저리에 와 있습니다. 다만 두 숫자 모두 회사 전체를 측정한 통계가 아니라 목표치와 개인 체감이라는 점은 구분해서 읽는 편이 좋아요. 현장 발언 전문은 블로터 기사에 실려 있습니다.
사진 출처: cdn.itdaily.kr
| 지표 | 수치 | 성격 | 기준 시점 |
|---|---|---|---|
| 개발 생산성 향상 목표 | 30% 이상 | 회사 발표 목표치 | 2025년 9월 |
| 개발 시간 단축 | 30~40% | 엔지니어 체감 | 2026년 9월 |
| 매뉴얼 작성 시간 단축 | 50% 이상 | 엔지니어 체감 | 2026년 9월 |
| 상반기 연구개발비 | 16억 2천만 원 | 반기보고서 기반 보도 | 2026년 상반기 |
연구개발비는 배경으로 볼 만합니다. 2026년 상반기 연구개발비가 이미 2025년 한 해 투자액을 넘어섰고, 매출 대비 비중은 0.2%에서 0.5%로 올라갔어요. 절대 금액은 크지 않지만 방향이 AI 쪽으로 기울었다는 신호로는 읽힙니다.
수치 뒤의 의미도 짚어 볼게요. 코드 생성 비중이 올라갈수록 검수 부담은 함께 올라갑니다. 문서 50% 단축은 검수가 가벼운 영역이라 숫자가 크고, 코드 30~40%는 검수가 무거워 숫자가 작은 거예요. 두 숫자의 차이 자체가 ‘어디에 사람이 남아야 하는지’를 보여 준다고 봅니다.
개발자 커리어, 무엇이 달라지나
요구되는 역량은 ‘빠르게 구현하는 힘’에서 ‘문제를 정의하고 결과를 판정하는 힘’으로 옮겨갑니다. 박 엔지니어도 앞으로는 “여러 AI 도구를 적재적소에 조합해 업무가 원활하게 진행되도록 구조를 설계하는 역량”이 중요해질 거라고 했어요. 신세계I&C는 2026년부터 개인과 조직 목표에 AI 활용을 주요 요소로 반영하고, 결과만이 아니라 적용하고 개선한 과정까지 평가한다고 합니다.
“예전에는 코드를 짜는 시간이 하루의 대부분이었는데 지금은 어떤 기능을 만들지 고민하는 시간이 더 길다.”
주니어에게는 솔직히 불리한 면이 있습니다. 코드를 직접 많이 짜 보며 감을 쌓는 단계가 짧아지는데, 검증은 그 감이 있어야 가능하거든요. 반대로 도메인을 오래 다룬 시니어는 유리해요. 유통 시스템의 예외 상황을 몸으로 아는 사람이 요구사항을 훨씬 촘촘하게 씁니다. 주로 다루던 언어가 아니어도 AI 초안으로 시도할 수 있게 됐다는 점은 양쪽 모두에게 기회입니다.
불안하실 수 있어요. 저도 코드 짜는 시간이 줄어드는 게 처음엔 손해처럼 느껴졌습니다. 그래도 지금 준비할 수 있는 건 분명해요. 요구사항을 검증 가능한 문장으로 쓰는 연습, 남이 쓴 코드를 빠르게 읽고 구멍을 찾는 연습입니다. 둘 다 AI가 대신해 주지 않는 일이에요.
우리 회사도 가능할까, 적용 조건 체크리스트
내부 시스템 비중이 높고 기술 스택이 표준화돼 있으며 코드 리뷰 문화가 이미 있는 조직일수록 이 방식이 잘 붙습니다. 반대로 고객마다 스택이 다른 외부 SI나 리뷰 없이 바로 배포하던 팀은 검수 병목부터 먼저 만나게 돼요. 도입 전에 아래 항목을 점검해 보면 좋습니다.
- 요구사항 템플릿이 있는가(입출력·예외·완료 기준 항목 포함)
- 코드 리뷰 체계가 있고 리뷰어 시간이 확보되는가
- 사내 코딩 규칙이 문서로 정리돼 AI에게 넘길 수 있는가
- AI 도구 라이선스와 소스코드 외부 반출 정책이 정리됐는가
- 파일럿 범위를 좁게 잡았는가(문서 작성처럼 검수가 가벼운 영역부터)
- 여러 AI 도구가 다른 답을 낼 때 판정 기준을 누가 갖는지 정했는가
- 평가 제도에 결과만이 아니라 AI 적용 과정을 넣을 수 있는가
파일럿은 문서부터 시작하는 편을 권해요. 신세계I&C 사례에서도 가장 큰 숫자가 나온 곳이 매뉴얼 작성이었습니다. 검수가 가벼운 곳에서 성공 경험을 쌓고, 그다음 코드 초안으로 넓히는 순서가 조직의 거부감을 줄입니다.
마무리하며
개발자가 사라지는 게 아니라 개발자의 정의가 바뀌는 중이라고 봅니다. 신세계I&C의 1년은 ‘요구사항만 쓰면 끝’이 아니라 ‘요구사항을 쓰고 결과를 책임진다’는 쪽으로 정리됐어요. 코드를 짜는 손은 AI로 넘어갔지만, 틀렸을 때 책임지는 자리는 그대로 사람에게 남았습니다.
앞으로 1년은 검수 병목을 어떻게 푸느냐가 관건일 것 같아요. 테스트 에이전트가 엣지 케이스를 얼마나 잡아 주느냐에 따라 체감 수치가 더 올라갈 수도, 여기서 멈출 수도 있다고 봅니다. 여러분 회사에서는 AI가 짠 코드를 누가, 얼마나 시간을 들여 검증하고 계신가요? 요구사항을 쓰다가 막혔던 경험이 있다면 댓글로 나눠 주세요.