AI 시대, 최선을 다한다는 말이 달라지고 있다

요즘 나는 백엔드 개발만 하지 않는다.

프론트엔드도 만들고, 시스템 구조도 잡는다. 시장을 조사하고, 어떤 문제부터 해결할지 고민한다. 일정과 우선순위를 정하고, 만든 기능이 제대로 돌아가는지도 확인한다.

백엔드 개발자로 시작했는데, 하는 일이 꽤 많아졌다.

그렇다고 내가 갑자기 모든 일을 잘하게 된 것은 아니다. AI 덕분에 일단 해볼 수 있는 일이 많아진 쪽에 가깝다.

그런데 이렇게 일하다 보니 조금 이상한 점이 있었다.

내가 쓰는 AI는 유독 백엔드 일을 잘하는 것 같았다.

프론트엔드도 만들어주고 시장조사도 해주지만, 백엔드에서 나오는 결과가 가장 만족스러웠다.

처음에는 그냥 모델의 특성이라고 생각했다. 그런데 계속 쓰다 보니 다른 생각이 들었다.

AI가 백엔드를 잘하는 걸까.

아니면 내가 백엔드에서 AI를 더 잘 쓰고 있는 걸까.

같은 AI를 쓰는데, 왜 결과가 다를까

나도 Codex나 Claude Code를 쓴다. 다른 개발자들이 쓰는 것과 크게 다르지 않다. 나만 가지고 있는 특별한 AI가 있는 것은 아니다.

물론 같은 제품을 쓴다고 모델과 설정까지 전부 같은 것은 아니다. 그래도 같은 도구를 줬을 때 모두가 같은 결과를 만들지는 않을 것 같다.

백엔드 일을 할 때 나는 AI에게 꽤 구체적으로 물어볼 수 있다.

같은 요청이 두 번 들어오면 어떻게 되는지. 처리하다가 중간에 실패하면 데이터가 어떻게 남는지. 이 정보를 바꿀 수 있는 사람은 누구여야 하는지.

답을 보고 다시 물을 수도 있다. 당장은 돌아가겠지만 나중에 문제가 되겠다 싶은 부분이 보이기 때문이다.

프론트엔드는 조금 다르다.

화면은 나왔다. 버튼도 눌린다. 그런데 어딘가 불편하다.

문제는 그다음이다. 왜 불편한지, 무엇을 어떻게 바꾸면 나아지는지를 설명하는 일이 백엔드에서만큼 쉽지 않다. “뭔가 이상한데 좀 고쳐줘”라는 말로 돌아갈 때도 있다.

프론트엔드를 잘하는 사람이라면 내가 못 본 문제를 발견할 것이다. 어떤 정보를 먼저 보여줘야 하는지, 버튼을 누른 다음 사용자가 무엇을 기대하는지부터 볼 수도 있다.

PM이나 CEO라면 또 다를 것 같다. 이 기능이 필요한 사람은 누구인지, 사람들이 돈을 내고 쓸 만한지, 지금 꼭 만들어야 하는 것인지부터 물을 수 있다.

직함 때문에 잘한다는 뜻은 아니다. 각자 해본 일이 다르니, 눈에 들어오는 문제도 다르다는 이야기다.

그래서 지금은 이렇게 생각한다.

내 AI가 백엔드에 특별히 강하다기보다, 내가 백엔드에서 더 잘 묻고 더 잘 고치고 있는 것일 수 있다.

내가 보고 있는 결과에는 AI의 성능뿐 아니라 내 경험도 들어 있다. 무엇을 알려줬는지, 어떤 질문을 했는지, 어떤 오류를 그냥 지나치지 않았는지가 함께 반영된다.

그런데 그 차이도 점점 줄어들지 않을까

그렇다고 “결국 원래 잘하던 사람만 잘하게 된다”는 결론은 내리고 싶지 않다.

나는 AI가 더 좋아질수록 지금의 실력 차이도 어느 정도 줄어들 것이라고 생각한다. 내가 정확하게 짚어줘야 했던 문제를 AI가 먼저 발견할 수도 있다. 화면이 왜 불편한지 내가 설명하지 못해도, AI가 먼저 찾아서 고쳐줄 수도 있다.

이런 가능성을 보여주는 연구를 봤다.

P&G 직원 791명을 대상으로 한 실험에서는 AI와 혼자 일한 사람이 AI 없이 일한 2인 팀과 비슷한 수준의 신제품 제안을 만들었다. 연구개발 담당자는 기술 쪽으로, 사업 담당자는 사업 쪽으로 치우치던 경향도 AI를 쓰면서 줄었다. 다만 하루 동안 제안을 만드는 실험이었다. 제품을 출시하고 운영하는 일까지 혼자 해냈다는 뜻은 아니다.1

개발자 4,867명이 참여한 세 기업의 실험을 합친 연구도 봤다. AI 코드 완성 도구를 쓴 개발자의 완료 작업 수는 약 26% 늘어난 것으로 추정됐다. 경험이 적은 개발자에게서 개선 폭이 더 컸다. 지금의 모든 코딩 에이전트에 그대로 붙일 수 있는 수치는 아니지만, AI가 부족한 경험을 일부 메워줄 수 있다는 결과였다.2

이 연구만으로 앞으로 모든 격차가 사라진다고 말할 수는 없다. 그래도 내가 지금 잘하는 일이 앞으로도 나만 잘할 수 있는 일이라고 생각하기는 어렵다.

내가 프론트엔드에 들어가기 쉬워진 만큼, 다른 사람도 백엔드에 들어오기 쉬워진다.

나에게만 문이 열린 것은 아니다.

그래서 지금의 강점을 지키는 데만 머물고 싶지는 않다. 그 강점을 가지고 어디까지 해볼 수 있는지 넓혀보고 싶다. 대신 낯선 분야에서 결과물 하나를 만들었다고, 그 분야를 다 알게 됐다고 착각하지는 않으려 한다.

할 일이 없어지는 걸까, 만드는 데 사람이 덜 필요한 걸까

명확하게 정리된 일을 AI가 처리할 수 있다면, 같은 양의 일을 하는 데 필요한 사람도 줄어들 수 있다.

정해진 요구사항을 받아 그대로 구현하는 일만으로는 예전과 같은 경쟁력을 유지하기 어려워질 것이라고 생각한다.

다만 “이런 사람은 이제 필요 없다”는 식으로 나누고 싶지는 않다. 반복 작업처럼 보여도 그 안에 경험과 판단이 들어 있을 수 있다. 매일 운송 정보를 입력하는 사람이 어떤 거래처의 요청에서 자주 오류가 나는지 가장 잘 알고 있을 수도 있다.

사람을 나누기 전에, 그 사람이 무슨 일을 하고 있는지부터 봐야 한다.

국제노동기구의 2025년 자료도 이 둘을 구분하고 있었다. 전 세계 노동자 약 4분의 1이 생성형 AI의 영향을 받을 수 있는 직종에 속한다는 추정이었다. 일자리 4분의 1이 사라졌다는 뜻은 아니다. 직업이 통째로 없어지기보다는 그 안의 일이 달라질 가능성을 더 크게 봤다.3

나는 이 변화를 생각할 때 농업이 떠오른다.

미국 농무부 자료를 보면 1948년부터 2023년까지 농업 생산량은 약 세 배가 됐지만, 노동 투입은 76% 줄었다. 여기서 노동 투입은 단순히 일하는 사람 수를 센 값은 아니다. 기술과 장비, 일하는 방식이 바뀌면서 더 적은 노동으로 더 많이 생산하게 됐다는 이야기다.4

농업이 필요 없어져서 생긴 변화는 아니었다.

소프트웨어도 비슷한 방향으로 갈 수 있지 않을까. 해결할 문제가 사라지는 것이 아니라, 하나를 만드는 데 드는 시간과 비용이 줄어드는 것이다.

내가 일하는 물류 현장에도 아직 불편한 일이 많다. 같은 정보를 여러 번 옮기고, 사람마다 다르게 쓴 요청을 해석하고, 바뀐 내용을 상대방이 확인했는지 다시 물어본다.

전에는 만드는 비용이 너무 커서 그냥 두었던 문제도, 이제는 해결해볼 수 있을지 모른다.

하지만 문제가 많다고 내 제품을 사람들이 써주는 것은 아니다. 나만 쉽게 만드는 것도 아니다. 더 많은 사람이 만들 수 있다면 공급도 늘어난다. 수요가 그만큼 늘어날지, 필요한 사람이 얼마나 달라질지는 따로 봐야 한다.

그래서 나에게 중요한 질문은 “얼마나 많이 만들 수 있나”보다 **“누가 이걸 필요로 하나”**에 가깝다.

그러면 지금까지 공부한 것은 뭐가 될까

대학에서 배운 내용이 회사에 와서 바로 쓸 수 있는 기술은 아니었다. 기초적이고 원리적인 내용이 많았다. 배운 것과 실제로 제품을 만드는 일 사이에는 거리가 있었다.

그 거리는 AI가 나오기 전에도 있었다.

그런데 내가 백엔드에서 AI를 상대적으로 잘 쓰는 이유를 생각해보면, 그동안 배운 것을 빼고 설명하기도 어렵다.

동시에 요청이 들어오면 어떤 문제가 생기는지, 실패한 작업을 다시 실행해도 괜찮은지, 데이터를 바꾸면 다른 기능에 어떤 영향을 주는지. 이런 이해는 내가 코드를 직접 쓰지 않는 순간에도 필요하다.

배운 게 사라진 것보다는 쓰는 곳이 달라졌다고 느낀다. 예전에는 직접 만들기 위해 썼다면, 지금은 무엇을 만들지 정하고 만들어진 것을 확인하는 데에도 쓴다.

그래서 기초는 필요 없고 제품만 만들면 된다는 생각에는 동의하기 어렵다.

제품이 완성됐다고 내가 그만큼 배운 것도 아닐 수 있다. Anthropic이 2026년 1월 공개한 개발자 52명의 학습 실험에서는, 낯선 라이브러리를 사용한 뒤 치른 시험의 평균 점수가 AI 사용 집단은 50%, 비사용 집단은 67%였다. 작업 시간 차이는 통계적으로 뚜렷하지 않았다. 짧은 실험이라 장기적인 실력까지 설명하지는 못하지만, 결과물을 얻는 것과 이해하는 것이 다를 수 있다는 점은 기억에 남았다.5

AI를 쓰지 말자는 이야기는 아니다. 나도 계속 쓸 것이다.

다만 중요한 부분은 한 번 더 확인하려 한다. 왜 이렇게 만들었는지 설명할 수 있는지. 조건이 바뀌면 고칠 수 있는지. 잘못됐을 때 어디부터 봐야 하는지.

요즘의 AI 활용법이 모두 정리돼서 학교에서 가르쳐줄 때까지 기다릴 수도 없다고 생각한다. 나부터도 어제 쓰던 방법을 오늘 바꾸고 있다. 학교에서는 오래 쓸 기초를 배우고, 아직 정리되지 않은 사용법은 직접 해보며 채워야 할 것 같다.

만들다가 막히면 공부하고, 공부한 것으로 다시 만들어본다.

지금 나에게는 그 방식이 가장 잘 맞는다.

내가 더 배우고 싶은 것은 출시까지 가보는 일이다

그래서 나는 하나의 제품을 실제 시장까지 가져가는 경험을 더 쌓고 싶다.

여기서 출시는 서버에 올리고 주소 하나 만드는 것만을 뜻하지 않는다. 필요한 사람을 찾고, 만들어서 써보게 하고, 왜 안 쓰는지 물어보고, 다시 고치는 일까지 포함한다.

내 컴퓨터에서 잘 돌아가는 것과 누군가의 일에 도움이 되는 것은 다르기 때문이다.

AI로 운송 등록을 돕는 기능을 만들 때도 그랬다.

엑셀 파일을 읽어서 운송 정보를 만들어냈다. 여기까지만 보면 잘된 것 같다.

그런데 주소를 잘못 읽었다면 사용자가 알아볼 수 있을까. 금액을 쉽게 고칠 수 있을까. 한 줄이 실패했다고 나머지까지 다시 기다려야 하는 건 아닐까.

이런 문제를 해결하지 못하면, AI는 열심히 일했는데 사용자는 더 피곤해질 수도 있다.

내가 알고 싶은 것은 결국 이것이다.

“그래서 직접 입력할 때보다 편해졌나?”

기능을 만들었는데 아무도 쓰지 않는다면 그 이유도 알아야 한다. 기능이 부족한 것인지, 기존 방식이 더 편한지, 결과를 믿기 어려운지. 아니면 처음부터 사람들이 별로 불편해하지 않는 문제를 내가 붙잡고 있었던 것인지.

필요한 사람에게 어떻게 알릴지, 계속 운영할 비용은 감당할 수 있을지도 봐야 한다.

앤드루 응의 「Shaping the build」를 읽으면서도 비슷한 생각을 했다. 정해진 기능을 구현하는 데서 끝내지 않고, 무엇을 만들지 판단하고, 사용자의 반응과 실험 결과를 보고 다음 일을 정하는 역량을 다룬 글이었다. 연구 결과라기보다는 실무적인 제안이었고, 내가 앞으로 배우고 싶은 방향과 맞닿아 있었다.6

이 말이 모든 개발자는 PM이나 CEO가 되어야 한다는 뜻은 아니다. 모든 일을 혼자 잘해야 한다는 뜻도 아니다. 모르는 부분은 도움을 받아야 한다. 누구와 같이 해야 하는지 아는 것도 실력이다.

다만 “제가 맡은 개발은 끝났습니다”에서 관심까지 끝내고 싶지는 않다.

만드는 능력뿐 아니라, 실제로 쓰이게 만드는 경험도 쌓고 싶다.

그 과정에 필요한 조사와 판단도 AI가 더 잘 도와줄 것이다. 사람만 할 수 있는 일을 찾아 지키기보다는, AI와 함께 어디까지 해결할 수 있는지 계속 넓혀보고 싶다.

최선을 다하라는 말은 일을 더 많이 하라는 뜻이 아니다

매일 데이터를 복사해서 붙여넣는 일이 있다고 해보자.

익숙해져서 하루에 백 건 하던 것을 이백 건으로 늘렸다. 당장은 도움이 된다. 그런데 어느 순간에는 다른 질문도 나와야 한다.

“이걸 왜 사람이 계속 옮기고 있지?”

같은 일을 더 빨리 하는 것과, 그 일을 안 해도 되게 만드는 것은 다른 기여다. 나는 두 번째에도 시간을 쓰고 싶다.

남는 맥북을 빌드 머신으로 활용하려 했던 것도, 테스트 시간을 줄이려는 것도 비슷한 이유다. 반복해서 기다리는 시간을 줄여 다른 문제에 쓸 수 없을까 하는 생각이다.

물론 확인해야 할 테스트를 빼서 빨라지는 것은 원하던 결과가 아니다. 같은 것을 제대로 확인하면서 덜 기다려야 한다.

노래를 들으면서 익숙한 작업을 하는 게 잘못됐다는 뜻도 아니다. 문제는 음악이 아니라, 익숙하다는 이유로 지금 방식을 한 번도 의심하지 않는 것이다.

모든 일을 자동화할 필요는 없다. 만드는 비용이 더 들 수도 있다. 그래도 더 나은 방법이 없는지는 생각해봤으면 한다.

이 말은 나에게도 똑같이 적용된다.

AI에게 일을 많이 시켰다고 일을 잘한 것은 아니다. 여러 모델에 같은 내용을 다시 물었다고 검토가 충분해지는 것도 아니다. 한 번 더 물어서 무엇을 확인했고, 어떤 결정을 바꿨는지가 중요하다.

백엔드도 하고 프론트엔드도 하고 시장조사도 했다는 사실만으로 성과가 되는 것은 아니다. 그래서 무엇이 나아졌는지를 봐야 한다.

괜히 바쁘게만 일하는 것은 AI가 있어도 가능하다.

오히려 더 쉽게 가능할지도 모르겠다.

AI가 좋아지는데, 나는 전선과 공구도 눈에 들어온다

한편으로는 하드웨어와 현장 기술이 더 중요해질 것 같다는 생각도 한다. 반도체만이 아니라 전기, 배선, 설비, 수리 같은 일들이다.

국제에너지기구의 2025년 보고서에서는 데이터센터를 늘릴 때 전력망과 설비 공급이 문제가 될 수 있다고 다뤘다. 변압기와 케이블처럼 실제로 설치해야 하는 물건도 중요했다. AI의 성능만 좋아진다고 해결되는 문제가 아니었다.7

그렇다고 이 분야는 영원히 자동화되지 않을 것이라고 생각하지는 않는다. 다만 디지털 기술이 좋아진다고 화면 밖의 일이 덜 중요해지는 것은 아닌 것 같다.

얼마 전 모니터를 고치겠다고 멀티미터를 꺼냈을 때도 그랬다. AI는 이것저것 설명해줬다. 어디를 확인해야 하는지도 알려줬다.

설명은 꽤 구체적이었다.

모니터는 못 고쳤다.

결국 새 모니터를 샀다.8

정보를 얻기 쉬워지는 것과 실제로 해내는 것은 다른 일이었다.

물류 소프트웨어도 마찬가지다. 화면에서 주소를 바꾸는 것은 쉬워 보여도, 이미 그 주소로 가고 있는 기사님이 있다면 이야기가 달라진다. 누가 바꿔도 되는지, 누구에게 알려야 하는지, 운송에 문제가 생기지 않는지까지 봐야 한다.

내가 더 잘 이해해야 할 것은 코드만이 아니다. 그 코드가 바꾸는 실제 업무도 함께 알아야 한다.

그래서 나는 팀에서 뭘 해야 할까

일단 관심 있는 사람들과 먼저 해보려고 한다.

모두를 같은 속도로 움직이게 만들 생각은 없다. 모두가 준비될 때까지 기다리고 싶지도 않다. 나 역시 관심 있는 사람이 많은 곳에서 배우고, 내가 도움이 될 수 있는 일을 하고 싶다.

여기서 관심은 최신 모델 이름을 많이 안다는 뜻이 아니다.

자기 일에서 불편한 것을 발견하고, 다르게 해보고, 정말 나아졌는지 확인하려는 태도에 가깝다. 내가 쓰는 도구를 좋아하지 않아도 그런 사람은 충분히 있을 수 있다.

예전에 AI Advisor를 맡았을 때는 환경만 만들어주면 사람들이 알아서 잘 쓸 것이라고 생각했다. 해보니 그렇지 않았다. 직접 문제를 같이 풀어보는 일과, 다음에는 스스로 할 수 있게 돕는 일이 모두 필요했다.9

지금도 비슷하게 생각한다.

도구를 쓰라고 하면서 배울 시간을 주지 않으면 시도하기 어렵다. 알아서 해보라고 하면서 모든 결정을 나에게 확인받게 해도 마찬가지다.

함께 해보려는 사람에게는 작은 일이라도 스스로 판단해서 끝낼 기회를 주고 싶다. 내가 하면 더 빠르다는 이유로 계속 가져오면 그 사람은 해볼 수가 없다.

팀이 서로의 경험을 나눌 수 있으면 좋겠다. 내가 못 본 화면의 문제는 프론트엔드 개발자가 찾고, 개발자가 놓친 실제 업무의 문제는 운영 담당자가 찾을 수 있다. 잘된 방법은 다음 사람도 쓸 수 있게 남기면 된다.

DORA의 2025년 보고서에서도 AI가 조직의 기존 강점과 약점을 더 크게 드러낸다는 분석을 봤다. 도구를 들여오는 것만큼 팀이 어떻게 일하는지도 중요하다는 내용이었다.10

그래서 내 역할도 돌아보게 된다. AI 덕분에 구현은 빨라졌는데 모든 확인이 나에게 몰린다면, 팀은 결국 나를 기다리게 된다.

내가 더 많은 일을 처리하는 것만으로는 부족하다.

내가 하나하나 설명하지 않아도, 동료가 잘 끝낼 수 있는 일을 늘리고 싶다.

모두를 끝없이 설득하는 데 힘을 쓰지는 않으려 한다. 대신 먼저 시도한 결과는 다른 사람도 쓸 수 있게 남기고 싶다. 시작은 관심 있는 사람들과 하더라도, 그 덕을 보는 사람이 그 사람들뿐일 필요는 없다.

아낀 시간을 전부 일로 채우고 싶지는 않다

나는 앞으로 사람을 즐겁게 하는 일도 더 중요해질 것 같다. 게임, 이야기, 음악, 취미, 사람들과 함께 보내는 시간 같은 것들이다.

정해진 미래라기보다는 내 기대에 가깝다. 만드는 일이 쉬워진다면, 무엇을 만들 수 있느냐만큼 사람들이 무엇을 좋아하느냐도 중요해지지 않을까.

그런데 생산성이 높아졌다고 여유가 저절로 생기는 것은 아닐 것이다. 아낀 시간에 일을 더 넣으면 된다.

나는 그러고만 싶지는 않다.

더 빨리 일하는 이유가 남은 시간까지 전부 일하기 위해서는 아니었으면 한다. 궁금한 것을 만들어보고, 글을 쓰고, 게임을 하고, 사람들과 시간을 보내는 것도 중요하다.

동료들이 모두 나처럼 일에서 재미를 찾아야 하는 것도 아니다. 맡은 일을 잘하면서 다른 곳에 더 큰 관심을 둘 수도 있다.

일을 더 잘하는 것과 삶 전체를 더 많이 일하게 만드는 것은 구분하고 싶다.

정답은 아직 모르겠다

나는 AI를 잘 쓰는 사람에서 멈추고 싶지는 않다.

AI와 함께 문제를 찾고, 제품을 만들고, 필요한 사람에게 전달하고, 잘못됐으면 고칠 수 있는 사람이 되고 싶다. 지금 잘하는 것은 활용하고, 모르는 것은 배우고, 혼자 못 하는 것은 같이 하고 싶다.

이 방향이 정답인지는 모르겠다.

지금 괜찮다고 생각하는 방법이 나중에는 틀릴 수도 있다. 다른 팀에서는 안 맞을 수도 있다. AI가 더 좋아지면 아예 고민할 필요가 없어지는 문제도 있을 것이다.

그래도 답이 정리될 때까지 기다리지는 않으려 한다.

일단 작게 해보고 싶다. 결과를 보고, 생각과 다르면 고치면 된다. 효과가 없으면 그만두고 다른 방법을 찾을 수도 있다.

물론 많이 해봤다는 사실만으로 답에 가까워지는 것은 아니다. 같은 실수를 계속 반복할 수도 있다. 그래서 해본 뒤에는 무엇이 달라졌는지 봐야 한다.

사용자가 덜 번거로워졌는지. 동료가 덜 헤매는지. 다음에 비슷한 일을 할 때 조금 더 쉽게 끝낼 수 있는지.

내 생각이 맞았다는 것을 증명하는 것보다 그런 결과가 더 중요하다.

정답을 알고 있어서 시도하는 것은 아니다.

무수한 시도 끝에, 그 결과를 보고 생각을 고치다 보면 더 나은 답으로 수렴할 수 있지 않을까.

지금은 그렇게 생각한다.

참고 자료

자료 확인일: 2026년 9월 29일.

Footnotes

  1. Dell’Acqua et al., The Cybernetic Teammate: A Field Experiment on Generative AI and Teamwork, Organization Science. P&G 직원 791명을 분석한 사전등록 무작위 현장 실험. 하루 동안 신제품 제안을 만드는 과제로, 출시 이후의 운영이나 시장 성과를 측정한 연구는 아니다. ↩

  2. Cui et al., The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers, 2025년 6월. Microsoft, Accenture, 익명의 Fortune 100 기업에서 개발자 4,867명의 무작위 실험을 통합 분석했다. 완료 작업 수 증가 추정치 26.08%, 표준오차 10.3%. 당시 코드 완성 도구를 평가했으며, 현재의 모든 코딩 에이전트나 소프트웨어 품질 전체에 관한 수치는 아니다. ↩

  3. Gmyrek et al., Generative AI and Jobs: A Refined Global Index of Occupational Exposure, ILO Working Paper 140, 2025년 5월 20일. 직업별 업무가 생성형 AI의 영향을 받을 가능성을 추정한 자료다. 실제 실직률을 측정한 자료는 아니다. ↩

  4. USDA Economic Research Service, Productivity Growth in U.S. Agriculture, 2026년 7월 20일 갱신. 1948–2023년 미국 농업의 생산량과 투입 지표를 다룬다. 노동 투입은 종사자 수와 다른 지표다. 본문에서는 생산량 증가와 노동 감소가 함께 일어난 사례로만 사용했다. ↩

  5. Shen and Tamkin, How AI assistance impacts the formation of coding skills, 2026년 1월 29일. 주로 주니어인 개발자 52명이 낯선 Python Trio 라이브러리를 배우는 무작위 실험. 사후 평가 평균은 AI 집단 50%, 비사용 집단 67%로 17%포인트 차이였다. 작업 시간 차이는 통계적으로 유의하지 않았다. 작은 표본의 단기 학습 결과이며, 모든 AI 사용이나 장기 역량의 효과로 일반화할 수 없다. ↩

  6. Andrew Ng, AI Engineering Skills Map: Shaping the build, 2026년 9월 11일. 제품 판단, 사용자 피드백과 기술 실험, 협업, 실제 가치에 대한 책임을 다룬 저자의 실무적 견해다. 실험 연구와 구분해 참고했다. ↩

  7. International Energy Agency, Energy and AI — Executive summary, 2025. 전력망 연결과 변압기·케이블 등 설비 공급의 제약을 다룬 분석이다. 특정 직종의 고용을 보장하는 근거로 사용하지 않았다. ↩

  8. JiYong, 눈으로만 봤던 납땜을 직접 해봤다., 2026년 6월 20일. 모니터 수리를 직접 시도한 경험을 기록한 기존 글. ↩

  9. JiYong, 회사에서 AI Advisor로 보낸 3개월 회고, 2025년 11월 15일. AI 도구 교육과 실제 업무 개선을 함께 해야 했던 경험을 기록한 기존 글. ↩

  10. Google Cloud DORA, State of AI-assisted Software Development 2025, 2025. AI의 효과를 조직의 기존 시스템과 일하는 방식에 연결한 연구 보고서. 본문의 팀 운영 방향은 이 보고서와 구분되는 개인적인 판단이다. ↩

Series

AI와 일하는 방식

이 글은 "AI와 일하는 방식" 시리즈의 4번째 기록입니다.

04 / 04
  1. 01회사에서 AI Advisor로 보낸 3개월 회고
  2. 02AI가 코드를 써주는 시대에, 우리는 무엇을 책임져야 하나
  3. 03요즘 나는 AI로 노래를 만들고 있다
  4. 04AI 시대, 최선을 다한다는 말이 달라지고 있다
시리즈 전체 보기