서론
최근에는 AI Agent를 사용해 코드를 작성하는 것이 일상이 되었습니다. 한편으로는, 직접 코드를 작성하는 빈도는 정말 줄었다고 느낍니다. 몇 년에 걸쳐 조금씩 변했다기보다는, 2년이 채 되지 않은 시간 동안의 변화입니다.
지금은 새로운 모델이 나올 때마다 Artificial Analysis 그래프를 살펴봅니다. 이전에는 충분하다고 생각했던 성능을 뛰어넘으면서도 속도가 빠르고 비용과의 균형까지 좋은 지점이 어디인지 확인하는日々가 되었습니다. 모델과 추론에 필요한 노력(Reasoning Effort)의 조합을 보며, '이 정도면 괜찮지 않을까' 싶은 것을 시도해보는 나날을 보내고 있습니다.
그러던 중 문득 '5년 후쯤에는 엔지니어로서의 일은 어떻게 되어 있을까'라는 생각을 하게 되었습니다. 기회가 되어서 현재의 생각을 정리해보고자 합니다.
현재로서는 5년 후의 엔지니어는 지금보다 코드를 적지는 않지만, 지금보다 더 많은 소프트웨어에 책임을 지는 직업이 아닐까 생각합니다. AI에 대한 위임이 PR(Pull Request) 단위에서 기능이나 제품 단위로 확장된다면, PR 단위로 업무를 파악하던 사람도 서비스 전체를 보게 될지도 모릅니다. 그 책임감을 다할 수 있는 개발 프로세스나 AI 실행 환경을 설계하는 일이 지금보다 커질 것이라고 생각합니다.
예를 들어, 서비스에서 예상치 못한 문제가 발생했을 때, 사용자에게 설명하고 대응에 책임을 지는 것 또한 포함됩니다.
이러한 설명과 대응에 책임을 지기 위해서는 제공하는 측이 서비스의 구조를 이해하고 있어야 합니다. AI에게 개발을 맡기게 되더라도 소프트웨어를 블랙박스로 취급할 수는 없습니다. 그곳에 엔지니어로서의 의무가 남아있다고 생각합니다.
전제: AI에 의한 개발 변화
제가 스스로 이 변화를 강하게 느끼기 시작한 것은 2025년 2월 26일에 공개된 mizchi 씨의 'CLINE에 전부 걸어라' 정도였습니다. 이는 업계 전체의 시작이라는 이야기라기보다는, AI에게 작업을 맡겨 구현과 확인을 반복하는 개발 방식이 가까워졌다는 감각입니다.
그때부터 2026년 11월까지는 아직 2년도 지나지 않았습니다. 이제 제 감각으로는 Claude Code에 구현을 맡겨 PR을 만드는 것도 거의 당연해졌습니다.
레바테크가 2026년 7월 15일에 발표한 조사에 따르면, AI를 매일 사용하는 IT 엔지니어는 43.4%, 주 몇 회 사용하는 사람은 28.3%로, 합쳐서 71.7%였습니다. 코딩/구현에 활용하는 비율은 40.9%입니다. 조사 기간은 2026년 5월 26일28일이며, 대상은 2059세 IT 엔지니어 572명입니다.
이는 AI 전반의 업무 이용에 대한 수치이며, Claude Code로 PR을 만드는 사람의 비율은 아닙니다. 제 체감과 업계 전체의 보급률은 분리해서 보고 싶지만, AI를 일상적으로 사용하는 것 자체는 확산되고 있는 것 같습니다.
논점: 개발을 AI에게 맡겨도 설명 책임은 남는다
제가 생각하는 구조를 그림으로 나타내면 이렇습니다.
서비스 이용 사용자
서비스 내부에서는 AI에 의해 소프트웨어 개발이 빠르게 돌아갑니다. 이용 사용자가 접촉하는 것은 그 바깥쪽의 서비스입니다.
예를 들어, 예약 서비스에서 예약을 잃어버렸다고 가정해 봅시다. 소프트웨어 내부적으로는 데이터 불일치(inconsistency)가 원인이지만, 이용 사용자 입장에서는 존재했어야 할 예약을 잃게 되는 사건입니다.
서비스 제공 측의 설명 책임
무슨 일이 일어났는지, 누구에게 영향을 미쳤는지, 어떻게 대응할 것인지를 설명하는 것은 서비스를 제공하는 사람이나 조직입니다. 'AI가 만들어서 모르겠습니다'로는 이용 사용자에게 대한 설명 책임을 다할 수 없습니다.
여기서 말하는 설명은 장애 발생 후의 보고에만 국한되지 않습니다. 평소에도 왜 이 동작을 했는지, 어떤 제약이나 리스크가 있는지 등을 설명하기 위해서도 구조를 이해하는 것이 필요합니다.
설명과 대응에 필요한 구조적 이해
어디서 예약 데이터가 바뀌는지. 어떤 처리에 의존하고 있는지. 무엇을 조사해야 영향 범위를 알 수 있고, 어떻게 해야 복구할 수 있는지. 구조를 이해하지 못하면 설명이나 대응의 근거도 가질 수 없습니다.
소프트웨어의 동작과 이용 사용자에게 발생하는 일을 연결하여 이해하는 것. 거기에 엔지니어의 책무가 있다고 생각합니다. 구현을 AI에게 맡기더라도, 설명 책임을 다하기 위해 필요한 이해까지 놓칠 수는 없습니다.
문제가 생겼을 때, 대응을 서두르며 AI의 설명을 확인하지 않고 채택하면 오히려 문제를 확산시킬 가능성도 있습니다. 로그나 실제 동작을 따라가며 무엇이 일어나고 있는지, 그 대응이 타당한지 꼼꼼하게 확인하는 것. 결과적으로는 그것이 더 빠를 수도 있습니다. 급할수록 돌아가라는 것이라고 생각합니다.
고찰: AI에게 개발을 맡기는 범위가 넓어질 때, 서비스 전체에 대한 책임을 어떻게 다할 것인가
AI에게 개발을 맡기는 단위의 변화: PR에서 기능/제품으로
지금은 AI에게 PR(Pull Request)을 만들게 하고 그 차이점을 확인하는 형태라 할지라도, 앞으로는 “이 기능을 제공하고 싶다”, “이 제품을 개선하고 싶다”라는 단위로 맡기게 되는 경우가 늘어날 것이라고 생각합니다.
PR 단위로 업무를 파악해왔다면, 인간이 책임지는 범위 역시 개별적인 차이점(diff)에서 기능이나 제품 전체로 확장될 수 있습니다. 무엇을 충족시켜야 사용자에게 전달할 수 있는지 결정하고, 제공 후의 동작이나 영향을 파악해야 합니다. 이를 위해 이해해야 하는 대상 또한 단순히 차이점에 국한되지 않고, 서비스를 지탱하는 소프트웨어들 간의 관계까지 넓어질 것 같습니다.
이미 풀 사이클로 관여해 온 경우
한편으로는, AI Agent에 의한 개발이 확산되기 이전부터 서비스 전체에 책임을 져왔던 경우도 있습니다. Netflix가 2018년에 공개한 풀 사이클(Full Cycle) 개발자 관련 기사에서는 개발팀이 설계부터 운영, 지원까지 책임지는 모델을 소개했습니다. CARTA TECH BLOG에 일본어 번역본이 게재되어 있습니다.
원문은 다음과 같습니다.
도구 및 자동화에 대한 투자를 통해 팀이 개발부터 운영까지 책임을 질 수 있도록 하는 개념이라는 이해입니다.
애초부터 이러한 풀 사이클 엔지니어링을 해왔다면, 책임지는 범위가 PR에서 서비스 전체로 확장된다는 변화는 없습니다. AI에게 맡기는 단위가 커진다 하더라도, 만든 결과물의 이용이나 운영까지 책임진다는 본질은 변하지 않는다고 생각합니다.
책임을 다할 수 있는 개발 프로세스와 하네스(Harness)
어느 경우든, AI에게 맡기는 범위나 변경량이 늘어나는 상황에서는 서비스 전체를 이해할 수 있는 상태를 유지할 필요가 있습니다. 스스로 구현하며 파악했던 것도, 위임한 곳에서는 다른 방법으로 확인해야 할 필요가 생깁니다.
여기서 중요해지는 것이, 이해와 판단에 필요한 정보를 얻을 수 있는 개발 프로세스나 하네스(Harness)의 설계라고 생각합니다. 여기서 하네스는 AI에게 전달할 사양이나 제약 조건, 사용할 도구 및 권한, 검증 및 기록 메커니즘을 포함하는 실행 환경으로 간주합니다.
어디까지 자동 진행해도 되는지, 어떤 조건에서 인간의 판단으로 되돌려야 하는지, 무엇을 근거로 결과물을 수용할지를 미리 결정해 두는 것입니다. 변경 의도나 검증 결과를 추적하고, 필요할 때 조사하거나 멈출 수 있도록 만드는 것입니다. 맡기는 범위와 책임을 다할 수 있는 범위를 일치시켜 나갈 필요가 있습니다.
모든 구현 내용을 머릿속에 담아두는 것은 어렵더라도, 중요한 동작 방식이나 의존 관계를 파악하고, 모르는 부분은 조사할 수 있는 상태를 유지하고 싶습니다. 테스트나 로그, 필요한 코드를 추적하여 AI의 설명과 실제 동작이 일치하는지 확인하는 것도 포함됩니다.
이전 리뷰 기사에서도, 확인 자동화를 진행한 끝에 사양이나 배경 이해를 팀 차원에서 맞추는 시간이 남을 것이라고 생각했습니다.
이러한 이해의 공유 역시, 팀으로서 서비스의 구조나 변경 이유를 설명할 수 있는 상태를 유지하는 것으로 이어진다고 생각합니다.
Addy Osmani의 “Own the Outer Loop” 또한, AI가 조사·구현·검증을 반복하는 동안 인간이 그 경계에서 판단하고, 이유를 설명할 수 있음을 중시하는 개념이라는 이해입니다.
시스템을 이해하는 힘은 어떻게 기를 것인가
다만, 이해를 유지한다는 이야기는 이미 개발 경험이 있다는 것을 전제로 하고 있는 듯한 느낌도 듭니다. 앞으로 경험을 쌓게 될 주니어는 그 이해를 어떻게 습득해야 할까요?
스스로 구현하고, 동작하지 않아 조사하고, 고치는 과정 자체가 시스템을 이해하는 기회가 되기도 했습니다. Addy의 “Don't Outsource the Learning”에서도 태스크를 완료하는 것과 배우는 것은 별개의 목표로 다루어지고 있습니다. AI에게 구현을 맡긴다면, 학습의 기회도 의식적으로 만들어야 할지도 모릅니다.
그 점에서 Addy가 다른 글에서 작성한 주니어를 위한 조언도 참고가 될 것 같습니다. AI의 출력을 학습 자료로 해석하거나, 경험자와 설계 이유에 대해 이야기하는 것이 권장됩니다.
예를 들어, 작은 변경 사항에 대해 어떻게 동작할지 예상하고, 코드나 테스트로 확인하며, 그 이유를 설명해 보는 것입니다. AI의 출력을 소재로 삼아도 그러한 경험을 쌓을 수 있을 것 같습니다. 팀으로서 함께 그 설명을 확인하는 시간을 가질 수 있다면 좋을 것 같습니다.
맺음말
5년 후에는 AI에게 맡기는 단위가 PR에서 기능이나 제품으로 확장되어 있을 것이라고 생각합니다. PR 단위로 업무를 파악해왔다면, 책임지는 범위도 넓어질 것입니다. 이미 풀 사이클로 관여해 왔다면, 그 책무는 이전부터 담당해 온 것입니다.
AI에 구현을 맡기더라도 서비스를 사용하는 것은 인간입니다. 이용 사용자에게 설명하고 대응하기 위해서는 제공 측면에서 시스템의 구조를 이해할 필요가 남아있다고 생각합니다. 위임하는 범위가 넓어지는 상황 속에서, 그 이해도를 유지하고 책임을 다할 수 있는 개발 프로세스나 하네스(Harness)를 설계하는 것이 이전보다 더 큰 과제가 될 것 같습니다.
그렇긴 해도 AI 역시 개발 방식이 계속 변화하고 있습니다. 현재의 생각을 고정하지 않고, 그때그때 무엇을 AI에 맡기고 인간이 무엇을 이해하고 있어야 할지 지속적으로 고민해 나가는 것이 중요하다고 생각합니다.
Discussion
