코드 너머의 시대

부제

AI가 모든 것을 바꾼 세상에서 살아남는 법

저자

김상기

머리말

2025년, 저는 여섯 명의 동료와 함께 “코드 너머, 회사보다 오래 남을 개발자”라는 책을 썼습니다. 코드만 잘 짜면 되는 줄 알았던 개발자들에게, 소프트 스킬이라는 ’코드 너머의 세계’가 얼마나 중요한지를 이야기한 책이었죠.

그 책이 세상에 나온 지 채 1년이 지나지 않아, 세상이 다시 한번 크게 바뀌었습니다. AI가 코드를 쓰기 시작한 겁니다. 비개발자가 자연어로 앱을 만들고, AI 에이전트가 수백만 줄의 코드베이스에서 자율적으로 작업하며, ’바이브 코딩’이라는 새로운 단어가 일상이 되었습니다.

전작에서 “코드 너머를 보라”고 말했는데, 이제는 코드 자체의 의미가 달라진 셈입니다.

이 책은 그 변화의 한가운데에서 쓰였습니다. “AI가 내 일자리를 뺏는 건 아닐까?”라는 불안부터, “이 시대에 진짜 중요한 건 무엇일까?”라는 질문까지, 개발자와 비개발자 모두가 품고 있는 고민에 답하려는 시도입니다.

한 가지 미리 말씀드리고 싶은 것이 있습니다. 이 책은 AI를 두려워하라는 책도, AI를 무조건 찬양하라는 책도 아닙니다. AI가 가져간 것과 가져갈 수 없는 것을 냉정하게 구분하고, 그 경계선 위에서 우리가 어떤 역량과 마인드셋을 갖춰야 하는지를 이야기합니다.

전작을 읽으신 분이라면 반가운 연결 고리를 발견하실 겁니다. 그때 “소프트 스킬이 중요하다”고 말씀드렸던 것이, 이 시대에는 “생존의 조건”이 되었거든요. 전작을 읽지 않으셨어도 전혀 문제없습니다. 이 책은 독립적으로 완결됩니다.

자, 그러면 시작해볼까요? AI가 코드를 쓰는 시대, 우리에게 남은 것은 무엇인지 함께 살펴봅시다.

1장. AI가 코드를 쓰는 시대

월요일 아침, 커피를 한 모금 마시고 노트북을 열었습니다. 슬랙에 주말 사이 올라온 메시지가 하나 있어요. 마케팅팀 김 대리가 보낸 겁니다.

“저 이번 주말에 앱 하나 만들었어요. 고객 설문 데이터 자동으로 분석해서 리포트 만들어주는 건데, 한번 봐주실 수 있나요?”

김 대리는 개발자가 아닙니다. 코드 한 줄 짜본 적 없는 사람이에요. 마케팅 전공에, 엑셀은 잘 다루지만 프로그래밍이라고는 대학교 교양 수업에서 파이썬 찍먹한 게 전부인 분입니다. 그런데 앱을 만들었다고요?

처음에는 장난인 줄 알았습니다. 링크를 눌러봤어요. 진짜 돌아갑니다. UI도 깔끔하고, 데이터도 제대로 들어가고, 차트까지 나옵니다. CSV 파일을 업로드하면 감성 분석까지 해서 긍정/부정 비율을 알려줘요. 솔직히 놀랐습니다. 아니, 놀랐다는 표현으로는 부족해요. 좀 당황스러웠다고 해야 정확할 것 같습니다.

“이거 어떻게 만든 거예요?”라고 물었더니, 김 대리의 답은 이랬어요. “Claude한테 이렇게 저렇게 해달라고 말했더니 만들어줬어요. 주말에 세 시간 정도 걸렸나?”

세 시간. 비개발자가. 세 시간 만에. 돌아가는 앱을.

이상한 일이 벌어지고 있습니다. 아니, 어쩌면 이상한 일이 아니라 이미 일상이 된 것인지도 모릅니다.

혹시 비슷한 경험을 하신 적 있으신가요? 주변에서 “나도 앱 만들었어”라는 이야기를 들은 적은요? 만약 아직 없다면, 곧 듣게 될 겁니다. 그리고 그때 느끼게 될 감정은 아마 놀라움 반, 불안 반일 거예요. 그 감정, 아주 자연스러운 겁니다.

이 장에서는 지금 소프트웨어 개발의 세계에서 어떤 일이 벌어지고 있는지를 함께 살펴보려 합니다. 숫자와 사례를 통해서요. 과장 없이, 축소도 없이. 그래야 이 변화가 나에게 어떤 의미인지를 제대로 판단할 수 있을 테니까요.

바이브 코딩 – “느낌대로 만든다”는 것의 의미

2025년 초, 테슬라의 전 AI 디렉터이자 세계적인 AI 연구자 Andrej Karpathy가 트위터에 짧은 글을 올렸습니다. 자신이 요즘 코딩하는 방식을 설명하면서 이런 표현을 썼어요.

“나는 요즘 ’바이브 코딩(Vibe Coding)’을 한다. 완전히 분위기에 몸을 맡기고, 지수적으로 발전하는 것들을 끌어안으며, 코드가 작동하는지조차 기억하려고 하지 않는다.”

바이브 코딩. 직역하면 “분위기 코딩”이라는 뜻인데요, 이 말이 순식간에 개발자 커뮤니티를 뜨겁게 달궜습니다. 왜냐하면 많은 사람이 이미 경험하고 있었지만 이름 붙이지 못했던 현상에 딱 맞는 이름이 생겼으니까요.

핵심은 이겁니다. 복잡한 프로그래밍 문법을 외우고, 세미콜론 하나까지 신경 쓰면서 코드를 짜는 대신, 자연어로 “이런 걸 만들어줘”라고 AI에게 말하면 AI가 코드를 생성해주는 방식이에요.

“로그인 페이지 만들어줘. 이메일이랑 비밀번호 입력 받고, 구글 소셜 로그인도 넣어줘.”

이렇게 말하면 진짜로 코드가 나옵니다. 그것도 꽤 그럴듯한 코드가요. HTML, CSS, JavaScript, 서버 사이드 로직까지 한 번에 생성해줍니다. 5분 전에는 빈 폴더였던 것이 5분 후에는 실행 가능한 로그인 페이지가 되어 있어요.

처음 이 이야기를 듣고 어떤 느낌이 드셨나요? 저는 솔직히 좀 찜찜했습니다. ‘그래서 그게 제대로 돌아가긴 해?’ 하는 의구심과, ‘이러면 우리는 뭘 하지?’ 하는 불안이 동시에 밀려왔거든요. 주변 개발자들에게 물어봐도 비슷한 반응이었어요. 한쪽에서는 “미래다, 혁명이다” 하고, 다른 쪽에서는 “장난감이다, 실무에서는 못 쓴다” 하고.

하지만 숫자는 감정을 기다려주지 않습니다.

Vercel이 발표한 ‘State of Vibe Coding 2025’ 보고서에 따르면, 자사의 AI 기반 개발 도구 v0 사용자 중 63%가 비개발자였습니다. 코드를 한 줄도 짜본 적 없는 사람들이 전체 사용자의 과반을 넘긴 겁니다. 이들은 마케터, 디자이너, 기획자, 창업자였어요. “아이디어는 있는데 개발자가 없어서 못 만든다”라는 말을 하던 사람들이, 이제 직접 만들기 시작한 거죠.

63%라는 숫자를 한번 음미해보세요. AI 개발 도구의 주요 사용자가 개발자가 아니라 비개발자라니요. 이건 마치 포토샵의 주요 사용자가 디자이너가 아니라 일반인이 된 것과 비슷한 상황이에요. 도구의 성격 자체가 바뀌고 있다는 신호입니다.

Cursor, Claude Code, GitHub Copilot, Replit Agent – 이런 도구들이 2025년을 거치며 폭발적으로 성장했습니다. 각각의 특징은 조금씩 다르지만, 본질은 같아요. 사람이 의도를 말하면, AI가 코드를 만든다. 개발자에게는 생산성 도구로, 비개발자에게는 진입 장벽을 없애주는 마법 같은 존재로 자리 잡았습니다.

여기서 한 가지 짚고 넘어가야 할 게 있습니다. 바이브 코딩이 “아무나 아무 프로그램이나 뚝딱 만들 수 있다”는 뜻은 아니에요. 간단한 웹 앱이나 프로토타입 수준에서는 놀라울 정도로 잘 작동하지만, 복잡한 시스템을 설계하거나 대규모 서비스를 안정적으로 운영하는 것은 완전히 다른 차원의 문제입니다. 앞서 김 대리가 만든 앱도, 팀 내에서 쓰기에는 훌륭하지만 수만 명의 사용자를 감당하는 서비스로 키우려면 전혀 다른 수준의 엔지니어링이 필요해요.

하지만 그게 바이브 코딩의 가치를 떨어뜨리지는 않습니다. 모든 아이디어가 대규모 서비스가 될 필요는 없으니까요. 팀 내부에서 쓸 도구, 빠른 프로토타입, 개념 검증(POC) – 이런 영역에서 바이브 코딩은 이미 게임 체인저입니다.

중요한 건 이거예요. 코드를 짜는 행위의 진입 장벽이 극적으로 낮아졌다는 사실. 그리고 이 변화가 일시적인 유행이 아니라, 도구의 성능이 매달 눈에 띄게 좋아지고 있다는 점에서 가속 중인 구조적 변화라는 것.

에이전틱 코딩 – AI가 “스스로” 일하기 시작했습니다

바이브 코딩이 “사람이 말하면 AI가 만든다”는 것이었다면, 한 걸음 더 나아간 개념이 있습니다. 에이전틱 코딩(Agentic Coding)이에요.

차이가 뭐냐고요? 바이브 코딩에서는 여전히 사람이 주도권을 가집니다. “이거 만들어줘”, “저거 고쳐줘”라고 한 줄 한 줄 지시하는 거죠. 에이전틱 코딩은 다릅니다. AI에게 “이 프로젝트를 완성해줘”라고 말하면, AI가 스스로 계획을 세우고, 코드를 작성하고, 테스트하고, 에러가 나면 디버깅하고, 수정합니다. 사람은 중간중간 확인하고 방향을 잡아주는 역할로 물러나는 겁니다.

비유를 하나 들어볼게요. 바이브 코딩이 “내가 운전하면서 내비게이션 안내를 받는 것”이라면, 에이전틱 코딩은 “목적지만 말하면 차가 알아서 가는 것”에 가깝습니다. 자율주행이라는 거죠.

공상과학 영화 이야기 같으신가요? Anthropic이 2026년에 발표한 ’Agentic Coding Trends Report’를 보면, 이건 이미 현실입니다.

이 보고서에 따르면 개발자들이 업무의 약 60%에서 이미 AI를 사용하고 있었습니다. 10명 중 6명이 AI와 함께 일하고 있다는 뜻이에요. 1년 전만 해도 “AI 코딩 도구를 써본 적 있다”는 사람이 절반도 안 됐는데, 이제는 “안 쓰는 사람이 소수”가 된 거예요.

하지만 여기서 흥미로운 숫자가 하나 더 나옵니다. AI에게 “완전히 위임”할 수 있는 작업은 0에서 20% 수준에 불과하다는 거예요. 즉, AI가 많은 일을 도와주지만 혼자서 처음부터 끝까지 해낼 수 있는 일은 아직 제한적이라는 뜻입니다. 이 숫자는 뒤에서 다시 중요하게 다룰 거예요. 기억해두세요.

그렇다면 AI는 주로 어떤 방식으로 쓰이고 있는 걸까요?

보고서가 정리한 8가지 트렌드 중 특히 눈에 띄는 것들을 살펴볼게요.

첫째, 개발 사이클이 극적으로 빨라졌습니다. 예전에는 기능 하나를 기획하고, 개발하고, 테스트하고, 배포하는 데 일주일이 걸렸다면, 이제는 같은 과정이 몇 시간 안에 끝납니다. SDLC(소프트웨어 개발 생명 주기)가 주 단위에서 시간 단위로 압축된 겁니다.

이게 무엇을 의미하는지 느껴지시나요? 한 달에 네 번 시도할 수 있던 것을, 이제는 하루에 네 번 시도할 수 있다는 뜻이에요. 실패해도 빨리 실패하고, 배우고, 다시 시도할 수 있습니다. 개발의 속도가 빨라진 게 아니라, 학습의 속도가 빨라진 거예요. 이건 생각보다 훨씬 큰 변화입니다.

둘째, 단일 에이전트에서 멀티에이전트 팀으로 진화하고 있습니다. AI 하나가 모든 걸 하는 게 아니라, 여러 AI 에이전트가 각자 역할을 맡아서 협업하는 구조가 만들어지고 있어요. 코드를 짜는 에이전트, 테스트를 돌리는 에이전트, 코드를 리뷰하는 에이전트, 문서를 작성하는 에이전트가 팀처럼 움직이는 겁니다.

마치 영화 촬영장처럼요. 감독 혼자서 카메라도 돌리고 연기도 하고 조명도 세팅하는 게 아니라, 각 분야의 전문가가 역할을 나눠서 협업하는 거죠. AI 세계에서도 비슷한 분업이 일어나고 있어요. 그리고 이때 인간의 역할은? 감독이에요. 전체 방향을 잡고, 결과물의 품질을 판단하는 사람.

셋째, AI가 “시도조차 하지 않았을 일”을 가능하게 만들고 있습니다. AI 지원 작업의 약 27%는 AI 없이는 아예 시작하지 않았을 작업이었습니다. 이건 단순히 기존 업무를 더 빠르게 처리하는 차원이 아닙니다. AI가 가능성의 공간 자체를 넓혀주고 있다는 뜻이에요.

“이건 너무 복잡해서 엄두가 안 나” 했던 일, “시간이 없어서 나중에” 미뤘던 일, “인력이 부족해서 포기한” 일 – 이런 것들이 AI 덕분에 가능해지고 있는 거예요. 파이가 커지고 있는 겁니다.

넷째, 소프트웨어 개발이 비기술적 사용 사례로 확장되고 있습니다. 개발 도구가 더 이상 개발자만의 것이 아니게 되었어요. HR에서 채용 프로세스를 자동화하고, 마케팅에서 캠페인 분석 도구를 만들고, 영업에서 CRM 연동 스크립트를 작성합니다. “개발”이라는 행위가 IT 부서를 넘어 조직 전체로 퍼지고 있는 거죠.

일본의 Rakuten 사례는 에이전틱 코딩의 현재 수준을 상징적으로 보여줍니다. Claude Code라는 AI 도구가 1,250만 줄 규모의 오픈소스 라이브러리에서 7시간 동안 자율적으로 작업하여 복잡한 엔지니어링 태스크를 완수했습니다. 정확도는 99.9%. 인간 개발자가 며칠 걸릴 작업을 AI가 하룻밤 사이에 해낸 거죠.

1,250만 줄이라는 숫자가 잘 와닿지 않으실 수 있는데, 비유하자면 두꺼운 소설책 약 2만 권 분량의 코드입니다. 그 방대한 코드를 이해하고, 필요한 부분을 찾아서, 수정하고, 테스트까지 한 거예요. 7시간 만에.

이쯤 되면 좀 불안해지실 수도 있어요. ‘그러면 개발자는 뭘 하라는 거지?’ 하는 생각이 드실 수도 있습니다. 비개발자 분들은 오히려 ‘와, 그러면 나도 뭔가 만들 수 있겠는데?’ 하는 기대감이 들 수도 있고요.

두 감정 모두 자연스러운 거예요. 그리고 두 감정 모두 일정 부분 맞습니다. 개발자가 할 일이 없어지는 게 아니라 할 일의 종류가 달라지는 것이고, 비개발자가 만들 수 있는 것의 범위는 실제로 넓어지고 있으니까요. 이 이야기는 2장과 5장에서 더 본격적으로 다루겠습니다.

보안 우선 아키텍처라는 새로운 과제

에이전틱 코딩 이야기를 하면서 하나 더 짚지 않으면 안 되는 게 있어요. Anthropic 보고서의 8대 트렌드 중 마지막에 자리 잡고 있는 항목, “보안 우선 아키텍처의 필요성”입니다.

AI가 코드를 대량으로 생성하는 시대가 되면, 보안은 어떻게 될까요? 사람이 한 줄 한 줄 짤 때는 (이론적으로는) 보안을 고려하면서 코드를 작성할 수 있었어요. 하지만 AI가 몇 초 만에 수백 줄을 쏟아내면, 그 안에 보안 취약점이 숨어 있을 확률도 높아집니다.

실제로 AI가 생성한 코드에서 발견되는 흔한 문제들이 있어요. SQL 인젝션에 취약한 쿼리, 하드코딩된 비밀 키, 불충분한 입력 검증, 안전하지 않은 라이브러리 의존성 같은 것들이요. AI는 “작동하는 코드”를 만드는 데는 뛰어나지만, “안전한 코드”를 만드는 데는 아직 사람의 검토가 필수적입니다.

이건 비개발자 분들에게도 중요한 이야기예요. 김 대리가 주말에 만든 앱, 잘 돌아가는 건 맞는데 혹시 고객 데이터가 외부로 새나갈 수 있는 구멍은 없을까요? AI가 만든 코드를 아무도 검토하지 않고 업무에 쓴다면, 보안 사고의 가능성은 열려 있는 거예요.

바이브 코딩과 에이전틱 코딩이 확산될수록, 보안을 설계하고 검증할 수 있는 전문가의 필요성은 더 커집니다. 이것 역시 “AI가 가져갈 수 없는 영역”의 하나예요. AI가 코드를 만들어도, 그 코드가 안전한지 판단하는 건 사람의 몫이니까요.

숫자로 보는 변화 – “구조적 전환”의 증거

여기까지 읽으시면서 혹시 이런 생각을 하진 않으셨나요?

“또 과장 아닐까? AI가 세상을 바꾼다는 말, 매년 나오잖아.”

맞습니다. 저도 그런 피로감이 있어요. 2010년대에 빅데이터가 세상을 바꾼다더니 그때도 세상은 그럭저럭 돌아갔고, 블록체인이 모든 것을 혁신한다더니 NFT 열풍은 식었잖아요. “이번에는 진짜 다르다”는 말을 몇 번이나 들었는데, 정말 이번에는 다른 건지 어떻게 알 수 있을까요?

그래서 숫자를 좀 더 들여다봐야 합니다. 감정이 아니라 데이터로 이야기해볼게요.

노코드/로코드 시장의 성장부터 보겠습니다. 2020년에 132억 달러였던 이 시장이 2025년에는 455억 달러로 커졌습니다. 5년 만에 3.4배. 이건 단순한 성장이 아니라 폭발이에요. 한화로 따지면 약 60조 원 규모의 시장이 생겨난 겁니다. 참고로 한국 반도체 수출액의 절반에 해당하는 금액이에요.

이전의 “혁명”들과 비교해보면 차이가 보입니다. 블록체인 시장은 성장과 폭락을 반복했지만, 노코드/로코드 시장은 꾸준히 우상향하고 있어요. 왜냐하면 이건 투기 대상이 아니라 실제 업무에서 쓰이는 도구이기 때문입니다. 실용성이 검증된 시장이 이 속도로 커진다는 건, 실제로 사용하는 사람이 그만큼 많다는 뜻이에요.

신규 애플리케이션의 75%가 로코드 플랫폼으로 제작될 것이라는 전망도 있습니다. 전통적인 코딩으로 처음부터 끝까지 만드는 앱은 오히려 소수가 되고 있다는 뜻이에요. 이건 마치 수제 맞춤 정장과 기성복의 관계와 비슷합니다. 수제 정장이 사라진 건 아니지만, 대부분의 사람은 기성복을 입잖아요. 소프트웨어도 그런 방향으로 가고 있는 겁니다.

앱의 80%가 비개발자에 의해 만들어지는 시대. 이 숫자 앞에서는 “좀 과장이 섞인 거 아냐?” 하는 의심도 잠시 내려놓게 됩니다. 물론 여기서 말하는 “앱”이 모두 복잡한 엔터프라이즈 시스템은 아닐 거예요. 간단한 업무 자동화 도구, 내부용 대시보드, 프로토타입 수준일 수도 있습니다. 하지만 중요한 건 방향이에요. 소프트웨어를 만드는 행위가 더 이상 특정 직군의 전유물이 아니게 되고 있다는 것.

이 숫자들이 말해주는 건 하나입니다. 이 변화는 일시적 트렌드가 아니라 구조적 전환이라는 것. 마치 인터넷이 처음 등장했을 때 “이게 정말 세상을 바꿀까?”라는 의심이 있었지만, 돌이켜보면 인터넷은 세상을 바꾼 정도가 아니라 세상의 기본 인프라가 된 것처럼요.

AI 코딩 도구도 그런 궤적을 밟고 있습니다. 이번에는 진짜 다릅니다. 왜냐하면 이전의 기술 혁명들은 “새로운 것을 할 수 있게 해줬지만”, 이번 혁명은 “기존에 할 수 있던 것의 진입 장벽을 극적으로 낮추고 있기 때문”입니다. 그리고 진입 장벽이 낮아지는 기술은 언제나 폭발적으로 확산됐어요.

개발의 민주화 – 누구나 만드는 시대의 빛과 그림자

“개발의 민주화”라는 표현을 한번 생각해보세요. 멋진 말처럼 들리지만, 이 안에는 꽤 복잡한 감정이 얽혀 있습니다.

비개발자 입장에서 보면, 이건 해방에 가깝습니다. “아이디어는 있는데 만들 사람이 없어서”, “개발팀에 요청했는데 우선순위에서 밀려서”, “외주 개발 견적을 받았는데 예산이 안 돼서” – 이런 답답함에서 벗어날 수 있으니까요.

한번 상상해보세요. 여러분이 영업팀에서 일하고 있는데, 고객 데이터를 매일 엑셀에서 수동으로 정리하고 있습니다. 자동화하면 좋겠다 싶어서 IT팀에 요청했더니, “다음 분기에 검토하겠다”는 답이 돌아왔어요. 3개월을 기다려야 합니다. 그런데 AI 도구를 쓰면 이걸 오늘 오후에 만들 수 있다면? 그 해방감이 느껴지시나요?

마케터가 직접 고객 분석 도구를 만들고, 인사팀이 직접 채용 자동화 시스템을 만들고, 재무팀이 직접 예산 시뮬레이션 앱을 만드는 세상. 문제를 가장 잘 이해하는 사람이 직접 해결책을 만들 수 있게 된 겁니다. 이건 분명 좋은 일이에요.

개발자 입장에서는 좀 다르게 느껴질 수 있어요. 솔직히 말하면, 찜찜하지 않으세요? 몇 년간 프로그래밍 언어를 배우고, 자료구조와 알고리즘을 공부하고, 실무에서 피 튀기며 경험을 쌓았는데, 코드를 한 줄도 모르는 사람이 “나도 앱 만들었어”라고 하면요.

아침에 김 대리의 메시지를 본 개발자가 느꼈을 감정을 상상해보세요. “대단하네”라는 생각과 “그러면 나는 뭐지?”라는 생각이 동시에 들지 않을까요?

그 감정은 자연스러운 겁니다. 부정할 필요 없어요. 다만 그 감정에 머물러 있으면 안 됩니다.

한 발 물러서서 생각해보면, 이런 질문이 떠오릅니다. 김 대리가 만든 그 앱, 정말로 제가 몇 년간 쌓아온 역량과 같은 수준일까요?

아마 아닐 겁니다. 간단한 기능은 잘 돌아가겠지만, 사용자가 급증하면 어떻게 될까요? 예상하지 못한 입력이 들어오면? 보안은? 데이터 정합성은? 동시 접속자가 만 명이 되면? 장애가 나면 누가 디버깅할까요? 이런 문제들은 AI가 자연어 몇 줄로 해결해주지 못합니다.

여기서 흥미로운 역설이 생깁니다. 비개발자가 더 많이 만들수록, 진짜 개발자의 가치는 더 높아질 수 있다는 것. 간단한 앱은 누구나 만들 수 있게 되지만, 그 앱이 실제 비즈니스에서 안정적으로 돌아가게 만드는 것, 여러 시스템과 연동하는 것, 보안과 성능을 보장하는 것, 수만 명의 사용자를 감당하는 것 – 이런 일은 여전히 깊은 전문성을 요구하거든요.

카카오의 경우를 보면 이 변화의 양면을 동시에 볼 수 있습니다. 카카오는 AI로 대체 가능한 직무에 신규 인원 배정을 중단하는 방침을 세웠어요. 한편으로는 무섭게 들리지만, 다른 한편으로는 “AI가 못하는 영역의 전문가를 더 집중적으로 뽑겠다”는 메시지이기도 합니다.

“소프트웨어 개발은 더 이상 특정 직군의 전유물이 아니라, 문제를 가진 사람이 곧 해결자가 되는 방향으로 재편되고 있다.” 이 문장이 우리가 목격하고 있는 변화의 핵심입니다.

그리고 이 문장에는 빛과 그림자가 공존해요. 더 많은 사람이 만들 수 있게 된다는 빛. 그리고 “만들 수 있다”와 “잘 만들 수 있다” 사이의 간극이라는 그림자. 이 간극이야말로, 앞으로 개발자의 가치가 존재하는 공간입니다.

카카오 기술블로그에서 흥미로운 질문을 던진 적이 있어요. “Vibe Coding하는 비개발자는 개발자인가?” 이 질문에 대한 답은 정의에 달려 있습니다. 코드를 만들어내는 사람이 개발자라면, 비개발자도 이제 개발자예요. 하지만 소프트웨어를 설계하고, 운영하고, 책임지는 사람이 개발자라면, 그 정의는 여전히 전문가에게 속합니다.

삼성SDS도 “바이브 코딩의 이해와 적용”이라는 글을 통해 이 변화를 분석했어요. 핵심 메시지는 이거였습니다. 바이브 코딩은 프로토타이핑과 아이디어 검증에서는 혁명적이지만, 엔터프라이즈 수준의 개발에서는 여전히 전문 개발자의 역할이 필수적이라는 것.

결국 개발의 민주화가 의미하는 건 “개발자가 필요 없어지는 것”이 아니라, “개발이라는 활동의 스펙트럼이 넓어지는 것”입니다. 간단한 자동화부터 대규모 시스템 운영까지, 그 스펙트럼 위에서 각자 자기 위치를 찾아가는 시대가 열리고 있는 거예요.

“그래서 코딩을 배울 필요가 없다고요?”

이쯤에서 자주 받는 질문 하나를 다뤄보겠습니다. 특히 비개발자분들, 혹은 자녀의 교육 방향을 고민하시는 부모님들이 많이 물어보세요.

“AI가 코드를 짜주는데, 그러면 코딩을 배울 필요가 없는 건가요?”

대답은 “그렇기도 하고 아니기도 하다”입니다. 좀 불친절한 답처럼 들리시죠? 하지만 진실은 원래 단순하지 않습니다.

자동차를 생각해보세요. 자동 변속기가 나오면서 기어 변속이라는 기술은 필수가 아니게 됐습니다. 내비게이션이 나오면서 지도를 읽는 능력도 덜 중요해졌어요. 후방 카메라가 나오면서 사이드 미러로 후진하는 기술도 덜 필요해졌습니다. 그런데 “운전”이 없어진 건 아니잖아요? 오히려 자동차를 운전하는 사람은 훨씬 더 많아졌습니다.

코딩도 비슷합니다. 프로그래밍 문법을 외우고 타이핑하는 행위의 가치는 줄어들고 있어요. for 루프의 문법을 정확히 기억하는 것, 세미콜론 위치를 아는 것, 특정 라이브러리의 API를 외우고 있는 것 – 이런 것의 가치는 확실히 낮아지고 있습니다. AI한테 물어보면 되니까요.

하지만 “컴퓨터에게 일을 시키는 방식으로 문제를 분해하고 구조화하는 사고력” – 이건 오히려 더 중요해지고 있습니다. AI에게 “이런 앱 만들어줘”라고 말하려면, 최소한 그 앱이 어떤 구조로 돌아가는지는 머릿속에 그릴 수 있어야 하거든요. 데이터가 어디서 들어와서 어디로 나가는지, 사용자가 어떤 흐름으로 화면을 이동하는지, 에러가 발생하면 어떻게 처리해야 하는지 – 이런 구조적 사고는 AI에게 지시를 내리기 위해서라도 필요합니다.

비유하면, 영어 문법을 완벽하게 외울 필요는 줄었지만 (번역기가 있으니까), 무슨 이야기를 할지 생각하는 능력은 여전히 중요한 것과 같아요. 번역기가 아무리 좋아져도 “무슨 메시지를 전달할 것인가”는 사람이 결정해야 하잖아요.

그래서 저는 이렇게 말씀드리고 싶어요. 코딩 문법을 배울 필요는 줄어들고 있지만, 코딩 사고를 배울 필요는 여전합니다. 아니, 오히려 더 커지고 있을지도 모릅니다. 왜냐하면 AI를 효과적으로 활용하려면 결국 기술적 구조를 이해하는 사람이 더 좋은 결과를 얻거든요. 같은 AI 도구를 써도 개발 배경이 있는 사람의 결과물이 더 나은 이유가 바로 이것입니다.

이전 책에서 물었던 질문, 그리고 달라진 대답

제가 전작 “코드 너머, 회사보다 오래 남을 개발자”를 쓸 때, 출발점은 이 질문이었습니다.

“코드만 잘 짜면 되는 거 아니야?”

그때 제 대답은 “아니요, 코드 너머에 있는 소프트 스킬이 결정적 경쟁력입니다”였어요. 경청, 질문, 회의 스킬, 협업, 리더십 – 이런 것들이 코딩 실력만큼이나 중요하다고 말씀드렸죠.

불과 1년여가 지난 지금, 질문 자체가 바뀌었습니다.

“코드를 AI가 짜면, 그 다음은?”

전작에서는 “코드만으로는 부족하다”고 말했는데, 이제는 코드 자체를 AI가 상당 부분 작성하는 시대가 와버린 겁니다. 전작의 추천사에서 누군가가 이런 말을 했었어요. “AI가 코딩을 대신할 순 있어도, 함께 일하고 싶은 사람은 결국 협업을 잘하는 사람이다.” 그때는 약간 먼 미래의 이야기처럼 들렸는데, 이제는 현재 진행형이 되어버렸습니다.

그렇다고 전작의 메시지가 틀린 건 아닙니다. 오히려 그 메시지는 더 강력해졌어요. 코드를 AI가 짤 수 있는 시대에, 사람의 가치는 코드 너머에 있는 것들 – 소통, 협업, 문제 정의, 비즈니스 이해, 사용자 공감 – 에서 결정된다는 것. 전작에서 말한 이 명제가, AI 시대에 와서 생존 전략의 핵심이 된 거죠.

이런 변화가 두려우실 수도 있어요. 하지만 이 책을 읽고 계시다는 것 자체가, 이미 변화를 인지하고 준비하려는 의지가 있다는 뜻입니다. 그리고 그 의지가 가장 중요한 첫 걸음이에요.

마무리 – 이것은 시작입니다

이 장에서 살펴본 바이브 코딩, 에이전틱 AI, 개발의 민주화 – 이 모든 현상이 가리키는 방향은 하나입니다.

코드를 짜는 행위의 의미가 근본적으로 달라지고 있다는 것.

코드를 타이핑하는 기술에서, 코드가 해결해야 할 문제를 정의하고 AI가 만든 코드를 판단하는 능력으로. “어떻게 만들 것인가”에서 “무엇을, 왜 만들 것인가”로. 소프트웨어 개발의 무게 중심이 이동하고 있습니다.

그리고 이 변화는 개발자만의 문제가 아닙니다. 비개발자도, 기획자도, 디자이너도, 경영자도, 취업을 준비하는 학생도 – 소프트웨어가 영향을 미치는 모든 영역의 사람들에게 해당되는 이야기입니다. 아니, 소프트웨어가 영향을 미치지 않는 영역이 있긴 한 걸까요? 2026년 현재, 그런 영역을 찾기가 오히려 어렵습니다.

그렇다면 자연스럽게 이런 질문이 떠오르겠죠.

“이 변화 속에서, 내 자리는 안전한 걸까?”

솔직히 말하면, 그 질문에 대한 대답은 간단하지 않습니다. 하지만 과장된 공포에 휘둘릴 필요도 없어요. 다음 장에서는 데이터를 바탕으로, 이 불안의 실체를 냉정하게 들여다보겠습니다. 불안한 숫자도, 희망적인 숫자도, 있는 그대로 보여드릴게요.

2장. 당신의 자리는 안전한가

어느 날 후배 개발자에게서 카톡이 왔습니다.

“형, 저 요즘 좀 불안해요. 회사에서 AI 도입한다고 하는데, 솔직히 제가 하는 일 대부분을 AI가 할 수 있을 것 같거든요. 3년차인데… 이직을 준비해야 할까요, 아니면 아예 다른 분야를 알아봐야 할까요?”

이 메시지를 읽으면서 가슴이 좀 먹먹했습니다. 3년차면 이제 막 일이 손에 붙기 시작할 때잖아요. 코드 리뷰도 혼자 할 수 있게 되고, 후배한테 설명도 해줄 수 있게 되고, “아, 나 좀 개발자 같아졌다” 싶은 그 시점에, 내 자리가 사라질 수도 있다는 불안을 느끼고 있다니요.

더 솔직하게 말하면, 이 메시지가 먹먹했던 이유는 후배의 불안이 완전히 틀린 말이 아니기 때문이에요. 저라도 3년차 때 이런 상황이었으면 불안했을 겁니다.

혹시 여러분도 비슷한 불안을 느끼고 계신가요? 개발자든 아니든, “AI 때문에 내 일이 바뀌지 않을까”라는 생각을 한 번도 안 해본 사람은 아마 거의 없을 겁니다. 밤에 뉴스를 보다가, 출근길에 팟캐스트를 듣다가, 회사에서 AI 관련 공지를 받다가 – 불현듯 스치는 그 불안 말이에요.

이 장에서는 그 불안을 회피하지 않고 정면으로 마주하려 합니다. 대신, 감정이 아니라 데이터로요. 불안을 키우려는 것도, 괜찮다고 안심시키려는 것도 아닙니다. 있는 그대로 보겠습니다. 불편한 숫자도, 희망적인 숫자도 모두요.

주니어 개발자의 겨울

먼저 불편한 숫자부터 보겠습니다. 외면하고 싶어도 봐야 하는 숫자들이에요.

Stanford Digital Economy Study가 발표한 데이터에 따르면, 22세에서 25세 소프트웨어 개발자의 고용이 2022년 대비 약 20% 감소했습니다. 5명 중 1명이 사라진 겁니다.

20%라는 숫자를 잠깐 음미해보세요. 같은 과 동기 5명이 개발자로 취업했는데, 지금 그중 1명의 자리가 없어졌다는 뜻이에요. 숫자가 체감이 안 되시면 이렇게 생각해보세요. 여러분의 첫 직장 동기들 중 한 명이 자리를 잃었다고요. 그 사람이 내가 될 수도 있었다고요.

상위 15개 테크 기업의 신입 채용도 전년 대비 25% 감소했습니다. 구글, 메타, 아마존, 마이크로소프트 같은 곳들이 주니어 개발자를 예전만큼 뽑지 않고 있다는 뜻입니다. 실리콘밸리의 간판 기업들이 신입을 4분의 1이나 줄였다는 건, 이 변화가 일부 기업의 사정이 아니라 산업 전체의 구조적 변화라는 걸 보여줍니다.

이 숫자들은 무엇을 말해줄까요? 명확합니다. 주니어 개발자, 특히 막 커리어를 시작하는 초급 개발자들이 가장 먼저 충격을 받고 있다는 것. AI가 가장 잘하는 일이 바로 주니어 개발자가 주로 맡는 일 – 보일러플레이트 코드 작성, 단순 버그 수정, 기초적인 기능 구현, 테스트 코드 작성 – 이거든요.

Stack Overflow의 분석도 이 그림을 뒷받침합니다. “AI vs Gen Z”라는 제목의 글에서, 이들은 AI가 초급 개발자의 커리어 진입 경로를 근본적으로 바꾸고 있다고 진단했어요. 예전에는 주니어 개발자가 단순 작업을 하면서 코드베이스를 이해하고, 시니어의 코드 리뷰를 받으며 성장했거든요. 그런데 그 “단순 작업”을 AI가 해버리면, 주니어가 성장하는 사다리의 첫 몇 단이 사라지는 셈입니다.

난감한 상황이죠. 주니어 개발자가 경험을 쌓아야 시니어가 되는데, 경험을 쌓을 기회 자체가 줄어들고 있다니. IEEE Spectrum에서도 “초기 경력 엔지니어가 AI보다 앞서려면 어떻게 해야 하는가”라는 제목의 글을 실었어요. 이 질문 자체가 문제의 심각성을 보여주는 것 같습니다.

이건 개발자만의 문제가 아닙니다. 비개발자 직군에서도 비슷한 현상이 벌어지고 있어요. 주니어 마케터가 하던 리서치 보조, 데이터 정리, 보고서 초안 작성 같은 일을 AI가 해내기 시작하면, 신입 마케터에게 기대하는 역량 수준도 올라갑니다. “들어와서 배우면 돼”가 아니라 “들어오기 전에 이미 할 줄 알아야 해”로 바뀌는 거예요.

코드트리에서 낸 “바이브 코딩 시대 개발자 생존 전략” 글에서도 이 점을 정확히 짚었어요. AI가 초급 업무를 가져가면서, 신입에게 요구되는 역량의 기준선이 올라가고 있다는 겁니다. 예전의 3년차 수준이 이제는 1년차의 기대 수준이 되고 있어요. 무섭지만, 이것이 현실입니다.

한국도 예외가 아닙니다. 카카오는 AI로 대체 가능한 직무에 대해 신규 인원 배정을 중단하는 방침을 세웠어요. CTO가 직접 나서서 AI 역량 강화를 독려하고 있습니다. 국내 채용 시장 전체가 “얼마나 많이 뽑느냐”에서 “누구를 뽑느냐”로 전환되고 있어요.

여기까지 읽으시면 심장이 좀 빨라지셨을 수 있어요. 특히 주니어 개발자이시거나, 개발자로 전향을 준비하고 계신 분이라면요. 혹은 자녀가 컴퓨터 공학을 전공하고 있는 부모님이시라면요.

잠깐, 숨 한번 고르시고요. 이제 동전의 다른 면을 보겠습니다.

잠깐, 정말 그렇게 심각한가요?

불편한 숫자를 먼저 보여드린 이유가 있습니다. 불안을 느끼는 건 자연스러운 일이지만, 불안에 휘둘리면 판단이 흐려지거든요. 공포 속에서 내린 결정은 대부분 좋지 않습니다. 그래서 반대편 데이터도 함께 봐야 해요.

미국 노동통계국(BLS)의 전망을 보면, 2033년까지 소프트웨어 엔지니어 직종은 17% 성장할 것으로 예측됩니다. 17%면 전체 직종 평균 성장률의 거의 4배에 달하는 수치예요. 이건 미국 정부의 공식 통계 기관이 내놓은 전망입니다. “AI가 개발자를 대체한다”는 이야기와는 정반대 방향의 숫자예요.

CNN Business는 이 주제를 다루면서 아예 제목을 이렇게 뽑았어요. “소프트웨어 엔지니어링 일자리 소멸은 크게 과장되었다(The Demise of Software Engineering Jobs Has Been Greatly Exaggerated).” 마크 트웨인의 유명한 말을 패러디한 이 제목이, 현재 상황에 대한 꽤 정확한 요약일 수 있습니다.

잠깐, 이상하지 않나요? 한쪽에서는 고용이 20% 줄었다고 하고, 다른 쪽에서는 17% 성장한다고 합니다. 둘 다 신뢰할 만한 기관의 데이터인데, 정반대 이야기를 하고 있어요.

모순처럼 보이지만, 사실 두 데이터는 같은 현상의 다른 측면을 보여주고 있습니다. 어떻게 그럴 수 있는지 설명해볼게요.

줄어든 20%는 “특정 유형”의 일자리입니다. 주로 초급 수준의 반복적 코딩 업무, AI가 이미 잘하는 영역의 일이에요. 22~25세 연령대에 집중된 감소라는 점이 이를 뒷받침합니다.

늘어나는 17%는 “새로운 유형”의 일자리입니다. AI 시스템을 설계하고, AI와 협업하고, AI가 만든 결과물을 검증하고 통합하는 일. AI/ML 엔지니어, MLOps 엔지니어, 에이전틱 AI 엔지니어 같은 새로운 직군이 빠르게 생겨나고 있어요.

결국 일자리의 총량이 줄어드는 게 아니라, 일자리의 성격이 바뀌고 있는 겁니다. 이 구분이 아주 중요합니다. 이걸 이해하느냐 못하느냐에 따라 앞으로의 전략이 완전히 달라지거든요.

비유를 하나 들어볼게요. 자동차가 등장했을 때를 생각해보세요. 마부는 줄었습니다. 마차를 만드는 사람도 줄었어요. 마구간을 관리하는 사람도 줄었고요. 그 직업들만 보면 “운송 산업이 망하고 있다”고 느꼈을 거예요.

하지만 동시에 운전사, 정비사, 도로 설계사, 교통 경찰, 주유소 직원, 자동차 보험 설계사, 자동차 디자이너가 생겨났잖아요. 마차 산업 종사자 수와 자동차 산업 종사자 수를 비교하면, 후자가 압도적으로 더 많습니다. 전환기에는 일시적으로 혼란이 있었겠지만, 전체적으로 보면 파이가 커진 거예요.

지금 AI 시대에도 비슷한 일이 벌어지고 있는 겁니다. 사라지는 역할에만 눈을 고정하면 공포를 느끼게 되지만, 생겨나는 역할까지 함께 보면 풍경이 달라져요.

65%의 개발자가 예감하고 있는 것

그렇다면 현업 개발자들은 이 변화를 어떻게 느끼고 있을까요? 외부 전문가의 분석도 중요하지만, 실제로 일하고 있는 사람들의 감각도 들어봐야 합니다.

조사에 따르면 개발자의 65%가 자신의 역할이 재정의될 것으로 예상하고 있었습니다. 10명 중 6명 이상이 “내가 하는 일의 종류가 바뀔 것이다”라고 느끼고 있는 거예요. 이건 꽤 압도적인 다수입니다.

주목할 점은, 이 숫자가 부정적이지만은 않다는 겁니다. 37%의 개발자는 AI가 이미 자신의 커리어 기회를 확장했다고 응답했거든요. 불안과 기회가 동시에 존재하는 거죠. 불안을 느끼면서도 동시에 가능성을 보고 있다니, 인간은 참 복잡한 존재입니다.

어떤 기회냐고요? 구체적으로 살펴보면 이렇습니다.

루틴한 코딩 – 반복적인 CRUD 작업, 비슷비슷한 API 연동, 뻔한 패턴의 코드 작성 – 에서 해방된 시간이 생깁니다. 매일 아침 출근해서 “오늘도 비슷한 코드를 치겠구나” 싶었던 그 시간이 돌아오는 거예요.

그 시간은 어디로 갈까요? 아키텍처 설계, 시스템 통합, AI 기반 의사결정 같은 더 고차원적인 업무로 이동하고 있어요.

쉽게 말하면, 벽돌을 쌓는 일에서 건물을 설계하는 일로 무게 중심이 옮겨가고 있는 겁니다. 벽돌 쌓기는 AI가 해주니까, 사람은 “이 건물이 어떤 모양이어야 하는가”, “지진에 견딜 수 있는 구조인가”, “사람들이 편하게 쓸 수 있는 동선인가”를 고민할 수 있게 된 거죠.

실제로 AI/ML 엔지니어링, MLOps, 에이전틱 AI 엔지니어링 같은 새로운 영역의 수요가 급증하고 있습니다. 이건 5년 전에는 존재하지도 않았던 직군이에요. AI를 만드는 일, AI가 잘 돌아가게 운영하는 일, 여러 AI를 조율하는 일 – 이 모든 것이 새로운 일자리로 등장하고 있습니다.

물론 모든 개발자가 이 전환을 자연스럽게 해낼 수 있는 건 아닙니다. 솔직히 말하면, 이 전환이 쉽다면 불안을 느낄 이유도 없겠죠. 어려우니까 불안한 겁니다. 벽돌 쌓기에 숙련된 사람에게 “이제부터 건물을 설계하세요”라고 하면, 당연히 난감하잖아요.

하지만 이 불안에는 건강한 측면이 있어요. 변화를 인지하고 있다는 뜻이니까요. 변화를 모르고 있는 것보다, 불안하더라도 알고 있는 게 훨씬 낫습니다. 최소한 준비할 시간이 있으니까요.

새로운 사다리가 필요한 시대

65%의 개발자가 역할 재정의를 예상한다는 건, 뒤집어 보면 35%는 아직 변화를 체감하지 못하고 있다는 뜻이기도 해요. 그리고 솔직히, 당장 내 업무에 큰 변화가 없다면 “아직은 괜찮아”라고 느끼는 게 자연스럽습니다.

하지만 여기서 한 가지 생각해볼 것이 있어요. 커리어의 변화는 지진처럼 갑자기 오지 않습니다. 물이 끓기 직전에는 조용한 것처럼, 변화가 임계점에 도달하기 전까지는 일상이 유지돼요. 어느 날 갑자기 “내일부터 AI가 당신의 일을 합니다”라고 통보받는 게 아니에요. 서서히, 조금씩, 내가 하던 일의 일부가 자동화되고, 내 직무기술서에 새로운 항목이 추가되고, 채용 공고에 내가 익숙하지 않은 기술 이름이 등장하기 시작합니다.

그래서 37%의 개발자가 “AI가 커리어 기회를 확장했다”고 느끼는 것은 매우 의미심장한 신호입니다. 이 사람들은 변화가 오기 전에 이미 변화의 방향으로 움직이고 있는 거예요. 커리어에서 “타이밍”이 중요하다는 말은 이런 맥락에서 나옵니다.

전통적으로 개발자의 성장 경로는 비교적 명확했어요. 주니어에서 시작해서 미드레벨을 거쳐 시니어로, 그 다음에는 테크 리드나 아키텍트, 혹은 엔지니어링 매니저로. 각 단계마다 “이걸 할 수 있으면 다음 단계로 간다”는 사다리가 있었습니다.

그런데 AI가 사다리의 아래쪽 몇 단을 가져가 버렸어요. 주니어가 밟았던 첫 번째 단 – 보일러플레이트 코딩, 단순 버그 수정, 테스트 작성 – 이런 것들이 AI의 영역이 되고 있으니까요. 기존 사다리의 아래쪽이 사라지면, 새로운 사다리를 놓아야 합니다. AI를 활용해서 더 복잡한 문제를 더 빨리 해결하는 경험, AI가 만든 코드를 평가하고 개선하는 경험, 시스템 전체를 조율하는 경험 – 이런 것들이 새로운 사다리의 첫 단이 될 거예요.

이건 불편하지만 동시에 흥미로운 일이기도 합니다. 새로운 사다리가 놓인다는 건, 새로운 방향으로 올라갈 수 있다는 뜻이니까요.

비개발자의 불안은 다른 모양입니다

여기서 한 가지 짚고 넘어가야 할 것이 있어요. 지금까지 주로 개발자의 시각에서 이야기했는데, 이 변화는 비개발자에게도 깊은 영향을 미칩니다. 오히려 어떤 면에서는 비개발자의 불안이 더 복잡할 수 있어요.

기획자를 한번 생각해보세요. 예전에는 “이런 기능이 필요해요”라고 요구사항 문서를 쓰면, 개발팀이 우선순위를 정하고, 스프린트에 넣고, 몇 주 후에 결과물이 나왔습니다. 기획자는 “무엇을 만들지” 정하는 사람이었고, 개발자는 “어떻게 만들지” 실행하는 사람이었어요. 역할이 명확하게 나뉘어 있었죠.

그런데 이제 AI 도구를 쓰면 기획자가 직접 프로토타입을 만들 수 있게 되었습니다. 개발팀에 부탁할 필요 없이요. 좋은 일처럼 들리시죠?

하지만 이건 동시에 기획자에게 새로운 부담을 안겨줍니다. 이제는 “무엇을 만들지”만 정하면 되는 게 아니라, 실제로 만들어서 보여줘야 하는 기대가 생기거든요. 회의 시간에 “그거 직접 만들어보셨어요? AI로 할 수 있잖아요.”라는 말을 듣게 되는 거예요. “기획만 하는 사람”의 입지가 좁아지는 느낌이 들 수 있습니다.

디자이너도 마찬가지입니다. AI가 디자인 시안을 순식간에 여러 개 만들어낼 수 있게 되면서, 디자이너의 가치는 “예쁘게 만드는 것”에서 “왜 이렇게 만들어야 하는지 설명하는 것”으로 이동하고 있어요. “이 버튼을 여기에 놓은 이유가 뭐예요?”라는 질문에 “AI가 추천했어요”라고 답하면 곤란하잖아요. 디자인 결정의 근거를 논리적으로 설명할 수 있는 능력이 더 중요해지는 거죠.

마케터를 보면 상황이 더 직접적입니다. 광고 카피 초안, SNS 포스팅, 이메일 마케팅 템플릿 – 이런 것들을 AI가 순식간에 만들어내요. “글 잘 쓰는 마케터”의 가치가 예전만큼 높지 않아진 겁니다. 대신 “어떤 메시지가 우리 고객에게 통할지 판단하는 능력”, “데이터를 보고 전략을 수정하는 능력”의 가치가 올라가고 있어요.

데이터 분석가, 프로젝트 매니저, HR 담당자, 재무 담당자 – 거의 모든 지식 노동자가 비슷한 상황에 놓여 있습니다. AI가 업무의 일부를 자동화할 수 있게 되면서, “이 사람은 자동화할 수 없는 어떤 가치를 제공하는가”라는 질문이 모든 직군에 던져지고 있는 거죠.

개발자의 불안이 “내 코딩 실력이 AI보다 못하면 어쩌지?”라면, 비개발자의 불안은 “AI가 내 업무를 더 잘하면 나는 뭘 하지?”에 가깝습니다. 형태는 다르지만, 본질은 같아요. “이 변화 속에서 나의 고유한 가치는 무엇인가?”

이 질문은 무겁지만, 피할 수 없는 질문입니다. 그리고 이 질문에 대한 답을 찾는 과정이 바로 이 책의 여정이에요.

한국의 풍경 – 우리는 어디쯤 서 있는가

글로벌 데이터만으로는 체감이 어려울 수 있으니, 한국 상황을 좀 더 구체적으로 보겠습니다. 우리가 매일 출근하는 그 회사, 그 사무실의 풍경이 어떻게 바뀌고 있는지를요.

카카오 이야기는 앞서 잠깐 언급했죠. AI 대체 가능 직무 신규 배정 중단. 이건 상징적인 사건이에요. 국내 대표 테크 기업이 공식적으로 “AI가 할 수 있는 일에는 사람을 더 뽑지 않겠다”고 선언한 거니까요. CTO가 직접 나서서 “AI 역량을 키우라”고 독려하고 있습니다. 이건 단순한 비용 절감이 아니라, 조직의 방향을 재설정하겠다는 선언이에요.

삼성전자의 SWITCH 사무국은 다른 방향에서 흥미로운 움직임을 보여줍니다. 이들은 기술적 전문성을 넘어선 소프트 스킬을 강조하고 있어요. AI 시대에 삼성이 원하는 인재는 코딩만 잘하는 사람이 아니라, 소통하고 협업하고 리더십을 발휘할 수 있는 사람이라는 메시지입니다. 국내 최대 기업이 이런 메시지를 보내고 있다는 건, 채용 시장의 기준 자체가 바뀌고 있다는 뜻이에요.

SK AX의 관점은 더 직접적입니다. 이들은 이렇게 말했어요.

“AI가 대신 만들어낸 결과물을 올바르게 이해하고 평가하며, 전체 시스템 안에서 의미 있게 연결할 수 있는 능력이 핵심이다.”

이 문장을 천천히 다시 읽어보세요. AI가 만든 결과물을 이해하고, 평가하고, 연결하는 능력. 이건 코딩 능력이 아닙니다. 판단력이에요. 맥락을 이해하는 힘이에요. 전체 그림을 볼 수 있는 시야예요. 그리고 이건 개발자에게만 해당되는 이야기가 아닙니다. 모든 직군에서 AI의 결과물을 평가하고 연결할 수 있는 사람이 필요해지고 있어요.

국내 채용 시장 전체를 보면, 트렌드는 명확합니다. “많이 뽑자”에서 “잘 뽑자”로. 양에서 질로의 전환이에요. 신입 채용의 문은 좁아지고 있지만, 뽑히는 사람에게 기대하는 역량의 수준은 올라가고 있어요.

커리어온뉴스가 정리한 ’2026년 한국 직업 트렌드 7대 핵심 역량’을 보면 이 방향이 더 선명해집니다. AI 리터러시, 데이터 해석력, 창의적 문제 해결, 디지털 커뮤니케이션, 자기 주도 학습력, 윤리적 판단력, 협업과 적응력. 이 7가지를 보세요. 순수한 기술 역량은 AI 리터러시와 데이터 해석력 정도이고, 나머지 5개는 전부 인간적 역량이에요. 한국의 직업 전문가들도 같은 방향을 가리키고 있는 겁니다.

이게 공정한 건지, 기존 세대는 그런 기대 없이 입사했는데 왜 지금 세대만 더 많은 걸 요구받아야 하는지 – 이런 불만도 자연스럽습니다. 공감해요. 하지만 현실은 현실이에요. 불만을 가진 채로 현실에 적응하는 것과, 현실을 부정하면서 준비를 미루는 것은 완전히 다른 결과를 가져옵니다.

한 가지 흥미로운 점을 덧붙이자면, 한국은 이 변화에서 오히려 유리한 위치에 있을 수 있어요. 한국의 개발자들은 빠른 변화에 익숙합니다. 스타트업 문화, 빠른 개발 사이클, 시장의 치열한 경쟁 – 이런 환경에서 단련된 적응력은 AI 시대에도 강점이 될 수 있습니다. 글로벌 테크 기업들이 “민첩성”과 “학습 속도”를 핵심 역량으로 꼽고 있는데, 한국 개발자들은 이미 그런 환경에서 살아남아 온 사람들이니까요.

문제는 방향이에요. 빠르게 움직이는 건 한국 개발자들이 잘하지만, “어디로” 움직여야 하는지가 명확해야 그 속도가 의미가 있습니다. 방향 없는 속도는 오히려 에너지 낭비가 될 수 있어요.

“나도 AI를 잘 쓰면 되는 건가요?”

여기서 많은 분이 떠올리시는 대응 전략이 있어요. “그러면 나도 AI를 잘 쓰면 되는 거 아냐?” 프롬프트 엔지니어링 강의 듣고, ChatGPT 능숙하게 다루고, Cursor 사용법 익히면 되는 거 아니냐고요.

맞기도 하고, 부족하기도 합니다.

AI를 잘 쓰는 것은 분명 중요해요. AI를 전혀 안 쓰는 사람과 잘 쓰는 사람 사이의 생산성 차이는 이미 눈에 보일 정도입니다. 같은 작업을 하는 데 한 사람은 3시간이 걸리고 다른 사람은 30분이 걸린다면, 그 차이를 무시하기는 어렵잖아요.

하지만 AI를 “잘 쓰는 것”만으로는 부족합니다. 왜냐하면 AI 사용법은 결국 모두가 배울 수 있는 것이거든요. 도구를 쓰는 법은 1개월이면 배울 수 있지만, 도구로 무엇을 만들 것인가를 판단하는 능력은 몇 년의 경험과 통찰이 필요합니다.

엑셀을 생각해보세요. 엑셀을 잘 다루는 건 좋은 일이지만, “엑셀을 잘 다린다”는 것만으로 차별화되기는 어렵잖아요. 모든 회사원이 어느 정도 엑셀을 다룰 수 있으니까요. 진짜 가치는 엑셀로 어떤 분석을 하느냐, 어떤 인사이트를 뽑아내느냐에 있습니다.

AI도 마찬가지예요. 조만간 AI 도구를 사용하는 것은 기본 소양이 될 거예요. 마치 지금 이메일을 못 쓰는 사무직이 없는 것처럼요. 그때 차별화되는 건 AI를 “어디에, 왜, 어떻게” 적용하느냐입니다. 그리고 그 판단에는 도메인 지식, 비즈니스 이해, 사용자 공감, 비판적 사고 같은 것들이 필요해요.

이건 6장과 7장에서 더 깊이 다루겠지만, 미리 한 가지만 말씀드릴게요. AI를 쓰는 법이 아니라, AI와 함께 일하는 법을 배워야 합니다. “도구를 다루는 기술”과 “도구를 활용해서 가치를 만드는 능력”은 전혀 다른 차원의 이야기거든요.

불안을 직시하되, 과장된 공포는 걷어내기

이 장에서 보여드린 숫자들을 정리해볼게요.

불안한 숫자들: - 22~25세 개발자 고용 20% 감소 - 상위 15개 테크 기업 신입 채용 25% 감소 - 카카오, AI 대체 가능 직무 신규 배정 중단

희망적인 숫자들: - 2033년까지 소프트웨어 엔지니어 17% 성장 전망 - CNN “일자리 소멸은 크게 과장” - 37%의 개발자가 AI로 커리어 기회 확장을 경험 - AI/ML, MLOps, 에이전틱 AI 엔지니어링 등 새로운 직군 급성장

핵심 통찰: - 65%의 개발자가 역할 재정의를 예상 - 일자리의 수가 아니라 성격이 바뀌고 있다

이 데이터들이 말해주는 건, 상황이 “전부 괜찮다”도 아니고 “전부 망했다”도 아니라는 겁니다. 변화는 실제로 일어나고 있고, 일부 영역은 축소되고 있지만, 새로운 영역은 확장되고 있어요.

문제는 이 전환의 속도입니다. 변화가 너무 빨라서 적응할 시간이 충분하지 않다고 느껴지는 거예요. 작년에 배운 기술이 올해 벌써 옛것이 된 느낌. 한 달 전에 익힌 도구가 이미 새 버전으로 바뀌어 있는 느낌. 그 가속감이 불안의 실체입니다.

그리고 이 가속감은 진짜예요. 과장이 아닙니다. AI 기술의 발전 속도는 정말로 전례 없이 빠릅니다. 하지만 한 가지 위안이 있다면, 이 속도에 압도당하는 건 여러분만이 아니라는 거예요. 업계의 거의 모든 사람이 같은 감정을 느끼고 있습니다. 시니어 개발자도, CTO도, CEO도요.

하지만 한 가지는 분명히 말씀드릴 수 있어요. 과장된 공포에 압도당해서 아무것도 하지 못하는 것이 가장 나쁜 선택지라는 것. “AI 때문에 다 끝났어”라고 체념하는 것도, “에이, 나한테는 해당 안 돼”라고 외면하는 것도 현명하지 않습니다.

필요한 건 냉정한 현실 인식과 구체적인 방향 감각입니다. 그리고 그 방향 감각을 잡기 위해 가장 먼저 해야 할 일은, 정확히 무엇이 사라지고 무엇이 남는지를 아는 것이에요.

EY(Ernst & Young)가 “AI 시대에 인간 역량을 중심으로 업무를 재설계하라”라는 보고서를 낸 적이 있어요. 이 보고서의 핵심 메시지는 단순합니다. AI가 업무를 대체하는 게 아니라, 업무를 재구성한다는 거예요. 같은 직무도 AI가 처리할 수 있는 부분과 사람만이 할 수 있는 부분으로 나뉘고, 사람의 시간은 후자에 집중됩니다. 이게 “일자리가 사라지는 것”과 “일자리의 성격이 바뀌는 것”의 차이입니다.

BCG도 비슷한 결론을 내렸어요. “AI는 대체(replace)하기보다 더 많은 일자리를 재편(reshape)할 것이다.” 대체와 재편의 차이가 중요합니다. 대체는 사라지는 거예요. 재편은 바뀌는 거예요. 그리고 바뀌는 것에는 적응할 수 있습니다. 사라지는 것에는 적응이 불가능하지만, 바뀌는 것에는 가능하거든요.

마무리 – 진짜 질문은 따로 있습니다

이 장을 시작할 때 후배의 카톡 이야기를 했었죠. “형, 저 이직 준비해야 할까요?”

저는 이렇게 답했습니다.

“이직이 문제가 아니야. 어딜 가든 같은 변화가 오고 있으니까. 중요한 건 네가 지금 하고 있는 일 중에서 뭐가 남고 뭐가 사라질지를 아는 거야. 그걸 알면 어디에 있든 준비할 수 있어.”

후배는 잠깐 침묵하더니 이렇게 물었어요. “그러면 뭐가 사라지는 건데요?”

좋은 질문입니다.

“당신의 자리는 안전한가?”라는 질문에 대한 대답은, 사실 당신이 앉아 있는 자리가 아니라 당신이 하고 있는 일의 성격에 달려 있습니다. 같은 “개발자”라는 직함을 가지고 있어도, 하고 있는 일의 성격에 따라 상황은 완전히 달라져요.

AI가 잘하는 일을 하고 있다면, 그 자리는 위태로울 수 있어요. AI가 못하는 일, 혹은 AI를 활용해서 더 잘할 수 있는 일을 하고 있다면, 그 자리의 가치는 오히려 올라갈 겁니다. 이건 개발자뿐만 아니라 기획자, 디자이너, 마케터, 모든 직군에 해당되는 이야기예요.

그렇다면 다음 질문은 자연스럽게 이겁니다.

“AI가 잘하는 일, 그래서 사라지고 있는 것들은 구체적으로 뭘까?”

다음 장에서는 이 질문에 데이터를 바탕으로 답해보겠습니다. 무엇이 사라지고 있는지를 정확히 알아야, 무엇을 남길 것인지도 결정할 수 있으니까요. 사라지는 것을 직시하는 건 두려운 일이지만, 눈을 감고 있는 것보다는 훨씬 현명한 선택입니다.

3장. AI가 가져간 것들

한번 이런 상상을 해보세요.

여러분이 5년차 백엔드 개발자입니다. 월요일 아침, 스프린트 백로그를 열어봅니다. 이번 주 태스크 목록이 쭉 나와 있어요.

• 사용자 프로필 API에 새 필드 추가
• 결제 모듈의 예외 처리 코드 보강
• 기존 API에 대한 유닛 테스트 보충
• 관리자 대시보드의 CRUD 화면 구현
• 레거시 코드의 변수명 정리 및 리팩토링

5개의 태스크를 보면서 어떤 느낌이 드시나요? 개발자라면 아마 이런 느낌일 거예요. “아, 또 이거.” 새로운 도전도, 창의적 판단도 필요 없는 – 해본 적 있는 패턴을 약간 변형해서 반복하는 일들. 손은 바쁜데 머리는 한가한 종류의 작업이에요.

비개발자 분들에게는 이렇게 비유할 수 있을 것 같아요. 매주 월요일 아침에 지난주 영업 실적을 엑셀로 정리해서 보고서 양식에 옮기는 일. 데이터 소스는 매번 같고, 양식도 같고, 손이 기억하는 대로 클릭하고 복사하고 붙이면 되는 그런 일. 숙련되었기 때문에 빠르게 할 수 있지만, 솔직히 이 일을 하면서 “나 전문가다”라는 자부심이 들지는 않잖아요.

바로 이런 일들이, 지금 AI가 가져가고 있는 것들입니다.

“가져간다”는 표현이 좀 과격하게 들릴 수 있어요. “도와준다”가 더 정확할 수도 있습니다. 하지만 솔직하게 말하는 편이 나을 것 같아요. AI가 이런 일들을 “도와주는” 수준을 넘어서, 사람보다 더 빠르고 때로는 더 정확하게 해내는 영역으로 진입하고 있거든요. 1분이면 해결되는 일을 사람이 30분 동안 하고 있으면, 그건 “도와주는” 수준이 아니라 “가져간” 거라고 봐야 합니다.

이 장에서는 AI가 구체적으로 무엇을 가져가고 있는지, 그리고 그 빈자리에 무엇이 들어오고 있는지를 살펴보려 합니다. 사라지는 것을 직시해야 남는 것도 보이거든요. 눈을 감으면 편하지만, 눈을 뜨고 있어야 방향을 잡을 수 있습니다.

보일러플레이트의 종말

개발자라면 누구나 경험해보셨을 겁니다. 새 프로젝트를 시작할 때, 혹은 새 기능을 추가할 때 가장 먼저 해야 하는 일. 프로젝트 구조를 만들고, 설정 파일을 작성하고, 기본적인 코드 뼈대를 잡는 일. 이른바 보일러플레이트(boilerplate) 코드를 작성하는 일이에요.

비개발자 분들에게 설명드리면, 보일러플레이트란 “본격적인 내용을 쓰기 전에 반드시 갖춰야 하는 형식적 구조”를 말해요. 편지를 쓸 때 “안녕하세요, OO님”으로 시작하고 “감사합니다”로 끝내야 하는 것처럼, 프로그램에도 이런 형식적 구조가 있습니다. 그걸 매번 처음부터 작성해야 해요. 내용은 아직 한 줄도 안 썼는데, 편지지 양식을 만드는 데 시간의 상당 부분을 쓰는 셈이죠.

지루하지만 필수적인 이 작업에 개발자들은 전통적으로 상당한 시간을 쏟아왔습니다. 새 API 엔드포인트 하나 만들려면, 라우터 설정하고, 컨트롤러 만들고, 서비스 레이어 뼈대 잡고, DTO(데이터 전송 객체) 정의하고, 에러 핸들링 패턴 적용하고, 로깅 추가하고… 비즈니스 로직 – 즉 실제로 가치를 만드는 코드 – 은 전체의 일부분인데, 나머지는 다 뻔한 패턴의 반복이에요.

경력 있는 개발자라면 이 말에 고개를 끄덕이실 거예요. “내가 하루에 짜는 코드 중에서 정말 창의적인 판단이 필요한 건 얼마나 될까?” 자문해보면, 솔직히 찜찜한 답이 나올 때가 있잖아요.

현재 개발자의 62%가 보일러플레이트 코드 생성에 AI를 사용하고 있습니다.

62%라는 숫자를 잠깐 생각해보세요. 10명의 개발자가 한 방에 앉아 있다면, 6명 이상이 이미 이 작업을 AI에게 맡기고 있다는 뜻이에요. 그리고 이건 “써보니 괜찮더라” 수준이 아니라, “이제 안 쓰면 오히려 비효율적이다” 수준에 가깝습니다. AI에게 “Spring Boot로 사용자 관리 API 뼈대를 만들어줘”라고 말하면, 몇 초 만에 프로젝트 구조, 설정 파일, 기본 CRUD 코드가 쏟아져 나오거든요. 사람이 30분 걸릴 작업을 30초에 해내는 거예요.

이미 안 쓰는 게 오히려 이상한 지경이 되고 있습니다. 마치 2024년에 자동 맞춤법 검사를 끄고 일일이 사전을 찾아보는 것처럼요. 할 수는 있지만, 왜 그래야 하죠?

비개발자 분들에게 더 친숙한 비유로 바꿔볼게요. 회사에서 보고서를 쓸 때, 매번 처음부터 빈 문서에서 시작하시나요? 아니죠. 템플릿을 가져와서 거기에 내용을 채우잖아요. AI가 보일러플레이트를 만들어주는 건, 그 템플릿을 AI가 자동으로 완성해주는 것과 비슷합니다. 다만 그 템플릿의 정교함과 완성도가 사람이 만든 것에 필적하거나 때로는 능가하는 수준이라는 게 차이점이에요.

단순 버그 수정의 자동화

두 번째로 AI가 빠르게 침투하고 있는 영역은 버그 수정입니다.

개발자의 58%가 버그 이해 및 수정에 AI를 활용하고 있어요.

여기서 “버그 수정”이라고 뭉뚱그려 말하면 오해가 생길 수 있습니다. 모든 버그가 같은 건 아니거든요. 버그에도 수준이 있어요. 마치 병원에 가는 이유가 감기부터 암까지 다양한 것처럼, 버그도 오타 수준부터 시스템을 마비시키는 수준까지 스펙트럼이 넓습니다.

한쪽 끝에는 오타 수준의 단순 버그가 있어요. 변수명을 잘못 쓴 거, null 체크를 빠뜨린 거, 반복문의 경계 조건이 하나 어긋난 거, 대소문자를 혼동한 거. 이런 건 패턴이 명확합니다. “여기서 이런 에러가 나면 십중팔구 이 원인이다”라는 공식이 있어요. AI는 수억 줄의 코드와 그에 대응하는 에러 패턴을 학습했기 때문에, 이런 종류의 버그를 매우 잘 잡아냅니다. 사실 사람보다 빠르고, 종종 더 정확해요. 사람은 피곤하면 눈에 뻔히 보이는 오타도 놓치지만, AI는 지치지 않으니까요.

다른 쪽 끝에는 시스템 전체의 상호작용에서 발생하는 복잡한 버그가 있어요. “이 버그는 A 서비스에서 B 서비스로 데이터를 보낼 때, 특정 시간대에, 특정 데이터 형식이, 특정 순서로 들어올 때만 발생한다.” 이런 류의 버그는 재현하는 것조차 어렵고, 원인을 찾으려면 시스템 전체의 맥락을 깊이 이해해야 합니다. 단서는 에러 로그 한 줄에 있지만, 그 한 줄을 해석하려면 시스템의 역사와 설계 의도까지 알아야 해요.

AI가 가져가고 있는 건 전자 – 패턴화할 수 있는 단순 버그 수정 – 입니다. 후자는 여전히 인간 개발자의 영역이에요. 그리고 흥미로운 건, 단순 버그 수정에서 해방되면 개발자는 더 복잡하고 근본적인 문제에 집중할 수 있게 된다는 점입니다.

솔직히 말해볼게요. 단순 버그 수정이 즐거웠던 적이 있으신가요? null pointer exception 뜨면 가슴이 뛰던가요? “undefined is not a function” 에러를 보면서 “오, 오늘도 보람찬 하루다”라고 느끼셨나요? 대부분은 “아, 또…” 하면서 한숨과 함께 처리하셨을 겁니다.

그 시간이 돌아온다면 뭘 하고 싶으세요? 아마 더 재미있고 도전적인 문제를 풀고 싶으실 거예요. “왜 우리 서비스의 전환율이 이 페이지에서 떨어지는 걸까?”, “이 시스템의 응답 속도를 10배 높이려면 아키텍처를 어떻게 바꿔야 할까?” 같은 문제 말이에요. AI가 바로 그런 문제에 집중할 시간을 만들어주고 있는 겁니다.

비개발자 분들도 비슷한 경험이 있으실 거예요. 매달 반복되는 보고서의 숫자 오류를 찾아 고치는 일. 데이터를 복사하다가 셀을 잘못 참조해서 수식이 깨진 걸 발견하는 일. 이런 “오류 수정” 작업에 쓰는 시간이 줄어든다면, 그 시간에 더 의미 있는 일을 할 수 있겠죠.

테스트 작성 – “귀찮지만 해야 하는 일”의 위탁

세 번째 영역은 테스트 코드 작성입니다. 57%의 개발자가 AI를 활용하고 있어요.

테스트 코드. 개발자 커뮤니티에서 테스트에 대해 이야기하면, 재미있는 현상이 벌어집니다. 모두가 “테스트는 중요하다”고 입을 모아 말하면서도, 실제로 충분한 테스트를 작성하는 팀은 많지 않아요. 왜 그럴까요?

이유는 간단합니다. 번거롭거든요.

함수 하나를 테스트하려면, 정상 입력에 대한 테스트, 경계값 테스트, 에러 입력에 대한 테스트, 예외 상황 테스트 등을 각각 작성해야 해요. 함수가 100개면 테스트도 수백 개가 필요합니다. 기능 하나 만드는 데 1시간이 걸렸는데, 테스트 짜는 데 2시간이 걸리기도 합니다. “이거 왜 하고 있지?” 싶은 순간이 한두 번이 아니에요.

그래서 많은 팀에서 테스트는 후순위로 밀립니다. “나중에 시간 나면 쓰자”가 되고, 그 “나중”은 영영 오지 않죠. 이런 경험, 개발자라면 한번쯤은 해보셨을 거예요.

그런데 AI는 불평 없이, 쉬지 않고, 빠르게 테스트를 만들어줍니다. 함수 하나 던져주면 엣지 케이스까지 고려한 테스트 코드를 뚝딱 생성해요. “이 함수가 null을 받으면 어떻게 되는지”, “빈 배열이 들어오면 어떻게 되는지”, “정수 최댓값이 들어오면 어떻게 되는지” – 사람이 깜빡하기 쉬운 케이스까지 챙겨줍니다. 완벽하지는 않지만, 초안으로는 충분한 수준이에요. 사람이 처음부터 작성하는 것보다 AI가 만든 초안을 수정하는 게 훨씬 빠르니까요.

비개발자 분들에게 설명드리자면, 테스트 코드라는 건 “내가 만든 프로그램이 제대로 작동하는지 확인하는 프로그램”이에요. 자동차를 만들고 나서 충돌 테스트, 제동 테스트, 내구성 테스트를 하는 것과 비슷합니다. 귀찮고 시간이 걸리지만, 안 하면 나중에 더 큰 문제가 생기죠. 고객이 쓰다가 앱이 죽어버리면 그때 가서 고치는 비용이 훨씬 크니까요.

AI 덕분에 이 “귀찮지만 해야 하는 일”의 부담이 크게 줄었습니다. 그리고 흥미로운 부수 효과가 있어요. 테스트 작성의 부담이 줄어드니, 오히려 테스트를 더 많이 작성하게 되었다는 거예요. 예전에는 “시간이 없어서” 스킵하던 테스트를, 이제는 AI에게 시키면 되니까 작성하게 된 겁니다. 소프트웨어의 전반적인 품질이 올라가는 선순환이 일어나고 있어요.

사라지는 것들의 공통분모

지금까지 AI가 가져가고 있는 세 가지 영역을 살펴봤습니다. 정리해볼게요.

• 보일러플레이트 코드 작성 (62%)
• 단순 버그 이해 및 수정 (58%)
• 테스트 코드 생성 (57%)

이 세 가지의 공통점이 보이시나요?

잠깐 생각해보시고요.

패턴이 명확하고, 반복적이며, 기존 데이터에서 학습 가능한 작업이라는 겁니다. 달리 말하면, “이전에 누군가가 수천 번, 수만 번 해본 적 있는 일”이에요.

AI는 본질적으로 패턴 매칭 기계입니다. 대량의 데이터에서 패턴을 학습하고, 새로운 입력에 대해 그 패턴을 적용하는 거예요. GitHub에 올라와 있는 수십억 줄의 코드를 학습했기 때문에, “이런 구조의 프로젝트에서는 보통 이런 보일러플레이트를 쓴다”, “이런 에러 메시지가 나오면 보통 이런 원인이다”, “이런 함수에는 보통 이런 테스트를 작성한다”를 알고 있는 거죠.

그래서 패턴화할 수 있는 작업에서는 놀라운 성능을 보이지만, 패턴이 없는 영역 – 전에 아무도 해보지 않은 일, 기존 데이터와 완전히 다른 맥락의 문제, 직관과 경험에 의존하는 판단 – 에서는 한계를 보입니다.

이걸 개발자의 일상으로 번역하면 이렇습니다.

사라지고 있는 것: - 코드를 타이핑하는 행위 그 자체 - 이미 알려진 패턴을 반복 적용하는 작업 - 명확한 정답이 있는 기계적 작업 - 이전 코드를 복사해서 약간 수정하는 일

사라지지 않는 것: - 무엇을 만들어야 하는지 결정하는 판단 - 여러 시스템 사이의 맥락을 이해하는 능력 - “거의 맞지만 완전하지 않은” 것을 완전하게 만드는 감각 - 비즈니스 요구사항을 기술적 설계로 번역하는 능력

비개발자 분들에게도 이건 동일하게 적용됩니다. 어떤 직종이든, “패턴화할 수 있는 반복 작업”은 AI로 넘어가고, “맥락과 판단이 필요한 고유 작업”은 사람에게 남아요.

마케터의 광고 문구 초안 작성은 AI가 할 수 있지만, 어떤 메시지가 우리 고객의 마음을 움직일지 판단하는 건 사람의 일이에요. 회계사의 정형화된 보고서 작성은 AI가 할 수 있지만, 숫자 뒤에 숨겨진 사업적 의미를 해석하는 건 사람의 일이에요. 디자이너의 레이아웃 초안은 AI가 만들 수 있지만, 그 디자인이 사용자에게 어떤 감정을 불러일으킬지 판단하는 건 사람의 일이에요.

패턴은 사라지고, 판단은 남습니다. 이것이 이 장의 핵심 메시지입니다.

“거의 맞지만 완전하지 않은” – 66%의 불만

여기서 잠깐, 중요한 반론을 하나 다루겠습니다.

“AI가 코드를 잘 짠다고? 실제로 써보면 영 아닌데요.”

이런 반응, 실제로 많이 들립니다. 개발자 커뮤니티에 가면 AI가 생성한 코드에 대한 불만이 넘쳐나요. “겉보기에는 그럴듯한데, 실제로 돌려보면 버그 투성이더라”, “간단한 건 잘하는데 조금만 복잡해지면 엉뚱한 코드를 내놓는다”, “AI가 짠 코드를 수정하느라 처음부터 내가 짜는 것보다 더 오래 걸렸다.”

그리고 이 반응에는 데이터가 뒷받침됩니다. 개발자의 66%가 AI의 가장 큰 불만으로 “거의 맞지만 완전하지 않은(almost right but not quite)” 솔루션을 꼽았어요.

3명 중 2명이 이런 불만을 가지고 있다는 건, 무시할 수 없는 숫자입니다. AI가 만든 코드를 보면, 언뜻 돌아가는 것 같은데 뭔가 이상해요. 변수명이 어색하거나, 에러 핸들링이 빠져 있거나, 성능이 좋지 않거나, 보안 허점이 있거나, 팀의 코딩 컨벤션을 따르지 않거나. 80점짜리 코드를 100점으로 만드는 데 생각보다 시간이 많이 들어요.

MIT Technology Review도 이 현상을 다루면서 “AI 코딩은 이제 어디에나 있다. 하지만 모든 사람이 납득하는 건 아니다(AI Coding Is Now Everywhere. But Not Everyone Is Convinced)”라는 제목의 기사를 냈어요. 확산은 되고 있지만, 만족도는 아직 따라가지 못하고 있다는 거죠.

이 불만이 말해주는 건 두 가지입니다.

첫째, AI는 아직 완벽하지 않습니다. 이건 분명한 사실이에요. AI가 생성한 코드를 그대로 프로덕션에 넣으면 문제가 생길 확률이 높습니다. 검토하고, 수정하고, 맥락에 맞게 조율하는 과정이 반드시 필요합니다. 이 과정을 건너뛰면 결국 더 큰 비용으로 돌아와요.

둘째, 그리고 이것이 더 중요한 포인트인데, “거의 맞지만 완전하지 않은 것”을 “완전하게” 만드는 능력이야말로 사람의 가치라는 겁니다. AI가 80점짜리를 만들어주면, 사람은 그걸 100점으로 끌어올리는 역할을 합니다. 이 20점의 차이가 프로덕션 환경에서는 결정적이에요. 80점짜리 코드는 데모에서는 작동하지만, 실제 서비스에서는 장애를 일으킬 수 있거든요.

비유하자면, AI는 훌륭한 초안 작성자예요. 빈 페이지를 앞에 두고 첫 문장을 쓰는 것, 구조를 잡는 것, 대략의 내용을 채우는 것 – 이런 일은 놀랍도록 잘합니다. 하지만 초안을 최종본으로 다듬는 편집자가 필요합니다. 어색한 표현을 고치고, 논리의 빈틈을 메우고, 독자에게 정말로 전달되는 글로 만드는 작업. 그 편집자가 바로 사람인 거죠.

그래서 “AI가 코드를 잘 못 짠다”라고 결론 내리는 것은 성급합니다. 정확히 말하면 “AI가 코드를 완벽하게 짜지는 못하지만, 시작점으로서는 놀라울 정도로 괜찮다”가 맞아요. 빈 페이지에서 시작하는 것과, 80점짜리 초안에서 시작하는 것은 완전히 다른 경험이거든요.

그리고 중요한 건, 이 시작점의 수준이 계속 올라가고 있다는 점입니다. 1년 전의 AI가 60점짜리를 만들었다면, 지금은 80점, 내년에는 90점이 될 수 있어요. 그 격차가 좁혀질수록, “사람이 메워야 할 20점”의 내용도 달라질 겁니다. 단순 수정에서 점점 더 고차원적 판단으로요.

“완전 위임”은 아직 먼 이야기

이와 관련해서 한 가지 더 짚어야 할 사실이 있습니다. 감정적으로 과잉 반응하지 않기 위해서 꼭 알아둬야 할 숫자예요.

1장에서 잠깐 언급했던 데이터를 다시 볼게요. 개발자의 60%가 AI를 사용하지만, AI에게 완전히 위임할 수 있는 작업은 0에서 20%에 불과합니다.

이 숫자를 찬찬히 뜯어보면, 현재 AI의 위치가 정확히 보입니다.

“사용한다”와 “맡긴다”는 완전히 다른 차원의 이야기입니다. 번역기를 사용하는 것과, 번역가를 고용해서 모든 걸 맡기는 건 다르잖아요. AI를 사용하는 60%의 개발자 중 대부분은 AI가 만든 결과물을 검토하고, 수정하고, 맥락에 맞게 조율하고 있어요. AI가 독립적으로 일하는 게 아니라, 사람과 짝을 이루어 일하는 거죠.

자율주행차에 비유하면 더 명확해집니다. 현재의 AI 코딩 도구는 완전 자율주행(Level 5)이 아니라 운전 보조(Level 2~3) 수준이에요. 차선 유지, 앞차와의 거리 유지, 자동 감속 같은 건 잘하지만, 운전석에 사람이 앉아 있어야 합니다. 갑자기 뛰어나오는 어린이, 공사 구간의 임시 차선 변경, 경찰의 수신호 – 이런 예외적 상황에서는 여전히 사람의 판단이 필요하거든요.

이 사실이 중요한 이유는, “AI가 개발자를 대체한다”라는 공포를 적절한 크기로 줄여주기 때문입니다. 현재 시점에서 AI는 조수에 가깝지, 후임자가 아닙니다. 아주 똑똑하고 빠른 조수지만, 혼자서 판단하고 책임질 수 있는 존재는 아직 아니에요.

물론 “아직”이라는 단어가 붙습니다. 기술은 계속 발전하고 있고, 완전 위임의 범위는 점점 넓어질 거예요. 자율주행차도 Level 2에서 시작했지만 결국 Level 5를 향해 나아가고 있잖아요. AI 코딩도 마찬가지일 겁니다.

그렇다고 안심하고 현재에 안주하라는 뜻은 아닙니다. “아직”이라는 시간 안에 준비해야 한다는 뜻이에요. Level 5가 오기 전에, “AI가 완전히 위임받더라도 사람만이 할 수 있는 일”이 무엇인지를 파악하고 그쪽으로 역량을 키워야 합니다. 그 시간이 3년일지, 5년일지, 10년일지는 아무도 모릅니다. 하지만 그 시간이 올 거라는 건 거의 확실합니다.

빈자리에 들어오는 것들

그렇다면 AI가 가져간 시간은 어디로 가고 있을까요? 보일러플레이트 안 짜도 되고, 단순 버그 AI가 잡아주고, 테스트 초안 AI가 만들어주면, 그 시간에 개발자들은 뭘 하고 있을까요?

앞에서 잠깐 언급했지만, 조금 더 구체적으로 살펴보겠습니다.

첫째, 아키텍처 설계. 개별 코드를 짜는 것에서 전체 시스템을 설계하는 것으로 무게 중심이 이동하고 있어요. 벽돌을 쌓는 일에서 건물을 설계하는 일로, 라고 앞 장에서 비유했었죠.

구체적으로 어떤 걸까요? 서비스를 모놀리스로 갈지 마이크로서비스로 갈지 결정하는 것, 데이터베이스를 어떻게 설계할지, 캐싱 전략은 무엇으로 할지, 서비스 간 통신은 동기로 할지 비동기로 할지 – 이런 판단들이에요. 이 판단들은 코드 한 줄 한 줄보다 훨씬 큰 영향을 미칩니다. 아키텍처를 잘못 잡으면 코드를 아무리 잘 짜도 서비스가 흔들리거든요.

비개발자 분들에게 비유하면, 이건 건물을 지을 때 벽돌을 어디에 놓을지 결정하는 게 아니라, 건물의 전체 구조를 설계하는 일과 같아요. 기둥은 몇 개 세울지, 엘리베이터는 어디에 놓을지, 비상계단은 어떻게 연결할지. 벽돌 하나하나는 AI가 놓아줄 수 있지만, 이 건물이 지진에 견디고 사람들이 편하게 쓸 수 있도록 전체 구조를 잡는 건 건축가의 일이잖아요.

둘째, 시스템 통합. 현대의 소프트웨어는 수십, 수백 개의 서비스와 도구가 연결되어 작동합니다. 결제 시스템, 인증 시스템, 알림 시스템, 분석 시스템, 외부 API – 이 모든 것이 유기적으로 연결되어야 해요. AI가 개별 모듈의 코드를 잘 짜준다 해도, 이 모듈들이 서로 잘 어울려 돌아가게 만드는 건 다른 차원의 문제입니다.

마치 오케스트라에서 각 악기 연주자가 훌륭해도 지휘자 없으면 음악이 안 되는 것처럼요. 바이올린 파트를 AI가 완벽하게 연주하고, 첼로 파트도 AI가 완벽하게 연주한다 해도, 두 파트가 조화롭게 어울리려면 전체를 조율하는 누군가가 필요합니다. 그 역할이 점점 개발자의 핵심 업무가 되고 있어요.

셋째, AI 기반 의사결정. 이건 완전히 새로운 영역입니다. AI의 출력을 평가하고, 신뢰 여부를 판단하고, 비즈니스 맥락에 맞게 조율하는 일. AI가 세 가지 구현 방법을 제안했을 때, “우리 서비스의 현재 상황과 향후 계획을 고려하면 두 번째가 맞다”고 판단하는 건 AI가 할 수 없는 일이에요. 왜냐하면 그 판단에는 “우리 회사가 어디로 가고 있는지”, “우리 사용자가 어떤 사람들인지”, “지금 팀에 어떤 역량이 있는지” 같은 맥락 정보가 필요하고, 이건 코드에 적혀 있지 않으니까요.

이걸 보면 재미있는 역설이 드러납니다. AI가 가져간 것들은 대부분 “실행”에 해당하는 일이고, 빈자리에 들어오는 것들은 “판단”에 해당하는 일이라는 겁니다. 코드를 타이핑하는 실행력에서, 무엇을 어떻게 만들 것인지 판단하는 의사결정력으로, 개발자의 핵심 역량이 이동하고 있어요.

이건 개발자에게 위협일 수도 있고 기회일 수도 있습니다. 실행력에 강점이 있던 사람 – 타이핑이 빠르고, 문법에 능숙하고, 코드를 많이 칠 수 있는 사람 – 에게는 적응이 필요한 시기입니다. 반면 판단력과 시야에 강점이 있던 사람 – 전체 그림을 잘 보고, 비즈니스를 이해하고, 복잡한 문제를 분해할 수 있는 사람 – 에게는 빛을 발할 시기예요.

비개발자의 “사라지는 것들”

개발자만 이야기하면 이 책의 독자 절반을 놓치는 거겠죠. 비개발자에게도 AI가 가져가고 있는 것들이 있습니다. 그리고 그 목록은 놀라울 정도로 개발자의 경우와 비슷해요.

기획자의 경우를 생각해보세요. 요구사항 문서의 초안 작성, 경쟁사 분석 자료 정리, 사용자 스토리 템플릿 작성 – 이런 일을 AI가 빠르게 해냅니다. 기획자가 3시간 걸려서 정리하던 경쟁사 분석을, AI가 15분 만에 비슷한 수준으로 만들어내요.

마케터의 경우는 더 직접적입니다. 광고 카피 초안, SNS 게시물, 이메일 뉴스레터 템플릿, A/B 테스트 문구 변형 – 이런 “글쓰기” 업무의 상당 부분을 AI가 처리할 수 있습니다.

디자이너의 경우, 간단한 아이콘 제작, 배너 사이즈 변형, 목업 제작, 프레젠테이션 레이아웃 같은 작업을 AI가 빠르게 수행합니다.

데이터 분석가의 경우, 정형화된 보고서 생성, 기본 통계 분석, 데이터 시각화 초안 같은 일이 자동화되고 있어요.

패턴이 보이시죠? 모든 직군에서 “정형화된 초안 작성”과 “패턴이 명확한 반복 작업”이 AI로 넘어가고 있어요. 그리고 모든 직군에서 남는 것은 같습니다. “왜 이 일을 해야 하는지 판단하고, AI가 만든 결과물을 평가하고, 맥락에 맞게 조율하는 능력.”

감정적 과잉 반응에 대한 경계

이쯤에서 한 가지 당부를 드리고 싶어요.

“사라지는 것들”을 이야기하면, 두 가지 극단적인 반응이 나오곤 합니다.

하나는 패닉입니다. “다 사라진다고? 나도 사라지는 거 아냐?” 모든 변화를 위협으로 해석하고, 극도의 불안 속에서 이것저것 닥치는 대로 배우려 하거나, 아예 체념해버리는 반응이에요. SNS에서 “AI 때문에 개발자 끝났다”는 글을 보고 밤잠을 설치는 분들이 있어요. 뉴스 헤드라인만 보고 “나도 빨리 뭔가 해야 해”라면서 무작정 프롬프트 엔지니어링 강의를 결제하는 분들도 있고요.

다른 하나는 부정입니다. “에이, 과장이지. AI가 만드는 코드 수준 못 봤어? 내가 짜는 게 훨씬 나아.” 변화의 크기를 축소하고, 현재의 역량에 안주하는 반응이에요. 커뮤니티에서 “AI 코딩은 장난감 수준”이라면서 자기 확신으로 무장하는 분들을 볼 수 있습니다.

두 반응 모두 자연스러운 감정의 표현이지만, 두 반응 모두 현명하지 않습니다.

패닉은 에너지를 낭비하게 만들어요. 방향 없이 이것저것 시도하다가 아무것도 제대로 하지 못하는 결과로 이어지기 쉽습니다. 부정은 준비의 기회를 놓치게 만들어요. 변화가 눈앞에 와도 “나는 괜찮아”라고 믿다가, 정작 대응해야 할 때 준비가 안 되어 있는 상태가 될 수 있습니다.

필요한 건 냉정한 중간 지대예요.

사라지는 것은 실제로 사라지고 있습니다. 부정할 필요 없어요. 하지만 모든 것이 사라지는 건 아닙니다. 패닉에 빠질 필요도 없어요.

AI가 보일러플레이트 코딩을 가져가고 있다고요? 네, 맞습니다. 그런데 솔직히, 그 일이 즐거우셨나요? 월요일 아침에 “오늘은 보일러플레이트 짜는 날이야!”라면서 출근한 적이 있으신가요? 그 일에서 해방되는 게 정말 슬픈 일인가요?

AI가 단순 버그 수정을 대신 해준다고요? 네, 맞습니다. 그런데 그 시간에 더 도전적인 문제를 풀 수 있다면, 더 흥미로운 일을 할 수 있다면, 그게 오히려 좋은 일 아닌가요?

AI가 테스트 코드 초안을 작성해준다고요? 네, 맞습니다. 그 덕분에 테스트를 더 많이 작성하게 되고, 소프트웨어 품질이 올라간다면, 이건 모두에게 좋은 일 아닌가요?

사라지는 것에 집착하면 새로 생기는 것이 보이지 않습니다. 그리고 새로 생기는 것은, 사실 사라지는 것보다 훨씬 흥미롭고 가치 있는 경우가 많아요. 지루한 반복 작업에서 해방되어 더 의미 있는 일에 집중할 수 있다면, 이건 위기가 아니라 기회일 수 있습니다.

물론 “기회”라는 말이 가볍게 들리실 수 있어요. 당장 취업이 안 되거나, 내 업무가 줄어들고 있는 사람에게 “기회야!”라고 하면 공허하게 들리잖아요. 이해합니다. 하지만 적어도 방향은 맞아요. 사라지는 것을 붙들고 있기보다, 새로 생기는 것 쪽으로 움직이는 게 현명한 선택이라는 건 확실합니다.

전작에서 말한 “코드 외의 역량”이 현실이 되다

제가 전작 “코드 너머, 회사보다 오래 남을 개발자”에서 “코드 외의 역량”을 이야기했을 때, 솔직히 약간 이상주의적으로 들렸을 수 있어요. “소프트 스킬이 중요하다니, 맞는 말이긴 한데… 결국 코딩 잘하는 사람이 인정받지 않나?” 하는 생각을 하신 분도 계셨을 겁니다. 전작의 추천사에서도 “코딩 실력만으로는 차별화되기 어려운 시대”라는 말이 있었는데, 그때는 미래형이었어요.

그런데 지금 벌어지고 있는 일을 보세요. 코딩의 상당 부분을 AI가 해내는 시대가 되면서, “코드 외의 역량”은 더 이상 이상주의적 주장이 아니라 생존의 조건이 되어가고 있습니다. 미래형이 현재형이 된 거예요.

전작에서는 “코드 외의 역량”을 주로 소프트 스킬 – 경청, 질문, 회의 스킬, 협업, 리더십 – 로 정의했어요. 이번 장에서 본 것처럼, 이제는 그 범위가 더 넓어졌습니다. 코드 역량 자체가 재편되고 있거든요.

“코드를 잘 짜는 것”의 정의가 바뀌고 있어요.

예전에는: 효율적인 알고리즘을 구현하고, 깔끔한 코드를 작성하고, 복잡한 로직을 빠르게 타이핑하는 것.

지금은: AI가 생성한 코드를 평가하고, 시스템 전체의 맥락에서 올바른 설계를 판단하고, “거의 맞지만 완전하지 않은” 것을 완전하게 만들고, 비즈니스 요구사항을 기술적 결정으로 번역하는 것.

개발자의 핵심 역량이 “작성자”에서 “설계자이자 평가자”로 이동하고 있는 겁니다. 글을 쓰는 능력에서 글을 편집하고 방향을 잡는 능력으로. 악기를 연주하는 능력에서 오케스트라를 지휘하는 능력으로.

비개발자도 마찬가지예요. 보고서를 쓰는 능력에서 보고서의 방향을 잡고 품질을 판단하는 능력으로. 디자인 시안을 만드는 능력에서 디자인의 의도를 설명하고 비즈니스 목표와 연결하는 능력으로. “실행자”에서 “판단자”로의 이동은 모든 직군에서 일어나고 있습니다.

마무리 – 빈자리를 어떻게 채울 것인가

이 장에서 살펴본 것을 한 문장으로 요약하면 이렇습니다.

AI는 패턴화할 수 있는 반복 작업을 가져가고 있으며, 그 빈자리에는 판단, 설계, 맥락 이해가 들어오고 있다.

보일러플레이트는 AI가 짜고, 단순 버그는 AI가 잡고, 테스트 초안은 AI가 만듭니다. 하지만 무엇을 만들 것인지 결정하고, 시스템을 설계하고, AI의 결과물을 평가하고, 전체를 조율하는 일은 여전히 사람의 몫입니다. 그리고 이 사람의 몫이 차지하는 비중과 가치가 점점 올라가고 있어요.

사라지는 것을 알았으니, 이제 남는 것을 알아야 합니다.

그렇다면 자연스럽게 다음 질문이 떠오릅니다.

“AI가 가져갈 수 없는 것은 무엇인가? 아무리 기술이 발전해도 사람만이 할 수 있는 일의 정체는 뭘까?”

다음 장에서는 이 질문에 글로벌 연구와 데이터를 바탕으로 답해보겠습니다. 그리고 흥미로운 사실 하나를 미리 말씀드릴게요. AI가 가져갈 수 없는 것들 중 상당수는, 여러분이 이미 가지고 있지만 과소평가하고 있었을 것들입니다. 코드를 짜는 능력보다 사소하다고 여겼던, 하지만 사실은 훨씬 더 희소하고 가치 있는 그것들에 대해 이야기해보겠습니다.

4장. AI가 가져갈 수 없는 것들

혹시 이런 생각을 해보신 적 있나요? AI가 코드를 짜고, 보고서를 쓰고, 이미지를 만들고, 심지어 음악까지 작곡하는 걸 보면서 “그러면 대체 사람이 할 일이 뭐가 남는 거지?”라고요. 3장에서 우리는 AI가 가져간 것들의 목록을 직시했습니다. 보일러플레이트 코딩의 62%, 단순 버그 수정의 58%, 반복적인 테스트 작성의 57%. 숫자로 확인하니 더 실감이 나셨을 겁니다.

그 목록을 보고 나면 당연히 불안해질 수 있습니다. 저도 처음 그 데이터를 봤을 때 솔직히 마음이 무거웠거든요.

하지만 잠깐, 시선을 돌려볼까요? 사라진 것들의 빈자리를 바라보는 대신, 아무리 기술이 발전해도 꿈쩍도 하지 않는 것들을 한번 살펴보겠습니다. 3장이 “무엇이 사라지는가”에 대한 이야기였다면, 이번 장은 “무엇이 남는가”에 대한 이야기입니다. 그리고 그 남는 것들이 놀랍게도 여러분이 이미 가지고 있는 것들이라는 사실을 확인하게 될 겁니다. 두렵기만 했던 풍경이, 이번 장을 지나고 나면 좀 다르게 보일 수 있기를 바랍니다.

기계가 흉내 낼 수 없는 영역

한 가지 장면을 떠올려보세요. 여러분이 새로운 서비스를 기획하는 회의에 참석했다고 가정합니다. AI에게 “사용자가 좋아할 만한 앱 아이디어를 열 개만 내줘”라고 시키면 정말 그럴듯한 목록이 나옵니다. 트렌드를 분석하고, 시장 데이터를 종합하고, 경쟁사 사례까지 참고한 결과물이죠. 깔끔하게 정리된 열 개의 아이디어. 발표 자료에 넣으면 꽤 그럴듯해 보일 겁니다.

그런데 그 목록을 받아든 순간, 뭔가 찜찜한 느낌이 들지 않으신가요?

그 아이디어들은 하나같이 “어디서 본 듯한” 것들입니다. 기존 서비스의 변형이거나, 이미 성공한 패턴의 조합이거나, 데이터가 말해주는 “평균적으로 괜찮은” 방향이에요. 나쁘지는 않습니다. 하지만 세상을 뒤집어놓은 혁신 중에 “평균적으로 괜찮은” 아이디어에서 시작된 것이 얼마나 될까요? 아이폰이 처음 나왔을 때 시장 조사 데이터가 “터치스크린 전면 스마트폰”을 가리키고 있었을까요? 아마 아닐 겁니다. 그 시점의 데이터는 물리 키보드가 달린 블랙베리형 디바이스를 가리키고 있었을 거예요.

AI는 기존 패턴을 기반으로 콘텐츠를 생성합니다. 이것은 AI의 본질적인 작동 방식이에요. 학습 데이터에 있는 패턴을 찾아내고, 그 패턴을 재조합하는 것이죠. 이 능력은 정말 대단합니다. 수십억 개의 문서에서 패턴을 찾아 인간보다 빠르고 정확하게 재조합할 수 있으니까요. 하지만 한 가지 근본적인 한계가 있습니다. 어떤 데이터셋에도 매핑되지 않는 방식으로 아이디어를 연결하는 것, 즉 진정한 의미의 창의적 도약은 AI의 영역 밖에 있다는 겁니다.

현실의 맥락, 문화적 통찰, 감정적 의미. 이런 것들에 뿌리를 둔 파괴적 아이디어는 인간의 경험에서만 나옵니다. 스티브 잡스가 서체 수업에서 얻은 영감을 컴퓨터 디자인에 연결한 것처럼, 전혀 관계없어 보이는 경험들 사이에서 새로운 의미를 발견하는 능력. 이것이 바로 인간 고유의 창의성입니다.

AI가 만들어낸 결과물이 “좋은 평균”에 머무는 이유가 있습니다. AI는 학습 데이터의 분포 안에서 최적의 답을 찾도록 설계되어 있거든요. 하지만 혁신은 그 분포를 벗어나는 곳에서 일어납니다. 데이터가 가리키는 방향이 아니라, 데이터에 없는 방향으로 뛰어드는 것. 그것이 진짜 창의성이에요. AI는 과거의 패턴에서 미래를 예측하지만, 진짜 혁신은 과거의 패턴을 깨뜨리는 데서 시작합니다.

여기서 한 가지 오해를 풀고 넘어가야 할 것 같아요. “창의성”이라고 하면 예술가나 천재 발명가를 떠올리기 쉽습니다. 하지만 제가 말하는 창의성은 그런 거창한 것이 아닙니다. 매일 아침 출근해서 “이 프로세스, 좀 더 나은 방법이 없을까?”라고 생각하는 것. 고객 불만 전화를 받고 “이 불만의 진짜 원인이 뭘까?”를 궁금해하는 것. 전혀 다른 산업의 사례를 보고 “이걸 우리 업무에 적용하면 어떨까?”라고 연결짓는 것. 이 모든 것이 AI가 흉내 낼 수 없는 창의성입니다. 데이터에 없는 연결고리를 만들어내는 일이니까요.

“진짜 문제가 뭔데요?”라고 물을 수 있는 힘

두 번째로 AI가 넘볼 수 없는 영역이 있습니다. 바로 비판적 사고, 그중에서도 “올바른 질문을 던지는 능력”입니다.

이런 상황을 생각해보세요. 누군가가 “로그인 화면의 반응 속도를 개선해주세요”라고 요청합니다. AI는 이 요청을 받으면 즉시 코드 최적화에 들어갈 겁니다. 캐싱을 적용하고, 쿼리를 개선하고, 불필요한 렌더링을 제거하겠죠. 아마 몇 분 안에 꽤 괜찮은 최적화 코드를 내놓을 거예요. 기술적으로는 완벽한 답입니다.

하지만 경험 많은 엔지니어라면 이렇게 물을 수 있습니다. “잠깐, 사용자들이 정말 로그인 속도 때문에 떠나는 건가요? 혹시 로그인 자체를 너무 자주 요구하는 게 문제는 아닐까요? 아니면 소셜 로그인 옵션이 없어서 매번 비밀번호를 입력하는 게 귀찮은 건 아닐까요?”

이것이 비판적 사고의 핵심입니다. “실제 문제가 무엇인가”를 정의하는 능력이에요. AI는 주어진 문제를 놀라울 정도로 잘 풉니다. 하지만 “이것이 풀어야 할 진짜 문제인가?”라는 질문은 던지지 못합니다. 올바른 질문을 던지려면 기초 지식뿐 아니라 맥락을 이해해야 하고, 훈련 데이터에 존재하지 않는 패턴을 인식할 수 있어야 합니다.

저도 현업에서 수없이 경험한 일입니다. 기술적으로 완벽하게 해결한 문제가 사실은 풀어야 할 문제가 아니었던 경우. 그때의 허탈함이란, 정말 난감하죠. 코드는 완벽한데 방향이 틀렸다니요. 며칠을 밤새워 최적화했는데, 정작 사용자가 원한 건 그게 아니었다는 걸 알았을 때의 그 기분. 개발자라면 한 번쯤은 겪어보셨을 거예요.

AI 시대에 이 능력은 더욱 결정적입니다. 왜냐하면 AI가 문제를 빠르게 풀어주는 만큼, 잘못된 문제를 풀 때의 낭비도 기하급수적으로 커지기 때문이에요. 과거에는 잘못된 방향으로 코딩하다가도 중간에 “이상한데?”라고 느끼고 돌아올 수 있었습니다. 코딩 속도가 느렸으니까요. 하지만 AI가 순식간에 코드를 쏟아내는 환경에서는, 방향이 틀렸다는 걸 깨닫기도 전에 이미 거대한 산출물이 만들어져 있을 수 있어요. “어떤 문제를 풀 것인가”를 결정하는 사람의 가치가 기하급수적으로 올라가는 이유입니다.

비판적 사고에는 또 하나의 중요한 측면이 있어요. AI의 출력물을 그대로 받아들이지 않고 검증하는 능력입니다. 개발자의 66%가 AI 솔루션에 대해 “거의 맞지만 완전하지 않다”고 느낀다는 조사 결과를 3장에서 살펴봤죠. 이 “거의 맞지만 완전하지 않은” 부분을 잡아내려면, 해당 도메인에 대한 깊은 이해와 비판적 시각이 필요합니다. AI가 내놓은 답이 그럴듯해 보일수록, 그것을 의심하고 검증하는 능력이 더욱 중요해지는 역설적인 상황인 셈이죠.

공감은 시뮬레이션할 수 없습니다

세 번째 영역은 어쩌면 가장 인간다운 것입니다. 바로 공감이에요.

AI 챗봇이 “고객님의 불편에 공감합니다”라고 말하는 것을 우리는 이미 익숙하게 접하고 있습니다. 그리고 솔직히 말하면, 꽤 그럴듯하게 느껴질 때도 있어요. AI가 감정적 단서를 인식하고 적절한 반응을 생성하는 능력은 분명 인상적입니다. 화가 난 고객의 메시지를 읽고, 사과의 말을 건네고, 해결책을 제시하는 과정. 형식적으로는 나무랄 데가 없어 보입니다.

하지만 한번 생각해보세요. 밤새 장애 대응을 하고 지쳐 있는 동료에게 “수고하셨어요”라고 말하는 것과, AI가 같은 문장을 출력하는 것 사이에는 건널 수 없는 간극이 있습니다. 왜 그럴까요? 인간의 공감은 생물학적, 사회적 인지에 깊이 뿌리를 둔 능력이기 때문입니다. 내가 비슷한 상황에서 느꼈던 좌절감, 피곤함, 그리고 그럼에도 끝까지 해냈을 때의 안도감. 이런 경험의 축적이 진정한 공감을 가능하게 하는 거죠.

새벽 3시에 서버가 터졌을 때의 그 심장이 철렁 내려앉는 느낌. 원인을 찾았을 때의 안도와 동시에 밀려오는 피로. 그리고 옆에서 같이 모니터를 들여다보며 “일단 커피 한 잔 하고 다시 보자”고 말해주는 동료의 따뜻함. 이런 것들은 경험해본 사람만 진짜로 이해할 수 있어요. AI가 “장애 대응 과정이 힘드셨겠습니다”라고 아무리 정교하게 말해도, 그 말의 무게는 직접 새벽 장애를 겪어본 사람이 하는 “나도 알아, 진짜 힘들지”와는 본질적으로 다릅니다.

AI가 감정 단서를 인식하는 것과, 인간이 감정을 진정으로 이해하고 공유하는 것은 본질적으로 다른 일입니다. 이것은 기술의 발전으로 해결될 문제가 아니에요. 공감의 뿌리 자체가 “경험하는 존재”에게만 주어진 것이기 때문입니다.

그리고 이 공감 능력은 소프트웨어 개발에서도 핵심적입니다. 사용자가 왜 이 버튼을 누르지 못하는지, 왜 이 화면에서 당황하는지, 왜 이 기능을 원하는지. 이런 것들을 데이터만으로는 온전히 파악할 수 없어요. 클릭률, 이탈률, 체류 시간 같은 숫자는 “무슨 일이 일어나고 있는지”를 알려주지만, “왜 그런 일이 일어나는지”는 알려주지 않거든요. 사용자의 맥락 속으로 들어가서 그 사람의 눈으로 세상을 보는 능력. 이것이 좋은 제품과 그저 그런 제품을 가르는 차이입니다.

비개발자 분들도 마찬가지입니다. 고객의 불만 전화를 받을 때, 데이터 리포트를 해석할 때, 새로운 서비스를 기획할 때. 상대방의 입장에서 생각하는 능력, 그 사람의 맥락을 이해하는 능력은 어떤 직무에서든 핵심 경쟁력이에요. AI가 데이터를 분석해줄 수는 있지만, 그 데이터 뒤에 있는 사람의 마음을 읽는 것은 오직 사람만이 할 수 있습니다.

윤리적 판단이라는 최후의 보루

네 번째 영역은 점점 더 중요해지고 있는 윤리적 판단입니다.

AI가 추천 알고리즘을 만들었는데, 그 알고리즘이 특정 집단에 불리하게 작동한다면 어떻게 해야 할까요? 기술적으로는 최적화가 잘 된 모델입니다. 성능 지표도 훌륭하고요. 목표 함수를 완벽하게 달성하고 있어요. 하지만 “이것이 올바른가?”라는 질문에 AI는 답할 수 없습니다.

윤리적 판단은 살아온 경험, 감정, 추론, 도덕적 성찰이 결합된 영역이에요. 효율성과 공정성이 충돌할 때, 단기 이익과 장기적 신뢰가 갈등할 때, 기술적으로 가능한 것과 사회적으로 바람직한 것 사이에서 균형을 잡아야 할 때. 이런 판단은 인간만이 내릴 수 있고, 또 인간이 내려야만 합니다.

구체적인 예를 들어보겠습니다. 여러분이 온라인 쇼핑몰의 개발자라고 해볼까요. AI가 분석한 결과, 특정 디자인 패턴을 적용하면 결제 전환율이 15% 올라간다는 제안을 합니다. 그런데 자세히 살펴보니, 그 패턴은 사용자가 취소 버튼을 찾기 어렵게 만드는 일종의 다크 패턴이에요. 전환율은 올라가겠지만, 사용자의 선택권을 침해하는 설계입니다. AI는 “전환율이 올라간다”는 지표만 봅니다. 하지만 “이것이 사용자를 기만하는 건 아닌가?”, “장기적으로 브랜드 신뢰에 어떤 영향을 미칠까?”, “우리가 이런 회사이고 싶은가?”라는 질문은 사람이 던져야 해요.

혹시 이런 생각이 드실 수 있어요. “윤리적 판단이라니, 그건 경영진이나 법무팀의 일 아닌가요?” 하지만 현실에서 윤리적 판단은 매 순간의 작은 결정에서 시작됩니다. 사용자 데이터를 어디까지 수집할 것인가, 접근성을 어느 수준까지 보장할 것인가, AI의 추천 결과를 어느 수준까지 신뢰할 것인가. 이런 결정들이 모여서 기술이 세상에 미치는 영향을 결정짓습니다. 그리고 이 결정의 최전선에 있는 사람이 바로 제품을 만들고 운영하는 여러분이에요.

AI가 더 많은 영역에 관여할수록, 윤리적 판단의 중요성은 높아집니다. 의료 AI가 진단을 내릴 때, 자율주행차가 위험 상황에서 판단을 내릴 때, 채용 AI가 지원자를 평가할 때. 이 모든 상황에서 최종적인 윤리적 판단은 인간이 해야 합니다. 이것은 기술적 한계가 아니라, 책임의 문제입니다.

Microsoft가 말하는 5C, 그리고 세계가 합의한 것들

이렇게 인간 고유의 역량을 이야기하면 “그건 개인적인 생각 아닌가요?”라는 반문이 나올 수 있습니다. 충분히 이해합니다. 그래서 데이터를 한번 살펴보겠습니다. 개인의 의견이 아니라, 세계적인 기관들이 연구와 분석을 통해 도달한 결론이거든요.

Microsoft는 AI 시대의 성공을 위한 필수 인간 역량으로 ’5C 프레임워크’를 제시했습니다.

첫째, 호기심(Curiosity)입니다. 끊임없이 “왜?”라고 묻는 태도. AI가 답을 쏟아내는 시대에 오히려 더 중요해진 역량이에요. 좋은 답은 좋은 질문에서 나오니까요. 답이 쉽게 나오는 세상에서, 좋은 질문을 던지는 사람의 가치는 올라갈 수밖에 없습니다.

둘째, 비판적 사고(Critical Thinking)입니다. 앞서 이야기한 것처럼, AI의 출력물을 그대로 받아들이지 않고 검증하고 판단하는 능력입니다. AI가 “거의 맞지만 완전하지 않은” 답을 내놓을 때, 그 빈틈을 잡아낼 수 있는 사람이 필요합니다.

셋째, 창의성(Creativity)입니다. 기존에 없던 연결고리를 만들어내는 힘. AI가 기존 패턴을 재조합한다면, 인간은 패턴 자체를 새로 만들 수 있습니다. 데이터에 없는 도약, 직관에서 나오는 통찰. 이것들은 여전히 인간의 영역이에요.

넷째, 소통(Communication)입니다. 기술적 내용을 비기술 이해관계자에게 설명하고, 다양한 배경의 사람들과 합의를 이끌어내는 능력이에요. AI가 팀원이 되는 시대에는 인간 사이의 소통이 더더욱 중요해집니다. 왜냐하면 AI와의 협업에서 발생하는 새로운 종류의 오해와 갈등을 해결해야 하거든요. “AI가 이렇게 했는데 괜찮을까요?”, “AI의 제안과 우리의 판단이 다른데 어떻게 할까요?” 같은 새로운 차원의 소통 과제가 생기고 있습니다.

다섯째, 인격(Character)입니다. 정직함, 책임감, 윤리 의식. 기술이 사회에 미치는 영향이 커질수록 이것을 다루는 사람의 인격이 중요해지는 건 당연한 일이겠죠. 앞서 윤리적 판단에서 이야기한 것과 같은 맥락입니다.

이 다섯 가지를 가만히 살펴보면, 재미있는 점을 발견하게 됩니다. 이것들은 서로 독립적이지 않아요. 호기심이 좋은 질문을 낳고, 비판적 사고가 그 질문을 날카롭게 다듬고, 창의성이 새로운 답을 찾아내고, 소통이 그 답을 팀에 전달하고, 인격이 그 모든 과정에 윤리적 기반을 제공합니다. 하나의 유기적인 체계인 셈이죠. 그래서 어느 하나만 키우는 것보다, 이 다섯 가지의 균형을 맞추는 것이 더 중요합니다.

Microsoft만 이런 이야기를 하는 게 아닙니다. 세계경제포럼(WEF)의 전망을 보면, 가장 수요가 높은 역량 목록의 상위에 분석적 사고, 창의성, 회복탄력성, 소통, 공감이 자리하고 있습니다. 분석적 사고가 1위라는 점이 특히 눈에 띕니다. 기술적 스킬이 아니라 “생각하는 능력”이 가장 중요한 역량이라는 뜻이에요.

McKinsey는 더 직접적으로 선언합니다. “인간의 역량은 AI 시대에 그 어느 때보다 중요하다(Human skills will matter more than ever in the age of AI).” 이것은 위로의 말이 아닙니다. 전 세계 수천 개의 기업 데이터를 분석한 결론입니다. 그리고 이 결론에는 구체적인 근거가 따라붙습니다. AI 문해력과 강한 인간 역량을 함께 갖춘 사람이, 둘 중 하나만 가진 사람보다 현저히 높은 보상을 받는다는 연구 결과예요. AI를 잘 다루는 것만으로는 부족하고, 인간적 역량만 가지고도 부족합니다. 두 가지를 함께 갖춘 사람이 이 시대의 승자가 됩니다.

소프트 스킬은 더 이상 “있으면 좋은 것”이 아닙니다

여기서 잠깐, 전작 이야기를 하지 않을 수 없습니다. “코드 너머, 회사보다 오래 남을 개발자”에서 저는 소프트 스킬의 중요성을 이야기했습니다. 경청, 질문법, 회의 스킬, 자기 인식, 회복탄력성, 심리적 안전감. 그때만 해도 “코드만 잘 짜면 되는 거 아니야?”라는 반응이 적지 않았어요. “소프트 스킬이요? 좋은 건 알겠는데, 당장 코딩 실력이 더 급하지 않나요?”라는 피드백도 받았습니다.

그런데 지금은 어떤가요? AI가 코드를 짜는 시대가 되면서, 그 “코드만 잘 짜면”이라는 전제 자체가 흔들리고 있습니다. 코드 작성 능력만으로는 더 이상 차별화가 어려운 시대가 온 거예요. 전작에서 추천사를 써주신 분의 말씀이 떠오릅니다. “AI가 코딩을 대신할 순 있어도, 함께 일하고 싶은 사람은 결국 협업을 잘하는 사람이다.” 그리고 또 다른 분은 이렇게 말씀하셨죠. “코딩 실력만으로는 차별화되기 어려운 시대.”

그때는 “소프트 스킬이 중요하다”가 메시지였다면, 지금은 한 걸음 더 나아가야 합니다. 소프트 스킬은 이제 “있으면 좋은 것(nice to have)”이 아니라 “없으면 안 되는 것(must have)”이 되었습니다. 이것은 제 개인적인 주장이 아니에요. McKinsey, WEF, BCG, Microsoft 같은 글로벌 기관들이 데이터로 확인한 사실입니다.

BCG의 연구가 특히 인상적입니다. “AI는 대체(replace)하기보다 더 많은 일자리를 재편(reshape)할 것이다.” 그리고 그 재편된 일자리에서 결정적 우위를 차지하는 것은 자동화 능력이 아니라, 인간-AI 협업 중심으로 워크플로우를 재설계하는 능력이라고 합니다. 결국 사람의 판단력, 창의성, 소통 능력이 AI를 제대로 활용하는 토대가 되는 셈이죠.

이 연구 결과가 말해주는 핵심은 이겁니다. AI를 잘 쓰려면, 역설적으로 인간적 역량이 먼저 탄탄해야 한다는 것. 비판적 사고가 없으면 AI의 오류를 잡아내지 못하고, 창의성이 없으면 AI에게 좋은 질문을 던지지 못하고, 공감이 없으면 AI가 만든 결과물이 사용자에게 가치가 있는지 판단하지 못합니다. 소프트 스킬은 AI 시대의 부가 옵션이 아니라, AI를 제대로 활용하기 위한 전제 조건인 셈이에요.

한국의 현장에서도 같은 목소리

글로벌 연구만 이야기하면 “우리나라 현실은 다르지 않나요?”라는 생각이 드실 수 있습니다. 충분히 공감합니다. 해외 리포트가 아무리 그럴듯해도, 내가 매일 출근하는 회사의 현실과 동떨어져 있으면 와닿지 않잖아요. 그래서 한국의 현장 이야기도 해보겠습니다.

삼성전자 SWITCH 사무국은 기술적 전문성을 넘어선 소프트 스킬을 강조하고 있습니다. 한국 최대의 테크 기업이 “기술만으로는 부족하다”는 메시지를 공식적으로 내고 있다는 건 의미심장한 변화예요.

SK AX는 더 구체적으로 말합니다. “AI가 대신 만들어낸 결과물을 올바르게 이해하고 평가하며, 전체 시스템 안에서 의미 있게 연결할 수 있는 능력이 핵심이다.” 이 문장을 잘 뜯어보세요. “올바르게 이해하고 평가하며”는 비판적 사고를 말하고, “전체 시스템 안에서 의미 있게 연결할 수 있는”은 맥락 이해와 창의적 통합을 말합니다. AI가 만든 결과물 자체가 아니라, 그것을 판단하고 연결하는 인간의 역량이 핵심이라는 뜻입니다.

2026년 한국 직업 트렌드가 꼽은 7대 핵심 역량을 보면 더 흥미롭습니다. AI 리터러시, 데이터 해석력은 당연히 포함되어 있지만, 그 옆에 창의적 문제 해결, 디지털 커뮤니케이션, 자기 주도 학습력, 윤리적 판단력, 협업과 적응력이 나란히 자리하고 있어요. 일곱 가지 중 다섯 가지가 인간적 역량입니다. 기술과 인간적 역량이 거의 반반, 아니 인간적 역량 쪽이 더 많아요. 어느 한쪽만으로는 부족하다는 현장의 목소리가 담긴 결과입니다.

국내 채용 시장의 변화도 주목할 만합니다. “얼마나 많이 뽑느냐”보다 “누구를 뽑느냐”로 기준이 바뀌고 있거든요. 코딩 테스트 점수가 높은 사람보다, 문제를 정의하고, 팀과 소통하고, 사용자의 관점에서 생각할 수 있는 사람. 그런 사람을 찾고 있다는 뜻입니다. 기술 면접 외에 행동 면접, 문화 면접의 비중이 높아지고 있다는 것도 같은 맥락이에요.

두 역량의 결합 – AI 리터러시와 인간 역량 사이에서

여기서 한 가지 중요한 포인트를 짚고 넘어가야 할 것 같습니다. 지금까지 “AI가 가져갈 수 없는 것들”을 이야기했다고 해서, “그러니까 기술은 안 배워도 된다”라는 뜻이 절대 아닙니다. 오히려 정반대예요.

McKinsey의 연구에서 특히 주목할 만한 부분이 있습니다. AI 문해력과 강한 인간 역량을 함께 갖춘 사람이, 둘 중 하나만 가진 사람보다 현저히 높은 성과와 보상을 보인다는 것이에요. 이것은 “어느 쪽이 더 중요한가”의 문제가 아닙니다. 양쪽 모두가 필요하다는 뜻이에요.

비유하자면, AI 리터러시는 자동차를 운전하는 기술이고, 인간 역량은 어디로 갈지를 결정하는 판단력입니다. 운전을 못하면 아무 데도 갈 수 없지만, 방향을 모르면 운전을 아무리 잘해도 엉뚱한 곳에 도착하게 되잖아요. 둘 다 필요합니다.

현실적으로 이것은 어떤 모습일까요? AI 도구를 능숙하게 다루면서 동시에 “이 AI의 답이 맞는지” 비판적으로 평가할 수 있는 사람. 프롬프트를 잘 작성하면서 동시에 “이 방향이 사용자에게 가치가 있는지” 판단할 수 있는 사람. AI가 생성한 코드를 리뷰하면서 동시에 “이 설계가 팀의 미래에 도움이 되는지” 고민할 수 있는 사람. 이런 사람이 두 역량의 결합을 체현하는 인재입니다.

2026년 한국 직업 트렌드가 선정한 7대 핵심 역량을 다시 한번 떠올려보세요. AI 리터러시와 데이터 해석력이라는 기술적 역량이 있고, 그 옆에 창의적 문제 해결, 디지털 커뮤니케이션, 윤리적 판단력, 협업과 적응력이라는 인간적 역량이 있습니다. 이 목록은 “둘 중 하나를 고르라”가 아니라 “둘 다 갖춰라”라는 메시지를 담고 있어요.

그렇다면 어느 쪽에 더 무게를 둬야 할까요? 제 생각은 이렇습니다. AI 리터러시는 빠르게 습득할 수 있는 영역입니다. 도구 사용법은 몇 주면 익힐 수 있고, 새로운 도구가 나오면 또 배우면 됩니다. 하지만 비판적 사고, 공감, 창의성, 윤리적 판단 같은 인간 역량은 하루아침에 생기지 않아요. 수년간의 경험과 성찰, 다양한 상황에서의 시행착오를 통해 천천히 쌓이는 것들입니다. 긴급도는 AI 리터러시가 높지만, 희소성과 장기적 가치는 인간 역량이 더 높다고 할 수 있어요.

그래서 전략은 이렇습니다. AI 도구는 당장 배우되, 인간 역량의 토양은 꾸준히 가꿔나가는 것. 단기적으로는 AI를 잘 쓰는 법을 익히면서, 장기적으로는 AI가 절대 대체할 수 없는 역량을 키워나가는 겁니다. 이 두 트랙을 동시에 가져가는 사람이, 결국 이 시대에 가장 강한 경쟁력을 갖게 될 겁니다.

혹시 “두 가지를 동시에 하라니, 너무 많은 것을 요구하는 거 아닌가요?”라는 생각이 드실 수 있어요. 하지만 좋은 소식이 있습니다. 이 두 트랙은 상충하는 게 아니라 서로를 강화합니다. AI를 잘 쓰다 보면 비판적 사고가 더 날카로워지고(AI의 실수를 잡아내야 하니까요), 공감 능력이 좋아지면 AI에게 더 좋은 프롬프트를 만들 수 있게 되고(사용자의 맥락을 정확히 전달할 수 있으니까요), 창의성이 높으면 AI를 더 창의적으로 활용할 수 있게 됩니다. 선순환이에요.

증강된 조직이라는 가능성

개인 차원의 이야기에서 조금 더 넓히면, 조직 차원에서도 같은 원리가 작동합니다.

BCG가 제시한 “증강된 조직(Augmented Organization)”이라는 개념이 있어요. 인간의 판단과 창의성을 AI가 증폭하는 선순환 구조를 말합니다. 이것은 단순히 “AI를 도입한 조직”과는 다릅니다. AI가 사람의 능력을 대체하는 게 아니라 확장하는 구조예요.

어떤 모습일까요? 예를 들어, 마케팅 팀에서 새로운 캠페인을 기획한다고 해봅시다. AI는 과거 캠페인 데이터를 분석하고, 타겟 고객의 행동 패턴을 파악하고, 최적의 채널과 메시지를 추천합니다. 하지만 “이 캠페인이 우리 브랜드의 가치관과 맞는가”, “이 메시지가 사회적으로 어떤 반향을 일으킬 수 있는가”, “고객이 이 캠페인을 통해 어떤 감정을 느끼길 원하는가” 같은 판단은 사람이 내립니다. AI가 제시한 최적해가 항상 윤리적으로, 감정적으로, 브랜드 관점에서 최선인 것은 아니니까요.

이런 조직에서는 AI가 인간의 능력을 깎아내리는 게 아니라, 인간이 더 높은 차원의 판단에 집중할 수 있도록 토대를 만들어줍니다. 반복적이고 분석적인 작업은 AI가 처리하고, 사람은 그 결과를 바탕으로 창의적이고 전략적인 결정을 내리는 거예요. 이것이 바로 “증강”의 의미입니다.

이 구조가 제대로 작동하려면 무엇이 필요할까요? 바로 이 장에서 이야기한 인간 역량입니다. AI의 분석 결과를 비판적으로 검토할 수 있는 사고력, 그 결과를 팀원들에게 효과적으로 소통할 수 있는 능력, 최종 결정에 윤리적 판단을 반영할 수 있는 성숙함. 결국 조직 차원에서도 AI 시대의 성패는 “기술을 얼마나 잘 도입했느냐”가 아니라 “그 기술 위에서 인간이 얼마나 잘 판단하느냐”에 달려 있는 셈입니다.

여러분이 이미 가지고 있는 것들

이쯤에서 한 가지 중요한 이야기를 하고 싶습니다. 지금까지 나열한 역량들, 창의성, 비판적 사고, 공감, 윤리적 판단, 소통. 이것들이 어딘가 먼 곳에 있는 대단한 능력이라고 생각하실 수 있어요. “나는 창의적인 사람이 아닌데”, “비판적 사고라니, 그런 건 학자들이나 하는 거 아닌가요?”라고요.

하지만 사실은 그렇지 않습니다. 한번 돌아보세요.

동료가 작성한 기획안을 보고 “이 부분은 사용자 입장에서 불편하지 않을까?”라고 생각한 적이 있으신가요? 그게 공감이고 비판적 사고입니다. 회의 중에 “잠깐, 우리가 풀려는 문제가 정말 이건가요?”라고 질문한 적이 있나요? 그게 문제 발견력이에요. 전혀 다른 분야의 경험에서 힌트를 얻어 업무에 적용한 적이 있다면? 그것이 창의성입니다. 동료의 어려움을 보고 “내가 도울 수 있는 게 있을까?”라고 먼저 나선 적이 있다면? 그게 바로 공감과 소통이에요.

이런 역량들은 거창한 훈련 프로그램을 통해서만 얻어지는 게 아닙니다. 매일의 업무 속에서, 동료와의 대화에서, 사용자를 관찰하면서, 실패를 복기하면서 자연스럽게 쌓이는 것들이에요. 다만 지금까지는 이것들의 가치가 과소평가되어 있었을 뿐입니다.

그래서 제가 드리고 싶은 말씀은 이겁니다. 새로운 능력을 처음부터 쌓아야 한다고 부담 갖지 마세요. 여러분은 이미 이 역량들의 씨앗을 가지고 있습니다. AI 시대가 바꾸는 것은 이 역량들의 존재가 아니라 이 역량들의 가치입니다. 코드를 AI가 대신 짜주는 세상에서, 코드 너머에 있는 이런 인간적 역량의 희소성이 급격히 올라가고 있는 겁니다. 여러분이 가진 것의 시장 가치가 올라가고 있는 거예요. 이것은 두려워할 일이 아니라, 기회로 삼을 일입니다.

마무리

3장에서 사라지는 것들의 목록을 마주했을 때, 어쩌면 마음 한쪽이 무거우셨을 겁니다. 하지만 이제는 좀 다른 풍경이 보이시나요? AI가 가져간 것들 너머에, AI가 절대 가져갈 수 없는 것들이 단단하게 자리 잡고 있습니다. 창의성, 비판적 사고, 공감, 윤리적 판단, 소통. 그리고 그것들은 이미 여러분 안에 있어요.

이 장의 메시지를 한 문장으로 압축하면 이렇습니다. AI가 “어떻게”를 해결하는 시대에, “왜”와 “무엇을”에 답하는 인간 역량의 가치는 오히려 올라간다. 이것은 위로가 아니라 사실입니다. McKinsey가 데이터로 확인했고, WEF가 전망으로 뒷받침했고, Microsoft가 프레임워크로 정리했고, BCG가 조직 차원에서 검증한 사실이에요.

물론 이 역량들이 저절로 빛나는 것은 아닙니다. 의식적으로 키워나가야 하고, 연습해야 하고, 때로는 불편한 상황에서 발휘해야 합니다. 하지만 적어도 방향은 분명합니다. AI와 경쟁하는 것이 아니라, AI가 할 수 없는 영역에서 자신만의 가치를 키워나가는 것. 그리고 AI 리터러시라는 기술적 토대 위에, 인간 역량이라는 차별화 요소를 쌓아나가는 것. 이 두 트랙의 결합이 이 시대의 생존 전략이자 성장 전략입니다.

그렇다면 이 변화는 개발자에게만 해당되는 이야기일까요? 다음 장에서는 좀 더 큰 그림을 그려보겠습니다. 모두가 개발자가 되는 세상, 그 안에서 “진짜 개발자”란 대체 누구인지, 그리고 개발자와 비개발자의 경계가 허물어지는 시대에 우리 각자가 어떤 역할을 찾아야 하는지 함께 생각해보겠습니다.

5장. 모두가 개발자가 되는 세상

여러분의 회사에 마케팅 팀장이 한 분 있다고 상상해보세요. 코딩이라곤 한 줄도 해본 적 없는 분입니다. HTML이 뭔지는 들어봤지만, 직접 써본 적은 없고요. 그런데 어느 날, 그분이 직접 업무용 앱을 만들어서 팀에 배포합니다. 고객 피드백을 자동으로 분류하고, 주간 보고서를 생성하고, 캠페인 성과를 대시보드로 보여주는 앱을요. 개발팀에 요청한 것도 아니고, 외주를 준 것도 아닙니다. AI 도구에 자연어로 요구사항을 설명해서, 직접 만든 겁니다. 점심시간에 샌드위치를 먹으면서요.

황당한 이야기처럼 들리시나요? 하지만 이미 현실입니다. Vercel의 조사에 따르면, v0 사용자의 63%가 비개발자입니다. 코드를 한 줄도 모르는 사람들이 소프트웨어를 만들고 있는 거예요. 이 숫자를 처음 봤을 때, 저도 솔직히 놀랐습니다.

그렇다면 진짜 개발자는 누구일까요? 이 질문이 이번 장의 출발점입니다.

시민 개발자라는 새로운 종

“시민 개발자(Citizen Developer)”라는 용어를 들어보신 적 있으신가요? 코딩 전문 지식 없이 비즈니스 문제를 직접 해결하는 새로운 유형의 개발자를 일컫는 말입니다. 이분들은 프로그래밍 언어를 배운 적이 없습니다. 알고리즘 수업을 들은 적도 없고, 자료구조가 뭔지도 잘 모를 수 있어요. 컴퓨터 공학과를 나오지도 않았고, 코딩 부트캠프를 다닌 것도 아닙니다.

하지만 한 가지는 확실합니다. 자신이 겪고 있는 문제가 무엇인지는 누구보다 잘 안다는 거예요.

영업팀의 A 과장은 매주 금요일마다 엑셀로 주간 매출 보고서를 만드는 데 반나절을 씁니다. HR 팀의 B 매니저는 수백 개의 지원서를 일일이 분류하는 작업에 지쳐 있고요. 고객 서비스 팀의 C 팀장은 반복되는 문의에 같은 답변을 복사-붙여넣기하는 일에 난감함을 느끼고 있습니다. 이 사람들은 자신의 문제를 너무나 잘 알고 있어요. 다만 그 문제를 기술적으로 해결할 수단이 없었을 뿐입니다.

이것이 왜 중요한지 한번 생각해보세요. 기존의 소프트웨어 개발 프로세스에서는 현장의 문제가 기술적 해결책으로 연결되기까지 긴 과정을 거쳐야 했습니다. A 과장이 느끼는 불편함을 기획서로 작성하고, 그 기획서를 개발팀에 전달하고, 개발팀이 요구사항을 분석하고, 우선순위를 정하고, 개발에 착수하고. 이 과정에서 원래의 문제가 변형되거나, 핵심이 빠지거나, 아예 대기열에서 사라지는 일이 비일비재했어요. “전화 게임”처럼, 원래의 메시지가 전달 과정에서 왜곡되는 거죠.

하지만 문제를 겪는 사람이 직접 해결책을 만들 수 있다면? 그 왜곡의 과정이 사라집니다. 현장의 뉘앙스, 미묘한 불편함, “말로 설명하기 어려운 그 느낌”까지 고스란히 해결책에 반영될 수 있어요. 이것이 시민 개발자의 진짜 가치입니다. 기술적 역량이 뛰어나서가 아니라, 문제에 대한 이해가 깊기 때문에 가치 있는 거예요.

그리고 바로 그 지점에서 새로운 가능성이 열립니다. 노코드, 로코드 도구와 AI가 그 수단을 제공하기 시작한 거죠.

노코드, 로코드 시장의 성장세를 보면 이 변화의 규모를 실감할 수 있습니다. 2020년에 132억 달러였던 이 시장은 2025년 455억 달러로 성장했습니다. 5년 만에 3배가 넘는 성장이에요. 2026년에는 신규 애플리케이션의 75%가 로코드 플랫폼으로 제작될 것이라는 전망도 있습니다. 더 놀라운 건 이겁니다. 앱의 80%가 비개발자에 의해 만들어지는 시대가 오고 있다는 거예요.

이 숫자들을 보면 솔직히 좀 아찔할 수 있습니다. 특히 개발자 분들이라면요. “그러면 우리는 뭘 하라는 거야?”라는 생각이 자연스럽게 들 수 있어요. 당연한 반응입니다. 하지만 잠깐, 좀 더 깊이 들어가보겠습니다. 이 변화의 이면에는 우리가 놓치기 쉬운 중요한 이야기가 숨어 있거든요.

“아무나 만든다”가 아니라 “더 많은 사람이 더 안전하게 만든다”

시민 개발자의 등장을 이야기할 때 가장 많이 듣는 우려가 있습니다. “아무나 앱을 만들면 품질은 어떻게 보장하나요?” “보안 문제는요?” “유지보수는 누가 하죠?” “서비스가 커지면 감당이 되나요?”

정말 중요한 질문들입니다. 그리고 이 질문들이 중요한 이유는, 바로 여기에 답이 숨어 있기 때문이에요.

성공적인 개발의 민주화는 “아무나 만든다”가 아닙니다. “안전장치 안에서 더 많은 사람이 더 빠르게 만든다”예요. 여기서 “안전장치”가 핵심입니다. 가드레일, 거버넌스, 아키텍처 기준, 보안 정책, 데이터 접근 규칙, 배포 절차. 이것들이 없으면 민주화는 그냥 혼란이 됩니다. 수백 개의 앱이 제각각 만들어지고, 보안 구멍이 여기저기 뚫리고, 데이터가 중복되고, 장애가 연쇄적으로 퍼지는 끔찍한 상황이 벌어질 수 있어요.

한번 비유를 들어보겠습니다. 자동차의 역사를 생각해보세요. 초기에 자동차는 전문 기술자만 운전할 수 있었습니다. 시동 거는 것부터 기어 변속까지 전문 지식이 필요했죠. 하지만 기술이 발전하면서 누구나 운전할 수 있게 되었습니다. 자동 기어, 파워 스티어링, 크루즈 컨트롤. 운전의 기술적 장벽이 계속 낮아졌어요.

그런데 “누구나 운전한다”가 “아무렇게나 운전한다”를 의미하지는 않습니다. 면허 제도가 있고, 교통 법규가 있고, 차선과 신호등이 있고, 안전벨트와 에어백이 있어요. 속도 제한이 있고, 음주 운전 단속이 있고, 정기 검사가 있습니다. 이 모든 안전장치 위에서 더 많은 사람이 자유롭게 이동할 수 있게 된 겁니다.

소프트웨어 개발의 민주화도 같은 원리입니다. 더 많은 사람이 소프트웨어를 만들 수 있게 되는 것은 좋은 일이에요. 현장의 문제를 가장 잘 아는 사람이 직접 해결할 수 있으니까요. 하지만 그 위에 견고한 거버넌스가 필요합니다. 누가 어떤 데이터에 접근할 수 있는지, 만든 앱이 어떤 기준을 충족해야 배포할 수 있는지, 문제가 생겼을 때 누가 책임지는지. 이런 규칙과 체계를 설계하고 유지하는 것, 이것이 바로 전문 개발자와 IT 조직의 새로운 핵심 역할입니다.

IT 조직의 역할이 올라갑니다

여기서 흥미로운 역설이 생깁니다. 더 많은 사람이 개발을 하게 되면, 전문 개발자는 필요 없어지는 걸까요? 정반대입니다. 오히려 더 필요해지고, 더 중요해집니다.

생각해보세요. 시민 개발자들이 매일 수백 개의 앱을 만들어낸다면, 그 앱들이 돌아가는 기반 인프라는 누가 관리하나요? 앱들 사이의 데이터 흐름은 누가 설계하나요? 보안 취약점은 누가 점검하나요? 서비스가 커지면서 생기는 확장성 문제는요? AI가 생성한 코드의 품질은 누가 보증하나요?

IT 조직의 역할은 사라지는 게 아니라 올라갑니다. 일상적인 화면이나 폼을 만드는 반복 작업에서 벗어나, 아키텍처 설계, 거버넌스 수립, 보안 관리라는 더 높은 수준의 일에 집중하게 되는 거예요.

비유하자면, 모든 부대원이 총을 쏠 수 있게 되었다고 해서 장군이 필요 없어지는 게 아닌 것과 같습니다. 오히려 더 많은 사람이 무장하게 되면, 전체 전략을 설계하고 조율하는 역할이 더 중요해지죠. 누가 어디를 담당하는지, 전체적인 작전은 어떻게 짜는지, 예상치 못한 상황에서 어떻게 대응하는지. 이런 고차원적인 판단은 깊은 경험과 넓은 시야를 가진 전문가의 몫입니다.

카카오의 사례가 이 변화를 잘 보여줍니다. AI로 대체 가능한 직무에는 신규 인원 배정을 중단하는 한편, CTO 주재로 AI 역량 강화를 적극적으로 독려하고 있어요. “사람이 덜 필요하다”가 아니라 “사람에게 다른 것을 기대한다”는 메시지입니다. 단순 반복 코딩을 하는 개발자는 줄어들겠지만, 시스템을 설계하고, AI를 감독하고, 거버넌스를 수립하는 개발자의 수요는 오히려 늘어나고 있어요.

3장에서 살펴본 것처럼, 개발자의 65%가 역할의 재정의를 예상하고 있습니다. 그리고 37%는 AI가 이미 커리어 기회를 확장했다고 응답했어요. 역할이 사라지는 것이 아니라, 더 높은 곳으로 이동하고 있다는 증거입니다.

한 가지 현실적인 질문이 떠오를 수 있어요. “그러면 지금 일상적인 개발 업무를 하고 있는 사람은 어떻게 해야 하나요?” 당장 내일부터 아키텍트가 되거나 거버넌스 전문가가 될 수는 없잖아요. 충분히 이해합니다.

하지만 전환은 하루아침에 일어나지 않습니다. 점진적으로 일어나요. 오늘 반복적인 코딩 업무를 하고 있더라도, 그 안에서 “이 부분은 왜 이렇게 설계되어 있지?”, “이 시스템의 전체 구조는 어떻게 생겼지?”, “이 코드가 다른 팀의 서비스와 어떻게 연결되지?”라는 질문을 던지기 시작하면, 그것이 바로 아키텍처적 사고의 출발점입니다. 매일의 업무 안에서 시야를 넓혀가는 거예요.

SK AX의 메시지가 다시 한번 떠오릅니다. “AI가 대신 만들어낸 결과물을 올바르게 이해하고 평가하며, 전체 시스템 안에서 의미 있게 연결할 수 있는 능력이 핵심이다.” 이 능력은 하루아침에 생기는 게 아니에요. 매일 코드를 작성하고, 리뷰하고, 시스템을 운영하면서 축적되는 경험의 결과물입니다. 그러니 지금 하고 있는 일이 무의미하다고 느끼실 필요가 없어요. 다만 그 일을 하면서 시야를 좀 더 넓게 가져가는 연습을 하시면 됩니다.

개발자와 비개발자 사이의 벽이 허물어지다

자, 여기서 한 발 더 나가보겠습니다. 시민 개발자의 등장은 단순히 “비개발자도 앱을 만든다”는 이야기가 아닙니다. 더 근본적인 변화가 일어나고 있어요. 바로 “개발자”와 “비개발자”라는 구분 자체가 희미해지고 있다는 겁니다.

이런 상황을 생각해보세요. 한쪽에는 Python으로 데이터 분석 스크립트를 짜는 마케터가 있습니다. 본인은 “난 개발자가 아니야”라고 말하지만, 실제로 코드를 작성하고 실행하고 있어요. 다른 한쪽에는 AI 도구를 활용해서 비즈니스 로직을 자연어로 정의하고, AI가 생성한 코드를 리뷰하는 시니어 개발자가 있습니다. 이 개발자는 하루 종일 한 줄의 코드도 직접 작성하지 않았어요.

이 두 사람 중 누가 “진짜 개발자”인가요?

과거에는 답이 명확했습니다. 프로그래밍 언어를 다루는 사람이 개발자였죠. 컴퓨터 공학과를 졸업하고, 코딩 테스트를 통과하고, IDE를 열어 코드를 타이핑하는 사람. 하지만 AI가 코드를 쓰는 시대에, 코드를 직접 작성하는 것이 개발자의 정의가 될 수 있을까요?

Anthropic의 2026 보고서에서 언급된 8대 트렌드 중 하나가 바로 “비전통적 사용자로의 확대”입니다. AI 코딩 도구의 사용자가 전통적인 개발자를 넘어 다양한 직군으로 퍼져나가고 있다는 뜻이에요. 소프트웨어 개발은 더 이상 특정 직군의 전유물이 아닙니다. “문제를 가진 사람이 곧 해결자가 되는 방향”으로 재편되고 있습니다.

카카오 기술 블로그에 흥미로운 글이 올라온 적이 있습니다. “바이브 코딩하는 비개발자는 개발자인가?”라는 제목이었어요. 이 질문 자체가 시대의 변화를 상징합니다. 불과 몇 년 전만 해도 이런 질문은 성립조차 하지 않았으니까요. 비개발자가 코딩을 한다고요? 말이 안 되는 이야기였죠. 하지만 이제는 진지하게 논의해야 할 주제가 되었습니다.

이 질문에 대한 답은 아마도 “예”도 “아니오”도 아닐 겁니다. “개발자”라는 단어의 정의 자체가 달라지고 있으니까요. 과거에 “운전자”라는 말이 마부(馬夫)를 가리켰다가 자동차 운전자를 가리키게 된 것처럼, “개발자”라는 말의 의미도 확장되고 있는 중입니다. 중요한 것은 명칭이 아니라, 각자가 어떤 가치를 만들어내느냐입니다.

이 변화를 부정적으로만 볼 필요는 없어요. 오히려 이렇게 생각해볼 수 있습니다. 경계가 허물어진다는 것은, 서로의 세계를 더 잘 이해할 수 있게 된다는 뜻이기도 합니다. 비개발자가 개발의 과정을 조금이라도 경험하면, 개발팀에 무리한 요구를 하는 일이 줄어들겠죠. “이거 간단하잖아요, 그냥 빨리 만들어주세요”라는 말이 줄어들 거예요. 직접 만들어봤으니까, “간단해 보이는 것”이 실제로는 얼마나 복잡한지를 체감하게 되니까요. 반대로 개발자가 비즈니스의 맥락을 더 깊이 이해하면, 기술적으로는 완벽하지만 비즈니스적으로는 의미 없는 것을 만드는 일이 줄어들 겁니다. “기술적으로 가능하니까 만들었다”가 아니라 “이것이 사용자에게 가치가 있기 때문에 만들었다”로 판단의 기준이 바뀌는 거죠.

벽이 허물어지면서, 소통의 비용이 줄고, 협업의 질이 올라가는 거예요. 개발자와 비개발자가 같은 언어로 대화할 수 있게 되면, 그동안 “번역 과정”에서 손실되던 맥락과 뉘앙스가 살아납니다. 마케터가 “이 기능이 비즈니스적으로 왜 중요한지”를 코드 수준까지 내려가서 설명할 필요는 없지만, 적어도 “이것을 구현하려면 대략 어느 정도의 복잡도가 필요한지”를 감으로 알게 되면 대화의 질이 완전히 달라집니다.

새로운 역할들이 태어나고 있습니다

경계가 허물어지는 자리에서 새로운 역할들이 생겨나고 있습니다. 기존의 “개발자” 또는 “비개발자”라는 이분법으로는 설명할 수 없는, 새로운 유형의 역할들이에요. 몇 가지만 살펴볼까요.

AI 오케스트레이터. 여러 AI 에이전트를 조율해서 하나의 복잡한 작업을 완수하는 사람입니다. 마치 오케스트라의 지휘자처럼, 각 에이전트의 강점을 파악하고, 적재적소에 배치하고, 전체 결과물의 품질을 관리합니다. 1장에서 이야기한 것처럼, 단일 에이전트가 아닌 멀티에이전트 팀을 조율하는 시대가 이미 시작되었거든요. 이 역할은 깊은 기술적 이해가 필요하지만, 전통적인 의미의 “코딩”과는 다릅니다. 코드를 짜는 것이 아니라, AI를 지휘하는 것이니까요.

프롬프트 디자이너. AI에게 정확한 지시를 내리는 것이 하나의 전문 역량이 되고 있습니다. 이것은 단순히 “AI에게 말을 잘 거는 것”이 아닙니다. 문제를 구조화하고, 맥락을 설정하고, 기대하는 결과물의 형태를 명확히 정의하는 능력이에요. 좋은 프롬프트를 설계하려면 해당 도메인에 대한 이해, 논리적 사고, 그리고 AI의 작동 방식에 대한 감각이 동시에 필요합니다. 이것은 기술적 이해와 커뮤니케이션 능력이 만나는 지점에 있는 역할이에요.

디지털 통역사. 기술 세계와 비즈니스 세계 사이를 오가며 양쪽의 언어를 번역하는 사람입니다. 개발자에게 비즈니스 요구사항을 기술적 명세로 변환해서 전달하고, 경영진에게 기술적 제약과 가능성을 비즈니스 용어로 설명합니다. 이 역할은 사실 예전부터 있었어요. 하지만 개발과 비개발의 경계가 흐려질수록, 그리고 AI라는 새로운 변수가 추가될수록, 이 통역의 가치는 오히려 올라갑니다. “AI가 이런 것을 할 수 있다고 하는데 정말인가요?”, “이 기술적 제약을 비즈니스 관점에서는 어떻게 받아들여야 하나요?” 같은 질문에 답할 수 있는 사람이 점점 더 필요해지고 있어요.

이 역할들의 공통점이 보이시나요? 하나같이 “코드를 직접 짜는 능력”보다 “사람과 시스템을 연결하는 능력”을 요구합니다. 기술적 깊이가 필요 없다는 뜻이 아니에요. 기술적 깊이 위에 다른 무언가가 더 필요해졌다는 뜻입니다. 4장에서 이야기한 소통, 공감, 비판적 사고 같은 역량들이 바로 그 “다른 무언가”에 해당합니다.

그리고 이 새로운 역할들은 기존의 “개발자”나 “비개발자”라는 분류로는 담기지 않아요. AI 오케스트레이터는 개발자인가요, 관리자인가요? 프롬프트 디자이너는 개발자인가요, 기획자인가요? 디지털 통역사는 개발자인가요, 커뮤니케이터인가요? 이 질문 자체가 무의미해지고 있습니다. 역할이 직군의 경계를 넘어서고 있으니까요.

IEEE Spectrum이 “초기 경력 엔지니어가 AI에 앞서가는 법”이라는 제목의 기사를 실은 적이 있습니다. 거기서 강조한 것이 바로 이 “경계를 넘나드는 역량”이에요. 코드만 아는 사람, 비즈니스만 아는 사람이 아니라, 둘 사이를 연결하고 번역할 수 있는 사람. 기술의 가능성을 비즈니스의 기회로 전환할 수 있는 사람. 이런 사람이 AI 시대에 가장 환영받는 인재라는 겁니다.

Stack Overflow 블로그의 표현을 빌리자면, “AI vs Gen Z”가 아니라 “AI with Everyone”이 올바른 프레임이에요. AI와 경쟁하는 것이 아니라, AI와 함께 더 많은 가치를 만들어내는 것. 그리고 그 과정에서 개발자와 비개발자의 구분보다는, “어떤 가치를 만들어내는가”가 사람을 정의하게 됩니다.

비개발자에게 열린 문

지금까지의 이야기가 주로 개발자 관점이었다면, 여기서는 비개발자 분들에게 직접 말씀드리고 싶습니다.

혹시 “나는 개발자가 아니니까 이 변화와는 상관없다”고 생각하고 계신가요? 그렇다면 다시 한번 생각해보시면 좋겠습니다. 이 변화의 가장 큰 수혜자는 어쩌면 바로 여러분일 수 있어요.

지금까지는 아이디어가 있어도 구현할 수단이 없으면 기다릴 수밖에 없었습니다. 개발팀에 요청서를 넣고, 우선순위 대기열에 들어가고, 몇 주 혹은 몇 달을 기다리고요. 그 과정에서 아이디어의 열기가 식어버린 경험, 한두 번쯤은 있으시지 않나요? “이거 만들면 정말 좋을 텐데”라는 생각이 “나중에 여유 있으면 해보자”로 바뀌고, 결국 잊히는 그 패턴이요.

하지만 이제는 다릅니다. AI 도구를 활용하면 아이디어를 가진 사람이 직접 프로토타입을 만들어볼 수 있습니다. 완벽한 제품은 아닐 수 있어요. 확장성이 부족할 수 있고, 보안이 완벽하지 않을 수 있고, 코드의 품질이 전문 개발자 수준은 아닐 수 있습니다. 하지만 “이런 것을 만들고 싶다”를 말이 아닌 실물로 보여줄 수 있다는 것, 이것은 엄청난 변화입니다.

생각해보세요. 기획 회의에서 파워포인트로 아이디어를 설명하는 것과, 실제로 동작하는 프로토타입을 보여주는 것 중 어느 쪽이 더 설득력이 있을까요? 당연히 후자겠죠. AI 도구는 비개발자에게 이 “실물의 힘”을 선물하고 있습니다.

이것이 왜 혁명적인 변화인지 좀 더 설명해볼게요. 지금까지 비개발자가 기술 기반의 아이디어를 제안하면, 흔히 이런 반응을 받았을 겁니다. “좋은 아이디어인 건 알겠는데, 기술적으로 가능한지 먼저 확인해봐야 해요.” 이 한마디가 수많은 좋은 아이디어의 묘비명이 되어왔어요. 기술적 가능성을 확인하는 데만 몇 주가 걸리고, 그 사이에 아이디어의 열기는 식고, 결국 조용히 사라지는 거죠.

하지만 이제 비개발자가 직접 프로토타입을 들고 오면 대화의 구조가 완전히 달라집니다. “이게 기술적으로 되나요?”가 아니라 “이것을 어떻게 더 좋게 만들 수 있나요?”로 시작할 수 있으니까요. 기술적 실현 가능성이 이미 증명된 상태에서 출발하는 대화. 이것은 조직의 혁신 속도를 근본적으로 바꿔놓을 수 있습니다.

Anthropic의 보고서에 따르면, AI 지원 작업의 약 27%는 AI 없이는 시도조차 하지 않았을 작업이었다고 합니다. 이것은 비개발자에게 특히 의미 있는 숫자예요. AI가 없었다면 아예 시작조차 못했을 프로젝트, 아예 만들어보지 못했을 프로토타입, 아예 검증하지 못했을 아이디어. 이런 것들이 이제 가능해졌다는 뜻이니까요.

물론 한 가지 꼭 기억하실 게 있습니다. “만들 수 있다”와 “잘 만들 수 있다” 사이에는 여전히 큰 간극이 존재한다는 거예요. AI 도구로 빠르게 프로토타입을 만드는 것과, 수천 명이 매일 사용하는 안정적인 서비스를 운영하는 것은 전혀 다른 차원의 일입니다. 프로토타입은 “이것이 가능한가”를 검증하는 도구이고, 프로덕션 서비스는 “이것을 안정적으로 운영할 수 있는가”의 영역이에요. 이 간극을 메우는 것이 바로 전문 개발자와 IT 조직의 역할이고, 시민 개발자와 전문 개발자가 협력해야 하는 지점입니다.

“진짜 개발자”의 새로운 정의

그래서 다시 처음의 질문으로 돌아옵니다. 모두가 개발자가 되는 세상에서, “진짜 개발자”란 누구일까요?

저는 이렇게 생각합니다. 진짜 개발자는 코드를 잘 짜는 사람이 아니라, 문제를 정의하고, 시스템을 설계하고, 품질을 보증하고, 사람들 사이의 기술적 소통을 이끄는 사람입니다.

코드 작성은 AI가 도와줄 수 있습니다. 하지만 “이 시스템이 5년 후에도 유지보수 가능한가?”, “이 아키텍처가 사용자가 10배로 늘어났을 때도 버틸 수 있는가?”, “이 설계가 팀 전체가 이해하고 발전시킬 수 있는 구조인가?” 같은 질문에 답하는 것은 깊은 경험과 판단력을 가진 사람의 몫입니다. AI는 코드를 생성할 수 있지만, 시스템의 미래를 내다보는 시야는 갖고 있지 않거든요.

개발자의 정체성이 “코드를 짜는 사람”에서 “기술적 판단을 내리는 사람”으로 이동하고 있는 겁니다. 어떻게 보면, 이것은 개발자의 위상이 낮아지는 게 아니라 오히려 높아지는 것입니다. 반복적인 코딩 작업에서 해방되어, 더 높은 수준의 의사결정에 집중할 수 있게 되니까요. 건물의 비유를 들자면, 벽돌을 쌓는 일에서 건축 설계를 하는 일로 올라가는 셈입니다.

이 이동은 이미 데이터로 확인되고 있어요. 2장에서 살펴봤던 것처럼, 개발자의 65%가 역할의 재정의를 예상하고 있고, 37%는 AI가 이미 커리어 기회를 확장했다고 응답했습니다. 루틴 코딩에서 해방된 시간이 아키텍처 설계, 시스템 통합, AI 기반 의사결정으로 흘러가고 있다는 뜻이에요. AI/ML 엔지니어링, MLOps, 에이전틱 AI 엔지니어링 같은 새로운 전문 분야의 수요가 급증하고 있다는 것도 같은 맥락입니다.

한 가지 더 생각해볼 것이 있어요. “기술적 판단을 내리는 사람”이 되려면, 역설적으로 기술에 대한 깊은 이해가 여전히 필요합니다. AI가 코드를 짜주니까 코드를 몰라도 된다는 뜻이 절대 아니에요. 오히려 AI가 짠 코드를 평가하고, 잠재적 문제를 예측하고, 더 나은 방향을 제시하려면 기초 체력이 탄탄해야 합니다. 마치 지휘자가 모든 악기를 직접 연주하지는 않지만, 각 악기의 특성을 깊이 이해하고 있어야 좋은 지휘를 할 수 있는 것처럼요.

그러니까 “코드를 안 짜도 된다”가 아니라, “코드를 짜는 것 너머의 가치를 만들어야 한다”가 정확한 표현입니다. 기반은 유지하되, 그 위에 더 높은 차원의 역량을 쌓아가는 것. 이것이 “진짜 개발자”가 되어가는 여정입니다.

개발자 분들께 한 가지 당부드리고 싶은 것이 있습니다. 시민 개발자의 등장을 위협으로 보지 마세요. 그것은 마치 계산기의 등장을 수학자에 대한 위협으로 보는 것과 같습니다. 계산기가 사칙연산을 대신해준 덕분에 수학자들은 더 깊은 문제에 집중할 수 있게 되었잖아요. 스프레드시트가 등장했을 때 회계사가 사라지지 않은 것처럼요. 오히려 회계사의 역할은 단순 계산에서 재무 전략과 분석으로 올라갔습니다. 마찬가지로, 시민 개발자가 일상적인 개발을 담당하게 되면 전문 개발자는 더 깊고, 더 어렵고, 더 가치 있는 문제에 집중할 수 있게 됩니다.

거버넌스라는 새로운 전장

시민 개발자가 만든 앱이 100개, 1,000개, 10,000개로 늘어나는 상황을 한번 상상해보세요. 각 부서에서 저마다의 필요에 따라 앱을 만들고, 데이터를 연결하고, 자동화 흐름을 구축합니다. 처음에는 편리하겠죠. 하지만 시간이 지나면 어떤 일이 벌어질까요?

마케팅팀이 만든 고객 데이터 앱과 영업팀이 만든 고객 데이터 앱이 서로 다른 정보를 가지고 있습니다. 어느 쪽이 맞는지 아무도 모릅니다. 누군가 만든 자동화 흐름이 외부 API를 호출하는데, 인증 키가 하드코딩되어 있어요. 퇴사한 직원이 만든 업무용 앱이 아직도 돌아가고 있는데, 아무도 코드를 이해하지 못합니다. 찜찜하죠?

이것이 바로 거버넌스가 필요한 이유입니다. 거버넌스는 딱딱하고 관료적인 규제가 아닙니다. 더 많은 사람이 더 안전하게 만들 수 있게 해주는 안전망이에요. 데이터 접근 정책, 앱 배포 기준, 보안 검증 절차, 코드 품질 기준선. 이런 것들이 잘 갖춰져 있으면 시민 개발자들은 오히려 더 자유롭게 실험할 수 있습니다. 안전벨트가 있으니까 더 과감하게 운전할 수 있는 것처럼요.

이 거버넌스를 설계하고 운영하는 것이 전문 개발자와 IT 조직의 핵심 역할이 됩니다. Anthropic의 2026 보고서가 꼽은 8대 트렌드 중 하나가 “보안 우선 아키텍처의 필요”였다는 점을 기억하세요. 개발의 민주화가 가속화될수록, 그 위에 놓이는 안전 장치의 중요성도 함께 올라갑니다.

재미있는 것은, 이 일이 단순한 기술적 과제가 아니라는 점이에요. 거버넌스를 설계하려면 기술적 이해와 함께, 조직의 업무 흐름을 이해하고, 다양한 이해관계자와 소통하고, 보안과 편의성 사이에서 균형을 잡아야 합니다. 4장에서 이야기한 비판적 사고, 소통, 윤리적 판단이 모두 필요한 일이에요. 결국 기술과 인간 역량이 동시에 요구되는, 고도로 복합적인 역할인 셈입니다.

공존의 생태계를 만들어가는 일

비개발자 독자분들도, 개발자 독자분들도 함께 기억하면 좋겠습니다. “모두가 개발자가 되는 세상”은 “개발자가 필요 없는 세상”이 아닙니다. “개발의 가치가 더 높은 곳으로 이동하는 세상”이에요. 그리고 그 이동의 과정에서 개발자와 비개발자의 협력이 그 어느 때보다 중요해집니다.

시민 개발자는 현장의 문제를 가장 잘 아는 사람으로서 빠른 프로토타이핑을 담당합니다. “이런 게 있으면 좋겠다”를 실제로 만들어서 보여주는 역할이에요. 전문 개발자는 그것을 안정적이고 확장 가능한 시스템으로 발전시킵니다. 프로토타입을 프로덕션 레벨의 서비스로 끌어올리는 것이죠. AI는 양쪽 모두의 생산성을 높여주는 도구가 됩니다. 시민 개발자에게는 기술적 장벽을 낮춰주고, 전문 개발자에게는 반복적인 작업에서 해방시켜줍니다.

이 세 축이 함께 돌아갈 때, 비로소 “더 많은 사람이 더 좋은 소프트웨어를 더 빠르게 만드는” 세상이 가능해집니다. 어느 한 축이 빠지면 균형이 무너져요. 시민 개발자 없이는 현장의 문제가 기술로 연결되지 않고, 전문 개발자 없이는 품질과 안정성이 보장되지 않고, AI 없이는 양쪽 모두 과거의 속도에 머물게 됩니다.

그렇다면 이 공존의 생태계에서 각자가 해야 할 일은 무엇일까요?

비개발자라면, AI 도구를 익히되 그 한계를 인식하는 것이 중요합니다. 프로토타입을 만들 수 있다는 것과 프로덕션 서비스를 운영할 수 있다는 것은 다른 차원의 일이라는 점을 기억하세요. 그리고 전문 개발자의 역할을 “내가 만든 것을 더 좋게 만들어주는 파트너”로 바라보는 시각이 필요합니다.

전문 개발자라면, 거버넌스와 아키텍처라는 새로운 전장에서 자신의 가치를 증명하는 것이 과제입니다. 시민 개발자를 경쟁자가 아니라 “현장의 목소리를 기술로 연결해주는 협력자”로 보는 관점의 전환도 중요합니다. 그들이 만든 프로토타입 속에 숨어 있는 현장의 통찰을, 견고한 시스템으로 발전시키는 것이 여러분의 새로운 사명이에요.

그리고 양쪽 모두에게 필요한 것은, 서로의 역할을 존중하고 협력하는 자세입니다. 결국은 사람과 사람 사이의 문제로 돌아오는 셈이죠. 전작에서 강조했던 “협업 스킬”이 여기서도 빛을 발합니다. AI가 아무리 발전해도, 사람과 사람이 함께 일하는 방식의 품질이 결과물의 품질을 결정하니까요.

마무리

모두가 개발자가 되는 세상. 이 문장은 개발자에게는 불안으로, 비개발자에게는 가능성으로 들릴 수 있습니다. 하지만 한 발 물러서서 보면, 이것은 결국 “만들 수 있는 사람이 더 많아지는 세상”이라는 뜻입니다.

그리고 이 세상에서 진짜 중요한 것은 “누가 개발자인가”라는 명칭의 문제가 아닙니다. “누가 어떤 가치를 만들어내느냐”의 문제예요. 시민 개발자가 현장의 문제를 빠르게 해결하고, 전문 개발자가 견고한 시스템을 설계하고, AI가 양쪽 모두의 생산성을 높여주는 생태계. 이 안에서 각자가 자신만의 자리를 찾아가는 것이 이 시대의 과제입니다.

만들 수 있는 사람이 많아질수록, 정말 중요해지는 질문은 따로 있습니다.

“무엇을 만들 것인가?”

아무리 만드는 비용이 낮아지고, 누구나 만들 수 있게 되어도, 만들 가치가 있는 것을 찾아내는 능력은 결코 저렴해지지 않습니다. 오히려 만드는 비용이 낮아질수록, 이 능력의 가치는 더 올라갑니다. 다음 장에서는 바로 이 질문, “무엇을 만들 것인가”에 대해 이야기해보겠습니다. 어쩌면 이 책에서 가장 중요한 질문일 수 있습니다.

6장. 무엇을 만들 것인가 – 문제 발견의 기술

한 가지 실험을 떠올려보세요. 같은 회사에서 일하는 두 사람에게 동일한 AI 도구를 줍니다. 같은 데이터에 접근할 수 있고, 같은 시간이 주어집니다. 둘 다 AI 도구를 능숙하게 다루는 편이에요. 한 달 후, 두 사람의 결과물은 전혀 다릅니다. 한 사람은 기존 업무를 조금 더 빠르게 처리하는 자동화 도구를 만들었고, 다른 한 사람은 아무도 주목하지 않았던 고객의 불편을 발견하고, 그것을 해결하는 서비스를 만들어서 새로운 매출을 일으켰습니다.

도구는 같았습니다. 기술적 역량의 차이도 크지 않았어요. 그렇다면 무엇이 이 차이를 만들었을까요?

답은 간단하면서도 깊습니다. “무엇을 만들 것인가”를 정의하는 능력의 차이입니다. 한 사람은 이미 있는 문제에 기술을 적용했고, 다른 한 사람은 아직 아무도 이름 붙이지 않은 문제를 먼저 발견했습니다. 이 차이가 결과물의 가치를 완전히 다른 차원으로 만들었어요.

병목이 이동했습니다

오랫동안 소프트웨어의 세계에서 병목은 “만들 수 있느냐”에 있었습니다. 아이디어는 넘쳤지만, 그것을 구현할 개발자가 부족했죠. 기획서는 쌓여가는데 개발 리소스는 한정되어 있고, 우선순위 싸움은 매 분기 반복되고. 혹시 이런 경험이 있으신 분이라면 고개를 끄덕이고 계실 겁니다. “좋은 아이디어인 건 알겠는데, 개발 리소스가 없어서요.” 이 한마디에 수많은 아이디어가 사라져갔습니다.

하지만 지금, 그 병목이 이동하고 있습니다. AI가 개발 비용을 극적으로 낮추면서, “만들 수 있느냐”는 더 이상 핵심적인 제약이 아니게 되었어요. Anthropic의 보고서에 따르면, SDLC(소프트웨어 개발 생명주기)의 사이클 타임이 주 단위에서 시간 단위로 압축되고 있습니다. 이전에는 몇 주가 걸렸을 작업을 이제는 하루 만에 끝낼 수 있게 된 거예요. 5장에서 보았듯이 비개발자도 프로토타입을 만들 수 있는 시대가 되었고요.

개발 비용이 급감하면서 재미있는 일이 벌어지고 있습니다. 더 많은 실험이 가능해졌어요. 과거에는 한 번 개발에 착수하면 몇 달이 걸리기 때문에, 시작 전에 철저하게 기획하고, 신중하게 판단하고, 잘못되면 큰 손실을 감수해야 했습니다. 하지만 이제는 빠르게 만들어보고, 빠르게 검증하고, 안 되면 빠르게 방향을 바꿀 수 있게 되었어요. 실패의 비용이 극적으로 낮아진 겁니다.

그러면 이제 병목은 어디에 있을까요? 바로 “무엇을 만들어야 하는가”입니다.

만드는 것이 쉬워질수록, 만들 가치가 있는 것을 찾아내는 능력의 가치가 올라갑니다. 이것은 단순한 논리가 아니라, 실제로 시장에서 벌어지고 있는 일입니다. 하지만 “무엇을 실험할 것인가”를 결정하는 능력이 없으면, 빠른 속도는 오히려 빠른 낭비가 될 뿐입니다. 아무리 빨리 달릴 수 있어도, 잘못된 방향으로 달리면 목적지에서 더 멀어지잖아요.

이 변화의 규모를 체감하기 위해 한 가지 비유를 들어보겠습니다. 과거의 소프트웨어 개발이 “화살 한 발을 신중하게 쏘는 것”이었다면, AI 시대의 소프트웨어 개발은 “기관총을 쏘는 것”에 가깝습니다. 화살이 귀할 때는 한 발 한 발이 소중하니까 어디를 겨냥할지 신중하게 골라야 했어요. 기획 단계에서 몇 달을 검토하고, 시장 조사를 하고, 경영진의 승인을 받고, 그제야 개발에 착수했습니다. 한 발을 잘못 쏘면 큰 손실이니까요.

하지만 기관총이 생기면서 탄약은 넉넉해졌습니다. 빠르게 만들고, 빠르게 테스트하고, 안 되면 빠르게 버리고 다음 것을 만들 수 있게 된 거예요. 그러면 이제 중요한 건 뭘까요? 어디를 겨냥하느냐, 즉 “무엇을 만들 것인가”의 판단이에요.

Anthropic의 보고서가 흥미로운 데이터를 하나 더 제공합니다. AI 지원 작업의 약 27%는 AI 없이는 시도조차 하지 않았을 작업이었다는 거예요. 이것은 무슨 뜻일까요? AI가 단순히 기존 작업을 빠르게 해주는 것을 넘어서, 이전에는 불가능했던 실험을 가능하게 해준다는 뜻입니다. 이전에는 “시간이 없어서”, “리소스가 부족해서” 시도조차 못했던 아이디어들이 이제는 실행 가능해진 거예요. 가능성의 공간이 폭발적으로 넓어진 셈입니다.

그런데 가능성이 넓어진다는 건, 선택의 어려움도 함께 커진다는 뜻이에요. 할 수 있는 것이 열 가지였을 때는 그중에서 고르는 게 어렵지 않았습니다. 하지만 할 수 있는 것이 천 가지, 만 가지가 되면? “이 중에서 정말 해야 할 것”을 골라내는 능력이 결정적으로 중요해집니다. 그리고 이것이 바로 문제 발견력의 핵심이에요.

문제 해결자에서 문제 발견자로

여기서 근본적인 관점의 전환이 필요합니다. 지금까지 개발자의 핵심 역량은 “문제 해결 능력”이었습니다. 주어진 문제를 효율적으로, 우아하게 푸는 것. 알고리즘을 최적화하고, 깔끔한 아키텍처를 설계하고, 버그를 추적해서 잡아내는 것. 이것은 앞으로도 중요한 역량입니다. 하지만 AI 시대에 가장 희소하고 가치 있는 역량은 한 단계 위에 있습니다. 바로 “문제 발견 능력”이에요.

한번 생각해보세요. AI는 주어진 문제를 놀라울 정도로 잘 풉니다. “이 코드를 최적화해줘”, “이 데이터에서 패턴을 찾아줘”, “이 에러를 수정해줘”, “이 화면을 구현해줘”. 이런 명확하게 정의된 문제 앞에서 AI의 능력은 인간을 압도합니다. 3장에서 살펴본 것처럼, 보일러플레이트 코딩의 62%, 버그 수정의 58%, 테스트 작성의 57%를 AI가 처리하고 있잖아요.

하지만 “어떤 문제를 풀어야 하는지”는 AI가 결정하지 못합니다. “사용자들이 진짜로 원하는 게 뭘까?”, “이 시장에서 아직 아무도 건드리지 않은 기회가 어디에 있을까?”, “우리 팀이 가진 강점으로 풀 수 있는 가장 가치 있는 문제는 뭘까?”, “이 기능이 정말 필요한 건가, 아니면 우리가 만들고 싶을 뿐인가?” 이런 질문에 AI는 그럴듯한 답을 내놓을 수 있지만, 그것은 기존 데이터의 재조합일 뿐입니다. 아직 데이터로 포착되지 않은, 현장에서만 느낄 수 있는 문제를 발견하는 것은 인간만의 영역이에요.

전작에서 저는 “경청”과 “질문법”의 중요성을 이야기한 바 있습니다. 상대방의 말을 제대로 듣고, 핵심을 짚는 질문을 던지는 능력. 그때는 개발자의 소통 역량으로서 다루었지만, AI 시대에 이 역량은 “문제 발견력”이라는 메타 역량으로 격상됩니다. 경청은 사용자의 숨은 니즈를 포착하는 능력이 되고, 질문법은 올바른 문제를 정의하는 능력이 됩니다. 전작에서 “소프트 스킬”이라고 불렀던 것이, 이 시대에는 가장 핵심적인 비즈니스 역량이 된 셈이에요.

한 가지 예를 들어보겠습니다. 어떤 회사의 고객 지원 팀에서 “채팅봇 응답 속도를 개선해달라”는 요청이 들어왔다고 해볼까요. 문제 해결자는 곧바로 채팅봇의 응답 시간을 줄이는 작업에 착수할 겁니다. 서버를 최적화하고, 모델을 경량화하고, 캐싱을 적용해서 응답 시간을 2초에서 0.5초로 줄였어요. 기술적으로 완벽한 해결입니다.

하지만 문제 발견자는 먼저 이렇게 물을 거예요. “잠깐, 고객들이 정말 불만인 게 응답 속도인가요? 혹시 채팅봇의 답변이 도움이 안 돼서, 결국 상담원 연결을 기다리게 되는 게 진짜 불만인 건 아닌가요?” 고객 지원 로그를 뒤져보니, 실제로 고객의 70%가 채팅봇의 첫 응답 이후 곧바로 “상담원 연결”을 요청하고 있었습니다. 속도가 아니라 품질이 문제였던 거예요.

같은 데이터를 보고도 다른 질문을 던지는 것. 이것이 문제 발견력의 핵심이에요. 첫 번째 접근은 기술적으로는 성공이지만 비즈니스적으로는 실패입니다. 두 번째 접근은 진짜 문제를 건드리기 때문에, 같은 노력으로도 훨씬 큰 가치를 만들어냅니다.

그리고 이 차이는 AI 시대에 더욱 극대화됩니다. 왜냐하면 AI에게 “채팅봇 응답 속도를 개선해줘”라고 시키면 AI는 정말 훌륭하게 속도를 개선해줄 겁니다. 하지만 “이것이 풀어야 할 진짜 문제인가?”는 묻지 않아요. AI는 주어진 문제를 의심하지 않습니다. 문제를 의심하고, 재정의하고, 더 가치 있는 문제를 찾아내는 것은 인간의 몫입니다.

제품 감각이라는 차별점

“무엇을 만들 것인가”를 잘 정의하려면, 한 가지 역량이 특히 중요합니다. 바로 제품 감각(Product Sense)이에요.

제품 감각이란 뭘까요? 한마디로 말하면, “이것이 사용자에게 진짜 가치를 줄 수 있는가”를 판단하는 직관입니다. 기술적으로 구현 가능한가와는 별개의 질문이에요. 기술적으로는 얼마든지 만들 수 있지만, 사용자에게 아무런 가치가 없는 것을 만드는 일. 솔직히 말하면, 우리 업계에서 이런 일이 너무나 자주 벌어지지 않나요? “기술적으로는 정말 멋진데, 아무도 안 쓰는” 제품. 혹시 떠오르는 사례가 있으신가요?

한 가지 장면을 그려보겠습니다. 개발 비용이 거의 0에 가까운 세상이 온다고 해보세요. 아이디어만 있으면 뚝딱 만들어낼 수 있는 세상이요. 그러면 소프트웨어가 넘쳐나겠죠. 앱스토어에는 매일 수만 개의 새로운 앱이 올라올 겁니다. 웹 서비스는 하루에도 수천 개가 생겨날 거예요. 그런 세상에서 사용자의 선택을 받으려면 무엇이 필요할까요?

기술적 완성도? AI가 보장해줍니다. 깔끔한 디자인? AI가 만들어줍니다. 성능 최적화? AI가 처리해줍니다. 그러면 차별점은 어디서 올까요?

“이 제품이 내 문제를 정말 이해하고 있구나”라는 느낌. 바로 이것입니다. 사용자가 자신도 명확히 말로 표현하지 못했던 불편을, 제품이 먼저 알아채고 해결해주는 경험. 이 경험을 설계하는 능력이 제품 감각이고, 이것은 AI가 대신해줄 수 없는 영역입니다.

제품 감각은 사용자에 대한 깊은 공감에서 시작됩니다. 4장에서 이야기한 공감 능력, 기억하시죠? 사용자가 어떤 맥락에서, 어떤 감정 상태로, 어떤 기대를 가지고 이 제품을 사용하는지를 온몸으로 이해하는 것. 데이터 분석만으로는 이 깊이에 도달하기 어렵습니다. 클릭률이 높다고 해서 사용자가 만족하는 건 아니거든요. 찾는 걸 못 찾아서 이리저리 클릭하고 있는 건지도 모르잖아요. 현장에 나가서 사용자를 만나고, 그들의 일상을 관찰하고, 그들의 좌절과 기쁨을 직접 느껴야 가능한 일이에요.

좋은 제품을 만든 사람들의 이야기를 들어보면, 공통적으로 등장하는 요소가 있습니다. “사용자를 직접 관찰했다”는 거예요. 데이터만 보고 만든 제품과, 사용자를 직접 만나고 관찰한 뒤에 만든 제품은 미묘하지만 결정적인 차이가 있습니다. 전자는 “합리적으로 올바른” 제품이고, 후자는 “사용자의 마음에 닿는” 제품이에요. AI는 전자를 만드는 데 탁월하지만, 후자는 인간의 공감에서만 나올 수 있습니다.

그런데 한 가지 짚고 넘어갈 것이 있어요. 제품 감각은 타고나는 것일까요? 저는 아니라고 생각합니다. 제품 감각은 수많은 관찰과 실패의 경험에서 자라나는 것이에요. 사용자의 반응을 보고, “아, 내가 생각한 것과 다르구나”라고 깨닫는 순간이 쌓일수록 감각이 날카로워집니다. AI에게 “좋은 제품의 특징을 알려줘”라고 물으면 교과서적인 답을 줄 겁니다. 하지만 실제로 제품을 만들고, 사용자의 반응을 직접 보고, 때로는 처참한 실패를 경험하면서 체득하는 감각은 차원이 달라요.

이것은 개발자에게만 해당되는 이야기가 아닙니다. 영업 사원이 고객의 표정을 읽고 “이 제안은 먹히지 않겠다”고 직감하는 것, 디자이너가 화면을 보고 “여기서 사용자가 헤맬 것 같다”고 느끼는 것, 기획자가 데이터를 보고 “이 지표 뒤에 뭔가 다른 이야기가 숨어 있다”고 감지하는 것. 이 모든 것이 제품 감각의 발현이에요. 그리고 이 감각은 현장에 가까이 있을수록, 실패를 많이 경험할수록, 사용자와 직접 대화할수록 날카로워집니다.

“왜 이것을 만들어야 하는가”를 설명할 수 있는 사람

제품 감각과 함께, 또 하나 점점 중요해지는 역량이 있습니다. 바로 비즈니스 맥락을 이해하는 능력입니다.

기술자들 사이에서 가끔 이런 말을 듣습니다. “비즈니스는 기획자가 알아서 하는 거 아닌가요? 우리는 기술에만 집중하면 되지 않나요?” 비개발자 분들 사이에서는 반대의 말이 들리기도 해요. “기술적인 건 개발자가 알아서 하면 되잖아요. 우리는 비즈니스만 생각하면 되는 거 아닌가요?”

솔직히 저도 한때 그렇게 생각했던 시절이 있습니다. 기술과 비즈니스를 깔끔하게 분리할 수 있다고요. 하지만 경험이 쌓이면서, 그리고 AI 시대가 본격화되면서, 이 생각이 얼마나 위험한지를 깨닫게 되었어요.

“왜 이것을 만들어야 하는가”를 설명할 수 있는 사람. 이것이 AI 시대에 가장 귀한 인재입니다. 기술적으로 무엇이 가능한지를 알면서, 동시에 비즈니스적으로 무엇이 의미 있는지를 판단할 수 있는 사람. 이 두 세계를 연결할 수 있는 사람이요.

왜 그럴까요? AI가 “어떻게”를 빠르게 해결해주면서, “왜”와 “무엇을”에 대한 판단이 결과물의 가치를 결정짓는 핵심 변수가 되었기 때문입니다. 같은 AI 도구를 써도 어떤 팀은 시장을 뒤흔드는 제품을 만들고, 어떤 팀은 아무도 쓰지 않는 것을 만듭니다. 기술적 역량의 차이가 아니에요. “무엇을, 왜 만들 것인가”에 대한 판단의 차이에서 오는 겁니다.

비즈니스 맥락 이해는 거창한 것이 아닙니다. MBA 학위가 필요하거나, 재무제표를 읽을 줄 알아야 한다는 뜻이 아니에요. “우리 고객이 돈을 내는 이유가 뭔지”, “경쟁사가 하지 못하는 우리만의 강점이 뭔지”, “이 기능을 추가하면 매출에 어떤 영향이 있는지”, “이 시장이 앞으로 어떤 방향으로 움직일지”. 이런 질문에 대한 감각을 키우는 것이에요.

그리고 이 감각은 현장 경험과 비즈니스에 대한 호기심에서 자랍니다. 자기 팀의 업무만 들여다보는 것이 아니라, 회사 전체가 어떻게 돌아가는지를 궁금해하는 것. 경쟁사의 움직임을 눈여겨보는 것. 고객의 목소리에 귀를 기울이는 것. 이런 습관들이 비즈니스 맥락 이해력을 키워줍니다.

같은 도구, 다른 결과 – 무엇이 차이를 만드는가

이 장의 처음으로 돌아가볼까요. 같은 도구를 받고도 전혀 다른 결과물을 만들어낸 두 사람의 이야기입니다.

그 차이를 만든 것은 기술적 능력이 아니었습니다. “무엇이 진짜 문제인가”를 볼 수 있는 눈, “이것이 사용자에게 가치가 있는가”를 판단하는 감각, “왜 이것을 지금 만들어야 하는가”를 설명할 수 있는 통찰. 이 세 가지의 조합이었어요.

좀 더 구체적으로 풀어보겠습니다. 첫 번째 사람은 “이 도구로 뭘 만들 수 있지?”라는 질문에서 시작했어요. 기술 중심의 접근이죠. 도구의 기능을 탐색하고, 할 수 있는 것들을 나열하고, 그중에서 자신의 업무에 적용할 만한 것을 골랐습니다. 결과물은 나쁘지 않았어요. 기존 업무가 좀 더 빨라졌으니까요.

두 번째 사람은 다른 질문에서 시작했습니다. “우리 고객이 가장 불편해하는 게 뭐지?” 이 사람은 먼저 고객 서비스 기록을 뒤져봤어요. 고객 불만 전화를 직접 들어봤고, 영업팀의 이야기도 들었습니다. 그리고 아무도 주의를 기울이지 않았던 패턴을 발견했어요. “아, 고객들이 이 부분에서 계속 막히는구나. 이걸 해결하면 엄청나게 큰 가치를 만들 수 있겠다.” 그 다음에야 AI 도구를 꺼내 들었습니다. 도구는 같았지만, 겨냥한 곳이 달랐던 거예요.

그리고 이 세 가지는 서로 떨어져 있는 게 아닙니다. 문제 발견력, 제품 감각, 비즈니스 맥락 이해. 이것들은 하나의 역량 체계를 이룹니다. “무엇을 만들 것인가를 정의하는 능력”이라는 메타 역량의 세 측면인 셈이죠.

재미있는 것은, 이 역량이 개발자에게만 필요한 게 아니라는 점입니다. 기획자, 디자이너, 마케터, 경영진. 조직에서 “무엇을 만들 것인가”에 관여하는 모든 사람에게 필요한 역량이에요. 5장에서 이야기한 것처럼 개발자와 비개발자의 경계가 허물어지는 시대에, 이 역량은 모든 직군을 관통하는 공통 언어가 됩니다.

사실 이 점이 이 책이 개발자와 비개발자 모두를 독자로 삼은 이유이기도 합니다. “무엇을 만들 것인가”라는 질문은 특정 직군의 전유물이 아니에요. 마케터가 “우리 고객이 진짜 원하는 게 뭘까?”라고 물을 때, 디자이너가 “이 화면에서 사용자가 느끼는 감정이 뭘까?”라고 물을 때, 경영진이 “우리 회사가 정말 풀어야 할 문제는 뭘까?”라고 물을 때. 이 모든 질문이 문제 발견력의 발현입니다. 그리고 이 질문들이 하나로 모일 때, 비로소 정말 만들 가치가 있는 것이 정의됩니다.

개발 비용이 급감하고 누구나 만들 수 있는 시대. 이 시대에 “무엇을”이라는 질문에 답하지 못하면, 아무리 빠르게 만들어도 의미가 없습니다. 반대로, 이 질문에 명확히 답할 수 있다면, 만드는 것 자체는 AI의 도움으로 얼마든지 빨라질 수 있어요. 결국 승부는 “무엇을”에서 갈립니다.

전작의 메시지가 여기서 만납니다

이 대목에서 전작의 이야기를 다시 꺼내지 않을 수 없습니다. “코드 너머, 회사보다 오래 남을 개발자”에서 저는 경청과 질문의 중요성을 강조했습니다. 상대방의 말을 진심으로 듣는 것, 핵심을 꿰뚫는 질문을 던지는 것. 그때는 “소프트 스킬”이라는 이름으로 이야기했어요.

그런데 지금 와서 보면, 그것이 바로 “문제 발견력”의 기초였다는 걸 깨닫게 됩니다. 사용자의 말을 경청하는 것이 숨은 니즈를 발견하는 첫걸음이고, 핵심을 짚는 질문을 던지는 것이 올바른 문제를 정의하는 시작입니다. 회의에서 “그런데 이게 정말 사용자가 원하는 건가요?”라고 물을 수 있는 용기, 고객의 불만을 표면적 증상이 아니라 근본 원인의 실마리로 볼 수 있는 시야. 전작에서 다룬 소프트 스킬들이 AI 시대에는 더 높은 차원의 역량으로 승격되는 셈이죠.

어쩌면 이것이 이 책의 핵심 메시지일 수 있습니다. AI가 기술적 실행력의 상당 부분을 대신해주는 시대에, 정말 차이를 만드는 것은 “무엇을 만들어야 하는가”를 정의하는 능력입니다. 그리고 그 능력의 뿌리는 다름 아닌 인간적 역량, 공감, 소통, 통찰, 판단에 있습니다.

“코드만 잘 짜면 되는 거 아니야?”라는 전작의 질문이, 이제는 “코드는 AI가 짜주는데, 그 다음은?”이라는 질문으로 진화했습니다. 그리고 그 답은 놀랍게도 같은 방향을 가리키고 있어요. 기술을 넘어선 인간적 역량으로요.

이것은 우연이 아니라고 생각합니다. 기술이 발전하면 할수록, 기술로 해결할 수 없는 영역의 가치가 올라가는 것은 어쩌면 불변의 법칙인지도 몰라요. 기계가 육체노동을 대신했을 때 지적 노동의 가치가 올라갔고, 컴퓨터가 계산을 대신했을 때 분석과 판단의 가치가 올라갔고, 이제 AI가 지적 노동의 상당 부분을 대신하면서 공감, 창의성, 윤리적 판단 같은 가장 인간적인 역량의 가치가 올라가고 있습니다.

전작에서 다룬 “회복탄력성”도 여기서 새로운 의미를 갖습니다. 문제 발견은 때로 실패를 동반하거든요. “이것이 진짜 문제다”라고 확신하고 달려들었는데, 알고 보니 아니었던 경험. 사용자가 원하는 것이 이것일 거라고 생각했는데, 완전히 빗나간 경험. 이런 실패를 겪고도 다시 일어나서 다음 문제를 찾아나서는 힘. 그것이 회복탄력성이고, 문제 발견자에게 필수적인 역량입니다.

문제 발견력을 키우는 다섯 가지 관점

그렇다면 이 “문제 발견력”이라는 것을 어떻게 키울 수 있을까요? 거창한 프로그램이나 비싼 교육이 필요한 건 아닙니다. 관점을 바꾸는 것에서 시작할 수 있어요. 몇 가지 실천적인 관점을 나눠보겠습니다.

첫째, 현장에 가까이 머무르세요. 데이터는 과거를 보여주지만, 현장은 미래를 보여줍니다. 사용자가 제품을 사용하는 실제 모습을 관찰하면, 데이터에서는 보이지 않는 불편과 기회를 발견할 수 있어요. “왜 이 기능을 안 쓰지?”가 아니라 “이 사람이 진짜로 하고 싶은 일이 뭐지?”를 물어보세요. 대시보드의 숫자 뒤에 숨어 있는 사람의 얼굴을 떠올리는 습관. 이것이 문제 발견의 시작입니다.

개발자라면, 고객 지원 로그를 가끔 들여다보세요. 고객이 어떤 표현으로 불만을 토로하는지, 어떤 기능에서 자주 막히는지를 직접 확인하는 것만으로도 많은 인사이트를 얻을 수 있습니다. 비개발자라면, 여러분이 매일 겪는 업무의 불편함을 기록해보세요. “이건 왜 이렇게 불편하지?”라는 느낌이 드는 순간이 바로 문제 발견의 순간이에요.

둘째, 다른 분야에 호기심을 가지세요. 문제 발견은 종종 서로 다른 분야의 교차점에서 일어납니다. 기술만 파고드는 것이 아니라, 비즈니스, 심리학, 디자인, 사회학 등 다양한 분야에 안테나를 세워두면 남들이 보지 못하는 문제를 발견할 수 있습니다. Microsoft의 5C에서 첫 번째로 호기심(Curiosity)을 꼽은 것이 우연이 아닙니다.

행동경제학 책을 읽다가 “우리 앱의 결제 흐름에 이 원리를 적용하면 어떨까?”라는 아이디어가 떠올 수 있어요. 심리학 팟캐스트를 듣다가 “사용자가 이 화면에서 이탈하는 이유가 인지 부하 때문이 아닐까?”라는 가설을 세울 수도 있고요. 이런 분야 간 연결은 AI가 잘하지 못하는 영역이에요. 왜냐하면 AI는 명시적으로 질문받은 것에 대해서만 분석하지만, 인간은 일상 속에서 무의식적으로 연결고리를 만들어내기 때문입니다.

셋째, “왜?”를 다섯 번 물어보세요. 도요타의 유명한 “5 Whys” 기법입니다. 표면적인 문제 뒤에 숨은 근본 원인을 파고드는 습관이에요. “매출이 줄었다”에서 멈추지 말고, 왜 줄었는지, 그 원인은 왜 생겼는지, 계속 파고 들어가면 진짜 해결해야 할 문제가 보입니다. 처음 보이는 문제와 다섯 번째 “왜?”를 통해 도달한 문제는 대부분 전혀 다른 것이에요.

예를 들어볼까요. “앱 다운로드 수가 줄었다.” 왜? “광고 효율이 떨어졌다.” 왜? “클릭률은 높은데 설치까지 이어지지 않는다.” 왜? “앱스토어 리뷰 점수가 낮아졌다.” 왜? “최근 업데이트 후 특정 기기에서 크래시가 발생한다.” 처음에는 마케팅 문제처럼 보였던 것이, 다섯 번의 “왜”를 거치니 기술적 문제로 드러났습니다. 문제의 진짜 모습은 표면에 잘 드러나지 않아요.

넷째, 불편함에 주목하세요. 일상에서 “이건 왜 이렇게 불편하지?”, “이건 좀 더 나을 수 있지 않을까?”라는 느낌이 드는 순간을 놓치지 마세요. 그 불편함이 바로 문제이고, 그 문제를 해결하는 것이 가치를 만드는 시작입니다. 대부분의 사람은 불편함에 적응합니다. “원래 그런 거지”라고 생각하고 넘어가죠. 하지만 문제 발견자는 그 불편함에 머무릅니다. “왜 원래 이래야 하지? 더 나은 방법이 있지 않을까?”라고요.

다섯째, 해결책부터 생각하지 마세요. 이것은 정말 빠지기 쉬운 함정이고, 솔직히 저도 여전히 자주 빠지는 함정입니다. 특히 기술을 잘 아는 사람일수록 더 그래요. 새로운 기술이나 도구를 보면 “이걸로 뭘 만들 수 있지?”라는 생각이 자동으로 떠오르거든요. 하지만 좋은 제품은 “이 기술을 쓰면 뭘 만들 수 있을까?”에서 시작하지 않습니다. “이 사람들이 겪고 있는 문제가 뭘까?”에서 시작해요. 기술은 문제를 발견한 다음에 꺼내도 늦지 않습니다. 오히려 문제를 먼저 명확히 정의하면, 그에 맞는 최적의 기술을 훨씬 잘 선택할 수 있어요.

조직 차원의 문제 발견력

지금까지 주로 개인의 역량으로서 문제 발견력을 이야기했습니다. 하지만 현실에서 큰 문제는 혼자 발견하기 어려운 경우가 많아요. 조직 차원의 문제 발견력도 중요합니다.

한번 생각해보세요. 개발팀은 기술적 부채를 가장 잘 알고, 마케팅팀은 고객의 인식 변화를 가장 먼저 감지하고, 영업팀은 시장의 온도를 가장 가까이서 느끼고, 고객 지원팀은 사용자의 불만을 가장 직접적으로 접합니다. 정말 가치 있는 문제를 발견하려면, 이 모든 관점이 교차해야 해요. 기술적으로 해결 가능하고, 사용자가 절실히 원하고, 비즈니스적으로 의미 있는 문제. 이런 “황금 교차점”은 한 팀의 시야만으로는 찾기 어렵습니다.

그래서 조직 차원에서 문제 발견력을 키우려면, 부서 간의 벽을 낮추는 것이 중요합니다. 개발자가 고객 인터뷰에 참여하고, 마케터가 기술 데모에 참석하고, 기획자가 장애 대응 과정을 지켜보는 것. 이런 교차 경험이 “아, 그 문제가 이쪽에서는 이렇게 보이는구나”라는 깨달음을 줍니다. 그리고 그 깨달음이 쌓이면, 어느 한 팀에서는 절대 발견하지 못했을 문제가 보이기 시작해요.

AI가 이 과정을 도울 수 있습니다. 각 팀이 수집한 데이터를 통합 분석하고, 숨겨진 패턴을 찾아내고, 이상 신호를 감지하는 것은 AI가 잘하는 일이에요. 하지만 그 분석 결과를 보고 “이것이 풀어야 할 문제인가?”를 판단하는 것, 그리고 “우리 조직이 이 문제를 풀기에 적합한가?”를 평가하는 것은 사람의 몫입니다. 데이터가 보여주는 것과 데이터가 보여주지 못하는 것 사이의 간극을 메우는 것이 조직 속 사람들의 역할이에요.

EY(Ernst & Young)가 “AI 시대에 인간 스킬을 중심으로 업무를 재설계해야 한다”고 강조한 것도 이 맥락입니다. AI가 분석과 실행의 속도를 높여주면, 인간은 방향 설정과 판단에 더 집중할 수 있게 됩니다. 조직 차원에서 이 분업이 잘 이루어지면, “무엇을 만들 것인가”에 대한 답의 품질이 달라집니다.

BCG의 “증강된 조직” 개념이 여기서도 적용됩니다. 4장에서 이야기한 것처럼, AI가 분석과 실행을 맡고 인간이 판단과 방향 설정을 맡는 구조. 이것이 조직 차원의 문제 발견에서도 동일하게 작동합니다. AI가 데이터 속에서 이상 패턴을 감지하면, 각 부서의 전문가들이 그 패턴이 의미하는 바를 해석하고, 그것이 풀어야 할 문제인지를 판단하는 거예요.

여기서 한 가지 현실적인 당부를 드리고 싶어요. 조직에서 문제 발견력을 키우려면, “틀린 질문”에 대한 관용이 필요합니다. “잠깐, 이게 진짜 문제가 맞나요?”라는 질문을 던졌는데, 그 질문이 결과적으로 틀렸다고 해서 비난받는 환경에서는 아무도 질문을 던지지 않게 돼요. 좋은 질문은 많은 틀린 질문 속에서 나옵니다. 심리적 안전감이 보장된 조직에서만 문제 발견력이 꽃필 수 있어요. 전작에서 강조했던 “심리적 안전감”이 여기서도 핵심 조건이 되는 셈이죠.

AI 시대의 진짜 경쟁력

이 장의 제목은 “무엇을 만들 것인가”입니다. 하지만 더 정확하게 말하면, 이 질문을 던지고 답을 찾아가는 과정 자체가 AI 시대의 진짜 경쟁력입니다.

AI가 코드를 짜고, 디자인을 하고, 테스트를 돌리고, 배포까지 도와주는 세상. 이 세상에서 “만드는 능력”의 가치는 점점 희석됩니다. 누구나 만들 수 있으니까요. 5장에서 본 것처럼 비개발자도 앱을 만들 수 있는 시대가 되었잖아요. 하지만 “만들 가치가 있는 것을 찾아내는 능력”의 가치는 점점 올라갑니다. 그 능력을 가진 사람이 희소하니까요.

소프트웨어 개발의 경제학이 재편되고 있습니다. 개발 비용이 급감하면서, 더 많은 실험이 가능해졌어요. 하지만 실험의 방향을 정하는 것, 수많은 가능성 중에서 정말 추구할 가치가 있는 것을 골라내는 것. 이것이 병목이자 기회입니다.

당연히 불안하실 수 있습니다. “나는 지금까지 기술을 열심히 갈고닦았는데, 이제 와서 제품 감각이라니, 비즈니스 이해라니.” 충분히 이해합니다. 하지만 다시 한번 생각해보세요. 문제를 발견하고, 사용자에 공감하고, 비즈니스 맥락을 이해하는 것. 이것들은 여러분이 매일 업무 속에서 이미 하고 있는 일입니다. 다만 그것의 가치를 스스로 인정하지 않았을 뿐이에요.

동료가 올린 코드를 리뷰하면서 “이 로직은 사용자 관점에서 직관적이지 않을 것 같은데”라고 코멘트한 적 있으시죠? 그게 제품 감각이에요. 기획 회의에서 “이 기능을 먼저 만드는 게 매출에 더 도움이 될 것 같다”고 의견을 낸 적이 있다면? 그게 비즈니스 맥락 이해입니다. 고객의 불만을 듣고 “이건 단순한 불만이 아니라, 우리 서비스의 구조적 문제를 드러내는 신호다”라고 느낀 적이 있다면? 그게 문제 발견력이에요. 이미 하고 있는 일을, 더 의식적으로, 더 체계적으로 하면 됩니다.

앤드류 응(Andrew Ng)의 말을 빌리자면, “AI 시대에는 무엇을 아는가보다 얼마나 빨리 배우는가가 중요”합니다. 그리고 저는 여기에 한 가지를 더 보태고 싶어요. “얼마나 빨리 배우는가”만큼이나, “무엇을 배울 것인가를 결정하는 판단력”이 중요하다고요. 수많은 배움의 기회 중에서 정말 가치 있는 것을 골라내는 능력. 이것도 결국 문제 발견력의 연장선에 있는 역량입니다.

마무리

“만들 수 있느냐”의 시대에서 “무엇을 만들 것인가”의 시대로. 이것은 위기가 아니라 기회입니다. 기술적 진입 장벽이 낮아지면서, 진짜 가치를 만들어내는 사람과 그렇지 못한 사람 사이의 차이는 오히려 더 선명해질 겁니다. 그리고 그 차이를 만드는 것은 코드가 아니라 관점입니다.

무엇이 문제인지 볼 수 있는 눈. 그 문제가 누구에게 중요한지 느낄 수 있는 마음. 왜 지금 이것을 만들어야 하는지 설명할 수 있는 통찰. 이 세 가지를 가진 사람이, AI 시대의 진짜 경쟁력을 가진 사람입니다. 그리고 다행히도, 이 역량들은 타고나는 것이 아니라 키워나갈 수 있는 것들이에요.

내일 아침 출근하시면, 한 가지만 해보시면 좋겠습니다. 하루 동안 “이건 왜 이렇게 하고 있지?”, “이것의 진짜 문제는 뭘까?”라는 질문을 의식적으로 던져보세요. 동료의 요청을 받을 때, 고객의 피드백을 읽을 때, 회의에 참석할 때. 표면적인 요구사항 뒤에 숨은 진짜 니즈를 찾아보세요. 그 하루의 연습이 문제 발견력을 키우는 첫걸음입니다.

그렇다면 이런 능력을 가지고 AI와 어떻게 함께 일해야 할까요? 문제를 발견했다면, 그 다음은 AI와 협력해서 해결해나가는 과정이 필요합니다. 다음 장에서는 AI를 도구가 아닌 팀원으로 다루는 법, 오케스트레이션의 기술에 대해 이야기하겠습니다. “잘 시키는 법”이 아니라 “함께 일하는 법”에 관한 이야기입니다.

7장. AI와 함께 일하는 법 – 오케스트레이션의 기술

당신 앞에 오케스트라가 있다고 상상해보세요. 바이올린, 첼로, 플루트, 트럼펫 – 각각이 뛰어난 연주자입니다. 그런데 지휘자가 없으면 어떻게 될까요? 아무리 훌륭한 연주자들이라도 제각각 다른 박자로, 다른 곡을 연주하기 시작할 겁니다. 소음이 되는 거죠.

AI와 함께 일한다는 것은 바로 이 지휘자의 자리에 서는 것과 같습니다. AI라는 놀라운 연주자들이 점점 늘어나고 있는데, 정작 그들을 조율할 수 있는 사람은 드물거든요. “AI를 잘 쓴다”는 말의 의미가 달라지고 있습니다. 단순히 프롬프트를 잘 쓰는 것을 넘어, AI라는 팀원을 이해하고, 역할을 나누고, 결과를 검증하는 총체적인 역량이 필요한 시대가 된 겁니다.

이번 장에서는 그 역량의 실체를 구체적으로 들여다보려고 합니다. AI와 경쟁하는 것이 아니라 AI를 지휘하는 법, 그리고 그 과정에서 인간만이 발휘할 수 있는 가치가 무엇인지를 함께 살펴보시죠.

경쟁이 아니라 지휘입니다

“AI가 당신을 대체하지 않습니다. AI를 사용하는 사람이 대체합니다.”

이 문장을 들어보신 적 있으시죠? 처음 들었을 때는 좀 막연하게 느껴질 수 있어요. ‘그래서 AI를 어떻게 사용하라는 건데?’ 하는 생각이 드는 게 당연합니다. 저도 처음에는 그랬거든요.

그런데 이 문장의 핵심은 “사용”이라는 단어에 있지 않습니다. “대체”라는 단어에 있어요. AI와 경쟁하려는 사람은 결국 지게 되어 있습니다. AI가 코드를 더 빨리 생성하고, 버그를 더 빨리 찾고, 테스트를 더 빨리 작성하는 것은 이미 현실이니까요. Anthropic의 2026 보고서에 따르면, 개발자들이 업무의 약 60%에서 AI를 사용하고 있습니다. 보일러플레이트 코드 생성은 62%, 버그 수정은 58%, 테스트 작성은 57%가 이미 AI의 도움을 받고 있어요.

그런데 여기서 흥미로운 숫자가 하나 있습니다. AI에게 “완전히 위임”할 수 있는 작업은 고작 0%에서 20% 사이라는 거예요. 60%나 사용하면서도 완전 위임은 20%도 안 된다? 이 간극이 말해주는 것이 있습니다.

AI는 혼자서 완결적으로 일하지 못합니다. 적어도 아직은요. 그래서 필요한 것이 “오케스트레이션” – 조율의 기술입니다. 경쟁하는 것이 아니라 지휘하는 겁니다. 바이올린과 경쟁하는 지휘자는 없잖아요. 지휘자의 일은 각 악기의 특성을 이해하고, 적절한 타이밍에 적절한 역할을 부여하며, 전체가 하나의 아름다운 곡을 만들어내도록 이끄는 것입니다.

AI와의 관계도 마찬가지예요. AI가 잘하는 영역을 정확히 파악하고, 그 영역에서는 충분히 맡기되, AI가 약한 영역에서는 인간이 개입해서 방향을 잡아주는 것. 이것이 오케스트레이션의 본질입니다.

한 가지 더 짚어두고 싶은 것이 있어요. “지휘”라는 표현이 자칫 AI를 단순한 도구로 격하하는 것처럼 들릴 수 있는데, 실제로는 그 반대입니다. 좋은 지휘자는 연주자를 존중합니다. 각 악기가 가장 빛나는 순간을 알고, 그 순간을 만들어주죠. AI와의 관계도 마찬가지입니다. AI의 강점을 존중하고, 그 강점이 최대한 발휘될 수 있는 환경을 만들어주는 것. 그것이 진정한 오케스트레이션이에요.

“거의 맞지만 완전하지 않은” – AI의 솔직한 성적표

AI와 함께 일해본 분이라면 이런 경험이 있으실 겁니다. AI가 만들어준 코드를 보면서 “오, 꽤 괜찮은데?” 하다가, 자세히 들여다보면 미묘하게 틀린 부분이 있는 거예요. 변수명이 살짝 엉뚱하다거나, 엣지 케이스를 놓쳤다거나, 비즈니스 로직의 뉘앙스를 제대로 반영하지 못했다거나.

이건 비개발자 분들도 마찬가지입니다. AI에게 기획서 초안을 부탁했는데, 읽어보면 그럴듯한 문장들이 나열되어 있지만 “우리 회사의 맥락”이 빠져 있는 느낌. 보고서를 요청했는데, 숫자는 맞는 것 같은데 “그래서 뭘 해야 하는지”에 대한 판단이 없는 느낌. 이런 경험 있으시죠?

실제로 개발자의 66%가 AI에 대해 가장 크게 느끼는 불만이 바로 이것입니다 – “거의 맞지만 완전하지 않은” 결과물. 이 숫자가 시사하는 바는 큽니다. AI의 문제가 “못한다”가 아니라 “거의 한다”에 있다는 뜻이거든요.

“거의 맞다”는 건 사실 꽤 난감한 상황이에요. 완전히 틀리면 차라리 버리고 처음부터 다시 하면 됩니다. 그런데 90%가 맞고 10%가 틀리면? 그 10%를 찾아내는 것이 오히려 더 어렵고, 더 많은 전문성을 요구합니다. 마치 교정 편집자가 글을 처음부터 쓰는 것보다 남의 글에서 미세한 오류를 찾는 것이 더 어려운 것처럼요.

이것이 바로 AI 시대에 인간의 역할이 “생산자”에서 “감독자”와 “평가자”로 이동하는 이유입니다. 직접 만드는 일은 줄어들지만, 만들어진 것을 판단하고 교정하는 일은 오히려 늘어납니다. 그리고 이 판단과 교정은 해당 분야에 대한 깊은 이해 없이는 불가능한 일이에요.

한번 생각해보세요. AI가 생성한 코드의 품질을 평가하려면 좋은 코드가 무엇인지 알아야 합니다. AI가 만든 기획서를 검증하려면 비즈니스 맥락을 이해하고 있어야 합니다. AI가 작성한 분석 보고서의 타당성을 따지려면 데이터를 읽는 눈이 있어야 합니다. 결국 AI가 아무리 발전해도, “이것이 정말 괜찮은 결과물인가”를 판단하는 사람의 역량은 사라지지 않습니다. 오히려 그 역량의 가치가 더 올라가는 거죠.

여기서 한 가지 중요한 사실을 더 짚어야 합니다. “거의 맞지만 완전하지 않은” 결과물의 위험성은 분야마다 다릅니다. 개인 블로그에 올릴 글이라면 AI가 만든 초안을 약간만 다듬어도 괜찮을 수 있어요. 하지만 금융 시스템의 코드나 의료 관련 분석이라면, 그 10%의 오류가 치명적인 결과를 가져올 수 있습니다. 어떤 작업에서 AI를 얼마나 신뢰할 것인가를 판단하는 것 자체가 하나의 중요한 역량이에요. 이 판단을 잘하는 사람과 못하는 사람의 차이가, AI 시대의 전문가와 아마추어를 가를 겁니다.

프롬프트를 넘어 – AI 리터러시의 진짜 의미

“프롬프트 엔지니어링”이라는 말이 한동안 크게 유행했습니다. AI에게 좋은 결과를 얻기 위해 질문을 정교하게 설계하는 기술이죠. 물론 중요합니다. 하지만 그것만으로는 부족해요.

비유를 하나 들어볼게요. 프롬프트 엔지니어링이 “AI에게 좋은 질문을 하는 기술”이라면, AI 리터러시는 “AI라는 존재 자체를 이해하는 능력”입니다. 마치 좋은 관리자가 팀원 개개인의 강점과 약점, 성격과 동기를 이해하는 것처럼요.

AI 리터러시가 실제로 의미하는 것은 이런 겁니다.

첫째, AI가 잘하는 것과 못하는 것의 경계를 아는 것입니다. AI는 패턴 기반의 작업에 탁월하지만, 맥락을 깊이 이해하고 판단하는 영역에서는 여전히 한계가 있습니다. 이 경계를 정확히 알아야 적절한 작업을 맡길 수 있어요. 마치 팀에 엑셀의 달인이 있다면, 그 사람에게 데이터 분석은 맡기되 고객 대면 프레젠테이션은 맡기지 않는 것처럼요.

둘째, AI의 결과를 비판적으로 평가하는 눈을 갖는 것입니다. AI가 “자신 있게” 말한다고 해서 그것이 반드시 옳은 것은 아닙니다. AI는 확률적으로 가장 그럴듯한 답을 생성하는 시스템이지, 진실을 보장하는 시스템이 아니거든요. 이 차이를 이해하는 것이 중요합니다.

셋째, AI와의 협업 패턴을 상황에 맞게 설계하는 것입니다. 모든 작업에 같은 방식으로 AI를 활용할 수는 없어요. 어떤 작업은 AI에게 초안을 맡기고 인간이 다듬는 것이 효율적이고, 어떤 작업은 인간이 뼈대를 잡고 AI가 살을 붙이는 것이 나을 수 있습니다. 또 어떤 작업은 AI를 아예 쓰지 않는 것이 더 빠를 수도 있고요.

넷째, AI 기술의 발전 방향을 읽는 것입니다. 지금은 AI가 못하는 것이 내년에는 가능해질 수 있어요. 반대로, AI가 잘한다고 알려진 것이 특정 맥락에서는 여전히 미흡할 수도 있습니다. 이 변화의 흐름을 파악하고, 자신의 업무 방식을 지속적으로 조정하는 것도 AI 리터러시의 중요한 부분입니다.

이런 종합적인 판단을 할 수 있는 능력, 그것이 진정한 AI 리터러시입니다. 프롬프트를 잘 쓰는 것은 그 중 일부일 뿐이에요. 2026 한국 직업 트렌드에서 AI 리터러시를 7대 핵심 역량의 첫 번째로 꼽은 이유도 여기에 있습니다. 단순한 도구 사용법이 아니라, AI와 공존하는 시대를 살아가는 기본 소양이 된 거예요.

한 가지 비유를 더 들어볼게요. 운전을 생각해보세요. 운전을 잘한다는 것은 핸들과 페달 조작법을 아는 것만이 아닙니다. 도로 상황을 읽고, 다른 차량의 움직임을 예측하고, 날씨와 노면 상태에 따라 운전 방식을 조절하고, 목적지까지의 경로를 선택하는 것까지 포함하죠. AI 리터러시도 마찬가지예요. AI라는 “차량”의 조작법만 아는 것이 아니라, AI가 놓인 “도로 환경” 전체를 이해하고, 상황에 맞게 판단하고 대응하는 능력이 필요합니다.

단일 에이전트에서 멀티에이전트로 – 조율의 복잡성

AI 기술의 발전 방향을 보면, 하나의 AI가 모든 것을 처리하는 모델에서, 여러 AI 에이전트가 협력하여 작업을 수행하는 모델로 빠르게 이동하고 있습니다. Anthropic 보고서가 짚은 8대 트렌드 중 하나가 바로 “단일 에이전트에서 조율된 멀티에이전트 팀으로의 진화”예요.

이것은 마치 프리랜서 한 명에게 프로젝트를 맡기던 것에서, 여러 전문가로 구성된 팀에 프로젝트를 맡기는 것으로 바뀌는 것과 비슷합니다. 결과물의 질은 올라갈 수 있지만, 조율의 복잡성도 함께 올라가죠.

Rakuten의 사례를 보세요. Claude Code가 1,250만 줄 규모의 오픈소스 라이브러리에서 7시간 동안 자율적으로 작업하여 복잡한 엔지니어링 태스크를 완수했습니다. 99.9%의 정확도로요. 이것은 놀라운 성과이지만, 여기서 주목해야 할 것은 “AI가 혼자 다 했다”가 아닙니다. 누군가가 그 작업의 범위를 정의하고, 목표를 설정하고, 결과를 검증했다는 사실이에요.

또 하나 주목할 트렌드가 있습니다. 장기 실행 에이전트의 등장이에요. AI가 몇 시간이 아니라 며칠 단위로 자율적으로 작업하는 시대가 오고 있습니다. 이렇게 되면 인간의 감독 방식도 근본적으로 달라져야 합니다. 매 순간 지켜보는 것은 불가능하니까요. 대신, 핵심적인 체크포인트를 설정하고, AI의 진행 상황을 주기적으로 확인하며, 방향이 틀어졌을 때 빠르게 교정하는 능력이 필요해집니다.

멀티에이전트 시대가 오면 이 조율의 역할은 더욱 중요해집니다. 코드를 작성하는 에이전트, 테스트를 실행하는 에이전트, 코드 리뷰를 하는 에이전트, 배포를 관리하는 에이전트가 각각 존재한다면, 이들 사이의 워크플로우를 설계하고 관리하는 것은 누구의 몫일까요?

바로 인간입니다. 그리고 이것이 “AI와 함께 일하는 법”의 가장 진보한 형태예요. 개별 AI를 잘 다루는 것에서, 여러 AI의 협업을 설계하고 조율하는 것으로. 개발자의 역할이 “코드를 짜는 사람”에서 “AI 팀을 지휘하는 사람”으로 진화하는 거죠.

비개발자 분들도 마찬가지입니다. 마케팅 캠페인을 기획할 때 카피를 쓰는 AI, 이미지를 생성하는 AI, 데이터를 분석하는 AI를 각각 활용하고 그 결과를 하나의 캠페인으로 엮어내는 것 – 이것도 오케스트레이션이에요. 영업 담당자가 고객 데이터 분석 AI, 제안서 작성 AI, 미팅 준비 AI를 조합하여 최적의 영업 전략을 세우는 것도 마찬가지고요.

흥미로운 점은, 이 멀티에이전트 조율이라는 개념이 우리에게 완전히 새로운 것이 아니라는 겁니다. 사실 우리는 이미 “멀티에이전트 조율”을 매일 하고 있어요. 다만 그 에이전트가 사람이었을 뿐이죠. 프로젝트 매니저가 디자이너, 개발자, 마케터의 작업을 조율하는 것. 리더가 팀원들의 역할을 분배하고 결과를 통합하는 것. 이 경험과 역량이 AI 에이전트 조율에도 그대로 적용됩니다. 사람을 잘 이끌어본 경험이 있는 사람이, AI를 잘 이끌 가능성도 높은 이유가 여기에 있어요.

인간 감독의 기술 – 지능적 협업이란

“감독”이라는 단어가 좀 딱딱하게 느껴질 수 있습니다. 마치 감시하듯 AI의 어깨 너머를 들여다보고 있는 이미지가 떠오를 수 있으니까요. 하지만 제가 말하는 감독은 그런 것이 아닙니다.

Anthropic이 제시하는 “지능적 협업을 통한 인간 감독 확장”이라는 개념이 있어요. 핵심은, AI가 발전할수록 인간의 감독 방식도 함께 진화해야 한다는 것입니다. 코드 한 줄 한 줄을 검토하는 것이 아니라, 전체적인 방향과 품질 기준을 설정하고, AI가 그 기준 안에서 자율적으로 일할 수 있도록 환경을 만들어주는 것이죠.

이것은 좋은 리더의 모습과 닮아 있습니다. 마이크로매니징을 하는 리더는 팀원의 능력을 활용하지 못합니다. 반면 방향만 제시하고 신뢰하되, 핵심적인 결정 지점에서는 반드시 확인하는 리더는 팀의 역량을 극대화하죠. AI와의 관계도 마찬가지예요.

실무에서 이것은 구체적으로 이렇게 작동합니다.

먼저, 작업의 맥락과 제약 조건을 명확히 전달합니다. “이 기능을 만들어줘”가 아니라, “이런 비즈니스 맥락에서, 이런 사용자를 위해, 이런 제약 조건 하에서 이 기능이 필요해”라고 전달하는 거예요. AI에게 더 풍부한 맥락을 줄수록 결과물의 질이 올라갑니다. 이건 사람 사이의 소통에서도 마찬가지잖아요. “그냥 알아서 해줘”라고 말하면 원하는 결과가 나오기 어렵습니다. AI도 똑같아요.

다음으로, 결과물의 평가 기준을 미리 설정합니다. 코드라면 성능 기준, 보안 요구사항, 코딩 컨벤션 등을 명시해요. 기획서라면 포함되어야 할 항목, 톤앤매너, 분량 등을 정합니다. 기준이 명확할수록 AI의 결과물도 명확해지고, 평가도 수월해집니다. “좋은 코드를 짜줘”라는 애매한 요청보다 “이 프로젝트의 코딩 컨벤션을 따르고, 에러 핸들링을 포함하며, 단위 테스트를 함께 작성해줘”라는 구체적인 요청이 훨씬 나은 결과를 가져옵니다.

그리고, 단계적으로 검증합니다. 처음부터 최종 결과물을 받으려 하지 말고, 중간 산출물을 확인하면서 방향을 조정하는 것이 좋습니다. AI에게 먼저 설계를 보여달라고 한 뒤, 설계가 괜찮으면 구현을 요청하고, 구현 결과를 리뷰한 뒤 개선 사항을 피드백하는 방식이죠. 이 반복적인 협업 사이클이 좋은 결과를 만듭니다. 소프트웨어 개발에서 애자일 방법론이 폭포수 모델보다 나은 것과 같은 이유예요.

마지막으로, AI가 틀릴 수 있다는 전제를 항상 유지합니다. 이것은 AI를 불신하라는 뜻이 아닙니다. 좋은 동료와 일할 때도 서로의 작업을 리뷰하잖아요. 같은 원리입니다. 신뢰하되 검증하는 것, 이것이 건강한 인간-AI 협업의 기본 자세예요.

“AI 없이는 시도조차 하지 않았을 일” – 가능성의 확장

여기서 한 가지 놓치기 쉬운, 그러나 매우 중요한 이야기를 하려고 합니다. AI에 대한 논의가 대부분 “기존 업무를 AI가 어떻게 바꾸는가”에 초점을 맞추고 있는데, 사실 더 흥미로운 변화는 다른 곳에 있어요.

Anthropic 보고서에 따르면, AI 지원 작업의 약 27%는 “AI가 없었다면 시도조차 하지 않았을 작업”입니다. 이 숫자의 의미를 한번 곱씹어보세요.

AI가 기존 업무를 효율화하는 것만이 전부가 아니라는 뜻입니다. AI가 열어준 가능성의 공간이 있다는 거예요. 예전에는 엄두도 내지 못했던 프로젝트, 시간이 부족해서 포기했던 아이디어, 기술적 장벽 때문에 미뤄두었던 시도가, AI의 도움으로 현실이 되고 있는 겁니다.

비개발자인 마케터가 자신의 아이디어를 직접 프로토타입으로 만들어보는 것. 소규모 팀이 대기업 수준의 데이터 분석을 시도하는 것. 혼자서 일하는 프리랜서가 여러 전문 분야를 아우르는 프로젝트를 수행하는 것. 1인 창업자가 개발팀 없이도 서비스의 MVP를 만들어보는 것. 현업 담당자가 “이런 도구가 있으면 좋겠는데”라는 생각을 실제 프로토타입으로 구현해보는 것. 이 모든 것이 “AI 없이는 시도조차 하지 않았을 일”에 해당합니다.

이런 관점에서 보면, AI와 함께 일하는 법을 배우는 것은 단순히 업무 효율을 높이는 차원의 이야기가 아닙니다. 자신의 가능성의 영역을 넓히는 일이에요. “나는 이것밖에 못해”라는 한계를 “이것도 한번 해볼까?”로 바꾸는 것, 그것이 AI 리터러시의 가장 설레는 측면이 아닐까요.

SDLC, 즉 소프트웨어 개발 생명 주기가 주 단위에서 시간 단위로 압축되고 있다는 Anthropic의 분석도 같은 맥락에서 읽을 수 있습니다. 개발 속도가 빨라진다는 것은 단순히 “같은 일을 더 빨리 한다”는 의미가 아닙니다. “더 많은 시도를 할 수 있다”는 의미이기도 해요. 실험의 비용이 낮아지면 실험의 횟수가 늘어나고, 실험이 늘어나면 혁신의 확률도 올라갑니다. 이것이 소프트웨어 개발 경제학의 재편이 가져오는 진짜 변화입니다.

보안 우선이라는 새로운 원칙

오케스트레이션을 이야기할 때 빼놓을 수 없는 주제가 있습니다. 바로 보안이에요.

Anthropic이 제시한 8대 트렌드의 마지막이 “보안 우선 아키텍처의 필요”인 것은 우연이 아닙니다. AI가 코드를 생성하고 시스템에 접근하는 범위가 넓어질수록, 보안의 중요성은 기하급수적으로 커집니다. AI가 만든 코드에 취약점이 있다면? AI 에이전트가 접근하면 안 되는 데이터에 접근한다면? 이런 시나리오는 이론적인 우려가 아니라 현실적인 도전입니다.

오케스트레이터의 역할에는 이 보안적 관점이 반드시 포함되어야 합니다. AI가 생성한 코드의 보안 취약점을 확인하는 것, AI 에이전트의 권한 범위를 적절히 설정하는 것, 민감한 데이터가 AI 처리 과정에서 노출되지 않도록 관리하는 것 – 이 모든 것이 오케스트레이터의 책임이에요.

솔직히 이 부분은 좀 번거롭게 느껴질 수 있습니다. AI를 써서 빠르게 일하려는 건데, 보안 검토까지 해야 한다니. 하지만 이 번거로움을 건너뛰면 나중에 훨씬 더 큰 문제가 됩니다. AI 시대의 보안 사고는 기존 보안 사고와 규모와 속도가 다를 수 있거든요. AI가 빠르게 일하는 만큼, 문제가 발생했을 때 확산되는 속도도 빠릅니다.

결국 좋은 오케스트레이터는 “빠르게”만 추구하지 않습니다. “안전하게 빠르게”를 추구해요. 이 균형 감각도 오케스트레이션의 중요한 부분입니다.

실전 가이드 – 개발자를 위한 AI 협업법

이론적인 이야기는 여기까지 하고, 이제 구체적인 실천법으로 들어가볼게요. 먼저 개발자분들을 위한 내용입니다.

첫 번째, AI에게 “무엇을”이 아니라 “왜”를 먼저 설명하세요.

“로그인 기능 만들어줘”보다 “우리 서비스는 B2B SaaS이고, 보안이 특히 중요한 금융 고객을 주로 다루고 있어. SSO와 MFA를 지원하는 인증 시스템이 필요해. 기존에 사용하던 라이브러리는 이것이고, 현재 아키텍처는 이렇게 되어 있어”라고 말하는 것이 훨씬 좋은 결과를 가져옵니다. AI에게 맥락을 충분히 전달할수록, “거의 맞지만 완전하지 않은” 문제가 줄어들어요.

왜 이것이 효과적인지 한 가지만 더 설명하자면, AI는 확률적으로 “가장 일반적인” 해법을 제시하는 경향이 있습니다. 맥락 없이 “로그인 기능”을 요청하면, 가장 흔한 형태의 로그인을 만들겠죠. 하지만 당신의 서비스는 “일반적인” 서비스가 아닙니다. 고유한 요구사항이 있고, 고유한 제약이 있어요. 그 고유한 맥락을 전달할수록, AI의 결과물이 당신의 상황에 맞는 것이 됩니다.

두 번째, 단계적으로 작업을 나누어 맡기세요.

큰 기능을 한 번에 만들어달라고 하면 실패 확률이 높아집니다. 대신 이렇게 접근하는 편이 낫습니다 – 먼저 설계를 잡고, 설계에 대해 토론하고, 합의된 설계를 바탕으로 구현을 요청하고, 구현 결과를 리뷰하는 거죠. 마치 사람과 협업할 때처럼요. 이 방식은 시간이 더 걸리는 것 같지만, 실제로는 시행착오를 줄여서 전체적으로 더 빠릅니다.

세 번째, AI의 결과물을 “신뢰”하지 말고 “검증”하세요.

이건 좀 찜찜하게 느껴질 수 있는 이야기입니다. AI가 자신 있게 생성한 코드인데 굳이 다 확인해야 하나? 네, 해야 합니다. 특히 보안 관련 코드, 데이터 처리 로직, 비즈니스 핵심 로직은 반드시요. AI가 생성한 코드에 테스트를 작성하는 것(이것도 AI에게 맡길 수 있죠)은 기본 중의 기본입니다. 다만 AI가 작성한 테스트도 검증이 필요합니다 – 테스트가 실제로 중요한 시나리오를 커버하는지, 해피 패스만 테스트하고 있지는 않은지를 확인해야 해요.

네 번째, AI를 “페어 프로그래밍 파트너”로 활용하세요.

AI의 가장 효과적인 활용법 중 하나는, 혼자 고민할 때 대화 상대로 쓰는 것입니다. “이 설계에 대해 어떻게 생각해?”, “이 접근 방식의 단점은 뭘까?”, “더 나은 대안이 있을까?” 같은 질문을 던지면, AI는 당신이 미처 생각하지 못한 관점을 제시해줄 수 있어요. 물론 그 제안을 채택할지 말지는 당신의 판단입니다. AI는 좋은 “토론 상대”이지, “의사결정자”가 아니에요.

다섯 번째, AI가 모르는 것을 솔직히 인정하게 만드세요.

프롬프트에 “확실하지 않은 부분은 확실하지 않다고 말해줘”라는 한 줄을 추가하는 것만으로도 결과의 신뢰도가 올라갑니다. AI가 자신 없는 부분을 표시해주면, 거기에 더 주의를 기울이면 되니까요. “모르면 모른다고 해”라는 간단한 지시가 생각보다 큰 차이를 만듭니다.

여섯 번째, 실패를 학습 데이터로 활용하세요.

AI와의 협업에서 기대에 못 미치는 결과가 나왔을 때, 그냥 넘기지 마세요. “왜 이런 결과가 나왔을까?”, “내가 어떤 맥락을 빠뜨렸을까?”, “다음에는 어떻게 요청하면 더 나을까?”를 복기해보세요. 이 복기의 과정이 당신의 오케스트레이션 역량을 빠르게 키워줍니다. AI와의 협업도 사람과의 협업처럼 경험에서 배우는 것이거든요. 한 번의 실패에서 얻은 교훈이 이후 열 번의 협업을 더 나아지게 만듭니다.

실전 가이드 – 비개발자를 위한 AI 협업법

개발자가 아닌 분들은 조금 다른 접근이 필요합니다. AI와의 협업은 코딩에만 해당하는 이야기가 아니거든요. 기획, 마케팅, 영업, 인사, 재무 – 모든 업무 영역에서 AI와 함께 일하는 시대가 이미 왔습니다.

첫 번째, 결과물의 “형태”보다 “기준”을 먼저 정하세요.

AI에게 보고서를 요청하기 전에, “좋은 보고서란 무엇인가”를 스스로 정의해보세요. 어떤 질문에 답해야 하는지, 누가 읽을 것인지, 어떤 결정을 위한 자료인지. 이 기준이 명확할수록 AI의 결과물도 쓸모 있어집니다. 반대로, 기준 없이 “보고서 좀 만들어줘”라고 하면, AI는 가장 일반적인 형태의 보고서를 만들 것이고, 그것은 아마 당신이 원하는 것과 거리가 멀 거예요.

두 번째, AI를 “초안 생성기”로 활용하고, 마무리는 직접 하세요.

AI가 만든 초안을 그대로 사용하는 것은 위험합니다. 하지만 초안을 만드는 시간을 절약하고, 그 시간을 “다듬고 판단하는 일”에 쓸 수 있다면 업무의 질이 크게 올라갑니다. 빈 화면 앞에서 첫 문장을 고민하는 시간이 사라지는 것만으로도 엄청난 효율 향상이에요. 작가들이 “빈 종이의 공포”라고 부르는 것이 있는데, AI가 바로 그 공포를 없애줍니다. 초안이 있으면 “이건 아닌데”라고 판단하는 것부터 시작할 수 있고, 그 판단이 점점 정교해지면서 좋은 결과물이 만들어지거든요.

세 번째, “AI가 틀릴 수 있다”는 전제 하에 결과를 확인하세요.

AI가 인용한 통계, AI가 제시한 사례, AI가 내린 결론 – 이것들은 모두 교차 검증이 필요합니다. 특히 숫자가 포함된 정보는 원본 출처를 확인하는 습관이 중요해요. AI는 때때로 매우 자신 있는 어조로 부정확한 정보를 제공하거든요. 이것은 AI의 구조적 한계이기도 합니다. AI는 “정확한 것”을 말하는 것이 아니라 “그럴듯한 것”을 말하는 시스템이니까요. 그 차이를 항상 기억해두세요.

네 번째, 반복적인 업무부터 AI에게 맡기세요.

매주 만드는 주간 보고서, 정기적으로 작성하는 회의록 요약, 반복되는 이메일 답변 – 이런 것들부터 AI에게 맡기기 시작하세요. 패턴이 명확한 업무일수록 AI의 정확도가 높고, 당신이 검증하기도 수월합니다. 처음부터 복잡한 업무를 AI에게 맡기려다 실망하는 것보다, 단순한 것부터 시작해서 점점 범위를 넓혀가는 것이 현명한 접근입니다. 자전거를 처음 배울 때 보조 바퀴를 달고 시작하는 것처럼, AI 활용도 난이도를 단계적으로 높여가세요. 반복적인 업무에서 성공 경험을 쌓으면, 더 복잡한 업무에 AI를 적용할 자신감도 자연스럽게 생깁니다.

다섯 번째, AI에게 역할을 부여하세요.

“이 기획안에 대해 비판적으로 검토해줘”보다 “너는 경험 많은 사업개발 디렉터야. 이 기획안의 사업성을 냉정하게 평가해줘”라고 말하면 결과가 달라집니다. AI에게 명확한 역할과 관점을 부여하면, 더 깊이 있는 피드백을 받을 수 있어요. 한 발 더 나아가서, 같은 자료에 대해 서로 다른 역할을 부여하여 여러 번 검토를 받아보는 것도 좋은 방법입니다. “마케팅 관점에서”, “재무 관점에서”, “고객 관점에서” – 이렇게 다양한 시각을 AI를 통해 확보할 수 있어요.

오케스트레이터라는 새로운 정체성

지금까지 이야기한 것을 종합하면, AI 시대에 새롭게 부상하는 역할이 보입니다. “AI 오케스트레이터”라는 역할이에요.

이것은 특정 직업의 이름이 아닙니다. 모든 직무에 스며드는 역량에 가깝습니다. 개발자이면서 AI 오케스트레이터, 마케터이면서 AI 오케스트레이터, 프로젝트 매니저이면서 AI 오케스트레이터 – 이렇게요. 여기에 “프롬프트 디자이너”, “디지털 통역사” 같은 새로운 역할도 함께 등장하고 있습니다. 기술과 비즈니스 사이를, 인간과 AI 사이를 연결하는 사람들이죠.

SK AX에서 이런 이야기를 했습니다. “AI가 대신 만들어낸 결과물을 올바르게 이해하고 평가하며, 전체 시스템 안에서 의미 있게 연결할 수 있는 능력이 핵심이다.” 이 한 문장이 오케스트레이터의 역할을 정확하게 요약하고 있어요.

올바르게 이해하고 – AI 리터러시입니다. 평가하며 – 비판적 사고와 전문성입니다. 전체 시스템 안에서 의미 있게 연결할 수 있는 – 시스템 사고와 맥락 이해력입니다.

결국 AI와 함께 일하는 법이란, AI라는 도구를 잘 다루는 기술적 스킬만을 말하는 것이 아닙니다. 기존에 중요하다고 여겨졌던 역량들 – 비판적 사고, 맥락 이해, 커뮤니케이션, 시스템적 관점 – 이 AI 시대에 “오케스트레이션”이라는 새로운 이름으로 더욱 빛나게 되는 겁니다.

전작에서 이야기했던 “협업 스킬”과 “개발문화”를 기억하시나요? 사람과 사람 사이의 협업이 중요하다는 것은 여전히 유효합니다. 거기에 “사람과 AI 사이의 협업”이라는 새로운 차원이 더해진 거예요. 좋은 팀원이 되는 법을 아는 사람이, 좋은 AI 오케스트레이터도 될 가능성이 높습니다. 경청하고, 명확히 소통하고, 상대의 강점을 활용하는 능력은 협업의 대상이 인간이든 AI이든 동일하게 필요하니까요.

흔한 실수와 그 해법

AI와 함께 일하기 시작한 분들이 자주 빠지는 실수 몇 가지를 짚어드릴게요. 미리 알고 있으면 시행착오를 줄일 수 있습니다.

첫 번째 실수는 “과도한 기대”입니다. AI가 만능이라고 생각하고, 복잡한 작업을 한 번에 완벽하게 처리해주기를 기대하는 거예요. 앞서 이야기했듯이 완전 위임 가능한 작업은 20%도 안 됩니다. 기대 수준을 현실에 맞추고, AI를 “완벽한 동료”가 아닌 “유능하지만 감독이 필요한 주니어”로 생각하는 편이 건강한 접근이에요.

두 번째 실수는 “검증 없는 수용”입니다. AI가 자신 있는 어조로 제시한 결과를 그대로 받아들이는 것이죠. 특히 시간이 부족할 때 이런 유혹에 빠지기 쉬워요. 하지만 바로 이 순간이 가장 위험합니다. 검증 없이 AI 결과물을 사용하다가 나중에 문제가 터지면, 절약했던 시간의 몇 배를 수습에 쓰게 됩니다.

세 번째 실수는 “모든 것에 AI를 쓰려는 것”입니다. AI가 좋은 도구라고 해서, 모든 상황에 적합한 것은 아닙니다. 간단한 작업을 AI에게 설명하고 결과를 검증하는 데 걸리는 시간이, 직접 하는 시간보다 오래 걸리는 경우도 있어요. 언제 AI를 쓸지, 언제 직접 할지를 판단하는 것도 오케스트레이터의 중요한 역량입니다.

마무리 – 경쟁하지 마세요, 지휘하세요

한 가지 당부를 드리고 싶습니다. AI와 함께 일하는 법을 배우는 것은 선택이 아니라 기본이 되어가고 있어요. 하지만 초조해하실 필요는 없습니다. 완벽하게 마스터해야 한다는 부담감을 내려놓으세요. AI 기술 자체가 매일 변하고 있으니까요. 중요한 것은 특정 도구의 사용법을 외우는 것이 아니라, “AI와 협업하는 마인드셋”을 갖추는 것입니다.

그리고 그 마인드셋의 핵심은 생각보다 단순합니다.

경쟁하지 마세요. 지휘하세요. 맡기되, 검증하세요. 두려워하지 말되, 맹신하지도 마세요.

오늘 당장 AI에게 무언가를 맡겨보세요. 작은 것이라도 좋습니다. 그리고 그 결과를 꼼꼼히 살펴보세요. AI가 잘한 부분을 인정하고, 부족한 부분을 보완하세요. 그 과정에서 당신은 이미 오케스트레이터가 되어가고 있는 겁니다.

처음에는 어색할 수 있어요. AI에게 뭘 맡겨야 할지 모르겠고, 어떻게 소통해야 할지 감이 안 잡힐 수 있습니다. 하지만 그 어색함은 모든 새로운 협업 관계의 시작에서 느끼는 자연스러운 감정이에요. 새로운 팀에 합류했을 때, 처음에는 서로의 업무 스타일을 파악하는 데 시간이 걸리잖아요. AI와의 관계도 마찬가지입니다. 시간이 지나면서, 어떤 작업을 어떻게 맡기면 좋은 결과가 나오는지 감이 생길 거예요. 그 감이 바로 오케스트레이션 역량입니다.

다음 장에서는 이 모든 역량의 토대가 되는 것, 즉 “어떻게 배워야 오래 남는 역량을 쌓을 수 있는가”에 대해 이야기해보겠습니다. AI 시대의 학습법은 이전과는 확실히 다릅니다. 무엇이 다른지, 함께 살펴보시죠.

8장. 오래 가는 사람의 학습법

한 가지 질문을 던져볼게요. 지금 당신이 가장 자신 있는 기술은 무엇인가요? 그리고 그 기술을 처음 배운 것은 언제인가요?

만약 그것이 특정 프로그래밍 언어나 프레임워크라면, 5년 전에 배운 것이 지금도 그대로 통용되고 있나요? 아마 많이 달라졌을 겁니다. 어쩌면 당시 열심히 배웠던 기술이 이미 레거시가 되었을 수도 있고요. 개발자가 아닌 분들도 마찬가지입니다. 5년 전에 익혔던 업무 도구, 분석 방법론, 프로세스 중 지금도 그대로 쓰이는 것이 얼마나 되나요?

기술은 빠르게 진부해집니다. 이건 AI 시대 이전에도 그랬고, AI 시대에는 그 속도가 더 빨라졌습니다. 그렇다면 질문을 바꿔야 해요. “무엇을 배워야 하는가”가 아니라 “어떻게 배워야 오래 남는 것을 쌓을 수 있는가”로요.

이번 장은 그 “어떻게”에 대한 이야기입니다. 추상적인 원칙이 아니라, 내일부터 당장 적용할 수 있는 구체적인 프레임워크를 함께 살펴보시죠.

기술과 역량 – 같은 듯 다른 두 가지

먼저 중요한 구분을 하나 해야 합니다. “기술(Skill)”과 “역량(Capability)”은 다릅니다. 이 구분이 명확하지 않으면, 아무리 열심히 배워도 “모래 위에 성을 쌓는” 느낌에서 벗어나기 어렵거든요.

기술은 특정 도구나 방법론을 다루는 능력입니다. React를 잘 다루는 것, Python으로 데이터를 분석하는 것, Figma로 디자인하는 것, 엑셀로 재무 모델을 만드는 것 – 이런 것들이 기술이에요. 기술은 명확하고, 측정 가능하고, 비교적 빠르게 습득할 수 있습니다. 그리고 비교적 빠르게 진부해지기도 합니다.

역량은 기술의 밑바탕에 깔려 있는, 더 근본적인 능력입니다. 복잡한 문제를 구조화하는 능력, 새로운 기술을 빠르게 학습하는 능력, 비즈니스 맥락을 이해하고 기술적 해법을 연결하는 능력, 다양한 배경의 사람들과 소통하는 능력 – 이런 것들이 역량이에요. 역량은 쉽게 측정하기 어렵고, 쌓는 데 오래 걸리지만, 한번 쌓이면 쉽게 사라지지 않습니다.

비유를 하자면, 기술은 옷이고 역량은 체력입니다. 옷은 유행이 바뀌면 갈아입어야 하지만, 체력이 좋은 사람은 어떤 옷이든 잘 소화해요. React가 진부해지면 다른 프레임워크를 배우면 되지만, “새로운 기술을 빠르게 배우는 능력” 자체는 어떤 프레임워크가 유행하든 유효합니다.

또 다른 비유를 들어볼게요. 기술이 “특정 악기를 연주하는 능력”이라면, 역량은 “음악적 감각” 자체입니다. 피아노를 치는 기술은 피아노에만 통하지만, 음악적 감각이 뛰어난 사람은 기타를 배워도, 드럼을 배워도 금방 적응해요. 그 근본적인 감각이 전이되기 때문입니다.

AI 시대에 이 구분이 특히 중요한 이유가 있습니다. AI가 가장 빠르게 대체하고 있는 것이 바로 “기술” 영역이기 때문이에요. 특정 언어의 문법을 외우는 것, 특정 라이브러리의 API를 아는 것, 특정 도구의 사용법을 익히는 것 – 이런 것들은 AI가 순식간에 해줍니다. 하지만 “이 상황에서 어떤 기술을 선택해야 하는가”를 판단하는 역량, “왜 이 방식이 더 나은가”를 설명하는 역량은 AI가 대신해주기 어렵습니다.

그러니까 오래 가는 사람의 학습법은, 기술을 배우되 역량을 쌓는 방향으로 배우는 것입니다. React를 배울 때 그냥 “React를 다룰 수 있는 사람”이 되는 것이 아니라, “UI 컴포넌트 설계의 원칙을 이해하고, 그 원칙이 React에서 어떻게 구현되는지 아는 사람”이 되는 겁니다. 후자는 React가 사라져도 남아요. 비개발자의 경우도 마찬가지입니다. “이 엑셀 함수를 쓸 줄 안다”가 아니라 “데이터를 구조화하고 분석하는 사고방식을 갖추고, 그것을 엑셀이라는 도구로 구현할 줄 안다”가 되어야 합니다. 도구가 바뀌어도 사고방식은 남으니까요.

T자형에서 파이(π)자형으로

“T자형 인재”라는 말을 들어보셨을 겁니다. 한 분야에 깊은 전문성(T의 세로 획)을 가지면서, 다른 분야에 대한 폭넓은 이해(T의 가로 획)를 갖춘 사람을 뜻하죠. 오랫동안 이것이 이상적인 인재상이었습니다.

그런데 AI 시대에는 이것만으로는 좀 부족해졌어요. “π(파이)자형 인재”라는 새로운 모델이 주목받고 있습니다. T와 비교하면 세로 획이 하나 더 늘어난 거죠. 깊이 있는 전문성이 한 개가 아니라 두 개라는 뜻입니다.

왜 두 개일까요? AI가 하나의 전문 분야를 빠르게 커버할 수 있게 되면서, 한 분야만 깊이 아는 것의 경쟁력이 낮아졌기 때문입니다. 하지만 두 가지 분야를 깊이 이해하고 그 교차점에서 새로운 가치를 만들어내는 능력은 AI가 쉽게 흉내 내지 못해요. 왜냐하면 AI는 기존 데이터에서 패턴을 찾아내는 데 뛰어나지만, 서로 다른 분야의 지식을 창의적으로 결합하는 것은 여전히 인간이 더 잘하거든요.

예를 들어볼게요. “프론트엔드 개발”만 깊이 아는 사람보다, “프론트엔드 개발 + UX 리서치”를 모두 깊이 아는 사람이 AI 시대에 더 독보적인 가치를 가집니다. 왜냐하면 이 사람은 사용자의 행동 패턴을 이해한 상태에서 인터페이스를 설계하고, 기술적 제약과 사용자 경험 사이의 균형점을 찾을 수 있으니까요. 이 “교차점에서의 판단”은 AI가 대신하기 어렵습니다.

“백엔드 개발 + 도메인 지식(예: 금융, 의료, 물류)”의 조합도 마찬가지예요. 금융 도메인을 깊이 이해하면서 시스템 아키텍처를 설계할 수 있는 사람은, AI가 코드를 아무리 잘 생성해도 대체되지 않습니다. 왜냐하면 “이 거래 시스템에서 정산 로직이 왜 이렇게 복잡해야 하는지”를 이해하는 것은 도메인 경험 없이는 불가능하거든요.

비개발자의 경우도 마찬가지예요. “마케팅 + 데이터 분석”을 모두 깊이 아는 사람, “인사 관리 + 조직심리학”을 모두 깊이 아는 사람, “영업 + 산업 전문 지식”을 모두 깊이 아는 사람 – 이런 사람들은 AI가 아무리 발전해도 대체되기 어렵습니다. 두 영역의 교차점에서 나오는 통찰은 기존 데이터셋 어디에도 없는 것이니까요.

그렇다면 두 번째 “세로 획”을 어떻게 찾을 수 있을까요? 몇 가지 힌트가 있습니다.

첫째, 지금 하고 있는 일에서 가장 자주 협업하는 분야를 살펴보세요. 개발자라면 아마 기획이나 디자인, 데이터 분석과 자주 만날 겁니다. 그 분야에 대한 이해를 의도적으로 깊이 가져가는 거예요. 그냥 “기획팀이 뭘 원하는지 대충 이해하는” 수준이 아니라, “기획의 프레임워크와 사고방식을 이해하고, 기획 관점에서 기술적 제안을 할 수 있는” 수준까지요.

둘째, 당신이 자연스럽게 끌리는 영역에 주목하세요. 업무 외 시간에도 관심을 갖게 되는 분야가 있다면, 그것이 두 번째 전문성의 후보일 수 있습니다. 흥미가 있어야 깊이 파고들 동기가 생기니까요.

셋째, 시장에서 수요가 높은 교차 영역을 찾아보세요. AI 리터러시 + 도메인 전문성의 조합은 거의 모든 분야에서 수요가 폭발하고 있습니다. 어떤 분야든 “이 분야에 AI를 어떻게 적용할 수 있는가”를 아는 사람은 귀한 대접을 받습니다.

“얼마나 빨리 배우는가” – 메타 학습의 기술

앤드류 응은 이렇게 말했습니다. “AI 시대에는 무엇을 아는가보다 얼마나 빨리 배우는가가 중요하다.”

이 말이 와닿으시나요? 처음 들으면 당연한 이야기처럼 들릴 수도 있어요. 하지만 깊이 생각해보면 꽤 난감한 명제입니다. “빨리 배우는 능력”을 어떻게 키울 수 있는 걸까요? 배움의 속도를 높이는 구체적인 방법이 있기는 한 걸까요?

있습니다. 몇 가지 검증된 접근법을 소개해드릴게요.

첫 번째, “배우는 법을 배우는” 시간을 따로 확보하세요.

새로운 기술을 배울 때 대부분의 사람들은 곧바로 튜토리얼부터 시작합니다. “일단 해보자”는 마인드로 뛰어드는 거죠. 물론 나쁘지 않아요. 하지만 오래 가는 학습자들은 한 발 물러서서 먼저 이런 질문을 던집니다. “이 기술의 핵심 개념은 무엇인가?” “이것은 내가 이미 알고 있는 무엇과 비슷한가?” “이 기술이 해결하려는 근본적인 문제는 무엇인가?”

이 질문들에 답하는 데 30분을 투자하면, 이후의 학습 시간을 몇 시간 절약할 수 있습니다. 왜냐하면 새로운 지식이 기존 지식 체계에 연결될 자리를 미리 마련해두는 것이거든요. 정리되지 않은 창고에 물건을 넣으면 나중에 찾기 어렵지만, 선반을 미리 정리해두면 물건을 제자리에 놓을 수 있는 것과 같습니다.

구체적인 예를 들어볼게요. Kubernetes를 처음 배운다고 합시다. 바로 설치 가이드를 따라 하기 전에, 먼저 이런 것을 파악하는 거예요. “컨테이너 오케스트레이션이라는 큰 그림에서 Kubernetes가 어디에 위치하는가?” “내가 이미 알고 있는 Docker와 어떤 관계인가?” “Kubernetes가 없던 시절에는 이 문제를 어떻게 해결했는가?” 이 질문들에 답하고 나면, 이후에 배우는 구체적인 개념들(Pod, Service, Deployment 등)이 왜 그렇게 설계되었는지가 자연스럽게 이해됩니다.

비개발자 분들도 마찬가지예요. 새로운 프로젝트 관리 도구를 배울 때, 도구의 버튼 하나하나를 익히기 전에 “이 도구가 해결하려는 문제는 무엇인가?”, “기존에 사용하던 방식과 어떻게 다른가?”를 먼저 파악하면 학습이 훨씬 빨라집니다.

두 번째, “가르치듯 배우세요.”

무언가를 배운 뒤 다른 사람에게 설명해보는 것은, 자신의 이해도를 확인하는 가장 효과적인 방법입니다. 설명하다 막히는 지점이 바로 당신이 제대로 이해하지 못한 부분이에요. 이것을 “파인만 기법”이라고도 하죠. 물리학자 리처드 파인만이 복잡한 개념을 이해하기 위해 “초등학생에게 설명하듯” 정리하는 방법을 사용했다고 해서 붙은 이름입니다.

꼭 실제로 누군가를 앞에 앉혀놓고 강의를 할 필요는 없습니다. 블로그에 정리하거나, 노트에 자신만의 말로 요약하거나, 심지어 AI에게 설명해보는 것도 좋은 방법이에요. “내가 이것에 대해 설명할 테니, 내 설명에서 부족하거나 잘못된 부분을 짚어줘”라고 AI에게 요청하면, 즉석에서 피드백을 받을 수 있습니다.

이전 책에서 “기술 공유”와 “퍼스널 브랜딩”의 중요성을 이야기한 적이 있는데, AI 시대에 이것은 단순한 브랜딩 전략이 아니라 학습 전략이기도 합니다. 배운 것을 정리하고 공유하는 과정 자체가 역량을 심화하는 가장 강력한 도구예요. “글을 쓸 시간이 없다”고 느끼시는 분들이 많을 텐데, 사실은 정반대입니다. 글을 쓰는 시간이 학습 시간을 절약해줍니다. 정리하면서 이해가 깊어지니까요.

세 번째, “작게 실험하고, 빠르게 피드백을 받으세요.”

AI 시대 학습의 가장 큰 변화 중 하나는, 실험의 비용이 극적으로 낮아졌다는 것입니다. 새로운 아이디어가 있으면 AI의 도움을 받아 빠르게 프로토타입을 만들고, 결과를 확인하고, 개선하는 사이클을 돌릴 수 있어요. 예전에는 며칠이 걸렸을 실험을 몇 시간 만에 할 수 있게 된 거죠.

이 변화를 학습에 활용하지 않을 이유가 없습니다. “이론을 완벽히 이해한 다음에 실습한다”는 전통적인 학습 순서 대신, “일단 해보고, 막히면 이론을 찾아보고, 다시 해본다”는 반복적 학습이 더 효과적인 시대가 되었어요. 소프트웨어 개발 경제학이 재편되면서 실험 비용이 급감했고, 이것은 학습 방식의 변화로 직결됩니다.

예를 들어, 새로운 프로그래밍 패러다임을 배우고 싶다면, 교과서를 처음부터 끝까지 읽는 대신, AI에게 “이 패러다임을 사용한 간단한 예제를 만들어줘”라고 요청하고, 그 예제를 분석하고, 변형해보고, 깨뜨려보는 것이 더 빠른 학습법이 될 수 있어요.

네 번째, “연결의 지도”를 그리세요.

개별 기술이나 지식을 독립적으로 배우지 마세요. 대신, 각각의 지식이 어떻게 연결되는지를 의식적으로 파악하세요. “이 기술은 저 기술과 어떤 관계인가?”, “이 개념은 다른 분야의 어떤 개념과 비슷한가?”, “이것을 알면 저것을 배우기가 더 쉬워지나?”

이 연결의 지도가 풍부할수록, 새로운 것을 배울 때 기존 지식에 연결할 지점이 많아지고, 학습 속도가 올라갑니다. 파이(π)자형 인재가 강력한 이유도 여기에 있어요. 두 가지 깊은 전문성 사이에 수많은 연결 지점이 존재하기 때문입니다.

연결의 지도를 만드는 가장 좋은 방법은, 배울 때마다 “이것은 무엇과 비슷하고, 무엇과 다른가”를 자문하는 것입니다. 처음에는 의식적인 노력이 필요하지만, 습관이 되면 자연스럽게 새로운 지식이 기존 체계에 편입됩니다. 마치 경험 많은 의사가 새로운 증상을 접했을 때 자동으로 기존 사례와 비교하는 것처럼요.

2026년, 시장이 원하는 7가지 역량

구체적으로 “무엇을” 배워야 하는지에 대한 힌트도 필요하시겠죠. 2026년 한국 직업 트렌드에서 제시한 7대 핵심 역량을 살펴보면, 시장이 어떤 방향으로 움직이고 있는지가 보입니다.

첫째, AI 리터러시. 이것은 앞 장에서 자세히 다루었으니 짧게만 이야기할게요. AI를 도구로 활용하는 기본 역량입니다. 코딩 능력이 아니라, AI의 작동 원리를 이해하고 자신의 업무에 적절히 활용하는 능력이에요. 프롬프트를 잘 쓰는 것을 넘어, AI의 한계를 이해하고 결과를 비판적으로 평가하는 것까지 포함합니다.

둘째, 데이터 해석력. 데이터를 수집하고 분석하는 것은 AI가 잘합니다. 하지만 그 데이터가 “무엇을 의미하는지”, “어떤 결정으로 연결되어야 하는지”를 해석하는 것은 인간의 영역입니다. 숫자를 보고 이야기를 읽어내는 능력, 그것이 데이터 해석력이에요. “매출이 10% 올랐다”는 것은 AI가 알려줄 수 있습니다. 하지만 “이 10%가 지속 가능한 성장인지, 일시적인 반등인지, 어떤 전략적 함의가 있는지”를 판단하는 것은 비즈니스 맥락을 이해하는 사람만 할 수 있어요.

셋째, 창의적 문제 해결. 기존의 패턴으로 해결되지 않는 문제를 만났을 때, 새로운 접근을 시도할 수 있는 능력입니다. AI는 기존 패턴 안에서 최적의 해를 찾는 데 뛰어나지만, 패턴 자체를 깨는 사고는 인간만이 할 수 있어요. “이 문제를 완전히 다른 각도에서 보면 어떨까?”라는 질문은 AI가 스스로 던지지 못하는 질문입니다.

넷째, 디지털 커뮤니케이션. 원격 근무와 비동기 소통이 일상이 된 시대에, 글과 영상과 데이터로 자신의 생각을 효과적으로 전달하는 능력입니다. AI가 초안을 써줄 수 있지만, “이 메시지를 이 청중에게 이런 맥락에서 전달하려면 어떤 톤이 적절한가”를 판단하는 것은 여전히 인간의 몫이에요.

다섯째, 자기 주도 학습력. 누군가 시키지 않아도 스스로 학습 목표를 세우고, 자원을 찾고, 진도를 관리하는 능력입니다. AI 시대에 이 역량이 특히 중요한 이유는, 배워야 할 것이 너무 빠르게 변하기 때문이에요. 회사의 교육 프로그램이나 학교의 커리큘럼이 변화의 속도를 따라가지 못하는 경우가 많아서, 결국 스스로 배울 수 있는 사람이 앞서가게 됩니다. 누군가가 “이것을 배우세요”라고 말해주기를 기다리는 사람과, 스스로 “이것을 배워야겠다”고 판단하고 실행하는 사람의 차이는 시간이 갈수록 커집니다.

여섯째, 윤리적 판단력. AI가 만들어낸 결과물이 윤리적으로 적절한지, 편향은 없는지, 사회적 영향은 어떠한지를 판단하는 능력입니다. AI 기술이 강력해질수록 이 역량의 중요성은 더 커져요. 할 수 있는 것과 해야 하는 것은 다르니까요. “AI가 이것을 할 수 있다”와 “AI가 이것을 해도 되는가”는 완전히 다른 질문입니다.

일곱째, 협업과 적응력. 변화에 저항하지 않고 유연하게 적응하며, 다양한 배경의 사람들(그리고 AI)과 효과적으로 협업하는 능력입니다. 변화가 빠를수록 혼자서 모든 것을 해내는 것은 불가능합니다. 함께 문제를 풀고, 서로의 강점을 활용하는 능력이 더욱 중요해져요.

이 7가지를 가만히 살펴보면, 특정 도구의 사용법 같은 것은 하나도 없습니다. 전부 “역량”에 해당하는 것들이에요. 시장이 원하는 것도 결국 기술이 아니라 역량이라는 뜻입니다.

증강된 학습 – AI를 학습의 파트너로

여기서 한 가지 역설적인 이야기를 해볼게요. AI 시대의 학습법에서, AI 자체가 가장 강력한 학습 도구가 될 수 있다는 것입니다.

BCG가 제시한 “증강된 조직(Augmented Organization)”이라는 개념이 있어요. 인간의 판단과 창의성을 AI가 증폭하는 선순환 구조를 말합니다. 이 개념을 학습에 적용하면 “증강된 학습”이 됩니다.

어떤 모습일까요?

새로운 분야를 공부할 때, AI에게 “이 분야의 핵심 개념을 초보자가 이해할 수 있는 수준으로 설명해줘”라고 요청할 수 있습니다. 그리고 그 설명을 읽은 뒤 “이 부분이 잘 이해가 안 되는데, 다른 비유로 설명해줄 수 있어?”라고 물을 수 있어요. 24시간 언제든 응답하는, 무한한 인내심을 가진 개인 튜터가 생긴 셈입니다.

더 나아가면, AI를 “소크라테스식 대화 상대”로 활용할 수도 있어요. “이 개념에 대해 내가 이해한 것을 말해볼 테니, 나의 이해가 맞는지 틀린지 짚어줘. 그리고 내가 놓치고 있는 부분이 있으면 질문으로 유도해줘”라고 요청하는 거예요. AI가 질문을 던지고, 당신이 답하면서, 스스로 사고를 정리해가는 방식입니다.

코드 학습에서는 더 구체적인 활용이 가능해요. 코드를 작성한 뒤 “이 코드의 문제점을 찾아줘. 그런데 답을 바로 알려주지 말고, 힌트만 줘”라고 요청할 수 있습니다. 이렇게 하면 AI가 스스로 문제를 찾는 과정을 거치게 해주면서도, 완전히 혼자 헤매는 것을 방지할 수 있어요.

하지만 – 그리고 이것이 중요한데 – AI를 학습 도구로 사용할 때도 앞서 이야기한 원칙은 동일하게 적용됩니다. AI의 설명이 항상 정확한 것은 아니에요. AI가 알려준 내용을 그대로 믿는 것이 아니라, 그것을 출발점으로 삼아 직접 확인하고 심화하는 과정이 필요합니다.

또 한 가지, AI에게 답을 바로 물어보는 대신, 먼저 스스로 고민해보는 시간을 갖는 것이 좋습니다. 이게 좀 찜찜하게 느껴질 수 있어요. AI에게 물으면 바로 답이 나오는데 굳이 왜 혼자 고민해야 하지? 하지만 학습의 본질은 “답을 아는 것”이 아니라 “답을 찾아가는 과정에서 사고 근육을 키우는 것”이거든요. AI가 바로 답을 알려주면 그 과정이 생략됩니다. 이건 마치 헬스장에서 기계가 대신 운동해주는 것과 같아요. 편하지만, 당신의 근육은 자라지 않죠.

제가 권하는 방식은 이렇습니다. 먼저 스스로 문제를 풀어보세요. 최소 15분에서 30분 정도는 혼자 고민하는 시간을 가지세요. 그 다음 AI에게 당신의 풀이를 보여주고 피드백을 요청하세요. 그리고 AI의 피드백을 참고하여 다시 시도하세요. 이 과정에서 당신은 AI가 제시하는 관점을 비판적으로 검토하는 능력까지 함께 키울 수 있습니다.

지속적 학습이라는 생존 전략

“평생학습”이라는 말은 이제 진부하게 들릴 수도 있어요. 하지만 AI 시대에 이 말은 문자 그대로의 의미를 갖습니다. 특정 시점에 학습을 “완료”하고 그 지식으로 커리어를 유지하는 것은 더 이상 불가능해졌습니다.

지속적 학습(Continuous Learning)은 “항상 공부해야 한다”는 압박이 아닙니다. 학습을 일상에 통합하는 시스템을 만드는 것입니다.

구체적인 프레임워크를 하나 제안해드릴게요. 저는 이것을 “3-3-3 학습법”이라고 부릅니다.

매일 30분: 자신의 주 전문 분야의 최신 동향을 따라갑니다. 뉴스레터 구독, 기술 블로그 읽기, 관련 커뮤니티 둘러보기 등. 30분이면 충분합니다. 중요한 것은 매일 하는 것이에요. 출퇴근 시간을 활용하면 별도의 시간을 내지 않아도 됩니다.

매주 3시간: 새로운 기술이나 도구를 직접 사용해봅니다. 튜토리얼을 따라 하거나, 사이드 프로젝트에 적용해보거나, AI를 활용해 프로토타입을 만들어봅니다. 이론만 읽는 것과 직접 해보는 것은 학습 효과에서 차원이 다릅니다. 주말 오전 3시간을 “학습 시간”으로 고정하는 것도 좋고, 평일에 30분씩 나눠서 하는 것도 괜찮아요.

매달 3일: 좀 더 깊이 있는 학습에 투자합니다. 온라인 강의 하나를 수강하거나, 관련 서적을 읽거나, 콘퍼런스나 밋업에 참석합니다. 그리고 배운 것을 자신만의 방식으로 정리합니다. 블로그에 쓰든, 노션에 정리하든, 동료에게 공유하든. 이 “정리”의 과정이 없으면 배운 것이 금방 휘발됩니다.

이 프레임워크의 핵심은 “무리하지 않으면서도 꾸준히”에 있습니다. 한 달에 한 번 10시간 몰아서 공부하는 것보다, 매일 30분이 훨씬 효과적이에요. 학습은 근육과 같아서, 자주 사용할수록 강해지고, 오래 쉬면 약해지거든요.

여기서 한 가지 더 중요한 것이 있어요. “3-3-3”은 시작점이지 정답이 아닙니다. 처음에는 이 프레임워크로 시작하되, 자신의 상황에 맞게 조정하세요. 핵심은 매일, 매주, 매달이라는 세 가지 주기로 학습이 일상에 자연스럽게 녹아드는 것입니다.

학습의 방향을 설정하는 나침반

“뭘 배워야 할지 모르겠다”는 고민을 하시는 분들이 많습니다. 너무나 많은 것이 너무 빠르게 변하고 있으니, 어디에 시간을 투자해야 할지 난감한 거죠. 이해합니다.

이럴 때 도움이 되는 나침반이 있어요. 세 가지 질문입니다.

첫 번째 질문: “이것은 3년 후에도 유효할까?” 특정 도구의 사용법은 3년 후 달라질 가능성이 높습니다. 하지만 그 도구가 해결하려는 문제에 대한 이해는 3년 후에도 유효합니다. Docker 사용법은 바뀔 수 있지만, 컨테이너화의 개념과 필요성은 남아요. 특정 AI 도구의 프롬프트 기법은 바뀔 수 있지만, “AI와 효과적으로 소통하는 원칙”은 남습니다. 이처럼, 변하는 것보다 변하지 않는 것에 더 비중을 두세요.

두 번째 질문: “이것은 AI가 대신하기 어려운 영역인가?” 앞에서 이야기했듯이, AI가 잘하는 영역(패턴 기반 작업, 코드 생성, 데이터 분석 실행 등)에 대한 학습은 점점 ROI가 낮아집니다. 특정 API의 사용법을 외우는 것보다, 그 API가 왜 그렇게 설계되었는지를 이해하는 것이 더 가치 있어요. 반면 AI가 약한 영역(문제 정의, 비즈니스 맥락 이해, 윤리적 판단, 사용자 공감 등)에 대한 학습은 ROI가 올라가고 있습니다.

세 번째 질문: “이것이 나의 고유한 조합을 강화하는가?” 파이(π)자형 인재의 관점에서, 새로운 학습이 당신만의 독특한 역량 조합을 더 강화하는지 확인하세요. 남들과 똑같은 것을 배우면 차별화가 어렵습니다. 당신의 경험, 배경, 관심사가 만들어내는 고유한 교차점을 더 깊게 파는 것이 전략적으로 훨씬 유리합니다.

이 세 가지 질문을 통과하는 학습 대상이라면, 투자할 가치가 있습니다. 세 가지 모두 “아니오”라면, 아무리 유행하는 주제라도 잠시 미뤄두는 편이 낫습니다. 시간은 유한하니까요.

한 가지 예를 들어볼게요. “최신 AI 프레임워크 X의 사용법”을 배울지 고민된다면, 세 가지 질문을 던져보세요. 3년 후에도 유효할까? 아마 프레임워크 자체는 바뀔 수 있어요. AI가 대신하기 어려운 영역인가? 도구 사용법은 AI가 금방 알려줄 수 있는 영역이에요. 나의 고유한 조합을 강화하는가? 이건 사람마다 다르겠죠. 이 질문들을 거치면, “프레임워크 X의 사용법”보다 “AI 시스템의 설계 원칙과 한계”를 배우는 것이 더 전략적이라는 판단이 나올 수 있습니다.

함께 배우는 힘

학습을 이야기할 때 빠지기 쉬운 함정이 있어요. “학습은 혼자 하는 것”이라는 생각입니다.

물론 집중해서 공부하는 시간은 혼자 필요합니다. 하지만 학습의 방향을 설정하고, 동기를 유지하고, 배운 것을 심화하는 데는 커뮤니티의 힘이 결정적입니다.

같은 분야를 공부하는 동료들과 정기적으로 모여 배운 것을 공유하는 것, 온라인 커뮤니티에서 질문을 주고받는 것, 관심 분야의 밋업이나 콘퍼런스에 참석하는 것 – 이런 활동들이 학습의 질과 지속성을 높여줍니다.

왜 그런지 생각해보면 이유는 간단합니다. 혼자 배우면 자신만의 시각에 갇히기 쉽거든요. “아, 이거 다 알겠다”라고 생각했는데, 다른 사람의 질문을 받아보면 전혀 생각하지 못했던 관점이 있다는 것을 깨달게 되는 경험, 있으시죠? 그 깨달음이 학습을 한 단계 끌어올리는 겁니다.

이전 책에서 “퍼스널 브랜딩”과 “기술 공유”에 대해 이야기한 것을 기억하시는 분도 계실 거예요. AI 시대에 이것은 브랜딩을 넘어 학습 전략이 됩니다. 배운 것을 정리해서 공유하면, 다른 사람의 피드백을 통해 자신의 이해가 깊어지고, 공유하는 과정에서 새로운 관점을 발견하게 되거든요.

“함께 일하고 싶은 사람”의 조건은 전작에서 깊이 다뤘지만, 여기서 하나만 덧붙이자면 – “함께 배우고 싶은 사람”도 못지않게 중요합니다. 자신이 배운 것을 기꺼이 나누고, 다른 사람의 성장에 관심을 갖는 사람. 이런 사람 곁에는 자연스럽게 학습 커뮤니티가 만들어지고, 그 커뮤니티가 개인의 성장을 가속합니다.

실질적인 제안을 하나 드릴게요. 지금 당장 주변에서 함께 배울 사람 3명을 찾아보세요. 같은 팀이어도 좋고, 다른 팀이어도 좋습니다. 격주로 한 시간씩 모여서, 각자 최근 배운 것을 하나씩 공유하는 자리를 만들어보세요. 형식적일 필요 없어요. 커피 한 잔 마시면서 편하게 이야기하는 것으로 충분합니다. 이 작은 습관이 쌓이면, 6개월 후에는 혼자서는 절대 도달하지 못했을 곳에 와 있는 자신을 발견하게 될 겁니다.

학습의 적 – 완벽주의와 비교

학습에 대해 이야기할 때 반드시 다뤄야 할 것이 하나 더 있어요. 학습을 가로막는 가장 큰 적, 완벽주의와 비교입니다.

“아직 준비가 안 됐어.” “다른 사람들은 이미 이렇게나 잘하는데.” “이것도 모르면서 저걸 배워도 되나.” 이런 생각이 들 때가 있으시죠? 특히 AI처럼 빠르게 변하는 분야를 배울 때, 이미 앞서간 사람들과 비교하면서 위축되기 쉽습니다.

하지만 기억해두세요. 모든 전문가는 초보자였던 시절이 있었습니다. AI에 대해 자신 있게 이야기하는 사람도, 불과 2~3년 전에는 “AI가 뭔지 잘 모르겠다”고 했을 수 있어요. 변화가 빠른 분야일수록 “시작이 늦었다”는 말은 의미가 없습니다. 어차피 6개월 전의 지식도 이미 업데이트가 필요하니까요.

완벽하게 이해한 다음에 시작하겠다는 마음을 내려놓으세요. 60%만 이해해도 일단 써보는 것이 100% 이해할 때까지 기다리는 것보다 훨씬 효과적입니다. 나머지 40%는 써보면서 자연스럽게 채워지거든요. 학습은 직선이 아니라 나선입니다. 같은 주제를 반복해서 만나면서, 매번 조금씩 더 깊이 이해하게 되는 거예요.

다른 사람과 비교하는 것도 마찬가지입니다. 비교 자체가 나쁜 것은 아니에요. “저 사람은 어떻게 저렇게 잘하지? 나도 배워야겠다”라는 동기 부여가 될 수 있으니까요. 하지만 비교가 “나는 안 돼”라는 결론으로 이어진다면, 그건 학습을 돕는 것이 아니라 방해하는 겁니다. 비교의 대상은 다른 사람이 아니라 “어제의 나”가 되어야 합니다. 어제보다 오늘 하나라도 더 알게 되었다면, 그것으로 충분합니다.

마무리 – 배움의 속도가 곧 적응의 속도입니다

이 장에서 드리고 싶었던 메시지를 한 문장으로 요약하면 이렇습니다. “무엇을 아느냐보다, 무엇이든 빨리 배울 수 있느냐가 중요한 시대입니다.”

기술은 계속 바뀝니다. AI가 할 수 있는 것도 계속 늘어납니다. 이 변화를 모두 따라잡으려고 하면 지칩니다. 하지만 변화를 학습하는 자신만의 시스템을 갖추면, 변화가 두렵지 않게 됩니다. 오히려 변화가 새로운 기회가 되죠.

기술이 아닌 역량을 쌓으세요. T자형을 넘어 π자형으로 성장하세요. 배우는 법을 배우고, 그것을 일상에 통합하세요. 그리고 혼자 배우지 마세요. 함께 배우는 것이 더 멀리 갑니다.

지치지 않는 학습의 비결은, 의무감이 아니라 호기심입니다. “해야 하니까”가 아니라 “궁금하니까” 배우는 사람이 결국 더 오래, 더 멀리 갑니다. AI 시대는 호기심 많은 사람에게 최고의 시대일 수 있어요. 궁금한 것을 탐구하는 비용이 이렇게 낮았던 적이 없으니까요.

BCG가 이야기한 “증강된 조직”의 핵심도 결국 이것입니다. 인간의 판단과 창의성을 AI가 증폭하는 선순환. 이 선순환의 출발점은 학습이에요. 배우는 사람이 AI를 더 잘 활용하고, AI를 잘 활용하는 사람이 더 많이 배우고, 더 많이 배운 사람이 더 좋은 판단을 내리고, 더 좋은 판단이 더 나은 결과를 만들어냅니다. 이 선순환에 올라타는 첫 번째 걸음이 바로 “오늘 하나 배우기”입니다.

다음 장은 이 책의 마지막 장입니다. 지금까지 이야기한 모든 것을 관통하는 하나의 질문으로 돌아가려 합니다. 시대가 아무리 바뀌어도 변하지 않는 것, 코드 너머에서 우리가 만나게 되는 것은 과연 무엇일까요.

9장. 코드 너머에서 만나는 것들

몇 년 전, 저는 “코드 너머, 회사보다 오래 남을 개발자”라는 책을 쓰면서 하나의 질문에 매달렸습니다. 코드만 잘 짜면 되는 거 아닌가? 그 질문의 답을 찾아가는 과정에서, 결국 중요한 것은 코드가 아니라 사람이라는 결론에 도달했어요.

그로부터 시간이 흘렀습니다. 세상이 많이 변했습니다. AI가 코드를 쓰고, 에이전트가 자율적으로 개발하고, 비개발자도 앱을 만드는 시대가 왔습니다. 그래서 새로운 질문을 던져야 했습니다. 코드를 AI가 쓰는 시대에, 그러면 대체 무엇이 남는 걸까요?

이 책 전체를 관통하며 그 답을 찾아왔습니다. 이제 마지막 장에서 그 답을 하나로 모아보려 합니다. 이 책을 여기까지 읽어주신 분들께 전하고 싶은 이야기가 아직 남아 있거든요.

변하는 것과 변하지 않는 것

이 책에서 우리는 많은 변화를 목격했습니다.

1장에서 바이브 코딩이 등장하고, 에이전틱 AI가 부상하는 풍경을 살펴봤습니다. v0 사용자의 63%가 비개발자라는 숫자, 개발자의 60%가 업무에서 AI를 사용한다는 현실, Rakuten에서 AI가 7시간 만에 복잡한 엔지니어링 태스크를 완수했다는 사례 – 이 모든 것이 “구조적 전환”이 이미 시작되었음을 보여주었죠.

2장에서는 그 변화가 우리 일자리에 미치는 영향을 직시했습니다. 22~25세 개발자 고용이 20% 감소했다는 데이터 앞에서 불안을 느꼈지만, 동시에 미국 노동통계국이 2033년까지 17% 성장을 전망한다는 사실도 확인했습니다. 일자리의 수가 아니라 성격이 변하고 있다는 것을 이해했어요.

3장에서 AI가 가져간 것들의 목록을 확인했습니다. 보일러플레이트 코딩, 단순 버그 수정, 테스트 작성 – 이미 AI가 상당 부분 처리하고 있는 영역들. 하지만 완전 위임 가능한 작업은 0~20%에 불과하다는 사실이 의미하는 바도 함께 깨달았습니다.

4장에서는 반전이 있었죠. AI가 가져갈 수 없는 것들 – 창의성, 비판적 사고, 공감, 윤리적 판단. 이 “인간적인” 역량들이 AI 시대에 오히려 더 귀해진다는 아이러니를 발견했습니다.

5장에서 모두가 개발자가 되는 세상의 의미를 탐구했고, 6장에서 “무엇을 만들 것인가”라는 질문의 힘을 깨달았습니다. 7장에서 AI와 함께 일하는 구체적인 방법을 배웠고, 8장에서 오래 남는 역량을 쌓는 학습법을 정리했습니다.

이 변화들을 처음 접했을 때 어떤 감정이 드셨나요? 솔직히, 좀 불안하셨을 수도 있어요. 저도 그랬습니다. “내가 해오던 일의 상당 부분이 AI로 대체될 수 있다”는 사실은, 아무리 이성적으로 받아들이려 해도 마음 한구석이 찜찜해지는 이야기니까요.

하지만 이 책을 여기까지 읽어오신 분이라면, 이제 그 불안의 실체가 좀 더 선명하게 보이실 겁니다.

변하는 것은 “어떻게 만드는가”입니다. 코드를 직접 타이핑하는 방식, 특정 언어의 문법을 외워야 하는 필요성, 반복적인 작업에 시간을 쏟아야 하는 현실 – 이런 것들은 빠르게 변하고 있고, 앞으로도 계속 변할 겁니다.

변하지 않는 것은 “무엇을, 왜 만드는가”입니다. 어떤 문제를 발견하고, 왜 그것을 해결해야 하는지 설명하고, 해결책이 사람들에게 어떤 가치를 주는지 판단하는 것 – 이런 것들은 시대가 바뀌어도 여전히 인간의 영역입니다.

BCG의 연구가 이것을 명확하게 정리해줍니다. “AI는 대체(replace)하기보다 더 많은 일자리를 재편(reshape)할 것이다.” 재편이라는 단어에 주목해주세요. 없어지는 것이 아니라 모양이 바뀌는 겁니다. 그리고 그 새로운 모양의 중심에는 항상 사람이 있습니다.

“함께 일하고 싶은 사람”이라는 변하지 않는 기준

전작에서 제가 가장 강조했던 메시지가 있습니다. 결국 중요한 것은 “함께 일하고 싶은 사람”이 되는 것이라고요.

그때는 주로 개발자들 사이의 협업을 이야기했습니다. 코드 리뷰를 잘하는 사람, 회의에서 경청할 줄 아는 사람, 후배의 성장을 돕는 사람, 어려운 상황에서 팀을 결속시키는 사람. 이런 사람이 결국 “회사보다 오래 남는 개발자”가 된다고 말이죠.

전작의 추천사에 이런 문장이 있었습니다. “AI가 코딩을 대신할 순 있어도 ’함께 일하고 싶은 사람’은 결국 협업을 잘하는 사람이다.” 그때는 이 말이 미래에 대한 예측처럼 들렸는데, 지금 돌이켜보면 현재에 대한 정확한 진단이었어요.

AI 시대에 이 기준이 사라졌을까요? 전혀요. 오히려 더 중요해졌습니다.

왜냐하면, AI가 기술적 역량의 격차를 줄여주고 있기 때문이에요. 예전에는 뛰어난 코딩 실력 자체가 희소한 경쟁력이었습니다. 하지만 AI 도구의 도움으로 누구나 일정 수준 이상의 코드를 생산할 수 있게 되면서, 순수한 기술 실력만으로 차별화되기가 점점 어려워지고 있어요. 또 다른 추천사의 표현을 빌리면, “코딩 실력만으로는 차별화되기 어려운 시대”가 이미 와 있는 거죠.

그렇다면 차별화는 어디서 오는 걸까요?

“이 사람과 함께하면 일이 잘 풀린다”는 느낌. “이 사람이 팀에 있으면 분위기가 달라진다”는 경험. “이 사람에게 물어보면 문제의 본질을 짚어준다”는 신뢰. “이 사람은 어떤 상황에서도 흔들리지 않는다”는 안정감. 이런 것들은 AI가 아무리 발전해도 만들어줄 수 없는 것입니다.

삼성전자 SWITCH 사무국이 기술적 전문성을 넘어선 소프트 스킬을 강조하고, SK AX가 “전체 시스템 안에서 의미 있게 연결할 수 있는 능력”을 핵심으로 꼽는 이유도 여기에 있습니다. 한국의 선도 기업들이 이미 이 변화를 감지하고 있어요. 그들이 찾는 “다음 시대의 인재”는 AI를 잘 다루면서도 사람과의 관계에서 탁월한 사람입니다.

카카오가 AI로 대체 가능한 직무에 신규 인원 배정을 중단하면서도, 동시에 AI 역량 강화를 독려하고 있다는 것도 같은 맥락이에요. 단순히 “사람을 줄인다”가 아니라, “사람에게 기대하는 것이 달라진다”는 신호입니다. AI가 대신할 수 있는 일은 AI에게 맡기고, 사람은 AI가 대신할 수 없는 일에 집중하라는 거죠.

인간의 역량은 그 어느 때보다 중요합니다

McKinsey는 이렇게 선언했습니다. “인간의 역량은 AI 시대에 그 어느 때보다 중요하다.”

처음 이 문장을 읽었을 때, 조금 의아하셨을 수도 있어요. AI가 이렇게 강력해지고 있는데, 인간의 역량이 “그 어느 때보다” 중요하다고? 역설처럼 들리죠.

하지만 생각해보면 논리적입니다. AI가 처리할 수 있는 영역이 넓어질수록, AI가 처리할 수 없는 영역의 가치가 올라가니까요. 희소성의 법칙이에요. 코드를 짜는 능력이 흔해지면, 어떤 코드를 짜야 하는지 판단하는 능력이 귀해집니다. 데이터를 분석하는 것이 쉬워지면, 그 분석을 어떤 의사결정으로 연결할지 아는 것이 귀해지고요.

WEF가 꼽은 미래 핵심 역량을 다시 떠올려보세요. 분석적 사고, 창의성, 회복탄력성, 소통, 공감. 이것들은 모두 “인간다운” 역량입니다. AI 시대의 경쟁력이 기술이 아니라 인간성에 있다는 것은, 어쩌면 이 시대가 우리에게 주는 가장 아이러니하면서도 가장 희망적인 메시지가 아닐까요.

Microsoft의 5C 프레임워크도 같은 방향을 가리킵니다. 호기심(Curiosity), 비판적 사고(Critical thinking), 창의성(Creativity), 소통(Communication), 인격(Character). 다섯 가지 모두 기술적 스킬이 아니라 인간적 역량이에요. 그리고 이 다섯 가지는 서로 분리된 것이 아니라 깊이 연결되어 있습니다. 호기심이 있어야 새로운 것을 탐구하고, 비판적 사고가 있어야 탐구한 것의 가치를 판단하고, 창의성이 있어야 새로운 해법을 제시하고, 소통 능력이 있어야 그 해법을 다른 사람과 나눌 수 있고, 인격이 있어야 그 모든 것을 윤리적으로 올바른 방향으로 이끌 수 있습니다.

이것은 개발자에게만 해당하는 이야기가 아닙니다. 기획자, 마케터, 디자이너, 영업 담당자, 관리자, 학생 – 어떤 역할을 맡고 있든, AI 시대에 당신의 경쟁력은 AI가 못하는 것을 할 수 있느냐에 달려 있습니다. 그리고 AI가 못하는 것의 목록은 놀랍도록 “인간적인” 것들로 채워져 있어요.

여기서 잠깐, 한 가지 오해를 풀고 가야 할 것 같습니다. “인간적 역량이 중요하다”는 말이, “기술은 이제 필요 없다”는 뜻은 아닙니다. 기술적 기반 없이 인간적 역량만으로는 AI 시대를 헤쳐나가기 어렵습니다. 가장 강력한 조합은, AI 리터러시를 포함한 기술적 역량과 인간적 역량을 모두 갖추는 것이에요. 연구들이 일관되게 보여주는 것은, “AI 문해력 + 강한 인간 역량을 겸비한 사람”이 어느 한쪽만 가진 사람보다 현저히 높은 보상을 받는다는 사실입니다.

한국의 기업들이 보내는 신호

이야기를 조금 더 구체적으로 좁혀볼게요. 한국의 기업 현장에서는 지금 어떤 일이 벌어지고 있을까요?

삼성전자의 SWITCH 사무국은 기술적 전문성만이 아니라 소프트 스킬을 강조하고 있습니다. “기술은 빠르게 바뀌지만, 소통하고 협업하고 문제를 정의하는 능력은 축적된다”는 인식이 반영된 거예요. 삼성이라는 거대한 조직이 이런 메시지를 내부에 전달하고 있다는 것 자체가 시대의 변화를 보여주는 강력한 신호입니다.

SK AX의 메시지는 더 직접적이에요. “AI가 대신 만들어낸 결과물을 올바르게 이해하고 평가하며, 전체 시스템 안에서 의미 있게 연결할 수 있는 능력이 핵심이다.” 이 문장은 7장에서 이야기한 오케스트레이션의 정의와 거의 일치합니다. 기업 현장에서 이미 이 역량을 필요로 하고 있다는 뜻이죠.

그리고 2026년 한국 직업 트렌드에서 제시한 7대 핵심 역량 – AI 리터러시, 데이터 해석력, 창의적 문제 해결, 디지털 커뮤니케이션, 자기 주도 학습력, 윤리적 판단력, 협업과 적응력. 이 목록을 다시 보세요. 특정 프로그래밍 언어도, 특정 도구의 이름도 없습니다. 전부 “역량”이에요. 시장이 원하는 것이 무엇인지가 이보다 더 명확할 수 없습니다.

이 신호들을 종합하면 하나의 그림이 그려집니다. 한국의 기업들은 “기술을 잘 다루는 사람”에서 “기술과 사람 모두를 잘 다루는 사람”으로 인재상을 재정의하고 있어요. 그리고 이 변화는 개발 직군에만 국한되지 않습니다. 모든 직군에서 동시에 일어나고 있습니다.

두 가지 길 – 두려움과 기회

AI 시대를 바라보는 시선은 크게 두 가지로 나뉩니다.

하나는 두려움입니다. “AI가 내 일자리를 빼앗을 것이다.” “내가 배운 것들이 쓸모없어질 것이다.” “나는 이 변화에 적응하지 못할 것이다.” 이런 두려움은 자연스러운 감정입니다. 부정하거나 억누를 필요 없어요. CNN이 “소프트웨어 엔지니어링 일자리 소멸은 크게 과장되었다”라고 보도한 것도, 그만큼 두려움이 널리 퍼져 있다는 반증이기도 하잖아요.

다른 하나는 기회입니다. “AI 덕분에 예전에는 시도하지 못했던 것들을 해볼 수 있게 되었다.” “반복적인 일에서 벗어나 더 의미 있는 일에 집중할 수 있게 되었다.” “비개발자인 나도 아이디어를 직접 구현해볼 수 있게 되었다.” AI 지원 작업의 27%가 “AI 없이는 시도조차 하지 않았을 작업”이라는 사실을 기억하세요. 이것은 두려움이 아니라 가능성의 이야기입니다.

같은 변화를 보면서 두려움을 느끼는 사람과 기회를 보는 사람의 차이는 무엇일까요? 능력의 차이가 아닙니다. 관점의 차이예요.

그리고 이 관점의 차이를 만드는 것은, 바로 “이해”입니다. 변화의 실체를 이해하지 못하면 두려움만 남습니다. 하지만 변화의 실체를 정확히 이해하면, 그 안에서 기회를 볼 수 있게 됩니다.

이 책을 통해 제가 드리고 싶었던 것은 바로 이 관점의 전환입니다. 두려움을 기회로 바꾸는 데 필요한 것은 대단한 결심이 아니라, 변화의 실체를 정확히 이해하는 것이에요. 무엇이 사라지고, 무엇이 남고, 무엇이 새로 생기는지를 알면, 막연한 불안이 구체적인 행동으로 바뀝니다.

이 여정을 함께 걸어오신 당신은, 이미 두려움을 기회로 바꿀 준비가 되어 있는 겁니다.

여기서 한 가지 더 말씀드리고 싶은 것이 있어요. 두려움을 완전히 없앨 필요는 없습니다. 사실 약간의 두려움은 건강한 것이에요. 변화에 대한 적절한 경각심이 있어야, 안주하지 않고 계속 성장할 동기가 생기니까요. 문제는 두려움 자체가 아니라, 두려움에 “압도”되는 것입니다. 두려움을 느끼되, 그 두려움이 행동을 막게 두지 않는 것. 그것이 이 시대를 살아가는 현명한 자세가 아닐까 생각합니다.

“회사보다 오래 남을 개발자”에서 “시대보다 오래 남을 사람”으로

전작의 결론은 “회사보다 오래 남을 개발자”였습니다. 회사는 언젠가 바뀌고, 직무도 바뀌고, 기술도 바뀌지만, 자신만의 역량과 가치관을 가진 사람은 어디서든 필요하다는 메시지였어요.

이번 책에서 그 메시지를 한 단계 더 확장하고 싶습니다.

“시대보다 오래 남을 사람.”

AI 시대가 와도, 그 다음 시대가 와도, 기술 패러다임이 완전히 뒤집혀도 – 결국 남는 사람이 있습니다. 그 사람은 어떤 사람일까요?

첫째, 특정 기술에 자신의 정체성을 걸지 않는 사람입니다. “나는 자바 개발자야”가 아니라 “나는 복잡한 문제를 구조화하고 해결하는 사람이야. 지금은 자바를 주로 쓰고 있지만”이라고 말할 수 있는 사람. 도구가 바뀌어도 자신의 정체성이 흔들리지 않아요.

둘째, 어떤 기술이든 빠르게 배우고 활용할 수 있는 학습 역량을 갖춘 사람입니다. 8장에서 이야기한 “메타 학습”의 기술을 가진 사람이죠. 변화가 빠를수록, “이미 알고 있는 것”보다 “빨리 배울 수 있는 능력”이 더 큰 자산이 됩니다.

셋째, 변화를 두려워하는 대신 호기심으로 받아들이는 태도를 가진 사람입니다. “이게 뭐지? 재밌겠다”라고 반응하는 사람과 “또 바뀌는 거야? 지겹다”라고 반응하는 사람은, 같은 변화 앞에서 완전히 다른 결과를 만들어냅니다.

넷째, 그리고 무엇보다, 사람과의 관계에서 신뢰를 쌓는 사람입니다. 기술은 바뀌지만, 신뢰는 남습니다. “이 사람 말은 믿을 수 있다”는 평판, “이 사람과 일하면 배우는 것이 있다”는 경험, “이 사람은 어려울 때 곁에 있어준다”는 기억 – 이런 것들은 시간이 지나도, 기술이 바뀌어도, 시대가 달라져도 사라지지 않습니다.

이것은 개발자에게만 해당하는 이야기가 아닙니다. 이 책의 독자 중에는 개발자가 아닌 분들도 많으실 거예요. 기획자, 디자이너, 마케터, 경영자, 학생, 커리어를 전환하려는 분들. 여러분 모두에게 동일한 메시지를 드리고 싶습니다.

당신의 가치는 당신이 다루는 도구에 있지 않습니다. 도구는 바뀝니다. 펜에서 타자기로, 타자기에서 워드프로세서로, 워드프로세서에서 AI로. 하지만 그 도구로 무엇을 만들고, 왜 만들고, 누구를 위해 만드는지를 판단하는 능력, 그리고 그 과정에서 함께 일하는 사람들과 좋은 관계를 만드는 능력 – 이것은 도구가 아무리 바뀌어도 변하지 않는 근본적인 가치입니다.

전작에서 저는 “회사보다 오래 남을 개발자”의 비결이 소프트 스킬에 있다고 이야기했습니다. 경청, 질문법, 회의 스킬, 자기 인식, 회복탄력성, 심리적 안전감, 기술 공유, 퍼스널 브랜딩. 이 키워드들을 기억하시는 분도 계실 거예요. 지금 다시 이 목록을 보면, 놀라울 만큼 AI 시대의 핵심 역량과 겹칩니다.

경청은 문제 발견력의 출발점이고, 질문법은 AI와의 협업에서 핵심이며, 회복탄력성은 빠른 변화 속에서 지치지 않는 힘이고, 기술 공유는 함께 배우는 문화의 기반입니다. 결국 “오래 남는 사람의 조건”은 시대가 달라져도 본질적으로 같다는 뜻이에요. 다만 그 조건이 발현되는 맥락이 달라질 뿐입니다.

“회사보다 오래 남을 개발자”가 소프트 스킬의 가치를 깨닫는 여정이었다면, “시대보다 오래 남을 사람”은 그 가치가 시대를 초월한다는 확신의 여정입니다. 그리고 이 여정은 개발자만의 것이 아니에요. 코드를 쓰든, 기획을 하든, 고객을 만나든, 팀을 이끌든 – “시대보다 오래 남을 사람”의 조건은 동일합니다.

내일 할 수 있는 한 가지

큰 변화 앞에서 우리는 종종 압도당합니다. “해야 할 게 너무 많다”는 생각에 아무것도 시작하지 못하는 거죠. 이 책에서 다룬 내용도 적지 않습니다. AI 리터러시, 오케스트레이션, 문제 발견력, 파이자형 전문성, 지속적 학습 – 다 중요한 이야기이지만, 한꺼번에 다 하려고 하면 오히려 아무것도 못합니다.

그래서 마지막으로, 아주 작은 제안을 하나 드리려고 합니다.

내일, 딱 한 가지만 해보세요.

개발자라면, 평소에 반복적으로 하던 작업 하나를 AI에게 맡겨보세요. 그리고 그 결과를 꼼꼼히 검토해보세요. AI가 잘한 부분과 놓친 부분을 구분해보세요. 그것만으로도 “AI와 함께 일하는 감각”의 첫 발을 뗀 겁니다. 완벽하게 할 필요 없어요. 처음은 누구나 서툴거든요.

비개발자라면, AI에게 당신의 업무와 관련된 질문을 하나 던져보세요. “이 기획서의 약점은 뭘까?”, “이 보고서에서 빠진 관점이 있을까?”, “이 문제를 다른 시각에서 보면 어떻게 될까?” AI의 답변이 완벽하지 않아도 괜찮습니다. 그 답변을 평가하는 과정 자체가 당신의 역량을 키우는 연습이 되니까요.

혹시 아직 어떤 AI 도구도 사용해보지 않으셨다면, 가장 쉬운 것부터 시작하세요. 오늘 하루 동안 궁금했던 것 하나를 AI에게 물어보세요. 그 대답이 마음에 드는지, 부족한 점이 있는지 판단해보세요. 그것만으로도 AI와의 첫 대화를 시작한 겁니다.

누구든, 자신이 이번 주에 배운 한 가지를 다른 사람과 나눠보세요. 동료에게, 후배에게, 온라인 커뮤니티에. 작은 것이라도 괜찮습니다. 배움을 나누는 순간, 그 배움은 당신의 것이 되고, 동시에 누군가에게 영감이 됩니다. 8장에서 이야기한 “함께 배우는 힘”의 시작이 바로 이 작은 나눔이에요.

큰 변화는 작은 시작에서 옵니다. 오늘 이 책의 마지막 페이지를 넘기는 것이, 당신의 작은 시작이 될 수 있습니다.

그리고 한 가지 더. 주변에 같은 고민을 하고 있는 사람이 있다면, 이 책을 건네보세요. 혹은 이 책에서 인상 깊었던 내용을 나눠보세요. 혼자 변화에 대응하는 것보다, 같은 방향을 바라보는 사람들과 함께하는 것이 훨씬 힘이 됩니다. 전작에서도, 이번 책에서도 변하지 않는 한 가지 진실이 있다면, “결국은 사람”이라는 것이에요. 기술도 중요하고, 역량도 중요하지만, 그 모든 것을 의미 있게 만드는 것은 결국 사람과 사람 사이의 연결입니다.

코드 너머에서 만나는 것

이 책의 제목이 “코드 너머의 시대”입니다. 그리고 이 마지막 장의 제목이 “코드 너머에서 만나는 것들”이에요.

코드 너머에서 우리가 만나는 것은 무엇일까요?

그것은 기술이 아닙니다. 기술은 코드 “안”에 있는 것이니까요.

코드 너머에는 문제가 있습니다. 누군가의 불편, 누군가의 필요, 세상이 아직 풀지 못한 과제들. 그 문제를 발견하고 정의하는 것, 그것이 6장에서 이야기한 “문제 발견의 기술”이었습니다. AI가 “어떻게 만들 것인가”를 해결해주는 시대에, “무엇을 만들어야 하는가”를 아는 것이야말로 가장 희소한 경쟁력이에요.

코드 너머에는 사람이 있습니다. 그 코드를 사용할 사람, 함께 만들 사람, 그 코드로 인해 삶이 달라질 사람. 그 사람들을 이해하고 공감하는 것, 그것이 4장에서 이야기한 “AI가 가져갈 수 없는 것”이었습니다. AI가 감정의 단서를 인식할 수는 있지만, 진정한 공감은 인간의 생물학적, 사회적 경험에서만 나올 수 있거든요.

코드 너머에는 판단이 있습니다. 수많은 가능성 중에서 무엇을 선택하고 무엇을 포기할지, 옳은 것과 효율적인 것이 충돌할 때 어느 쪽을 택할지. 그 판단을 내리는 것, 그것이 AI가 대신할 수 없는 인간 고유의 영역이었습니다. 윤리적 판단, 전략적 선택, 가치의 우선순위 결정 – 이 모든 것에는 살아온 경험과 감정과 도덕적 추론이 결합되어야 합니다.

코드 너머에는 성장이 있습니다. 어제보다 나은 오늘을 만들려는 의지, 실패에서 배우는 겸손, 새로운 것 앞에서 느끼는 설렘. 그 성장의 여정을 지속하는 것, 그것이 8장에서 이야기한 “오래 가는 사람의 학습법”이었습니다. 기술은 빠르게 진부해지지만, 배우는 능력 자체는 배울수록 강해지는 역설. 그 역설이 우리의 희망입니다.

코드 너머에는 관계가 있습니다. “함께 일하고 싶은 사람”이라는 기준은 시대가 바뀌어도 변하지 않습니다. 경청하고, 공감하고, 신뢰를 쌓고, 함께 성장하는 것. 이것은 전작에서도 이야기했고, 이번 책에서도 다시 확인한 변하지 않는 진실입니다.

그리고 코드 너머에는, 결국 “나”가 있습니다. 어떤 기술을 다루든, 어떤 시대에 살든, 어떤 도구를 사용하든 – 그 모든 것의 주체인 나. 나의 호기심, 나의 가치관, 나의 관계, 나의 이야기.

AI가 아무리 똑똑해져도, 당신의 이야기를 대신 살아줄 수는 없습니다. 당신이 어떤 문제에 마음이 움직이는지, 어떤 사람들과 함께하고 싶은지, 어떤 세상을 만들고 싶은지 – 이것은 오직 당신만이 답할 수 있는 질문이에요.

당신은 이미 준비되어 있습니다

이 책을 끝까지 읽어주신 당신에게 마지막으로 전하고 싶은 말이 있습니다.

당신은 이미 준비되어 있습니다.

이 말이 빈말처럼 들릴 수 있다는 것을 알아요. “나는 아직 AI 도구도 제대로 못 다루는데”, “나는 개발자도 아닌데”, “나는 이미 너무 많은 변화를 겪어서 지쳤는데” – 이런 생각이 드실 수 있습니다.

하지만 한번 생각해보세요. 당신은 이 책을 읽었습니다. 변화를 외면하지 않고 정면으로 마주하려는 용기가 있었다는 뜻이에요. 그리고 이 책이 이야기하는 “오래 남는 사람의 조건” – 호기심, 학습 의지, 변화에 대한 열린 태도 – 을 이미 갖추고 계신 겁니다. 이 책을 집어 든 것 자체가 그 증거예요.

완벽하게 준비될 때까지 기다리지 마세요. 그런 날은 오지 않습니다. 기술은 계속 변할 것이고, 새로운 도구는 계속 등장할 것이고, 세상은 계속 달라질 것이니까요. 완벽한 준비란 환상입니다. 하지만 “변화에 대응할 준비”는 이미 되어 있을 수 있어요. 그리고 그 준비의 핵심은 특정 기술을 얼마나 아느냐가 아니라, 배움에 대한 의지와 사람에 대한 관심이 있느냐입니다.

기술의 변화는 빠릅니다. 하지만 사람의 성장에는 시간이 걸리고, 그래서 더 가치 있습니다. 빠르게 만들어지는 것은 빠르게 사라지지만, 천천히 쌓인 것은 오래 남습니다. 당신이 지금까지 쌓아온 경험, 관계, 판단력, 배움의 습관 – 이것들은 어떤 AI도 하룻밤에 복제할 수 없는 것들이에요.

AI 시대는 끝이 아닙니다. 새로운 시작입니다. 그리고 모든 시작은, 그것을 시작하기로 결심한 사람의 것입니다.

돌이켜보면, 인류는 항상 기술의 변화 앞에서 비슷한 두려움을 느꼈습니다. 인쇄기가 등장했을 때 필경사들이 느꼈을 두려움, 자동화가 공장에 도입되었을 때 노동자들이 느꼈을 불안, 인터넷이 모든 것을 바꿨을 때 기존 산업이 느꼈을 위기감. 매번 “이번은 다르다”고 말했지만, 매번 인간은 적응했고, 새로운 가치를 만들어냈고, 기술을 자신의 삶을 풍요롭게 하는 데 사용했습니다.

AI 시대도 마찬가지일 거예요. 물론 적응의 과정이 순탄하지만은 않을 겁니다. 어떤 일은 사라지고, 어떤 역할은 재편되고, 어떤 사람들은 전환의 고통을 겪을 거예요. 하지만 그 과정에서도, 배우고 적응하고 성장하는 사람들은 새로운 기회를 만들어낼 겁니다. 역사가 그것을 증명하고 있으니까요.

이 책이 당신에게 작은 나침반이 되었으면 좋겠습니다. 어디로 가야 할지 정확히 알려주는 지도는 아닐 수 있어요. 하지만 적어도 “북쪽이 어느 방향인지”는 보여드렸으리라 생각합니다. 변하는 것과 변하지 않는 것의 구분, AI가 가져가는 것과 가져갈 수 없는 것의 경계, 기술과 역량의 차이, 두려움과 기회의 관점 – 이 나침반이 있으면 길을 잃지 않을 수 있습니다.

마지막으로, 한 가지만 더 말씀드릴게요.

이 책을 읽는 동안 밑줄을 긋거나, 고개를 끄덕이거나, “나도 그런 적 있는데”라고 생각하신 순간이 있었다면 – 그 순간들이 바로 당신의 출발점입니다. 거기서부터 시작하세요. 거창할 필요 없습니다. 오늘 하나 배우고, 내일 하나 시도하고, 모레 한 사람과 나누면 됩니다. 그 작은 걸음들이 모여 당신만의 이야기가 될 겁니다.

코드가 사라진 자리에, 사람이 남습니다. 기술이 바뀐 자리에, 역량이 남습니다. 시대가 지나간 자리에, 이야기가 남습니다.

당신의 이야기는 이제부터입니다.