[발표자료 다운로드] AI 시대 엔지니어의 문제 정의 역량

구현을 AI가 맡을수록 사람의 일은 요구 정의와 품질 판단으로 옮겨 간다. 이 발표자료의 메시지는 이 한 문장이다.

전체 30장, PDF로 30쪽이다. AI 주도 개발과 국내 현장 변화, 기술 관점에 머무는 사고 습관, 요구를 정확히 정의하는 사고 기법, 아키텍트 역량과 기술 기본기 네 부분으로 나뉘고, 마지막에 개발팀이 바로 쓸 수 있는 점검표 여섯 항목을 실었다.

문제 제기는 MinoDriven의 TECH PLAY 2026 발표 “AI 시대의 커리어 플랜”에서 착안했다. 수치와 사례, 해석은 국내 공공·연구기관 자료와 해외 조사, 국제 표준을 근거로 새로 정리했고 장마다 바닥글에 발행처와 연도를 적었다.

개발팀 세미나 자료로 바로 쓸 수 있도록 PDF로 공개한다.

이 발표자료만 다룬 영상은 아직 없다. 대신 같은 AI 시대 시리즈에서 먼저 나온 업무 습관 편을 소개한다.

문제 정의가 일의 출발점을 다룬다면 업무 습관 편은 매일의 실행을 다룬다. 아래 영상은 이 발표가 아니라 같은 시리즈의 다른 편인 일 잘하는 사람의 다섯 가지 습관을 다룬다.

영상에서 다루는 순서는 다음과 같다.

• 일 잘하는 사람의 차이가 재능보다 반복한 습관에서 나온다는 출발점
• 업무 속도, 우선순위 판단, 에스컬레이션, 솔직함, 반복의 양 다섯 가지 습관의 개요
• 근로시간은 줄었지만 시간당 노동생산성 격차가 남아 있는 국내 직장의 현실

기업이 AI를 업무에 들이는 전체 그림은 엔터프라이즈 AI란 무엇인가에서 함께 볼 수 있다.

AI 도입 뒤 개발팀에서 반복해서 나오는 질문을 기준으로 슬라이드를 배치했다.

1. 국내 기업과 개발자는 AI를 얼마나 쓰고, 얼마나 믿는가
2. AI를 쓰면 실제로 빨라지는가
3. 개발 단계 중 어디를 AI가 맡고 어디가 사람에게 남는가
4. 왜 엔지니어는 요구를 들으면 바로 테이블 설계부터 떠올리는가
5. 요구를 정확히 정의하려면 어떤 질문과 틀을 써야 하는가
6. 아키텍트는 품질을 어떻게 고르고 맞바꾸는가
7. 개발팀은 내일부터 무엇을 바꾸면 되는가

과기정통부와 KISDI의 2025 디지털산업 실태조사에서 국내 사업체의 AI 업무 활용률은 2024년 기준 24.9%다. 한 해 전 15.5%에서 9.4%p 올랐고, 최근 3년 동안 도입한 디지털 신기술 가운데 AI가 43.5%로 가장 많았다.

대한상공회의소 조사를 보도한 기사에 따르면 제조기업의 AI 활용률은 대기업 49.2%, 중소기업 4.2%다. 두 조사는 대상과 질문이 달라 한 축에 겹쳐 비교하지 않는다.

▲ 국내 사업체의 AI 업무 활용률은 2024년 24.9%로 한 해 만에 9.4%p 올랐지만 제조 대기업과 중소기업의 격차는 크다 (발표자료 4쪽)

Stack Overflow 2025 개발자 설문에서 개발자 84%가 AI 도구를 쓰거나 쓸 계획이라고 답했고, 전문 개발자의 50.6%는 매일 쓴다. 그런데 AI 출력의 정확도를 신뢰한다는 응답은 33%, 불신한다는 응답은 46%였다.

가장 큰 불만은 거의 맞지만 틀린 답이라는 응답 66%였고, 45%는 AI 코드를 디버깅하는 데 더 오래 걸린다고 답했다. 쓰는 사람은 많지만 결과를 그대로 믿지 못한다. 거의 맞는 답을 걸러 내는 검증이 개발자의 핵심 업무로 남는다.

근거를 추적할 수 없는 답은 업무에 그대로 쓰기 어렵다. AI 답변이 어떤 자료에 기대고 있는지 확인하는 절차가 검증 업무의 첫 단계다.

▲ 개발자 대부분이 AI 도구를 쓰지만 결과를 그대로 믿지 못해 검증이 핵심 업무로 남는다 (발표자료 5쪽)

Google의 2025 DORA 설문에서 응답자 약 5,000명 중 90%가 업무에 AI를 쓰고 80% 이상이 생산성 향상을 체감했다. 하지만 AI 도입은 처리량과는 양의 관계, 배포 안정성과는 음의 관계로 나타났다. DORA는 AI가 팀을 고치지 않고 이미 있는 것을 증폭한다고 정리했다.

METR의 무작위 대조 실험에서는 숙련 개발자 16명이 이슈 246건을 처리할 때 AI를 쓰면 19% 더 걸렸지만, 본인들은 20% 빨라졌다고 믿었다. 2025년 초 도구 기준이며, 2026년 2월 재측정에서는 빨라지는 방향이 약하게 나왔다. 요건·리뷰·테스트 기반이 약한 팀에서는 속도보다 배포 불안정이 먼저 커진다.

▲ AI 는 팀이 이미 가진 기반을 키우므로 요건·리뷰·테스트가 약하면 배포 불안정이 먼저 커진다 (발표자료 6쪽)

국내 공공 SW 사업의 개발 단계로 보면 구현과 시험은 AI 활용 효과가 크고 요구분석과 설계는 생성형 AI를 쓰기 어렵다. 소프트웨어정책연구소(SPRi)는 요구분석·설계 단계에서는 생성형 AI 활용이 쉽지 않고 시험 단계가 가장 효과적이라고 봤다.

설계는 초안을 AI가 쓰고 결정은 사람이 내린다. 사람의 일이 요구사항을 정의하는 쪽으로 옮겨 가고 있다.

▲ 구현과 시험은 AI 가 빠르게 맡고 요구분석은 사람 판단이 남는다 (발표자료 7쪽)

요구와 요건을 정하는 문제 정의 구간에서는 사람이 Pilot이고 AI가 Copilot으로 돕는다. 설계와 구현의 문제 해결 구간에서는 AI가 Pilot이고 사람이 Copilot으로 리뷰한다.

그런데 리뷰는 결국 요구 이해로 이어진다. AI 결과물을 리뷰하려면 요건을 알아야 하고, 요건이 맞는지 판단하려면 고객 요구를 알아야 하며, 마지막에는 정의한 요구 자체가 맞는지 검증해야 한다. 리뷰 역량과 요구 이해 역량은 한 묶음이다.

에이전트형 코딩 도구가 저장소를 읽고 파일을 고친 뒤 테스트까지 돌리는 팀에서는 개발자의 시간이 코드 작성보다 명세 품질과 검증, 리뷰로 옮겨 간다. 요구를 정확히 적는 일이 곧 AI에 일을 맡기는 방법이 된다.

▲ AI 결과물을 리뷰하려면 요건을, 요건을 판단하려면 고객 요구를 알아야 한다 (발표자료 8쪽)

한국은행 분석에서 4년간 줄어든 청년 일자리 28.5만 개 가운데 94%인 26.8만 개가 AI 고노출 업종이었다. 청년 고용은 정보서비스업에서 31.4%, 컴퓨터 프로그래밍업에서 16.6% 줄었고, 같은 기간 50대 일자리는 오히려 늘었다. 한국은행은 이를 경력 편향 기술 변화로 보면서도 AI 단독 효과로 보기는 신중해야 한다고 덧붙였다.

SPRi의 전문가 26명 델파이 조사도 초급 개발자 일자리가 생성형 AI의 영향을 가장 크게 받는다고 봤다. 경력 초기부터 요구 이해와 검증 경험을 쌓아야 경쟁력이 남는다.

▲ 경력이 짧은 사람의 정형화된 구현 업무부터 줄어든다 (발표자료 9쪽)

이 작업으로 고객의 어떤 문제가 풀리느냐고 물으면 API를 바르게 동작시키려고, 성능 요건을 맞추려고, 그 칼럼이 NULL이면 장애가 나서 같은 답이 먼저 나온다. 모두 수단에 관한 답이다.

고객 문제로 답하면 주문을 취소한 고객이 다시 구매하지 않아 매출이 줄어든다처럼 누가, 무엇 때문에, 어떤 손해를 보는지가 나온다. 고객이 겪는 문제까지 말하지 못하면 AI에 줄 요건도 정할 수 없다. 사안을 정리해 결론을 내는 논리적 사고가 필요하다.

요구를 자연어로 AI에 건네는 지금은 요구가 정확한지, 명세가 분명한지가 결과 품질을 먼저 정한다.

▲ 고객이 겪는 문제까지 말하지 못하면 AI 에 줄 요건도 정할 수 없다 (발표자료 11쪽)

현업이 주문을 취소한 고객에게 다시 연락하고 싶다고 하면, 개발자는 바로 주문 테이블에 취소 사유 칼럼과 알림 플래그를 추가하자고 말한다. 목적을 묻지 않은 채 설계가 먼저 정해진다.

이때 건너뛴 질문은 세 가지다.

1. 왜 연락하려는가 — 목적
2. 무엇으로 성공을 판단하는가 — 성공 기준
3. 누구에게 연락하는가 — 대상 범위

요구가 틀리면 구현이 맞아도 다시 만들어야 한다.

▲ 해결책을 먼저 내면 목적·성공 기준·대상을 묻는 요구 확인 단계를 건너뛴다 (발표자료 12쪽)

과기정통부가 2020년 공공SW사업 과업변경 가이드를 내며 밝힌 2018년 실태조사에서 공공 SW 사업 참여 기업의 27.3%가 과업 변경을 겪었다. 정부는 원인을 시스템이 구축되면서 요구사항이 구체화되는 특성으로 설명한다.

해외에서도 PMI 조사에서 목표에 못 미친 프로젝트의 47%가 부정확한 요구사항 관리를 원인으로 꼽았다. 소프트웨어 진흥법 제44조는 발주할 때 요구사항을 상세하게 작성해 공개하도록 정한다. 법으로 상세화를 의무화할 만큼 반복된 약점이다.

▲ 요구사항이 구축 도중에 구체화되는 구조가 과업 변경의 원인이다 (발표자료 13쪽)

스키마는 경험으로 쌓인 지식의 틀이고, 사람은 새 정보를 이 틀에 맞춰 해석한다. 바틀렛의 1932년 실험에서 낯선 민담을 여러 번 다시 말하게 하자 낯선 부분은 빠지고 익숙한 표현으로 바뀌었다.

엔지니어도 같다. 고객이 다시 찾아오게 하고 싶다는 말을 듣는 순간 방문 이력 테이블과 알림 API로 받아 적는다. 기술력 자체는 버릴 대상이 아니다 — AI 결과물을 판단하는 데 계속 필요하다.

▲ 기술 지식이 깊을수록 요구도 기술 틀로 바꿔 듣게 된다 (발표자료 14쪽)

엔지니어는 요건을 코드로 옮기는 구체화에는 익숙하지만, 코드에서 요구로 거슬러 오르는 추상화에는 서툴다. 추상화는 대상의 여러 특징 가운데 목적에 맞는 특징만 뽑아내는 일이다.

위로 올라갈 때는 즉, 무엇을 위해서인가를 묻고, 아래로 내려갈 때는 예를 들면 무엇인가를 묻는다. AI가 구체화를 맡을수록 위로 묻는 질문이 사람 몫으로 남는다.

▲ 위로는 무엇을 위해서인지, 아래로는 예를 들면 무엇인지 묻는다 (발표자료 16쪽)

목적은 도달하려는 상태, 목표는 목적을 이뤘는지 판단하는 조건, 수단은 그 방법이다.

요건과 인수 기준이 AI에 주는 합격선 역할을 한다.

AI가 그럴듯한 결과를 내더라도 무엇이 맞는지 정해 둔 기준이 없으면 그 결과를 실무에 적용할 수 없다. 인수 기준을 먼저 적어 두면 AI 결과물을 받았을 때 통과와 반려를 바로 가를 수 있고, 리뷰 시간도 짧아진다.

▲ 목표가 없으면 AI 결과물이 맞는지 판단할 기준이 없다 (발표자료 17쪽)

ISO/IEC/IEEE 29148은 요구를 비즈니스 요구(BRS), 이해관계자 요구(StRS), 시스템 요구(SyRS), 소프트웨어 요구(SRS) 네 층으로 나눈다.

국내 RFP의 기능 요구사항은 맨 아래 층에 해당한다. 위 층의 사업 목적을 모르면 항목을 다 채우고도 사업 목표를 놓친다.

▲ 국내 RFP 의 기능 요구사항은 요구 계층의 맨 아래 층에 해당한다 (발표자료 18쪽)

포인트 적립·사용 내역을 DB에 저장하고 싶다는 기술 목적을 거슬러 오르면, 구매 금액만큼 포인트를 적립해 결제에 쓰게 하고 싶다는 기능 목적이 나온다. 더 올라가면 고객이 혜택을 받고 다시 방문하게 하고 싶다는 사용자 목적, 결국 재구매율을 높여 고객 이탈을 줄이고 싶다는 사업 목적이 나온다.

포인트는 재구매를 이루는 수단 중 하나다. 상위 목적을 알면 쿠폰이나 재구매 알림과 비교할 수 있다.

▲ 포인트는 재구매를 이루는 수단 중 하나이며 상위 목적을 알면 다른 수단과 비교할 수 있다 (발표자료 19쪽)

같은 주문이라는 말도 영업팀에서는 계약 체결, 물류팀에서는 출고 지시, 회계팀에서는 매출 인식을 뜻한다. 도메인 주도 설계(DDD)는 개발자와 현업이 함께 쓰는 공통 언어를 유비쿼터스 언어라고 부른다.

팀마다 다른 뜻을 용어 사전으로 맞춰야 요구가 정확히 전달된다. 용어 사전에는 용어, 쓰는 문맥, 뜻, 업무 규칙을 함께 적는다. AI에 주는 지시문도 같은 용어를 써야 결과가 맞는다.

사람과 AI가 서로 다른 문서를 근거로 삼으면 같은 질문에도 다른 결론이 나온다. 용어 사전과 요구 문서는 사람과 AI가 함께 읽는 한 자리에 두어야 판단이 갈라지지 않는다.

▲ 팀마다 다른 뜻을 용어 사전으로 맞춰야 요구가 정확히 전달된다 (발표자료 20쪽)

요구 정의 단계의 결과에 책임을 지는 직무는 PM과 아키텍트다. PM은 고객 요구와 사업 목적을, 아키텍트는 품질 요건과 시스템 구조를 정의한다. 아키텍처는 소프트웨어 구성에 관한 중요한 설계 결정의 묶음이다(Keeling, Bass 외).

둘 다 제품 가치가 목적이고 책임지는 층이 다르다. 기술에서 출발한 엔지니어에게는 아키텍트가 가까운 경로이고, 구현을 AI가 맡을수록 두 직무의 판단이 엔지니어의 일상 업무로 내려온다.

현장에서는 개발자의 역할이 코드 작성에서 제품 기획, 명세 작성, 검증, 조정, 의사결정으로 넓어지고 있다. 아키텍트로 가는 길은 새 직함보다 이 일들을 먼저 맡아 보는 데서 열린다.

▲ PM 과 아키텍트는 모두 제품 가치가 목적이고 책임지는 층이 다르다 (발표자료 22쪽)

ISO/IEC 25010은 2023년 개정으로 품질 특성이 9개가 됐다. 사용성은 상호작용 능력, 이식성은 유연성으로 이름과 범위가 바뀌었고 안전성이 새로 들어갔다.

AI에 기능만 지시하면 나머지 특성은 정하지 않은 채 남는다. 피크 시 응답 2초 이내, 개인정보 칼럼 암호화 저장 같은 품질 요건을 지시에 함께 넣어야 한다.

▲ 기능 외 여덟 품질 특성을 AI 지시에 함께 넣어야 한다 (발표자료 23쪽)

컨테이너 기반 클라우드 네이티브는 가용성과 확장성을, MSA는 변경 용이성을, 제로 트러스트는 보안성을 높인다. 제로 트러스트 원칙은 과기정통부·KISA 가이드라인 2.0(2024)이 정리했다. 관측성은 장애 원인 추적과 병목 측정으로 신뢰성과 성능 효율성을 판단할 근거를 준다.

MSA는 서비스 경계가 늘어나는 만큼 공격 표면과 운영 부담도 함께 늘어난다. MSA를 고를 때의 판단 기준은 마이크로서비스 아키텍처(MSA)란?에서 이어서 볼 수 있다.

▲ 어떤 구조도 모든 품질 특성을 함께 올리지 못한다 (발표자료 24쪽)

개발 자원은 유한하고 품질 특성끼리 부딪친다. 그래서 ATAM(Architecture Tradeoff Analysis Method) 같은 방법으로 품질 시나리오를 정하고 트레이드오프 지점을 찾아 어느 특성에 비용을 쓸지 결정한다. 순서는 품질 시나리오 정의, 아키텍처 방식 분석, 트레이드오프점 식별, 위험 정리와 결정 기록이다.

결제 서비스에서 결제마다 추가 인증을 넣으면 보안성은 오르지만 결제 단계가 늘어 상호작용 능력이 떨어진다. 고액 결제에만 추가 인증을 넣는 식으로 이탈률과 사고 위험을 같은 제품 가치 기준으로 비교한다. 제품 가치를 기준으로 어느 특성에 비용을 쓸지 정하는 일이 아키텍트의 판단이다.

▲ 제품 가치를 기준으로 어느 품질 특성에 비용을 쓸지 정하는 일이 아키텍트의 판단이다 (발표자료 25쪽)

품질을 판단하고 개선하려면 리팩터링, 테스트, 도메인 주도 설계 같은 기술 지식이 필요하다. DORA도 AI 효과를 키우는 역량으로 버전 관리와 작은 배치를 꼽았다.

• 리팩터링을 알면 AI 코드의 중복이나 긴 함수 같은 구조 문제를 판별한다.
• 테스트는 요건을 충족했는지 자동으로 검증한다.
• DDD는 지시문과 코드의 용어가 맞는지 확인하게 해 준다.

기술을 내려놓지 않고 그 위에 질문하는 사고를 더해야 한다.

▲ 좋은 구조를 아는 사람만 AI 코드의 문제를 찾아낸다 (발표자료 26쪽)

개발팀이 바로 해 볼 수 있는 문제 정의 점검 항목은 여섯 가지다.

요구사항 정의서와 리뷰 기준부터 바꾸면 AI 결과물 품질이 함께 올라간다.

AI 에이전트를 개발 업무에 들일 때도 마지막에는 두 질문이 남는다. 이 실행을 누가 승인했는가, 그 결과를 누가 확인하는가. 목적 열과 인수 기준은 두 질문에 답할 근거가 된다.

▲ 새 절차 없이 기존 산출물에 점검 항목 여섯 가지를 더하는 것으로 시작한다 (발표자료 27쪽)

DORA가 보여 준 것처럼 AI는 팀의 강점과 약점을 함께 키운다. 그래서 요구를 정의하는 힘, 품질을 판단하는 힘, 그리고 리팩터링·테스트·도메인 모델 같은 기술 기본기를 함께 다듬어야 한다. 기본기를 다진 팀일수록 AI로 얻는 이득이 커진다.

▲ AI 는 팀의 강점과 약점을 함께 키우므로 요구 정의·품질 판단·기술 기본기를 함께 다듬어야 한다 (발표자료 28쪽)

AI가 구현과 시험을 빠르게 맡으면서 엔지니어의 가치는 무엇을 만들지 정하고 만든 것이 맞는지 판단하는 데로 옮겨 간다. 도구는 빨리 퍼지는데 요구를 정의하고 검증하는 기반은 그만큼 따라오지 못했다.

엔지니어가 길러야 할 역량은 문제 정의, 품질 판단, 기술 기본기 세 가지다.

AI 시대에 개발자에게 남는 일은 무엇인가

요구를 정의하고 품질을 판단하는 일이다. 구현과 시험은 AI 효과가 크고, AI 결과물을 리뷰하려면 요건과 고객 요구를 알아야 하기 때문이다.

AI를 쓰면 개발이 실제로 빨라지는가

체감과 측정이 다르다. METR 실험에서 숙련 개발자는 AI를 쓸 때 19% 더 걸렸지만 20% 빨라졌다고 믿었다.

문제 정의 역량이란 무엇인가

고객이 겪는 문제를 누가, 무엇 때문에, 어떤 손해를 보는지로 말하고, 그 문제를 이뤘는지 판단할 조건을 정하는 역량이다. 소프트웨어에서는 요건과 인수 기준이 그 판단 조건이다.

ISO/IEC/IEEE 29148 요구사항 계층은 무엇인가

요구를 비즈니스 요구, 이해관계자 요구, 시스템 요구, 소프트웨어 요구 네 층으로 나누는 국제 표준이다. 국내 RFP의 기능 요구사항은 맨 아래 층이다.

초급 개발자는 무엇을 준비해야 하는가

경력 초기부터 요구 이해와 검증 경험을 쌓아야 한다. 줄어든 청년 일자리의 94%가 AI 고노출 업종이었다(한국은행).

개발팀은 무엇부터 바꾸면 되는가

새 절차를 만들기보다 기존 산출물에 항목을 더한다. 요구사항 정의서의 목적 열과 인수 기준, AI 코드 리뷰의 요건 대비 확인 항목부터다.

MSAP.ai 자료

• 엔터프라이즈 AI란 무엇인가 — 아직도 Prompt? 이제는 AI Agent 시대
• AI 시대 소프트웨어 종말론과 개발자의 새로운 책임
• AI 인재 부족 시대, AI Agent로 무엇을 대체할 수 있나
• AX(AI 전환)란 무엇인가 — 정의부터 DX와의 차이, 추진 4단계까지
• AI Agent란 무엇인가 — 정의, 구조, 기업 도입 기준
• 마이크로서비스 아키텍처(MSA)란?

외부 공개 자료

• Stack Overflow — 2025 Developer Survey
• Google Cloud — 2025 DORA Report
• METR — Early-2025 AI 숙련 개발자 생산성 실험
• SEI — The Architecture Tradeoff Analysis Method
• 국가법령정보센터 — 소프트웨어 진흥법
• Cloud Native Forum — AI 시대 개발자 생존 전략

국내 AI 활용 수치와 단계별 역할 분담, 목적·목표·수단 표, 요구사항 계층과 품질 특성 9가지, ATAM 판단 순서와 개발팀 점검표 여섯 항목이 PDF 한 파일에 들어 있다. 아래 버튼에서 30쪽 발표자료 PDF를 내려받을 수 있다.