나는 AI에 의존하는 사람인가, AI를 활용하는 사람인가
그간 브런치에는 내 커리어 중 어느 정점의 순간에 대한 회고만 올렸던 것 같다.
오늘은 AI로 인해 생각과 고민이 많아진 개발자로서 단상을 남겨보려고 한다.
올해 들어 숙박 커머스 상품의 개발을 맡게 되고, 처음 대규모 프로모션을 대응해야 할 일이 생겼다.
매년 특정 계절마다 진행해 오던 이벤트였다고 들었고, 이런 식의 이벤트를 준비하는 CMS(content management system)도 사내에 구축되어 있기에 담당자로서 의례 준비했던 것들만 차분히 준비하면 되겠다고 생각하면서 킥오프 회의에 들어갔다. 그런데 올해는 운영 방침이 변경되면서 기존의 프로모션 운영 방식을 따르기는 것이 쉽지 않아 보였다.
사업적으로 좋은 기회이고, 사업 담당자들도 성공적으로 판매하고자 하는 열의가 가득했다. 나 또한 오랜만에 목적 조직에 속해 있다 보니 비즈니스적으로 성과를 남길 수 있기를 기대했다. 이런저런 논의 끝에 오픈까지 기간이 촉박하긴 하지만 이번 이벤트 기간에는 커스텀 웹페이지를 제공해서 고객들에게 직관적으로 더 많은 혜택을 인지하게 하고, 다양한 상품 구매 기회를 제공해 보자는 결론에 이르렀다.
현재 나는 이 도메인 목적 조직에서 1인 프론트엔드 개발자이다. 예전에 나였다면, 혹은 프론트엔드 팀원의 입장이었다면 지속 가능성이 보장되지 않는 이벤트 페이지 개발에 시간을 할애하면서 지금 진행 중인 장기 프로젝트를 지연시켜야 하는 결정에 대해서 일정, 인적 리소스, 코드의 지속성 등의 이유를 가지고 어떻게든 기존 프로모션 CMS로 프로모션을 진행하게끔 설득했을 것이다.
그러나 이제는 AI로 프로젝트 여러 작업을 병행하는 것이 충분히 가능해졌고, 초기 설계만 잘해준다면 크게 문제없이 현재 진행 중인 프로젝트와 병행하여 풀어낼 수 있는 문제로 보였다.
때마침 소스 코드에 프론트 개발에 대한 규칙(rule) 기반 개발 컨벤션과 가이드 등을 문서 구조로 추가하고 테스트 코드와 스펙 문서 기반 개발 방법론 초안을 반영한 직후였다.
시기적으로 내가 짜둔 '하네스(harness: 에이전트가 안전하게 실행될 수 있도록 입출력을 제어하고, 그 과정을 실시간으로 추적하는 운용 프레임워크)'가 안전장치 역할을 해서 AI 코딩 에이전트가 의도된 절차에 맞춰 최종 산출물을 만들어내는지 가볍게 확인할 수 있는 기회이기도 했다.
그렇게 실시간성 쿠폰 현황과 상품 전시에 대한 화면 설계와 개발을 위한 스펙 문서 구성에 1일, AI 코딩 에이전트를 이용한 코드 작성과 리뷰/테스트에 1.5일이 걸려서 커스텀 이벤트 페이지가 세상에 나오게 되었다.
AI 코딩 에이전트가 없었던 시절이라면 워킹데이로 5일 정도 걸렸을 법한 화면 구조였는데 꽤 빠른 기간 안에 개발을 마칠 수 있었다.
여기까지 보면 단순히 이벤트 페이지 AI로 딸깍 개발한 이야기이겠지만, 덕분에 절약한 나머지 2.5일 동안 추가로 할 수 있었던 시도들 덕분에 의미 있고 또 재미있는 시간을 보낼 수 있었다.
내가 재직 중인 회사에서는 대고객 페이지를 모노레포(monorepo: 다수 프로젝트의 단일 저장소 관리 방식) 구조로 개발하고 있는데 기존 프로모션 페이지를 담당하는 앱과 이번에 개발을 진행한 앱(숙박 버티컬 전용)이 내부적으로 나뉘어 있다.
그동안 대규모 프로모션에서는 프로모션 버티컬 앱에 대한 웹서버 증설과 모니터링만 이뤄졌던 터라 이번에 내가 개발한 페이지가 숙박 버티컬 전용 웹서버에서 대규모 트래픽을 잘 받아낼 수 있을지 의문이었다. 그렇게 k6, datadog의 synthetic test 도구를 이용해서 부하테스트를 진행해 볼 수 있는 시간과 여유가 생겼다.
예전 같으면 병행 중인 프로젝트 때문에 할당할 수 없는 리소스였고 시간이었다.
실제로 부하 테스트 중간에 앱 내 병목이 발생함을 발견했다. 문제 해결을 위해서 사내 인프라 트래픽 분석이 가능한 AI 코딩 에이전트 도움을 받아 인프라 담당자분과 문제 상황을 분석해 보면서 내부 코드를 수정하고 튜닝하는 시간이 주어졌다.
또, 프로모션 오픈 초반에 백엔드 쪽 데이터의 캐싱 이슈가 발생했는데 백엔드 이슈 해결을 위한 디버깅이 진행되는 동안 대안으로 프론트엔드에서 이 문제를 우회하게끔 코드를 구현해야 하는 일이 발생했다.
커스텀 이벤트 페이지다 보니 복잡한 코드 규모는 아니었지만 설계와 개발 스펙 문서 리뷰에 시간을 많이 쏟았기에 어디를 고쳐야 할지 바로 파악하고 수정한 상태로 배포 대기를 할 수 있었다.
예전처럼 내가 한 땀 한 땀 작성한 코드는 아니었지만, 무엇을 어떻게 구현했고 이 코드의 영향 범위가 어디까지인지 알고 있었기에 예상치 못한 이슈 대응도 빠르게 할 수 있었다. 만약 내가 그저 AI로 피그마 화면만 비슷하게 구현해서 딸깍 개발(*AI나 자동화 도구를 활용해 클릭 몇 번으로 개발하는 방식)을 했다면 같은 상황이 발생했을 때 담당자로서 얼마나 당황했을 것인가.
일련의 사건이었지만 요즘 들어 AI로 개발하는 것에 대한 고민을 많이 하는 시점이었는데 약간의 각성(?)을 일으키는 순간이었다.
프로모션 오픈을 잘 마친 며칠 뒤 Vercel에서 발행한 Agent Responsibly라는 글을 읽게 되었다.
글에서 AI를 활용하는 것(leveraging by AI)과 AI에 의존하는 것(relying on AI)을 비교한 부분이 있었는데, 여기서 나는 또 한 번 비슷한 깨달음을 얻었다.
“Putting your name on a pull request means "I have read this and I understand what it does." If you have to re-read your own PR to explain how it might impact production, the engineering process has failed.
The litmus test is simple: would you be comfortable owning a production incident tied to this pull request?”
글에서는 AI 에이전트를 사용해 작성된 코드더라도 내 이름으로 된 Pull Request(*코드 변경 사항에 대한 검토 및 통합 요청)를 대할 때 그 내용을 잘 이해하고, 운영 환경에서 사고 발생 시 해결해 나가는데 문제가 없어야 함을 강조한다.
이 질문에 '아니요, 이 코드로 인해 운영 환경에서 에러가 발생했는데 어떻게 해야 할지 모르겠습니다'라고 답한 누군가가 있다면 그 사람은 AI에 의존(relying)하는 개발을 하고 있다는 것이다.
돌이켜 보니 올해 AI 코딩 에이전트를 적극적으로 사용해서 진행했던 프로젝트 모두 이 질문에 '예'라고 답할 수 있었다. 순간 다행이라는 생각이 들었다.
요즘은 누구에게나 AI라는 도구가 주어지면서 많은 사람들이 그간 생각도 못했던 것들을 다양하게 시도하고, 그 결과를 세상에 열심히 뽐내고 보여주는 시대인 것 같다.
정작 나는 개발자라는 타이틀을 달고 있으면서도 그 사이 스스로 뒤처진 것 같은 고립감을 많이 느끼고 있었다. 사내 AI 에이전트 토큰 사용량 차트가 공개될 때에도, 매일 링크드인 피드를 덮고 있는 AI 최신 소식과 프로젝트 이야기를 읽을 때도, 나는 항상 비슷한 감정에 휩싸였던 것 같다.
'나도 저렇게 AI로 프로젝트를 만들고 업적을 자랑하는 사람이 되어야 생존할 수 있을까?'
'프론트엔드를 구현하는 나는 그저 서서히 저무는 역할일 수밖에 없을까?'
이런 감정들 말이다.
이 혼돈의 시대에 유명한 Vercel과 같은 그룹 안에서도 엔지니어들이 이런 고민과 대화를 나누며 기준을 세워 간다는 사실을 알게 되어 그간의 고립감이 조금 해소된 느낌이 들었다.
그리고 글에서 audit이라는 단어가 꽤 많이 언급되었는데, 앞으로 어떻게 될지 모르지만 지금의 나는 사람이든 AI든 하고자 하는 바를 잘 수행하도록 설계하고 울타리를 치고 보강하는 감독(audit)의 역할에 조금 더 집중해보자는 다짐을 해본다.
https://vercel.com/blog/agent-responsibly
poster image generated by Gemini