AI 도구가 팀 전체에 들어오면, 그 다음 질문은 직무별로 달라진다. 누가 무엇을 더 잘해야 하는가. 공통 원칙은 같아도, 실제로 요구해야 할 역량은 직무마다 다르다.

WEF, LinkedIn, Microsoft가 공통으로 가리키는 방향을 기준으로 직무별 핵심 역량을 정리했다. 분석적 사고, 시스템 사고, AI 리터러시, 워크플로우 설계력, 학습 민첩성이 축이다.

화면기획자 / 설계자

AI 시대 화면기획자는 “요청 받은 걸 정리하는 사람”에서 “문제를 정의하고 실행 가능한 구조로 번역하는 사람”으로 올라가야 한다.

• 문제 정의력 — 무엇을 만들지가 아니라, 왜 바꾸는지부터 자를 수 있어야 한다. 사용자 이탈, 결제 전환, 진입 장벽, 운영 비효율, 예외 처리 누락 같은 문제를 정확히 정의해야 AI도 제대로 쓸 수 있다.
• 구조화 능력 — 요구사항, 정책, 플로우, 상태값, 예외, 문구, 데이터 조건을 구조적으로 정리할 수 있어야 한다. AI는 정리된 입력에는 강하지만, 엉킨 요구사항을 대신 정리해 주지 못한다.
• 예외·운영 시나리오 설계력 — 정상 플로우만 짜는 사람은 약해진다. 미로그인, 결제 실패, 쿠폰 충돌, 권한 없음, 빈 상태, 만료, 환불, 앱/웹 경계 같은 예외를 설계해야 한다.
• AI 활용 검증력 — AI로 정책안, 화면 설명, 회의 정리, QA 체크리스트 초안을 뽑을 수 있어도, 정책 충돌·법적 리스크·문맥 오류는 사람이 걸러야 한다.
• 전달력 — 개발자, 디자이너, QA가 바로 이해할 수 있게 문서화하는 능력. 말 잘하는 것보다 해석 여지 적게 쓰는 능력이 중요하다.

UXUI 디자이너

디자이너는 “보기 좋은 화면 생산자”보다 “사용자 행동을 설계하는 사람”이어야 살아남는다.

• 목적 중심 설계력 — 예쁜 시안보다, 이 화면이 어떤 행동을 유도해야 하는지 설명할 수 있어야 한다. 가입, 결제, 재방문, 탐색, 습관화, 이해도 향상 같은 목적이 먼저다.
• 사용자 흐름 설계력 — AI로 목업은 빠르게 만들 수 있어도, 진입-선택-완료-재방문까지 이어지는 흐름은 사람이 짜야 한다.
• 설명 가능성 — “느낌상 좋아 보여요”는 더 이상 통하지 않는다. 왜 이 구조인지, 왜 이 정보 우선순위인지, 왜 이 CTA인지 설명할 수 있어야 한다.
• 시스템 사고 — 개별 화면 한 장보다 컴포넌트, 패턴, 일관성, 재사용성, 운영 효율까지 봐야 한다.
• AI 시안 활용 + 인간 판단력 — AI로 레이아웃, 카피 방향, 탐색안은 빠르게 만들 수 있어도, 최종안은 브랜드·서비스 맥락·실제 유저 행동 기준으로 걸러야 한다.

퍼블리셔

퍼블리셔는 “디자인을 코드로 옮기는 사람”보다 “구조와 품질을 구현 단계에서 지키는 사람”이 되어야 한다.

• 구조 해석력 — 시안을 그대로 따라 만드는 게 아니라, 컴포넌트화·상태 변화·반응형·재사용·접근성 관점으로 해석할 수 있어야 한다.
• 품질 검증력 — AI가 코드 초안은 만들어 줄 수 있어도, 구조의 적합성·유지보수 가능성·접근성·반응형 안정성·기존 시스템 충돌 여부는 퍼블리셔가 봐야 한다.
• 디자인-개발 중간 번역력 — 디자이너 의도를 이해하고, 개발자가 구현 가능한 단위로 정리하는 능력. 이 연결력이 약하면 AI를 써도 결과가 엇나간다.
• AI 코드 활용력 — 직접 손으로 짜는 속도보다, AI가 만든 코드 초안을 구조적으로 수정하고 정리하는 힘이 중요하다.
• 프론트 이해 기반 확장성 — HTML/CSS/JS 수준에서 끝나지 않고, 컴포넌트 구조와 프론트 협업 방식까지 이해해야 경쟁력이 생긴다.

프론트 개발자

프론트 개발자는 AI 시대에 착시가 가장 빠르게 오는 직무다. 코드 생성 속도가 빨라진다고 대체로 이어지는 게 아니라, 오히려 설계력과 검증력이 약한 개발자가 먼저 흔들린다.

• 아키텍처 판단력 — AI가 컴포넌트 하나는 잘 만들어도, 상태 관리·데이터 흐름·성능·의존성·확장성까지 포함한 구조 판단은 여전히 사람 몫이다.
• 코드 검증력 — AI가 만든 코드는 돌아갈 수 있어도, 보안·예외 처리·성능·테스트 가능성·장기 유지보수성에서 문제를 남기는 경우가 많다.
• 요구사항 해석력 — 애매한 기획을 구현 가능한 형태로 다시 정의하는 능력. 이걸 못 하면 AI를 써도 헛도는 코드만 늘어난다.
• 협업형 문서화 능력 — 기획·디자인·QA와 기준을 맞추기 위한 인터페이스 정의, 상태 정의, API 조건 정리가 점점 중요해진다.
• AI 코딩 도구 통제력 — Copilot류나 LLM으로 생산성은 높이되, 결과물을 무비판적으로 머지하지 않는 습관이 필요하다.

QA 담당자

QA는 AI 시대에 오히려 더 중요해진다. 산출물이 빨라질수록 오류도 더 빠르게, 더 많이, 더 그럴듯하게 나오기 때문이다. QA는 “오류를 찾는 사람”이 아니라 “품질 리스크를 예측하고 차단하는 사람”이어야 한다.

• 리스크 기반 사고 — 모든 걸 다 보는 QA보다, 어디서 사고가 날지·어떤 조합이 치명적인지 우선순위를 세울 수 있는 QA가 강하다.
• 시나리오 설계력 — 정상 케이스 체크만으로는 부족하다. 예외·경계값·권한·상태 전이·기기/브라우저 차이·데이터 누락·운영 상황까지 설계해야 한다.
• AI 활용 테스트 자산화 능력 — AI로 테스트 케이스 초안, 회귀 체크리스트, 버그 리포트 정리, 로그 요약의 속도를 높이되, 최종적으로는 실제 리스크를 반영한 설계가 중요하다.
• 커뮤니케이션 정확성 — 버그를 찾는 것보다 더 중요한 건, 재현 경로·영향 범위·우선순위·예상 원인을 명확히 전달하는 능력이다.
• 초기 단계 품질 개입력 — QA는 더 이상 마지막 검사자가 아니다. 기획·설계 단계부터 위험을 미리 짚는 역할로 가야 한다.

직무 공통 필수 역량

직무별 차이는 있어도, 전원 공통으로 요구해야 할 기준이 있다.

• AI 리터러시 — 어떤 일에 AI를 써도 되는지, 어디서 한계가 있는지, 어떤 오류가 자주 나는지 알고 있어야 한다.
• 검증 책임 — AI가 만든 결과물이어도 최종 책임은 사람에게 있다는 감각을 가져야 한다.
• 보안·윤리 감각 — 대외비, 개인정보, 저작권, 내부 문서 사용 기준을 지켜야 한다.
• 구조화·문서화 능력 — AI를 잘 쓰는 사람의 공통점은 머릿속 생각을 구조화해서 입력할 수 있다는 것이다.
• 학습 민첩성 — 툴이 바뀔 때마다 버벅이지 않고 자기 업무에 먼저 붙여보는 속도가 필요하다.

정리: 직무별 한 줄 정의

• 화면기획자/설계자 — 문제를 실행 가능한 구조로 바꾸는 사람
• UXUI 디자이너 — 사용자 행동과 서비스 흐름을 설계하는 사람
• 퍼블리셔 — 구현 품질과 구조를 판단하는 사람
• 프론트 개발자 — 복잡성과 코드 품질을 통제하는 사람
• QA 담당자 — 품질 리스크를 예측하고 차단하는 사람

팀원들에게 요구해야 하는 건 결국 이거다. “AI를 써서 더 빨리 일해라”가 아니라, “AI를 써도 문제 정의, 품질 판단, 협업 전달, 최종 책임은 더 잘해라.” 속도만 KPI로 잡으면 팀이 얕아진다. AI를 도입하면서도 팀이 단단하게 유지되려면, 직무마다 이 기준을 명확히 가져가야 한다.

팀장 관점에서 본 직무별 평가 포인트

팀장으로서 실제로 팀원을 볼 때 기준이 필요했다. “이 사람이 AI 시대에 맞게 일하고 있는가”를 판단하려면, 툴 사용 여부나 산출물 속도가 아니라 일하는 방식을 봐야 한다. 직무별로 내가 실제로 보는 포인트를 정리했다.

직무	평가 포인트
화면기획자 / 설계자	문제를 정확히 정의하는가 / 요구사항과 예외를 구조적으로 정리하는가 / 실행 가능한 문서로 전환하는가
UXUI 디자이너	화면의 목적과 흐름을 설명할 수 있는가 / 사용자 행동 기준으로 설계하는가 / 시안 생산이 아니라 판단과 보정을 하는가
퍼블리셔	시안을 구조적으로 해석하는가 / 구현 품질과 재사용성을 챙기는가 / AI 코드 초안을 정리·개선할 수 있는가
프론트 개발자	구현 속도보다 구조와 품질을 통제하는가 / 요구사항을 기술적으로 재정의하는가 / AI 코드를 검증하고 책임지는가
QA 담당자	리스크 중심으로 테스트 우선순위를 세우는가 / 결함을 명확히 전달하는가 / 초기 단계부터 품질 관점으로 개입하는가

공통적으로 보는 건 하나다. AI를 쓰든 안 쓰든, 결과물에 대한 판단과 책임이 본인에게 있다는 감각이 있는가. 속도는 도구가 올려줄 수 있어도, 이 감각은 도구가 대신해 주지 않는다.