26상 SK하이닉스 자기소개서 항목별 풀이 (IT(AMHS) - AI 사용 경험 & 전공/프로젝트 중심

■ 산업/기업/직무 분석

① 산업 분석

지금 반도체 메모리 시장을 한 문장으로 줄이면 '만들기만 하면 다 팔리는' 상황이에요. 인공지능 데이터센터가 메모리를 어마어마하게 빨아들이면서, 공급이 수요를 도저히 따라가지 못하는 품귀가 벌어지고 있거든요. 예전처럼 값이 잠깐 올랐다 내렸다 반복하던 사이클이 아니라, AI가 메모리를 굶주리게 만드는 전혀 다른 국면이라고 볼 수 있죠.

이 호황을 끌고 가는 엔진은 HBM이라는 제품인데요. D램을 여러 장 위로 차곡차곡 쌓아서 데이터가 오가는 길을 확 넓힌 부품이라고 생각하시면 됩니다. AI 연산은 데이터를 쉴 새 없이 주고받아야 하는데, 그 길이 좁으면 아무리 비싼 GPU라도 데이터를 기다리느라 놀게 되니까요. 그래서 이 부품이 AI 시대의 병목을 푸는 핵심으로 떠올랐습니다.

여기서 중요한 건, 이 호황이 가격으로만 끝나지 않는다는 점이에요. 메모리가 모자라면 회사는 공장을 더 짓습니다. 그리고 새 공장이 하나 세워질 때마다 그 안에는 천장을 따라 웨이퍼를 실어 나르는 자동 반송 설비가 수천 대씩 깔리죠. 자동 반송을 구축하는 일이 곧 새 공장의 혈관을 까는 작업인 셈입니다.

재미있는 대목은, 산업이 불황으로 돌아서도 이 일의 가치는 줄지 않는다는 거예요. 호황이면 새 공장을 짓느라 구축 수요가 몰리고, 불황이면 이미 돌아가는 라인의 효율을 한 방울이라도 더 짜내는 운영·개선 수요가 늘어나거든요. 게다가 이 분야는 하드웨어 중심에서 소프트웨어와 데이터, AI 쪽으로 무게가 빠르게 옮겨가는 중이라, 기계 산업으로만 바라보면 그림을 놓치게 됩니다.

② 기업 분석

SK하이닉스는 지금 창사 이래 가장 좋은 시절을 보내고 있어요. 2025년 한 해에 매출 약 97조 원, 영업이익 약 47조 원을 기록하면서 전사 영업이익에서 삼성전자를 사상 처음으로 앞질렀거든요. 2026년 1분기엔 영업이익률이 무려 72%까지 올라, 1,000원어치를 팔면 720원이 남는 장사를 한 셈이에요.

이 실적의 심장은 HBM이에요. 엔비디아 GPU에 들어가는 고성능 메모리에서 SK하이닉스는 세계 1위 자리를 지키고 있고, 차세대 제품에서도 절반이 넘는 점유율을 가져갈 것으로 시장은 보고 있죠. 한마디로 가장 비싸고 가장 잘 팔리는 제품을 가장 잘 만드는 회사라고 할 수 있습니다.

돈을 많이 버니 공장도 공격적으로 짓습니다. 설비투자가 2024년 약 18조 원에서 2025년 약 30조 원으로 한 해 만에 크게 뛰었고, 청주의 새 팹과 용인 클러스터, 미국 인디애나 패키징 시설이 동시에 올라가는 중이에요. 새 팹마다 자동 반송 시스템이 통째로 들어가야 하니, 이 직무의 일감이 수년치 쌓여 있는 셈이죠.

회사가 그리는 미래도 눈여겨봐야 합니다. SK하이닉스는 2030년까지 사람 손을 거의 타지 않는 '자율형 팹'을 만들겠다고 선언했는데요. 공장의 두뇌 역할을 하는 AI, 몸 역할을 하는 로봇과 반송 설비, 그리고 실제 공장을 가상으로 똑같이 복제한 모형을 세 기둥으로 삼고 있어요. 이 공장을 굴리는 연료가 데이터인데, 팹 한 곳에서 하루 나오는 양만 고화질 영화 수만 편에 맞먹는다고 하죠. 현대전자에서 하이닉스를 거쳐 SK로 이어지며 위기를 함께 넘어온 '원팀' 문화도 이 회사를 이해하는 중요한 열쇠입니다.

③ 직무 분석

IT(AMHS) 직무는 반도체 공장 안에서 웨이퍼를 자동으로 옮기고, 보관하고, 제어하는 물류 시스템을 책임지는 자리예요. 웨이퍼는 낱장으로 다니지 않고 25장씩 밀폐 용기에 담겨 이동하는데, 이걸 사람 손 대신 천장 레일 위 차량이 알아서 장비에서 장비로 날라 주거든요. 비유하자면 공장 안의 도로망과 차량, 그리고 교통 관제탑을 통째로 만드는 일이라고 보시면 됩니다.

하는 일은 크게 네 갈래예요. 새 라인에 맞춰 반송 설비를 기획하고 까는 구축, 생산 관리 시스템과 연결해 반송을 지휘하는 제어, 어떤 차량을 어디로 어떤 길로 보낼지 정하는 알고리즘 개발, 그리고 쌓인 데이터를 분석해 끊임없이 개선하는 운영이죠. 기계와 전자, 소프트웨어, 데이터 분석이 한 자리에서 만나는 융합형 직무라는 게 핵심입니다.

소프트웨어 쪽을 조금 더 들여다보면 흥미로워요. 급한 웨이퍼를 먼저 처리하되 전체 흐름이 마비되지 않게 조율하는 건, 마치 구급차에 길을 내주면서도 도로 전체가 막히지 않도록 신호를 조정하는 일과 비슷하거든요. 여러 차량이 서로의 길을 막아 다 같이 멈춰 버리는 상황을 미리 막는 것도 중요한 과제고요.

이 직무가 협업을 강조하는 이유도 분명합니다. 생산기술이 정한 흐름, 설비가 둔 장비, IT가 굴리는 시스템, 공급사가 만든 하드웨어를 하나로 엮어야 하니, 서로 다른 언어를 쓰는 부서 사이를 통역하는 역할이 필수거든요. 반송이 빠르고 안정적이면 수천억 원짜리 장비가 쉬지 않고 돌아가고, 막히면 그 비싼 장비가 멈춰 서니, 결국 공장 전체의 생산성을 좌우하는 동맥을 다루는 일이라고 할 수 있습니다.

■ 1번 항목 : AI를 활용한 프로젝트/공모전/논문/연구/학습/활동/문제해결경험 등을 작성해 주세요. (AI 서비스를 단순 질의응답 형태로 활용한 경험은 작성을 지양해 주세요.) / 3000자

■ 출제 의도

이 문항은 'AI를 얼마나 잘 쓰느냐'가 아니라, 'AI를 쓰는 너라는 사람이 얼마나 단단하냐'를 보려는 질문이에요. 같은 도구를 줘도 누가 쥐느냐에 따라 결과물이 천차만별로 갈리거든요. 그러니 평가자가 진짜 궁금해하는 건 AI가 해낸 일이 아니라, 그 AI를 부리는 동안 당신이 어떤 판단을 내렸는가입니다.

왜 이런 걸 묻기 시작했을까요. AI가 이제 실무에 깊숙이 들어와서, 안 쓰면 손해인 도구가 됐기 때문이에요. 그런데 AI에는 치명적인 약점이 하나 있죠. 답이 정해진 문제는 잘 풀지만, 세상에 없던 문제나 가장 최신의 정보 앞에서는 그럴듯한 거짓말을 천연덕스럽게 만들어 냅니다. 그래서 회사는 'AI를 맹신하지 않고 결과를 의심하고 검증할 줄 아는 사람인가'를 꼭 확인하고 싶어 해요.

쉽게 예를 들어 볼게요. 어떤 지원자는 "AI한테 시켰더니 보고서가 뚝딱 나왔습니다"라고 씁니다. 이러면 글의 주인공이 AI가 되어 버려요. 반면 다른 지원자는 "AI가 내놓은 초안에서 통계 두 군데가 수상해 원본을 직접 찾아 확인했고, 한 건이 실제로 틀렸더라"고 씁니다. 후자에서야 비로소 사람의 머리가 보이죠. 이 문항의 본질이 바로 이거예요. 역설적이게도, AI가 한 일을 걷어 내고 남는 '나만의 판단과 검증'을 드러내야 하는 겁니다.

한 가지 덧붙이면, 평가자는 이 글로 당신의 '배우는 속도'도 가늠합니다. 기술이 워낙 빠르게 바뀌는 곳이라, 모르는 영역을 AI를 활용해 빠르게 익히고 곧장 결과물로 연결하는 민첩함을 귀하게 여기거든요. 다만 여기서도 베껴 쓰는 게 아니라, 질문하고 따져 가며 능동적으로 익혔다는 점이 드러나야 합니다.

실은 이 태도가 먼 이야기가 아니에요. AMHS 직무만 해도 반송 데이터를 분석하거나 제어 코드를 짤 때 AI의 손을 빌릴 수 있는데, AI가 짠 코드를 검증 없이 24시간 돌아가는 현장에 그대로 올렸다 멈추면 큰일이 나거든요. 결과를 한 줄씩 따져 보는 습관이 곧 실력이 되는 셈이죠.

정리하면 이 항목은 'AI를 능숙하게 다루는가'와 'AI를 협업 상대로 쓰되 결코 통째로 믿지는 않는가'라는 두 인상을 동시에 남기는 글이에요. 도구의 화려함이 아니라, 그 도구를 모는 사람의 분별력을 보여 주는 게 이 문항의 열쇠입니다.

■ 풀이 방법

자, 그럼 어떻게 풀어 가면 좋을지 짚어 볼게요. 먼저 소재는 'AI한테 처음엔 막연하게 시켰다가 영 못 쓸 결과를 받았던 경험'에서 출발하면 좋습니다. 처음에 "이것 좀 해줘"라고 두루뭉술하게 요청했더니 쓸 수 없는 답이 나왔다는 실패를 솔직하게 보여 주세요. 그게 출발점이 됩니다.

그다음이 핵심이에요. 그 막연한 요청을 어떻게 바꿨는지를 구체적으로 풀어 주는 겁니다. 예를 들어 "누구에게 쓰는 글인지, 어떤 말투로, 무엇은 빼야 하는지, 예시는 이런 식으로, 결과는 표 형태로"처럼 조건을 또렷이 달았더니 바로 쓸 수 있는 결과가 나왔다고 이야기해 보세요. 두루뭉술했던 처음과 정교해진 다음을 나란히 보여 주면, '같은 AI인데 내가 입력을 바꿔 결과를 끌어올렸다'는 인상이 남습니다. 마지막엔 "그 결과로 무엇이 몇 퍼센트 좋아졌다"처럼 숫자로 못을 박아 주면 더 좋고요.

여기에 한 겹을 더 얹으면 글이 강해집니다. 낯선 분야나 새 도구를 AI를 개인 과외 선생처럼 활용해 빠르게 익힌 경험을 붙여 보세요. "개념을 물어보고, 만들어 달라 하고, 틀린 부분을 해석하고, 다시 고쳐 묻는" 과정을 반복해 짧은 기간에 직접 결과물을 완성했다고 쓰는 거죠. 가령 처음 다뤄 보는 프로그래밍 언어를 몇 주 만에 익혀 데이터 정리 프로그램을 손수 만들어 냈다는 식의 이야기가 여기에 딱 맞습니다. 단, 여기서 절대 빠뜨리면 안 되는 한 문장이 있어요. "AI가 준 걸 그대로 쓰지 않고 한 줄씩 이해하고 검증했다"는 대목입니다. 이게 빠지면 '베꼈다'로 읽히고, 들어가면 '스스로 익혔다'로 읽혀요.

글 전체를 관통하는 원칙은 하나예요. 주인공은 AI가 아니라 당신이어야 합니다. AI가 무엇을 했는지보다, 그 과정에서 당신이 어떤 프롬프트를 짜고 무엇을 의심하고 어떻게 검증했는지가 글의 심장이 되어야 하죠. 마지막은 'AI가 다 한다'도 'AI는 쓸모없다'도 아닌, 협업하되 통째로 믿지는 않는다는 균형으로 닫고, 입사 후 이 직무에서 AI를 이렇게 쓰겠다는 다짐으로 마무리하면 깔끔합니다. 실제로 해본 경험만 써야 한다는 것도 잊지 마세요. 없던 도구를 끼워 넣으면 면접 한 번에 무너지니까요.

■ 상위 1% 예시

[ 답을 만든 건, AI였을까 나였을까? ]

 

학부 연구실에서 천장 반송차 OHT의 운영 로그를 분석하는 과제를 맡았습니다. 반송이 한 번 막히면 수천억 원짜리 장비가 통째로 멈춰 서기에, 정체가 어디서 비롯되는지를 찾는 일은 곧 생산성과 직결되는 문제였습니다. OHT 수백 대가 천장 레일 위를 동시에 오가는 라인에서는 한 지점의 정체가 이내 옆 구간으로 번지기에, 첫 단추를 어디서 끼우느냐가 중요했습니다. 연구의 목표는 정체를 일으키는 알람을 가려내 우선 대응 순위를 매기는 것이었고, 그러려면 한 달 치 로그에 수천 건씩 뒤섞인 알람 메시지를 먼저 같은 언어로 묶는 분류가 출발점이었습니다. 양이 너무 많아 손으로는 엄두가 나지 않았고, 자연스럽게 AI에 손을 뻗었습니다. 처음 제가 던진 요청은 그저 "이 알람 로그들을 분류해줘"가 전부였습니다.

 

결과는 쓸 수 없었습니다. 똑같은 통신 끊김 메시지를 어떤 줄은 통신 오류로, 어떤 줄은 네트워크 지연으로, 또 어떤 줄은 연결 불안정으로 제각각 묶어 놓았습니다. 기준이 없으니 같은 사건이 세 가지 이름표를 달았고, 이런 데이터로는 어떤 통계도 낼 수 없었습니다. 그 순간 문제는 AI가 아니라 제 입력에 있다는 걸 깨달았습니다. AI는 제가 시킨 만큼만 했을 뿐, 무엇을 어떤 기준으로 묶을지는 제가 알려 준 적이 없었으니까요.

 

그래서 요청 자체를 다시 설계했습니다. 막연한 누군가가 아니라 반송 설비 로그를 다루는 분석가의 눈으로 판단하라고 역할부터 부여했습니다. 이어 분류 기준을 통신·구동·센서·정체 네 갈래로 못 박고, 각 갈래가 무엇을 뜻하는지 한 줄씩 정의한 뒤, 실제 로그에서 뽑은 본보기 메시지를 갈래마다 세 개씩 붙여 판단의 기준으로 삼게 했습니다. 헷갈리기 쉬운 경계 사례, 이를테면 센서값 이상으로 차량이 멈춘 경우는 센서로 볼지 정체로 볼지까지 규칙을 문장으로 적어 주었습니다. 결과는 원문·유형·판단 근거 세 칸을 가진 표로 돌려 달라고 출력 형식까지 지정했습니다. 전체에 적용하기 전 먼저 200건 남짓한 표본에 규칙을 시험해 어긋나는 분류가 없는지 확인하고서야 나머지로 넓혔고, 근거 칸이 비어 있는 줄이 보이면 모든 줄에 반드시 근거를 채우라는 제약을 한 번 더 더했습니다.

 

같은 AI에 같은 데이터를 넣었지만, 결과는 전혀 다른 물건이었습니다. 4천여 건이 흔들림 없이 일관된 기준으로 분류됐고, 판단 근거 칸 덕분에 결과를 한 줄씩 되짚어 검증할 수 있었습니다. 막연한 한 문장이 정교한 설계로 바뀌자 같은 모델이 전혀 다른 일꾼이 된 셈이었습니다. 정리된 분류표는 곧장 다음 분석의 재료가 되었습니다. 어떤 알람이 정체와 같은 시각에 터지는지 짝지을 수 있게 되면서, 막연하던 로그 더미가 추적 가능한 단서로 바뀌었고, 전체 알람의 절반 가까이가 특정 교차 구간의 정체에 몰려 있다는 사실이 한눈에 드러났고, 이 한 줄의 발견이 정체 원인을 좁히는 출발점이 되었습니다. 손으로 했다면 이틀이 꼬박 걸렸을 일이 두 시간으로 줄었고, 무엇보다 같은 도구라도 입력의 질이 출력을 가른다는 것을, 좋은 입력은 운이 아니라 설계의 결과라는 것을 몸으로 익혔습니다.

 

분류는 끝났지만, 정체가 시간대별로 어떻게 번지는지 더 깊이 파고들려면 직접 코드를 써야 했습니다. 문제는 제가 파이썬을 제대로 다뤄 본 적이 없다는 것이었고, 발표까지 3주밖에 남지 않았다는 것이었습니다. 학원을 다닐 시간은 없었기에, 저는 AI를 개인 과외 선생으로 삼기로 했습니다. 개념을 묻고, 예시 코드를 받고, 실행해 보고, 쏟아지는 오류 메시지를 다시 AI와 함께 해석하고, 고쳐서 또 묻는 과정을 매일 반복했습니다. 낯선 개념일수록 통째로 외우기보다 작은 예제로 쪼개 직접 돌려 보며 익혔고, 한번은 데이터 형식이 맞지 않아 같은 오류가 거듭 났는데 메시지가 무슨 뜻인지부터 AI에 되물어 원인을 짚고서야 풀렸습니다. 코드를 베껴 발표만 넘기는 건 어렵지 않았지만, 그러면 다음 과제에서 똑같이 막힐 게 뻔했기에 느리더라도 스스로 짤 수 있을 만큼 익히는 길을 택했고, 그렇게 익힌 파이썬은 발표 이후 다른 데이터를 다룰 때도 든든한 무기로 남았습니다.

 

여기서 제가 끝까지 지킨 원칙이 하나 있습니다. AI가 준 코드를 그대로 붙여 넣지 않고, 반드시 한 줄씩 직접 이해하고 검증했습니다. 실제로 AI가 짜 준 결측치 처리 코드는 빈 값만 지우는 게 아니라 0이라는 정상 측정값까지 함께 지워 버리는 함정을 품고 있었습니다. 그대로 돌렸다면 멀쩡한 데이터가 사라져 분석이 통째로 어긋났을 겁니다. 한 줄씩 따져 본 덕분에 이 오류를 잡아 조건을 다시 짰고, 그렇게 3주 만에 반송 데이터 전처리 스크립트를 제 손으로 완성했습니다. 결국 특정 시간대의 특정 구간에 정체가 몰린다는 결론을, 빌린 답이 아니라 검증된 제 결과로 내놓을 수 있었습니다.

 

이 두 경험은 제게 같은 가르침을 남겼습니다. AI는 맹신할 도구도, 쓸모없는 도구도 아닌, 협업하되 끝까지 의심해야 할 동료라는 것입니다. 막연히 시키면 못 쓸 답을 주지만 잘 설계해 물으면 두 시간 만에 일을 끝내 주고, 그럴듯해 보여도 검증하면 숨은 함정이 드러납니다. AI가 가장 자신 있게 내놓는 답일수록 한 번 더 의심하는 습관도 이 과정에서 얻었습니다. 그러니 답을 만든 주인공은 AI가 아니라, 좋은 질문을 짜고 결과를 끝까지 의심한 저였습니다. SK하이닉스가 그리는 자율형 팹은 결국 데이터를 연료로 굴러가고, 그 데이터를 다루는 일에 AI는 빼놓을 수 없는 동료가 될 것입니다. 다만 검증 없는 코드를 24시간 멈추지 않는 라인에 올리는 일은 결코 없어야 합니다. AI가 내놓은 결과를 한 줄씩 따져 보는 습관으로, 반송 제어는 한 줄의 오류가 라인 전체의 멈춤으로 번질 수 있는 일이기에, 의심하고 검증하는 이 습관은 곧 안정성으로 이어진다고 믿습니다. 빠르면서도 흔들리지 않는 반송 환경을 만드는 데 보탬이 되겠습니다.

■ 2번 항목 : 지원 분야 및 직무 역량과 관련된 프로젝트/공모전/논문/연구/학습/활동/경험 등을 작성해주세요. (예시) [기간] 2025.02 ~ 2026.02 / [경험] 회로 및 시스템 설계 연구 학부 연구생 / [역할] CMOS 집적회로 설계 및 성능개선 분석

■ 출제 의도

이 문항은 돌려 말하지 않고 대놓고 묻습니다. "당신, 이 일을 할 수 있는 사람이 맞나요?" 성격이나 인성을 두루뭉술하게 보는 항목이 아니라, 지원한 직무를 실제로 해낼 근거가 있는지를 정면으로 검증하는 자리예요. 그래서 자소서 전체에서 가장 무게가 실리는 핵심 항목이라고 볼 수 있죠.

평가자가 보고 싶은 건 두 가지가 한 묶음이에요. 첫째, 이 직무가 도대체 무슨 일을 하는 자리인지 정확히 알고 있는가. 둘째, 그 일을 해낼 만한 지식과 기술, 그리고 그 일에 맞는 태도를 갖췄는가. 이 둘은 동전의 양면이라서, 직무를 어설프게 알고 쓰면 아무리 화려한 경험을 나열해도 '직무를 모르는 사람의 글'처럼 읽혀 버립니다. SK하이닉스가 사람을 볼 때 협업할 줄 아는가, 기술이 받쳐 주는가, 깊이 생각하는가, 실제로 해내는가를 따진다는 점도 함께 기억해 두면 좋아요.

쉬운 예로 설명해 볼게요. AMHS 직무는 천장 레일 위 차량으로 웨이퍼를 나르고, 어디서 막히는지 데이터로 찾아내 고치는 일이에요. 그런데 이걸 모른 채 "저는 소통을 잘합니다, 협업을 잘합니다"만 적으면 어떨까요. 어느 직무에 내도 똑같은 글이 되어 버리죠. 반대로 "신호 제어 시스템을 직접 설계해 처리 지연을 줄여 본 경험"을 구체적으로 쓰면, 평가자는 '아, 이 사람은 이 일이 뭔지 알고 준비했구나'를 단번에 느낍니다.

경험이 직무와 딱 맞아떨어지지 않아도 괜찮아요. 인턴이나 프로젝트가 가장 좋지만, 없다면 내가 가진 경험을 직무와 구조적으로 연결해 다시 풀어낼 수 있거든요. 다만 그러려면 먼저 이 직무가 무엇을 하는지부터 제대로 공부해야 합니다. 결국 이 항목의 본질은 테크닉이 아니라 공부예요. 직무를 깊이 알고 나면, 쓰는 일은 그다음 문제일 뿐이죠.

한 가지 더 있어요. 같은 직무라도 회사마다 선호하는 결이 다릅니다. 어디는 분석력을, 어디는 현장 대응력을 더 칩니다. 그러니 흔한 모범답안을 그대로 옮겨 적으면 다 똑같은 자소서가 되어 버려요. 이 회사가, 이 직무가 어떤 사람을 원하는지를 읽어 내 거기에 맞춰 쓰는 것, 그게 이 문항이 진짜로 보려는 지점입니다.

■ 풀이 방법

먼저 형식을 정확히 지키는 게 첫 단추예요. 문항이 [기간] / [경험] / [역할] 양식으로 쓰라고 못 박았으니, 그 틀을 그대로 따르세요. 여기서 흔한 실수가 칸을 채우려고 직무와 상관없는 경험까지 욱여넣는 건데, 그러지 말고 AMHS와 가장 가까운 경험부터 골라 담는 게 좋습니다. 반송 장비 같은 하드웨어를 다뤄 본 경험, 제어나 알고리즘처럼 소프트웨어를 짜 본 경험, 데이터를 분석해 병목을 찾아낸 경험, 시뮬레이션으로 미리 검증해 본 경험이 잘 맞아떨어지죠.

각 경험을 쓸 때가 진짜 승부처예요. 이 문항은 전공과 프로젝트를 콕 집어 물었으니, 소통이나 협업 같은 두루뭉술한 이야기는 과감히 빼고 담백하게 가야 합니다. 대신 '무엇을, 어떤 도구로, 어떤 과정을 거쳐, 어떤 결과를 냈는지'를 전문용어와 숫자로 또렷하게 적으세요. 예를 들어 "어떤 장비로 무엇을 계측하고, 어떤 조건을 변수로 잡아, 몇 번의 반복 실험으로 불량률을 몇 퍼센트에서 몇 퍼센트로 낮췄다"처럼요. 이렇게 디테일이 살아 있으면 '아, 이 사람 진짜 깊이 파봤구나'라는 인상이 단숨에 생깁니다.

그리고 3~5개가 그냥 흩어진 목록이 되지 않게, 이들을 하나로 꿰는 실을 깔아 두세요. 그 실은 당신만의 정성적인 강점이면 좋아요. 이를테면 '답이 나올 때까지 놓지 않는 끈질김'이나 '안 되는 걸 되게 만드는 근성' 같은 거죠. 한 가지 팁을 드리면, 강점이 '끈질김'이라면 글도 끈질기게, 한 사안을 끝까지 파고드는 방식으로 쓰는 거예요. 말과 글이 일치하면 그 강점이 훨씬 믿음직하게 읽히거든요.

마지막은 직무로 닫아 주세요. "이 경험에서 기른 이런 힘이, 반송 시스템이 어디서 왜 막히는지 데이터를 붙들고 끝까지 추적해야 하는 이 일에서 그대로 무기가 되겠다"처럼 연결하면 글 전체에 방향이 생깁니다. 한 가지만 더 당부하면, 경험이 직무와 조금 멀더라도 포기하지 마세요. 가진 경험을 직무의 언어로 다시 풀어내면 됩니다. 다만 없는 일을 지어내는 건 절대 금물이에요. 면접에서 한 겹만 더 물어보면 바로 드러나니까요.

■ 상위 1% 예시

[기간] 2025.03 ~ 2025.12

 

[경험] 반송 물류 시뮬레이션 캡스톤 / 학부 연구생

 

[역할] OHT 반송 모델 구축 및 정체 구간 개선

 

가상의 팹 라인을 시뮬레이션 도구로 그대로 옮겨, 천장 반송차 OHT가 장비 사이를 오가는 흐름을 모델로 세웠습니다. 열 대가 넘는 장비와 수십 대의 차량이 얽힌 라인을 모델에 담았는데, 첫 모델을 돌리자 특정 교차 구간에서 차량들이 서로의 길을 막아 라인 전체가 멈추는 교착이 반복됐습니다. 교착이 한 번 일어나면 여파가 라인 전체로 번지기에, 원인을 한 구간으로 좁히기까지 며칠을 로그에 매달렸습니다. 수만 건의 이동 로그를 시간순으로 되짚어, 한 구간에 진입 차량이 몰리는 순간 우회로가 닫히는 게 화근임을 잡아냈습니다. 그래서 디스패칭 규칙을 가까운 차량을 무조건 부르던 방식에서 목적지까지의 혼잡도를 함께 따져 부르는 방식으로 바꾸고, 우회 경로의 우선순위도 손봤습니다. 차량을 더 늘리는 손쉬운 답 대신 같은 자원으로 흐름을 푸는 길을 택했고, 규칙 하나를 바꿀 때마다 대기 시간과 처리량, 교착 횟수를 표로 비교하며 서른 번 넘게 조건을 다시 돌린 끝에, 평균 대기 시간을 38% 줄이고 시간당 반송 처리량을 21% 끌어올렸습니다. 한 번의 개선에 그치지 않고 어떤 조합이 가장 안정적인지 끝까지 비교한 이 과정에서, 반송 설계가 요구하는 흐름을 읽는 눈을 길렀습니다.

 

[기간] 2024.07 ~ 2024.09

 

[경험] 다중 차량 경로 제어 알고리즘 프로젝트 / 교내 SW 경진대회

 

[역할] 교착 회피 경로탐색 알고리즘 설계

 

여러 대의 차량이 좁은 격자 위를 동시에 움직일 때 서로를 막아 멈추는 문제를 풀고자 했습니다. A* 기반 경로탐색에 차량별 우선순위와 점유 예약 개념을 더했습니다. 점유 예약은 차량이 지날 칸과 시점을 미리 예약대장에 적어, 다른 차량이 같은 칸을 같은 시점에 쓰지 못하게 막는 방식이었습니다. 충돌이 예상되면 우선순위가 낮은 차량이 한 발 물러서도록 설계했는데, 처음엔 오히려 교착이 더 늘어 며칠을 헤맸습니다. 포기하지 않고 로그를 한 줄씩 따라가 보니, 예약이 풀리지 않은 채 서로 맞물리는 순환 대기가 원인이었습니다. 맞물린 차량 중 하나가 양보하도록 해제 규칙을 추가하자 매듭이 풀렸고, 교착을 줄이면서도 평균 경로가 길어지지 않도록 양보 거리를 최소로 잡는 조건까지 맞췄습니다. 그 결과 100대 동시 주행 모의에서 교착 발생을 92% 줄였습니다. 이 예약 방식은 실제 반송 제어에서 교착을 막는 핵심 원리이기도 해, 이론이 현장과 맞닿는 지점을 직접 확인할 수 있었습니다.

 

[기간] 2024.01 ~ 2024.02

 

[경험] 제조 물류 데이터 분석 공모전 / 데이터 분석 담당

 

[역할] 반송 로그 기반 병목 구간 도출

 

수십만 행의 반송 이벤트 로그에서 어디가 상습 정체 구간인지 찾는 과제였습니다. 파이썬으로 로그를 불러와 구간과 시간대를 축으로 집계하되, 단순 평균으로는 병목이 드러나지 않아 분위수로 지연의 분포를 잘게 쪼개 들여다봤습니다. 평균 뒤에 가려져 있던 상위 5%의 긴 지연이 특정 두 구간의 출퇴근 시간대에 집중된다는 패턴을 찾아냈고, 그 구간의 합류 지점 설계가 원인임을 데이터로 짚어냈습니다. 수천 건을 일일이 확인하며 분석을 왜곡할 수 있는 이상치까지 함께 걸러낸 꼼꼼함이 결과의 신뢰를 떠받쳤습니다. 왜 하필 그 시간대 그 구간인지 끝까지 캐묻지 않았다면 평균이라는 착시 뒤에서 진짜 원인을 놓쳤을 것입니다. 분석에 그치지 않고 합류 지점의 진입 순서를 조정하자는 개선안까지 함께 제시한 덕분에, 공모전에서 정체 원인을 가장 구체적으로 규명한 점을 인정받아 수상으로 이어졌습니다.

 

[기간] 2023.06 ~ 2023.08

 

[경험] 자동 반송 설비 제작 동아리 / 구동·제어 팀

 

[역할] 라인 추종 운반차 구동부 설계 및 센서 제어

 

천장이 아닌 바닥을 달리는 자율 운반차 AMR을 직접 만들며 하드웨어의 언어를 익혔습니다. 모터 드라이버와 적외선 라인 센서, 제어 보드를 엮어 정해진 경로를 따라가게 했는데, 곡선 구간마다 차량이 자꾸 경로를 벗어났습니다. 센서가 읽은 경로 오차를 모터 출력으로 되먹이는 제어 흐름을 직접 짜고, 센서 배치 간격과 속도 제어 값을 한 변수씩 바꿔 가며 쉰 번 넘게 시험 주행을 반복했습니다. 처음 다뤄 보는 장비와 회로 앞에서도 데이터시트를 뒤지고 값을 바꿔 보며 끝까지 매달린 끝에, 곡률이 큰 구간 앞에 미리 감속 구간을 두는 방식으로 주행 성공률을 70%대에서 96%로 끌어올렸습니다. 값 하나가 차량의 움직임을 어떻게 바꾸는지 손으로 만지며 익히면서, 하드웨어가 왜 그렇게 동작하는지를 알아야 그 위에서 도는 소프트웨어도 제대로 설계할 수 있다는 걸 배웠습니다.

 

네 경험에서 다룬 도구도 분야도 모두 달랐지만, 관통하는 자세는 하나였습니다. 흐름이 멈춘 자리를 데이터로 찾아 답이 나올 때까지 파고드는 집요함입니다. AMHS는 반송이 어디서 왜 막히는지를 끝까지 추적해 뚫어내야 하는 일이고, 그 일에는 한 번의 개선에 만족하지 않고 가장 안정적인 답을 찾을 때까지 놓지 않는 끈기가 필요합니다. 그 흐름이 멈추지 않을 때 수천억 원짜리 장비가 쉬지 않고 돌아간다는 것을 알기에, 막힌 동맥을 끝내 뚫어내 온 이 집요함을, 진단에서 멈추지 않고 반드시 답을 손에 쥐는 자세로, 멈추지 않는 팹의 반송 흐름을 지키는 무기로 쓰겠습니다.