코드를 짜는 일이 더 이상 나의 본업이 아니라는 자각

2024년 말, 나는 처음으로 하루 종일 코드를 한 줄도 직접 작성하지 않은 채 퇴근한 날을 겪었다. 그런데 그날이 그 분기에서 가장 생산적인 하루였다. 아이러니하게도, 20년간 코드를 써온 사람이 코드를 쓰지 않는 날이 가장 큰 가치를 만들어낸 것이다.

그날 나는 무엇을 했는가. AI가 생성한 코드 세 건을 리뷰했고, 주니어 두 명이 AI와 협업하며 만든 설계안의 방향을 재설정했고, 운영팀과 장애 시나리오 워크숍을 진행했고, 아키텍처 의사결정 하나를 문서화했다. 손가락이 키보드 위에서 코드를 두드리지 않았을 뿐, 머릿속에서는 20년치 경험이 끊임없이 가동되고 있었다.

이 시리즈를 10화까지 이어오면서 AI 시대에 사람만이 할 수 있는 일들 — 판단, 맥락 읽기, 신뢰 구축, 창의적 도약, ‘왜’를 묻는 힘 — 을 하나씩 짚어왔다. 그 모든 역량이 한 사람 안에서 종합적으로 발현되는 역할이 있다면, 그것이 바로 시니어 개발자다. 오늘은 매우 개인적인 이야기를 해보려 한다. 20년차 개발자인 내 일이, 지난 2년간 어떻게 바뀌었는지에 대해서.

과거의 시니어: ‘가장 빠르고 정확하게 코드를 짜는 사람’

솔직히 고백하자면, 나는 오랫동안 나의 가치를 ‘코딩 속도와 정확도’에서 찾았다. 복잡한 비즈니스 로직을 머릿속에서 풀어내고, 그것을 정확한 코드로 변환하는 능력. 후배가 이틀 걸리는 작업을 반나절에 끝내는 것. 그것이 시니어의 증명이라고 생각했다.

2000년대 초반 금융IT에 입문했을 때부터 나의 성장 곡선은 명확했다. 더 많은 언어를 익히고, 더 복잡한 시스템을 다루고, 더 빠르게 문제를 해결하는 것. 5년차에는 혼자서 모듈 하나를 온전히 맡았고, 10년차에는 시스템 전체의 설계를 주도했고, 15년차에는 장애 상황에서 30분 안에 원인을 찾아내는 사람이 되었다.

이 모든 것의 공통점은 ‘직접 하는 것’이었다. 직접 코드를 읽고, 직접 디버깅하고, 직접 해결책을 구현하는 것. 그것이 경력의 핵심이었고, 존재 이유였다.

그 정체성이 흔들린 순간

2024년 중반, 우리 팀에 AI 코딩 도구가 본격 도입되었을 때 나는 묘한 위기감을 느꼈다. 5년차 후배가 AI를 활용해 내가 반나절 걸릴 작업을 2시간 만에 해내는 것을 목격했다. 물론 그 코드에는 미묘한 문제들이 있었고, 내가 리뷰해서 잡아냈지만 — 그 순간 나는 깨달았다. ‘빠르게 코드를 짜는 것’은 더 이상 시니어의 고유 역량이 아니다.

AI는 이미 대부분의 정형화된 코딩 작업에서 인간을 능가한다. CRUD 구현, 보일러플레이트 작성, 테스트 코드 생성, 간단한 버그 수정 — 이런 것들에서 속도로 AI를 이기는 것은 불가능해졌다. 내가 20년간 축적해온 ‘타이핑 생산성’의 가치가 급격히 떨어지고 있었다.

이것은 단순한 도구의 변화가 아니었다. 정체성의 위기였다.

전환기: 잃어버린 것과 발견한 것

정직하게 말하겠다. 처음 몇 달은 불안했다. ‘내가 필요 없어지는 건 아닌가’라는 생각이 들었다. 특히 AI가 점점 더 복잡한 코드를 생성해내는 것을 보면서, 내 경력의 핵심 가치가 증발하는 듯한 느낌을 받았다.

하지만 실제 현장에서 벌어진 일은 달랐다. AI가 코드 생산을 대량으로 가능하게 만들수록, 오히려 나를 찾는 빈도가 늘어났다. 다만 그 이유가 과거와 완전히 달라졌을 뿐이다.

과거에 나를 찾던 이유

• “이 로직 어떻게 짜야 해요?”
• “이 에러 왜 나는 거예요?”
• “이 API 스펙 좀 봐주세요.”
• “코드 리뷰 부탁드립니다.”

지금 나를 찾는 이유

• “AI가 세 가지 방안을 제시하는데, 우리 시스템에는 어떤 게 맞을까요?”
• “이 설계로 가면 3년 뒤에 문제가 생길까요?”
• “AI가 만든 코드인데, 뭔가 찝찝한데 뭐가 문제인지 모르겠어요.”
• “이 기술 부채를 지금 갚아야 할까요, 아니면 다음 분기에?”
• “규제 변경이 예고됐는데, 시스템 어디를 미리 손봐야 할까요?”

차이가 보이는가? 과거에는 ‘어떻게(How)’를 물었다면, 지금은 ‘왜(Why)’와 ‘언제(When)’와 ‘무엇을(What — 여러 선택지 중에서)’을 묻는다. 10화에서 신입에게 ‘왜’를 가르쳐야 한다고 말한 것과 같은 맥락이다. 시니어의 역할은 이제, 그 ‘왜’의 답을 줄 수 있는 사람이 되는 것이다.

새로운 시니어의 다섯 가지 역할

지난 2년간의 시행착오를 통해, 나는 AI 시대 시니어 개발자의 역할을 다섯 가지로 정리하게 되었다. 이것은 이론이 아니라, 매일 출근해서 실제로 하고 있는 일들이다.

역할 1: 아키텍처 심판관 (Architecture Arbiter)

AI는 놀라울 정도로 빠르게 코드를 생성하지만, 시스템 전체의 맥락 안에서 ‘이 설계가 3년 뒤에도 유효한가’를 판단하지는 못한다. 8화에서 다뤘듯, AI가 못 읽는 ‘행간’이 있기 때문이다.

예를 하나 들겠다. 최근 우리 팀에서 새로운 서비스 간 통신 방식을 결정해야 했다. AI에게 물어보면 REST, gRPC, 메시지 큐 각각의 장단점을 깔끔하게 정리해준다. 기술적으로 완벽한 비교표를 만들어준다. 하지만 AI는 다음을 모른다.

• 우리 팀에서 gRPC 경험이 있는 사람이 한 명뿐이라는 것
• 3년 전 메시지 큐 도입 시도가 운영 복잡도 때문에 실패한 역사가 있다는 것
• 내년에 예정된 조직 개편으로 이 시스템의 소유권이 바뀔 수 있다는 것
• 현재 인프라팀이 특정 기술에 대한 지원 체계를 갖추고 있다는 것
• 규제당국이 특정 통신 방식에 대해 감사 추적을 요구할 가능성이 있다는 것

이 모든 ‘보이지 않는 제약 조건’을 종합해서 최적의 결정을 내리는 것. 그것이 아키텍처 심판관의 역할이다. AI는 선택지를 제공하고, 시니어는 조직·역사·미래를 고려해 결정한다.

내가 실제로 하는 일의 상당 부분이 이것이다. “AI가 A와 B를 추천하는데요”라고 오면, 나는 기술적 우열이 아니라 ‘우리 조직의 맥락에서 어떤 것이 지속 가능한가’를 판단해준다. 이 판단에는 기술적 지식뿐 아니라 조직에 대한 깊은 이해, 과거 실패의 경험, 업계 규제의 흐름 파악이 필요하다.

역할 2: 품질의 최종 방어선 (Quality Gatekeeper)

AI가 코드를 대량 생산하는 시대에, 코드 리뷰의 의미가 완전히 바뀌었다. 과거의 코드 리뷰가 ‘변수명 컨벤션’이나 ‘에지 케이스 누락’을 잡는 것이었다면, 지금의 코드 리뷰는 훨씬 더 고차원적인 문제를 다룬다.

AI가 생성한 코드는 대체로 문법적으로 완벽하고, 컨벤션도 잘 따르고, 기본적인 에지 케이스도 처리한다. 그래서 표면적으로는 완벽해 보인다. 하지만 20년간 시스템을 운영해본 사람의 눈에는 다른 것들이 보인다.

• 숨겨진 성능 함정: “이 쿼리, 데이터가 100만 건 넘으면 풀스캔 나갈 텐데?”
• 운영 사각지대: “이 에러 처리, 새벽 3시에 장애 나면 원인 추적할 수 있나?”
• 보안 취약점: “이 입력값, 금융 거래에서 조작 가능성은?”
• 확장성 병목: “지금은 괜찮은데, 트래픽 10배 되면 여기서 막힐 거야.”
• 규제 위반 잠재성: “이렇게 로그 남기면 개인정보 보호법 위반 소지 있어.”

이것들은 AI가 놓치는 것들이다. 왜냐하면 AI는 ‘코드 수준의 정확성’은 보장하지만, ‘시스템 수준의 적합성’까지 판단하지 못하기 때문이다. 4화에서 말했듯, AI가 ‘끝맺지 못하는 일’의 영역이다.

한 가지 구체적 사례. AI가 생성한 금융 데이터 처리 코드가 있었다. 로직은 완벽했다. 테스트도 통과했다. 하지만 나는 한 가지를 발견했다 — 부동소수점 연산을 사용하고 있었다. 일반적인 시스템에서는 전혀 문제없다. 하지만 금융 시스템에서 부동소수점 연산은 1원 미만의 차이를 만들어낼 수 있고, 이것이 수천만 건의 거래에 걸쳐 누적되면 실제 금전적 차이가 발생한다. 감사에서 걸리면 큰 문제다. 이런 것은 금융IT에서 수년간 일해본 사람만이 ‘본능적으로’ 감지한다.

역할 3: 번역가 — 기술과 비즈니스의 통역 (Translator)

시니어 개발자의 가장 과소평가된 역할 중 하나가 ‘번역’이다. 비즈니스 요구사항을 기술 설계로, 기술적 제약을 비즈니스 언어로 번역하는 것.

AI가 아무리 뛰어나도, “규제당국에서 이런 지침이 나왔는데, 우리 시스템에 어떤 영향이 있나요?”라는 질문에 정확히 답하려면 두 세계를 모두 깊이 이해하는 사람이 필요하다. AI에게 규제 문서를 분석시키면 일반적인 해석은 해주겠지만, ‘우리 시스템의 구체적인 컴포넌트 X가 규제 조항 Y에 저촉될 수 있으며, 이를 해결하려면 아키텍처를 Z 방향으로 변경해야 하고, 그 변경의 공수는 대략 N주’라는 답은 줄 수 없다.

이 번역가 역할은 AI 시대에 오히려 더 중요해졌다. 왜냐하면 AI 도입 자체가 새로운 번역 과제를 만들어내기 때문이다.

• “AI가 이 업무를 자동화할 수 있다고 하는데, 실제로 우리 환경에서 가능한가요?” (기술 → 경영진)
• “이 AI 도구를 도입하면 기존 워크플로우가 어떻게 바뀌나요?” (기술 → 현업)
• “AI가 판단한 결과의 신뢰도를 어떻게 보장하나요?” (기술 → 컴플라이언스)
• “AI 도입 비용 대비 효과를 어떻게 측정하나요?” (비즈니스 → 기술팀)

6화에서 ‘AI가 정답을 줘도 결정은 사람이 한다’고 말했을 때, 그 결정을 가능하게 하는 것이 바로 이 번역이다. 의사결정자에게 기술적 선택지를 그들의 언어로 전달하고, 각 선택의 비즈니스적 임팩트를 명확히 해주는 것.

역할 4: 위험 감지기 — 보이지 않는 리스크를 읽는 사람 (Risk Sensor)

이것은 어쩌면 시니어의 가장 본질적인 역할일지 모른다. ‘아직 일어나지 않은 문제’를 미리 감지하는 능력.

20년간 시스템을 운영하면서 수많은 장애를 겪었다. 새벽 3시에 호출받아 나가본 적이 수십 번이다. 그 경험들이 축적되면 일종의 ‘위험 직감’이 생긴다. 코드를 보거나 설계를 보면, 아직 문제가 터지지 않았는데도 “여기서 언젠가 터지겠다”는 느낌이 온다.

AI는 이 직감을 가지지 못한다. AI는 패턴을 인식하지만, ‘우리 시스템의 특수한 맥락에서 이 패턴이 위험하다’는 판단은 못 한다. 9화에서 말한 ‘외삽(extrapolation)’의 영역이다. 기존 데이터에 없는 새로운 장애 시나리오를 상상하는 것, 아직 경험하지 못한 규모의 트래픽에서 어떤 일이 벌어질지 예측하는 것.

최근 겪은 일이다. 한 서비스의 새 기능 설계를 검토하고 있었다. AI가 생성한 설계안은 기능적으로 완벽했다. 하지만 나는 한 가지가 걸렸다 — 특정 시간대에 두 개의 배치 작업이 동시에 이 테이블을 접근하는 패턴이 보였다. 각각은 문제없지만, 분기 말 마감일에 동시 실행되면 데드락 가능성이 있었다. 이것은 ‘분기 말’이라는 비즈니스 맥락과 ‘데드락’이라는 기술 지식, 그리고 ‘과거에 비슷한 상황에서 겪은 장애 경험’이 합쳐져야만 감지할 수 있는 위험이다.

AI에게 “이 설계에 문제가 있나?”라고 물으면, 일반적인 동시성 이슈를 지적해줄 수는 있다. 하지만 ‘분기 말 마감 시점에 배치가 겹치는 구체적 시나리오’까지 상상해서 경고해주지는 않는다. 그 상상력은 경험에서 온다.

역할 5: 성장 촉진자 — AI 시대의 새로운 멘토링 (Growth Catalyst)

10화에서 신입에게 ‘왜’를 가르쳐야 한다고 말했다. 그 가르침을 실행하는 것이 시니어의 다섯 번째 역할이다. 하지만 AI 시대의 멘토링은 과거와 완전히 다른 양상을 띤다.

과거의 멘토링: “이 패턴은 이렇게 구현하는 거야” → 구현 방법 전수

현재의 멘토링: “AI가 만들어준 이 코드에서 네가 의심해야 할 부분이 뭘까?” → 비판적 사고 훈련

이 변화는 미묘하지만 본질적이다. 과거에는 지식을 ‘주는’ 것이 멘토링이었다면, 지금은 판단력을 ‘기르게 하는’ 것이 멘토링이다. AI가 지식 전달의 상당 부분을 대체한 지금, 시니어가 후배에게 줄 수 있는 가장 큰 선물은 ‘무엇을 의심해야 하는지’를 알려주는 것이다.

나는 요즘 후배들에게 이렇게 말한다. “AI가 만든 답을 가져오되, 그 답이 틀릴 수 있는 세 가지 시나리오를 같이 가져와.” 처음에는 어려워하지만, 이 훈련이 반복되면 스스로 위험을 감지하는 능력이 생긴다. 내가 지금 가지고 있는 ‘직감’을 다음 세대에 전달하는 방법이다.

시니어의 하루: Before & After

구체적으로 내 일상이 어떻게 바뀌었는지 비교해보겠다.

2년 전의 전형적인 하루

• 09:00 — 출근, 메일 확인, 코드 리뷰 2건 (문법·스타일 위주)
• 10:00 — 신규 기능 코딩 시작
• 12:00 — 점심
• 13:00 — 코딩 계속 (복잡한 비즈니스 로직 구현)
• 15:00 — 후배 질문 대응 (“이거 어떻게 짜요?”)
• 16:00 — 버그 디버깅
• 18:00 — 코드 커밋, 퇴근

코딩 비율: 약 60~70%

현재의 전형적인 하루

• 09:00 — 출근, AI가 생성한 코드 리뷰 3건 (아키텍처 적합성·보안·성능 관점)
• 10:00 — 설계 의사결정 회의 (AI가 제시한 세 가지 옵션 중 선택)
• 11:00 — 기술 부채 분석 및 우선순위 조정
• 12:00 — 점심
• 13:00 — 후배와 1:1 (AI 활용 패턴 코칭 + 비판적 리뷰 훈련)
• 14:00 — 장애 대응 시나리오 문서화
• 15:00 — 비즈니스팀과 기술 제약 미팅
• 16:00 — 신규 시스템 PoC 방향 설정 (직접 코딩 → AI에게 위임할 부분 분리)
• 17:00 — 아키텍처 의사결정 기록(ADR) 작성
• 18:00 — 퇴근

직접 코딩 비율: 약 10~20%

비율만 보면 “시니어가 할 일이 줄었다”고 느낄 수 있다. 하지만 현실은 정반대다. 오히려 더 바쁘고, 더 많은 정신 에너지를 쓴다. 코딩은 손과 뇌의 협업이지만, 의사결정과 판단은 순수하게 뇌만 쓰는 일이다. 하루가 끝나면 손가락은 멀쩡한데 머리가 지끈거린다.

‘코딩 실력’에서 ‘판단 실력’으로 — 평가 기준의 변화

시니어의 역할이 바뀌면, 당연히 평가 기준도 바뀌어야 한다. 하지만 많은 조직이 아직 이 전환을 따라잡지 못하고 있다.

전통적으로 개발자의 역량은 다음으로 측정됐다.

• 코드 라인 수 (물론 이건 좋은 지표가 아니었지만, 암묵적으로 작용했다)
• 기능 구현 속도
• 버그 수정 건수
• 기술 스택 다양성

하지만 AI 시대의 시니어는 다른 것으로 측정되어야 한다.

• 의사결정의 적중률: 내가 내린 아키텍처 결정이 6개월 뒤에도 유효한가?
• 위험 예방 건수: 내가 리뷰에서 잡아낸 잠재적 문제가 몇 건인가?
• 팀 생산성 증폭: 내가 있음으로써 팀 전체의 산출물 품질이 얼마나 올라가는가?
• 기술 부채 관리: 시스템의 건강도가 유지되고 있는가?
• 후배 성장 속도: 내 팀원들이 얼마나 빨리 자립하는가?

이 중에서 가장 측정하기 어렵지만 가장 가치 있는 것이 ‘위험 예방’이다. 문제가 터지기 전에 막은 것은 눈에 보이지 않기 때문이다. 장애가 한 번 터지면 회사가 수억 원의 손실을 입을 수 있는 금융 시스템에서, 그 장애를 미리 막아낸 시니어의 가치는 어떻게 측정해야 하는가? 이것이 시니어의 딜레마이자, 조직이 풀어야 할 과제다.

위기: AI가 시니어마저 위협하는가?

솔직히 이 질문을 피할 수 없다. “AI가 더 발전하면 시니어도 필요 없어지는 것 아닌가?”

나는 이 질문에 대해 단기와 장기를 나눠서 답한다.

단기 (2~3년): 시니어의 가치가 오히려 상승한다

AI 도입 초기에는 ‘사람의 판단’이 더 귀해진다. 3화에서 다뤘듯, AI를 잘 쓰는 팀과 못 쓰는 팀의 차이는 피드백 루프에 있다. 그 피드백 루프의 품질을 결정하는 것이 시니어의 경험이다. AI가 생산하는 코드의 양이 폭증하면서, 그것을 걸러내고 방향을 잡아줄 시니어의 희소성은 높아진다.

현재 시장에서도 이 현상은 이미 나타나고 있다. AI 도구를 활용해 생산성을 높인 주니어·미드레벨 인력은 많아졌지만, ‘AI가 못하는 판단’을 할 수 있는 시니어는 여전히 부족하다. 수요와 공급의 법칙은 여기서도 작동한다.

중장기 (5~10년): 역할은 다시 변한다

솔직히 5~10년 뒤에는 현재의 ‘아키텍처 심판관’ 역할도 AI가 상당 부분 대체할 수 있을 거라고 본다. AI가 조직의 맥락, 과거 의사결정 히스토리, 규제 환경까지 학습하게 되면.

하지만 그때도 남는 것이 있다. 7화에서 다룬 ‘신뢰 자산’이다. 기술적 판단을 넘어서, 사람과 사람 사이의 신뢰를 기반으로 조직을 움직이는 능력. “이 사람이 괜찮다고 하면 괜찮은 거다”라는 인간적 신뢰. 이것은 아무리 AI가 발전해도 대체하기 어렵다.

결국 시니어의 역할은 ‘기술 전문가’에서 ‘판단 전문가’로, 그리고 다시 ‘신뢰 기반 리더’로 진화해갈 것이다. 각 단계에서 순수한 기술적 역량의 비중은 줄어들지만, 인간적 역량의 비중은 늘어난다.

실전 가이드: 시니어로서 AI와 공존하는 법

이론은 여기까지 하고, 실제로 내가 매일 실천하는 것들을 공유하겠다.

1. AI를 ‘부하 직원’이 아니라 ‘페어 프로그래밍 파트너’로 대하라

많은 시니어가 AI를 ‘시키는 대로 하는 도구’로 취급한다. 하지만 나는 AI를 ‘내 생각에 도전하는 파트너’로 활용한다.

“내가 이렇게 설계하려고 하는데, 이 접근의 단점 세 가지만 말해봐.” “이 결정에 대해 반대 의견을 낸다면 어떤 논거를 댈 수 있을까?” 이런 식으로 AI를 활용하면, 내 판단의 사각지대를 발견할 수 있다. 시니어가 되면 경험이 많아지는 만큼 ‘경험의 편향’도 커지는데, AI는 이 편향을 견제하는 좋은 도구가 된다.

2. ‘무엇을 AI에게 맡기지 않을 것인가’를 먼저 정의하라

AI에게 뭘 맡길지보다, 뭘 맡기지 않을지를 먼저 정하는 것이 중요하다. 나의 기준은 이렇다.

• AI에게 맡기는 것: 정형화된 코드 생성, 테스트 작성, 문서 초안, 코드 변환, 보일러플레이트
• 내가 반드시 하는 것: 최종 설계 결정, 보안 리뷰, 성능 크리티컬 로직 검증, 장애 대응 판단, 팀원 코칭
• AI와 협업하는 것: 설계 옵션 탐색, 리팩토링 방향 논의, 코드 리뷰 초벌, 기술 조사

이 분류를 명확히 해두면 “AI가 내 일을 빼앗는다”는 불안 대신 “AI가 내 시간을 확보해준다”는 관점으로 전환된다.

3. 의사결정을 기록하라

AI 시대에 시니어의 가장 중요한 산출물은 코드가 아니라 ‘의사결정 기록’이다. 왜 이 기술을 선택했는지, 왜 이 설계를 채택했는지, 어떤 대안을 검토했고 왜 기각했는지.

이 기록이 중요한 이유는 세 가지다.

• 조직의 학습: 내가 없어도 팀이 과거 결정의 맥락을 이해할 수 있다.
• AI의 학습: 이 기록을 AI에게 먹이면, 미래에 AI가 더 나은 제안을 할 수 있다.
• 자기 보호: “왜 그때 그렇게 결정했나”라는 질문에 명확히 답할 수 있다.

나는 주요 기술 결정을 내릴 때마다 ‘Architecture Decision Record’를 작성한다. 형식은 간단하다 — 맥락, 결정, 이유, 고려한 대안, 예상 결과. 이것이 내 20년 경험의 ‘문서화된 형태’이며, 조직에 남기는 유산이다.

4. ‘모르겠다’를 두려워하지 마라

AI가 모든 정보를 즉시 제공하는 시대에, 시니어가 “모르겠다”고 말하기는 더 어려워졌다. 하지만 역설적으로, ‘모르겠다’를 인정하는 용기는 AI 시대에 더 중요해졌다.

AI는 절대 “모르겠다”고 말하지 않는다(5화에서 다뤘듯, 이것이 위험하다). 시니어가 “이건 불확실하다”, “여기는 더 검증이 필요하다”, “이 영역은 내 전문성 밖이다”라고 솔직히 말하는 것 자체가 팀에게 ‘건강한 불확실성 관리’의 모델이 된다.

AI가 확신에 찬 답을 줄 때, 시니어가 “잠깐, 이게 정말 맞나?”라고 의심의 브레이크를 거는 것. 그 한마디가 조직을 큰 실수에서 구할 수 있다.

5. 학습을 멈추지 마라 — 하지만 방향을 바꿔라

과거의 학습: 새 프레임워크 익히기, 새 언어 배우기, 새 도구 마스터하기 → ‘실행력’ 확장

현재의 학습: 산업 동향 파악, 규제 변화 추적, 조직 역학 이해, 커뮤니케이션 스킬 향상 → ‘판단력’ 확장

물론 기술 자체를 완전히 놓으라는 말은 아니다. AI 도구가 어떻게 동작하는지, 최신 기술이 어떤 가능성을 여는지는 계속 알아야 한다. 하지만 학습의 무게중심이 ‘기술 깊이’에서 ‘판단 폭’으로 이동해야 한다.

나는 요즘 기술 블로그보다 규제 동향 리포트를 더 많이 읽는다. 새 프레임워크의 튜토리얼보다 기술 리더십에 관한 책을 더 많이 본다. 이것이 AI 시대에 시니어의 가치를 유지하는 학습 전략이다.

흔한 오해와 함정

오해 1: “AI가 다 해주니까 시니어는 편해졌겠다”

오히려 반대다. AI가 실행을 대신해줄수록, 판단의 압박은 커진다. 과거에는 “이거 구현하는 데 2주 걸립니다”가 방어 논리가 됐다. 지금은 AI가 2시간 만에 만들어내니, 결정을 미룰 여유가 없다. 의사결정의 속도와 정확도 모두에 대한 기대치가 높아졌다.

오해 2: “코딩을 안 하면 감각이 무뎌지는 거 아닌가”

맞는 말이다. 그래서 나는 완전히 코딩을 놓지 않는다. 주 1~2회는 직접 코딩하는 시간을 확보한다. 하지만 그 목적이 바뀌었다. ‘산출물을 내기 위해’가 아니라 ‘감각을 유지하기 위해’ 코딩한다. 운동선수가 시합 없는 날에도 연습하는 것과 같다.

다만 코딩 시간의 비중이 60~70%에서 10~20%로 줄었다는 것은 사실이고, 이것은 자연스러운 진화다. 요리사가 경력이 쌓이면 직접 프라이팬을 잡는 시간보다 메뉴를 구성하고 주방을 관리하는 시간이 늘어나는 것과 같다.

오해 3: “젊은 사람이 AI를 더 잘 쓰니까 시니어가 밀리는 거 아닌가”

AI ‘도구 사용 숙련도’에서는 젊은 세대가 빠르게 따라잡는다. 당연하다. 하지만 AI ‘활용 판단’에서는 경험이 압도적 우위다. “AI에게 뭘 물어야 하는지”를 아는 것과 “AI의 답에서 뭘 걸러야 하는지”를 아는 것은 경험에서 나온다.

비유하자면, AI는 레스토랑의 모든 식재료를 무한히 제공해주는 것과 같다. 젊은 요리사는 식재료를 빠르게 다루지만, 경험 많은 셰프는 어떤 식재료를 조합해야 최고의 요리가 되는지를 안다. 두 능력 다 필요하지만, 시니어의 가치는 후자에 있다.

오해 4: “시니어 역할이 매니저 역할이랑 같아지는 거 아닌가”

비슷해 보이지만 결정적 차이가 있다. 매니저는 ‘사람’을 관리하고, 시니어 엔지니어는 ‘기술적 복잡성’을 관리한다. AI 시대의 시니어는 코딩 비중이 줄어들면서 매니저와의 경계가 모호해지는 것은 사실이다. 하지만 시니어의 판단은 여전히 ‘깊은 기술적 이해’ 위에 세워져야 한다.

“이 시스템을 마이크로서비스로 분리해야 하나?”라는 질문에 답하려면, 분산 시스템의 트레이드오프를 뼛속까지 이해하고 있어야 한다. 이건 피플 매니지먼트 역량이 아니라 기술적 깊이에서 나오는 판단이다. 시니어는 ‘코딩을 안 하는 매니저’가 아니라 ‘코딩 너머의 기술적 판단을 하는 엔지니어’다.

시니어 개발자에게 보내는 메시지

이 글을 읽고 있는 시니어 동료들에게 하고 싶은 말이 있다.

첫째, 불안을 인정하자. AI 시대에 “내 자리가 위협받는 것 같다”는 느낌은 정상이다. 그것을 부정하거나 무시하면 오히려 적응이 늦어진다. 불안을 인정하되, 그것에 지배당하지 않는 것이 중요하다.

둘째, 정체성을 재설정하자. “나는 코드를 잘 짜는 사람”에서 “나는 좋은 판단을 내리는 사람”으로 정체성을 옮기는 작업이 필요하다. 이것은 하루아침에 되지 않는다. 시간을 들여 서서히 전환하면 된다.

셋째, 20년의 경험을 무기로 인식하자. AI가 학습한 것은 공개된 데이터다. 당신이 특정 도메인에서 20년간 축적한 암묵지, 장애 대응 경험, 조직 맥락에 대한 이해 — 이런 것들은 AI의 학습 데이터에 없다. 그것이 당신의 대체 불가능한 가치다.

넷째, 후배를 키우는 것을 부담이 아니라 투자로 보자. AI 시대에 시니어의 가장 큰 레버리지는 ‘판단력의 전파’다. 한 명의 시니어가 다섯 명의 후배에게 비판적 사고를 가르치면, 조직의 AI 활용 품질이 5배 올라간다. 그 증폭 효과가 시니어의 존재 가치를 증명한다.

다섯째, 기술과 멀어지지는 말자. 직접 코딩 비중이 줄더라도, 기술의 깊이를 놓으면 판단력도 따라서 무뎌진다. “감각 유지”를 위한 코딩 시간을 의식적으로 확보하자. 주 1회라도.

조직에 보내는 메시지

시니어 개발자 개인의 노력만으로는 이 전환이 완성되지 않는다. 조직 역시 바뀌어야 한다.

평가 체계의 전환

“코드 라인 수”나 “기능 구현 건수”로 시니어를 평가하는 조직은, AI 시대에 시니어의 진짜 가치를 놓치게 된다. ‘예방한 장애’, ‘내린 의사결정의 질’, ‘팀 생산성 증폭’ 같은 새로운 지표를 도입해야 한다.

시니어의 시간 보호

시니어에게 여전히 대량의 코딩 작업을 할당하는 조직은, 가장 비싼 인력을 가장 저렴한 일에 쓰는 것이다. AI가 대체할 수 있는 일에 시니어를 묶어두는 것은 자원 낭비다. 시니어의 시간은 ‘판단이 필요한 일’에 집중되어야 한다.

지식 전달 인센티브

시니어가 후배를 가르치는 것을 ‘추가 부담’이 아니라 ‘핵심 성과’로 인정하는 체계가 필요하다. AI 시대에 시니어의 암묵지를 조직에 전파하는 것은, 코드를 한 줄 더 짜는 것보다 훨씬 큰 가치를 만든다.

금융IT 20년의 관점에서

마지막으로, 금융IT라는 특수한 도메인에서의 경험을 더 나누겠다.

금융 시스템은 ‘실수의 비용’이 극단적으로 높은 도메인이다. 코드 한 줄의 버그가 수억 원의 손실로, 규제 위반으로, 고객 신뢰 상실로 이어질 수 있다. 이런 도메인에서 AI의 도입은 양날의 검이다.

한편으로는, AI가 반복적인 검증 작업을 자동화해줌으로써 인적 오류를 줄여준다. 다른 한편으로는, AI가 만들어낸 코드에 대한 과도한 신뢰가 새로운 형태의 리스크를 만든다.

금융IT에서 시니어의 역할이 특히 중요한 이유가 여기에 있다. “이 AI가 만든 코드, 정말 프로덕션에 넣어도 되나?”라는 최종 판단은 도메인의 특수성을 깊이 이해하는 사람만이 할 수 있다. 부동소수점의 함정, 동시성 이슈, 규제 준수, 감사 추적 요건 — 이런 것들은 범용 AI가 일반적 수준에서는 알고 있을지 몰라도, ‘우리 시스템의 구체적 맥락’에서의 적용은 경험 있는 사람의 몫이다.

챗봇 8년의 경험도 마찬가지다. 4화에서 말했듯, 금융 챗봇에서 AI가 ‘끝맺지 못하는 일’이 있다. 그 일의 최종 책임은 결국 도메인을 아는 시니어에게 돌아온다. AI가 만든 응답 로직이 규제에 저촉되지 않는지, 고객에게 오해를 줄 소지가 없는지, 예외 상황에서 적절한 에스컬레이션이 되는지 — 이 모든 것을 판단하는 것이 시니어의 일이다.

시니어의 가치는 사라지지 않는다 — 형태가 바뀔 뿐이다

이 시리즈를 통해 계속 강조해온 것이 있다. AI는 사람을 대체하는 것이 아니라, 사람의 역할을 재정의한다. 시니어 개발자도 마찬가지다. ‘코드를 짜는 시니어’는 사라지고 있지만, ‘판단을 내리는 시니어’, ‘방향을 잡는 시니어’, ‘팀을 키우는 시니어’는 오히려 더 절실하게 필요해지고 있다.

20년의 경험이 ‘타이핑 속도’에 있었다면, 그 가치는 줄어들 수밖에 없다. 하지만 20년의 경험이 ‘판단의 정확도’, ‘위험의 감지력’, ‘맥락의 이해력’에 있다면, AI 시대에 그 가치는 오히려 폭등한다.

변화는 이미 일어나고 있다. 적응하지 못하면 도태되는 것도 사실이다. 하지만 나는 20년간 이 업계에서 살아남으면서 수많은 기술 변화를 겪어왔다. 그때마다 “이제 개발자 필요 없다”는 말이 나왔지만, 실제로 사라진 것은 ‘역할의 형태’였지 ‘사람의 필요성’은 아니었다.

AI 시대도 마찬가지일 것이다. 다만 이번에는 변화의 속도가 전례 없이 빠르다. 그래서 더 의식적으로, 더 능동적으로 자신의 역할을 재정의해야 한다. 가만히 있으면 떠밀리지만, 방향을 잡고 움직이면 오히려 더 높은 곳에 도달할 수 있다.

다음 화, 시리즈의 마지막인 12화에서는 이 모든 이야기를 종합한다. AI 시대에 ‘사람으로서의 가치’를 지키기 위해 우리 각자가 할 수 있는 것, 그리고 이 긴 여정의 결론을 이야기하려 한다.

📝 이번 주 한 줄 노트: 시니어의 가치는 ‘코드를 짜는 속도’에서 ‘판단을 내리는 정확도’로 이동했다. 20년 경험의 진짜 가치는 키보드가 아니라 머릿속에 있다.

※ 이 글은 특정 기업이나 조직의 입장이 아닌, 20년차 금융IT 개발자 개인의 견해입니다.

이미지는 Leonardo AI 로 생성되었습니다.

이미지는 Claude AI 로 생성되었습니다.