Backend / AI Integration / Reliable Systems

업무 요구사항을 실제로 작동하는 백엔드 시스템으로 구현합니다.

데이터, 권한, 처리 상태와 실패 조건을 명확하게 설계하고, AI 기능은 서버의 검증과 사람의 승인 안에서 실제 업무와 연결합니다. Java/Spring과 Python/FastAPI를 업무 특성에 따라 사용하며, 두 기술 축 모두 회사 코드와 독립된 공개 구현과 실행 검증으로 보여드립니다.

제가 잘하는 일

백엔드 역할을 중심으로 데이터, AI, 보안과 운영을 연결합니다.

먼저 쉽게 이해할 수 있는 결과를 설명하고, 필요한 경우 아래에 구현 기술과 검증 근거를 붙입니다.

공개 검증

몇 개를 테스트했는지보다 무엇을 실제로 확인했는지 보여드립니다.

실제 모델, 실패 조건, 권한 경계와 실행 환경처럼 채용 검토자가 다시 확인할 수 있는 범위를 우선합니다.

실제 모델 E2E

OpsMate Local: 실제 LLM 핵심 업무 시나리오 9건 전건 성공

Ollama `gemma3:12b`를 사용해 구매 요청부터 초안 생성까지의 핵심 합성 시나리오를 실제 모델로 실행했습니다.

실패 경계: 잘못된 모델 출력이나 모델 장애가 중요한 데이터 저장으로 이어지지 않게 차단

외부 접속 검증

사용자 작업 분리와 외부 노출 차단 확인

실제 Internet HTTPS 경로에서 서로 다른 사용자의 작업이 섞이지 않는지, 과도한 요청이 차단되는지, DB와 모델이 외부에 직접 노출되지 않는지 확인했습니다.

복구: 서비스를 닫고 같은 검증 버전으로 다시 열 수 있는지까지 확인

Python / PostgreSQL E2E

Text2SQL Workspace: 사용자 격리와 읽기 전용 DB 경계를 실제 runtime에서 검증

Python/FastAPI 멀티사용자 API에서 자연어 질문을 SQL로 연결하고 PostgreSQL Docker runtime에서 사용자별 workspace, SQL 정책과 DB 권한을 함께 확인했습니다.

실패 경계: 다른 사용자 접근 차단, 위험 SQL 실행 전 차단, analytics reader의 write 거부

독립 재현 사례

업무에서 자주 발생하는 실패 조건을 합성 샘플로 재현

로그인과 권한, 데이터 정합성, 배포와 복구, 업무 규칙 일관성 문제를 회사 코드와 독립된 Java/Spring 샘플로 다시 구현했습니다.

검증: 정상 흐름과 함께 권한 오류, 기간 경계, 잘못된 설정과 상태 불일치를 자동 테스트

대표 프로젝트

AI는 초안을 돕고, 서버는 중요한 규칙을 지킵니다.

`OpsMate Local`은 구매 요청부터 승인과 발주까지의 백엔드 업무 흐름에 AI 초안 생성을 연결한 프로젝트입니다.

Controlled AI Integration

AI의 결과를 그대로 저장하거나 업무 결정으로 사용하지 않습니다.

AI는 요청을 이해하고 초안을 제안하지만, 사용자 권한, 상태 변경, 중복 방지와 발주는 서버가 최종 검증합니다. 모델이 잘못된 결과를 반환하거나 사용할 수 없으면 중요한 처리를 진행하지 않습니다.

기술적으로: Spring Boot, Spring Security, JPA/PostgreSQL, local LLM adapter, RBAC, idempotency, fail-closed, audit event, isolated session workspace를 적용했습니다.

업무 흐름

  1. 자연어 구매 요청
  2. 서버가 정책 근거 조회
  3. AI가 초안 제안
  4. 사람이 승인 또는 반려
  5. 서버가 승인된 요청만 발주
  6. 누가 무엇을 했는지 감사 기록

확인한 범위: 실제 모델 E2E, 내부 배포와 네트워크 경계, Internet HTTPS의 사용자 작업 분리, rate limit, 비노출, close/reopen을 확인했습니다. 장기 production SLA는 주장하지 않습니다.

Python / Data & AI Backend

모델이 만든 SQL을 여러 사용자가 안전하게 쓰는 백엔드 기능으로 연결했습니다.

`Text2SQL Workspace`는 Python/FastAPI, PostgreSQL과 Docker로 구현한 독립 공개 멀티사용자 데이터 질의 서비스입니다.

Multi-user Text2SQL

SQL 생성보다 사용자 격리, 실행 권한과 정답 검증을 먼저 설계했습니다.

사용자가 workspace에서 자연어 질문을 보내면 모델은 SQL 후보만 제안합니다. 서버가 사용자 소유권과 SQL 정책을 확인한 뒤 전용 PostgreSQL reader로만 실행하며, 결과 평가는 SQL 문자열이 아니라 실제 columns와 rows를 기준으로 합니다.

기술적으로: Python, FastAPI, SQLAlchemy, SQLGlot, PostgreSQL, psycopg, Docker Compose, result-based evaluation을 적용했습니다.

검증한 경계

  1. 사용자별 workspace와 query history 분리
  2. 위험 SQL을 DB 실행 전에 차단
  3. PostgreSQL 전용 reader로 SELECT만 허용
  4. 동일 reader의 write 시도 거부
  5. generation / validation / execution / correctness 분리
  6. Docker/PostgreSQL E2E에서 runtime 경계 재검증

한계: 현재 실제 LLM의 통계적 정확도, production IdP, 대규모 동시 사용자와 SLA는 검증하거나 주장하지 않습니다.

실무 문제 해결 사례

프레임워크보다 해결한 문제와 실패 조건을 먼저 설명합니다.

회사 코드와 데이터를 공개하지 않고 직접 담당한 문제를 일반화해 독립 샘플과 테스트로 재현했습니다.

AI를 활용해 개발하는 방식

AI가 빨라져도 완료 기준은 테스트와 실제 실행입니다.

AI를 조사, 계획, 구현과 리뷰에 활용하지만 결과를 그대로 완료로 보지 않습니다.

사람이 목표와 제약을 유지하고, AI는 탐색과 구현을 가속합니다.

다른 개발자나 AI가 작업을 이어받아도 현재 상태, 제한과 검증 기준을 파악할 수 있도록 작업 규칙과 검증 근거를 함께 관리합니다.

쉽게 말하면: AI가 만든 코드와 설명도 다시 테스트하고 실제로 실행해 확인합니다.

기본 workflow

  1. 문제와 제약 정의
  2. 구현 계획
  3. AI를 활용한 탐색과 구현
  4. 자동 테스트와 리뷰
  5. 실제 실행 환경 검증
  6. 결과와 한계 기록

사용하는 기술

백엔드 시스템을 만들기 위해 목적에 맞는 도구를 선택합니다.

기술 이름은 역할 자체가 아니라 문제를 해결하기 위한 구현 도구로 설명합니다.

공개 범위

확인한 사실과 공개 가능한 코드만 담았습니다.

실무 사례에는 회사 코드, 고객 데이터와 내부 식별자를 포함하지 않습니다. 독립 재현 샘플과 검증된 공개 evidence를 구분하며, 확인하지 않은 장기 운영, 성능과 팀 전체 성과는 주장하지 않습니다.