이슈의 절반은 AI가 씁니다 : 그런데 개발에 드는 시간은 늘었습니다

컴퓨터 구조를 공부하면 반드시 한 번은 만나는 이름이 있습니다. 진 암달입니다. IBM에서 System/360의 아키텍처를 총괄했고, 나중에는 자기 이름을 딴 회사를 세워 친정과 정면으로 경쟁한 사람이죠.

그가 남긴 것 중에 가장 오래 살아남은 것은 컴퓨터가 아니라 한 줄의 계산입니다. 프로세서를 두 배로 늘리면 프로그램도 두 배로 빨라지느냐는 질문에 그는 아니라고 답했는데요. 프로그램에는 아무리 쪼개도 순서대로 처리할 수밖에 없는 구간이 남아 있고, 그 구간이 전체의 10퍼센트라면 프로세서를 천 개 붙여도 열 배 이상은 빨라지지 않는다는 것이었습니다. 1967년 학회 발표에서 나온 이야기이고, 지금은 암달의 법칙이라고 부릅니다.

이 계산이 오래 살아남은 이유는 상한이 있다는 사실 자체보다는 그 상한이 잘 안 보인다는 데 있다고 생각합니다. 빠르게 만든 구간은 눈에 잘 띕니다. 손대지 않은 구간이 그대로 남아 있는 것은 눈에 띄지 않죠.

프로젝트 관리 도구를 만드는 리니어(Linear)가 최근 자사 제품 데이터를 정리해 공개했습니다. 2024년 6월부터 2026년 8월까지, 유료 워크스페이스에서 벌어진 일을 모아 놓은 자료인데요. 도입률 분석에는 유료 사용자 12만 7,000명, 풀 리퀘스트 분석에는 유료 워크스페이스 4만 7,900곳이 들어갔습니다. 벤치마크 점수로 도구의 성능을 주장하는 자료가 아니라, 그 도구를 쓰는 팀들이 실제로 무엇을 얼마나 하고 있는지를 자기 서버에 쌓인 기록으로 센 자료입니다.

숫자는 예상대로 화려합니다. 2년 전에는 리니어에 만들어지는 이슈 1,000건 중에 AI가 만든 것이 한 건도 채 되지 않았습니다. 지금은 만들어지는 것의 절반 가까이를 AI가 씁니다. 에이전트와 MCP 클라이언트가 만드는 이슈가 주당 수백만 건 규모로 올라와, 사람과 기존 연동이 만드는 양과 거의 같아졌어요. 코드 변경을 합쳐 달라고 올리는 요청, 즉 풀 리퀘스트는 워크스페이스당 111퍼센트 늘었습니다. 코딩 에이전트를 붙여 놓은 팀은 주당 21건에서 65건으로 세 배가 됐고, 붙이지 않은 팀은 주당 8~10건에서 거의 움직이지 않았습니다.

▸ 절반은 가져간 절반이 아니라 얹힌 절반이었습니다

여기까지가 헤드라인으로 뽑히는 부분입니다. 그런데 같은 리포트에 시간을 다룬 대목이 있습니다.

리니어의 문장을 그대로 옮기면 이렇습니다. "리니어에서 기존 작업에 쓰는 시간은 그대로 유지된 반면 AI 사용은 새로운 층의 작업으로 나타났고, 이는 제품 개발에 쓰는 전체 시간이 줄어드는 것이 아니라 늘어난다는 뜻이다."

절반이라는 숫자를 다시 읽어야 하는 지점이 여기입니다. 사람이 하던 일의 절반을 AI가 가져간 것이라면 사람 쪽 시간이 줄어야 하는데요. 줄지 않았습니다. AI가 쓴 이슈는 사람이 쓰던 이슈를 대신한 것이 아니라, 사람이 쓰던 양 위에 그만큼이 새로 얹힌 것이었습니다. 그러니 절반은 맞습니다. 다만 대체된 절반이 아니라 더해진 절반이죠.

만들어진 이슈가 늘고 풀 리퀘스트가 세 배가 됐다는 것은 실행 능력이 실제로 커졌다는 뜻입니다. 그 자체를 깎아내릴 이유는 없습니다. 다만 그것을 생산성 향상으로 옮겨 적으려면 한 단계가 더 필요합니다. 늘어난 산출물이 만들어야 했던 것이었는지, 그리고 그것을 받아 읽고 판단하고 합치는 쪽의 시간이 그만큼 감당됐는지를 봐야 하죠.

▸ 표에서 유일하게 움직이지 않은 칸

리포트에서 가장 눈에 걸린 문장은 다른 것이었습니다. "이 리포트의 거의 모든 것이 위로 움직인 해에, 고객 요청과 문서, 프로젝트에 쓴 시간은 그대로였다."

거의 모든 칸이 올라간 표에서 한 칸만 제자리였다는 것인데요. 그 한 칸이 무엇을 만들지 정하는 시간입니다. 고객이 무엇을 요구했는지 정리하고, 왜 이렇게 만들기로 했는지를 문서로 남기고, 프로젝트의 범위를 자르는 일. 리니어는 이 관찰을 한 문장으로 요약해 두었습니다. "AI는 지금까지 팀이 무엇을 만들지 결정하는 방식보다 어떻게 실행하는지를 훨씬 많이 바꿨다."

*출처: Wikimedia Commons*

암달이 말한 직렬 구간이 어디였는지가 이렇게 드러납니다. AI가 가속한 것은 병렬화가 잘 되는 구간이었습니다. 이슈를 쓰고 코드를 짜고 변경을 올리는 일은 에이전트를 붙이는 만큼 늘어납니다. 그런데 무엇을 만들지 정하는 일은 그런 성질이 아닙니다. 판단은 한 번에 하나씩 내려야 하고, 판단하는 쪽을 열 배로 늘린다고 결정이 열 배로 빨라지지 않죠. 개발 조직의 병목이 코드 작성 속도였던 적은 사실 별로 없었습니다. 그동안은 코드 작성이 느려서 그 사실이 가려져 있었을 뿐입니다.

물론 이 자료를 과장해서 읽지는 말아야 합니다. 리니어가 센 것은 리니어 안에서 벌어진 일입니다. 유료 워크스페이스만 집계했고, 리니어를 쓰는 조직이 업계 전체를 대표하지도 않습니다. 무엇보다 리니어 밖에서 생긴 절약은 이 표에 잡히지 않아요. 저장소에서, 빌드 파이프라인에서, 배포 과정에서 아껴진 시간이 있다면 그것은 다른 회사의 데이터베이스에 쌓입니다. 리포트가 다루지 않은 것도 분명히 있습니다. AI가 만든 이슈가 실제로 완료되는 비율, 코드 리뷰에 걸린 시간, 늘어난 풀 리퀘스트의 품질은 이 자료로 말할 수 없습니다. 총 시간이 늘어난 것이 도입 초기의 학습 비용일 가능성도 열려 있습니다.

▸ 늘어난 산출량은 대시보드에 찍히고 늘어난 시간은 찍히지 않습니다

그래도 이 방향의 관찰이 리니어 하나뿐이라면 조심스럽겠지만, 그렇지도 않습니다.

AI 평가 기관인 METR이 지난해 7월에 공개한 실험이 있습니다. 숙련된 오픈소스 개발자 16명에게 자기 저장소의 실제 작업 246건을 주고, 각 작업을 AI 사용 허용과 금지로 무작위 배정한 대조 실험이었는데요. 개발자들은 시작 전에 AI가 있으면 24퍼센트쯤 빨라질 것이라고 예상했습니다. 작업을 다 끝낸 뒤에는 20퍼센트 빨라졌다고 자기 평가를 했습니다. 실제 측정값은 19퍼센트 느려진 것이었습니다. 표본 16명에 2025년 초 모델을 쓴 실험이니 지금 상황에 그대로 대입할 수는 없습니다. 다만 방향은 리니어의 시간 항목과 같은 쪽을 가리킵니다. 체감은 위로, 실측은 아래로요.

두 자료를 겹쳐 놓으면 왜 이 간극이 잘 안 보이는지도 짐작이 됩니다. 늘어난 산출량은 세기가 쉽습니다. 주당 풀 리퀘스트가 21건에서 65건이 됐다는 것은 대시보드에 그려지고, 토큰 사용량은 청구서에 찍히고, AI 기능 도입률은 분기 보고에 올라갑니다. 반면 제품 개발에 들어간 총 시간이 늘었다는 사실은 어느 화면에도 자동으로 뜨지 않습니다. 그것을 보려면 산출량이 아닌 것을 세기로 마음먹은 사람이 있어야 하죠. 토큰을 얼마나 썼는지가 성과가 아니라는 얘기를 예전에 다룬 적이 있는데요, 구조가 거의 같습니다. 세기 쉬운 것이 목표가 되고, 목표가 된 것은 올라갑니다.

국내 조직들도 지금 같은 자리에 서 있습니다. AI 도구를 전사에 깔고 성과를 정리해야 하는 시기인데요, 보고서에 들어가는 항목은 대개 도입률과 활성 사용자 수, 생성된 코드량, 처리한 티켓 수입니다. 전부 실행 쪽 숫자입니다. 리니어 데이터가 보여 준 것은 그 실행 쪽 숫자가 이미 두 배로 올랐다는 것이고, 움직이지 않은 것은 무엇을 만들지 정하는 시간이라는 것입니다. 실행이 세 배가 된 조직에서 판단이 그대로라면, 그 조직은 예전보다 더 많은 것을 더 빠르게, 다만 같은 근거로 만들고 있는 셈입니다.

프로세서를 천 개 붙여도 직렬 구간이 10퍼센트면 열 배가 상한이었습니다. AI를 몇 개 더 붙일지는 앞으로도 계속 이야기가 나오겠죠. 그 전에 우리 조직의 직렬 구간이 어디인지, 그리고 지금 재고 있는 지표가 그 구간을 보여 주는 숫자인지에 대한 고민이 필요합니다.