AI 시대에 시니어 개발자가 오히려 귀해지는 이유와 40·50대의 준비법

얼마 전 후배가 이런 질문을 했습니다. "이제 코드는 AI가 다 짜는데, 우리 같은 사람은 앞으로 뭘 하고 살아야 하나요." 저는 그 자리에서 명확한 답을 못 했습니다. 대신 되물었습니다. "그럼 AI가 짠 코드가 맞는지는 누가 판단하나요."

이 질문이 지금 40대와 50대 개발자가 놓인 자리를 잘 보여준다고 생각합니다. 구현 속도는 더 이상 경쟁력이 아닙니다. 타이핑이 빠른 것도, 문법을 많이 외운 것도 값이 떨어졌습니다. 대신 다른 쪽 값이 올라가고 있습니다.

다만 이 이야기를 "그러니 시니어는 안전하다"로 끝내면 위험합니다. 안전해지는 시니어와 오히려 위태로워지는 시니어가 갈리고 있고, 그 기준이 나이가 아니기 때문입니다. 이 글에서는 값이 오르는 이유, 실제로 위험한 지점, 그리고 지금 할 수 있는 준비를 순서대로 적어보겠습니다.

왜 정의하고 검증하는 역량의 값이 오르는가

AI 에이전트가 코드를 대량으로 만들어내는 상황에서 병목이 어디로 옮겨가는지 보면 답이 나옵니다.

• 입력이 흐릿하면 산출도 흐릿합니다: 요구사항이 정리되지 않은 상태에서 만들어진 코드는 빠르게 나온 만큼 빠르게 버려집니다. 무엇을 만들지 정확히 쓰는 일 자체가 작업의 절반이 됐습니다.
• 양이 늘면 검토가 병목이 됩니다: 하루에 읽어야 하는 코드의 양이 늘었습니다. 이 변경이 기존 동작을 깨뜨리는지, 성능에 어떤 영향을 주는지 판단하는 일은 여전히 사람 몫입니다.
• 틀린 답이 그럴듯하게 나옵니다: 문법적으로 완벽하고 논리적으로 어긋난 코드가 나오는 경우가 있습니다. 이걸 알아채려면 그 도메인에서 무엇이 정상인지 알고 있어야 합니다.
• 책임은 분리되지 않습니다: 장애가 났을 때 "AI가 짰다"는 설명은 통하지 않습니다. 결과에 책임지는 자리는 그대로 남아 있습니다.

정리하면 문제를 정의하고, 결과를 검증하고, 책임지는 역할의 값이 올라갑니다. 이건 경력이 길다고 자동으로 생기는 능력은 아니지만, 오래 일하며 여러 실패를 본 사람이 유리한 영역인 것도 사실입니다. "이렇게 하면 나중에 이런 식으로 터진다"는 감각은 대부분 실제로 터뜨려본 경험에서 나오기 때문입니다.

다만 이 유리함은 저절로 유지되지 않습니다. 예전에 겪은 장애의 형태와 지금 시스템에서 나는 장애의 형태가 다르면, 경험이 오히려 잘못된 확신으로 작동하기도 합니다. 그래서 저는 "예전에 이랬으니 이번에도 그럴 것"이라는 생각이 들면 일단 확인부터 하려고 합니다.

그러나 위험한 자리도 분명히 있습니다

낙관만 하기 어려운 이유는 다음과 같은 경우입니다. 저 자신도 여기서 자유롭지 않아서 종종 점검합니다.

• 단순 구현 위주로 쌓인 경력: 설계와 판단은 다른 사람이 하고 받아서 구현만 오래 한 경우입니다. 경력 연차는 길지만 대체하기 쉬운 위치에 있습니다.
• 도메인 없이 프레임워크만 아는 경우: 특정 기술에 익숙한 것은 강점이지만, 그 기술이 저물면 함께 저뭅니다. 반면 물류, 금융, 의료, 제조처럼 도메인 지식이 붙어 있으면 기술이 바뀌어도 자산이 남습니다.
• 새 도구를 관망만 하는 경우: "예전에도 이런 유행은 있었다"는 태도로 몇 년을 보내면, 다시 들어오는 비용이 매년 커집니다.
• 검증 습관 없이 그대로 받아들이는 경우: AI가 준 코드를 읽지 않고 붙여 넣는 습관은 연차와 무관하게 위험합니다. 오히려 연차가 높을수록 그 코드가 시스템 깊은 곳에 들어가서 피해가 큽니다.

지금 준비할 다섯 가지

준비 항목구체적으로 무엇을 하는가

도메인 지식 축적	지금 다루는 업무의 규칙과 예외를 문서로 정리해보기
설계와 리뷰 능력	남의 코드에 이유를 붙여 의견을 남기는 훈련
AI 지시와 검증 훈련	요구사항을 글로 쓰고, 결과를 테스트로 확인하는 습관
본인 서비스 운영	작게 하나 만들어 배포하고 6개월 이상 굴려보기
글쓰기로 자산화	해결한 문제를 정리해 남기기

도메인 지식은 코드보다 오래 남습니다

지금 맡은 업무에서 왜 이런 규칙이 있는지, 예외 처리는 왜 생겼는지를 알아두는 일이 기술 학습보다 값질 때가 많습니다. 이런 지식은 검색으로 잘 안 나오고, AI도 그 회사의 사정까지는 모릅니다. 방법은 단순합니다. 업무 규칙을 한 페이지로 정리해보고, 설명되지 않는 부분을 담당자에게 물어보는 겁니다.

리뷰는 판단을 언어로 만드는 훈련입니다

코드 리뷰에서 "이렇게 하는 게 낫습니다"라고만 쓰면 훈련이 되지 않습니다. "이 경우 동시 요청이 들어오면 이런 순서로 문제가 생길 수 있어서"까지 써야 판단 근거가 언어로 남습니다. 이 능력이 그대로 AI에게 지시하는 능력이 됩니다.

AI 도구는 지시와 검증을 나눠서 훈련합니다

제가 쓰는 방식은 이렇습니다. 먼저 만들 것을 산문으로 적습니다. 입력과 출력, 지켜야 할 조건, 하지 말아야 할 것까지 적습니다. 그다음 결과를 받으면 실행 전에 눈으로 읽고, 경계값 테스트를 먼저 만들어 돌립니다. 이 두 단계를 건너뛰면 도구가 아무리 좋아도 품질이 떨어집니다.

서비스 하나를 직접 운영해보는 것

저는 메리톡톡을 혼자 만들고 운영하면서 회사 안에서는 배우기 어려운 것들을 얻었습니다. 사용자가 예상과 다르게 쓰는 장면, 새벽에 터진 장애를 혼자 수습하는 경험, 돈이 나가고 들어오는 흐름 같은 것들입니다. 규모가 작아도 상관없습니다. 처음부터 끝까지 혼자 책임져보는 경험 자체가 목적입니다.

글쓰기는 경험을 옮길 수 있게 만듭니다

해결한 문제를 정리해두면 두 가지가 생깁니다. 하나는 나중에 같은 문제를 만났을 때 쓸 기록이고, 다른 하나는 내가 무엇을 할 수 있는 사람인지 보여주는 근거입니다. 이력서 한 줄보다 문제 해결 기록 한 편이 더 많은 것을 설명할 때가 있습니다.

거창하게 쓸 필요는 없습니다. 어떤 증상이 있었고, 무엇을 의심했고, 어떻게 확인했고, 결국 원인이 무엇이었는지 네 문단이면 충분합니다. 저는 이 형식으로 몇 년째 쓰고 있는데, 실제로 예전 글을 다시 열어 해결한 적이 여러 번 있습니다. 남을 위해 쓴 글이 결국 나를 가장 많이 도왔습니다.

마치며

AI가 구현을 대신할수록 정의하고 검증하는 자리의 값이 오릅니다. 다만 그 자리는 연차가 아니라 습관으로 만들어집니다. 단순 구현 위주 경력이나 도메인 없는 기술 숙련은 오히려 위태로워질 수 있습니다.

오늘 할 수 있는 한 가지는 지금 맡은 업무의 규칙 중 설명하지 못하는 것 하나를 찾아 이유를 알아보는 일입니다. 그런 항목이 열 개쯤 쌓이면, 그게 다른 사람이 쉽게 못 가져가는 자산이 됩니다.