298 lines
19 KiB
Markdown
298 lines
19 KiB
Markdown
# IT 직무별 공고 요구와 경험 근거 매핑
|
|
|
|
이 문서는 채용 공고의 키워드를 자소서에 반복하는 대신, 사용자가 실제로 한 행동과 산출물로 요구 역량을 입증하기 위한 기준이다. 경력 수준을 부풀리지 말고 신입에게 가능한 경험도 동등하게 탐색하라.
|
|
|
|
## 목차
|
|
|
|
1. 공통 매핑 절차
|
|
2. 근거의 품질과 신입 경험 활용
|
|
3. 백엔드
|
|
4. 프론트엔드
|
|
5. 모바일
|
|
6. 데이터·AI
|
|
7. 인프라·DevOps
|
|
8. 보안
|
|
9. QA
|
|
10. Product·PM
|
|
11. 과장 방지 규칙
|
|
12. 트레이드오프 질문 모음
|
|
|
|
## 1. 공통 매핑 절차
|
|
|
|
### 1단계: 공고를 원자 단위 요구로 나누기
|
|
|
|
공고 문장을 그대로 복사하지 말고 다음으로 분류한다.
|
|
|
|
- **업무**: 입사 후 실제로 수행할 일
|
|
- **필수 역량**: 없으면 업무 수행이 어려운 지식·경험
|
|
- **우대 역량**: 있으면 도움이 되지만 필수가 아닌 경험
|
|
- **환경·제약**: 트래픽, 데이터 민감도, 협업 구조, 배포 주기, 규제 등
|
|
- **행동 특성**: 문제 정의, 협업, 학습, 문서화 등
|
|
|
|
“Java/Spring 사용 가능”처럼 넓은 문구는 `API 설계`, `데이터 정합성`, `예외 처리`, `테스트`, `배포 후 관찰`처럼 실제 업무 장면으로 다시 나눈다. 단, 공고에 없는 세부 역량을 회사가 반드시 요구한다고 단정하지 않는다.
|
|
|
|
### 2단계: 각 요구를 관찰 가능한 근거로 바꾸기
|
|
|
|
다음 여섯 요소 중 최소 세 가지가 있는 경험을 우선한다.
|
|
|
|
| 요소 | 확인 질문 |
|
|
|---|---|
|
|
| 행동 | 본인이 실제로 설계·구현·분석·조정한 것은 무엇인가? |
|
|
| 산출물 | 코드, 테스트, 문서, 대시보드, 실험 기록, 이슈 등 무엇이 남았는가? |
|
|
| 소유 범위 | 개인 결정, 공동 결정, 보조 역할을 어떻게 구분할 수 있는가? |
|
|
| 제약 | 시간, 데이터, 비용, 성능, 안정성, 사용성 중 무엇이 제한이었는가? |
|
|
| 선택·절충 | 어떤 대안을 비교했고 무엇을 얻거나 포기했는가? |
|
|
| 결과 | 전후 수치나 관찰 가능한 변화는 무엇인가? |
|
|
|
|
도구 이름만 일치하는 경험은 약한 근거다. 예를 들어 “Docker를 사용했다”보다 “개발 환경 차이로 생기던 재현 문제를 줄이기 위해 이미지와 실행 조건을 고정하고 팀원이 같은 절차로 실행하게 했다”가 더 관찰 가능하다.
|
|
|
|
### 3단계: 근거 카드를 만든다
|
|
|
|
각 공고 요구마다 다음 형식으로 한 줄을 만든다.
|
|
|
|
> 공고 요구 → 관련 사건 → 본인 행동·산출물 → 선택 기준·제약 → 확인된 결과 → 남은 한계
|
|
|
|
예:
|
|
|
|
> 데이터 정합성 → 중복 주문 생성 → 멱등 키와 DB 고유 제약을 비교하고 테스트 추가 → 애플리케이션 로직만으로는 동시 요청을 막기 어려움 → 같은 동시성 테스트에서 중복 행이 생기지 않음을 확인 → 실제 대규모 트래픽 검증은 하지 않음
|
|
|
|
### 4단계: 가장 강한 근거만 선택한다
|
|
|
|
- 필수 업무와 직접 연결되는 경험을 우선한다.
|
|
- 하나의 경험이 여러 요구를 입증할 수 있어도 문항에서 중심 역량은 한두 개만 둔다.
|
|
- 약한 근거를 기술명 나열로 보완하지 않는다.
|
|
- 요구 근거가 없으면 “학습 중”, “개인 환경에서 실습”처럼 현재 수준을 정확히 표시하거나 다른 강점을 선택한다.
|
|
|
|
## 2. 근거의 품질과 신입 경험 활용
|
|
|
|
### 근거 강도
|
|
|
|
| 수준 | 설명 | 사용 방식 |
|
|
|---|---|---|
|
|
| A | 코드·기록·결과물과 본인 역할을 설명할 수 있음 | 핵심 근거로 사용 |
|
|
| B | 구체적인 과정은 기억하지만 산출물이나 수치가 제한적임 | 범위를 좁혀 사용 |
|
|
| C | 기술을 배웠거나 따라 해 봤으나 독립적인 판단이 거의 없음 | 학습 출발점으로만 사용 |
|
|
| D | 해 보지 않았거나 기억이 불확실함 | 사실처럼 사용하지 않음 |
|
|
|
|
### 신입에게 사용할 수 있는 경험
|
|
|
|
- 전공·부트캠프 수업, 캡스톤, 팀 과제
|
|
- 개인 프로젝트, 홈랩, 포트폴리오, 기술 회고
|
|
- 해커톤, 공모전, 오픈소스 이슈·문서·코드 기여
|
|
- 연구실·학부 연구, 데이터 분석 과제, 논문 재현
|
|
- 동아리·학생회·스터디 운영, 행사 기획
|
|
- 인턴·현장실습·아르바이트에서의 작은 개선
|
|
- 비IT 아르바이트의 고객 문제 파악, 절차 개선, 협업 경험
|
|
- 실패한 프로젝트에서 남은 원인 분석과 이후 수정
|
|
|
|
수업·개인 환경의 경험도 유효하지만 상용 서비스 운영 경험으로 바꾸어 말하지 않는다. 사용자 수가 적어도 요구를 정의하고 선택을 검증한 과정이 선명하면 근거가 된다.
|
|
|
|
## 3. 백엔드
|
|
|
|
### 공고 요구를 근거로 바꾸기
|
|
|
|
| 공고 신호 | 관찰 가능한 근거 |
|
|
|---|---|
|
|
| API 설계·서버 개발 | 엔드포인트와 오류 규약 정의, 입력 검증, API 문서, 통합 테스트 |
|
|
| DB·SQL·데이터 모델링 | 스키마와 관계 설계, 마이그레이션, 실행 계획 확인, 인덱스 선택, 정합성 제약 |
|
|
| 성능·확장성 | 병목을 측정한 조건, 캐시·쿼리·동시성 대안 비교, 부하 테스트 결과와 한계 |
|
|
| 안정성·트랜잭션 | 실패 경로, 재시도·멱등성, 트랜잭션 경계, 장애 재현, 복구 또는 롤백 절차 |
|
|
| 테스트·운영 | 단위·통합 테스트, 로그·메트릭 추가, 배포 체크리스트, 재발 방지 문서 |
|
|
|
|
신입 경험으로는 팀 프로젝트 API, 게시판·예약·주문 서비스, DB 과제, 오픈소스 버그 수정, 개인 서버 배포를 사용할 수 있다. 단순 CRUD라면 예외 처리, 동시 요청, 스키마 변경, 테스트 전략 중 실제로 판단한 지점을 찾는다.
|
|
|
|
심층 질문:
|
|
|
|
- 데이터 정합성과 구현 단순성이 충돌했을 때 무엇을 선택했나요?
|
|
- 캐시나 비동기 처리를 넣기 전 병목을 어떻게 확인했나요?
|
|
- 트랜잭션 범위를 넓히거나 좁힐 때 각각 어떤 문제가 생기나요?
|
|
- 현재 구조가 더 큰 트래픽이나 장애 조건에서 실패한다면 어디일까요?
|
|
|
|
## 4. 프론트엔드
|
|
|
|
### 공고 요구를 근거로 바꾸기
|
|
|
|
| 공고 신호 | 관찰 가능한 근거 |
|
|
|---|---|
|
|
| UI 구현·컴포넌트 설계 | 화면을 컴포넌트로 나눈 기준, 재사용 범위, 디자인 명세와 실제 구현 비교 |
|
|
| 상태·데이터 흐름 | 서버·클라이언트 상태 구분, 로딩·오류·빈 상태 처리, 캐시 무효화 판단 |
|
|
| 성능 | 렌더링·번들·네트워크 병목 측정, 변경 전후 조건, 사용자 체감과 복잡성의 균형 |
|
|
| 접근성·호환성 | 키보드 이동, 의미 있는 마크업, 화면 크기·브라우저별 확인 기록 |
|
|
| 품질·협업 | 컴포넌트 테스트, E2E 시나리오, 디자인·백엔드와의 인터페이스 합의, 오류 모니터링 |
|
|
|
|
신입 경험으로는 포트폴리오 웹, 팀 프로젝트, 디자인 시스템 실습, 기존 화면 리팩터링, 접근성 점검, 사용자 테스트를 활용할 수 있다. 화면을 “예쁘게 만들었다”보다 어떤 사용 문제를 발견하고 어떤 상호작용을 바꿨는지 확인한다.
|
|
|
|
심층 질문:
|
|
|
|
- 재사용성을 높이면서 개별 화면의 단순성을 얼마나 포기했나요?
|
|
- 전역 상태와 지역 상태를 나눈 기준은 무엇이었나요?
|
|
- 빠른 첫 화면, 최신 데이터, 구현 복잡성 중 무엇을 우선했나요?
|
|
- 접근성이나 반응형 요구를 일정 안에서 어떤 순서로 처리했나요?
|
|
|
|
## 5. 모바일
|
|
|
|
### 공고 요구를 근거로 바꾸기
|
|
|
|
| 공고 신호 | 관찰 가능한 근거 |
|
|
|---|---|
|
|
| 앱 기능·화면 개발 | 화면 전환, 상태 보존, 입력·권한·오류 처리, UI 테스트 |
|
|
| 네트워크·오프라인 | 끊김·재시도·중복 요청 처리, 로컬 저장과 동기화 규칙, 충돌 처리 |
|
|
| OS·기기 대응 | 버전·화면 크기·권한 차이를 확인한 테스트 매트릭스와 수정 내역 |
|
|
| 성능·자원 | 시작 시간, 렌더링, 메모리, 배터리·백그라운드 제약을 측정하거나 점검한 기록 |
|
|
| 배포·품질 | 빌드 설정, 서명·버전 관리, 베타 테스트, 크래시 원인 분석, 출시 체크리스트 |
|
|
|
|
신입 경험으로는 수업 앱, 개인 앱, 해커톤 프로토타입, 베타 배포, 오픈소스 모바일 프로젝트 기여를 쓸 수 있다. 앱 스토어에 올리지 않았다면 “출시”라고 하지 말고 테스트·배포 범위를 밝힌다.
|
|
|
|
심층 질문:
|
|
|
|
- 네이티브와 크로스플랫폼 또는 특정 라이브러리를 선택한 제약은 무엇이었나요?
|
|
- 오프라인 데이터의 최신성과 사용 가능성 중 무엇을 우선했나요?
|
|
- 다양한 기기 대응과 개발 속도 사이에서 테스트 범위를 어떻게 정했나요?
|
|
- 백그라운드 작업이나 권한 거부 상황에서 어떤 경험을 제공하려 했나요?
|
|
|
|
## 6. 데이터·AI
|
|
|
|
### 공고 요구를 근거로 바꾸기
|
|
|
|
| 공고 신호 | 관찰 가능한 근거 |
|
|
|---|---|
|
|
| 데이터 수집·정제 | 데이터 출처, 스키마, 결측·이상치 처리 기준, 품질 검사와 재현 가능한 파이프라인 |
|
|
| 분석·실험 | 질문과 가설, 기준선, 평가 지표 선택, 실험 분리, 결과 해석과 한계 |
|
|
| 모델 개발 | 문제 정의, 데이터 분할, 특성·모델 대안 비교, 오류 사례 분석, 누수 방지 |
|
|
| 서빙·MLOps | 추론 API·배치 작업, 버전 관리, 재현 환경, 지연 시간·비용, 모니터링 설계 |
|
|
| 의사결정 지원 | 분석 결과가 바꾼 제품·운영 판단, 시각화·문서, 이해관계자 피드백 |
|
|
|
|
신입 경험으로는 공개 데이터 분석, 대회, 논문 재현, 연구실 과제, 추천·분류 모델 개인 프로젝트, 데이터 파이프라인 구축을 활용할 수 있다. 리더보드 점수만 쓰지 말고 기준선, 검증 방식, 오류 분석, 재현성을 함께 묻는다.
|
|
|
|
심층 질문:
|
|
|
|
- 정확도와 재현율, 모델 복잡도와 설명 가능성 중 어떤 기준을 선택했나요?
|
|
- 검증 데이터가 실제 사용 환경을 대표한다고 본 근거는 무엇인가요?
|
|
- 성능 향상이 데이터 누수나 우연이 아닌지 어떻게 확인했나요?
|
|
- 더 좋은 모델과 더 낮은 추론 지연·비용이 충돌하면 무엇을 우선하나요?
|
|
|
|
## 7. 인프라·DevOps
|
|
|
|
### 공고 요구를 근거로 바꾸기
|
|
|
|
| 공고 신호 | 관찰 가능한 근거 |
|
|
|---|---|
|
|
| 클라우드·인프라 구성 | 네트워크·컴퓨팅·스토리지 구성도, 권한 경계, IaC 변경 기록과 재현 절차 |
|
|
| 컨테이너·오케스트레이션 | 이미지 구성, 배포 명세, 자원·헬스 체크 설정, 장애·재시작 관찰 |
|
|
| CI/CD | 빌드·테스트·배포 단계, 실패 차단 조건, 비밀값 처리, 롤백 또는 이전 버전 복구 연습 |
|
|
| 관측·신뢰성 | 로그·메트릭·알림 기준, 장애 탐지와 원인 분석, 런북·사후 회고 |
|
|
| 비용·운영 효율 | 자원 사용 근거, 자동화한 반복 작업, 비용과 안정성 사이의 결정 |
|
|
|
|
신입 경험으로는 개인 서비스 배포, 홈랩, 학교 서버 운영, CI 파이프라인, Docker·Kubernetes 실습, IaC 포트폴리오, 장애 실험을 사용할 수 있다. 구성 파일을 따라 만든 것과 문제를 진단·변경한 부분을 구분한다.
|
|
|
|
심층 질문:
|
|
|
|
- 관리형 서비스와 직접 운영 중 무엇을 선택했고 어떤 부담을 감수했나요?
|
|
- 배포 속도와 승인·검증 절차 사이의 기준은 무엇이었나요?
|
|
- 가용성과 비용이 충돌할 때 현재 규모에서 어떤 선택이 타당했나요?
|
|
- 알림 민감도를 높였을 때 생기는 오탐과 놓침을 어떻게 다뤘나요?
|
|
|
|
## 8. 보안
|
|
|
|
### 공고 요구를 근거로 바꾸기
|
|
|
|
| 공고 신호 | 관찰 가능한 근거 |
|
|
|---|---|
|
|
| 보안 설계·위협 분석 | 자산·신뢰 경계·위협 시나리오, 우선순위 기준, 완화책과 잔여 위험 |
|
|
| 인증·인가 | 역할·권한 모델, 토큰·세션 처리, 실패·만료 시나리오, 권한 테스트 |
|
|
| 취약점 분석·대응 | 허가된 범위에서의 재현, 영향 판단, 수정 또는 완화, 회귀 테스트와 보고서 |
|
|
| 보안 운영 | 로그 탐지 규칙, 경보 조사, 대응 절차, 사후 개선과 문서화 |
|
|
| 안전한 개발 | 입력 검증, 의존성·비밀값 관리, 코드 리뷰 기준, 자동 검사 적용 |
|
|
|
|
신입 경험으로는 CTF, 보안 동아리, 취약한 실습 환경, 안전한 코딩 과제, 오픈소스 보안 수정, 위협 모델 문서를 활용할 수 있다. CTF 풀이를 실제 침해 대응이나 상용 시스템 보안 운영으로 바꾸어 말하지 않는다. 허가받지 않은 대상의 공격 세부 사항은 사용하지 않는다.
|
|
|
|
심층 질문:
|
|
|
|
- 위험 감소와 사용자 편의 또는 개발 속도가 충돌했을 때 기준은 무엇이었나요?
|
|
- 발견한 취약점의 심각도를 어떤 자산과 공격 조건으로 판단했나요?
|
|
- 완전한 수정이 어려울 때 어떤 임시 완화책과 잔여 위험을 남겼나요?
|
|
- 탐지 규칙의 오탐과 미탐을 어떻게 비교했나요?
|
|
|
|
## 9. QA
|
|
|
|
### 공고 요구를 근거로 바꾸기
|
|
|
|
| 공고 신호 | 관찰 가능한 근거 |
|
|
|---|---|
|
|
| 테스트 설계 | 요구사항을 정상·경계·예외 조건으로 나눈 기준, 테스트 케이스와 추적성 |
|
|
| 자동화 | 자동화 대상을 고른 기준, 테스트 코드·리포트, CI 연동, 유지보수 비용 |
|
|
| 결함 관리 | 재현 절차, 환경·증거, 심각도·우선순위 판단, 수정 후 회귀 확인 |
|
|
| 품질 지표 | 실패율, 결함 추이, flaky 테스트 등 지표의 정의와 사용 목적 |
|
|
| 협업·프로세스 | 개발·기획과 수용 기준 합의, 출시 위험 공유, 회고 후 절차 변경 |
|
|
|
|
신입 경험으로는 팀 프로젝트의 테스트 담당, 테스트 자동화 개인 실습, 오픈소스 버그 리포트, 앱·웹 탐색 테스트, 요구사항 리뷰를 활용할 수 있다. 발견한 버그 개수보다 중요한 결함을 어떻게 재현하고 우선순위를 설명했는지 묻는다.
|
|
|
|
심층 질문:
|
|
|
|
- 테스트 범위와 출시 일정이 충돌했을 때 위험 기반으로 무엇을 우선했나요?
|
|
- 자동화 비용보다 반복 이득이 크다고 본 기준은 무엇이었나요?
|
|
- flaky 테스트를 유지, 격리, 수정 중 어떻게 판단했나요?
|
|
- 심각도와 수정 우선순위에 의견 차이가 있을 때 어떤 증거를 사용했나요?
|
|
|
|
## 10. Product·PM
|
|
|
|
### 공고 요구를 근거로 바꾸기
|
|
|
|
| 공고 신호 | 관찰 가능한 근거 |
|
|
|---|---|
|
|
| 문제·사용자 이해 | 인터뷰·관찰·문의 분석, 사용자 문제 진술, 가정과 확인되지 않은 부분 |
|
|
| 요구사항·우선순위 | 목표, 수용 기준, 백로그, 우선순위 기준, 제외한 범위와 이유 |
|
|
| 실험·지표 | 성공 지표 정의, 프로토타입·실험 설계, 결과 해석, 다음 결정 |
|
|
| 실행·조율 | 일정·의존성·리스크 기록, 디자인·개발·운영과의 의사결정 과정 |
|
|
| 제품 개선 | 피드백이나 데이터에서 발견한 문제, 변경안, 검증 결과와 후속 과제 |
|
|
|
|
신입 경험으로는 해커톤 PM, 팀 프로젝트 기획, 동아리·행사 운영, 사용자 인터뷰, 프로토타입 테스트, 학내 서비스 개선 제안을 쓸 수 있다. 회의 횟수와 문서 분량보다 어떤 불확실성을 줄이고 어떤 결정을 바꿨는지 확인한다.
|
|
|
|
심층 질문:
|
|
|
|
- 사용자 요구, 사업 목표, 기술 제약이 충돌했을 때 무엇을 기준으로 우선순위를 정했나요?
|
|
- 일정 안에 넣지 않기로 한 범위와 그 결정의 위험은 무엇이었나요?
|
|
- 인터뷰 의견과 사용 데이터가 달랐다면 어떤 추가 검증을 했나요?
|
|
- 성공 지표가 단기 반응만 높이고 장기 경험을 해칠 가능성은 없었나요?
|
|
|
|
## 11. 과장 방지 규칙
|
|
|
|
- 팀이 만든 결과는 “팀은”, 본인이 한 행동은 “저는”으로 구분한다.
|
|
- 참여를 주도, 사용을 설계, 실습을 운영, 배포를 출시로 자동 승격하지 않는다.
|
|
- 강의나 문서를 그대로 따라 한 부분과 본인이 문제를 정의하고 바꾼 부분을 나눈다.
|
|
- 측정하지 않은 성능 향상, 사용자 증가, 비용 절감, 정확도는 숫자로 만들지 않는다.
|
|
- 수치에는 기준값, 표본·기간, 환경, 측정 방법을 확인한다. 기억이 불확실하면 범위를 좁히거나 수치를 뺀다.
|
|
- 변경과 결과가 함께 일어났다는 이유만으로 인과를 단정하지 않는다.
|
|
- 기술을 사용한 사실만으로 숙련도, 대규모 운영, 아키텍처 역량을 주장하지 않는다.
|
|
- 공개 저장소·문서가 없다고 경험을 무효화하지 않되, 기억과 해석을 사실처럼 보강하지 않는다.
|
|
- 실패의 책임을 타인에게 돌리거나 동료의 기여를 지우지 않는다.
|
|
- 회사의 기술 환경이나 문제를 공고에 없는 내용까지 추측해 맞춤형 사실처럼 쓰지 않는다.
|
|
- “완벽히 해결”, “획기적”, “압도적” 같은 표현은 검증 가능한 범위가 없으면 제거한다.
|
|
|
|
안전한 표현 예시는 다음과 같다.
|
|
|
|
| 과장 위험 | 사실 범위에 맞춘 표현 |
|
|
|---|---|
|
|
| 대규모 트래픽을 안정적으로 처리했습니다 | 로컬 부하 테스트의 동일 조건에서 오류와 응답 시간을 비교했습니다 |
|
|
| 프로젝트를 총괄했습니다 | 4인 팀에서 API 일정 조율과 주문 기능 구현을 맡았습니다 |
|
|
| AI 모델을 서비스화했습니다 | 모델을 API로 감싸 테스트 환경에 배포했습니다 |
|
|
| 보안을 강화했습니다 | 권한 없는 요청의 실패 테스트를 추가하고 인가 누락을 수정했습니다 |
|
|
| 사용자 만족도를 높였습니다 | 사용성 테스트 참여자들이 막힌 단계가 줄었는지 후속 확인했습니다 |
|
|
|
|
## 12. 트레이드오프 질문 모음
|
|
|
|
기술명보다 판단을 드러내기 위해 경험에 맞는 질문 1~3개만 선택한다.
|
|
|
|
- 당시 실제로 고려한 대안은 무엇이었나요?
|
|
- 선택 기준은 성능, 일정, 비용, 안정성, 사용성, 학습 난이도 중 무엇이었나요?
|
|
- 선택으로 얻은 것과 포기한 것은 각각 무엇인가요?
|
|
- 그 선택이 유효했던 규모·환경·기간은 어디까지인가요?
|
|
- 어떤 신호가 나타나면 현재 선택을 다시 검토해야 하나요?
|
|
- 충분한 시간이나 데이터가 있었다면 무엇을 먼저 검증했을까요?
|
|
- 가장 단순한 방법을 쓰지 않은 이유, 또는 복잡한 방법을 쓰지 않은 이유는 무엇인가요?
|
|
- 팀의 유지보수 역량이나 일정이 기술 선택에 어떤 영향을 주었나요?
|
|
- 단기 결과와 장기 유지보수가 충돌했을 때 어떻게 결정했나요?
|
|
- 본인 선택의 부작용이나 아직 해결하지 못한 한계는 무엇인가요?
|
|
|
|
사용자가 실제로 비교하지 않은 대안을 사후에 만들어 내지 않는다. 당시에는 직관적으로 골랐다면 그렇게 기록하고, 이후에 알게 된 대안은 “회고 시점의 학습”으로 분리한다.
|