AI가 코드를 쓰는 시대, 백엔드 실력은 어떻게 증명되는가

URL: https://www.youtube.com/watch?v=wyjdDHb8pu0 날짜: 2026-08-27 채널: 딩코딩코 원문 제목: [24시간만 공개] AI가 코드를 쓰는 시대, 백엔드 실력은 어떻게 증명되는가 영상 ID: wyjdDHb8pu0 영상 유형: YouTube Live 다시보기 영상 길이: 1시간 58분 24초 발표자: 박현준(딩코딩코 운영자, 포스텍 출신, 토스 백엔드 경력, 백엔드 9년차로 소개) 자막: YouTube 한국어 자동 자막 전체 검토

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==AI가 코드를 빠르게 만들어 주는 시대에는 무엇을 구현했는지가 아니라, 어떤 핵심 기술로 어떤 문제를 풀었고 그 결과를 어떤 증거로 검증했는지가 백엔드 실력을 증명한다.==

• 발표자가 제시한 기본 공식은 핵심 기술 + 문제 소재 + 검증 증거다.
• AI 코딩 에이전트는 이 세 요소를 대신 만들어 주지 않는다. 학습·탐색·구현·측정·기록의 속도를 높이고, 좋은 문제를 더 크게 실험하도록 돕는 도구에 가깝다.
• 흔한 N+1이나 단순 CRUD처럼 누구나 말할 수 있는 소재는 기술을 썼다는 사실만으로 차별화되지 않는다. 비즈니스 맥락, 병목, 트래픽 가정, 전후 수치가 결합되어야 한다.
• 신입은 거대한 MSA·Kafka·Elasticsearch 스택을 나열하기보다 자신이 이해하고 설명할 수 있는 단일 서버와 명확한 문제를 깊게 파는 편이 안전하다.
• AI를 쓸수록 오히려 기초를 직접 실행해 본 경험, 결과를 검증하는 능력, 무엇을 만들지 선택하는 판단이 중요해진다.

1. 라이브의 맥락과 발표자의 문제의식

1.1. 방송 도입

1. 방송 초반에는 마이크와 오디오 입력을 확인하고 시청자에게 좋아요·구독을 요청하는 시간이 이어졌다.

   • 9월 6일 신촌에서 개발자 오프라인 행사를 열 예정이며, 참가비와 제공 상품, 개발자 간 대화와 추첨 이벤트를 안내했다.
   • 이 부분은 본론의 근거라기보다 라이브 방송의 운영 맥락이다. 발표자는 중간에도 부트캠프와 강의, 이력서 피드백 프로그램을 소개했다.

2. 본론은 약 9분부터 시작했다.

   • 주제는 “AI가 코드를 쓰는 시대, 백엔드 실력은 어떻게 증명되는가”다.
   • 시청자에게 신입·경력 연차를 채팅으로 물어보고, 서로의 상황에 맞는 이력서와 포트폴리오 전략을 이야기하는 형식으로 진행했다.

1.2. 발표자의 관찰 범위

1. 발표자는 딩코딩코/딘코닷넷, 개발 강의와 챌린지, 백엔드 취업 부트캠프를 운영한다고 소개했다.
2. 크몽 등을 통해 100개가 넘는 개발자 이력서를 보고 피드백하면서 합격 이력서에 반복되는 패턴을 관찰했다고 말했다.
3. 과거에는 Spring Boot, 인증, JPA 동적 쿼리처럼 사용한 기술만 적어도 성장 가능성을 보여줄 수 있다고 판단되던 시기가 있었다.
4. 그러나 AI가 코드를 만들고 이력서의 기술 키워드도 빠르게 평준화하면서, 이제는 “무엇을 써 봤다”보다 “무엇을 증명했는가”가 더 중요해졌다는 것이 출발점이다.

2. 실력을 증명하는 세 가지 요소

2.1. 핵심 기술

1. 핵심 기술은 단순히 많이 들어 본 기술이 아니라, 지원하는 팀이나 프로젝트의 문제를 풀 수 있게 해 주는 기술이다.

   • 예로 Go/gRPC, MySQL, Redis, Kafka 같은 팀의 기술 스택이 언급됐다.
   • AI 연구·개발팀에 지원하고 AI 자체를 제품의 핵심으로 다룬다면 AI가 핵심 기술이 될 수 있다.
   • 반대로 일반 백엔드 지원자가 코딩 에이전트를 사용했다는 사실만으로 AI를 핵심 기술로 내세우는 것은 충분하지 않다.

2. 스택을 무조건 크게 만들 필요는 없다.

   • Java/Spring 백엔드 신입을 예로 들며 Spring Boot, JPA, 트랜잭션·동시성, 인덱스와 쿼리 최적화, Redis 등 자신이 설명할 수 있는 범위를 제안했다.
   • 이는 절대적인 필수 목록이 아니라 “이 정도 범위에서도 충분히 매력적인 문제를 만들 수 있다”는 하한선에 가깝다.
   • 자신 있는 스택이 다른 언어, 메시징 플랫폼, 인프라라면 그것을 중심으로 문제와 증거를 구성해도 된다.

2.2. 문제 소재

1. 문제 소재는 프로젝트를 만들었다는 설명이 아니라, 왜 그 시스템과 설계가 필요했는지에 대한 구체적 상황이다.
   • 트러블슈팅으로 발견한 병목
   • 특정 기술을 도입하면서 생긴 부작용
   • 도메인과 비즈니스 요구에서 나온 제약
   • 보안·성능·운영·검증상의 실패
2. 지원자가 해당 도메인의 문제를 이해하고 있다는 것을 보여주는 전문성도 문제 소재가 될 수 있다.
3. 흔한 키워드일수록 소재의 신선도가 낮아진다.
   • JPA N+1, 단순 동시성 문제처럼 검색 결과와 블로그가 매우 많은 주제는 면접관이 반복해서 접하는 소재다.
   • 발표자는 JPA 동시성 검색 결과 약 2만 6천 개, Kafka 이벤트 중복 처리 검색 결과 약 1만 7천 5백 개를 화면에서 확인하는 방식으로 이 점을 설명했다. 검색 수치는 방송 중 확인한 값이므로 절대적 시장 통계가 아니라 반복성의 예시로 봐야 한다.
   • 이력서 100개 중 95개가 비슷한 이야기를 하면, 지원자가 백엔드 문제에 특별히 관심이 있는지 판단하기 어려워진다.

2.3. 검증 증거

1. 검증 증거는 “개선했다”라는 문장을 측정 가능한 변화로 바꾸는 장치다.
   • TPS
   • 응답 시간과 레이턴시
   • 에러율
   • 쿼리 실행 계획
   • 큐 지연 시간과 재시도 배수
   • CPU·DB 부하
   • 장애 복구 시간과 DLQ 건수
2. 예전에는 기술 스택만 보고도 경험을 추정할 수 있었지만, AI 시대에는 핵심 기술만으로도, 문제 소재만으로도 부족하다.
3. 세 요소가 하나의 이야기로 결합되어야 한다.
   • 어떤 기술을 썼는가
   • 어떤 조건에서 어떤 문제가 발생했는가
   • 어떤 조치를 했고 무엇이 얼마나 달라졌는가
4. 발표자는 이력서의 차별화된 문장을 한두 개가 아니라 약 세 개 정도 만들고, 문제를 파악하고 분석하고 행동한 뒤 결과를 보여주는 PAR 흐름으로 준비하라고 권했다.

3. 구체적 포트폴리오 소재

3.1. 비동기 메시지 재시도 폭풍 제어

1. 핵심 기술
   • 비동기 메시징
   • 지수 백오프(Exponential Backoff)
   • DLQ(Dead Letter Queue)
   • Kafka나 다른 메시지 큐, 또는 필요에 따라 인메모리 큐를 사용할 수 있다.
2. 문제 소재
   • 실패한 메시지를 제한 없이 재시도하면 장애가 커지고, 큐가 밀리고, 정상 메시지까지 늦어질 수 있다.
3. 검증 증거
   • 재시도 배수
   • 큐 지연 시간
   • 복구에 걸린 시간
   • DLQ로 이동한 메시지 수
4. 실제 업무에서 대규모 메시징 시스템을 운영해 본 경험이 없더라도, 도메인과 요구사항을 합리적으로 가정해 실험할 수 있다.
   • 예를 들어 배달 서비스의 메시지 플랫폼을 만든다고 하고, 특정 시간 안에 여러 수신자에게 메시지를 전파해야 한다는 요구를 둔다.
   • 예상 트래픽과 임계점을 정하고, 그 부하를 모두 발생시켰을 때 어디까지 처리되는지 측정한다.
   • 가정은 임의의 과장이 아니라 트래픽·전환율·트랜잭션 수·용량의 관계를 설명할 수 있어야 한다.
5. 발표자는 이를 다리 건설에 비유했다.
   • 평상시 물만 보고 다리를 세우는 것이 아니라 비·홍수·수위 변화까지 고려해야 한다.
   • 백엔드 개발자도 서비스를 구현하는 데서 끝나지 않고, 예상 부하와 장애 조건을 상상하고 수치로 검증해야 한다.

3.2. AI가 만든 코드의 규칙 위반 자동 검증

1. AI로 생성되는 코드의 양이 늘면서 코드 리뷰가 병목이 되고, 팀 규칙을 사람이 매번 확인하기 어려워진다.
2. 정적 분석과 컨벤션 자동 검증을 이용해 규칙 위반을 조기에 발견하고 CI에서 차단하는 소재를 만들 수 있다.
3. 이때 핵심 기술 자체가 매우 화려하지 않아도 된다.
   • 오히려 AI 코드 슬롭을 어떻게 통제했는지, 위반 검출 건수와 CI 차단·수정 시간이 어떻게 달라졌는지가 문제와 증거가 된다.
   • 현업 개발자가 실제로 고민하는 최신 문제에 닿아 있기 때문에 단순한 기술 나열보다 면접 대화가 풍부해진다.
4. 발표자는 수동 리뷰에서 트랜잭션 규칙 위반을 놓치는 문제를 발견하고, JPA·트랜잭션 규칙·CI 정적 검사를 이용해 검증을 자동화한 사례도 설명했다.

3.3. 결제 상태 조회 API

1. 문제: 결제 상태를 확인할 때마다 데이터베이스를 조회하면 트래픽이 몰릴 때 QPS와 CPU가 치솟을 수 있다.
2. 핵심 기술: Spring Boot, JPA, Redis.
3. 해결과 증거: 상태 조회 흐름을 분석하고 캐시 등으로 병목을 줄인 뒤 QPS, CPU, 응답 시간 등의 전후 수치를 남긴다.
4. 이 사례에는 MSA나 Kafka가 없어도 된다.
   • 특정 유즈 케이스가 분명하고 문제의 원인과 결과가 뾰족하면, 거대한 분산 시스템보다 오히려 설명 가능성이 높다.
   • 결제라는 도메인에서 어떤 상태를 얼마나 자주 확인하고 어떤 일관성 요구가 있는지까지 설명하면 단순 CRUD와 구분된다.

3.4. 메시지 재시도와 관측성

1. Spring Retry로 재시도 정책을 두고, JPA DLQ 테이블과 Micrometer 메트릭으로 실패와 복구를 기록하는 조합도 예시로 들었다.
2. 중요한 것은 도구 이름을 적는 것이 아니라 다음을 설명하는 것이다.
   • 어떤 실패를 재시도할 것인가
   • 몇 번, 어떤 간격으로 시도할 것인가
   • 언제 격리하고 어떻게 다시 처리할 것인가
   • 장애 전후의 지연·에러·복구 수치가 어떻게 달라졌는가

4. 프로젝트를 만드는 현실적인 방법

4.1. 가정 기반 확장

1. 실제 회사에서 큰 트래픽이나 복잡한 메시징 문제를 맡을 기회는 제한적일 수 있다.
2. 그럴 때 도메인과 비즈니스 요구를 먼저 정하고, 예상 트래픽과 임계점을 가정해 부하를 만든다.
3. 면접에서는 “실제 장애를 겪었다”고 과장하지 말고, 어떤 가정을 세웠고 어떤 조건에서 병목이 생겼으며 어떻게 측정했는지 투명하게 설명해야 한다.
4. 서비스가 출시되기 전에는 정확한 TPS나 전환율을 알 수 없으므로, 백엔드 개발자는 예상치를 세우고 여러 부하 조건을 실험하는 능력이 필요하다.

4.2. 회사에서 소재를 얻기 어려울 때

1. 회사가 PHP나 파일 기반 저장소처럼 지원 직무의 시장에서 흔하지 않은 스택을 사용하거나, 업무가 기능 추가에만 머물러 문제를 드러내기 어려울 수 있다.
2. 이 경우에는 사이드 프로젝트를 의도적으로 만드는 것이 좋다고 했다.
   • 목표 회사가 사용하는 스택과 가까운 프로젝트를 선택한다.
   • 단순 구현이 아니라 트래픽·일관성·장애·관측성 중 하나의 문제를 고른다.
   • 작은 범위라도 핵심 기술, 문제, 증거를 끝까지 연결한다.
3. 현재 회사의 실무 경험을 숨기라는 뜻은 아니다. 실무 경력에는 실제로 맡은 역할을 쓰고, 문제 소재가 빈약한 경우 개인 프로젝트를 앞세워 기술적 증거를 보완할 수 있다는 의미다.

4.3. 신입이 피해야 할 과도한 스택

1. 신입 포트폴리오에 MSA, Kafka, Elasticsearch를 모두 넣으면 면접에서 설명해야 할 시스템 경계와 운영 지식이 급격히 늘어난다.
2. 메시징 시스템을 썼다면 단순히 “메시지 큐로 사용했다”를 넘어 프로듀서·컨슈머, 전달 보장, 재처리, 운영 경험과 장애 대응까지 질문받을 수 있다.
3. 신입은 우선 모놀리스에서 자신이 실제로 이해하는 병목을 깊게 파는 편이 낫다.
4. JVM·GC·JPA·ORM·데이터베이스 내부 원리를 깊게 파는 전략은 알고리즘과 CS를 강하게 보는 대기업 신입 공채형 목표에 더 잘 맞을 수 있다.
5. 서비스 기업을 목표로 한다면 실제 비즈니스 요구와 사용자 규모를 가정하고 문제를 해결한 경험이 더 직접적인 신호가 될 수 있다.
6. 발표자는 이를 “정파와 사파”라는 즉흥적 비유로 구분했지만, 어느 한쪽이 기본기를 공부하지 않아도 된다는 뜻은 아니라고 반복해서 정정했다.

5. AI를 사용하는 올바른 순서

5.1. AI는 세 요소를 대체하지 않는다

1. AI는 핵심 기술·문제 소재·검증 증거의 빈칸을 자동으로 채워 주지 않는다.
2. AI가 바꾸는 것은 학습 자료 탐색, 코드 작성, 실험 반복, 문서화와 같은 과정의 속도와 규모다.
3. 따라서 AI를 사용했다는 문장은 그 자체로 차별점이 아니다.
   • 어떤 개발 라이프사이클의 병목을 발견했는가
   • AI를 어디에 적용했는가
   • 사람의 검토와 검증 과정이 어떻게 달라졌는가
   • 시간·오류·반복 작업이 어떤 수치로 개선됐는가를 보여줘야 한다.

5.2. 기초는 직접 해 보고 확장한다

1. 신입이라면 JPA, Redis, 동시성처럼 이력서에서 핵심으로 내세울 기술의 기본 동작을 먼저 손으로 구현해 봐야 한다.
2. 직접 실행하지 않고 AI가 만든 설명과 코드를 바로 사용하면, 이해한 것 같은 착각이 생기고 면접에서 질문과 답변을 이어 가기 어려워진다고 발표자는 자신의 부트캠프 경험을 근거로 말했다.
3. 권장 순서는 다음과 같다.
   1. 작은 예제로 기술의 기본 동작을 직접 확인한다.
   2. 의도적으로 문제 조건을 만든다.
   3. 로그와 메트릭을 수집한다.
   4. 그 다음 AI를 이용해 변형·확장·테스트·리뷰·문서화를 가속한다.
   5. AI의 결과도 직접 실행하고 검증한다.
4. 잘하는 조직에서는 AI가 코드 생성만 하는 것이 아니라 기획, 리서치, 구현, 테스트, 코드 리뷰, 이슈 관리, 모니터링, 운영 전 과정에 연결될 수 있다.
5. 그러나 코드 생성물을 사람이 설명하고 책임질 수 있어야 하며, AI 코드를 검증하는 흔적을 남기는 것이 중요하다.

5.3. 발산을 통제하는 수렴 장치

1. AI는 아이디어와 구현 변형을 매우 빠르게 늘리는 데 강하다. 이 때문에 프로젝트가 수십 갈래로 뻗어 아무도 최종 결과를 설명하지 못하는 상황이 생길 수 있다.
2. 프로젝트를 시작하기 전에 PAR 흐름으로 무엇을 해결할지, 어디까지 증명할지, 어떤 결과를 남길지 정해야 한다.
3. 팀원끼리 계속 질문하고 문서와 설계를 설명하게 해야 한다.
4. 상용 서비스를 만드는 경우에는 실제 품질을 확보하기 위한 부하·성능·운영 검증을 생략하지 말아야 한다. 포트폴리오라면 범위를 분명히 줄이고 그 범위 안에서 결론을 내야 한다.

6. 이력서와 포트폴리오 작성법

6.1. 기술보다 문제를 앞세우기

1. 제목과 첫 문장에서 Kafka, Redis, Kubernetes 같은 도구를 크게 내세우기보다 사용자가 겪은 문제와 시스템의 제약을 먼저 보여준다.
2. 기술은 그 문제를 풀기 위해 선택한 수단으로 설명한다.
3. 결과는 “성능 개선” 대신 전후의 지표와 측정 조건으로 적는다.
4. 문제 소재가 약한데 수치만 뛰어난 사례는 메인 프로젝트가 되기 어렵다.
   • 예를 들어 운영 중 발견한 느린 서브쿼리를 제거한 결과는 훌륭한 보조 사례일 수 있지만, 그것 하나만 이력서의 중심으로 삼으면 문제의 맥락이 빈약할 수 있다.
5. 팀 협업, 리팩터링, 컨벤션, 클린 코드, DDD, TDD는 중요하지만 대개 핵심 성과를 보완하는 요소다.
   • 기본 원리를 공부하고 적용할 수 있어야 한다.
   • 다만 그것을 이력서의 주된 문제 해결 증거로 포장하기보다 기술 블로그, 면접의 설계 설명, 협업 사례로 보여주는 편이 낫다.

6.2. 개인 프로젝트의 경쟁력

1. 회사 경력 없이 개인 프로젝트만으로 합격한 신입 사례도 있다고 했다.
2. 프로젝트 수보다 한 프로젝트에서 몇 개의 분명한 문제 해결 문장을 꺼낼 수 있는지가 중요하다.
3. 게임 프로젝트 하나라도 도메인 요구와 병목을 잘 설계하면 여러 개의 PAR 사례를 만들 수 있다.
4. 이미 만든 CRUD 프로젝트도 도메인 요구와 부하 조건을 보강해 발전시킬 수 있다.
   • 다만 단순한 투두 리스트처럼 비즈니스 복잡도가 너무 낮으면 억지로 문제를 추가하기 어렵다.
   • 그럴 때는 새 프로젝트가 더 나을 수 있다.
5. 경력자도 회사에서 의미 있는 문제를 맡지 못했다면 사이드 프로젝트를 활용할 수 있다. 실제 경력과 개인 프로젝트가 서로의 약점을 보완하도록 배치하면 된다.

6.3. 프로젝트에서 세울 수 있는 수치

1. 사용자 수와 요청량을 가정한다.
2. 목표 응답 시간, 허용 에러율, 처리해야 할 메시지 수, 데이터 일관성 조건을 정한다.
3. 병목이 발생하기 전과 후를 같은 조건에서 측정한다.
4. 단순히 서버와 메모리를 늘려 해결한 결과는 운영상 유효할 수 있지만, 백엔드 기술의 핵심 증거로는 약할 수 있다.
5. 비용을 늘리지 않고 개선했다는 뜻은 아니다. 비용·성능·복잡도 사이의 선택을 설명하고, 어떤 조건에서 스케일업이 더 합리적인지도 함께 말할 수 있어야 한다.

7. 후반 Q&A에서 나온 실전 조언

7.1. Kafka와 고급 인프라

1. Kafka를 부가 기능으로 메시지 큐처럼 사용했다면, 왜 그 도구가 필요했는지와 프로젝트의 중심 문제가 무엇인지 구분해서 설명한다.
2. Kafka 자체가 문제 해결의 중심이었다면 프로듀서·컨슈머, 처리 보장, 재시도와 장애 복구 등 더 깊은 질문을 받을 수밖에 없다.
3. 신입이 기술을 기능적으로만 붙이고 운영 문제를 고려하지 않으면 핵심 기술을 과시하려다 오히려 약점이 된다.
4. 경력자는 서비스 간 경계, 인프라 임계점, 분산 트랜잭션이나 보상 트랜잭션처럼 더 복잡한 주제를 다뤄도 된다. 이미 단일 서버를 다뤄 본 기반이 있다는 전제가 있기 때문이다.

7.2. 사이드 프로젝트와 이직

1. 직무와 직접 관련 없는 인프라 프로젝트라도 기술적 호기심과 탐구력을 보여줄 수 있다.
2. 다만 “만들었다”에서 끝나면 약하다. 어느 정도의 트래픽과 스트레스를 견디도록 설계했고 무엇을 관찰했는지가 중요하다.
3. 개인 프로젝트만으로도 신입·3년차 이직 모두 가능하다고 답했지만, 실무 경력을 지우라는 뜻은 아니다.
4. 회사에서 문제 소재를 얻기 어렵다면 실무 경력을 정직하게 적고 개인 프로젝트를 별도의 강한 증거로 배치한다.

7.3. 기본기와 AI 학습

1. AI가 새 기술을 설명해 주더라도, 핵심 기술은 반드시 직접 구현하고 실행해 봐야 한다.
2. 면접에서는 AI가 만든 설명을 재생하는 것이 아니라, 자신이 선택한 이유와 결과를 대화로 검증받는다.
3. 네트워크, SOLID, DI/IoC 등 기본 개념은 여전히 필요하다.
   • 예전에는 이런 설명 자체가 합격을 가르는 차별점이었다면, 이제는 기본선에 가깝다.
   • 이 기본기가 있어야 AI가 만든 코드가 어디에 놓여야 하는지 판단하고 통제할 수 있다.
4. 클린 코드·DDD·TDD는 학습과 기술 블로그, 코드 설계의 기반이지, 항상 이력서의 메인 소재가 되는 것은 아니다.
5. 루프 엔지니어링·그래프 엔지니어링처럼 새 유행어가 나와도 먼저 개발 라이프사이클의 병목을 이해하고, 정말 필요한 도구인지 판단해야 한다.

7.4. 신규 기능 개발 중심의 경력자

1. 예전에는 요구사항을 얼마나 빨리 반영했는지와 학습 속도를 수치화하는 것이 강점이 될 수 있었다.
2. AI가 구현 속도를 끌어올린 지금은 단순한 기능 개발 속도만으로 차별화하기 어렵다.
3. 신규 기능 위주의 개발자는 사이드 프로젝트에서 성능·안정성·검증·운영 문제를 의도적으로 경험해 보는 것이 좋다고 했다.

7.5. 개발 방향 선택

1. 알고리즘과 CS를 강하게 보는 대기업 공채를 목표로 한다면 알고리즘·자료구조·운영체제·네트워크 같은 기본기를 우선한다.
2. 서비스 기업을 목표로 한다면 팀 프로젝트, 외부 활동, 실제 서비스 도메인과 비즈니스 요구, 트래픽과 운영 문제를 해결한 경험을 쌓는다.
3. 이 구분은 어느 한쪽이 우월하다는 뜻이 아니라, 목표에 따라 이력서에서 전면에 드러낼 증거가 달라진다는 뜻이다.

7.6. 벡터 DB·RAG·LLM 연동

1. 백엔드 채용에서 벡터 DB, RAG, LLM 연동을 요구하는 경우가 있어도 이를 프로젝트의 중심 기술로 과장할 필요는 없다.
2. 백엔드의 핵심 문제를 해결하면서 검색·추천·요약 같은 부가 기능을 붙인 사례로 설명하는 편이 안전하다.
3. 벡터 DB 자체를 얼마나 최적화했는지보다, 왜 그 기능이 필요했고 시스템의 전체 흐름에서 어떤 역할을 했는지가 중요하다.

7.7. AI로 프로젝트를 확장할 때

1. AI는 발산을 잘하므로 시작 전에 프로젝트의 PAR 구조와 종료 조건을 정한다.
2. 팀원이 문서와 설계를 실제로 설명할 수 있는지 계속 확인한다.
3. 상용 서비스라면 부하 테스트와 품질 검증을 하고, 포트폴리오라면 목표 범위를 명확히 한 뒤 그 안의 증거를 남긴다.

8. 발표자가 제안한 실행 순서

1. 핵심 기술 학습
   • 강의·책·문서·AI 등 적절한 방법으로 기술의 기본 원리를 익힌다.
   • 적어도 핵심 동작은 직접 코드를 작성하고 실행한다.
2. 소재 보드 작성
   • 다른 사람의 기술 블로그, 컨퍼런스, 회사 사례에서 문제를 수집한다.
   • 자신의 도메인과 기술 스택으로 옮길 수 있는 문제를 고른다.
3. 미션 또는 프로젝트 수행
   • 문제를 먼저 정의하고 트래픽·데이터·실패 조건을 가정한다.
   • 필요한 기술만 선택한다.
4. 병목에 부하와 스트레스 주기
   • TPS, 지연, CPU, DB 부하, 큐 지연, 에러율 등 관찰할 지표를 정한다.
   • 개선 전후를 같은 조건에서 비교한다.
5. 결과를 PAR 흐름으로 정리
   • 문제를 어떻게 발견했는지, 무엇을 분석했는지, 어떤 조치를 했는지, 결과가 어떻게 달라졌는지를 문장으로 만든다.
   • 프로젝트 하나에서 약 세 개 정도의 분명한 핵심 문장을 꺼낼 수 있으면 좋다.
6. 면접에서 재현
   • 이력서에 적은 기술과 수치를 직접 설명할 수 있어야 한다.
   • AI가 작성한 코드를 사용했다면 어디까지 사람이 판단하고 검증했는지 설명한다.

9. 핵심 인용과 표현

“핵심 기술, 문제 소재, 검증 증거”가 함께 있어야 백엔드 실력을 설명할 수 있다는 것이 발표자의 중심 공식이다.

AI는 빈칸을 대신 채우는 것이 아니라, 이미 가진 증명 요소를 더 빠르고 크게 실험하게 해 주는 도구에 가깝다.

발표자는 마지막에 백엔드 실력을 “믿을 수 있는 증거로 바꾼 기록”으로 남겨야 한다고 정리했다.

• “정파와 사파”는 방송 중 즉흥적으로 만든 비유다. 전자는 알고리즘·CS·JVM 같은 기본 원리와 기술 깊이를 강하게 보여주는 경로, 후자는 비즈니스 문제와 서비스 운영 사례를 강하게 보여주는 경로를 가리킨다.
• 발표자는 서비스 기업을 목표로 하는 사람도 기본기를 공부해야 하며, 사파가 정파 공부를 하지 않는다는 의미가 아니라고 여러 차례 보완했다.

10. 최종 정리: AI 시대 백엔드 포트폴리오 체크리스트

• [ ] 내가 지원하는 팀이 중요하게 보는 핵심 기술을 골랐는가?
• [ ] 그 기술을 단순히 붙인 것이 아니라 구체적인 문제를 해결하기 위해 선택했는가?
• [ ] 문제의 도메인·트래픽·실패 조건·비즈니스 요구를 설명할 수 있는가?
• [ ] 개선 전후의 TPS, 지연, 에러율, CPU, DB, 큐 관련 지표가 있는가?
• [ ] 실제 경험과 가정 기반 실험을 구분해 말할 수 있는가?
• [ ] 하나의 프로젝트에서 문제 파악→분석→행동→결과의 문장을 세 개 정도 만들 수 있는가?
• [ ] 기술 스택을 면접 질문의 깊이까지 설명할 수 있는가?
• [ ] AI가 만든 코드와 설명을 직접 실행하고 검증했는가?
• [ ] 기본 동작은 AI 없이도 손으로 구현해 본 적이 있는가?
• [ ] AI를 사용한 사실보다 개발 라이프사이클의 병목을 어떻게 개선했는지를 말할 수 있는가?
• [ ] 프로젝트 범위를 통제하고, 더 이상 확장하지 않을 종료 조건을 정했는가?
• [ ] 클린 코드·DDD·TDD·새 AI 유행어를 메인 성과로 과장하지 않고 적절한 역할로 배치했는가?

결론

이 영상은 AI 시대에 백엔드 개발자의 가치가 사라진다는 이야기가 아니라, 가치의 증명 방식이 바뀐다는 이야기다. AI가 구현 속도를 평준화할수록 채용자는 지원자가 무엇을 만들었는지보다 어떤 문제를 골랐는지, 그 문제를 기술적으로 어떻게 분석했는지, 실제 또는 명시적 가정 아래에서 결과를 어떻게 측정했는지를 보게 된다. 따라서 포트폴리오의 중심은 기술 목록이 아니라 문제와 증거의 연결이어야 한다.

개발자는 먼저 핵심 기술의 기본 동작을 직접 익히고, 그 기술로 풀 만한 문제를 도메인에서 찾고, 작은 프로젝트라도 부하와 실패 조건을 수치로 만들어야 한다. 그 다음 AI를 사용해 구현·실험·리뷰·문서화를 확장할 수 있다. AI가 만들어 낸 수많은 가능성을 하나의 설명 가능한 결과로 수렴시키는 것이 결국 개발자의 판단이며, 그 판단이 이력서와 면접에서 신뢰할 수 있는 백엔드 실력으로 남는다.

핵심 요약 (40줄)

1. AI가 코드를 쓰는 시대에도 백엔드 채용의 중심은 AI 도구 사용이 아니라 실력을 증명하는 것이다.
2. 발표자가 제시한 증명 공식은 핵심 기술, 문제 소재, 검증 증거의 결합이다.
3. 핵심 기술은 지원 팀이나 프로젝트의 문제를 풀 수 있게 하는 기술 스택을 뜻한다.
4. AI 연구팀이라면 AI 자체가 핵심 기술이 될 수 있지만 일반 백엔드에서는 코딩 에이전트가 도구인 경우가 많다.
5. 문제 소재는 프로젝트를 만들었다는 사실이 아니라 왜 그 시스템과 설계가 필요했는지다.
6. 트러블슈팅, 비즈니스 요구, 도메인 지식, 기술 도입의 부작용이 문제 소재가 될 수 있다.
7. JPA N+1과 단순 동시성은 너무 흔해 기술을 썼다는 사실만으로는 차별화하기 어렵다.
8. 이력서 100개 중 95개가 같은 이야기를 하면 지원자의 차별점을 발견하기 어려워진다.
9. 검증 증거는 TPS, 응답 시간, 레이턴시, 에러율, 실행 계획 같은 측정값이다.
10. 핵심 기술만 있거나 문제와 수치만 있는 것보다 세 요소가 하나의 서사로 연결되어야 한다.
11. 비동기 메시지 재시도 폭풍 제어는 메시징, 지수 백오프, DLQ를 결합한 포트폴리오 소재다.
12. 실패 메시지를 무제한 재시도하면 장애가 커지고 큐 지연과 복구 시간이 늘어날 수 있다.
13. 재시도 배수, 큐 지연, 복구 시간, DLQ 건수로 개선을 검증할 수 있다.
14. 실제 대규모 시스템 경험이 없어도 도메인과 트래픽을 가정해 임계점을 실험할 수 있다.
15. 가정 기반 프로젝트는 트래픽, 전환율, 트랜잭션, 용량의 관계를 설명할 수 있어야 한다.
16. AI 생성 코드가 늘수록 코드 리뷰와 팀 규칙 자동 검증이 새로운 문제 소재가 된다.
17. 정적 분석과 CI 검증은 규칙 위반 검출 건수와 수정 흐름으로 증명할 수 있다.
18. 결제 상태 조회 API는 DB 반복 조회로 인한 QPS와 CPU 상승을 다룰 수 있는 사례다.
19. Spring Boot, JPA, Redis만으로도 뾰족한 문제와 증거를 만들면 충분히 매력적일 수 있다.
20. 신입이 MSA, Kafka, Elasticsearch를 모두 넣으면 면접에서 설명해야 할 복잡도가 급격히 커진다.
21. 신입은 거대한 인프라보다 자신이 이해하는 모놀리스의 병목을 깊게 파는 편이 안전하다.
22. 회사에서 소재를 얻기 어렵다면 목표 직무에 맞는 사이드 프로젝트를 의도적으로 만들 수 있다.
23. 개인 프로젝트만으로도 신입과 경력자의 이직 경쟁력을 만들 수 있지만 문제와 수치가 필요하다.
24. 단순 CRUD 프로젝트는 도메인 요구와 실패 조건을 보강하기 어렵다면 새로 만드는 편이 낫다.
25. AI는 핵심 기술과 문제와 증거의 빈칸을 대신 채우지 않고 학습과 실험의 속도를 높인다.
26. AI 사용 경험은 어떤 개발 라이프사이클의 병목을 줄였는지로 설명해야 한다.
27. 신입은 핵심 기술의 기본 동작을 AI 없이 직접 구현한 뒤 AI로 확장하는 것이 좋다.
28. 직접 실행하지 않은 AI 설명은 이해한 것 같은 착각을 만들고 면접 대응력을 낮출 수 있다.
29. AI는 아이디어를 발산시키므로 프로젝트 시작 전에 PAR 구조와 종료 조건을 정해야 한다.
30. 팀원에게 문서와 설계를 계속 설명하게 하면 프로젝트가 통제 불능으로 커지는 것을 막을 수 있다.
31. 리팩터링, 클린 코드, DDD, TDD는 중요하지만 항상 이력서의 메인 문제 소재는 아니다.
32. 네트워크, SOLID, DI/IoC 같은 기본기는 AI가 만든 코드를 통제하기 위해 필요하다.
33. 알고리즘과 CS를 강하게 보는 기업과 서비스 문제 해결을 중시하는 기업은 드러낼 증거가 다르다.
34. “정파와 사파”는 목표에 따른 전략 차이를 설명하는 즉흥적 비유이며 기본기를 포기하라는 뜻이 아니다.
35. Kafka를 부가 기능으로 썼다면 핵심 문제와 선택 이유를 분리해서 설명해야 한다.
36. 벡터 DB, RAG, LLM 연동은 백엔드 핵심 문제를 보완하는 기능으로 배치할 수 있다.
37. 서버와 메모리를 늘린 해결도 가능하지만 비용과 성능과 복잡도의 선택을 설명해야 한다.
38. 프로젝트 하나에서 문제 파악, 분석, 행동, 결과의 분명한 문장을 세 개 정도 준비하는 것이 좋다.
39. 이력서는 기술 목록이 아니라 문제와 근거와 결과가 이어지는 기록이어야 한다.
40. AI 시대의 백엔드 실력은 믿을 수 있는 증거로 바꾼 문제 해결의 기록으로 남는다.