# ㈜크레셈 자기소개서 — S/W 개발자(제어)

---

## 1. 지원동기 — 제어 소프트웨어가 만드는 차이

저는 크레셈이 하드웨어 제어기를 소프트웨어 모션 제어로 전환하며 IT와 OT를 융합해 가는 방향에 주목해 지원했습니다.

크레셈은 2D/3D 비전, AI 라이브러리, C# 기반 제어 프로그램을 결합해 검사장비를 개발하고 있습니다. 고객별 공정에 맞는 장비를 플랫폼 기술 위에서 빠르게 커스터마이징한다는 점이 인상 깊었습니다. WMX 소프트웨어 모션 제어 도입 사례에서는 관리 인력을 12명에서 1명으로 줄이고 장비 면적을 1/20로 축소한 결과가 나왔습니다. 검사장비의 경쟁력이 결국 제어 소프트웨어의 안정성과 확장성에서 결정된다고 판단한 계기였습니다.

저는 C# 기반 라이브러리와 백엔드 시스템을 직접 설계하고 운영해왔습니다. 그 과정에서 외부 시스템과의 안정적 연동, 장기 실행 작업의 신뢰성 확보를 핵심 과제로 다뤘습니다. Blazor WebAssembly용 대용량 파일 업로드 라이브러리에서는 .NET과 JavaScript 모듈의 생명주기를 안전하게 관리했고, 그 결과를 NuGet에 배포했습니다. ASP.NET Core 기반 파일 서비스에서는 외부 업로드 서버와 동기화되는 상태 머신을 CAS 패턴으로 설계해 중복 실행을 차단했습니다.

이런 경험은 센서·모션·후속 공정 장비를 잇는 검사장비 제어 소프트웨어에서 그대로 쓰일 수 있다고 생각합니다. 융합·정열·신뢰를 핵심 가치로 두는 크레셈의 방향과 제 개발 경험이 맞닿아 있다고 판단해 지원했습니다.

---

## 2. 업무 시 강점 — 외부 시스템의 상태를 끝까지 책임지다

저의 가장 큰 강점은 외부 시스템과 연결된 작업의 상태를 끝까지 책임지고 안정화하는 역량입니다.

ASP.NET Core 기반 셀프호스팅 파일 서비스 CloudSharp를 설계할 때 동시성 문제를 마주했습니다. 여러 클라이언트가 같은 업로드 세션을 동시에 완료 처리하면, 파일이 중복 등록되거나 메타데이터가 어긋날 수 있는 구조였습니다. 외부 업로드 서버 tusd가 보내는 hook과 백그라운드 worker가 같은 세션을 동시에 건드릴 수 있었기 때문입니다.

분산 락 인프라를 추가하지 않고 해결하기 위해, 저는 PostgreSQL의 단일 UPDATE 문을 락으로 사용하는 CAS 패턴을 설계했습니다. `UPDATE upload_session SET status='FINALIZING' WHERE status='UPLOADING'` 쿼리에서 영향받은 행이 1이면 점유 성공, 0이면 다른 프로세스가 처리 중이라고 판단하도록 했습니다. 또한 느린 파일 I/O와 짧은 DB 트랜잭션의 경계를 분리해 락 점유 시간을 최소화했습니다. 10분 이상 점유 상태에 머무는 세션은 별도 Recovery Worker가 자동으로 복구하도록 구성했습니다.

그 결과 외부 락 인프라 없이 동시 finalize 중복 실행을 차단했고, 장애 시에도 운영자 개입 없이 시스템이 정상 상태로 돌아오도록 만들었습니다.

검사장비 제어 프로그램은 센서, 모션 제어기, 후속 공정 장비와 동시에 통신하는 영역입니다. 어느 한 단계라도 어긋나면 공정 전체가 멈춥니다. 이 경험에서 익힌 상태 머신 설계와 동시성 제어 방식을, 크레셈의 검사장비 제어 소프트웨어에서도 같은 원칙으로 적용해 장비 안정성에 기여하겠습니다.

---

## 3. 입사 후 포부 — 안정성과 확장성을 함께

입사 후에는 검사장비의 안정성과 확장성을 함께 책임지는 제어 소프트웨어 개발자로 성장하고 싶습니다.

크레셈은 한 대의 장비를 만드는 데 그치지 않습니다. 2D/3D 비전, Dual-Layer AI Filtering, MLOps 서버, Inline 자동화를 하나의 플랫폼으로 통합해 가는 방향을 갖고 있습니다. 이런 환경에서 제어 소프트웨어는 센서, AI 모듈, 후속 공정 장비를 잇는 중심축이 되어야 한다고 생각합니다.

입사 초기 6개월 동안은 기존 장비의 C# 제어 코드와 MMI 구조를 빠르게 이해하는 데 집중하겠습니다. 실제 운영되는 검사 공정의 흐름을 따라가며 장비 시퀀스, 통신 프로토콜, 사용자 운영 패턴을 익히겠습니다. 작은 기능부터 단독으로 구현하며 도메인 감각을 쌓겠습니다.

1년 차에는 신규 검사장비 제어 모듈을 단독으로 맡아 설계부터 현장 적용까지 책임지는 단계로 올라가고 싶습니다. 외부 시스템과의 통신 안정화, 비정상 상황에서의 복구 시퀀스 설계, MMI 사용성 개선 영역에서 측정 가능한 결과를 만들겠습니다.

3년 차에는 플랫폼 기술의 한 축을 담당하는 개발자가 되고 싶습니다. 여러 장비에서 반복되는 제어 패턴을 공통 모듈로 정리하겠습니다. AI 검사 결과, 모션 제어, Inline 자동화 시퀀스가 하나의 흐름으로 동작하도록 구조를 다듬는 일에 기여하고자 합니다.

반도체 검사 공정과 대규모 장비 운영 경험은 아직 부족합니다. 다만 C# 기반 라이브러리와 ASP.NET Core 백엔드를 직접 설계하고 NuGet과 Docker 환경에 배포해본 경험이 있어, 새로운 도메인에도 빠르게 적응할 수 있다고 생각합니다.

---

## 4. 자기소개 / 성장 과정 — 동작하는 코드에서 끝나지 않게

저는 동작하는 코드를 만드는 단계에서 멈추지 않고, 그 코드가 운영 환경에서 어떻게 견디는지를 끝까지 확인하려는 개발자입니다.

처음 개발을 본격적으로 한 것은 Blazor WebAssembly 환경에서 대용량 파일 업로드 라이브러리를 만들면서였습니다. 기능이 동작하는 데까지는 어렵지 않았습니다. 그러나 네트워크가 끊기거나 브라우저가 닫혔을 때 이어 올리는 재개 동작, JavaScript 모듈과 .NET 객체 사이의 생명주기를 안전하게 관리하는 일은 전혀 다른 문제였습니다.

이 라이브러리를 NuGet에 배포하고 외부에서 사용 가능한 상태로 만들면서 한 가지를 체감했습니다. "동작한다"와 "다른 사람이 안전하게 쓸 수 있다" 사이에는 큰 거리가 있다는 것입니다. 그 뒤로는 어떤 프로젝트를 하더라도 상태 머신과 실패 시나리오를 먼저 정리하는 습관이 생겼습니다.

이후 셀프호스팅 파일 서비스를 직접 설계하면서 이 관점을 한 단계 확장했습니다. 외부 업로드 서버, DB, Redis, 파일 시스템이 동시에 움직이는 환경에서 어느 한 곳이 실패해도 전체 정합성이 깨지지 않도록 트랜잭션 경계와 복구 로직을 설계했습니다.

지금의 저는 새로운 기능을 마주할 때 "이 동작이 실패하면 어떻게 복구되는가"를 가장 먼저 고민하는 개발자입니다. 검사장비 제어 소프트웨어처럼 한 번의 오작동이 공정 전체에 영향을 주는 영역에서, 이 사고방식이 가장 잘 쓰일 수 있다고 생각합니다.

---

### 작성 시 반영한 컨벤션 요약

| 항목 | 적용 방식 |
|---|---|
| **두괄식** | 모든 문항 첫 문장에서 결론 제시 |
| **회사 연결** | WMX 도입 사례, Dual-Layer AI Filtering, MLOps, Inline 자동화 등 크레셈 고유 키워드 인용 |
| **STAR 구조** | 강점 문항을 CloudSharp CAS 사례로 S→T→A→R→입사 후 연결 순으로 전개 |
| **수치 결과** | 인력 12→1명, 면적 1/20, 점유 시간 10분 임계 등 구체 수치 사용 |
| **금지 표현 회피** | "열정", "최선", "인재", "누구보다" 미사용 |
| **사례 분리** | 지원동기·강점·자기소개에 각각 다른 초점(연결성 / 동시성 제어 / 성장 전환점) 배치 |
| **소제목** | 문항명 반복 없이 핵심 메시지로 작성 |

추가로 다른 문항(예: 협업 경험, 실패 경험, 1분 자기소개)이 필요하면 같은 컨벤션으로 이어서 작성하겠습니다.