코드를 대신 써 주면 퇴근도 빨라질까. 여러 에이전트에게 일을 나눠 맡긴 개발자 오레스티스 이오아누(Orestis Ioannou)는 정반대의 변화를 겪었다. 하나의 작업이 어려워진 게 아니라, 동시에 벌이는 일이 너무 많아졌다. 10월 27일 공개한 글에서 그는 자신의 GitHub 활동 기록을 꺼내 그 변화를 짚었다.
에이전트는 지시를 받아 코드를 고치거나 문제를 조사하는 도구다. 사람이 계속 지켜보지 않아도 진행하므로 여러 작업을 함께 돌릴 수 있다. 이오아누는 이제 모든 엔지니어링 업무에 에이전트를 쓴다. 예전 같으면 시작할 엄두를 내지 못했을 버그 수정과 실험까지 가능해졌지만, 결과를 이해하고 승인하는 일은 여전히 자신의 몫이다.
기다리는 시간은 줄고, 다시 파악할 문제는 늘었다
풀스택 엔지니어로 일하던 때에는 한 주에 중요한 과제 두세 개를 다뤘다. 기능 하나나 까다로운 버그, 데이터 이전 같은 일이었다. 하나를 머릿속에 붙들고 끝낸 뒤 다음으로 넘어가는 방식이었다.
지금은 한 에이전트가 변경 사항을 구현하는 동안 다른 에이전트가 운영 문제를 조사하고, 또 다른 에이전트가 코드 검토나 자료 조사를 진행한다. 모두가 늘 사람을 필요로 하지는 않는다. 대신 각자 다른 순간에 질문과 승인 요청, 변경 내역, 조사 결과를 들고 돌아온다. 그때마다 어느 저장소의 무슨 문제였는지부터 다시 떠올려야 한다.
이 부담은 단순히 읽을 코드가 많다는 말과 다르다. 방금 보던 버그의 원인을 내려놓고 다른 프로젝트의 설계 조건을 불러오는 전환이 반복된다. 이오아누가 더 피곤하다고 느끼는 지점도 여기다. 구현을 기다리는 시간을 줄인 자리에 서로 다른 문제를 다시 이해하는 일이 들어왔다.
관리자가 된 뒤, 활동량은 개발에 전념하던 시절로 돌아갔다
그는 장학금 플랫폼 Bold.org에 2020년 입사했다. 풀스택 엔지니어를 거쳐 2022년 8월부터 프린시펄 엔지니어로, 2025년 8월부터 기술 부문 부사장으로 일했다. 설계와 기획, 조직을 이끄는 일이 늘면서 직접 기능을 개발하는 비중은 줄었다.
GitHub 기록도 한동안 그 흐름을 따랐다. 풀스택 시절 월평균 활동은 173건, 프린시펄 시절은 114건이었다. 부사장이 된 2025년 8~12월 평균도 111건에 머물렀다. 그런데 2026년에는 10월 27일까지 2,102건을 기록했다. 2021~2025년의 어느 한 해 전체보다 많고, 가장 바빴던 2020년 같은 기간의 2,371건에 가까워졌다.
이 수치는 커밋에 더해 코드 변경 요청, 리뷰, 이슈 등을 합친 활동 기록이다. 일한 시간이나 제품에 더한 가치를 그대로 뜻하지는 않는다. 그럼에도 기능 개발 비중이 낮아진 사람이 다시 예전 수준의 활동을 보인다는 점이 이 글의 출발점이다.
활동이 늘어난 이유로 그는 시작할 만하다고 느끼는 일의 범위가 넓어진 것을 든다. 구현 비용이 낮아지자 예전에는 남겨 뒀을 버그를 고치고, 코드 전반의 패턴을 정리하고, 새 프로젝트까지 시작했다. 기존 업무를 빨리 끝낸 만큼 쉬는 대신 스스로 맡는 업무량을 키운 셈이다.
활동이 몰리는 시기 뒤에는 검토와 피로가 따라왔다
2026년 기록은 꾸준한 우상향이 아니다. 에이전트를 본격적으로 쓰기 시작한 1월과 2월에는 각각 277건, 233건이었다. 6월에는 77건까지 줄었다가 여름휴가 뒤 8월에 427건으로 뛰었다. 종전 월간 최고였던 2020년 4월의 319건을 넘어선 수치다. 9월도 301건으로 높았다.
이오아누는 새 모델이나 작업 방식이 등장할 때마다 떠오른 아이디어를 한꺼번에 시도했다고 설명한다. 몇 주 동안 에이전트와 대화 창을 늘리다가 검토와 맥락 전환을 감당하기 어려워지면 추가 실험을 줄였다. 올해 이런 주기를 세 번 겪었다고 한다. 피로가 쌓인 뒤에도 평소 업무는 계속했지만, 더 많은 가능성을 좇을 여력은 사라졌다.
활동이 많이 몰린 날도 늘었다. 하루 활동이 24건 이상인 날은 2022~2025년에는 매년 하루씩이었는데, 2026년에는 10월 27일까지 16일이었다. 2020년 전체의 17일에 가깝다. 이는 활동 빈도의 변화이며, 해당 날짜의 노동시간을 센 것은 아니다.
동시에 시작할 일도, 검토할 수 있는 만큼 정해야 한다
이 사례를 모든 개발자의 생산성 변화로 일반화할 수는 없다. 한 사람의 직무와 도구 사용이 함께 바뀐 기록이다. 이오아누도 에이전트 사용을 포기해야 한다고 주장하지 않는다. 더 많은 문제를 고칠 수 있게 된 점을 좋아하면서도, 구현 능력이 아이디어를 생각하고 판단할 능력보다 훨씬 빨리 커졌다고 말한다. 아직 균형을 찾지는 못했다.
팀 운영에 적용할 때는 실행 중인 에이전트 수와 별도로 검토를 기다리는 결과를 봐야 한다. 예컨대 운영 장애 조사를 확인하던 중 새 기능의 변경 내역이 도착했다면, 즉시 다른 작업을 더 맡기기 전에 그 결과를 누가 언제 읽을지 정하는 식이다. 완료 보고에 변경 이유와 실행한 검사, 사람이 결정할 사항을 함께 담도록 하면 다시 파악할 범위를 줄일 수 있다. 이는 원문의 측정 결과가 아니라, 검토가 한 사람에게 모이는 구조에 대한 운영상의 대응이다.
얼마나 많이 실행했는지만으로는 업무가 줄었는지 알기 어렵다. 검토 대기가 늘고 추가 작업을 피하고 싶어졌다면, 다음 실험을 더 쉽게 시작하는 기능보다 이미 돌아온 결과를 끝낼 시간이 필요한 상황일 수 있다.
출처: Orestis Ioannou, AI Promised Less Work. I Have Never Worked More.