cover-letter-haness/skills/draft-korean-it-cover-letter/references/it-role-evidence.md

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개만 선택한다.

• 당시 실제로 고려한 대안은 무엇이었나요?
• 선택 기준은 성능, 일정, 비용, 안정성, 사용성, 학습 난이도 중 무엇이었나요?
• 선택으로 얻은 것과 포기한 것은 각각 무엇인가요?
• 그 선택이 유효했던 규모·환경·기간은 어디까지인가요?
• 어떤 신호가 나타나면 현재 선택을 다시 검토해야 하나요?
• 충분한 시간이나 데이터가 있었다면 무엇을 먼저 검증했을까요?
• 가장 단순한 방법을 쓰지 않은 이유, 또는 복잡한 방법을 쓰지 않은 이유는 무엇인가요?
• 팀의 유지보수 역량이나 일정이 기술 선택에 어떤 영향을 주었나요?
• 단기 결과와 장기 유지보수가 충돌했을 때 어떻게 결정했나요?
• 본인 선택의 부작용이나 아직 해결하지 못한 한계는 무엇인가요?

사용자가 실제로 비교하지 않은 대안을 사후에 만들어 내지 않는다. 당시에는 직관적으로 골랐다면 그렇게 기록하고, 이후에 알게 된 대안은 “회고 시점의 학습”으로 분리한다.