vault backup: 2026-05-07 22:19:19

2026-05-07 22:19:19 +09:00
parent ab57f88d80
commit d9a468cdda
12 changed files with 1335 additions and 3 deletions
--- a/.obsidian/plugins/copilot/data.json
+++ b/.obsidian/plugins/copilot/data.json
@@ -6,7 +6,7 @@
  "openAIOrgId": "",
  "huggingfaceApiKey": "",
  "cohereApiKey": "",
-  "anthropicApiKey": "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",
+  "anthropicApiKey": "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",
  "azureOpenAIApiKey": "",
  "azureOpenAIApiInstanceName": "",
  "azureOpenAIApiDeploymentName": "",
@@ -24,7 +24,7 @@
  "githubCopilotToken": "",
  "githubCopilotTokenExpiresAt": 0,
  "defaultChainType": "llm_chain",
-  "defaultModelKey": "claude-sonnet-4-6|anthropic",
+  "defaultModelKey": "claude-opus-4-7|anthropic",
  "embeddingModelKey": "openai/text-embedding-3-small|openrouterai",
  "temperature": 0.1,
  "maxTokens": 6000,
--- a/.obsidian/plugins/copilot/main.js
+++ b/.obsidian/plugins/copilot/main.js
--- a/자기소개서/SG커뮤니티.md
+++ b/자기소개서/SG커뮤니티.md
@@ -0,0 +1,76 @@
+# 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건으로 차단했습니다.
+
+이런 경험이 쌓이며 저는 시스템의 정합성과 복구 가능성을 함께 고민하는 백엔드 개발자로 성장해왔습니다. 제조현장처럼 잠깐의 오류도 운영에 영향을 주는 환경에서, 이러한 사고방식으로 신뢰할 수 있는 시스템을 만드는 데 기여하고 싶습니다.
+
+---
+
+## 최종 체크리스트
+- [x] 회사 연결: SG커뮤니티의 MES, AWS, Java/.NET 이중 스택, 마이크로서비스 전환 방향 반영
+- [x] 경험 증명: Didit, CloudSharp, 술통여지도의 구체적 기술 판단과 행동 명시
+- [x] 수치 결과: "중복 0건", "10분 이상 FINALIZING 자동 복구" 등 측정 가능한 표현
+- [x] 입사 후 기여: 초기/1년/3년 타임라인으로 회사 방향과 성장 계획 연결
+- [x] 금지 표현 제거: "열정", "최선", "인재", "누구보다" 등 미사용
+- [x] 두괄식: 모든 문항 첫 문장에서 결론 노출
+- [x] 소제목: 15자 내외, 추상적이지 않음
+
+---
+
+**보완 가능 포인트** (필요 시 알려주세요)
+1. 자소서 글자 수 제한이 다른 경우 → 500자 / 1000자 버전으로 재구성
+2. SG커뮤니티 채용공고에 별도 문항(예: 협업 경험, 갈등 해결)이 있는 경우 → 추가 문항 작성
+3. Java 또는 .NET 한쪽으로 비중 강조 필요 시 → 기술 매칭 재조정
+4. 신입/경력 여부에 따라 보완점 톤 조정
--- a/자기소개서/마준소프트.md
+++ b/자기소개서/마준소프트.md
@@ -0,0 +1,65 @@
+# 마준소프트㈜ 자기소개서
+
+## 1. 지원동기
+
+### 인프라 운영과 자동화의 교차점
+
+저는 마준소프트의 하이브리드 인프라 운영 방향에 주목해 지원했습니다.
+
+SK-IDC와 KT-IDC를 직접 운영하면서도 NHN클라우드와 협력해 영역을 넓히는 흐름이 인상 깊었습니다. 여기에 RCS와 AI 연산 서버로 서비스를 확장하는 모습은, 단순한 서버 임대를 넘어 운영 자동화와 지능화를 함께 고민하는 방향이라고 판단했습니다.
+
+이러한 방향성은 셀프호스트 파일 서비스 CloudSharp를 설계하며 마주한 문제의식과 맞닿아 있습니다. 해당 프로젝트에서는 PostgreSQL, Redis, tusd, ASP.NET Core, nginx 다섯 개 서비스를 Docker Compose로 오케스트레이션했습니다. internal 네트워크로 DB와 Redis를 격리해 외부 진입점을 nginx 하나로 제한했습니다. healthcheck 조건으로 서비스 기동 순서를 보장하고, Multi-stage Dockerfile로 이미지 크기도 함께 줄였습니다.
+
+이 과정에서 인프라 안정성은 좋은 장비가 아니라 예측 가능한 운영 구조에서 나온다는 점을 배웠습니다. 자체 IDC와 클라우드를 함께 운영하며 보안 인증을 꾸준히 관리해 온 마준소프트라면, 그동안 쌓아 온 인프라 설계 경험을 실제 운영 환경에서 더 깊게 발전시킬 수 있다고 판단해 지원을 결심했습니다.
+
+---
+
+## 2. 업무 시 강점
+
+### 측정 가능한 결과로 증명하는 AI 최적화
+
+저의 가장 큰 강점은 AI 시스템의 비용과 품질을 동시에 개선하는 역량입니다.
+
+술통여지도(Sulmap) 프로젝트에서 GPT-5.2 기반 술집 추천 엔진을 설계할 때 두 가지 문제에 부딪혔습니다. 반경 내 후보가 최대 200개에 이르러 한 번에 전송하면 입력이 16,000토큰을 넘었습니다. 게다가 GPT가 후보에 없는 술집을 만들어 내는 hallucination도 발생했습니다.
+
+먼저 토큰 비용 문제를 해결하기 위해 2단계 Cascade Ranking 구조를 직접 설계했습니다. 200개를 100개씩 배치로 나눠 1단계에서는 ID만 반환하는 형태로 top 5씩 선별했습니다. 2단계에서는 최대 40개만 정밀 랭킹해 Top 10과 추천 이유를 생성했습니다. 여기에 더해 JSON 대신 도메인 특화 Pipe-delimited Format을 정의했습니다. 키 이름과 따옴표 같은 구조 문자가 차지하던 토큰을 제거하기 위한 선택이었습니다.
+
+다음으로 hallucination 문제는 프롬프트와 코드 양쪽에서 방어했습니다. 시스템 프롬프트에서는 후보 외 ID 생성을 명시적으로 금지했습니다. 코드 레벨에서는 정규식으로 입력 B 라인에서 허용 ID Set을 추출해, GPT 응답을 즉시 대조하고 필터링했습니다. 부족한 결과는 거리순 fallback으로 채워 사용자 경험도 보장했습니다.
+
+그 결과 호출당 토큰을 1단계에서 약 70%, 포맷 변경으로 추가 40% 절감했고 잘못된 ID 노출은 0건으로 차단했습니다. 단순한 기능 구현이 아니라 비용·품질·신뢰성을 수치로 증명하는 방식을 익혔습니다. 같은 접근을 마준소프트의 AI 연산 서버 운영과 서비스 지능화 업무에도 그대로 적용하겠습니다.
+
+---
+
+## 3. 입사 후 포부
+
+### 운영 부담을 코드로 줄이는 개발자
+
+입사 후에는 IDC 운영과 클라우드 인프라를 코드로 자동화하는 개발자로 성장하고 싶습니다.
+
+마준소프트는 자체 IDC를 운영하면서도 NHN클라우드 파트너십과 RCS, AI 연산 서버로 영역을 넓히고 있습니다. 이런 환경에서는 반복 운영 작업과 모니터링을 코드로 옮기는 역할이 점점 더 중요해진다고 판단했습니다.
+
+입사 초기 6개월은 ASP/PHP 기반 코드베이스와 IDC 운영 프로세스, 보안 정책을 빠르게 파악하는 데 집중하겠습니다. 기존 운영 흐름을 충분히 이해한 뒤에야 자동화 대상이 보인다고 생각하기 때문입니다.
+
+1년 차에는 반복적인 서버 점검과 로그 수집을 Python 스크립트와 알림 파이프라인으로 전환하겠습니다. CloudSharp에서 Recovery Worker와 healthcheck 기반 기동 순서를 설계해 본 경험이 있습니다. 이 경험을 운영 자동화 영역에 그대로 옮겨 적용할 수 있다고 봅니다.
+
+3년 차에는 AI 연산 서버의 부하 예측과 비정상 트래픽 탐지, 보안 점검 자동화처럼 지능화 영역에 기여하고 싶습니다. Sulmap에서 GPT 호출의 비용·품질을 수치로 측정하고 개선했던 방식으로, 운영 지표를 수치로 정의하고 줄여 나가는 데 보탬이 되겠습니다.
+
+ASP/PHP 실서비스 운영 경험은 아직 부족합니다. 다만 Java와 C# 기반 백엔드와 Linux 컨테이너 운영 경험을 토대로 학습 기간을 꾸준히 줄여 나가고 있습니다.
+
+---
+
+## 4. 자기소개 / 성장 과정
+
+### 동작하는 코드에서 예측 가능한 시스템으로
+
+저를 한 문장으로 소개하면, 동작하는 코드에서 예측 가능한 시스템으로 관심이 옮겨 간 개발자입니다.
+
+처음 개발을 시작했을 때는 기능이 동작하면 충분하다고 생각했습니다. 그러나 셀프호스트 파일 서비스 CloudSharp를 설계하며 그 생각이 바뀌었습니다.
+
+대용량 업로드를 tusd로 처리하던 중 같은 업로드가 두 번 Finalize되는 경쟁 상태가 보였습니다. 이를 막기 위해 단일 SQL 한 줄로 점유 여부를 판정하는 CAS 방식을 도입했습니다. 10분 이상 멈춘 세션은 Recovery Worker가 자동 복구하도록 구성했습니다. Quota 경쟁 조건도 PostgreSQL의 row-level lock으로 판정과 예약을 한 트랜잭션 안에서 원자화해 해결했습니다.
+
+이 과정에서 좋은 시스템은 장애가 없는 시스템이 아님을 배웠습니다. 좋은 시스템은 장애가 어떻게 일어나고 어떻게 복구되는지 설명할 수 있는 시스템이었습니다.
+
+이후 TusBlazorClient를 NuGet 패키지로 공개하면서 같은 원칙을 라이브러리 설계에도 적용했습니다. JS 모듈은 Lazy 로딩으로 묶고, IAsyncDisposable로 생명주기를 명확히 노출했습니다. 사용하는 쪽에서 동작과 비용을 예측할 수 있도록 만든 선택이었습니다.
+
+이러한 경험을 바탕으로 마준소프트의 IDC와 AI 서버 운영 환경에 합류하고 싶습니다. 결과를 수치로 설명할 수 있는 예측 가능한 시스템을, 마준소프트의 운영 노하우 위에서 함께 만들어 가겠습니다.
--- a/자기소개서/씨앤지
+++ b/자기소개서/씨앤지
@@ -0,0 +1,77 @@
+# 씨앤지 마이크로웨이브 자기소개서
+
+> 작성 기준: IT 개발자 자기소개서 컨벤션, 직무: S/W 개발(위성추적·모션 및 계측기 제어 / 안테나 측정 소프트웨어 개발)
+
+---
+
+## 1. 지원동기
+
+### 정밀 제어와 .NET 경험이 만나는 자리
+
+귀사가 국내 최초로 확보한 CATR 측정 기술과 .NET 기반의 제어 소프트웨어 개발 환경에 주목해 지원했습니다.
+
+채용공고를 확인하며 위성추적·계측기 제어 소프트웨어가 C#과 WPF로 개발된다는 점을 확인했습니다. 안테나 측정 시스템은 단순 GUI 애플리케이션이 아니라, 포지셔너와 계측기, 데이터 분석이 하나의 흐름으로 연결되어야 하는 영역이라고 판단했습니다. 이런 환경에서는 외부 하드웨어와 안정적으로 통신하는 .NET 인터페이스 설계 능력이 핵심 역량이 된다고 보았습니다.
+
+저는 .NET 환경에서 외부 라이브러리와 통신하는 인터페이스를 직접 설계하고 NuGet에 배포한 경험이 있습니다. Blazor WebAssembly에서 JavaScript tus 프로토콜 라이브러리를 C# API로 래핑한 TusBlazorClient 프로젝트입니다. 이 과정에서 콜백 브릿지 설계, 비동기 리소스 생명주기 관리, 외부 시스템 호출 비용 최적화를 직접 다뤘습니다.
+
+이러한 외부 시스템 연동 설계 경험은 안테나 측정 소프트웨어가 다양한 계측기와 포지셔너를 동시에 제어해야 하는 환경에서 그대로 활용될 수 있다고 보았습니다. 귀사가 추구하는 신뢰성 있는 측정 시스템과 제가 쌓아온 .NET 인터페이스 설계 경험이 맞닿아 있다는 점이 지원을 결심한 가장 큰 이유입니다.
+
+---
+
+## 2. 업무 시 강점
+
+### 외부 시스템과 안정적으로 연결하는 설계
+
+저의 가장 큰 강점은 .NET 환경에서 외부 시스템과 안정적으로 연결되는 소프트웨어를 설계하는 역량입니다.
+
+Blazor WebAssembly에서 대용량 파일 업로드를 처리하는 라이브러리 TusBlazorClient를 단독으로 개발해 NuGet에 배포한 경험이 있습니다. Blazor WASM은 순수 C# I/O만으로 대용량 전송이 어려워, 검증된 JavaScript 라이브러리를 C# API로 래핑하는 방식이 필요했습니다.
+
+가장 큰 문제는 .NET 델리게이트가 JSON 직렬화 대상이 아니라는 점이었습니다. JS와의 콜백 브릿지를 직접 설계해야 했습니다. 모든 콜백을 단일 객체에 모아 `DotNetObjectReference`로 전달하고, 옵션 직렬화 시에는 `[JsonIgnore]`로 콜백을 분리했습니다. 또한 각 콜백의 null 여부를 별도 객체로 JS에 전달해, 사용하지 않는 콜백은 `invokeMethodAsync` 호출 자체가 발생하지 않도록 최적화했습니다. JS 모듈은 `IAsyncDisposable`과 Lazy 초기화로 생명주기를 관리해, 사용하지 않는 페이지에서는 모듈이 아예 로드되지 않도록 구성했습니다.
+
+그 결과 18개 tus 옵션과 7종 콜백을 C#에 완전히 매핑했고, Selenium 기반 9개 E2E 테스트로 업로드, 재개, 옵션 동적 변경 시나리오를 검증했습니다. 현재 NuGet에 v1.0.1로 배포되어 외부 프로젝트에서 그대로 설치해 사용할 수 있습니다.
+
+이 경험을 통해 외부 시스템과의 호출 비용을 측정하고 줄이는 설계 방식을 익혔습니다. 안테나 측정 소프트웨어 역시 다양한 계측기·포지셔너와 실시간으로 통신해야 하므로, 동일한 방식으로 안정적인 제어 흐름과 자원 관리 구조를 설계하는 데 기여하겠습니다.
+
+---
+
+## 3. 입사 후 포부
+
+### 측정 정확도를 코드로 지키는 개발자
+
+입사 후에는 귀사의 정밀 측정 환경 안에서 안정성과 정확도를 책임지는 .NET 개발자로 성장하고 싶습니다.
+
+귀사는 CATR, Near-Field, Far-Field 등 다양한 측정 환경을 운용하며, 각 환경에서 측정 편차를 최소화해야 한다는 도전을 갖고 있습니다. 이를 코드 측면에서 뒷받침하려면 계측기 통신 프로토콜, 포지셔너 모션 제어, 측정 데이터 처리 흐름을 정확히 이해해야 한다고 판단했습니다.
+
+입사 초기에는 기존 C#·WPF·DevExpress 기반 소프트웨어 코드베이스와 사용 중인 계측기 통신 프로토콜을 빠르게 파악하는 데 집중하겠습니다. .NET 기반 백엔드와 클라이언트 라이브러리를 직접 설계해 본 경험이 있어, 언어와 프레임워크 학습 시간보다 도메인 학습에 시간을 투자할 수 있다고 생각합니다.
+
+1년 차에는 모션 제어 또는 안테나 측정 모듈에서 단일 기능을 단독으로 책임지고 구현해, 측정 자동화 흐름의 한 축을 안정적으로 담당하고자 합니다. 3년 차에는 측정 소프트웨어 구조 개선이나 신규 계측기·프로토콜 통합 작업을 주도해, 새로운 측정 환경을 도입하는 속도를 높이는 데 기여하고 싶습니다.
+
+안테나·RF 도메인 경험은 아직 부족하지만, 측정 자동화에 필요한 비동기 처리, 실시간 데이터 흐름, 외부 시스템 연동은 기존 프로젝트에서 직접 다뤄왔습니다. 도메인 지식은 사내 학습과 실무 경험을 통해 빠르게 보완하면서, 코드 품질과 측정 신뢰성을 함께 지키는 개발자로 성장하겠습니다.
+
+---
+
+## 4. 자기소개 / 성장 과정
+
+### 동작하는 코드에서 지속 가능한 코드로
+
+저는 동작하는 코드에서 멈추지 않고 유지보수 가능한 구조를 고민하는 개발자로 성장해 왔습니다.
+
+처음 개발을 시작했을 때는 기능 구현 자체가 목표였습니다. 그러나 셀프호스팅 파일 서비스인 CloudSharp 프로젝트를 진행하며, 단순 구현만으로는 운영을 견디기 어렵다는 사실을 직접 경험했습니다. 대용량 파일 업로드 과정에서 동시 요청이 같은 자원을 두고 경쟁하거나, 외부 업로드 서버의 콜백이 중복 도달하는 문제가 반복적으로 발생했습니다.
+
+이 문제를 풀기 위해 CAS(Compare-And-Swap) 기반 동시성 제어와 Recovery Worker 구조를 직접 설계했습니다. 단일 SQL UPDATE 문으로 업로드 세션을 원자적으로 점유하고, 교착 상태는 별도 워커가 자동으로 복구하도록 만들었습니다. 그 결과 추가 분산 락 인프라 없이도 중복 처리 0건을 유지할 수 있었고, 동시 업로드 환경에서 자원 경쟁 문제도 트랜잭션 단위에서 차단되었습니다.
+
+이 경험 이후로는 새로운 기능을 구현할 때마다 “이 코드가 실패할 수 있는 지점은 어디인가”를 먼저 묻습니다. Result 패턴으로 실패를 명시적으로 다루고, Clean Architecture로 도메인 경계를 분리하며, 주요 결정마다 ADR로 근거를 남기는 방식이 자연스러운 습관이 되었습니다.
+
+지금의 저는 화려한 기능보다 측정 가능한 결과와 재현 가능한 구조를 신뢰하는 개발자입니다. 이러한 방식은 안테나 측정처럼 정밀성과 반복성이 핵심인 영역에서 더 큰 가치를 발휘한다고 생각합니다.
+
+---
+
+## 최종 체크리스트
+
+- [x] 회사 연결 — CATR, C#/WPF, 계측기 제어 등 채용공고·홈페이지 정보 반영
+- [x] 경험 증명 — TusBlazorClient(강점), CloudSharp(성장 과정)로 사례 분리
+- [x] 수치 결과 — NuGet v1.0.1, 18개 옵션, 7종 콜백, 9개 E2E 테스트, 중복 처리 0건
+- [x] 입사 후 기여 — 초기/1년/3년 단계별 계획 + 보완점 명시
+- [x] 금지 표현 제거 — 열정·최선·인재·누구보다 등 미사용
+- [x] 두괄식 — 4개 문항 모두 첫 문장에서 결론 제시
+- [x] 사례 분리 — 같은 프로젝트가 동일한 방식으로 반복되지 않음
--- a/자기소개서/아레스.md
+++ b/자기소개서/아레스.md
@@ -0,0 +1,63 @@
+# (주)아레스 자기소개서
+
+---
+
+## 지원동기
+
+### 시뮬레이터 안에서 본 익숙한 문제
+
+저는 귀사의 VR 낙하산 강하 시뮬레이터 APS®를 살펴보며 익숙한 문제의식을 발견했습니다. 풍향·풍속·기상 효과를 실시간으로 반영하면서 모션 제어와 3D 렌더링을 동기화하는 구조는, 결국 **다중 사건의 동시 처리와 일관성 보장** 문제로 수렴합니다. 이 지점이 제가 백엔드에서 다뤄온 업로드 파이프라인의 동시성 제어 문제와 본질적으로 같다고 판단했습니다.
+
+CloudSharp 프로젝트에서는 tus 프로토콜 기반 대용량 업로드의 Finalize 단계에서 중복 실행 문제를 마주했습니다. 분산 락 인프라 없이도 단일 SQL UPDATE 기반 CAS 패턴으로 원자적 점유를 구현했고, 파일 I/O와 DB 트랜잭션을 분리해 안전성과 응답성을 함께 확보했습니다. 이 과정에서 "정확성을 보장하면서도 실시간성을 잃지 않는 구조"가 백엔드뿐 아니라 시뮬레이션의 핵심 가치라는 점을 체득했습니다.
+
+귀사가 강조하는 Agile & DevOps 기반의 지속적 통합과 TDD 문화 또한 제 개발 방식과 맞닿아 있습니다. CloudSharp에서는 14개의 코딩 컨벤션과 ADR을 함께 운영하고 GitLab CI로 단위·인프라 테스트를 자동화했습니다. 단순한 기능 구현이 아니라 품질을 측정 가능한 형태로 관리하는 개발 문화를 직접 만들어본 경험입니다.
+
+이처럼 귀사의 M&S 시뮬레이터 개발 방향과 제가 쌓아온 동시성·성능·품질 관리 경험이 자연스럽게 연결된다고 판단했고, 이것이 지원을 결심한 가장 큰 이유입니다.
+
+---
+
+## 업무 시 강점
+
+### 원인을 끝까지 추적하는 실행력
+
+저의 가장 큰 강점은 **시스템 문제의 원인을 끝까지 추적해 측정 가능한 결과로 개선하는 역량**입니다.
+
+CloudSharp 프로젝트에서 tus 기반 대용량 파일 업로드 시스템의 Finalize 단계 중복 실행 문제를 마주했습니다. tusd hook과 백그라운드 Worker 두 경로에서 같은 업로드 세션이 동시에 처리될 수 있어, 하나의 파일이 두 개의 메타데이터로 등록되는 위험이 있었습니다. 일반적인 해법은 Redis Redlock 같은 분산 락 인프라를 도입하는 것이지만, 운영 복잡도와 장애 지점이 함께 늘어나는 단점이 있었습니다.
+
+저는 별도 인프라를 추가하지 않고 **CAS(Compare-And-Swap) 패턴**을 단일 SQL UPDATE로 구현했습니다. `UPDATE upload_session SET status='FINALIZING' WHERE status='UPLOADING'` 한 줄로 원자적 점유를 보장하고, affected_rows 값으로 처리 여부를 판단했습니다. 또한 느린 파일 I/O 구간과 짧은 DB 트랜잭션 구간을 분리해, 동시성 제어 중에도 다른 요청이 블로킹되지 않도록 설계했습니다. 마지막으로 Recovery Worker를 두어 10분 이상 FINALIZING 상태에 머문 세션을 자동 복구하도록 했습니다.
+
+그 결과, 별도 분산 락 인프라 없이 **중복 Finalize를 0건으로 차단**했고, DB UNIQUE 제약과 함께 이중 안전장치를 구축할 수 있었습니다. CAS 방식은 PostgreSQL이 보장하는 원자성에만 의존하므로 추가 인프라 비용이 없고, 장애 시 자동 복구까지 포함된 견고한 구조였습니다.
+
+이 경험은 단순히 동작하게 만드는 것을 넘어, 문제의 본질을 분석하고 가장 단순하면서도 안전한 해법을 선택하는 개발 방식을 익히는 계기였습니다. 입사 후에도 시뮬레이터의 실시간성과 정확성이라는 까다로운 요구사항 앞에서, 원인을 끝까지 추적하고 측정 가능한 결과로 만드는 방식으로 기여하겠습니다.
+
+---
+
+## 입사 후 포부
+
+### 안정성과 실시간성을 함께
+
+입사 후에는 **국방 M&S 도메인의 안정성과 실시간성을 함께 책임지는 SW 개발자**로 성장하고 싶습니다.
+
+귀사는 2030년 M&S 분야 세계 중심을 목표로, VR·AR·MR·XR 기술과 자체 시뮬레이션 엔진을 결합한 실감형 훈련체계를 확장하고 있습니다. 이러한 방향 안에서 시뮬레이션의 정확성과 실시간 응답성을 동시에 책임지는 개발자가 되고자 합니다.
+
+입사 초기에는 M&S 도메인 지식과 시뮬레이터 코드베이스를 빠르게 파악하는 데 집중하겠습니다. C#과 C++ 개발 경험은 이미 갖추고 있으므로, 기존 시뮬레이션 엔진의 구조와 풍향·풍속·기상 효과 같은 도메인 모델을 이해하는 것이 우선 과제입니다. Agile 스프린트 흐름에 적응하며 코드 리뷰와 TDD에 적극적으로 참여하겠습니다.
+
+1년 차에는 시뮬레이션 모듈 한 단위를 단독으로 설계하고 구현할 수 있는 수준에 도달하는 것을 목표로 합니다. CloudSharp에서 운영했던 코딩 컨벤션과 ADR 작성 경험을 살려, 팀의 CI 파이프라인과 테스트 자동화 개선에도 기여하겠습니다.
+
+3년 차에는 시뮬레이션 엔진 구조 개선과 AI·VR 기술 융합 제안에 참여할 수 있는 개발자로 성장하겠습니다. AI SW 개발 직무까지 함께 다루는 귀사의 특성상, 백엔드와 AI 연동 경험을 살려 **훈련 데이터 분석이나 행동 예측 모델을 시뮬레이터에 접목**하는 영역에서 기여할 여지가 크다고 봅니다.
+
+국방 M&S 도메인과 Unity 3D 실무 경험은 아직 부족하지만, HLA/RTI 같은 M&S 표준 자료와 Unity 기반 물리 시뮬레이션 학습을 통해 보완해 나가고 있습니다. 입사 후에도 도메인 지식과 기술 깊이를 동시에 키워, 귀사의 "World Best" 비전에 보탬이 되는 개발자로 성장하겠습니다.
+
+---
+
+## 성장 과정
+
+### 동작에서 측정으로
+
+저의 개발자 정체성은 "기능이 동작하는 것"에서 "결과를 측정할 수 있는 것"으로 관점이 바뀐 한 시점에서 형성되었습니다.
+
+처음 개발을 시작했을 때는 요구사항대로 화면이 그려지고 API가 응답하면 충분하다고 생각했습니다. 이 관점이 바뀐 계기는 .NET Blazor 환경에서 대용량 파일 업로드를 처리하기 위한 **TusBlazorClient 오픈소스 라이브러리**를 직접 만들어 NuGet에 배포하면서였습니다. 라이브러리는 제가 쓰는 코드가 아니라 다른 개발자가 쓰는 코드이므로, 동작 여부만으로는 부족했습니다. C# 델리게이트 직렬화 불가 문제, JS 모듈 생명주기, 옵션 동적 변경 등 사용자가 마주칠 수 있는 시나리오를 예측하고 Selenium E2E 테스트로 검증해야 했습니다.
+
+이 경험은 CloudSharp 프로젝트에서 더 깊어졌습니다. tus 기반 업로드 파이프라인의 Finalize 동시성 문제를 마주했을 때, "어떻게 동작하게 할까"가 아니라 "어떤 조건에서 깨질 수 있는가"부터 분석했습니다. CAS 패턴으로 분산 락 없이 원자적 점유를 보장하고, Recovery Worker로 교착 상태를 자동 복구하는 구조를 설계했습니다. 동시에 14개의 코딩 컨벤션 문서와 ADR을 정리하며 **결정의 이유까지 측정 가능한 형태로 남기는 습관**을 만들었습니다.
+
+지금의 저는 새로운 문제를 만나면 가장 먼저 원인 분석과 측정 지표부터 정의하는 개발자입니다. 단순한 기능 구현보다 시스템이 깨질 수 있는 경계 조건에 관심을 두고, 그 결과를 수치와 문서로 남기려고 합니다. 귀사의 시뮬레이터 개발에서도 정확성·실시간성·안정성이라는 까다로운 요구사항을 측정 가능한 형태로 다루는 데 기여하고 싶습니다.
--- a/자기소개서/에이투텍.md
+++ b/자기소개서/에이투텍.md
@@ -0,0 +1,78 @@
+# 에이투텍 자기소개서
+## 1. 지원동기
+
+### 데이터 품질에서 출발하는 AI 솔루션
+
+에이투텍이 강조하는 "현업 문제를 해결하는 AI 모델" 개발 방향에 주목해 지원했습니다.
+
+AX 서비스 페이지에서 SOTA 모델 조사부터 데이터 가공, 학습, 검증, REST API 구축까지 전 과정을 직접 수행한다는 점이 인상 깊었습니다. 특히 Problem 페이지에서 종이 기반 설비 유지보수 데이터를 표준화하고 통합 DB로 연결한 뒤 예지정비 모델을 적용한 사례는, 데이터 품질이 곧 AI 결과의 품질이라는 메시지로 다가왔습니다.
+
+이 방향은 제가 술통여지도 프로젝트에서 부딪힌 문제의식과 맞닿아 있습니다. GPT-5.2 기반 술집 추천 시스템을 만들면서, 단순히 모델에 데이터를 던지는 방식으로는 hallucination과 토큰 비용 문제를 해결할 수 없었습니다.
+
+그래서 도메인 특화 Pipe-delimited Format을 설계해 JSON 대비 토큰을 약 40% 절감했습니다. 또한 정규식 기반 허용 ID Set 검증으로 GPT가 만들어낸 존재하지 않는 술집 추천을 0건으로 차단했습니다. 외부 API 장애에 대비한 거리순 폴백을 두어, AI가 실패해도 사용자에게 기본 결과는 반환되도록 했습니다.
+
+이 경험은 AI를 단순히 호출하는 개발이 아니라, 데이터 품질과 운영 안정성까지 책임지는 개발이 무엇인지 고민하게 만들었습니다.
+
+에이투텍의 폐쇄형 AI 개발 환경과 디지털 전환 솔루션은, 데이터 정제부터 모델 운영까지 통합적으로 다루는 개발자가 가장 필요한 영역이라 판단했습니다. 그동안 쌓아온 데이터 직렬화 최적화와 AI 응답 검증 경험이 회사의 방향과 맞닿아 있다고 판단했고, 이 점이 지원을 결심한 가장 큰 이유입니다.
+
+---
+
+## 2. 업무 시 강점
+
+### AI의 한계를 코드로 보완하다
+
+저의 가장 큰 강점은 외부 AI API의 한계를 시스템 설계로 보완하는 역량입니다.
+
+술통여지도 프로젝트에서 사용자의 위치, 날씨, 시간대, 요청사항을 GPT-5.2에 전달해 반경 내 술집을 추천하는 백엔드 추천 엔진을 단독으로 담당했습니다.
+
+가장 큰 문제는 세 가지였습니다. 후보 술집이 최대 200개에 달해 한 번에 GPT에 전달하면 16,000토큰을 초과하여 응답 품질이 저하되었습니다. 또한 GPT가 입력 후보에 없는 술집을 만들어내는 hallucination이 발생했고, JSON 직렬화의 구조 문자가 불필요한 토큰을 소비했습니다.
+
+이를 해결하기 위해 세 가지 설계를 적용했습니다.
+
+첫째, 2단계 Cascade Ranking 구조를 도입했습니다. 1단계에서 200개를 100개씩 배치로 나눠 top5를 선별하고, 2단계에서 최대 40개를 정밀 랭킹해 Top 10과 추천 이유를 생성했습니다. 그 결과 호출당 토큰을 약 70% 절감했습니다.
+
+둘째, Defensive Normalization을 구현했습니다. 정규식으로 입력에서 허용 ID Set을 추출한 뒤, GPT 응답의 barId를 대조해 미허용 ID를 즉시 제거했습니다. 이 구조로 hallucination에 의한 잘못된 추천을 0건으로 차단했습니다.
+
+셋째, 도메인 특화 Pipe-delimited Format을 설계했습니다. `B|id=123|n=포차` 형식으로 직렬화하고 모든 필드에서 파이프와 개행을 sanitize했습니다. JSON 대비 토큰을 약 40% 절감했고 파싱 오류도 함께 제거했습니다.
+
+이 경험을 통해 외부 의존성의 실패 가능성과 비용까지 시스템에 반영하는 개발 방식을 익혔습니다. 입사 후에도 같은 방식으로 회사 AI 솔루션의 안정성과 비용 효율에 기여하겠습니다.
+
+---
+
+## 3. 입사 후 포부
+
+### 데이터부터 모델까지 책임지는 개발자
+
+입사 후에는 에이투텍의 디지털 전환 솔루션 안에서 데이터 파이프라인과 AI 서빙을 함께 다루는 백엔드 개발자로 성장하고 싶습니다.
+
+회사가 강조하는 "데이터 기반 의사결정 자동화"는 정제된 데이터, 안정적인 모델 학습, 실패에 강한 서빙 구조 세 축이 맞물려야 가능하다고 판단했습니다.
+
+입사 초기에는 기존 AX 솔루션과 빅데이터 플랫폼의 코드와 문서를 빠르게 파악하겠습니다. 특히 폐쇄형 AI 환경에서 데이터가 흐르는 경로와 REST API 서빙 구조를 이해하는 데 집중하겠습니다.
+
+1년 차에는 AI 모델과 백엔드 API를 연결하는 영역에서 단독으로 기능을 수행하고 싶습니다. 술통여지도에서 적용한 입력 검증, 응답 정규화, Graceful Degradation 패턴을 사내 솔루션에 맞게 발전시켜 운영 안정성에 기여하겠습니다.
+
+3년 차에는 데이터 품질 검증과 AI 응답 모니터링을 자동화하는 구조 개선을 제안하고 싶습니다. 단발성 기능 개발에 머무르지 않고, 팀 전체가 데이터 정합성을 더 빠르게 확인할 수 있는 환경을 만드는 데 보탬이 되겠습니다.
+
+대규모 분산 데이터 처리 경험은 아직 부족하지만, 현재 Hadoop과 Spark 학습을 진행하며 빅데이터 플랫폼의 동작 원리를 익히고 있습니다. 또한 Didit 협업 플랫폼에서 Redis 기반 비동기 작업 큐와 Pub/Sub 메시징을 직접 설계하며 분산 처리 감각을 보완하고 있습니다.
+
+장기적으로는 회사가 진행하는 스마트팩토리와 스마트시티 솔루션에서, 현장 데이터를 안정적으로 받아들이고 AI 모델로 가치를 만드는 백엔드 시스템을 함께 만드는 개발자가 되겠습니다.
+
+---
+
+## 4. 자기소개 / 성장 과정
+
+### 측정 가능한 결과를 만드는 개발자
+
+저는 동작하는 코드보다 측정 가능한 결과를 만드는 것을 더 중요하게 여기는 개발자입니다.
+
+백엔드를 처음 시작했을 때는 기능이 동작하면 충분하다고 생각했습니다. 그러나 Didit 협업 플랫폼에서 GitHub 이슈를 AI로 분석해 우선순위를 매기는 기능을 구현하면서 이 생각이 바뀌었습니다.
+
+ML 추론은 수 초에서 수십 초가 걸려 일반 HTTP 요청-응답 사이클로 처리할 수 없었습니다. 처음에는 단순한 동기 호출로 구현했지만 응답 지연으로 사용자 경험이 무너졌습니다.
+
+이 문제를 해결하기 위해 Redis List를 작업 큐로, Redis Pub/Sub을 결과 알림으로 활용한 비동기 파이프라인을 구성했습니다. 결과는 SSE로 클라이언트에 전달하여 ML 추론 시간과 API 응답성을 완전히 분리했습니다. 동작이 아니라 사용자가 체감하는 시간이 진짜 결과라는 점을 그때 처음 체감했습니다.
+
+이 경험 이후 기능을 구현할 때 항상 외부 의존성의 실패와 비용을 함께 고민하게 되었습니다. CloudSharp 파일 서비스에서는 업로드 Finalize 중복 실행 문제를 해결하기 위해 CAS 기반 원자적 점유와 Recovery Worker를 설계했습니다. 술통여지도에서는 GPT 응답의 hallucination과 토큰 비용을 코드 수준에서 방어했습니다.
+
+또한 도메인 모델링과 클린 아키텍처에도 관심을 두고 있습니다. CloudSharp에서는 Api/Core/Infrastructure 의존성 방향을 엄격히 분리하고, Result 패턴으로 성공과 실패를 값으로 표현해 호출부의 예외 누락을 차단했습니다. 같은 코드라도 구조에 따라 유지보수 비용이 크게 달라진다는 점을 직접 체감했습니다.
+
+현재의 저는 외부 시스템의 한계를 인정하고 코드와 구조로 보완하는 개발자, 결과를 수치로 측정해 다음 개선의 근거로 삼는 개발자로 정리할 수 있습니다.
--- a/자기소개서/위존.md
+++ b/자기소개서/위존.md
@@ -0,0 +1,73 @@
+# ㈜위존 솔루션 개발자 자기소개서
+
+---
+
+## 1. 지원동기
+
+### 두 스택과 AI 경험이 한 곳에서 만나는 자리
+
+위존의 솔루션 개발자 채용 공고를 본 순간, 지난 2년간 따로 쌓아온 경험이 한 자리에서 연결될 수 있겠다고 판단했습니다.
+
+귀사는 EHS·LIMS·출입관리 같은 산업용 솔루션을 Java/Spring과 C#/ASP.NET MVC 양쪽 스택으로 개발하고 있습니다. 프론트엔드는 Vue.js를 사용하며, AI/LLM 프로젝트 경험을 우대하고 있습니다. 저는 Spring Boot 기반 협업 플랫폼(Didit)과 GPT-5.2 기반 추천 서비스(술통여지도)를 Java로 개발했습니다. 동시에 ASP.NET Core 기반 파일 저장 서비스(CloudSharp)와 Blazor용 오픈소스 라이브러리(TusBlazorClient, NuGet v1.0.1 배포)를 C#으로 개발했습니다. 프론트엔드는 Vue 3 + TypeScript + Pinia로 지도 UI와 AI 추천 결과를 동기화하는 화면을 구현했습니다.
+
+특히 SHE 시스템 페이지의 "Web 기반 모듈식 구조로 TMS·LIMS·RTDB 등 다양한 시스템과 인터페이스되며, 통합 또는 개별 모듈 구축이 가능하다"는 설명에 주목했습니다. 이는 제가 CloudSharp에서 Clean Architecture로 12개 엔티티를 모듈러 모놀리스로 분리하고, Storage Provider를 Local FS·MinIO·S3로 추상화한 경험과 직접 맞닿아 있다고 느꼈습니다.
+
+또한 귀사가 Green IT & ESG와 AI 기반 DX/AX로 사업 영역을 확장하고 있다는 점도 인상 깊었습니다. 술통여지도에서 GPT 호출 토큰을 70% 절감한 2단계 Cascade Ranking 설계 경험이, LIMS의 품질 데이터 분석이나 SHE의 사고 예측 같은 산업 솔루션의 AI 도입 단계에서 의미 있게 활용될 수 있다고 판단했습니다.
+
+이처럼 두 스택을 모두 다뤄본 경험과 AI 엔지니어링 경험이 귀사의 산업용 솔루션 개발 환경과 직접 연결된다고 보고 지원했습니다.
+
+---
+
+## 2. 업무 시 강점
+
+### 200개 후보를 GPT에 한 번에 보낼 수 없을 때
+
+저의 가장 큰 강점은 외부 시스템의 한계를 측정 가능한 수치로 풀어내는 역량입니다.
+
+술통여지도 프로젝트에서 사용자의 위치·날씨·시간대를 반영해 반경 내 최대 200개 술집 중 Top 10을 추천하는 기능을 설계했습니다. 초기 구현에서는 200개를 한 번에 GPT에 전달했는데, 입력 토큰이 16,000개를 넘었습니다. 컨텍스트가 길어질수록 GPT의 attention 품질이 저하되어 추천이 거리순과 큰 차이가 없는 문제가 발견되었습니다.
+
+원인은 두 가지였습니다. 첫째, JSON의 키 이름과 따옴표 같은 구조 문자가 토큰을 낭비했습니다. 둘째, 후보가 200개에 달하면 GPT가 핵심 후보에 집중하기 어려웠습니다.
+
+저는 두 단계로 해결했습니다. 먼저 도메인 특화 Pipe-delimited 포맷(`B|id=123|c=주점|n=포차`)을 설계해 JSON 대비 약 40% 토큰을 절감했습니다. 다음으로 2단계 Cascade Ranking을 도입했습니다. 1단계는 100개씩 배치로 나눠 ID만 반환하는 경량 호출로 후보를 40개로 압축했습니다. 2단계에서 정밀 랭킹과 자연어 추천 이유를 생성했습니다.
+
+추가로 GPT가 입력에 없는 가게 ID를 만들어내는 hallucination을 막아야 했습니다. 정규식 `(?m)^B\|id=(\d+)\b`로 입력 B 라인에서 허용 ID Set을 추출했습니다. 응답의 barId를 대조해 허용되지 않은 ID를 즉시 제거했습니다. AI 호출 실패 시에는 거리순 폴백으로 서비스 중단을 막았습니다.
+
+결과적으로 API 호출당 토큰을 약 70% 절감하고, 잘못된 가게가 노출되는 사고를 0건으로 유지했습니다. AI 장애 시에도 사용자에게 빈 화면이 아닌 기본 추천이 제공되도록 가용성을 확보했습니다.
+
+이 경험은 외부 의존성을 다룰 때 "측정 가능한 지표 → 단계별 분리 → 방어 코드 → 폴백"이라는 절차를 익히게 해줬습니다. 귀사의 LIMS·SHE 솔루션도 TMS·RTDB·HMI 등 다양한 인터페이스를 통합하는 만큼, 외부 시스템 연동을 안정적으로 다루는 역량으로 입사 직후부터 기여하겠습니다.
+
+---
+
+## 3. 입사 후 포부
+
+### 도메인을 이해하는 솔루션 개발자로
+
+입사 후에는 제조·화학 산업의 도메인 지식을 갖춘 솔루션 개발자로 성장하고 싶습니다.
+
+귀사는 EHS·LIMS·출입관리 솔루션을 통합 또는 모듈 단위로 제공하며, 최근 Green IT & ESG와 AI 기반 DX/AX로 영역을 확장하고 있습니다. 저는 이 방향 안에서 "기술을 산업 문제에 정확히 적용하는 개발자"가 되고자 합니다.
+
+입사 첫 6개월은 도메인 이해에 집중하겠습니다. EHS와 LIMS의 핵심 업무 흐름, 산업안전보건법과 화학물질관리법 등 관련 규제, 기존 솔루션의 코드베이스와 모듈 구조를 학습하겠습니다. 동시에 Spring과 ASP.NET 양쪽 환경에서 작은 기능부터 단독으로 수행하며 팀의 코딩 컨벤션을 익히겠습니다.
+
+1년 차에는 독립적인 기능 단위 개발을 목표로 합니다. 기존 모듈에 신규 기능을 추가하거나, 다른 시스템과의 인터페이스를 설계·구현하는 작업을 맡고 싶습니다. 코드 리뷰에 적극 참여해 팀의 품질 기준을 익히겠습니다. CloudSharp에서 사용한 Result 패턴이나 파일 I/O와 DB 트랜잭션 경계 분리 같은 검증된 설계 기법은 팀에 공유하며 함께 발전시키고 싶습니다.
+
+3년 차에는 AI 기능 통합과 구조 개선에 기여하겠습니다. 술통여지도에서 GPT 호출 비용을 70% 절감한 경험을 살려, LIMS의 품질 데이터 분석이나 SHE의 사고 예측 같은 영역에서 AI 도입을 제안하고 PoC부터 운영까지 끌고 갈 수 있는 개발자가 되겠습니다. 또한 신입·후배 개발자의 온보딩을 돕고, 모듈 간 중복 코드를 줄이는 구조 개선을 주도하고 싶습니다.
+
+대규모 운영 환경에서의 장애 대응 경험은 아직 부족합니다. 다만 CloudSharp에서 Recovery Worker와 CAS 기반 락 회복 절차를 직접 설계하며 운영 감각을 보완하고 있습니다. 입사 후에는 실제 운영 환경에서 이 부족함을 빠르게 메워가겠습니다.
+
+---
+
+## 4. 성장 과정
+
+### 동작하는 코드에서 유지보수 가능한 구조로
+
+저는 "동작하는 코드"에서 "유지보수 가능한 구조"로 시각이 바뀐 시점을 개발자 정체성의 출발점이라고 봅니다.
+
+처음에는 기능이 동작하면 끝이라고 생각했습니다. 그러나 Blazor WebAssembly에서 대용량 파일 업로드를 구현하던 중, 같은 코드를 여러 컴포넌트에서 반복 호출하다 콜백 누수와 JS 모듈 중복 로딩 문제를 겪었습니다. 이때 처음으로 "재사용 가능한 라이브러리로 추출하면 어떨까"라는 질문을 던졌습니다.
+
+그 결과 tus 프로토콜 기반 업로드 라이브러리 TusBlazorClient를 만들어 NuGet에 배포했습니다(v1.0.1). 이 과정에서 Public API와 internal 구현을 엄격히 분리했습니다. IAsyncDisposable로 JS 모듈의 생명주기를 관리했습니다. Selenium 기반 E2E 테스트로 업로드·재개·재시도 등 9개 시나리오를 검증했습니다. 외부 사용자가 라이브러리를 어떻게 잘못 쓸 수 있을지 예상하고 방어하는 일은 처음에는 번거로웠습니다. 그러나 결국 그 작업이 코드의 수명을 결정한다는 사실을 배웠습니다.
+
+이후 진행한 CloudSharp 프로젝트에서는 처음부터 Clean Architecture로 12개 엔티티의 도메인 경계를 분리했습니다. Finalize 중복 실행을 막는 CAS 기반 락, Quota 경쟁을 막는 FOR UPDATE 트랜잭션, 단명 5분 TTL 다운로드 세션 같은 설계는 모두 "나중에 운영하면서 후회하지 않을 코드"를 만들기 위한 선택이었습니다.
+
+지금의 저는 "기능을 빠르게 만드는 개발자"보다 "오래 운영해도 무너지지 않는 구조를 설계하는 개발자"를 지향합니다. 귀사의 인재상인 Creation·Credit·Challenge 중에서도 신뢰(Credit)에 가장 깊이 공감하는 이유입니다. 산업용 솔루션은 한 번 도입되면 수년간 운영되는 시스템이며, 그 안에서 신뢰는 결국 코드의 구조와 검증된 설계에서 나온다고 믿기 때문입니다.
+
+이런 사고방식이 위존의 EHS·LIMS·출입관리 솔루션처럼 장기간 운영되는 시스템에서 강점이 되리라 확신합니다.
--- a/자기소개서/케이에스아이.md
+++ b/자기소개서/케이에스아이.md
@@ -0,0 +1,84 @@
+# 자기소개서 — ㈜케이에스아이 지원
+
+> 작성 기준: IT 개발자 자기소개서 작성 컨벤션 (회사 분석 + 내 경험 연결, 두괄식, STAR 구조, 수치 결과 포함)
+
+---
+
+## 1. 지원동기
+
+### 닷넷과 AI가 만나는 지점
+
+저는 귀사의 MES/POP 시스템에 AI를 접목하려는 방향에 주목해 지원했습니다.
+
+귀사는 1988년부터 35년간 .NET 기반 MES/POP·ERP 솔루션을 자체 개발해온 전문 기업입니다. 최근에는 AI 소프트웨어 개발자를 채용하며 공정 데이터 분석과 예지보전으로 영역을 확장하고 있습니다. 특히 MICOM PLC와 무선 컨버터를 직접 개발해 소프트웨어와 통합하는 구조가 인상 깊었습니다. 단순한 업무 시스템이 아니라, 현장 설비부터 데이터 분석까지 전체를 책임지는 솔루션이기 때문입니다.
+
+저는 ASP.NET Core 기반 파일 저장 플랫폼인 CloudSharp를 설계·구현하며 .NET 환경에서 인증, 동시성 제어, 인프라 구성까지 직접 책임진 경험이 있습니다. 또한 술통여지도 프로젝트에서는 GPT-5.2를 실서비스에 적용해 토큰을 약 70% 절감하고 Hallucination을 차단하는 다층 방어 체계를 구축했습니다.
+
+.NET 기반 시스템 설계와 AI 활용 경험이 동시에 요구되는 환경은 흔치 않습니다. 귀사가 추진하는 MES/POP의 AI 고도화 방향이 제가 쌓아온 경험과 직접 맞닿아 있다고 판단해 지원을 결심했습니다.
+
+---
+
+## 2. 업무 시 강점
+
+### 원인을 끝까지 추적하는 개발
+
+저의 가장 큰 강점은 시스템 동시성 문제의 원인을 끝까지 추적하고 측정 가능한 결과로 개선하는 역량입니다.
+
+ASP.NET Core 기반 파일 저장 플랫폼인 CloudSharp를 개발하며, 대용량 파일 업로드의 Finalize 단계에서 중복 실행 가능성을 발견했습니다. tusd hook과 백그라운드 Worker 두 경로에서 같은 업로드 세션이 동시에 처리될 경우, 동일한 파일이 두 번 등록될 위험이 있었습니다.
+
+먼저 동시 요청 시나리오를 분석해 문제를 재현했습니다. 일반적인 분산 락(Redis Redlock 등)을 도입하면 인프라 복잡도가 증가하므로, 기존 상태 머신을 락으로 재활용하는 방향을 선택했습니다.
+
+구체적으로는 PostgreSQL의 CAS(Compare-And-Swap) 패턴을 적용했습니다. `UPDATE upload_session SET status='FINALIZING' WHERE status='UPLOADING'` 쿼리로 단일 트랜잭션 점유를 구현했고, 파일 I/O와 DB 트랜잭션을 분리해 느린 작업이 락을 잡지 않도록 했습니다. 또한 10분 이상 FINALIZING 상태에 머문 세션을 자동 복구하는 Recovery Worker를 추가했습니다.
+
+그 결과 별도 분산 락 인프라 없이 SQL 한 줄로 중복 실행을 차단했고, DB UNIQUE 제약과 결합해 이중 안전장치를 구축했습니다. 같은 방식으로 Quota 동시 요청 문제에도 `SELECT FOR UPDATE`를 적용해 경쟁 조건을 제거했습니다.
+
+이 경험을 통해 단순히 기능을 만드는 것을 넘어, 동시성과 정합성 문제를 측정 가능한 결과로 개선하는 방식을 익혔습니다. 입사 후에도 동일한 접근으로 MES/POP 시스템의 실시간 공정 데이터 처리 안정성에 기여하겠습니다.
+
+---
+
+## 3. 입사 후 포부
+
+### 현장과 AI를 잇는 개발자
+
+입사 후에는 귀사의 스마트팩토리 AI 고도화 방향 안에서 .NET 기반 시스템과 AI를 잇는 개발자로 성장하고 싶습니다.
+
+귀사는 MES/POP 시스템에 AI를 접목해 공정 데이터 분석과 예지보전으로 영역을 확장하고 있습니다. 이 흐름 안에서 단순 기능 구현이 아니라, 현장 데이터의 신뢰성과 분석 결과의 정확성을 함께 책임지는 개발자가 되고자 합니다.
+
+입사 초기에는 업종별 MES/POP 패키지 구조와 PLC 데이터 수집 흐름을 파악하는 데 집중하겠습니다. 자동차부품, 프레스/금형, 인쇄 등 업종마다 공정과 데이터 특성이 달라, 코드베이스와 현장 도메인을 함께 학습할 계획입니다.
+
+1년 안에는 .NET 기반 모듈을 단독으로 담당하고, API 연동과 데이터 정합성 개선에 기여하겠습니다. CloudSharp에서 쌓은 동시성 제어 경험과 술통여지도에서 다진 외부 API 안정화 경험이 바로 활용될 영역입니다.
+
+3년 안에는 MES/POP 시스템에 AI 분석을 안정적으로 통합하는 구조를 제안할 수 있는 개발자가 되겠습니다. GPT 기반 추천 엔진에서 토큰 비용과 Hallucination을 동시에 잡았던 경험을 바탕으로, 제조 도메인 AI에서도 비용·정확도·운영 안정성을 함께 고려한 설계를 만들어가겠습니다.
+
+PLC와 하드웨어 연동 경험은 아직 부족하지만, MICOM PLC와 무선 컨버터 관련 자료를 미리 학습하며 사내 OJT를 통해 빠르게 보완하겠습니다. 장기적으로는 현장과 AI를 자연스럽게 연결하는 개발 사례를 만들어, 귀사의 스마트팩토리 솔루션이 한 단계 확장되는 데 보탬이 되겠습니다.
+
+---
+
+## 4. 자기소개 / 성장 과정
+
+### 구현에서 구조로
+
+저는 동작하는 코드를 넘어 유지보수 가능한 구조를 고민하는 개발자입니다.
+
+처음 개발을 시작했을 때는 기능을 빠르게 구현하는 데 집중했습니다. 하지만 프로젝트 규모가 커질수록 동작하는 코드와 잘 만든 코드는 다르다는 점을 체감했습니다.
+
+술통여지도 프로젝트에서 GPT-5.2를 실서비스에 적용했을 때, 단순히 API를 호출하는 수준으로는 운영이 불가능했습니다. 200개 후보를 한 번에 보내면 토큰이 16,000개를 넘었고, GPT는 입력에 없는 술집을 만들어내기도 했습니다. 이 문제를 풀기 위해 2단계 Cascade Ranking 구조를 도입했고, 응답을 정규식으로 검증해 허용되지 않은 ID를 제거하는 다층 방어 체계를 만들었습니다. 그 과정에서 외부 시스템과 통신할 때는 항상 실패와 비정상 응답을 전제로 설계해야 한다는 원칙을 체득했습니다.
+
+이후 CloudSharp 프로젝트에서는 처음부터 Clean Architecture, Result 기반 에러 처리, CAS 동시성 제어를 적용했습니다. TusBlazorClient라는 .NET 라이브러리를 단독으로 설계해 NuGet에 배포하면서, 외부 사용자가 사용할 API의 책임 분리와 확장성도 직접 고민했습니다.
+
+이런 경험을 거치며 단순 구현보다 원인 분석과 구조 설계를 우선하는 개발자가 되었습니다. 입사 후에도 이 자세로 귀사 솔루션의 품질과 안정성에 기여하겠습니다.
+
+---
+
+## 작성 컨벤션 점검
+
+| 항목 | 점검 결과 |
+|---|---|
+| 회사 연결 | MES/POP, AI 접목, MICOM PLC, 35년 역사 등 회사 정보 직접 인용 |
+| 경험 증명 | CloudSharp(CAS), 술통여지도(GPT 70% 절감), TusBlazorClient(NuGet) 사례 사용 |
+| 수치 결과 | 토큰 70% 절감, 16,000 토큰, 10분 자동 복구, 35년 |
+| 입사 후 기여 | 초기 → 1년 → 3년 타임라인으로 구성, 보완점(PLC) 명시 |
+| 두괄식 | 모든 문항 첫 문장에 결론 위치 |
+| 금지 표현 | "열정", "최선", "누구보다", "인재" 미사용 |
+| 문장 길이 | 60자 내외 유지, 80자 초과 문장 없음 |
+| 소제목 | 15자 내외, 핵심 메시지 반영 |
--- a/자기소개서/크레셈.md
+++ b/자기소개서/크레셈.md
@@ -0,0 +1,77 @@
+# ㈜크레셈 자기소개서 — S/W 개발자(제어)
+
+> 컨벤션 가이드(두괄식 / 회사 분석 + 내 경험 연결 / STAR / 60자 내외 문장 / 추상어 금지)에 따라 작성했습니다.
+> 채용공고 핵심 키워드: **C#, Visual Studio, 검사장비 제어, MMI**
+> 활용 경험: **TusBlazorClient(C# 라이브러리·NuGet)**, **CloudSharp(ASP.NET Core 파일 서비스·CAS 동시성 제어)**
+
+---
+
+## 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분 자기소개)이 필요하면 같은 컨벤션으로 이어서 작성하겠습니다.
--- a/자기소개서/페이타랩.md
+++ b/자기소개서/페이타랩.md
@@ -0,0 +1,55 @@
+# 자기소개서
+
+> ㈜페이타랩 · C# WPF 응용프로그램 개발자 지원
+
+---
+
+## 1. 지원동기 — Windows 환경 위의 안정성
+
+저는 귀사의 패스오더가 풀어내고 있는 **"Windows POS와 모바일 서비스를 잇는다"**는 문제에 주목해 지원했습니다.
+
+귀사의 채용 정보와 기술 글에서 인상 깊었던 지점은 두 가지였습니다. 하나는 카페 POS의 99%가 Windows 기반이라는 환경 위에서 구형 PC부터 최신 키오스크까지 모두 지원해야 한다는 점이었습니다. 다른 하나는 오전 피크에 하루 트래픽의 33.3%가 몰리는 가운데, 점주 PC가 초당 수백 건의 주문을 누락 없이 받아야 한다는 점이었습니다. 단순한 데스크톱 클라이언트가 아니라 외부 서버, 영수증 프린터, 마이크로서비스가 한 번에 맞물려 동작하는 통합 지점이라는 점이 가장 인상 깊었습니다.
+
+이 문제는 제가 그동안 익혀온 문제 의식과 닿아 있습니다. 셀프호스트 파일 서비스 CloudSharp에서는 Local FS·MinIO·S3를 동일한 storage_key로 추상화했습니다. 운영 환경이 달라져도 동일하게 동작하는 구조를 만들었고, tusd라는 외부 Go 프로세스와 hook으로 안전하게 연계했습니다. 또한 `TusBlazorClient`를 NuGet에 배포하면서 C# 코드와 JavaScript 라이브러리를 직접 잇는 경계 설계를 경험했습니다. 다양한 실행 환경과 외부 의존성을 한 번에 다뤄야 한다는 점에서, 귀사의 점주용 프로그램이 풀고 있는 문제에 제가 가장 잘 기여할 수 있다고 판단해 지원했습니다.
+
+---
+
+## 2. 업무 시 강점 — 외부 시스템을 안정적으로 잇는 설계
+
+저의 가장 큰 강점은 **C# 코드와 외부 시스템 사이의 경계를 안정적으로 설계하는 능력**입니다.
+
+이 강점은 Blazor WebAssembly용 NuGet 라이브러리 `TusBlazorClient`를 단독으로 설계·구현·배포한 경험에서 만들어졌습니다. Blazor의 순수 C# 코드는 대용량 파일 업로드에서 메모리·속도 한계가 있었습니다. 검증된 JavaScript 라이브러리 `tus-js-client`를 C# API로 감싸는 래퍼가 필요한 상황이었습니다.
+
+가장 어려웠던 지점은 **JS↔.NET 콜백 브릿지 설계**였습니다. tus-js-client는 진행률·오류·완료를 JS 콜백으로 통지합니다. 반면 C# 델리게이트는 JSON 직렬화가 불가능해 JS에 그대로 넘길 수 없었습니다. 콜백을 일부만 사용하는 시나리오에서는 JS→.NET 호출 자체가 불필요한 오버헤드가 되는 문제도 있었습니다.
+
+저는 모든 콜백을 `TusOptionJsInvoke`라는 한 객체에 모아 `DotNetObjectReference`로 JS에 한 번만 전달했습니다. 콜백 본문은 `[JsonIgnore]`로 직렬화에서 제외했습니다. 동시에 `TusOptionNullCheck` 메타정보를 별도로 두어, JS 측에서 null 콜백에 대한 `invokeMethodAsync`를 아예 건너뛰도록 했습니다. 상태 변경이 없는 `OnBeforeRequest`/`OnAfterResponse`는 동기 호출로 바꿔 마샬링 비용을 추가로 줄였습니다.
+
+그 결과 사용자는 JavaScript 한 줄 없이 C#만으로 **18개 옵션과 7종 콜백을 모두 사용**할 수 있게 되었습니다. 기본 업로드, 중단·재개, 옵션 동적 변경, 재시도 시나리오를 **9개의 Selenium E2E 테스트**로 검증했습니다. 이후 NuGet에 1.0.1 버전으로 공개 배포해 외부 사용자에게 노출되는 라이브러리로 운영했습니다.
+
+이 경험은 패스오더 점주용 프로그램이 풀어야 할 문제와 직접 닿아 있다고 생각합니다. 영수증 프린터, 바코드 스캐너, REST API, Socket 통신, 마이크로서비스는 모두 C# 외부에 있는 시스템입니다. 이들을 C#에서 어떻게 안전하게 연결하느냐가 곧 안정성의 핵심이기 때문입니다. 입사 후에도 외부 의존성과 C# 사이의 경계를 명확히 설계해 주문 누락과 장애를 줄이는 데 기여하겠습니다.
+
+---
+
+## 3. 입사 후 포부 — 구형부터 최신까지, 같은 안정성으로
+
+입사 후에는 **수만 개 매장의 다양한 환경에서 동일한 안정성을 보장하는 WPF 개발자**로 성장하고 싶습니다.
+
+귀사는 ArgoCD·Argo Rollouts 기반 Canary 배포, Istio Service Mesh, Kafka 전용 Gateway, 0단계 모드를 운영하고 있습니다. 모두 "사용자에게 영향을 주지 않는 검증"을 핵심 가치로 둔 도구입니다. 점주용 PC 프로그램에서도 같은 기준으로 안정성을 끌어올리고 싶습니다.
+
+**입사 초기**에는 패스오더 점주용 프로그램의 코드베이스를 파악하는 데 집중하겠습니다. 영수증 프린터·POS PC·키오스크에서 같은 코드가 어떻게 다르게 동작하는지, REST/Socket 통신과 마이크로서비스 연동이 어떻게 맞물려 있는지 익히고 싶습니다.
+
+**1년 안**에는 점진적 리팩토링 과정에 직접 참여하고 싶습니다. CloudSharp에서 Clean Architecture로 계층 경계를 분리해본 경험이 도움이 될 것으로 보입니다. 비즈니스 로직·통신·UI가 섞여 있는 부분을 단계적으로 분리하고, 구형 PC와 최신 키오스크의 동작 차이를 잡아내는 회귀 테스트를 보강하고 싶습니다.
+
+**3년 안**에는 주문 접수·결제 상태·하드웨어 제어 흐름의 신뢰성 패턴을 팀 내에서 정리해 공유할 수 있는 개발자가 되고 싶습니다. 대규모 운영 경험은 아직 부족합니다. 다만 CloudSharp에서 Finalize 동시성을 CAS로 다루고 Recovery Worker로 교착을 자동 해소한 경험이 있습니다. 이 경험을 바탕으로 실제 운영 환경에서 발생하는 장애를 분석해 구조에 반영하는 역량을 채워가겠습니다.
+
+---
+
+## 4. 성장 과정 — 외부에 닿는 코드의 무게
+
+저는 **"동작하는 코드"에서 "외부에 노출되어도 안정적인 코드"**로 관점을 옮겨온 개발자입니다.
+
+처음 개발을 시작했을 때는 기능이 잘 돌아가면 그것으로 충분하다고 생각했습니다. 관점이 바뀐 계기는 `TusBlazorClient`를 NuGet에 공개하면서였습니다. 내 코드를 다른 개발자가 의존하기 시작하자, 작은 결정 하나가 외부 사용자의 코드를 깨뜨릴 수 있다는 사실을 체감했습니다. 콜백을 `[JsonIgnore]`로 분리하고, `IAsyncDisposable`로 JS 모듈 생명주기를 정리한 것은 모두 같은 질문에서 나왔습니다. "사용자의 코드가 이 라이브러리 때문에 어떻게 깨질 수 있는가."
+
+이 경험 이후 CloudSharp에서도 같은 태도로 설계했습니다. JWT 대신 Opaque Session Token을 선택해 권한 변경이 즉시 반영되도록 했습니다. Finalize 중복은 CAS와 Recovery Worker로 막았고, 외부 공개 API에는 Zero Information Leak 정책을 적용했습니다. 모두 "외부에서 이 코드가 어떻게 잘못 사용될 수 있는가"를 먼저 묻는 사고에서 나온 선택이었습니다.
+
+귀사의 점주용 프로그램은 전국 수만 개 매장에서 매일 영업의 가장 앞단에 서 있는 코드입니다. 외부에 닿는 코드의 무게를 익혀온 만큼, 점주님과 손님 양쪽이 신뢰할 수 있는 프로그램을 만드는 데 책임감 있게 기여하겠습니다.
--- a/프롬프트/it_developer_self_intro_convention_context.md
+++ b/프롬프트/it_developer_self_intro_convention_context.md
@@ -0,0 +1,684 @@
+# IT 개발자 자기소개서 작성 컨벤션 컨텍스트
+
+## 0. 문서 목적
+
+이 문서는 IT 개발자 자기소개서를 작성하거나 수정할 때 항상 참조해야 하는 **작성 컨벤션 문서**다.
+
+자기소개서는 단순한 성격 소개나 다짐문이 아니라, 아래 세 가지를 설득하는 문서로 작성한다.
+
+1. **왜 이 회사인지**
+2. **왜 내가 이 직무에 적합한지**
+3. **입사 후 어떻게 성장하고 회사에 기여할 것인지**
+
+작성 대상은 신입 개발자 및 주니어 개발자 기준이며, 백엔드 / 프론트엔드 / 풀스택 / 데이터 엔지니어 / DevOps / 인프라 / QA / 모바일 직무에 적용할 수 있다.
+
+---
+
+## 1. 최상위 작성 원칙
+
+### 1-1. 모든 문항은 회사와 연결한다
+
+자기소개서의 모든 문항에는 반드시 다음 두 요소가 함께 들어가야 한다.
+
+| 요소 | 설명 |
+|---|---|
+| 회사 정보 | 채용공고, 홈페이지, 서비스, 기술 방향, 사업 방향, 개발 문화 |
+| 내 경험 | 프로젝트, 협업, 성능 개선, 운영 경험, 학습 경험, 문제 해결 경험 |
+
+기본 공식은 다음과 같다.
+
+```text
+회사 분석 + 내 경험 연결 = 설득력 있는 자기소개서
+```
+
+회사 이름을 다른 회사명으로 바꿔도 자연스러운 문장은 사용하지 않는다.
+
+---
+
+### 1-2. 문항마다 역할을 분리한다
+
+각 문항은 서로 다른 질문에 답해야 한다.
+
+| 문항 | 핵심 질문 | 중심 내용 |
+|---|---|---|
+| 지원동기 | 왜 이 회사에 지원했는가 | 회사 강점 + 내 경험 연결 |
+| 업무 시 강점 | 어떤 역량으로 바로 기여할 수 있는가 | 강점 1개 + 사례 1개 + 수치 결과 |
+| 입사 후 포부 | 어떻게 성장해 장기적으로 기여할 것인가 | 회사 방향 + 성장 계획 + 기여 방식 |
+| 자기소개 / 성장 과정 | 어떤 개발자인가 | 개발자 정체성이 형성된 계기 |
+
+같은 사례를 여러 문항에서 그대로 반복하지 않는다. 같은 프로젝트를 쓰더라도 초점은 다르게 둔다.
+
+---
+
+### 1-3. 두괄식으로 작성한다
+
+각 문항의 첫 문장에서 결론이 보여야 한다.
+
+좋은 첫 문장은 아래 조건을 만족한다.
+
+- 문항의 답이 바로 보인다.
+- 회사 또는 직무와 연결된다.
+- 추상적인 감정 표현이 아니라 판단이 드러난다.
+
+예시:
+
+```text
+저는 귀사의 데이터 기반 서비스 고도화 방향에 주목해 지원했습니다.
+저의 가장 큰 강점은 성능 문제의 원인을 끝까지 추적하고 개선하는 역량입니다.
+입사 후에는 안정성과 확장성을 함께 고민하는 백엔드 개발자로 성장하고 싶습니다.
+```
+
+---
+
+### 1-4. 추상어는 사례로 증명한다
+
+아래 표현은 단독으로 쓰지 않는다.
+
+| 약한 표현 | 문제점 | 대체 방향 |
+|---|---|---|
+| 책임감이 있습니다 | 증명 없는 자기 평가 | 끝까지 맡아 해결한 사례로 증명 |
+| 협업을 잘합니다 | 방식이 보이지 않음 | 역할 분담, 일정 조율, 리뷰 방식 설명 |
+| 문제 해결 능력이 있습니다 | 어떤 문제인지 불명확 | 문제 원인, 판단, 해결 과정 제시 |
+| 성실합니다 | 개발 역량으로 보이지 않음 | 꾸준히 학습해 적용한 결과 제시 |
+
+기본 공식:
+
+```text
+추상적 강점 선언 금지
+강점 1개 → 사례 1개 → 내가 한 행동 → 결과 수치 → 입사 후 연결
+```
+
+---
+
+## 2. 입력 정보 정리 컨벤션
+
+자기소개서 작성 전 반드시 아래 정보를 먼저 정리한다.
+
+```markdown
+# 기업 / 직무 분석 메모
+
+## 기본 정보
+- 회사명:
+- 지원 직무:
+- 지원 팀 / 서비스:
+- 서비스 대상 사용자:
+
+## 채용공고 분석
+- 필수 기술 스택:
+- 우대 기술 스택:
+- 담당 업무:
+- 요구 역량:
+- 반복 등장 키워드:
+
+## 회사 / 서비스 분석
+- 핵심 서비스:
+- 해결하는 문제:
+- 주요 고객:
+- 최근 사업 방향:
+- 인상 깊은 지점:
+
+## 기술 / 개발 문화 분석
+- 사용하는 기술:
+- 기술 블로그에서 확인한 문제:
+- 아키텍처 / 인프라 방향:
+- 성능 / 운영 / 보안 관련 이슈:
+- 강조하는 가치:
+- 일하는 방식:
+- 개발 문화:
+
+## 내 경험 연결 후보
+- 경험 1:
+  - 프로젝트명:
+  - 사용 기술:
+  - 문제 상황:
+  - 내가 한 행동:
+  - 결과:
+  - 연결 가능한 회사 요구사항:
+- 경험 2:
+- 경험 3:
+```
+
+---
+
+## 3. 문항별 작성 컨벤션
+
+## 3-1. 지원동기
+
+### 핵심 질문
+
+```text
+왜 이 회사에 지원했는가?
+```
+
+### 작성 목표
+
+지원동기는 회사 칭찬이 아니다.
+
+아래 두 가지가 동시에 드러나야 한다.
+
+1. **Why this company**: 왜 이 회사인가
+2. **Why me**: 왜 내가 이 회사와 맞는가
+
+### 권장 구조
+
+```text
+① 회사를 알게 된 계기          → 1~2문장
+② 회사의 기술 / 사업 강점 발견  → 2~3문장
+③ 그것이 인상 깊었던 이유       → 1~2문장
+④ 내 경험과의 연결              → 2~3문장
+⑤ 지원 결론                    → 1문장
+```
+
+### 작성 공식
+
+```text
+[회사 강점] + [내 경험 연결] = 지원 이유
+```
+
+### 첫 문장 템플릿
+
+```text
+저는 귀사의 ______에 주목해 지원했습니다.
+저는 귀사가 ______을 통해 ______ 문제를 해결하고 있다는 점에 주목했습니다.
+저는 귀사의 ______ 서비스 방향이 제가 경험한 ______ 문제의식과 맞닿아 있다고 판단했습니다.
+```
+
+### 반드시 포함할 내용
+
+- 채용공고 / 홈페이지 / 기술 블로그 / 서비스 페이지에서 확인한 구체 정보
+- 회사의 기술 또는 사업 방향에 대한 내 판단
+- 내 프로젝트 경험과의 연결
+- 마지막 지원 결론
+
+### 피해야 할 문장
+
+```text
+귀사는 업계를 선도하는 기업으로...
+4차 산업혁명 시대에...
+성장 가능성이 높아 지원했습니다.
+혁신적인 회사라고 생각했습니다.
+```
+
+### 좋은 마무리 예시
+
+```text
+이처럼 귀사의 기술 방향과 제가 프로젝트에서 쌓아온 문제 해결 경험이 맞닿아 있다고 판단했고, 이 점이 지원을 결심한 가장 큰 이유입니다.
+```
+
+---
+
+## 3-2. 업무 시 강점
+
+### 핵심 질문
+
+```text
+어떤 역량으로 바로 기여할 수 있는가?
+```
+
+### 작성 목표
+
+업무 강점 문항은 채용공고 요구 역량과 가장 직접적으로 연결해야 한다.
+
+강점은 많이 나열하지 않는다. 가장 설득력 있는 강점 **1개**를 고르고, 대표 사례 **1개**로 증명한다.
+
+### 권장 구조: STAR
+
+| 단계 | 내용 | 분량 비중 |
+|---|---|---:|
+| S: Situation | 어떤 프로젝트 / 어떤 문제였는가 | 15% |
+| T: Task | 내가 맡은 역할은 무엇인가 | 10% |
+| A: Action | 내가 한 기술적 판단과 실행은 무엇인가 | 45% |
+| R: Result | 어떤 결과를 만들었는가 | 20% |
+| 연결 | 입사 후 어떻게 활용할 것인가 | 10% |
+
+Action이 가장 길어야 한다. 여기서 기술적 판단과 문제 해결 방식이 드러나야 한다.
+
+### 작성 공식
+
+```text
+[강점 1개 선언] + [사례 1개 증명] + [수치 결과] = 설득
+```
+
+### 첫 문장 템플릿
+
+```text
+저의 가장 큰 강점은 ______입니다.
+저는 ______ 문제를 끝까지 추적하고 개선하는 데 강점이 있습니다.
+저는 ______을 실제 결과로 연결하는 개발 역량을 갖추고 있습니다.
+```
+
+### 직무별 강점 키워드
+
+| 직무 | 강점 후보 |
+|---|---|
+| 백엔드 | API 설계, 성능 개선, DB 최적화, 인증/인가, 장애 대응, 대용량 처리 |
+| 프론트엔드 | 컴포넌트 설계, 렌더링 최적화, 접근성, 상태 관리, 사용자 경험 개선 |
+| 풀스택 | 기능 흐름 설계, API-UI 연결, 빠른 MVP 구현, 문제 범위 통합 이해 |
+| 데이터 | 파이프라인 설계, 데이터 품질 관리, 배치 처리, 실시간 처리 |
+| DevOps / 인프라 | CI/CD, 컨테이너 운영, 모니터링, 인프라 자동화, 배포 안정화 |
+| QA | 테스트 자동화, 결함 분석, 커버리지 확대, 품질 프로세스 개선 |
+| 모바일 | 앱 성능 최적화, 오프라인 대응, 배포 자동화, 사용자 경험 개선 |
+
+### 수치 표현 규칙
+
+가능하면 결과에는 숫자를 넣는다.
+
+| 영역 | 예시 |
+|---|---|
+| 성능 | 응답속도 1.2초 → 0.3초 |
+| 빌드 | 빌드 시간 40% 단축 |
+| 테스트 | 커버리지 20% → 65% |
+| 장애 | 재현 시간 2시간 → 20분 |
+| DB | 조회 성능 60% 개선 |
+| 배포 | 배포 주기 주 1회 → 일 2회 |
+| 비용 | 로그 저장 비용 월 30% 절감 |
+
+정확한 수치가 없으면 비율, 배수, 범위 표현을 사용한다.
+
+```text
+기존 대비 절반 수준으로 줄였습니다.
+도입 전보다 약 3배 빠르게 처리할 수 있었습니다.
+반복 작업 시간을 30분에서 5분 내외로 줄였습니다.
+```
+
+### 피해야 할 문장
+
+```text
+저는 문제 해결 능력이 뛰어납니다.
+프로젝트를 성공적으로 마쳤습니다.
+팀원들과 협력하여 좋은 결과를 냈습니다.
+열심히 참여했습니다.
+```
+
+### 좋은 마무리 예시
+
+```text
+이 경험을 통해 단순히 기능을 구현하는 것을 넘어, 원인을 분석하고 측정 가능한 결과로 개선하는 개발 방식을 익혔습니다. 입사 후에도 이러한 방식으로 서비스 안정성과 품질 개선에 기여하겠습니다.
+```
+
+---
+
+## 3-3. 입사 후 포부
+
+### 핵심 질문
+
+```text
+어떻게 성장해 장기적으로 기여할 것인가?
+```
+
+### 작성 목표
+
+입사 후 포부는 다짐문이 아니다.
+
+아래 세 가지가 보여야 한다.
+
+1. 회사의 방향 이해
+2. 그 안에서의 내 성장 방향
+3. 성장 결과가 회사 기여로 이어지는 방식
+
+### 권장 구조
+
+```text
+① 회사의 방향 확인           → 1~2문장
+② 그 안에서 내 성장 방향      → 1~2문장
+③ 입사 초기 목표              → 1~2문장
+④ 1년 목표                    → 1~2문장
+⑤ 3년 목표                    → 1~2문장
+⑥ 보완점 + 보완 방법          → 1~2문장
+```
+
+### 작성 공식
+
+```text
+[회사 방향] + [나의 성장 계획] + [회사 기여 연결] = 포부
+```
+
+### 첫 문장 템플릿
+
+```text
+입사 후에는 ______ 개발자로 성장하고 싶습니다.
+입사 후에는 귀사의 ______ 방향 안에서 ______ 역량을 갖춘 개발자로 성장하고 싶습니다.
+```
+
+### 타임라인 기준
+
+| 시점 | 키워드 | 작성 내용 |
+|---|---|---|
+| 입사 초기 | 적응 | 도메인 파악, 코드베이스 이해, 기본 업무 수행 |
+| 1년 내외 | 독립 | 기능 단독 수행, 코드 리뷰 참여, 품질 개선 |
+| 3년 내외 | 주도 | 구조 개선 제안, 기술 공유, 팀 기여 확대 |
+
+### 보완점 작성 공식
+
+보완점은 약점 고백이 아니라 성장 가능성으로 보여야 한다.
+
+```text
+_______ 경험은 아직 부족하지만, _______을 통해 보완하고 있습니다.
+```
+
+예시:
+
+```text
+대규모 운영 경험은 아직 부족하지만, 개인 프로젝트에서 부하 테스트와 모니터링 환경을 구성하며 운영 감각을 보완하고 있습니다.
+```
+
+### 피해야 할 문장
+
+```text
+열심히 배우겠습니다.
+최선을 다해 기여하겠습니다.
+꼭 필요한 인재가 되겠습니다.
+회사와 함께 성장하겠습니다.
+```
+
+### 좋은 마무리 예시
+
+```text
+장기적으로는 서비스 구조 개선과 기술 공유에 기여하며, 팀이 안정적으로 확장할 수 있는 개발 문화를 만드는 데 보탬이 되겠습니다.
+```
+
+---
+
+## 3-4. 자기소개 / 성장 과정
+
+### 핵심 질문
+
+```text
+나는 어떤 개발자인가?
+```
+
+### 작성 목표
+
+개발 직무의 자기소개는 어린 시절 이야기나 성격 소개가 아니다.
+
+개발자로서의 정체성이 어떻게 형성되었는지 보여줘야 한다.
+
+### 권장 구조
+
+```text
+① 개발에 관심을 갖게 된 계기
+② 기술적 성장의 전환점이 된 경험
+③ 그 경험이 현재의 개발 방식에 준 영향
+④ 현재 나의 개발자 정체성 요약
+```
+
+### 좋은 방향
+
+```text
+동작하는 코드를 넘어 유지보수 가능한 구조를 고민하게 된 계기
+단순 구현보다 문제 원인 분석을 중요하게 여기게 된 경험
+협업 과정에서 코드 품질과 문서화의 중요성을 느낀 경험
+```
+
+### 피해야 할 내용
+
+```text
+어린 시절 이야기
+가족 환경 설명
+컴퓨터를 좋아해서 시작했다는 표현
+MBTI나 성격 유형 중심 설명
+직무와 연결되지 않는 인생 서사
+```
+
+---
+
+## 4. 분량별 작성 전략
+
+| 분량 | 핵심 메시지 | 사례 수 | 전략 |
+|---|---:|---:|---|
+| 500자 | 1개 | 1개 압축 | 결론 → 핵심 사례 → 결과 → 연결 |
+| 700자 | 1개 | 1개 상세 | 결론 → STAR 전개 → 업무 연결 |
+| 1000자 | 1~2개 | 1~2개 | 메인 사례 상세 + 보조 사례 간략 |
+
+분량이 짧을수록 메시지를 줄인다. 700자 이하에서는 강점 2~3개를 나열하지 않는다.
+
+---
+
+## 5. 문체 컨벤션
+
+### 5-1. 기본 문체
+
+- 기본 문체는 `~했습니다`, `~합니다` 존댓말을 사용한다.
+- 문체는 문서 전체에서 통일한다.
+- 지나치게 감정적인 표현보다 판단과 근거를 중심으로 쓴다.
+
+---
+
+### 5-2. 문장 길이
+
+- 한 문장은 60자 내외를 권장한다.
+- 80자를 넘으면 문장을 나눈다.
+- 긴 문장은 `문제 상황 → 판단 → 행동 → 결과`로 분리한다.
+
+나쁜 예:
+
+```text
+저는 프로젝트에서 API 응답속도가 느려지는 문제가 발생했을 때 로그를 분석하고 쿼리를 개선하고 캐시를 적용하여 성능을 개선했습니다.
+```
+
+좋은 예:
+
+```text
+프로젝트에서 API 응답속도가 느려지는 문제가 발생했습니다.
+먼저 로그를 분석해 병목 구간을 찾았습니다.
+이후 쿼리 구조를 개선하고 Redis 캐시를 적용해 응답속도를 줄였습니다.
+```
+
+---
+
+### 5-3. 1인칭 반복 제한
+
+`저는`으로 시작하는 문장이 3회 이상 연속되면 수정한다.
+
+대체 표현:
+
+```text
+해당 프로젝트에서는...
+이 과정에서...
+문제의 원인은...
+그 결과...
+이 경험을 통해...
+```
+
+---
+
+### 5-4. 접속사 사용 제한
+
+`그리고`, `또한`, `그래서`를 반복하지 않는다.
+
+문장 흐름 자체가 원인과 결과를 드러내도록 구성한다.
+
+---
+
+## 6. 금지 표현 및 대체 방식
+
+| 금지 표현 | 이유 | 대체 방식 |
+|---|---|---|
+| 열정을 가지고 | 증명 불가능 | 실제 행동과 지속 기간 제시 |
+| 최선을 다해 | 누구나 사용 가능 | 구체적 실행 계획 제시 |
+| 인재가 되겠습니다 | 추상적 | 어떤 역할을 할지 명시 |
+| 누구보다 | 비교 불가능 | 사례와 결과로 증명 |
+| 남다른 | 자기 과장 | 차별화된 행동 설명 |
+| 성장 가능성 | 범용 표현 | 회사 방향과 내 경험 연결 |
+| 4차 산업혁명 | 공허함 | 회사의 구체 기술 방향 사용 |
+| 업계를 선도하는 | 회사 소개문 같음 | 실제 서비스 / 기술 / 사업 근거 사용 |
+| 컴퓨터를 좋아해서 | 흔한 표현 | 개발 방식이 바뀐 경험 사용 |
+
+---
+
+## 7. 소제목 작성 컨벤션
+
+소제목은 문항 제목을 반복하지 않는다.
+
+### 좋은 소제목 조건
+
+- 15자 내외
+- 핵심 메시지가 보임
+- 개발자 정체성이 드러남
+- 추상적이지 않음
+
+### 좋은 예시
+
+| 문항 | 소제목 예시 |
+|---|---|
+| 지원동기 | 경험이 연결되는 곳 |
+| 지원동기 | 기술 방향에서 얻은 확신 |
+| 업무 강점 | 문제를 끝까지 추적하다 |
+| 업무 강점 | 성능 개선으로 증명한 실행력 |
+| 입사 후 포부 | 안정성과 확장성을 함께 |
+| 입사 후 포부 | 구조 개선으로 기여하다 |
+
+### 나쁜 예시
+
+```text
+지원동기
+저의 장점
+입사 후 포부
+열심히 하는 개발자
+끊임없이 도전하는 인재
+```
+
+---
+
+## 8. 경험 선택 기준
+
+자기소개서에 사용할 경험은 아래 기준으로 고른다.
+
+| 기준 | 설명 |
+|---|---|
+| 직무 관련성 | 지원 직무의 업무와 직접 연결되는가 |
+| 문제성 | 단순 구현이 아니라 해결할 문제가 있었는가 |
+| 내 역할 | 내가 맡은 판단과 행동이 분명한가 |
+| 결과 | 수치나 변화로 결과를 설명할 수 있는가 |
+| 회사 연결성 | 회사의 기술 / 서비스 방향과 연결 가능한가 |
+
+우선순위:
+
+```text
+회사 요구 역량과 맞는 경험 > 기술적으로 깊은 경험 > 단순히 규모가 큰 경험
+```
+
+---
+
+## 9. 작성 전 질문 리스트
+
+자기소개서를 쓰기 전 아래 질문에 답한다.
+
+### 회사 질문
+
+```text
+이 회사는 어떤 문제를 해결하는가?
+이 회사의 핵심 서비스는 무엇인가?
+이 회사의 주요 고객은 누구인가?
+채용공고에서 반복되는 기술 / 역량 키워드는 무엇인가?
+최근 사업 방향이나 기술 방향은 무엇인가?
+```
+
+### 나의 경험 질문
+
+```text
+이 회사의 요구 역량과 연결할 수 있는 프로젝트는 무엇인가?
+그 프로젝트에서 실제로 발생한 문제는 무엇인가?
+내가 직접 판단하고 실행한 부분은 무엇인가?
+결과를 수치로 표현할 수 있는가?
+이 경험이 입사 후 업무에 어떻게 연결되는가?
+```
+
+---
+
+## 10. 최종 점검 체크리스트
+
+### 10-1. 전체 구조
+
+- [ ] 문항별 역할이 분리되어 있는가
+- [ ] 같은 사례가 동일한 방식으로 반복되지 않는가
+- [ ] 모든 문항의 첫 문장에서 결론이 보이는가
+- [ ] 회사명과 직무명을 바꿔도 자연스러운 범용 문장이 없는가
+
+### 10-2. 회사 연결
+
+- [ ] 채용공고 / 홈페이지 / 기술 블로그 / 서비스 정보가 반영되었는가
+- [ ] 회사 방향과 내 경험이 연결되는 문장이 있는가
+- [ ] 회사 칭찬만 있고 내 경험이 빠진 문장은 없는가
+
+### 10-3. 사례 품질
+
+- [ ] 업무 강점 문항에 STAR 구조가 있는가
+- [ ] 팀이 아니라 내가 한 행동이 명확한가
+- [ ] 기술적 판단이 드러나는가
+- [ ] 결과에 숫자 또는 비교 표현이 있는가
+
+### 10-4. 표현 품질
+
+- [ ] `열정`, `최선`, `인재`, `누구보다` 같은 금지 표현이 없는가
+- [ ] `저는`으로 시작하는 문장이 3회 이상 반복되지 않는가
+- [ ] 80자를 넘는 문장이 없는가
+- [ ] 소제목이 문항 제목 반복이 아닌가
+- [ ] 맞춤법 검사를 완료했는가
+
+---
+
+## 11. AI 작성 / 리뷰용 지시문
+
+자기소개서를 작성하거나 리뷰하는 AI는 아래 원칙을 따른다.
+
+```text
+너는 IT 개발자 자기소개서 작성 코치다.
+자기소개서는 회사 분석 + 내 경험 연결 구조로 작성한다.
+추상적인 성격 표현, 감탄, 다짐문을 피하고 기술 경험과 문제 해결 과정을 중심으로 쓴다.
+각 문항은 두괄식으로 시작한다.
+지원동기는 회사 강점과 내 경험의 연결을 중심으로 쓴다.
+업무 강점은 STAR 구조로 작성하고, Action과 Result를 가장 구체적으로 쓴다.
+입사 후 포부는 회사 방향, 초기/1년/3년 성장 계획, 기여 방식으로 구성한다.
+문장은 60자 내외를 권장하고, 80자를 넘으면 나눈다.
+금지 표현은 구체적 행동과 결과로 대체한다.
+회사명만 바꿔도 통하는 범용 문장은 수정한다.
+```
+
+---
+
+## 12. 출력 형식 컨벤션
+
+자기소개서 초안 출력 시 기본 형식은 아래와 같다.
+
+```markdown
+## 문항명
+
+### 소제목
+
+본문
+```
+
+리뷰 출력 시 기본 형식은 아래와 같다.
+
+```markdown
+## 총평
+-
+
+## 좋은 점
+-
+
+## 수정이 필요한 부분
+| 위치 | 문제 | 수정 방향 |
+|---|---|---|
+
+## 개선 초안
+
+## 최종 체크리스트
+- [ ] 회사 연결
+- [ ] 경험 증명
+- [ ] 수치 결과
+- [ ] 입사 후 기여
+- [ ] 금지 표현 제거
+```
+
+---
+
+## 13. 한 줄 원칙
+
+좋은 IT 개발자 자기소개서는 다음 한 문장으로 정리된다.
+
+```text
+회사를 분석하고, 내 경험으로 증명하고, 앞으로의 기여 계획까지 연결한 글이다.
+```
+