IT 취업 상담에서 희망 직무를 물으면 개발자, 데이터 분석가, 보안 전문가처럼 익숙한 이름부터 이야기하는 경우가 많습니다. 하지만 해당 직무가 하루 동안 어떤 일을 하는지, 어떤 결과물을 만들며, 문제가 생겼을 때 무엇을 확인하는지까지 설명하는 준비생은 많지 않습니다. 프로그래밍을 배우면 개발자, 숫자를 좋아하면 데이터 분석가, 컴퓨터를 잘 다루면 보안 전문가가 맞을 것이라고 단순하게 판단하기도 합니다.
IT직무는 같은 기술을 사용하더라도 해결하려는 문제가 다릅니다. 개발은 기능과 서비스를 구현하는 데 가깝고, 데이터 분야는 수집된 자료에서 기준과 의미를 찾는 역할이 중심입니다. 보안은 위험을 발견하고 대응 기준을 세우며, 인프라는 서비스가 안정적으로 운영되도록 시스템의 연결과 상태를 관리합니다. 직무 이름보다 실제 업무 흐름과 필요한 결과물을 이해해야 자신에게 맞는 준비 방향을 정할 수 있습니다.
IT직무 이해는 기술 목록보다 서비스가 운영되는 흐름에서 시작합니다
- 하나의 서비스에도 서로 다른 역할이 필요합니다
온라인 쇼핑몰에서 사용자가 상품을 검색하고 주문을 완료하는 장면을 생각해 보겠습니다. 화면에서 검색어를 입력하고 결과를 확인하는 기능은 프런트엔드 개발과 연결됩니다. 검색 요청을 처리하고 상품과 주문 정보를 데이터베이스에 저장하는 기능은 백엔드 영역에 가깝습니다.
이용 기록을 분석해 어떤 상품이 다시 구매되는지 파악하는 일은 데이터 분야와 연결됩니다. 비정상적인 로그인이나 결제 접근을 확인하는 것은 보안 업무가 될 수 있고, 사용자가 언제든 서비스에 접속할 수 있도록 서버와 네트워크를 운영하는 일은 인프라 역할에 해당합니다. 하나의 서비스 안에서도 각 담당자가 바라보는 문제와 결과물이 다릅니다.
- 개발 직군은 사용자가 이용할 기능을 코드로 구현합니다. 같은 개발자라도 화면과 사용자 상호작용을 담당하는지, 서버 로직과 데이터 처리를 담당하는지에 따라 공부할 기술과 프로젝트의 강조점이 달라집니다.
- 데이터 직군은 필요한 자료를 수집하고 정리한 뒤 업무 질문에 맞는 기준으로 분석합니다. 단순히 그래프를 만드는 것이 아니라 어떤 데이터를 포함하고 제외했는지, 계산한 지표가 무엇을 의미하는지 설명해야 합니다.
- 보안 직군은 시스템과 서비스에서 발생할 수 있는 위험을 점검합니다. 취약점을 발견하는 것뿐 아니라 실제 영향과 발생 가능성을 판단하고 우선순위를 정하는 과정도 중요합니다.
- 인프라 직군은 서버와 네트워크, 클라우드 환경이 안정적으로 작동하도록 관리합니다. 장애가 발생하면 접속 경로와 시스템 상태를 구간별로 확인하고 서비스를 복구해야 합니다.
- 직무 이름만 보고 선택하면 실제 업무에서 차이를 느낄 수 있습니다
경영학을 전공한 한 준비생은 숫자를 다루는 일을 좋아한다는 이유로 데이터 분석가를 선택했습니다. 파이썬과 SQL 강의를 수강하고 시각화 프로젝트도 만들었지만, 분석 주제를 정하거나 지표 기준을 세우는 과정에서는 흥미를 느끼지 못했습니다. 반면 데이터를 정리하고 오류값을 찾아 일정한 형태로 변환하는 작업에는 집중력이 높았습니다.
처음에는 분석 역량이 부족해서 흥미를 잃었다고 판단했습니다. 그러나 프로젝트를 검토하면서 새로운 의미를 해석하는 역할보다 데이터가 정상적으로 수집되고 사용할 수 있는 상태로 유지되는 과정을 더 선호한다는 점을 발견했습니다. 이후 데이터 분석가만 보지 않고 데이터 운영과 데이터 엔지니어 직무의 채용공고도 함께 비교했습니다.
분석 직무에서는 지표 설정과 결과 해석, 보고서 작성이 반복적으로 등장했습니다. 데이터 엔지니어 공고에서는 데이터 수집과 변환, 저장 구조, 작업 자동화, 오류 확인이 주요 업무로 나타났습니다. 이 준비생은 같은 데이터 분야 안에서도 자신이 선호하는 업무가 다르다는 사실을 확인하고 학습 방향을 수정했습니다.
- 관심 분야 중심 설명: 숫자를 다루는 것을 좋아해 데이터 분석가를 준비했습니다.
- 업무 경험이 보이는 설명: 주문 데이터를 정리하면서 중복값과 누락값을 찾고 분석 가능한 형태로 변환했습니다.
- 직무 방향이 구체화된 설명: 분석 결과를 발표하는 일보다 데이터 수집 오류를 확인하고 변환 기준을 정하는 과정에 더 집중했습니다. 이후 데이터 엔지니어 공고의 수집, 정제, 적재 업무를 비교하고 작은 데이터 처리 프로젝트를 추가했습니다.
- 결과물보다 반복 업무가 자신에게 맞는지 확인해야 합니다
직무를 선택할 때 완성된 결과물만 보면 모든 역할이 흥미롭게 보일 수 있습니다. 프런트엔드는 화면이 바로 나타나고, 데이터 분석은 그래프로 결론을 보여주며, 보안은 위험을 발견하는 모습이 강조됩니다. 그러나 실제 준비 과정에서는 오류를 수정하고 조건을 다시 확인하며 반복적으로 테스트하는 시간이 더 많습니다.
개발자는 코드 작성뿐 아니라 기존 코드를 읽고 오류 원인을 추적해야 합니다. 데이터 분석가는 원하는 결과가 나오지 않더라도 기준을 다시 검토하고 자료의 품질을 확인해야 합니다. 보안 담당자는 경고가 발생할 때 실제 위험인지 정상 행동인지 구분해야 하고, 인프라 담당자는 장애가 발생하지 않는 시간에도 시스템 상태와 변경 내용을 관리해야 합니다.
- 화면을 만드는 일에 관심이 있다면 디자인 결과만 보지 말고 사용자 입력과 상태 변화, API 실패를 처리해 봐야 합니다. 예외 상황을 수정하는 과정까지 지속할 수 있는지 확인해야 프런트엔드 적합성을 판단할 수 있습니다.
- 데이터 분석이 궁금하다면 준비된 자료로 그래프만 만들지 말고 누락값과 중복값, 계산 기준을 직접 정해 봐야 합니다. 결과를 해석하고 자신의 기준을 다른 사람에게 설명하는 과정이 맞는지도 살펴봐야 합니다.
- 보안과 인프라에 관심이 있다면 도구 실행 화면보다 로그와 설정을 비교하는 실습이 필요합니다. 문제가 발생한 구간을 찾고 점검 순서를 기록하는 과정에 흥미가 있는지 확인해야 합니다.
- 작은 실습이 직무 선택의 근거가 됩니다
직무 소개를 많이 읽는 것만으로는 자신에게 맞는 역할을 확정하기 어렵습니다. 관심 있는 분야마다 작은 과제를 수행하고 어떤 문제를 해결했는지 기록해야 합니다. 결과물의 완성도보다 어떤 과정에서 집중력이 높아졌고 무엇을 더 개선하고 싶었는지를 확인하는 것이 좋습니다.
프런트엔드를 알아보고 있다면 로그인 화면을 만들고 빈 입력, 로딩, 성공, 실패 상태를 처리해 볼 수 있습니다. 백엔드는 회원가입 API를 구현해 검증과 데이터 저장, 오류 응답을 확인할 수 있습니다. 데이터 분야는 주문 자료에서 재구매율을 정의하고 추출 조건에 따라 값이 달라지는 이유를 정리해 보는 방식이 적합합니다.
보안 직무는 로그인 실패 로그를 유형별로 분류하고 위험 기준을 세워볼 수 있습니다. 인프라는 가상 서버에 서비스를 배포한 뒤 포트나 서버 상태를 바꾸어 접속 실패 원인을 추적해 볼 수 있습니다. 작은 실습을 여러 개 경험하면 직무 이름이 아니라 실제 업무 방식을 기준으로 선택할 수 있습니다.
개발 vs 데이터 차이는 만드는 일과 해석하는 일에서 드러납니다
- 프런트엔드와 백엔드는 같은 기능을 다른 위치에서 다룹니다
개발 직군 안에서도 프런트엔드와 백엔드는 담당하는 영역이 다릅니다. 프런트엔드는 사용자가 직접 보는 화면과 입력 흐름을 구현합니다. 버튼을 눌렀을 때 어떤 변화가 나타나는지, 서버 응답을 기다리는 동안 무엇을 보여줄지, 잘못된 입력을 어떻게 안내할지를 다룹니다.
백엔드는 화면에서 들어온 요청을 검증하고 필요한 데이터를 처리합니다. 사용자 인증과 권한, 비즈니스 로직, 데이터베이스 저장, 예외 응답을 설계합니다. 같은 회원가입 기능이라도 프런트엔드는 입력 편의성과 화면 상태를, 백엔드는 중복 확인과 비밀번호 처리, 저장 결과를 중심으로 바라봅니다.
- 프런트엔드 결과물에는 화면 디자인뿐 아니라 사용자 입력과 상태 변화가 보여야 합니다. 정상 화면만 제시하기보다 로딩, 결과 없음, 서버 오류, 권한 부족 상황을 어떻게 처리했는지 설명하는 것이 좋습니다.
- 백엔드 프로젝트에는 API 목록만 적지 말고 요청이 처리되는 흐름을 보여줘야 합니다. 입력 검증, 데이터 조회와 저장, 예외 처리, 인증과 권한을 어느 단계에서 적용했는지 정리할 필요가 있습니다.
- 풀스택 개발을 목표로 하더라도 처음부터 모든 영역을 같은 수준으로 공부하기는 어렵습니다. 대표 프로젝트에서 자신이 더 깊게 다룬 영역을 정하고 해당 직무에 맞는 근거를 먼저 만들어야 합니다.
- 검색 화면의 오류를 수정하며 프런트엔드를 이해한 사례
디자인을 전공한 준비생은 상품 검색 화면을 만들고 API를 연동했습니다. 검색어를 입력하면 관련 상품이 표시됐기 때문에 기능이 완성됐다고 생각했습니다. 하지만 검색어를 빠르게 바꾸면 이전 검색 결과가 뒤늦게 도착해 현재 입력값과 다른 상품이 화면에 나타나는 문제가 발생했습니다.
처음에는 네트워크 속도가 느려서 어쩔 수 없는 현상이라고 판단했습니다. 코드를 다시 확인한 결과 검색어가 바뀔 때마다 새로운 요청이 발생했고, 먼저 보낸 요청이 나중에 도착하면 해당 응답이 현재 결과를 덮어쓰고 있었습니다. 새로운 라이브러리를 추가하기 전에 요청 시점과 화면 상태가 변경되는 순서를 기록했습니다.
이후 짧은 시간 동안 연속되는 입력을 조절하고 현재 검색어에 해당하는 응답만 화면에 반영하도록 수정했습니다. 검색 결과가 없는 상황, 요청이 진행 중인 상태, 서버에서 오류가 반환된 경우도 각각 다른 화면으로 구분했습니다. 빠르게 검색어를 변경하거나 네트워크 응답을 지연시킨 상황도 다시 테스트했습니다.
- 기능 중심 설명: 상품명으로 검색할 수 있는 화면을 구현했습니다.
- 처리 과정이 보이는 설명: 검색어에 따라 API를 호출하고 로딩, 결과 없음, 요청 실패 상태를 구분했습니다.
- 문제해결이 담긴 설명: 이전 검색 요청이 나중에 도착해 현재 결과를 덮어쓰는 문제를 발견했습니다. 요청과 응답 순서를 확인해 현재 검색어와 일치하는 결과만 반영하고 연속 입력과 응답 지연 상황을 다시 검증했습니다.
이 경험을 통해 준비생은 프런트엔드가 화면을 예쁘게 만드는 역할에만 머물지 않는다는 점을 이해했습니다. 사용자 행동과 비동기 요청, 화면 상태를 연결하는 과정이 핵심 경험으로 바뀌었습니다.
- 데이터 분석과 데이터 엔지니어는 질문과 흐름이 다릅니다
데이터 분석가는 자료에서 업무에 필요한 의미를 찾습니다. 매출이 감소한 원인을 살펴보거나 고객 행동을 구분하고, 지표를 정의해 의사결정에 필요한 정보를 제공합니다. SQL과 파이썬을 사용하더라도 최종 결과는 분석 보고서와 대시보드, 지표 해석에 가까울 수 있습니다.
데이터 엔지니어는 자료가 안정적으로 수집되고 처리될 수 있는 흐름을 만듭니다. 여러 시스템에서 생성된 데이터를 일정한 형태로 변환하고 저장하며, 처리 작업이 실패했을 때 원인을 확인합니다. 분석가가 신뢰할 수 있는 자료를 사용할 수 있도록 데이터의 이동과 품질을 관리하는 역할입니다.
같은 SQL을 사용해도 분석가는 어떤 고객을 재구매 고객으로 정의할지 고민하고, 엔지니어는 주문 자료가 빠짐없이 저장되고 정해진 시간에 처리되는지 확인할 수 있습니다. 도구의 이름보다 해결하는 문제와 결과물의 차이를 이해해야 합니다.
- 재구매율 기준을 수정한 데이터 분석 사례
데이터 직무를 준비한 지원자는 쇼핑몰 주문 자료에서 고객별 구매 횟수를 계산하고 두 번 이상 주문한 고객을 재구매 고객으로 분류했습니다. 대시보드에는 높은 재구매율이 표시됐지만 취소 주문과 테스트 계정도 포함되어 있었습니다. 분석 기간 마지막에 처음 구매한 고객 역시 오랫동안 관찰된 고객과 같은 조건으로 계산됐습니다.
처음에는 그래프 종류가 적어 결과물이 단순해 보인다고 생각했습니다. 하지만 포트폴리오 검토에서 발견된 문제는 시각화 개수가 아니라 지표 기준이었습니다. 재구매 기회가 충분하지 않은 고객까지 같은 분모에 넣으면 기간에 따라 수치가 크게 달라질 수 있었습니다.
취소와 환불 주문, 테스트 계정을 제외하고 첫 구매 이후 90일 안에 추가 구매한 경우를 재구매로 정의했습니다. 첫 구매 후 90일이 지난 고객만 계산한 결과와 전체 고객을 포함한 결과를 비교했습니다. 신규 고객이 많은 기간에는 두 지표의 차이가 커질 수 있다는 해석도 추가했습니다.
- 결과 중심 정리: SQL로 고객별 구매 횟수와 재구매율을 계산했습니다.
- 기준이 보이는 정리: 취소와 환불 주문을 제외하고 첫 구매 후 90일 안에 다시 구매한 고객을 재구매 고객으로 정의했습니다.
- 해석까지 포함한 정리: 관찰 기간이 짧은 신규 고객을 같은 기준으로 계산하면 수치가 달라질 수 있어 전체 고객과 90일 이상 관찰된 고객을 나누어 비교했습니다. 지표 정의에 따른 변화와 분석의 한계도 함께 설명했습니다.
이 결과물은 SQL 사용 능력만 보여주는 자료에서 데이터의 범위와 지표를 판단한 분석 경험으로 달라졌습니다. 숫자를 계산하는 것보다 해당 숫자가 무엇을 의미하는지 설명하는 일이 데이터 분석가의 역할과 더 가깝다는 점도 확인할 수 있었습니다.
- 개발과 데이터는 프로젝트 결과물부터 다르게 설계해야 합니다
개발 지원자가 분석 그래프만 제시하거나 데이터 지원자가 사용 기술과 화면 기능만 나열하면 목표 직무가 선명하게 보이지 않습니다. 같은 쇼핑몰 프로젝트를 활용하더라도 지원 분야에 따라 강조할 경험을 바꿔야 합니다.
개발자는 사용자 요청과 처리 흐름, 데이터 저장, 오류 대응을 보여줄 수 있습니다. 데이터 분석가는 어떤 업무 질문을 정했고, 어떤 조건으로 자료를 추출했으며, 결과를 어떻게 해석했는지 정리해야 합니다. 데이터 엔지니어는 수집과 변환, 저장 흐름, 작업 실패와 재처리 기준을 강조할 수 있습니다.
기술을 많이 사용한 프로젝트보다 직무의 핵심 업무가 보이는 결과물이 더 설득력 있습니다. 프로젝트를 새로 만들기 전에 기존 결과물에서 목표 직무와 관련된 판단과 검증이 충분히 나타나는지 먼저 확인하는 것이 좋습니다.
보안과 인프라는 위험 판단과 안정적인 운영에서 차이가 나타납니다
- 보안은 위험을 찾고 인프라는 서비스 상태를 유지합니다
보안과 인프라는 서버와 네트워크, 운영체제를 함께 다루기 때문에 비슷하게 보일 수 있습니다. 실제 업무에서도 두 분야는 긴밀하게 연결되지만 문제를 바라보는 중심은 다릅니다. 보안은 허용되지 않은 접근과 취약한 설정, 정보 유출 가능성을 점검하고 대응 기준을 세웁니다.
인프라는 서비스가 필요한 성능과 안정성을 유지하도록 서버, 네트워크, 클라우드 자원을 구성하고 운영합니다. 장애가 발생하면 사용자의 요청이 어느 구간에서 막혔는지 확인하고 복구합니다. 보안은 안전하지 않은 상태를 찾는 데, 인프라는 서비스가 정상적으로 지속되는 상태를 만드는 데 더 무게가 있습니다.
- 보안 담당자는 경고가 발생했다는 사실만으로 공격이라고 단정하지 않아야 합니다. 접속 IP와 요청 간격, 대상 계정, 사용자 행동을 비교해 실제 위험인지 정상 행동인지 판단해야 합니다.
- 인프라 담당자는 서버가 작동한다는 결과만 확인하지 않습니다. 네트워크 접근과 포트, 서버 자원, 프로세스, 로그를 지속적으로 점검하고 변경 사항을 관리해야 합니다.
- 클라우드는 독립된 하나의 직무라기보다 개발, 인프라, 보안과 연결되는 기술 환경으로 보는 것이 좋습니다. 같은 클라우드 서비스를 사용해도 배포 자동화, 서버 운영, 접근 권한, 보안 설정처럼 담당 영역이 달라질 수 있습니다.
- 로그인 실패 로그에서 위험 기준을 수정한 보안 사례
보안 분야를 준비한 지원자는 서버의 로그인 실패 기록을 수집하고 일정 횟수 이상 실패하면 경고가 발생하도록 설정했습니다. 포트폴리오에는 보안 도구 화면과 설정 방법이 정리되어 있었지만 일반 사용자가 비밀번호를 여러 번 틀린 상황과 자동화된 접근을 어떻게 구분했는지는 설명하지 못했습니다.
처음에는 로그인 실패 횟수가 많으면 위험한 접근이라고 판단했습니다. 그러나 테스트 과정에서 비밀번호를 잊은 정상 사용자도 경고 대상으로 분류됐습니다. 반대로 하나의 IP에서 여러 계정을 조금씩 바꾸어 시도하면 계정별 실패 횟수 기준을 피할 수 있었습니다.
이후 단순한 횟수만 확인하지 않고 접속 IP, 대상 계정 수, 요청 간격, 사용자 환경, 성공 로그인 전환 여부를 함께 비교했습니다. 특정 계정에 반복 접근하는 유형과 하나의 IP에서 여러 계정을 시도하는 유형을 나누었습니다. 정상 사용자와 의심스러운 접근을 가정한 로그를 직접 생성해 탐지 결과도 다시 검증했습니다.
- 도구 사용 중심 설명: 로그인 실패 로그를 수집해 비정상 접근을 탐지했습니다.
- 점검 기준이 보이는 설명: 접속 IP와 실패 횟수, 대상 계정 수를 비교해 반복 로그인 유형을 구분했습니다.
- 위험 판단이 담긴 설명: 정상 사용자의 입력 실수까지 위험으로 분류되는 문제를 발견해 요청 간격과 대상 계정 수를 추가했습니다. 여러 계정에 접근하는 유형과 하나의 계정에 반복 접근하는 유형을 나누고 테스트 로그로 결과를 확인했습니다.
단순한 보안 도구 실습이 처음 설정한 기준의 한계를 발견하고 새로운 판단 조건을 적용한 경험으로 바뀌었습니다. 보안 직무에서는 도구를 실행하는 능력뿐 아니라 경고의 의미와 실제 영향도를 해석하는 과정이 필요합니다.
- SSH 접속 실패를 구간별로 추적한 인프라 사례
클라우드 엔지니어를 준비한 비전공자는 가상 서버를 생성하고 웹 서비스를 배포했습니다. 안내 문서를 따라 정상 접속까지 완료했지만 며칠 뒤 SSH 연결에 실패하자 인스턴스를 삭제하고 다시 만들려고 했습니다. 접속 문제가 네트워크인지, 인증 정보인지, 서버 상태인지 구분하지 못했기 때문입니다.
환경을 새로 만들기 전에 접속 경로를 단계별로 나누었습니다. 인스턴스 실행 상태와 접속 주소를 확인하고, 보안그룹에서 22번 포트가 허용됐는지 점검했습니다. 인증 키의 경로와 권한, 명령에 사용한 사용자 이름도 비교했습니다. 실제 원인은 서버를 다시 시작한 뒤 변경된 접속 주소를 기존 설정 파일에서 사용한 것이었습니다.
문제를 해결한 뒤에는 접속 성공 화면만 남기지 않았습니다. 서버 상태, 주소, 보안그룹, 포트, 인증 키, 사용자 정보를 어떤 순서로 확인했는지 기록했습니다. 22번 포트를 닫거나 잘못된 인증 키를 사용했을 때 나타나는 실패 메시지도 비교했습니다.
- 처음 자료에서는 가상 서버를 생성하고 서비스를 배포했다는 결과만 보였습니다. 안내 문서를 따라 한 내용과 직접 판단한 부분을 구분하기 어려웠습니다.
- 보완된 자료에서는 SSH 요청이 서버에 도달하는 경로와 접속이 막힐 수 있는 구간이 나타났습니다. 각 구간에서 무엇을 확인했는지도 구체적으로 정리됐습니다.
- 면접에서는 서버를 다시 만들겠다고 답하는 대신 네트워크 접근, 인증 정보, 서버 상태를 나누어 확인하겠다고 설명할 수 있게 됐습니다.
- 보안과 인프라는 같은 실습에서도 기록 기준이 달라집니다
웹 서버를 클라우드에 배포하는 프로젝트는 두 분야에서 모두 활용할 수 있습니다. 그러나 보안 지원자는 접근 권한과 공개 포트, 취약한 설정, 로그인 기록, 위험 대응을 강조해야 합니다. 인프라 지원자는 네트워크 구조와 서버 구성, 배포 과정, 상태 점검, 장애 복구 순서를 보여주는 것이 좋습니다.
보안을 준비하면서 해킹 도구의 실행 화면만 넣거나 인프라를 준비하면서 배포 성공 화면만 보여주면 자신의 판단을 확인하기 어렵습니다. 설정을 변경했을 때 어떤 위험이 생기는지, 접속 실패 시 어디부터 확인했는지, 수정 후 무엇을 다시 검증했는지가 포함되어야 합니다.
채용공고에서도 같은 클라우드와 리눅스 경험을 요구하더라도 실제 업무는 다를 수 있습니다. 접근통제와 취약점 점검이 반복된다면 보안 성격이 강하고, 서버 운영과 장애 대응, 배포 관리가 중심이라면 인프라와 가까울 수 있습니다. 기술 이름보다 반복되는 업무를 비교해야 정확한 준비 방향을 정할 수 있습니다.
- conclusion
IT직무 종류를 이해한다는 것은 개발자, 데이터 분석가, 보안 전문가처럼 이름을 외우는 일이 아닙니다. 같은 서비스 안에서 각 역할이 어떤 문제를 해결하고, 무엇을 결과물로 만들며, 문제가 발생했을 때 어디부터 확인하는지를 비교하는 과정입니다.
현재 자신의 선택과 준비 상태는 다음 내용을 중심으로 점검할 수 있습니다.
- 개발 분야가 궁금하다면 화면과 사용자 상태를 다루는 일이 맞는지, 서버 로직과 데이터 처리를 설계하는 과정이 맞는지 구분해야 합니다. 작은 기능을 직접 만들고 오류를 수정해 봐야 프런트엔드와 백엔드의 차이를 현실적으로 판단할 수 있습니다.
- 데이터 분야를 희망한다면 그래프를 만드는 일보다 지표 기준을 정하고 결과를 해석하는 과정에 흥미가 있는지 확인해야 합니다. 수집과 변환, 저장 흐름을 만드는 일이 더 잘 맞는다면 데이터 엔지니어 방향도 함께 비교할 수 있습니다.
- 보안과 인프라를 고민한다면 위험한 접근을 판단하는 일과 시스템의 정상 상태를 유지하는 일 중 어디에 더 관심이 있는지 살펴봐야 합니다. 로그인 로그 분석과 서버 접속 장애 추적처럼 작은 실습을 통해 차이를 확인하는 것이 좋습니다.
실제 포트폴리오를 검토하면 직무 이름은 정했지만 해당 역할에서 보여줘야 할 경험이 빠져 있는 경우가 많습니다. 프런트엔드를 준비하면서 완성 화면만 넣거나, 데이터 분석을 지원하면서 도구 이름만 나열하고, 인프라를 희망하면서 배포 성공 화면만 보여주면 준비의 깊이를 판단하기 어렵습니다.
직무 선택은 유행이나 익숙한 이름보다 반복해서 수행할 업무를 기준으로 해야 합니다. 작은 실습에서 자신이 내린 판단과 해결 과정을 기록하면 포트폴리오의 방향이 구체화되고 면접 답변의 근거도 만들어집니다. 자신에게 맞는 IT 분야는 설명만 듣고 찾는 것이 아니라 직접 만들어 보고 분석하고 점검하면서 발견하게 됩니다.
