수행한 구축 사례 중 기술 과제가 뚜렷했던 건들을 골라, 배경과 판단 근거까지 함께 정리했습니다.
연구원들이 매번 개발팀에 요청해야 데이터 전처리부터 모델 추론까지 파이프라인을 바꿀 수 있었다. 연구 방향이 자주 바뀌는 국가 연구과제 특성상, 개발팀을 거치지 않고 연구원이 직접 구성을 조정할 수 있어야 했다.
핵심 기술 선택
전처리부터 추론까지를 노드 단위로 쪼개고 연결 방식으로 구성
연구원마다 필요한 전처리 단계와 모델 조합이 달라, 고정된 파이프라인 하나로는 대응이 안 됐다. 각 단계를 독립된 노드로 만들어 연구원이 필요한 노드만 골라 연결하게 하니, 새 실험 구성마다 개발팀 요청 없이 바로 시도할 수 있었다.
채용 담당자가 공고 하나에 쌓이는 지원서를 하나하나 읽고 요건에 맞는지 판단하고 있었다. 지원자가 늘수록 검토 시간이 늘어나는데, 왜 특정 후보를 골랐는지 근거를 남기기도 번거로웠다.
핵심 기술 선택
적합도 점수만 보여주지 않고 근거 항목을 함께 노출
채용 담당자가 점수만 보고는 왜 그런 결과가 나왔는지 설명할 수 없어 실제 의사결정에 쓰지 못했다. 어떤 요건이 맞고 어떤 요건이 부족한지 항목별로 나눠 보여줘서, 담당자가 최종 판단의 근거로 삼을 수 있게 했다.
결제사에서 내려오는 거래 내역과 은행 입금 내역을 담당자가 매일 엑셀로 맞춰보고 있었다. 건수가 늘면서 대사 작업이 하루를 넘기기 시작했고, 마감이 밀리면 다음 정산에도 영향을 줬다.
핵심 기술 선택
대사 결과를 자동 확정하지 않고 예외 건만 담당자 확인 후 마감
금액이 걸린 정산이라 시스템이 자동으로 확정해버리면 오류가 있어도 발견이 늦어진다. 규칙에 맞는 건은 자동 처리하되 규칙을 벗어난 건은 반드시 사람이 확인하고 승인해야 마감되도록 흐름을 나눴다.
사내 규정과 기술 문서를 검색하고 싶었지만 외부 LLM 서비스에 문서를 올릴 수 없는 보안 정책이 있었다. 문서가 회사 밖으로 나가지 않으면서도 질문에 바로 답하는 방식이 필요했다.
핵심 기술 선택
외부 LLM 대신 사내망 안에서 도는 언어 모델을 구축
문서를 외부로 반출하지 않는 것이 요구사항의 전제였다. 모델을 사내 인프라에 두면 질의와 문서가 회사 경계를 넘지 않는 구조를 만들 수 있었다.
본부가 가맹점 운영 지표를 점포별로 따로 보고받고 있어, 어느 점포에 지원이 더 필요한지 판단하려면 담당자가 매번 보고서를 취합해야 했다.
핵심 기술 선택
지표를 점포가 직접 입력하되 본부에서 최종 확인 단계를 두는 구조
점포 현장 데이터는 점포가 가장 정확히 알지만, 입력값을 그대로 신뢰하면 오입력이 그대로 지표에 반영되는 문제가 있었다. 점포 입력 이후 본부 담당자가 확인하는 단계를 하나 둬서, 데이터 정확도와 현장 부담 사이 균형을 맞췄다.
설비에 이상이 생겨도 현장 작업자가 눈으로 확인하기 전까지는 아무도 몰랐다. 설비 신호는 PLC에 남아 있었지만 그걸 모아서 보는 화면이 없었다.
핵심 기술 선택
HTTP 폴링 대신 MQTT로 설비 신호 수집
설비 PLC가 초당 수백 건 단위로 신호를 밀어올리는데, 일정 주기로 상태를 물어보는 폴링 방식으로는 주기 사이에 발생한 신호가 그대로 유실됐다. 브로커를 두고 설비가 신호를 발행하는 방식으로 바꿔 유실 없이 순서대로 받을 수 있게 했다.
거점마다 전력 사용량을 월말에 청구서로만 확인하고 있어, 절감 목표를 세워도 중간에 얼마나 달성했는지 알 방법이 없었다. 사용량이 튀는 시점을 그때그때 확인할 수 없어 원인 파악도 늦었다.
핵심 기술 선택
시계열 데이터 저장에 TimescaleDB 사용
거점마다 짧은 주기로 쌓이는 전력 사용량 데이터가 시간이 지날수록 방대해지는데, 이후에는 이번 달이 아니라 작년 같은 시기와 비교하는 식으로 기간을 넘나드는 조회가 필요했다. 시계열 데이터에 맞춘 구조를 써서 기간별 집계 조회 성능을 확보했다.
수주부터 출하까지 각 공정 단계가 어디까지 진행됐는지 현장 화이트보드와 담당자 기억에 의존하고 있었다. 공정이 늘어날수록 지금 어느 단계에서 지연이 생기는지 파악하기 어려워졌다.
핵심 기술 선택
화이트보드 방식 그대로 보드형 화면으로 옮기고 데이터 구조는 새로 설계
현장 담당자가 이미 화이트보드로 공정을 옮겨가며 확인하는 방식에 익숙했다. 화면 조작 방식은 익숙한 형태를 유지하되, 뒷단 데이터는 공정 이동 이력이 남도록 새로 설계해 나중에 어느 공정에서 지연이 반복되는지 추적할 수 있게 했다.
영상 편집을 브라우저 안에서 끝내고 싶어하는 고객이었다. 데스크톱 편집 프로그램 설치 없이 레이어와 타임라인을 다루는 초기 버전이 필요했다.
핵심 기술 선택
캔버스 렌더링을 WebGL로 구현
레이어가 여러 장 겹치고 타임라인을 스크럽할 때마다 다시 그려야 하는데, 일반 캔버스 2D로는 레이어가 늘어날수록 화면이 버벅였다. GPU를 쓰는 WebGL로 옮겨 레이어 수가 늘어도 편집 중 화면 반응을 유지할 수 있었다.
매장마다 재고 장부가 따로 돌고 있었다. 본사가 전체 재고를 파악하려면 매장에 전화를 돌리거나 엑셀을 취합해야 했고, 그 사이 실제 재고와 장부가 어긋나는 일이 반복됐다.
핵심 기술 선택
기존 회계 시스템은 그대로 두고 재고 데이터를 API로만 동기화
회계 시스템을 새로 만들면 세무 처리까지 다시 검증해야 해서 리스크가 컸다. 재고관리 영역만 새로 짓고 마감 시점에 회계 쪽에 필요한 수치만 API로 넘기는 편이 안전했다.
전국 곳곳의 스크린골프 매장을 프랜차이즈로 운영하는 본사였지만, 매장 기기 상태와 매출은 각 지점 PC에만 남아 있었다. 특정 매장의 기기가 멈춰도 본사는 고객 항의 전화가 오기 전까지 알 방법이 없었다.
핵심 기술 선택
매장 PC에 상주 에이전트를 두고 PostgreSQL 중앙 서버로 상태를 밀어올리는 구조
매장 인터넷 회선이 지역마다 품질이 달라 중앙에서 매장으로 매번 상태를 물어보는 방식은 응답이 느리거나 아예 끊기는 매장이 있었다. 매장 쪽에서 먼저 보내는 구조로 바꾸니 회선이 불안정한 매장도 최소한의 주기로는 상태가 들어왔다.
전체 24건의 작업물은 포트폴리오에서 볼 수 있습니다.
포트폴리오 전체 보기