구현이 5분이면 끝나는 시대, 개발자의 나머지 시간은 어디에 쓰일까?
DEV에서 반응을 모은 글은 구현 5분과 합의 4일을 대비하며 코딩과 소프트웨어 엔지니어링을 구분하자고 말합니다. 제목의 주장은 입증된 결론이 아니라 작성자의 견해입니다. 그 구분을 받아들인다면 구현 밖의 시간이 어디로 가는지, 그 시간을 어떻게 드러내고 줄일지 정리합니다.
9월 10일 DEV에 올라온 Sylwia Laskowska의 글 「AI Is Already Better at Coding Than Most Software Developers」가 월간 인기 목록에 올라 있습니다. 9월 14일 기준으로 반응 175개, 댓글 150개입니다.
제목만 보면 "이제 개발자는 필요 없다"는 글 같지만, 본문의 요지는 다릅니다. 작성자가 구분하려는 것은 코드를 만드는 속도와 소프트웨어 엔지니어링의 가치입니다. 이 글에서는 그 구분을 출발점으로 삼아 이번 주 질문에 답해 보려 합니다.
구현이 5분이면 끝나는 시대, 개발자의 나머지 시간은 어디에 쓰일까?
원문이 말하는 것과 말하지 않는 것
작성자가 든 경험은 이렇습니다. 애플리케이션에 변경 하나를 넣어야 했는데, 코딩 에이전트라면 5분이면 구현할 만한 크기였습니다. 그런데 그 변경이 정확히 어떤 모습이어야 하는지 논의하고, 관련된 팀들과 조율하고, 고객과 최종안을 합의하는 데 4일이 걸렸습니다. 그 4일 동안 결정은 여러 번 바뀌었습니다. 작성자는 이 회의에 개발자, 그것도 경험 있는 개발자가 반드시 있어야 했다고 덧붙입니다.
그리고 이렇게 정리합니다. 구현은 5분, 무엇을 구현할지 정하는 데는 4일. 이것이 코딩과 소프트웨어 엔지니어링의 차이라고요.
다만 제목의 주장, 즉 "AI가 이미 대부분의 개발자보다 코딩을 잘한다"는 작성자의 견해입니다. 작성자는 METR와 NBER의 연구를 참고 자료로 달았지만, 그 연구들이 개발자 전체와 AI를 맞붙여 우열을 가린 것은 아닙니다. 특정 과제에서 AI 에이전트가 무엇을 해내는지, AI 도구가 개발자의 작업 속도를 어떻게 바꾸는지를 본 연구들입니다. 작성자 스스로도 예전 연구에서는 숙련 개발자가 AI를 쓸 때 오히려 느렸고, 최근 결과도 코딩 벤치마크만큼 극적이지는 않다고 적었습니다. 이 연구는 앞선 글에서 자세히 다뤘습니다.
그래서 저는 이 글을 "AI가 개발자를 이겼다"는 선언이 아니라, 원문의 문장대로 "코드 생성에서 멀어질수록 기계의 이점은 덜 극적이 된다"는 관찰로 읽는 편이 정확하다고 봅니다. 작성자 역시 "적어도 지금은(At least for now)"이라는 단서를 달았습니다.
4일은 어디에 쓰였을까
원문은 4일의 내역을 자세히 적지 않았습니다. 하지만 비슷한 일을 겪어 본 개발자라면 대략 짐작할 수 있습니다. 변경 하나가 합의되기까지는 보통 다음 질문들에 답해야 합니다.
- 무엇이 바뀌어야 하나? 요청자가 말한 것과 실제로 필요한 것이 같은지 확인합니다.
- 어디까지 영향이 가나? 이 필드를 바꾸면 어떤 API, 어떤 배치, 어떤 리포트가 함께 흔들리는지 따집니다.
- 누가 동의해야 하나? 데이터를 소비하는 팀, 운영팀, 고객 중 누구의 확인이 필요한지 정합니다.
- 실패하면 어떻게 되나? 중간에 실패하거나, 되돌려야 하거나, 옛 데이터와 섞일 때의 동작을 정합니다.
이 질문들은 코드를 빨리 쓴다고 짧아지지 않습니다. 오히려 경험 있는 개발자가 회의에 있어야 하는 이유가 여기 있습니다. 어떤 요구가 구현하기 싸고 어떤 요구가 비싼지, 어디서 사고가 나는지 아는 사람이 있어야 논의가 현실적인 선에서 수렴합니다.
한 가지 더 짚고 싶은 점이 있습니다. 작성자의 사례에서 결정이 여러 번 바뀌었다는 대목입니다. 이건 제 추측이지만, 구현이 싸지면 결정을 뒤집는 비용도 싸 보이기 쉽습니다. "어차피 금방 다시 만들 수 있으니"라는 생각이 들면 합의를 서둘러 마무리하려는 압력이 약해집니다. 구현 비용이 줄어든 만큼 합의가 흔들리는 시간이 늘어난다면, 전체 리드 타임은 기대만큼 줄지 않을 수 있습니다.
나머지 시간이 쓰이는 다섯 곳
구현이 짧아졌을 때 개발자의 시간이 어디로 옮겨 가는지, 제가 보기에 중요한 곳을 다섯 가지로 정리해 봤습니다.
| 영역 | AI가 줄여 주는 부분 | 여전히 사람이 책임지는 부분 |
|---|---|---|
| 문제 정의 | 요구사항 초안, 질문 목록 만들기 | 무엇을 하지 않을지 정하고, 실패 조건까지 합의하기 |
| 영향 범위와 합의 | 호출 관계 검색, 변경 파일 목록 추리기 | 팀 간 계약을 바꿀지 결정하고, 결정권자를 찾아 동의받기 |
| 검증 | 테스트 초안, 반복 점검 자동화 | 무엇을 검증해야 안전한지 정하고, 결과를 설명하기 |
| 운영과 되돌리기 | 로그 요약, 배포 스크립트 작성 | 배포 순서와 롤백 기준 정하기, 조용한 실패 알아차리기 |
| 결정 기록 | 회의록 정리, 문서 초안 | 왜 이렇게 했는지 6개월 뒤에도 설명할 수 있게 남기기 |
1. 문제 정의: 실패 조건까지 좁히기
"주문에 부분 환불 기능을 추가해 주세요"라는 요청은 한 줄입니다. 하지만 쿠폰이 적용된 주문은 어떻게 나누는지, 정산이 마감된 뒤의 환불은 어느 달에 잡는지, 환불 중 결제사 응답이 끊기면 어떻게 하는지는 요청에 없습니다.
AI에 이 요청을 그대로 주면 그럴듯한 코드가 나옵니다. 문제는 그 코드가 위 질문들에 대해 조용히 한쪽을 골라 버린다는 점입니다. 누가 그 선택을 했는지 아무도 모르는 상태가 됩니다. 구현이 싸진 시대에 개발자의 시간이 가장 먼저 옮겨 가야 할 곳이 여기라고 생각합니다.
2. 영향 범위와 합의: 코드 밖의 계약
한 서비스 안에서 끝나는 변경이라면 AI가 영향 범위를 꽤 잘 찾아 줍니다. 하지만 이벤트 스키마를 다른 팀이 구독하고 있거나, 고객사가 특정 응답 형식에 맞춰 연동해 두었다면 이야기가 달라집니다. 이런 계약은 저장소 안에 다 적혀 있지 않습니다. 누가 쓰고 있는지, 바꾸면 누구에게 먼저 알려야 하는지는 조직을 아는 사람이 챙겨야 합니다.
원문의 4일 가운데 상당 부분도 아마 이 조율에 들어갔을 것입니다.
3. 검증: 생성보다 비싸진 일
생성이 싸지면 검증이 상대적으로 비싸집니다. 작성자도 에이전트가 만든 드롭다운이 한번 열리면 닫히지 않았다는 일화를 웃으며 적었습니다. 이런 결함은 금방 눈에 띄니 차라리 다행입니다. 정상 경로에서는 멀쩡하고 재시도나 동시 요청에서만 틀리는 코드가 더 위험합니다.
AI가 만든 PR이 쌓일 때 리뷰를 어떻게 나눌지는 리뷰 병목 글에서 따로 다뤘습니다. 요지는 모든 줄을 읽는 대신 어디를 깊게 볼지 미리 정하는 일에 사람의 시간을 쓰자는 것입니다.
4. 운영과 되돌리기: 한 줄 수정 뒤의 며칠
최근에 쓴 @Transactional 롤백 장애 글이 좋은 예입니다. 최종 수정은 YAML 한 줄이었습니다. 그 한 줄을 AI가 5분 만에 써 줄 수도 있었을 겁니다. 하지만 그 한 줄이 맞다고 말할 수 있게 된 건 진단 API를 만들고, 개발 WAS에서 재현하고, 옵션을 바꿔 가며 측정한 며칠 덕분이었습니다. 수정 뒤에 새로 돌기 시작할 트랜잭션 전파 설정과 락 경합을 점검하고, 즉시 되돌릴 방법을 준비한 것도 같은 시간에 포함됩니다.
코드를 쓰는 시간은 줄어도, 이 변경이 운영에서 무엇을 바꾸는지 확인하는 시간은 그대로 남습니다.
5. 결정 기록: 나중에 설명할 사람
구현을 AI가 하고 리뷰도 AI가 거들면, "왜 이렇게 만들었나요?"라는 질문에 답할 사람이 흐려집니다. 6개월 뒤 장애가 났을 때 필요한 것은 코드가 아니라 당시의 판단입니다. 어떤 대안을 버렸는지, 어떤 실패는 감수하기로 했는지를 남겨 두는 일은 여전히 결정에 참여한 사람의 몫입니다.
그렇다고 모든 구현이 5분은 아닙니다
원문의 사례를 일반화할 때는 조심해야 합니다. "5분"은 무엇을 만들지 정해진 뒤, 잘 알려진 패턴 안에서 끝나는 변경에 가까운 이야기입니다. 문서화가 안 된 레거시, 도메인 규칙이 코드 곳곳에 흩어진 시스템, 성능이나 동시성이 핵심인 작업에서는 구현 자체도 여전히 오래 걸립니다.
또 구현이 짧아졌다고 해서 구현 역량이 필요 없어지는 것도 아닙니다. AI가 만든 코드가 이상하다는 걸 알아보려면, 적어도 그 코드를 직접 짤 수 있었을 만큼은 알아야 합니다. 주니어가 그 감각을 어디서 얻을지는 개발자 수요 글에서 다룬 고민과 이어집니다.
그래서 팀은 무엇을 해 볼 수 있을까
"개발자의 가치는 판단에 있다"는 말은 맞지만, 이대로는 막연합니다. 당장 해 볼 수 있는 일을 적어 둡니다.
- 리드 타임을 쪼개서 보세요. 착수 전 합의, 구현, 리뷰 대기, 배포 후 확인에 각각 얼마나 걸렸는지 몇 건만 기록해 봐도 병목이 구현이 아니라는 게 드러나는 경우가 많습니다. 원문의 5분과 4일도 이렇게 나눴기 때문에 보인 숫자입니다.
- 이슈에 실패 조건 칸을 만드세요. "무엇을 만든다" 옆에 "이런 경우에는 이렇게 동작해야 한다", "이번에는 하지 않는다"를 적게 하면, AI에 넘기기 전에 사람이 정해야 할 것이 먼저 드러납니다.
- 결정이 바뀐 이유를 남기세요. 결정이 여러 번 바뀌는 것 자체는 나쁘지 않습니다. 다만 무엇 때문에 바뀌었는지 남기지 않으면 같은 논의를 다음 달에 되풀이하게 됩니다.
- 회의에 개발자를 부르는 기준을 정하세요. 모든 회의에 개발자가 들어갈 필요는 없습니다. 하지만 외부 계약, 데이터 정합성, 되돌리기 어려운 변경이 걸린 논의라면 처음부터 들어가는 편이 4일을 줄이는 길입니다.
정리
구현이 5분으로 줄어도 개발자의 하루가 5분짜리가 되지는 않습니다. 남은 시간은 무엇을 만들지 좁히고, 누구와 무엇을 합의할지 정하고, 그 변경이 안전하다고 말할 근거를 만들고, 나중에 설명할 수 있게 남기는 데 쓰입니다.
원문의 마지막 문장이 이 변화를 잘 요약합니다. AI가 코딩을 잘하게 된다고 해서 소프트웨어 엔지니어의 가치가 떨어지는 것은 아니고, 엔지니어링 역량 가운데 코딩이 차지하던 비중이 줄어드는 것이라고요. 저는 여기에 하나를 더하고 싶습니다. 그 줄어든 비중만큼의 시간이 어디로 가는지, 팀이 직접 재 보기 전까지는 아무도 모른다는 점입니다.