진짜로 코딩의 판도는 바뀌었다. 개발자는 어떻게 해야 할까?

'진짜 한번 해볼까? 한번 코드를 내가 직접 작성하지 않고 어디까지 가능할지를 확인해봐야겠다! 한계를 정확히 알아줘야지'

두달전 재미로 시작하게 된 사이드 프로젝트에서 시작한 에이전트 기반 코딩은 단순하게 "채팅만으로 어디까지 코딩할 수 있을까?"로 시작해서 지금은 에이전트 기반 코딩의 시대가 도래했다는 것을 체감했고 개발의 방식이 완전히 바뀌었습니다.

이제는 AI에게 일을 시켰을때 검증을 걱정하지 않을 정도로 하는 수준이 오면서 개발하는 방식이 완전히 바뀌었다. 어셈블러에서 C++로 오듯 코드에서 자연어 수준으로 넘어가는 것을 느낍니다. 코드를 직접 수정하지 않고서도 대부분의 개발이 가능한 수준, 아니 그 이상이 되었습니다.

에이전트가 GitHub 이슈를 스스로 해결하는 벤치마크(SWE-bench)에서 2023년 초기 성공률은 2%였습니다. 2%짜리 주사위를 반반 확률로 한 번이라도 성공하려면 35번을 던져야 해요. 바이브 코딩이 개발자의 빈축을 산 이유죠.

지금은 어떨까요? 같은 벤치마크의 검증된 문제셋(SWE-bench Verified) 기준으로 79%입니다. 한 번 던지면 79%. 못해도 네 번이면 99%. 거의 성공하고 틀리면 "안되는데? 다시 해봐." 한번 더 시키면 그만인 수준이 되었습니다.

그렇다면 앞으로 개발자는 뭘 해야 할까요?

하지만 모든 문제가 79%일 수 없습니다. 실제 현업 수준의 복잡한 문제를 모은 별도의 벤치마크(SWE-bench Pro)에서는 최고 모델도 23%라고 합니다. 3번 정도 돌리면 반반의 확률로 성공하는 수준이군요. 그것도 매번 접근 방식을 바꿔가며 돌렸을 때 이야기입니다. 같은 방식으로 반복하면 오히려 더 깊은 수렁에 빠지면서 같은 실패를 반복할 가능성이 높아요. 이따금 우리가 에이전트를 돌리다 겪는 모습입니다. 그래서 가끔 개발자가 방향을 잡아줘야 하죠. 그러면 개발자는 이렇게 조금씩 방향만 잡아주면 되는 사람일까요?

"어? 이게 왜 되지?"

개발자에게 가장 무서운건 버그가 분명 있었고 나는 분명 그 버그를 수정한 적이 없었는데 그냥 되는 경우입니다. 개발자에게는 차라리 깨끗한 실패와 에러가 낫습니다. 코드 수정의 실패는 단순한 실패가 아니기 때문입니다. 분석이나 보고서는 실패하면 버리면 끝이에요. 원본이 그대로니까.

하지만 코드 수정은? 파일 여러 개를 건드려놓고 일부는 맞고 일부는 틀리고 테스트는 통과하는데 사이드이펙트가 숨어있을 수도 있고 리뷰가 "됐다/안됐다"가 아니라 코드 리뷰가 됩니다. 그것도 내가 짠 코드가 아니라 남이 짠 코드의 리뷰.

대규모의 유지보수에 많은 인력이 들어가는 이유는 한번 잘못된 설계로 진행하면 그 누적된 문제를 복구하고 고치는 비용이 너무 비싸기 때문이죠. AI도 마찬가지예요. 특히나 잘못된 구조를 정석이라고 믿고 고치다보면 노이즈가 컨텍스트를 방해합니다. AI의 시행착오는 비용입니다.

"개발자, AI의 시행착오의 비용을 줄여주는 사람"

그러면 이 시대에 개발자의 역할은 뭘까요? 세 가지를 한번 생각해봤습니다.

1 문제를 쪼개는 사람 — 23%짜리 어려운 문제를 79%짜리 여러 개로 분해하는 것. 에이전트가 한 번에 성공할 수 있는 단위로 만들어주는 겁니다.

2 실패를 빠르게 판별하는 사람 — 에이전트의 결과물이 쓸 만한지, 버려야 하는지, 부분 성공의 함정에 빠진 건 아닌지. 이 판단을 빠르게 내릴수록 시행착오의 비용이 줄어듭니다.

3 성공률 자체를 높이는 환경을 설계하는 사람 — 좋은 테스트, 명확한 인터페이스, 잘 분리된 모듈. 코드베이스의 아키텍처가 곧 에이전트의 성공률을 결정하는 변수가 됩니다.

사실 이건 좋은 시니어가 주니어를 키울 때 하는 일과 많이 겹칩니다. 하지만 결정적 차이가 하나 있어요.

"에이전트는 욕망이 없고, 성장하지 않습니다."

주니어는 냅둬도 알아서 성장합니다. 잘하고 싶다는 욕망이 있으니까요. 물론 좋은 시니어가 옆에 있으면 더 빠르지만, 본인의 의지로 알아서 커갑니다. 에이전트는? 절대적으로 가만히 있어요. 프롬프트를 다듬고 규칙을 정리하면 성공률은 올라가지만, 그건 에이전트가 성장한 게 아니라 환경을 설계한 사람의 역량이 올라간 겁니다.

그래서 역설적으로, 에이전트 시대에 사람의 가치가 더 선명해집니다. 문제를 쪼개려면 제품이 어디로 가야 하는지 알아야 하고, 실패를 판별하려면 좋은 코드에 대한 감각이 있어야 하고, 환경을 설계하려면 미래에 어떤 변경이 올지 예측해야 합니다. 이건 전부 경험과 의지에서 나오는 것들이고, 자동화가 안 되는 영역입니다.

저는 지금 제 클론을 만들고 있습니다. 에이전트는 똑똑한데 일은 못하는 사원이에요. 지식은 있는데 일하는 감각이 없는 거죠. 문제를 어떻게 쪼개는지, 실패를 어떻게 판단하는지, 어떤 구조가 좋은 구조인지 — 제가 일하는 방식을 하나하나 알려주고 있는데, 이게 신입사원 키우는 재미와 똑같습니다.

에이전트가 아직 23%인 지금이 오히려 가르치는 법을 익히기 좋은 때라고 생각합니다. 79%가 되면 다들 그냥 갖다 쓰겠지만, 지금 가르치는 법을 익혀둔 사람은 그때 훨씬 더 잘 쓸 수 있을 테니까요.

저도 이제 막 눈을 뜬 직후라 아직은 대단하게 정리되지는 못했지만 조만간 정리된 아티클을 만들어서 공유하려고 합니다. 우선 제가 발견한거 하나를 공유드립니다.

"스킬을 등록하는 스킬을 등록해"
"... 를 스킬로 등록해"

콜롬부스의 달걀. 아는 사람에게는 너무 당연한 데, 이걸 처음 입력하는 순간이 진짜 시작이 됩니다. 이 첫 단추가 여러분들이 에이전트를 쓰는 관점을 바꾸는데 도움이 되기를 바랍니다.