엔지니어링·AI·기술리더십

AI 시대, 내 역할의 범위와 목표

Stripe에서 AI 시대의 엔지니어 역할을 다룬 글을 계기로, 최근 실제 업무와 다음 목표를 정리했다.

문제
AI로 실행 속도가 빨라진 환경에서 직접 구현과 조직 전체의 기술 책임 사이에 있는 내 역할을 구체적으로 정의해야 했다.
선택
직접 구축과 문제 구조화, 동료 지원, 품질 검증을 현재 역할의 네 축으로 정했다.
결과
현재 맡고 있는 네 가지 역할 범위와 다음 목표를 구분했으며, 혼자 더 많이 처리하는 방식은 목표에서 제외했다.

최근 2026년 Stripe에서 Staff Engineer로 일한다는 것을 읽었다. AI가 일을 편하게 해주는 만큼 Staff Engineer에게 기대하는 결과의 범위도 커지고 있다는 글이었다. 여러 에이전트를 병렬로 움직이는 능력, 여러 프로젝트의 상태와 품질을 함께 보는 시야, 동료의 결과까지 좋아지게 만드는 역할이 필요하다는 내용이었다.

Stripe의 환경을 그대로 내 상황에 대입할 수는 없다. 다만 최근 몇 달 동안 맡았던 일을 돌아보니, 내 역할도 이미 한 프로젝트의 구현을 잘 끝내는 데서 멀어지고 있었다. 지금 무엇을 맡고 있고 어디까지 넓혀야 하는지 정리할 필요가 있었다.

실제로 맡은 문제

최근 업무는 한 직무 이름으로 묶기 어려웠다. 내부 CMS를 직접 설계하고 운영했고, 고객지원 조직의 수기 업무를 웹 서비스로 옮기기 위한 범위를 정리했다. 비개발자가 바이브코딩으로 업무 도구를 만들 수 있도록 온보딩했고, 배포 권한과 보안 알림, 사내 봇의 운영 환경, 도메인 이전 같은 문제도 함께 다뤘다.

표면만 보면 서로 다른 일이다. 공통점은 담당 조직이나 해결 범위가 처음부터 명확하지 않았다는 데 있었다. 요청은 들어왔지만 무엇부터 정해야 하는지 모호하거나, 여러 시스템과 팀 사이에 걸쳐 있어 한 팀의 작업만으로 끝나지 않는 문제였다. 나는 이 빈 구간에 들어가 다음 결정을 내릴 수 있는 상태까지 만드는 일을 맡고 있었다.

확인한 사실과 제약

직접 만드는 능력은 여전히 필요했다. 운영 중인 CMS에서 장애가 나면 원인을 좁히고 복구해야 했고, 빠른 검증이 필요한 내부 도구는 기획부터 배포까지 손을 대야 했다. 현장에서 멀어지면 설계와 정책이 실제 문제를 놓치기 쉽다.

반대로 모든 문제를 직접 처리하면 내가 병목이 됐다. 일대일로 같은 설정을 반복해 알려주거나, 요청이 들어올 때마다 새 도구를 대신 만들어주는 방식은 처리량에 한계가 있었다. AI로 구현 속도를 높여도 검토할 맥락과 운영 책임까지 자동으로 생기지는 않았다. 빠르게 만든 결과가 많아질수록 배포 전 검증, 권한, 데이터 접근, 유지보수 주체를 더 일찍 확인해야 했다.

내가 한 선택

현재 역할의 범위를 네 가지로 정리했다.

첫째, 중요한 병목에서는 직접 만든다. 설계만 전달하고 빠지는 것이 아니라, 실제 코드와 운영 환경을 확인할 수 있어야 한다.

둘째, 모호한 요청을 조직이 결정할 수 있는 형태로 바꾼다. 실제로 수십 개의 업무 시트를 전부 확인해 전환 대상과 제외 대상을 나누고, 필요한 기능과 단계별 오픈 범위를 정리한 뒤 담당 조직의 결정을 요청했다.

셋째, 내가 없어도 다음 사람이 움직일 수 있게 만든다. 바이브코딩 온보딩에서 막힌 설정을 대신 처리하는 데서 끝내지 않고, 다음 사람도 그대로 사용할 수 있는 가이드로 남겼다. 코드 리뷰와 기술 결정 기록도 같은 목적을 가진다.

넷째, 속도를 막지 않으면서 품질 경계를 만든다. 자동 배포가 실제로 동작하는지 확인한 뒤 직접 배포 권한을 줄였고, 외부 공개 경로와 사내 시스템을 연결하는 작업에서는 DNS 변경보다 인증서와 네트워크 경로 검증을 먼저 두었다. 모든 작업을 통제하려는 것이 아니라, 사고 비용이 큰 지점만 먼저 드러내려는 선택이었다.

실제로 한 일

이 역할은 이미 몇 가지 형태로 나타났다. 하나의 내부 시스템에서는 설계·구축·운영 장애 대응까지 직접 맡았다. 다른 업무에서는 수기 관리 항목을 전수 분석해 실제 전환 범위를 줄이고, 빠른 1차 오픈과 이후 통합을 나눴다. 비개발자의 도구 제작을 도우면서는 일대일 지원 내용을 재사용 가능한 문서로 바꿨다. 보안과 인프라 영역에서는 배포 자동화, 접근 권한, 외부 진입 경로를 따로 보지 않고 운영 흐름으로 연결해 검토했다.

참고 글에서 말한 AI 에이전트의 병렬 활용은 앞으로 더 적극적으로 써볼 부분이다. 조사, 초안, 반복 구현은 여러 에이전트에 나눌 수 있다. 하지만 어떤 문제를 먼저 풀지, 결과를 받아들일 기준은 무엇인지, 운영 사고가 나면 누가 책임질지는 사람이 정해야 한다. 내가 맡아야 할 일도 에이전트 수를 늘리는 것이 아니라 그 판단과 검증을 놓치지 않는 쪽에 가깝다.

확인된 결과와 남은 일

현재까지 분명해진 역할은 이렇다. 나는 한 팀의 기능만 구현하는 사람보다, 팀 사이에 남은 기술 문제를 실행 가능한 범위로 만들고 필요하면 직접 끝까지 구현하는 쪽에 가깝다. 동시에 한 번 해결한 일을 문서, 자동화, 검증 절차로 바꿔 다른 사람의 실행 속도도 높여야 한다.

다음 목표는 혼자 더 많은 일을 처리하는 것이 아니다. 반복되는 지원을 셀프서비스로 바꾸고, 여러 에이전트가 만든 결과의 상태와 품질을 한눈에 확인할 수 있게 만들며, 위험이 큰 변경에는 배포 전에 검증 기준이 작동하도록 하는 것이다. 다른 엔지니어와 바이브코딩 구성원이 더 넓은 범위를 안전하게 맡을 수 있어야 한다.

그 결과는 아직 완성되지 않았다. 앞으로는 내가 처리한 티켓 수보다 모호했던 결정이 얼마나 빨리 정리됐는지, 반복 문의가 문서와 도구로 얼마나 줄었는지, 배포 전에 잡힌 위험이 무엇인지로 이 역할을 확인해보려 한다. AI가 늘린 실행력이 내 개인 처리량에서 끝나지 않고 조직의 실행력으로 남게 만드는 것. 요즘 내가 맡고 있는 역할과 다음 목표를 한 문장으로 줄이면 그 정도다.