그럼에도 살아남을 개발자의 조건 3가지
아직까지도 풀리지 않는 의문이 하나 있다.
과연 '전문가'라는 칭호는 스페셜리스트(Specialist)에 가까운가, 제너럴리스트(Generallist)에 가까운가?
결론부터 말하자면, 현시대 기준으로 후자에 가깝다고 생각은 하나 여전히 의문이긴 하다.
AI가 조명되기 전까지만 해도 통상적으로 한 분야에 깊은 지식이 있는 사람들을 전문가라고 칭하곤 했다. 마치 개발자를 세분화하여 프론트엔드 개발자, 백엔드 개발자로 나누는 것처럼 말이다.
그러나 지금은 상황이 너무 많이 달라졌다. 실무에서 모르는 부분이 생겼을 때, 당장 그 자리에서 창 하나 켜고 ChatGPT에게 모르는 것을 물어보면 빠르게 정보 습득이 가능하기 때문이다. 물론 해당 정보를 빠르게 소화하는가에 대한 여부는 그동안의 경험과 지식이 부가적으로 필요하다.
해고되는 MS 직원 40%는 ‘소프트웨어 개발자’… AI가 촉발한 기술직 해고
美 컴퓨터 개발자 고용 2년간 27.5% 하락
“단순한 코딩은 AI가 대체… 개발자 전문성 중요”

개발자 전문성, 과연 그 전문성의 스펙트럼은 어느 정도까지를 얘기하는 걸까?
솔직히 현업 개발자의 입장에서 이런 현실을 마주하는 것이 매우 속이 쓰리다. 열심히 코딩테스트 공부하고, 사수에게 갈굼 당하며 코드 리뷰를 받고, 또 배움을 게을리하지 않아야 한다기에 나름대로 틈틈이 공부도 해왔건만 개발자들이 제 발등에 도끼를 찍는 아이러니한 현상에 정신이 얼얼하다.
그렇다고 컴퓨터를 좋아해서 개발하고 있는 컴쟁이들이 당장 어떠한 액션을 취할 수도 없는 노릇이다. 흔히 SNS나 미디어에서는 개발자는 살아남고 코더는 뒤쳐진다고는 하나 이미 기업에서 AI 도입은 활성화되고 있고, ChatGPT와 함께 코딩을 하고 있다면 '나는 지금 코더가 아니야'라고 100% 자신 있게 말할 개발자들은 많지 않을 거라 생각된다. 이전보다 편하게, 가끔은 뇌 빼고 개발하고 있는 건 부정할 수 없지 않은가.
이제는 회피해선 안되고 정면으로 부딪혀야 한다.
따라서, 그럼에도 살아남을 개발자의 조건 3가지를 읊어보려고 한다.
이미 기업에서는 Copilot이나 ChatGPT, Cursor 등 LLM 사용을 적극 권장하는 분위기이다. 필자는 사이드 프로젝트를 진행하면서 Claude Opus 4를 애용하며 쓰고 있다.
그렇다면, AI 도구를 잘 다룬다는 기준은 뭘까?
단순히 프롬프트에 '~해줘'를 넘어 논리적으로 AI에게 일을 시킬 수 있는 수준을 말한다.
1. 체계적 프롬프트 설계
❌ "로그인 기능 만들어줘"
✅
"Node.js Express 프레임워크 기반으로, JWT 토큰 방식의 로그인 API를 작성해 줘."
- 사용자 정보는 MongoDB에 저장
- 비밀번호는 bcrypt로 해싱
- 에러 처리와 validation 포함
- 테스트 코드도 함께
2. 단계별 작업 분해
❌ "쇼핑몰 사이트 만들어줘"
✅
1단계: "쇼핑몰 데이터베이스 스키마 설계해 줘"
2단계: "상품 CRUD API 구현"
3단계: "장바구니 기능 추가"
4단계: "결제 시스템 연동"
3. 코드 리뷰 및 최적화 요청
"이 코드의 성능을 개선하고, 보안 취약점을 점검해 줘"
"이 함수를 더 읽기 쉽게 리팩토링 해줘"
"테스트 커버리지를 높이는 추가 테스트 케이스 작성해 줘"
4. 맥락 제공과 제약 조건 명시
"월 1억 건 이상의 로그 데이터를 처리하는 시스템이야.
PostgreSQL을 사용하고, 파티셔닝이 이미 적용됐어.
메모리는 16GB, 실시간 분석 쿼리 성능을 개선할 인덱싱 전략을 제안해 줘."
추가적으로 AI가 짠 코드를 검증하고, 최적화할 수 있는 능력이 필요하다. 비즈니스 도메인 영역을 AI가 오롯이 100% 커버하긴 어렵기 때문에 개발자가 미흡한 부분을 커버해야 한다.
AI의 치명적인 약점(?)이 하나 있다면, 먼저 질문을 할 수 없다는 것이다. AI와의 대화에서 첫 물꼬를 트기 위해서는 설계와 기획에 대한 충분한 이해가 필요하다. 아키텍처 관점에서 프로그램을 바라볼 수 있어야 비로소 프롬프팅도 가능하다.
1. 시스템 아키텍처 설계 능력
- 문제: "사용자가 몰려서 서버가 다운돼요"
- 해결 전략: 전체 시스템 구조 재설계 (로드밸런싱, 캐싱 전략, DB 샤딩)
AI는 개별 코드는 짜주지만, 전체 시스템 그림은 그리지 못한다.
2. 기술 스택 선택과 의사결정
AI의 한계는 "어떻게 구현할지"는 알지만 "어떤 기술을 선택할지"는 비즈니스 맥락 없이 판단 불가하다.
3. 요구사항 분석과 기술적 해법 도출
- 비개발자: "고객이 주문을 취소할 수 있게 해 주세요"
- 단순 개발자: 취소 버튼만 추가
- 설계 기반 개발자: 결제 상태별 취소 정책 수립, 재고 복원 로직 설계, 고객 알림 시스템 연동, 환불 프로세스 자동화
4. 비기능적 요구사항 정의
성능, 보안, 확장성, 유지보수성과 같은 비기능적 요구사항은 AI가 놓치기 쉬운 영역이다. 클라이언트의 모호한 요구사항을 수치화, 구체화하는 영역은 다수의 경험을 지닌 개발자만이 할 수 있다.
추후 기술 부채 대응 전략과 리팩토링 전략까지 수립할 수 있다면 금상첨화다.
결국 설계와 기획 능력이 뛰어난 개발자는 AI를 더 정교하게 활용할 수 있다. 무엇을 만들지 구체적으로 정의할 수 있기 때문에 AI에게는 '어떻게(How)'를 묻고, 인간에게는 '무엇(What)'과 ‘왜(What)' 를 물으며 효율적 생산성 제고를 실현할 수 있다.
1. 개발 + 디자인
2. 개발 + 데이터 분석
3. 개발 + 비즈니스
4. 개발 + 교육
개발만 하다가 뜬금없이 디자인 공부를 각 잡고 하라는 뜻은 아니다. 개발자는 디자이너, 기획자와 커뮤니케이션할 일이 생각보다 많은데 (그때마다 싸우는 것보다는) "어떻게 하면 품질 향상으로 이어지는 생산적인 대화가 가능할까?"라고 지속적으로 고민해 보는 것이 중요하다. 가끔은 UI/UX 책도 읽어보고, 기획 관련 책도 읽어보는 정도의 관심만으로도 충분하다.
AI가 코딩을 대체한 만큼 개발자는 타 영역에서도 역량을 발휘할 수 있어야 가치가 올라갈 것이다. 순수 코딩만 하는 개발자는 AI와 경쟁해야 하지만, +a 역량이 있다면 멀티 플레이어로서 AI가 대체할 수 없는 고유한 경쟁력을 갖게 될 것이다.
1+1=3
결론적으로 현시대 ‘개발자의 전문성' 기준은 비즈니스 관점으로 더 넓은 시각에서 볼 수 있는가 여부를 의미한다. 마치 A 기능에 대한 개발 티켓을 부여받는다면, 파생된 서브 이슈를 선제안할 수 있는 능력이지 않을까.
(물론 현실적으로 팀 내에서 일감을 적절히 분배해 준다거나 직속 상사가 이를 존중할 수 있다는 전제가 필요하다.)
따라서, AI를 경계하고 두려워하는 것보다 위기를 기회 삼아 더 큰 비즈니스 임팩트를 창출할 수 있는 개발자가 되기 위한 새로운 기회라고 생각하자.
다소 희망적으로 바라보자면, 코딩이라는 무릇 반복적인 작업에서 해방된 만큼 더 큰 그림 기반으로 창의적이고 전략적인 일에 집중할 수 있게 되었다고 생각한다.
더 나은 사용자 경험을 설계하고, 요구사항에 집중하여 비즈니스 성장에 직접적으로 기여할 수 있는 방안을 도출해 내는 것. 이것이 바로 AI 시대 개발자의 진짜 역할이자 기회이다.