IT 컨설턴트 면접 질문: 모범 답변 예시와 준비 팁

다음은 IT 컨설턴트 직무에서 가장 자주 나오는 면접 질문들을, 실제로 채용 담당자가 무엇을 보고 걸러내는지에 기반한 예시 답변과 준비 팁과 함께 정리한 내용입니다. 채용 퍼널은 매우 빡빡합니다. 2024년 데이터에서 온라인 지원(인바운드) 지원자의 **오퍼율은 약 0.2%**에 불과했습니다[1]. 그래서 면접 단계까지 올라가는 것 자체가 이미 중요하고, Specific Resume는 그 과정에 도움이 되도록 직무에 맞춘 이력서를 작성할 수 있게 해줍니다.

IT 컨설턴트 면접에서 자주 나오는 질문

1. 자기소개를 해주세요
2. 왜 이 IT 컨설턴트 역할을 원하나요?
3. 저희 회사와 고객에 대해 무엇을 알고 있나요?
4. 왜 IT 컨설턴트로 당신을 채용해야 하나요?
5. 기술을 추천하기 전에 고객의 비즈니스 문제를 어떻게 이해하나요?
6. 어려운 이해관계자를 관리했던 경험을 말해 주세요
7. 여러 고객 프로젝트나 마감이 겹칠 때 우선순위를 어떻게 정하나요?
8. 고객을 위해 복잡한 기술 문제를 해결했던 경험을 설명해 주세요
9. 비기술 이해관계자에게 기술 개념을 어떻게 설명하나요?
10. 프로젝트가 계획에서 벗어났던 경험과 그때 어떻게 했는지 말해 주세요
11. 요구사항을 어떻게 수집하고 검증하나요?
12. 컨설팅 프로젝트에서 어떤 프레임워크/방법론/도구를 사용하나요?
13. 고객 팀의 변화 저항을 어떻게 다루나요?
14. 프로세스/시스템/구현 결과를 개선했던 경험을 말해 주세요
15. 기술적 실현 가능성, 비즈니스 가치, 예산을 어떻게 균형 있게 판단하나요?
16. 컨설팅 업무에 영향을 주는 기술 트렌드를 어떻게 최신으로 유지하나요?
17. IT 컨설턴트로서 업무에 AI 도구를 어떻게 활용하나요?
18. AI가 생성한 결과물을 신뢰하기 전에 어떻게 검증하나요?
19. IT 컨설턴트로서 본인의 가장 큰 강점은 무엇인가요?
20. 저희에게 질문이 있나요?

답변은 반드시 해당 직무에 맞게 커스터마이즈하세요. 같은 면접 질문이라도 직무에 따라 필요한 답변이 크게 달라질 수 있습니다. IT 컨설턴트라면 단순한 IT 경력 소개가 아니라, 고객 대면 문제 해결, 이해관계자 관리, 비즈니스 임팩트, 기술적 판단력을 강조해야 합니다. 답변 구조를 더 탄탄하게 만들고 싶다면 IT 컨설턴트 면접을 위한 STAR 기법과 IT 컨설턴트 면접에서 채용 담당자가 실제로 생각하는 것 가이드가 큰 도움이 됩니다.

IT 컨설턴트 면접 질문과 답변 상세

1. 자기소개를 해주세요

채용 담당자는 이 질문으로 당신이 경력을 명확하게 요약하고, 지원 직무에 맞게 본인을 포지셔닝할 수 있는지 봅니다. 자서전을 듣고 싶은 게 아니라, 핵심이 잡힌 커리어 스토리를 원합니다. IT 컨설턴트라면 기술적 깊이, 고객 업무 경험, 비즈니스 성과를 연결해 말하는 게 좋습니다.

예시 답변: 저는 비즈니스 니즈를 실무에 적용 가능한 기술 솔루션으로 번역하는 경험이 있는 IT 전문가입니다. 최근에는 시스템 개선을 지원하고, 기술/비기술 팀 전반에서 요구사항을 수집했으며, 운영 효율을 높이고 사용자 불편을 줄이는 프로젝트 납품을 도왔습니다. 이 역할에 특히 잘 맞는 점은 기술적인 부분만큼이나 컨설팅적인 부분—고객의 문제를 이해하고, 이해관계자를 정렬시키고, 사람들이 실제로 채택할 수 있는 형태로 해결책을 구현하는 것—을 즐긴다는 것입니다.

2. 왜 이 IT 컨설턴트 역할을 원하나요?

이 질문은 동기와 적합도를 봅니다. 채용 담당자는 당신이 컨설팅 환경을 이해하는지, 그리고 올바른 이유로 이 역할을 선택했는지 확인하고 싶어 합니다.

예시 답변: 이 역할은 비즈니스 문제, 기술, 고객 관계의 교차점에 있다는 점이 매력적입니다. 제가 가장 성과를 잘 내는 영역이기도 합니다. 저는 이슈를 진단하고 실용적인 해결책을 제안하며, 문서만 넘기는 게 아니라 팀이 실제로 변화를 구현하도록 돕는 역할을 좋아합니다. 또한 귀사의 업무는 자문과 딜리버리의 비중이 함께 있는 점이 눈에 띄었는데, 제가 계속 쌓아가고 싶은 컨설팅 경험과 정확히 맞습니다.

3. 저희 회사와 고객에 대해 무엇을 알고 있나요?

준비성을 확인하기 위해 묻습니다. 또한 회사의 시장, 딜리버리 방식, 고객이 겪을 가능성이 큰 페인 포인트를 이해하고 있는지 보고 싶어 합니다.

예시 답변: 제가 확인한 바로는 귀사는 기술을 ‘판매’하기보다, 기술 전환을 통해 고객의 운영을 개선하는 데 초점을 두는 것으로 보였습니다. 특히 구현과 이해관계자 정렬을 강조하는 점이 인상적이었는데, 이는 컨설턴트가 전략과 실행 사이를 연결해야 한다는 의미로 이해했습니다. 고객군을 고려하면 레거시 시스템, 프로세스 불일치, 도입(채택) 리스크, 빠르게 측정 가능한 ROI를 보여줘야 하는 압박 등이 흔한 과제일 것이라고 예상합니다.

4. 왜 IT 컨설턴트로 당신을 채용해야 하나요?

핵심은 당신의 가치 제안입니다. 채용 리스크를 낮추는 이유를 짧고 명확하게 듣고 싶어 합니다.

예시 답변: 저는 기술 이해도와 고객 커뮤니케이션 역량을 함께 갖추고 있습니다. 필요하면 디테일까지 들어갈 수 있지만, 동시에 한 발 물러나 실제 비즈니스 문제를 명확히 하고 이해관계자를 정렬시키는 방법도 압니다. 저는 구조적으로 일하고, 압박 상황에서도 침착하며, 실제 구현 가능한 권고안에 집중합니다. 컨설팅에서는 ‘좋은 아이디어’도 고객이 실제로 사용할 수 있어야 의미가 있기 때문에, 이 부분이 특히 중요하다고 생각합니다.

5. 기술을 추천하기 전에 고객의 비즈니스 문제를 어떻게 이해하나요?

컨설팅의 핵심 질문입니다. 채용 담당자는 당신이 도구부터 성급하게 고르는지, 아니면 진단부터 시작하는지 확인합니다.

예시 답변: 저는 먼저 비즈니스 목표, 현재의 페인 포인트, 그리고 성공의 기준이 무엇인지부터 명확히 합니다. 그다음 해결책을 이야기하기 전에 현재 프로세스, 이해관계자, 시스템, 제약조건을 매핑합니다. 보통 ‘지금은 어떤 일이 벌어지고 있는지’, ‘어디서 깨지는지’, ‘문제 비용이 얼마나 되는지’, ‘조직이 감당할 수 있는 변화 범위는 어디까지인지’를 묻습니다. 이렇게 해야 겉보기엔 좋아 보이지만 조직에 맞지 않는 기술을 추천하는 실수를 피할 수 있습니다.

6. 어려운 이해관계자를 관리했던 경험을 말해 주세요

컨설팅에서는 이해관계자 마찰이 흔하기 때문에 묻습니다. 방어적으로 대응하지 않고 긴장을 관리할 수 있는지에 대한 증거를 원합니다.

예시 답변: 한 프로젝트에서 부서 리더가 시스템 변경에 강하게 반발했는데, 새로운 워크플로우가 팀 속도를 떨어뜨릴 거라고 느꼈기 때문입니다. 저는 큰 회의에서 논쟁으로 이기려 하기보다, 별도 세션을 잡아 우려를 디테일하게 이해하려고 했습니다. 확인해보니 저항의 원인은 리포팅 단계 하나가 실제로 설계가 좋지 않았던 것이었습니다. 해당 부분을 조정하고, 팀에 미치는 영향을 문서화한 뒤, 롤아웃에 대한 지지를 얻었습니다. 핵심은 저항을 ‘반대’가 아니라 ‘정보’로 다루는 것이었습니다.

7. 여러 고객 프로젝트나 마감이 겹칠 때 우선순위를 어떻게 정하나요?

조직력과 판단력을 봅니다. 채용 시장이 빡빡해지면서 기업은 과거보다 채용 1건당 더 많은 후보자를 검토하고 있어, 실행 리스크가 낮은 사람인지 더 꼼꼼히 봅니다[2].

예시 답변: 저는 비즈니스 임팩트, 딜리버리 리스크, 그리고 의존관계(디펜던시)를 기준으로 우선순위를 정합니다. 먼저 마감이 고정된 항목이 무엇인지, 어떤 작업이 다른 작업을 막고 있는지, 어떤 이해관계자의 기대치를 적극적으로 관리해야 하는지를 파악합니다. 그다음 일을 단기 산출물로 쪼개고, 트레이드오프가 필요하면 조기에 커뮤니케이션합니다. 특히 여러 고객이 ‘내 이슈가 최우선’이라고 느끼는 상황에서는, 작업 관리만큼이나 기대치 설정이 중요하다고 경험했습니다.

8. 고객을 위해 복잡한 기술 문제를 해결했던 경험을 설명해 주세요

개념적으로 말만 하는 사람이 아니라, 모호함을 다루고 결과를 내는 사람인지 증명하길 원합니다.

예시 답변: 한 고객사에서 핵심 시스템 2개 사이 데이터 불일치가 반복 발생해 리포팅 오류와 수작업 재처리가 생기고 있었습니다. 저는 필드 매핑을 추적하고, 예외 로그를 검토하며, 운영팀과 기술팀 모두를 인터뷰해 원인을 진단했습니다. 매핑 로직을 재설계하고 검증 규칙을 강화했으며 간단한 모니터링 대시보드를 추가해, 월별 예외 발생량 기준으로 정합성 오류를 60% 줄였습니다.

9. 비기술 이해관계자에게 기술 개념을 어떻게 설명하나요?

커뮤니케이션, 공감, 영향력에 관한 질문입니다. 뛰어난 컨설턴트는 ‘똑똑해 보이는 것’보다 ‘명확한 것’이 더 중요하다는 걸 압니다.

예시 답변: 저는 아키텍처보다 비즈니스 임팩트부터 시작합니다. 시스템이 어떻게 동작하는지 기술 디테일로 설명하기보다, 무엇을 해결하는지, 사용자에게 무엇이 바뀌는지, 어떤 리스크가 있는지, 어떤 의사결정이 필요한지를 설명합니다. 또한 중간중간 이해도를 확인하고, 청중에 맞춰 언어를 조정합니다. 임원에게는 트레이드오프만 필요하므로 하이레벨로, 운영 리드에게는 워크플로우 디테일이 필요하므로 더 깊게 들어갑니다.

10. 프로젝트가 계획에서 벗어났던 경험과 그때 어떻게 했는지 말해 주세요

압박 상황에서의 대응을 봅니다. 책임감, 문제 해결, 커뮤니케이션을 확인합니다.

예시 답변: 한 번은 구현 단계 후반에 핵심 요구사항을 두 팀이 서로 다르게 해석하고 있었다는 사실을 늦게 발견해 일정이 위험해졌습니다. 저는 이해관계자를 모아 의사결정 포인트를 명확히 하고, 임팩트가 가장 큰 산출물부터 우선순위를 재설정해 계획을 리셋했습니다. 1단계 범위를 축소하고, 오너십을 명확히 문서화하며, 마지막 스프린트 동안 체크인을 늘려, 수정된 마일스톤 계획 대비 프로젝트 일정을 2주 회복했습니다.

11. 요구사항을 어떻게 수집하고 검증하나요?

핵심 딜리버리 역량입니다. 즉흥이 아니라 방법론이 있는지 봅니다.

예시 답변: 저는 이해관계자 인터뷰, 프로세스 워크스루, 기존 문서, 시스템 관찰, 데이터 예시 등 다양한 소스에서 요구사항을 수집합니다. 그다음 일반적인 언어로 요구사항을 되짚어 확인하고, 가정을 문서화하며, 설계가 시작되기 전에 엣지 케이스를 확인하는 방식으로 검증합니다. 또한 ‘원하는 것(want)’과 ‘필요한 것(need)’을 분리하려고 합니다. 고객은 종종 선호 솔루션을 설명하지만, 우리가 진짜 알아야 하는 건 그 아래의 문제이기 때문입니다.

12. 컨설팅 프로젝트에서 어떤 프레임워크/방법론/도구를 사용하나요?

일하는 방식이 어떤지 파악하기 위해 묻습니다. 반복 가능한 접근법과 표준 딜리버리 관행에 대한 익숙함을 찾습니다.

예시 답변: 저는 프로젝트에 맞게 접근을 조정하지만, 애자일 및 하이브리드 딜리버리 모델, 표준 요구사항 문서화, 프로세스 매핑, 리스크 로그, 이해관계자 커뮤니케이션 플랜과 같은 방식에 익숙합니다. 도구 측면에서는 계획 수립, 문서화, 이슈 트래킹을 위한 일반적인 프로젝트/협업 플랫폼들을 사용해왔습니다. 제게 가장 중요한 건 방법론을 위한 방법론을 강요하는 게 아니라, 고객이 의사결정을 내릴 수 있게 돕고 딜리버리가 앞으로 나가게 만드는 구조를 선택하는 것입니다.

13. 고객 팀의 변화 저항을 어떻게 다루나요?

변화관리 성숙도를 보는 질문입니다. 도입(채택)을 ‘남의 문제’로 취급하면 컨설팅은 실패합니다.

예시 답변: 저는 저항의 아래에 무엇이 있는지 먼저 이해하려고 합니다. 어떤 경우엔 명확성 부족이고, 어떤 경우엔 업무 증가에 대한 두려움이며, 또 어떤 경우엔 제안된 설계에 대한 타당한 우려일 수 있습니다. 저는 적절한 사용자를 초기에 참여시키고, 변화가 일상 업무에 어떤 영향을 주는지 보여주며, 트레이드오프를 솔직하게 설명하는 방식으로 대응합니다. 사람들은 자신의 의견이 반영되고, 변화의 이유가 구체적일수록 변화를 지지할 가능성이 높습니다.

14. 프로세스/시스템/구현 결과를 개선했던 경험을 말해 주세요

컨설팅은 측정 가능한 개선을 만드는 일이기 때문에 묻습니다. 업무 나열이 아니라 ‘결과’로 말해야 합니다.

예시 답변: 이전 프로젝트에서 지원팀과 엔지니어링팀 사이 인수인계가 일관되지 않아 지연과 중복 작업이 발생했습니다. 저는 인입 워크플로우를 재설계하고, 에스컬레이션 기준을 표준화하며, 공동 트리아지 체크리스트를 만들어, 분기 기준으로 첫 응답 단계에서의 해결률을 25% 개선했습니다. 그 결과 양 팀 모두 더 명확한 프로세스를 갖게 되었고 불필요한 핑퐁 커뮤니케이션이 줄었습니다.

예시 답변(경력이 초기라면): 프로젝트 과제 수행 중 테스트 결함이 서로 다른 형식으로 등록되어 분석이 어려운 것을 발견했습니다. 스프린트 회고를 기준으로 리뷰 시간을 30% 줄였는데, 단일 결함 템플릿과 간단한 분류 체계를 만들어 반복 이슈를 더 쉽게 발견할 수 있게 했기 때문입니다.

15. 기술적 실현 가능성, 비즈니스 가치, 예산을 어떻게 균형 있게 판단하나요?

컨설팅에서의 판단력을 묻는 질문입니다. 고용주는 그럴듯하기만 한 제안이 아니라, 신뢰할 수 있고 현실적이며 상업적으로도 타당한 권고안을 원합니다.

예시 답변: 저는 이 세 가지를 각각 따로 논의하기보다, 하나의 의사결정 프레임워크로 봅니다. 보통 가치, 구현 노력, 리스크, 일정, 비용을 기준으로 옵션을 비교하고, 고객의 목표와 제약에 가장 맞는 경로를 추천합니다. 기술적으로 최고의 솔루션이라도 채택이 느리거나 비용 정당화가 어려우면 정답이 아닐 수 있습니다. 좋은 컨설팅은 가장 ‘인상적인’ 옵션이 아니라, 가장 강력한 ‘현실적인’ 옵션을 찾는 것입니다.

16. 컨설팅 업무에 영향을 주는 기술 트렌드를 어떻게 최신으로 유지하나요?

최신 동향을 따라가고 상업적 감각이 있는지 보기 위해 묻습니다. 2024년 전후 데이터에서 기술 직무 지원자 수가 급증한 시장에서는[3], 최신 지식이 차별화에 도움이 됩니다.

예시 답변: 저는 벤더 업데이트, 업계 뉴스레터, 직접 테스트, 동료들과의 대화를 섞어서 최신 동향을 따라갑니다. 유행(hype)보다는 고객에게 딜리버리/비용/리스크/사용자 경험 측면에서 무엇이 바뀌는지에 더 초점을 둡니다. 새로운 기술이 관련 있어 보이면, 고객 권고안에 반영하기 전에 어디에 진짜로 फिट하는지, 어디에는 맞지 않는지, 어떤 트레이드오프를 만드는지부터 이해하려고 합니다.

17. IT 컨설턴트로서 업무에 AI 도구를 어떻게 활용하나요?

IT 컨설턴트 역할에서는 이제 현실적인 질문입니다. 채용 담당자는 유행어가 아니라 실무 활용을 원합니다.

예시 답변: 저는 AI를 판단을 대체하는 도구가 아니라, 속도를 높이는 가속기로 사용합니다. 일상 업무에서는 ChatGPT나 Copilot 같은 도구로 워크숍 아젠다 초안을 빠르게 만들거나, 회의 노트를 요약하거나, 요구사항 테마를 비교하거나, 문서 구조를 잡는 데 활용합니다. 기술 업무에서는 예시 쿼리를 생성하거나, 통합 옵션을 아웃라인하거나, 엣지 케이스를 상식선에서 점검하는 데 AI를 쓸 수 있습니다. 다만 최종 권고안은 항상 고객 맥락, 시스템 제약조건, 그리고 제 검토에 기반해 확정합니다.

18. AI가 생성한 결과물을 신뢰하기 전에 어떻게 검증하나요?

성숙도를 보는 질문입니다. AI의 한계를 이해하고 품질을 지킬 수 있는지 확인합니다.

예시 답변: 저는 AI 결과물을 주니어 애널리스트의 조언을 검증하듯 확인합니다. 사실 관계를 점검하고, 논리를 테스트하고, 실제 프로젝트 맥락에 비춰 검토합니다. 기술 제안을 내놓으면 공식 문서, 알려진 제약조건, 실제 데이터로 검증합니다. 비즈니스 정보를 요약했다면 원본 노트와 대조하고 핵심 가정은 이해관계자에게 재확인합니다. AI는 속도 면에서 유용하지만, 유창한 출력이 정확한 출력이라고 보진 않습니다.

19. IT 컨설턴트로서 본인의 가장 큰 강점은 무엇인가요?

본인이 자신의 가치를 어떻게 정의하는지 듣고 싶어 합니다. 직무에 중요한 강점 하나를 고르고 근거를 들어야 합니다.

예시 답변: 제 가장 큰 강점은 비즈니스 팀과 기술 팀 사이를 핵심 이슈를 잃지 않고 번역해 주는 능력입니다. 저는 복잡하고 정리되지 않은 상황에서 중요한 포인트를 명확히 하고, 사람들을 실용적인 해결책으로 움직이게 만드는 데 강합니다. 그 덕분에 오해나 모호한 요구사항 때문에 의사결정이 막히는 일이 줄어 프로젝트가 더 빠르게 진전됩니다.

20. 저희에게 질문이 있나요?

절대 덤으로 묻는 질문이 아닙니다. 준비성, 시니어리티, 그리고 역할을 어떻게 바라보는지를 보여줍니다.

예시 답변: 네. 이 역할에서 ‘첫 6개월을 성공적으로 보냈다’고 판단하는 기준이 무엇인지, 이 팀이 가장 자주 해결하러 투입되는 고객 문제 유형이 무엇인지, 그리고 신규 컨설턴트가 보통 어떤 영역에서 가장 빠르게 가치를 내는지 알고 싶습니다. 또한 자문 업무와 구현 지원의 균형을 어떻게 가져가는지도 궁금합니다.

IT 컨설턴트 면접을 따내는 건 얼마나 어려운가요?

채용 퍼널에서 가장 어려운 구간은 종종 면접이 아닙니다. **처음부터 ‘보이는 것’**이 더 어렵습니다.

LinkedIn은 2026년 1월에 미국에서 채용 공고 1건당 지원자 수가 2022년 봄 이후 두 배가 됐다고 보고했습니다[4]. IT 컨설턴트 지원자에게도 이는 퍼널 상단의 현실입니다. 채용 담당자가 당신의 스토리를 읽기도 전에 경쟁이 더 심해진 겁니다. 게다가 한 번 흐름을 타도 과정은 여전히 까다롭습니다. Ashby는 2024년에 채용 팀이 2021년 대비 채용 1건당 약 40% 더 많은 후보자를 면접했다고 보고했습니다[2].

그래서 이렇게 정리할 수 있습니다. 이미 면접이 잡혔다면, 큰 필터 하나를 통과한 겁니다. 그 기회를 낭비하지 마세요. 하지만 아직 지원 단계라면 진짜 병목은 더 앞에 있습니다. 첫 번째 필터는 이력서이고, 채용 담당자는 보통 5–8초 만에 판단합니다. 적합도가 즉시 보이지 않으면, 아무리 자격이 좋아도 존재하지 않는 것과 같습니다. 목표는 간단합니다. 지원서는 줄이고, 면접은 늘리는 것. 그리고 이는 매 지원마다 이력서를 맞춤화하면 가능합니다.

모든 지원서에 이력서를 맞춤화해야 하는 이유

채용 담당자의 5–8초 스캔에서 ‘이 직무와 딱 맞다’는 게 바로 보이는 이력서는, 매번 범용 CV를 이깁니다. 이건 누구나 알고 있습니다.

문제는 노력(시간)입니다. 지원할 때마다 이력서를 다시 쓰는 건 느리고, 반복적이고, 미루기 쉽습니다. 그래서 대부분의 사람은 중요하다는 걸 알면서도 실제로는 잘 못 합니다.

이제 Specific Resume를 사용하면 직무별 맞춤 이력서를 훨씬 쉽게 만들 수 있습니다. 1페이지에 꼭 필요한 자격요건을 먼저 배치하고, 채용공고의 언어와 맞추고, 빠르게 스캔하기 쉬운 레이아웃을 유지하며, ATS 친화성을 지키고, 업무 나열이 아닌 성과 중심으로 정리할 수 있게 도와줍니다. 지원자에게도 좋고 채용 담당자에게도 좋습니다. 덜 파고들어도 되고, 더 명확하니까요. 함께 제출할 지원 서류가 필요하다면, 집중도 높은 IT 컨설턴트 커버레터도 같이 준비해 보세요.

범용 지원에서 타겟팅 지원으로 바꾸고 싶다면, 작성해서 직무별 이력서를 만들고, 당신의 적합도를 빠르게 확실하게 보여주세요.

다음 지원을 위한 더 좋은 IT 컨설턴트 이력서 만들기

퍼널은 잔인합니다. 지원은 많고, 면접은 적고, 오퍼는 더 적습니다. 그래서 이력서를 ‘중요한 것’처럼 다루세요. 실제로 중요하니까요.

면접 행운을 빕니다. 그리고 다음에 지원하는 역할에서는, 그 단계까지 갈 수 있게 도와주는 직무별 이력서를 생성해 보세요. 실제 면접 전에 ChatGPT로 IT 컨설턴트 면접 질문을 연습하기도 할 수 있습니다.

출처

1. Ashby. 2025년 5월 인재 트렌드 보고서(추천 및 인바운드 지원 오퍼율). 93,000개 채용 공고에 대한 3,800만 건의 지원 데이터를 기반으로 함.
2. Ashby. 2025년 채용 담당자 생산성 보고서. 비즈니스 및 기술 직무 전반에서 2024년 채용 1건당 면접 규모를 다룸.
3. Ashby. 채용 공고 1건당 지원 수에 대한 2024년 2월 업데이트. 2021년 1월부터 2024년 1월까지 기술 직무에서 2.6배 성장 포함.
4. LinkedIn News. 2026년 1월 LinkedIn 리서치. 미국에서 채용 공고 1건당 지원자 수가 2022년 봄 이후 두 배가 됐다고 보고.