# SG커뮤니티 자기소개서

## 1. 지원동기

### 두 언어로 쌓은 경험이 닿는 지점

저는 귀사의 클라우드 기반 MES 전환 방향과 Java/.NET 이중 기술 스택 운영 방식에 주목해 지원했습니다.

귀사는 현대·기아차 그룹사의 생산정보시스템을 개발하면서, AWS와 ASP.NET Core, Java를 함께 사용해 MES를 클라우드 마이크로서비스 구조로 현대화하고 있는 것으로 파악했습니다. 특히 제조현장의 실시간 데이터 수집과 ERP·SCM 연계가 시스템 안정성을 좌우한다는 점이 인상 깊었습니다.

저는 그동안 Java/Spring Boot 기반 협업 플랫폼(Didit)과 .NET 기반 셀프호스트 파일 서비스(CloudSharp)를 양쪽 모두 설계하며, 두 생태계를 오가는 경험을 쌓아왔습니다. Didit에서는 Redis Pub/Sub과 SSE로 AI Worker의 분석 결과를 특정 사용자에게 실시간 전달하는 구조를 구현했고, CloudSharp에서는 ASP.NET Core 기반 Clean Architecture와 Docker Compose 5-서비스 오케스트레이션을 직접 구성했습니다.

이러한 양면 경험은 귀사가 추구하는 클라우드 MES의 실시간성과 신뢰성 요구에 그대로 연결됩니다. 두 언어 환경을 자연스럽게 오가며 제조현장 시스템 개발에 기여하고 싶어 지원을 결심했습니다.

---

## 2. 업무 시 강점

### 동시성 문제를 끝까지 추적하다

저의 가장 큰 강점은 분산 시스템의 동시성 문제를 구조적으로 해결하는 역량입니다.

CloudSharp 프로젝트에서 tus 프로토콜 기반 대용량 파일 업로드의 Finalize 단계에 동시성 문제가 있었습니다. 여러 hook 콜백과 백그라운드 Worker가 동일 업로드 세션을 두 번 처리해, 같은 파일이 중복 생성될 위험이 있었습니다. 분산 락을 도입하면 ZooKeeper나 Redis Redlock 같은 추가 인프라가 필요했습니다.

저는 추가 인프라 없이 해결할 방법을 찾기 위해 UploadSession의 상태 머신을 락으로 재활용하는 CAS(Compare-And-Swap) 방식을 설계했습니다. `UPDATE upload_session SET status='FINALIZING' WHERE status='UPLOADING'` 단일 SQL로 원자적 점유를 구현했고, 영향 행 수가 1이면 점유 성공, 0이면 이미 처리 중으로 판정했습니다. 또한 파일 이동이라는 느린 I/O와 DB 트랜잭션 경계를 분리해 락 지속 시간을 최소화했고, 10분 이상 FINALIZING 상태에 머문 세션을 자동 복구하는 Recovery Worker도 함께 구현했습니다.

그 결과 추가 인프라 없이 중복 실행을 0건으로 차단하면서, 장애 발생 시 자동 복구되는 구조를 만들었습니다. 입사 후에도 MES처럼 실시간성과 정합성이 함께 요구되는 시스템에서 이러한 분석·설계 방식으로 기여하겠습니다.

---

## 3. 입사 후 포부

### 안정성과 확장성을 함께 고민하다

입사 후에는 귀사의 클라우드 기반 MES 전환 방향 안에서, 실시간성과 안정성을 함께 책임지는 개발자로 성장하고 싶습니다.

입사 초기에는 귀사의 MES 도메인과 자동차 제조 공정을 빠르게 익히는 데 집중하겠습니다. 기존 코드베이스와 Java/.NET 양쪽 모듈의 흐름을 파악하고, AWS 운영 구조와 배포 파이프라인을 학습해 작은 기능부터 단독으로 수행할 수 있는 수준에 도달하겠습니다.

1년 내에는 MES 모듈 단위 기능을 책임지고 개발하며, 실시간 데이터 수집과 ERP 연동 구간의 품질 개선에 기여하고 싶습니다. 그동안 Result 패턴과 정합성 검증으로 쌓은 안정적 코드 작성 습관을 적용해 운영 장애를 줄이는 데 보탬이 되겠습니다.

3년 내에는 클라우드 마이크로서비스 구조 개선을 제안할 수 있는 개발자로 성장하겠습니다. CloudSharp에서 Docker Compose 기반 멀티 서비스 오케스트레이션과 Healthcheck/Recovery 구조를 설계한 경험을 바탕으로, MES의 모놀리식-마이크로서비스 전환 과정에서 구조적 의사결정에 참여하고 싶습니다.

대규모 제조 현장 운영 경험은 아직 부족하지만, 개인 프로젝트에서 분산 환경의 정합성 문제와 장애 복구를 직접 설계해본 경험을 바탕으로 빠르게 보완해나가겠습니다.

---

## 4. 자기소개 / 성장 과정

### 동작하는 코드에서 견고한 코드로

저는 단순히 기능이 동작하는 것을 넘어, 실패와 동시성을 미리 가정하고 설계하는 개발자입니다.

처음 개발을 시작했을 때는 화면에 결과가 보이면 만족했습니다. 그러나 Didit 프로젝트에서 AI Worker가 장시간 추론하는 동안 API 응답이 묶이는 문제와, 결과가 모든 사용자에게 전파되는 문제를 마주하면서 생각이 바뀌었습니다. 단순 구현으로는 해결되지 않고, Redis Pub/Sub 기반 비동기 큐와 사용자별 클라이언트 키 매핑이라는 구조 자체를 다시 설계해야 했습니다.

이 경험 이후 저는 어떤 기능을 구현하기 전에, 어떤 실패가 발생할 수 있는지부터 정리하는 습관을 갖게 되었습니다. CloudSharp에서는 업로드 중복, Quota 경합, 파일명 충돌 같은 시나리오를 사전에 도출하고 CAS, Row-level Lock, 명시적 실패 반환이라는 정책으로 분리해 설계했습니다. 술통여지도에서는 GPT의 hallucination을 방어하기 위해 허용 ID Set 검증과 거리순 폴백을 다층으로 배치해 잘못된 추천을 0건으로 차단했습니다.

이런 경험이 쌓이며 저는 시스템의 정합성과 복구 가능성을 함께 고민하는 백엔드 개발자로 성장해왔습니다. 제조현장처럼 잠깐의 오류도 운영에 영향을 주는 환경에서, 이러한 사고방식으로 신뢰할 수 있는 시스템을 만드는 데 기여하고 싶습니다.

---