Salesforce 개발자 면접 질문
Salesforce Developer를 위한 가장 흔한 면접 질문을 모아, 실제로 리크루터가 무엇을 보고 거르는지 기준으로 한 예시 답변과 준비 팁을 정리했습니다. 기술 채용 파이프라인이 더 빡빡해지고 2023년에는 면접까지 간 기술 후보자 중 오퍼로 전환된 비율이 일부에 그쳤던 시장에서는[2], 준비를 탄탄히 하는 것이 중요합니다. 그리고 무엇보다 먼저 면접까지 가기 위해, 해당 공고에 맞춘 이력서를 작성하는 것도 큰 차이를 만듭니다.
자주 나오는 Salesforce Developer 면접 질문
- Salesforce Developer로서 자기소개를 해주세요
- 왜 이 Salesforce Developer 포지션을 원하나요
- 어떤 Salesforce 클라우드와 플랫폼 기능을 다뤄봤나요
- 확장 가능한 Salesforce 솔루션은 어떻게 설계하나요
- Apex 대신 Flow를 언제 사용하나요
- 효율적인 Apex 코드는 어떻게 작성하나요
- Salesforce의 governor limit은 어떻게 대응하나요
- 유지보수성을 위해 Lightning Web Components를 어떻게 구조화하나요
- Salesforce 통합(Integration)은 어떤 방식으로 접근하나요
- 환경 간에 변경사항을 안전하게 배포하려면 어떻게 하나요
- Salesforce 코드는 어떻게 테스트하고 디버깅하나요
- 해결했던 어려운 Salesforce 버그 사례를 말해 주세요
- Salesforce 프로세스나 기능을 개선했던 경험을 말해 주세요
- 관리자(admin), 분석가, 이해관계자와는 어떻게 협업하나요
- 요구사항이 불명확하거나 충돌할 때는 어떻게 우선순위를 정하나요
- Salesforce에서 보안과 데이터 접근은 어떤 방식으로 설계하나요
- Salesforce 릴리즈와 베스트 프랙티스는 어떻게 최신 상태로 유지하나요
- Salesforce Developer로 일할 때 AI 도구는 어떻게 활용하나요
- AI가 생성한 코드나 제안을 믿기 전에 어떻게 검증하나요
- Salesforce Developer 포지션에 대해 저희에게 질문이 있나요
답변은 ‘해당 포지션’에 맞춰 구체화하세요. 같은 면접 질문이라도 채용 공고에 따라 요구되는 답변이 크게 달라질 수 있습니다. Salesforce Developer라면 플랫폼 아키텍처, Apex, LWC, 자동화의 트레이드오프, 통합, 이해관계자 커뮤니케이션을 강조해야지, 일반적인 소프트웨어 직무에서 쓰는 예시를 그대로 가져오면 안 됩니다. 더 체계적으로 연습하고 싶다면 ChatGPT로 연습하는 Salesforce Developer 면접 질문 가이드로 모의면접을 해보고, 행동 기반 사례는 Salesforce Developer 면접을 위한 STAR 기법으로 정리해 보세요.
Salesforce Developer 면접 질문과 답변 (상세)
1. Salesforce Developer로서 자기소개를 해주세요
리크루터는 이 질문으로 지원자가 명확하고 직무 관련성이 높은 커리어 스토리를 말할 수 있는지 확인합니다. 현재 레벨, Salesforce에서의 핵심 강점, 그리고 배경이 해당 역할과 빠르게 매칭되는지를 보고 싶어 합니다. 길게 늘어놓지 말고 “지금 어디에서 무엇을 하고 있는지, 무엇에 강점이 있는지, 어떤 문제를 푸는지”만 간결하게 말하세요.
예시 답변: 저는 Salesforce 플랫폼에서 깔끔하고 확장 가능한 솔루션을 만드는 데 집중하는 Salesforce Developer입니다. Apex, Lightning Web Components, Flow, 통합(Integration) 경험이 있고, 관리자와 비즈니스 이해관계자와 긴밀히 협업하면서 복잡한 요구사항을 유지보수 가능한 기능으로 정리해 구현해 왔습니다. 제가 특히 좋아하는 일은 과도한 설계 없이도 비즈니스 프로세스를 더 효율적으로 개선하는 것입니다.
2. 왜 이 Salesforce Developer 포지션을 원하나요
동기와 적합도를 확인하는 질문입니다. 리크루터는 지원자가 회사의 환경을 이해하고 있으며, 아무 데나 무작정 지원한 것이 아니라는 신호를 듣고 싶어 합니다. 가장 좋은 답변은 본인의 경험을 그들의 기술 스택, 도메인, 성장 단계와 연결합니다.
예시 답변: 이 포지션이 플랫폼 개발과 비즈니스 임팩트의 교차점에 있다는 점이 매력적입니다. 공고를 보면 팀이 Salesforce에서 자동화, 통합, 사용자 경험 개선을 추진하는 것으로 보이는데, 이는 제가 해왔고 즐기는 일과 잘 맞습니다. 특히 단순히 티켓만 처리하는 형태가 아니라, 개발자가 관리자와 이해관계자와 가까이 협업하는 팀에 합류하고 싶습니다.
3. 어떤 Salesforce 클라우드와 플랫폼 기능을 다뤄봤나요
실제 실무 경험이 그 회사 환경과 얼마나 맞는지 매핑하려는 질문입니다. 구체적으로 답하세요. 사용해 본 클라우드/도구/커스터마이징을 말하되, 얕게만 접한 영역을 깊게 한 것처럼 포장하지는 마세요.
예시 답변: 저는 Sales Cloud와 Service Cloud 경험이 가장 깊고, 커스텀 오브젝트, validation rule, record-triggered Flow, Apex, LWC, profile, permission set, 리포트 등을 꾸준히 사용해 왔습니다. 또한 REST API와 platform event를 통해 통합을 지원한 경험도 있습니다. 이전 직무에서는 케이스 관리 워크플로우를 개선하고, 내부 영업 사용자를 위한 커스텀 UI를 만드는 데 많은 시간을 썼습니다.
4. 확장 가능한 Salesforce 솔루션은 어떻게 설계하나요
“일단 되게 만들기”를 넘어 생각하는지 보는 질문입니다. 리크루터는 limit, 유지보수성, 데이터 볼륨, 보안, 관리자 사용성을 처음부터 고려하는 개발자를 원합니다.
예시 답변: 먼저 비즈니스 프로세스, 예상 데이터 볼륨, 사용자 그룹, 통합 요구를 명확히 합니다. 그다음 확장 가능한 범위에서 가장 단순한 해법을 선택합니다. 예를 들어 선언형 도구(declarative tool)가 맞으면 그걸 쓰고, 더 많은 제어/성능이 필요하면 Apex로 옮깁니다. 또한 bulkification, 테스트 용이성, 네이밍 기준, 그리고 추후 관리자가 어떻게 운영/지원할지까지 함께 고려합니다.
5. Apex 대신 Flow를 언제 사용하나요
판단력을 보는 질문입니다. 코딩부터 박는 습관이 아니라, 트레이드오프를 이해하는지 확인합니다. 좋은 Salesforce Developer는 선언형 자동화로 충분한 경우와, 코드가 정당화되는 경우를 구분합니다.
예시 답변: 로직이 비교적 단순하고 유지보수가 쉬우며, 관리자가 가시성을 갖는 것이 도움이 되는 경우에는 Flow를 씁니다. 예를 들면 표준 레코드 자동화, 승인(approval), 단계형 UI(가이드 화면) 같은 케이스입니다. 반대로 복잡한 로직, 실행 제어, 재사용 가능한 서비스, 또는 Flow로 구현하면 깨지기 쉬운 통합 처리 같은 경우에는 Apex를 선택합니다. 제 목표는 ‘전부 코딩’이 아니라 플랫폼과 팀에 맞는 도구를 고르는 것입니다.
6. 효율적인 Apex 코드는 어떻게 작성하나요
엔지니어링 기본기를 보려는 질문입니다. bulkification, 관심사 분리, 재사용 가능한 로직, 성능 감각을 어떻게 갖고 있는지 듣고 싶어 합니다.
예시 답변: 저는 먼저 bulk 작업을 기준으로 Apex를 설계합니다. 그래서 loop 안에서 SOQL/DML을 피하고, 컬렉션을 처리할 수 있게 메서드를 구성합니다. 또한 보통 트리거 로직을 handler와 service 레이어로 분리해 테스트/유지보수를 쉽게 만듭니다. 기능 완료로 보기 전에는 쿼리 selectivity, limit 소비량, 에러 처리까지 점검합니다.
7. Salesforce의 governor limit은 어떻게 대응하나요
플랫폼 핵심 질문입니다. Salesforce 개발에서 가장 큰 제약 중 하나를 이해하는지, 그리고 한계에 ‘사후 대응’이 아니라 ‘사전 설계’로 접근하는지를 확인합니다.
예시 답변: 저는 governor limit을 나중에 고치는 문제가 아니라 처음부터 설계에 반영합니다. 즉 트리거를 bulkify하고, 중복 쿼리를 줄이며, 가능한 작업을 집계하고, 적절한 경우 Queueable Apex 같은 비동기 처리를 사용합니다. 또한 배포 전에 현실적인 데이터 볼륨으로 테스트해 문제를 미리 잡습니다.
8. 유지보수성을 위해 Lightning Web Components를 어떻게 구조화하나요
프론트엔드 품질과 팀 확장성을 보는 질문입니다. LWC가 모듈화되어 있고 읽기 쉬우며 확장하기 쉬운지 확인합니다.
예시 답변: 저는 LWC를 하나의 명확한 책임에 집중시키고, 가독성이 좋아진다면 공용 로직을 유틸이나 자식 컴포넌트로 분리합니다. 가능하면 비즈니스 로직을 UI 레이어에서 분리하고, 일관된 네이밍을 쓰며, 상태(state) 처리를 예측 가능하게 유지하려고 합니다. Apex에 의존하는 컴포넌트라면 에러/로딩 상태와 테스트 커버리지를 특히 신경 써서 운영 환경에서 안정적으로 동작하게 만듭니다.
9. Salesforce 통합(Integration)은 어떤 방식으로 접근하나요
Salesforce Developer 역할에서 외부 시스템 연동은 흔하기 때문에 나오는 질문입니다. 데이터 계약, 장애 처리, 인증, 시스템 경계를 어떻게 다루는지 듣고 싶어 합니다.
예시 답변: 먼저 통합의 비즈니스 목적을 확인한 다음, 어떤 데이터가 언제 이동하는지, 각 필드는 어떤 시스템이 소유하는지를 정의합니다. 그 후 타이밍, 신뢰성, 규모에 따라 REST, platform event, 미들웨어, 배치 동기화 같은 패턴을 선택합니다. 통합은 실제로는 반드시 실패하기 때문에, 재시도, 로깅, 에러 가시성, 인증을 처음부터 설계에 포함합니다.
10. 환경 간에 변경사항을 안전하게 배포하려면 어떻게 하나요
릴리즈/배포 дисцип플린을 보려는 질문입니다. sandbox, 버전 관리, 테스트, change set 또는 CI/CD, 롤백 계획을 이해하는지 확인합니다.
예시 답변: 저는 버전 관리를 시작점으로 하고, 환경 간 승격(promotion) 흐름이 명확한 배포 프로세스를 선호합니다. 하위 환경에서 변경사항을 검증하고, 타깃/회귀 테스트를 실행하며, 의존성을 점검하고, 운영 배포 전에 데이터/메타데이터 전제 조건을 문서화합니다. 팀에 CI/CD가 있으면 활용하고, 없더라도 체크리스트와 롤백 플랜이 포함된 반복 가능한 프로세스를 갖추고 싶습니다.
11. Salesforce 코드는 어떻게 테스트하고 디버깅하나요
코드 품질 습관을 보는 질문입니다. 단순히 커버리지 수치만 맞추는 개발자가 아닌지 확인합니다.
예시 답변: 저는 커버리지 임계치만 채우기보다, 동작(behavior), 엣지 케이스, bulk 시나리오 중심으로 테스트를 작성합니다. 디버깅할 때는 로그와 재현 단계로 접근하고, 실패하는 분기나 데이터 조건을 격리해 원인을 좁힙니다. 그리고 기술적으로 백엔드 변경이 맞더라도 실제 업무 흐름을 깨뜨릴 수 있기 때문에, 사용자 관점에서도 테스트하는 편입니다.
12. 해결했던 어려운 Salesforce 버그 사례를 말해 주세요
끈기와 문제 해결 깊이를 보는 행동 질문입니다. 결국 답을 찾았는지보다, 불확실성 속에서 어떻게 사고하는지를 봅니다.
예시 답변: 한 번은 자동화가 어떤 경로에서는 정상 업데이트되는데 다른 경로에서는 실패하는, 간헐적인 이슈를 조사한 적이 있습니다. 특정 데이터 조건에서 문제를 재현한 뒤 실행 순서를 추적했고, Flow와 Apex 트리거가 같은 레코드에 동시에 작동하면서 결과가 충돌한다는 것을 찾았습니다. 저는 실행 경로를 재설계하고 실패 시나리오에 대한 테스트를 추가해 로직을 통합했고, 그 결과 해당 워크플로우에 대한 반복 지원 티켓이 사라지는 것으로 효과를 확인했습니다.
예시 답변(주니어라면): 샌드박스 프로젝트에서 일부 사용자에게 컴포넌트가 불완전한 데이터를 로딩하는 버그를 겪었습니다. field-level security, wire 동작, Apex 응답을 점검했고, 모든 profile에 동일한 접근 권한이 있다는 가정이 문제 원인임을 찾았습니다. 쿼리와 권한 모델을 맞추어 수정했고, 디버깅 초기에 보안 컨텍스트를 더 일찍 확인해야 한다는 점을 배웠습니다.
13. Salesforce 프로세스나 기능을 개선했던 경험을 말해 주세요
임팩트의 증거를 듣기 위한 질문입니다. 여기서는 정량적인 결과가 중요합니다. “도와줬다”로 끝내지 말고 무엇이 어떻게 좋아졌는지 설명하세요.
예시 답변: 수동 라우팅 때문에 시간을 낭비하던 영업팀을 위해 리드 배정 및 후속 조치 자동화를 개선했습니다. 깨지기 쉬운 규칙 묶음을 더 깔끔한 Flow로 바꾸고, 엣지 케이스는 타깃 Apex 로직으로 처리해, 수동 재배정 리드가 줄고 첫 접촉 시간이 빨라지는 것으로 배정 지연을 줄였습니다.
예시 답변(초기 커리어라면): 프로젝트 환경에서 불필요한 단계가 많은 케이스 접수 프로세스를 개선했습니다. 화면 Flow를 단순화하고 중복 필드를 제거해, 사용자 테스트 피드백 기준으로 클릭 수와 인수인계 혼선을 줄였습니다.
14. 관리자(admin), 분석가, 이해관계자와는 어떻게 협업하나요
Salesforce Developer는 혼자 일하는 경우가 드뭅니다. 기술과 비즈니스 사이를 번역할 수 있는지, 그리고 크로스펑셔널 파트너를 존중하는지 확인합니다.
예시 답변: 저는 먼저 원하는 비즈니스 결과를 명확히 하고, 기술적 의사결정은 보이되 이해 가능한 수준으로 공유할 때 협업이 가장 잘 된다고 느낍니다. 관리자에게는 운영 가능한 형태로 설계하려고 하고, 분석가/이해관계자와는 구현 전에 프로세스 세부사항, 엣지 케이스, 성공 지표를 확인합니다. 초기에 짧게라도 워크스루를 하면 이후 재작업이 크게 줄었습니다.
15. 요구사항이 불명확하거나 충돌할 때는 어떻게 우선순위를 정하나요
판단력을 보는 질문입니다. 멈춰버리는지, 추측으로 밀어붙이는지, 아니면 명확화를 주도하는지를 확인합니다.
예시 답변: 먼저 가정과 확정 요구사항을 분리하고, 사용자/매출/컴플라이언스/데드라인에 가장 큰 영향을 주는 요소를 파악합니다. 그다음 이해관계자에게 트레이드오프가 있는 ‘결정 지점’을 제시해, 끝없는 혼란이 아니라 선택을 하게 만듭니다. 필요하다면 불확실한 부분을 해결하는 동안에도 가치를 주는 작은 1차 릴리즈를 제안합니다.
16. Salesforce에서 보안과 데이터 접근은 어떤 방식으로 설계하나요
보안 질문은 리스크가 큰 개발자를 걸러내는 데 도움이 됩니다. 좋은 답변은 보안을 ‘나중에 붙이는 것’이 아니라 ‘처음부터 설계하는 것’으로 다룹니다.
예시 답변: 저는 보안을 정리 작업이 아니라 설계의 일부로 봅니다. 특히 커스텀 Apex나 통합이 들어가면, 오브젝트 접근, 필드 접근, 레코드 가시성, 실행 컨텍스트를 구현 전에 먼저 설계합니다. 또한 최소 권한 원칙을 선호하고, 비관리자 사용자로 테스트해 실제 사용자가 무엇을 보게 되는지 확인합니다.
17. Salesforce 릴리즈와 베스트 프랙티스는 어떻게 최신 상태로 유지하나요
지식이 낡았는지 보는 질문입니다. Salesforce는 계속 바뀌기 때문에, 실무적으로 학습을 지속하는 개발자를 선호합니다.
예시 답변: 저는 릴리즈 노트를 확인하고, 신뢰할 수 있는 Salesforce 기술 소스를 팔로우하며, 추천하기 전에 샌드박스에서 새 기능을 테스트합니다. 또한 새로운 기능이 있다고 해서 기존의 안정적인 프로세스를 무조건 대체해야 하는 것은 아니기 때문에, 현재 사용 중인 것과 비교해 실익을 평가합니다. 제 목표는 배지 수집이 아니라 ‘실무적으로 최신’인 상태를 유지하는 것입니다.
18. Salesforce Developer로 일할 때 AI 도구는 어떻게 활용하나요
이제 AI는 많은 개발 워크플로우에서 현실적인 도구라서, 생산적이고 책임감 있게 사용하는지 보기 위한 질문입니다. 유행어가 아니라 구체적인 사용 방식을 원합니다.
예시 답변: 저는 ChatGPT, GitHub Copilot, 때로는 Claude 같은 도구를 활용해 초안을 빠르게 만들 때가 많습니다. 특히 Apex 테스트 케이스, LWC 보일러플레이트, 정규식, 문서화, 다른 구현 대안 아이디어를 정리할 때 도움이 됩니다. 길게 늘어진 요구사항 스레드를 요약해서 더 명확한 기술 작업으로 바꾸는 데도 AI를 씁니다. 다만 아키텍처, 보안, 플랫폼 특화 의사결정은 결국 제가 책임지고 결정합니다.
19. AI가 생성한 코드나 제안을 믿기 전에 어떻게 검증하나요
AI 관련 질문 중 더 중요한 질문입니다. 기업은 AI를 쓰더라도 환각(hallucination)이나 약한 코드를 그대로 배포하지 않는 개발자를 원합니다.
예시 답변: 저는 AI 출력물을 기본값으로 신뢰하지 않습니다. Salesforce 문서, 플랫폼 한계, 보안 규칙, 실제 비즈니스 요구사항과 대조해 검증한 다음, 테스트를 실행하고 엣지 케이스를 확인한 뒤에야 채택합니다. AI는 속도를 높여주지만, 특히 Salesforce에서는 자신감 있는 오답이 실제 운영 장애로 이어질 수 있습니다.
20. Salesforce Developer 포지션에 대해 저희에게 질문이 있나요
형식적인 질문이 아닙니다. 리크루터는 이 질문으로 진지함, 시니어리티, 역할을 바라보는 사고방식을 판단합니다. 좋은 질문은 업무를 이해하고 성공 조건에 관심이 있다는 신호가 됩니다.
예시 답변: 네. 현재 팀에서 관리자와 개발자가 업무를 어떻게 분담하는지, 배포 프로세스가 어떤 형태인지, 그리고 향후 6~12개월 동안 가장 중요한 Salesforce 이니셔티브가 무엇인지 알고 싶습니다.
예시 답변: 또, 이 역할에서의 성공을 어떤 지표로 측정하는지도 여쭙고 싶습니다. 예를 들어 우선순위가 빠른 딜리버리인지, 플랫폼 안정성인지, 이해관계자 협업 개선인지, 아니면 기술 부채 감소인지가 궁금합니다.
행동 기반 답변을 더 날카롭게 만들고 싶다면, Salesforce Developer 면접에서 리크루터가 실제로 어떤 생각을 하는지를 이해하는 것이 도움이 됩니다. 그리고 지원 패키지가 아직 아쉽다면, 준비 과정에 타깃형 Salesforce Developer 커버레터를 함께 더하면 전체 퍼널에서 스토리가 더 탄탄해집니다.
Salesforce Developer 면접을 따내는 난이도는 얼마나 되나요
어려운 이유는 진짜 병목이 면접 이전에 있기 때문입니다.
Greenhouse의 2026 벤치마크 리포트에 따르면 6,000개+ 기업, 6억 4천만 건의 지원서를 기준으로 2025년에는 채용 공고 1건당 평균 지원서 수가 **244건(2025년)**까지 올라갔다고 합니다[1]. 2025–2026년 기준으로 Salesforce Developer에 한정된 “공고당 지원자 수” 벤치마크는 없지만, 전체 신호는 분명합니다. 관련 공고 하나에 수백 명이 몰릴 수 있고, 기술 채용은 더 타이트해졌습니다. Ashby의 2025 리포트도 2021년에서 2024년 사이 채용 1건당 지원서 수가 3배로 늘었고, 팀들은 2021년 대비 기술/비즈니스 직무에서 약 40% 더 많은 후보자를 인터뷰했다고 말합니다[2]. LinkedIn의 2026년 2월 소프트웨어 엔지니어 시장 데이터는, 2025년 말까지도 엔트리 레벨 소프트웨어 엔지니어 채용이 반등하지 않았고 시장이 AI와 거시적 압력에 적응 중이라고 덧붙입니다[3].
즉, 면접까지 갔다는 것 자체가 이미 거대한 필터를 통과했다는 뜻입니다. 그 기회를 낭비하지 마세요.
다만 아직 지원 단계에 있다면 교훈은 다릅니다. 가장 큰 병목은 ‘눈에 띄는 것’입니다. 이력서는 첫 번째 필터입니다. 5~8초 안에 “이 역할에 딱 맞는다”가 드러나지 않으면, 실력이 아무리 좋아도 존재하지 않는 것과 같습니다. 목표는 단순합니다: 지원서는 줄이고, 면접은 늘리는 것. 그리고 이는 지원할 때마다 이력서를 맞춤화하면 가능합니다.
지원할 때마다 이력서를 맞춤화해야 하는 이유
리크루터의 5~8초 스캔에서 ‘매칭이 명확한 이력서’는, 매번 범용 CV를 이깁니다. 모든 구직자가 이미 알고 있는 사실이죠.
진짜 문제는 노력(시간)입니다. 지원할 때마다 이력서를 다시 쓰는 일은 시간이 들고, 금방 반복 작업이 되며, 그래서 대부분은 제대로 맞춤화하지 않습니다. 예전에는 번거로운 일이었습니다. 이제는 AI가 대부분의 번거로운 작업을 해낼 수 있습니다.
Specific Resume는 Salesforce Developer 지원마다 맞춤형 이력서를 쉽게 만들 수 있게 해줍니다. 덕분에 1페이지에서 핵심 자격요건이 바로 보이게 하고, 공고 언어에 맞춰 표현을 정렬하고, 정량적 성과를 보여주며, ATS 친화성을 유지하고, 리크루터에게 “다음 단계로 넘길 이유”를 더 명확히 제공할 수 있습니다. 지원자에게도 좋고, 서류를 스크리닝하는 사람에게도 더 좋습니다.
매 지원을 1시간짜리 글쓰기 프로젝트로 만들지 않으면서 합격 확률을 높이고 싶다면, 지금 지원 중인 역할에 맞는 직무 맞춤형 이력서를 작성해 보세요.
다음 지원을 위한 더 좋은 Salesforce Developer 이력서 만들기
채용 퍼널은 잔인합니다. 지원서는 수백 건, 면접은 훨씬 적고, 오퍼는 소수입니다. 그러니 첫 번째 필터에 그만큼의 공을 들이세요.
면접 행운을 빕니다. 그리고 다음에 지원할 역할을 위해서는, Salesforce Developer로서의 적합성이 첫눈에 드러나는 이력서를 작성해 두세요.
출처
- Greenhouse. 6,000개+ 기업, 6억 4천만 건의 지원서를 다룬 2026 채용 벤치마크 리포트.
- Ashby. 기술 채용 퍼널 벤치마크와 면접-오퍼 전환 데이터가 포함된 2025 인재 트렌드 리포트.
- LinkedIn Economic Graph. 2026년 2월 발행, 미국 소프트웨어 엔지니어 인재 지형 리포트.
- LinkedIn Economic Graph. 2026년 2월 26일자, 채용 둔화 및 지원자 1인당 공고 수 관련 노동시장 업데이트.
