당신의 이력서에 있는 경험, 대학생이 AI를 쓰면 대체할 수 있지 않나요?

"AI는 결국 개발자를 대체할까요?"

요즘 개발자들끼리 이야기 할 때면 어김없이 나오는 주제입니다.
이미 클로드 코드와 커서 등이 만들어내는 코드는 제법 그럴듯하고, 단순한 기능은 몇 분 만에 뚝딱 만들어내기도 합니다.
불안감이 드는 건 어쩔 수 없죠.

그래서 오늘은 조금 도발적인 질문을 던져보려고 합니다.
지금 당신의 이력서를 한 번 열어보세요.
빼곡히 적힌 기술 스택들과 .

혹시 그 역량들은, 대학생이 AI를 활용했을 때 금방 따라 할 수 있는 것들은 아닌가요?

이 불편한 질문에 답하기 위해, 저는 최근 생각했던 흥미로운 비유 하나를 공유하고 싶습니다.

"AI는 프렌차이즈와 같다."

프랜차이즈는 요리 산업에 혁명을 가져왔습니다.
본사에서 제공하는 표준화된 레시피와 시스템 덕분에, 최고급 요리사가 아니어도 누구나 일정한 맛의 음식을 만들어 팔 수 있게 되었죠.
기존에 가장 비싼 인건비를 차지하던, '전문 요리사'를 고용할 필요가 줄어든 겁니다.

AI가 지금 개발 생태계에서 하는 역할이 이와 똑같습니다.
프랜차이즈 본사가 만든 '레시피'처럼, 우리 개발자들은 '개발 레시피(상세한 기획, 견고한 아키텍처, 정교한 프롬프트)'를 만듭니다.

그리고 AI는 그 레시피를 받아 빠르고 정확하게 코드를 찍어내는 '요리 로봇'이나 '서빙 로봇'과 같은 역할을 합니다.
여기서 핵심은, 로봇에게 어떤 요리를 어떤 순서로 만들라고 지시하는 주체는 바로 우리 '사람 개발자'라는 점입니다. 로봇이 아무리 뛰어나도, 레시피 자체가 훌륭하지 않으면 결코 좋은 요리가 나올 수 없습니다.

여기까지 생각하면 우리의 미래는 암울한 것 같습니다.
하지만 이 비유를 한 걸음 더 파고들면, 우리가 나아가야 할 길이 선명하게 보입니다.

'AI로 대체되기 쉬운 경험'이 뭔가요?

그렇다면 'AI로 무장한 대학생'이 쉽게 따라 할 수 있는 경험이란 구체적으로 무엇일까요? 당신의 이력서를 검토할 때, 아래 항목들이 경험의 '전부'는 아닌지 스스로에게 냉정하게 질문해봐야 합니다.

AI가 순식간에 해치우는 작업들

• 정형화된 기능 구현:
  • "게시판/댓글 CRUD API 엔드포인트 만들기"
  • "로그인/회원가입 폼 및 유효성 검사 기능 구현하기"
  • "특정 조건에 맞는 데이터를 DB에서 조회하여 테이블 형태로 보여주는 페이지 만들기"
• 잘 알려진 알고리즘 및 유틸리티 함수 작성:
  • "이메일 형식, 비밀번호 강도 등을 검증하는 정규표현식 만들기"
  • "JSON 데이터를 파싱해서 특정 값만 추출하는 스크립트 작성하기"
  • "파일 업로드 및 S3에 저장하는 로직 구현하기"
• 반복적인 보일러플레이트 코드 생성:
  • "새로운 React 컴포넌트 기본 구조(state, props) 생성하기"
  • "단순 CRUD 로직에 대한 기본 단위 테스트(Unit Test) 코드 짜기"
  • "새로운 프로젝트를 위한 초기 환경 설정 파일(eslint, prettier 등) 구성하기"
• 단순 데이터 처리 및 쿼리 작성:
  • "User 테이블과 Order 테이블을 JOIN하여 특정 유저의 주문 목록을 가져오는 SQL 쿼리 작성"
  • "CSV 파일을 읽어와 데이터베이스에 삽입하는 간단한 스크립트 만들기"

물론 이 모든 기술이 쓸모없다는 뜻이 아닙니다.
하지만 중요한 것은, 이것들이 핵심 역량의 '전부'가 되어서는 안 된다는 의미입니다.
이 작업들은 이제 '문제 해결'이라는 더 큰 목표를 위한 과정의 일부일 뿐, 그 자체가 다른 개발자와 차별화되는 고유한 '경험'이 되기는 어렵습니다.

'개발자의 레시피'는 무엇일까요?

앞서 나열한 CRUD, 보일러플레이트 코드 작성 등은 레시피의 '결과물'일 뿐, 레시피 그 자체가 아닙니다.
AI라는 '요리 로봇'은 정해진 레시피를 빠르고 정확하게 수행할 수는 있지만, 레시피 자체를 창조하지는 못합니다.

개발자의 '레시피'란, AI가 판단하기 어려운 불확실한 영역에서 최적의 길을 찾아가는 총체적인 문제 해결 과정을 의미합니다. 구체적으로는 다음과 같은 능력들을 포함합니다.

• 모호함 속에서 길 찾기 (요구사항 분석 및 정의): 비즈니스 담당자의 모호한 요구사항(e.g., "요즘 MZ세대에게 인기 있는 기능을 만들어주세요")을 듣고, 날카로운 질문을 통해 진짜 문제를 파악하고 구체적인 개발 요구사항으로 정의하는 능력.
• 최적의 균형점 찾기 (설계 및 아키텍처): 주어진 시간, 예산, 팀원의 역량 등 현실적인 제약 조건 안에서 최적의 아키텍처를 설계하는 능력. (e.g., "지금 MSA를 도입하는 것이 과연 우리에게 맞는가?", "이 기술 부채는 언제, 어떻게 해결할 것인가?")
• 예상치 못한 문제 해결하기 (디버깅 및 트러블슈팅): 원인을 알 수 없는 버그가 발생했을 때, 시스템 전체를 아우르는 넓은 시야로 근본 원인을 찾아내고, 재발 방지 대책까지 마련하는 능력.

이러한 총체적인 문제 해결 과정, 이것이 바로 AI가 흉내 낼 수 없는 '셰프의 레시피'입니다. 그리고 여러분의 이력서는 바로 이 '레시피 만드는 능력'이 있음을 증명하는 문서가 되어야 합니다.

그렇다면, 이력서를 어떻게 바꿔야 할까요?

단순히 성과를 나열하는 것은 더 이상 충분하지 않습니다.
AI는 '결과물'은 만들 수 있지만, 그 결과물이 필요했던 '상황과 배경'을 이해하거나, 그 과정에서 얻은 '교훈'을 체화하지는 못합니다.
바로 이 지점이 AI와 당신을 구분하는 결정적인 차이입니다.

경험을 단순 '성과'가 아닌, 한 편의 성장 '스토리'로 만들어야 합니다.

AI 시대의 이력서 스토리텔링: 배경-과정-성과-교훈 프레임워크

1. 배경 (Context): 이 프로젝트는 왜 시작되었나요? 팀과 회사는 어떤 문제를 겪고 있었나요? 왜 이런 판단을 했는지('Why')를 명확히 하세요.
2. 과정 (Process): 문제를 해결하기 위해 어떤 기술적 고민과 선택을 했나요? 여러 대안 중 왜 그 기술을 선택했는지, 어떤 트레이드오프가 있었는지 등, 어떻게 했는지('How')를 구체적으로 보여주세요.
3. 성과 (Achievement): 그래서 결과적으로 무엇이 바뀌었나요? 정량적인 수치로 비즈니스에 어떤 기여를 했는지, 무엇을 했는지('What')을 명확히 증명하세요.
4. 교훈 (Lesson Learned): 이 경험을 통해 무엇을 배웠나요? 기술적으로, 혹은 협업 관점에서 어떤 성장을 이루었는지 당신의 '성장'을 보여주세요.

Before (단순 성과 나열)

• 쇼핑몰 검색 기능 개발
• Spring Boot, Elasticsearch 사용

After ('배경-과정-성과-교훈' 스토리텔링)

• 쇼핑몰 검색 정확도 개선 및 사용자 이탈률 감소 프로젝트
  • (배경) 사용자들이 '원하는 상품을 찾기 어렵다'는 피드백과 함께 검색 페이지의 이탈률이 40%에 육박하는 심각한 비즈니스 문제가 있었습니다. 기존 검색 시스템은 단순 텍스트 매칭 방식이라 동의어/유의어 처리가 불가능했고, 이는 직접적인 매출 하락의 원인이었습니다.
  • (과정) 검색 로그를 분석해 사용자의 주요 실패 원인이 동의어 처리 부재와 느린 응답 속도임을 특정했습니다. RDB의 LIKE 검색, 외부 SaaS 등 여러 대안을 검토했으나, 유지보수성과 확장성을 고려해 Elasticsearch 도입을 결정했습니다. 한국어 처리를 위해 Nori 형태소 분석기를 적용하고, 운영팀과 협력하여 동의어 사전을 구축하는 등 검색 품질을 높이기 위한 구체적인 기술적 과제들을 해결했습니다.
  • (성과) 그 결과, 6개월 내에 검색 페이지 이탈률을 40%에서 15%로 낮추는 데 성공했으며, 검색 정확도 관련 사용자 불만 접수 건수를 월 평균 30건에서 5건 이하로 줄이는 정량적 성과를 달성했습니다.
  • (교훈) 이 경험을 통해 단순히 주어진 기술을 사용하는 것을 넘어, 사용자 데이터에 기반하여 문제를 명확히 정의하고, 여러 기술적 대안의 장단점을 비교 분석하여 최적의 솔루션을 선택하는 역량을 길렀습니다. 특히 대용량 데이터 검색 시스템의 원리에 대한 깊은 기술적 이해를 얻게 되었습니다.

AI는 적이 아닌, 최고의 부사수입니다.

이제 처음의 질문으로 돌아가 봅시다.
당신의 이력서, AI로 무장한 대학생이 대체할 수 있습니까?

만약 당신의 경험이 단순히 '주어진 기능 구현'에 머물러 있다면, 대답은 '그렇다'일지도 모릅니다.
하지만 당신이 문제를 해결한 '배경-과정-성과-교훈'을 하나의 스토리로 엮어냈다면, 대답은 달라질 것 입니다.

AI는 우리의 일자리를 빼앗는 경쟁자가 아닙니다. 단순하고 반복적인 코딩을 맡길 수 있는, 큰 연봉도 필요 없는 최고의 '부사수'입니다.
우리는 이 최고의 부사수에게 잡무를 맡기고, 더 높은 차원의 문제에 우리의 시간과 지성을 쏟아부어야 합니다.

이제 당신의 이력서를 다시 한번 들여다보세요. 그리고 스스로에게 질문해보세요.
"나는 AI를 부릴 수 있는 사람인가, AI에게 대체될 사람인가?"

---

참고사항

배경-과정-성과-교훈 프레임워크 라는거, STAR 기법이랑 비슷한데요?

네, 맞습니다.
이 프레임워크는 널리 알려진 STAR 기법(Situation-Task-Action-Result)과 매우 유사한 구조를 가집니다.

그럼에도 굳이 나눈 이유는, AI 시대에 개발자의 진짜 역량, 즉 '문제 해결 과정'과 '성장 잠재력'을 증명하는 데 목적을 둔, 보다 특화되고 친절한 '생각의 가이드'를 제시하기 위함이라는 결정적인 차이가 있습니다.

과거에는 주니어에게 "이 기술을 쓸 줄 아는가?"를 물었다면, AI 시대에는 "이 기술로 어떤 문제를 '왜', '어떻게' 해결해 보았는가?"를 묻기 시작했습니다.

'배경-과정-성과-교훈' 프레임워크는 바로 이 높아진 기대치에 맞춰, 시니어뿐만 아니라 주니어 개발자도 자신의 경험을 깊이 있게 되돌아볼 수 있도록 돕는 역할을 합니다.

• "그 일 왜 했어?" → 배경(Context)
• "다른 방법은 없었어? 왜 그 방법을 썼어?" → 과정(Process)
• "그래서 정말 뭐가 좋아졌어?" → 성과(Achievement)
• "그 경험으로 넌 무엇이 달라졌는데?" → 교훈(Lesson Learned)

이 질문들을 따라가다 보면, 자신의 경험 속에 숨겨진 AI와 차별화되는 지점을 발견하고, 그것을 설득력 있는 이야기로 완성할 수 있게 됩니다.

성과는 꼭 정량적(Quantitative)이어야 할까요?

결론부터 말하면, 전혀 그렇지 않습니다.
오히려 정성적 성과가 더 큰 임팩트를 보여줄 때도 많습니다.

초기 기획 단계에서 '사용자의 진짜 니즈를 파악'하거나, 복잡한 레거시 시스템의 '기술 부채를 해결'하는 것과 같은 중요한 경험은 명확한 숫자로 측정하기 어렵습니다.
이러한 정성적 성과는 '상태의 변화'나 '미래 가치 확보'의 관점에서 서술할 때 그 가치가 드러납니다.

다음은 AI가 절대 만들어 낼 수 없는, 개발자의 역량을 보여주는 좋은 정성적 성과의 예시입니다.

• 기술적 발판 마련: 레거시 코드를 리팩토링하여, 향후 신규 기능 개발 속도를 2배 이상 개선하고 버그 발생 가능성을 현저히 낮추는 기술적 토대를 마련함.
• 팀 생산성 및 문화 개선: 비효율적인 배포 프로세스를 자동화(CI/CD)하여, 개발자들이 코드 외적인 작업에 쏟는 시간을 절약하고 개발에만 집중할 수 있는 환경을 구축함.
• 커뮤니케이션 비용 감소: 산발적인 UI 컴포넌트를 표준화하여 디자인 시스템의 기초를 다졌고, 이를 통해 디자이너와 개발자 간의 불필요한 커뮤니케이션 비용을 크게 줄이고 프로덕트 전반의 UI 일관성을 확보함.

프레임워크 활용 시 주의사항

이 프레임워크는 강력한 도구이지만, 만병통치약은 아닙니다.
잘못 사용하면 오히려 이력서의 가독성을 해치는 독이 될 수 있습니다.
다음 세 가지를 꼭 기억하세요.

1. 모든 경험에 적용하려 하지 마세요 (강약 조절이 핵심입니다).
이력서는 당신의 커리어 하이라이트를 담는 '예고편'과 같습니다. 모든 장면에 힘을 줄 필요는 없습니다. 당신의 성장을 가장 잘 보여주는 핵심 프로젝트 2~3개에만 이 프레임워크를 적용하여 깊이를 보여주고, 나머지 경험들은 간결하게 성과 위주로 요약하는 것이 좋습니다.

2. 억지로 스토리를 만들지 마세요 (진정성이 중요합니다). 모든 경험에 대단한 서사가 있는 것은 아닙니다. 단순하고 반복적인 업무였다면 솔직하게 명시하는 것이 낫습니다. 성과나 배운 점이 빈약한 경험을 억지로 이 틀에 맞춰 포장하려 하면, 글이 부자연스러워지고 진정성을 잃게 됩니다.

3. 읽는 사람을 고려하세요 (전략적인 맞춤화가 필요합니다). 지원하는 회사와 직무에 따라 강조할 포인트를 조절해야 합니다. 예를 들어, 기술 중심의 스타트업이라면 과정의 기술적 깊이를 강조하고, 안정적인 대기업이라면 성과의 비즈니스 기여도나 교훈을 통한 협업 경험을 더 부각하는 것이 효과적일 수 있습니다.