73 lines
8.5 KiB
Markdown
73 lines
8.5 KiB
Markdown
# ㈜위존 솔루션 개발자 자기소개서
|
|
|
|
---
|
|
|
|
## 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·출입관리 솔루션처럼 장기간 운영되는 시스템에서 강점이 되리라 확신합니다. |