제가 할 수 있는 일

문제를 안고 있는 당사자와 직접 일합니다 —— 운영 담당자, 창업자, 고객사 엔지니어 —— 불완전한 요구를, 범위가 분명하고 금액이 있으며 "완료"의 정의가 공유된 제안으로 바꿉니다. 이 일은 양쪽에서 모두 해 봤습니다: 사업회사 내부에서는 업무 프로세스 담당으로 문서가 없던 재무·물류 업무를 그렸고, 외부 엔지니어로서는 AI 시스템을 사 본 적 없는 중소기업의 프로젝트 평가를 했습니다.

관련 기술

요구사항 파악 · As-Is / To-Be 업무 정리 · 비용을 포함한 구축 견적 · 착수 전 서면 합의 · 이해관계자 워크숍

뒷받침하는 사례 사례 02 · 사례 04

실제 운영 안에서 돌아가야 하는 AI 시스템입니다: 서류에서 항목을 뽑아내고, 기록하기 전에 사람이 확인하는 공정. 고객 지원 AI의 지식 구조, 도구 호출, 대화 관리, 상담원 인계. 그리고 재무와 물류에 걸쳐 원래 수기로 입력하던 RPA.

관련 기술

OpenAI / Claude APIs · RAG · 검색 튜닝 · prompt 버전 관리 · tool calling · OCR(PyTesseract) · Power Automate · Datagrand RPA · Selenium · LangChain / LangGraph(평가함) · Ragas(PoC) · n8n · Dify

뒷받침하는 사례 사례 02 · 사례 03

이어질 것을 전제로 만들어지지 않은 시스템끼리 잇습니다 —— 고객사의 오래된 ERP, API가 없는 원천 시스템, 외부 이커머스·결제 플랫폼, 메시지 큐, 그리고 그 사이에 끼어 있는 사람의 공정. 반복해서 나오는 판단은 "살 것인가 만들 것인가"이고, 저는 양쪽을 충분히 여러 번 해 봤기 때문에 정말 흥미로운 질문이 어디에 있는지 압니다: 어떤 제약이 "사 온 부품"을 성립하지 않게 만드는가.

관련 기술

REST API 설계 · OpenAPI / Swagger · webhooks · OAuth 2.0 / JWT · RabbitMQ · Redis · PostgreSQL / MySQL · Shopify API · Stripe · PayPal · 침습적이지 않은 연동

뒷받침하는 사례 사례 01 · 사례 02

가동된 뒤에도 책임은 저에게 있습니다. 긴 작업은 처음이 아니라 중단된 지점부터 이어서 돌립니다. 실패는 사람이 아직 수작업으로 되돌릴 수 있는 시점에 드러나게 합니다. 큐로 처리해서, 느린 한 건이 다음 고객을 기다리게 하지 않도록 합니다. 제출은 멱등하게 만들어, 새로고침해도 중복으로 실행되지 않게 합니다. 쓰이지 않는 자원은 붙잡고 있지 않고 해제합니다.

관련 기술

queue workers · 비동기 처리 · 체크포인트 재개 · 멱등 제출 · 캐시 전략 · Docker · NGINX · CI/CD · AWS / GCP / Azure · 모니터링과 알림

뒷받침하는 사례 사례 03 · 사례 05

제가 이끄는 것은 납품과 기술 판단이지, 인원 수가 아닙니다: 팀의 의견을 들은 뒤의 최종 설계·기술 선택 결정, 팀이 실제로 따르는 코드 리뷰 운영, 그리고 엔지니어가 정말로 막혀 있는 지점에서 끌어내는 일 —— 제 경험으로는 그것은 거의 언제나 코드가 아니라 인터페이스 계약입니다.

관련 기술

기술 리드 · 코드 리뷰 운영 · 멘토링 · 스프린트 계획과 작업 분해 · 3개 언어 납품(English · 중국어 · Bahasa Malaysia)

뒷받침하는 사례 사례 01 · 사례 05