왜 직업 단위가 아니라 업무 단위로 봐야 하나
기사 제목은 직업이 살아남을지를 묻습니다. 연구는 더 유용한 질문을 던집니다. 그 직업 안의 어떤 업무가, 얼마나 빨리 바뀌는가입니다. O*NET은 소프트웨어 개발을 하나의 활동이 아니라 여러 업무의 묶음으로 기술합니다. 코드 작성과 테스트부터 사용자 요구 분석, 시스템 아키텍처 설계, 다른 팀과의 조율까지 포함되며, 이 업무들의 운명은 같지 않습니다.
실제 AI 사용 데이터도 같은 방향을 가리킵니다. AI 어시스턴트와의 실제 대화를 분석하는 Anthropic 경제 지수는 소프트웨어 관련 업무를 생성형 AI의 가장 큰 실사용 영역 중 하나로 꾸준히 꼽으며, 대부분은 사람이 개입을 유지하는 보조 패턴이지 완전한 위임이 아닙니다. 따라서 개발자에게 실질적인 질문은 AI와 코드 생성 속도를 겨루는 것이 아니라, 한 주의 어떤 부분을 넘기고 어떤 부분을 의도적으로 지킬 것인가입니다.
한 주의 어떤 업무부터 압축되나
먼저 압축되는 업무에는 세 가지 공통점이 있습니다. 입력이 화면 위의 텍스트나 코드이고, 결과물의 구조를 검사할 수 있으며, 사람이 검토하기 때문에 틀린 초안의 비용이 낮다는 점입니다. 반복 코드와 뼈대 작성, 단위 테스트 생성, 코드 설명, 1차 문서화, 프레임워크나 언어 간 마이그레이션 초안, 일상적인 디버깅 제안이 여기에 해당합니다.
압축은 소멸이 아닙니다. 생성된 테스트 묶음에도 무엇을 테스트할 가치가 있는지 정하는 사람이 필요합니다. 마이그레이션 초안에도 옛 시스템의 숨은 전제와 새 시스템의 제약을 모두 이해하는 사람이 필요합니다. 사라지는 것은 대부분 중간의 타이핑 시간이지, 양 끝의 책임이 아닙니다.
사람에게 몰리는 업무
초안 작성이 값싸질수록 세 종류의 개발 업무가 상대적으로 더 귀해집니다. 첫째는 아키텍처입니다. 경계, 데이터 모델, 장애 양상을 선택하는 일은 잘못되면 몇 달을 잃고, 하나의 프롬프트에 전체 맥락이 담기지 않습니다. 둘째는 검증입니다. 미묘한 버그, 안전하지 않은 기본값, 라이선스 문제, 성능 절벽을 프로덕션보다 먼저 잡아낼 만큼 깊이 있게 AI 결과물을 읽는 능력입니다. 셋째는 책임입니다. 시스템이 왜 그렇게 동작하는지 설명할 수 있고, 그렇지 않을 때 답을 내놓는 사람이 되는 것입니다.
BLS의 직업 데이터도 소프트웨어 개발을 타이핑 속도가 아니라 요구 분석, 설계, 구축, 유지보수라는 더 큰 순환으로 기술합니다. AI를 적극 도입한 팀일수록 개발자의 시간을 리뷰, 통합, 신뢰성 쪽으로 옮기는 경향이 있으며, 엔지니어링 판단의 필요 자체를 줄이지는 않습니다.
현실적인 90일 계획
첫 달에는 자신의 한 주를 측정하세요. 초안 작성, 검토, 의사결정에 각각 대략 몇 시간이 가는지 기록합니다. 테스트 생성처럼 반복되는 업무 하나에 AI 보조를 도입하되, 결과물을 항상 한 줄씩 검토해서 도구가 의존성이 아니라 읽는 능력을 훈련하게 하세요.
둘째 달에는 자신이 다루는 시스템 하나를 골라 아무도 기록하지 않은 트레이드오프까지 포함해 아키텍처를 글로 정리하세요. 자신이 전부 설계하지 않은 시스템을 설명하는 능력이 바로 검증 업무가 요구하는 능력입니다. 셋째 달에는 장애 건수나 리뷰 처리 시간 같은 운영 품질 지표 하나를 맡아 AI를 활용해 개선하세요. 다음 면접에서 도구 목록보다 품질 개선의 전후 이야기가 훨씬 힘이 셉니다.
