김대정 · 포트폴리오

1. 글쓰기 품질 기준 수립과 AI 생성·검수·교정 설계

상황

Threads에서 인플루언서가 작성한 것처럼 자연스러운 글을 생성해야 했습니다. 초기 생성 결과에는 한국어에서 잘 쓰지 않는 표현과 지나치게 정돈된 문체가 나타났습니다. 의사결정권자인 대표님께 품질 피드백을 받았지만, “Claude Code로 작성한 글보다 어색하다”는 정성적 평가만으로는 수정할 요소와 통과 기준을 정하기 어려웠습니다.

구현

• 글 구조 기반 품질 기준 수립: 실제 Threads 글과 AI 생성 글의 구조를 분석하고, 점수·구두 피드백을 활용해 글쓰기 기준을 구체화했습니다. 직접 수집한 글을 분류하고 인플루언서를 섭외해 평가 점수와 이유를 모았습니다. 후킹·본문 전개·정보 밀도·말투와 문단별 줄 수·줄당 단어 수 등 구조·가독성 요소를 기준으로 정리했습니다. 생성 글에도 평가를 반복하며, 점수만으로 설명하기 어려운 어색한 표현과 문맥은 구두 피드백으로 보완해 생성 규칙을 개선했습니다.

• 지시 충돌·역할 구성 비교: 글쓰기 규칙의 준수 편차를 줄이기 위해 프롬프트 구성과 모델별 처리 역할을 비교했습니다. 규칙을 하나의 프롬프트에 반영하면서 소재 보존·정보 선별·분량 제약이 충돌하자, 규칙을 압축하거나 역할별로 분리하고 중간 모델을 추가하는 구성을 실험했습니다. 지시 준수 여부·내용 누락·후단 교정 효과를 확인하며 프롬프트와 역할 구성을 조정했습니다.

• 품질 기준을 적용한 검수·교정: 생성 글의 품질을 평가하고, 미달 사유를 같은 생성 세션에 전달해 교정하도록 구성했습니다. 의미 연결과 표현 정확성을 독립 평가 축으로 두고, 평균 점수와 축별 최소 기준을 함께 검사했습니다. 교정 횟수를 소진하면 의미 관련 기준을 우선해 후보를 선택하고, 자연스러운 구어체까지 불필요하게 수정하지 않도록 교정 범위를 조정했습니다.

결과

생성 결과에 대한 평가·피드백을 축적하고, 프롬프트와 검수·교정 기준을 지속적으로 개선할 수 있는 파이프라인을 구축했습니다. 모델의 검수 결과와 사람의 점수·구두 피드백을 바탕으로 생성 규칙을 조정하고 재평가하며, 고객의 문체와 요구에 맞는 생성 품질을 개선했습니다.

2. 생성 실행 구조 개선과 처리 시간 85% 단축

상황

고객이 초안을 확인하기까지의 대기 시간을 줄여야 했습니다. 기존에는 재료 계획·생성·사실 검사를 각각 별도의 LLM 호출로 실행해 글 생성에 294초가 소요됐습니다. 서비스 운영 과정에서 생성 대기를 개선 과제로 잡고, 기존 품질 기준을 유지하면서 실행 구조를 단순화할 방법을 검토했습니다.

구현

계획·생성·사실 확인을 하나의 Agent 세션으로 통합하고, 앞서 수립한 품질 기준을 적용하는 검수·교정 절차는 유지했습니다.

• 생성 실행 구조 통합: 단계별로 별도 LLM 호출을 실행하던 구조를, 하나의 Agent가 같은 맥락에서 계획·생성·사실 확인을 이어가는 방식으로 변경했습니다.
• 품질 검증 유지: 입력 검사·결과 검증·교정 로직과 사용자 프롬프트 템플릿을 공통으로 유지해, 실행 구조를 변경해도 기존 품질 기준을 적용하도록 구성했습니다.
• 단계적 전환: 엔진 선택 설정으로 기존 방식과 전환할 수 있도록 구성했습니다. 적용 과정에서 기존 엔진으로 되돌릴 수 있는 경로를 유지하고, 전환을 마친 뒤 이전 엔진을 제거했습니다.

결과

글 생성 시간을 294초에서 43초로 약 85% 단축했습니다. 기존 품질 검증 절차를 유지하면서 초안 전달까지의 대기를 줄였으며, 서비스 운영 데이터에서 생성 중 사용자 이탈률 약 40% 개선을 확인했습니다.

3. 비동기 글 생성의 사용량 정산과 실행 상태 관리

상황

고객별 사용 한도를 적용하면서, 별도 AI 서비스에서 비동기로 글을 생성해야 했습니다. 사용량 예약과 AI 서비스의 요청 접수를 하나의 트랜잭션으로 묶을 수 없어, 동시 요청이나 응답 유실 상황에서도 사용량을 일관되게 관리해야 했습니다. 재처리·취소 이후 도착하는 이전 작업의 결과도 구분해야 했습니다.

구현

• 동시 요청의 한도 검사·예약: 사용자·일자별 advisory lock으로 한도 검사와 사용량 예약을 직렬화했습니다. 확정 차감량과 진행 중 예약량을 합산해 한도를 판단하고, 같은 트랜잭션에서 예약을 저장했습니다. 외부 AI 호출은 트랜잭션 밖에서 실행하고 예약 ID를 접수 멱등 키로 사용했습니다.
• 실행 결과 기반 정산: 응답이 유실돼도 생성이 진행될 수 있으므로, 접수 여부가 불명확한 요청은 예약을 유지한 채 실행 결과를 조회했습니다. 확인된 결과에 따라 사용량을 차감·반환하고, 취소된 요청은 AI 서비스의 사용량 소모 여부를 기준으로 정산했습니다.
• 이전 작업의 결과 저장 제어: 상태 전이 규칙과 version CAS로 재처리·취소 이후의 결과 저장을 제어했습니다. 워커가 읽은 버전과 현재 버전이 일치하는 경우에만 저장하도록 구성해, 이전 워커의 늦은 결과가 최신 실행 상태를 덮어쓰는 것을 방지했습니다.

결과

사용량 예약부터 실행 결과 확인·정산까지 연결하고, 재처리·취소 상황에서도 최신 실행 상태를 유지하도록 구성했습니다. 접수 여부가 불명확한 요청을 즉시 반환하지 않고 확인 후 정산해, 실제 생성 처리와 고객 사용 한도를 일관되게 관리했습니다.

4. 외부 게시 상태와 내부 발행 상태의 정합성 확보

상황

Threads의 실제 게시 결과와 서비스의 발행 상태를 일치시켜야 했습니다. 외부 API 응답이 유실되면 게시가 완료됐어도 내부에서는 결과를 확정할 수 없었습니다. 단순 재시도로 인한 중복 게시를 피하면서, 중단된 발행 작업을 복구할 구조가 필요했습니다.

구현

• 승인 기록과 실행 요청의 원자적 저장: 고객의 수정본·승인 결정·예약 및 발행 작업을 하나의 트랜잭션으로 저장하고, commit 이후 워커가 Meta Threads API를 호출하도록 구성했습니다. 동일한 명령의 재요청은 기존 결과를 반환하도록 멱등 처리를 적용했습니다.
• 외부 상태 확인 후 복구: 응답 유실을 게시 실패로 단정하지 않고, 기존 발행 준비 객체인 container의 상태를 조회했습니다. 게시가 확인되면 내부 발행 상태에 결과를 반영하고, 이미 발행된 후속 답글은 건너뛰도록 구성했습니다.
• 중단된 작업의 실행 권한 관리: 워커 중단 시 lease 만료 후 기존 container를 기준으로 작업을 재개했습니다. 시도 토큰으로 이전 워커의 늦은 완료 처리를 제한하고, 실패 시 작업 상태·시도 이력·실패 알림을 함께 저장했습니다.

결과

외부 게시 상태를 확인해 내부 발행 상태를 갱신하고, 중단된 작업을 이어갈 수 있는 복구 구조를 구축했습니다. 승인·예약 발행부터 결과 반영까지 연결하고, 응답 유실 시 무조건 재게시하지 않고 기존 게시 결과를 확인해 복구하도록 구성했습니다.

1. 재고·발주 도메인 설계와 처리 정합성

상황

재고 변동을 정확히 기록하고, 기존 발주 상태와 승인 절차를 고려해 후속 주문을 연결해야 했습니다. 재고가 안전재고보다 적더라도 이미 발주 예정이나 진행 중 주문이 있을 수 있어, 수량만으로 신규 주문을 생성하면 보충 업무가 중복될 수 있었습니다.

출고 반영과 후속 발주 판단 사이의 정합성도 필요했습니다. 출고 저장과 후속 처리 요청을 따로 실행하면, 중간 실패로 재고만 차감되고 발주 판단은 시작되지 않을 수 있었습니다.

구현

재고 기록과 발주 의사결정은 분리하고, 출고 변경과 후속 판단 요청은 같은 트랜잭션으로 연결했습니다.

• 재고 현황과 변동 이력을 분리했습니다. 특정 일자의 재고 상태를 확인하는 업무와 개별 입출고 원인을 추적하는 업무는 조회 목적이 달랐습니다. 품목별·일자별 재고에는 현재 수량과 입출고 누계를, 개별 입출고 내역에는 변동 수량과 거래 후 잔량을 기록했습니다. 품목·일자 조합에 고유 제약을 적용해 일자별 재고의 중복 생성을 방지했습니다.

• 실제 조회 조건에 맞춰 복합 인덱스를 구성했습니다. 품목별 재고 현황과 기간별 입출고 이력을 조회하는 경로를 기준으로, 품목·재고 일자와 재고 식별자·거래 일자 조합의 인덱스를 적용했습니다. 데이터 모델을 나누는 데서 끝내지 않고, 각 기록을 조회하는 필터와 기간 조건까지 함께 고려했습니다.

• 발주 필요성 판단과 실제 주문 생성을 분리했습니다. 재고가 부족하더라도 보충이 진행 중이거나 현장 승인이 필요한 경우가 있어, 수량 조건만으로 주문을 생성하는 방식은 업무 절차에 맞지 않았습니다. 안전재고·자동발주 수량과 함께 미처리 예정·진행 중 주문을 확인하고, 발주 예정·승인·주문을 단계별 상태로 관리했습니다. 승인 또는 자동 승인된 예정만 실행 시점에 실제 주문으로 연결했습니다.

• 출고와 후속 요청은 함께 저장하고, 발주 판단의 실행은 분리했습니다. 출고만 반영되고 후속 요청이 누락되는 상황을 방지하기 위해 Transactional Outbox를 적용했습니다. 출고 처리에 사용한 DB 세션을 이벤트 저장에도 전달해 재고 변경과 발주 판단 이벤트가 함께 커밋·롤백되도록 구성했습니다. 이후 별도 Consumer가 커밋된 대기 이벤트를 조회해 발주 판단을 실행했습니다.

• 요청 저장과 처리 완료를 구분해 추적했습니다. 이벤트가 저장됐다는 사실만으로 후속 업무가 완료된 것은 아니므로, Consumer의 실행 결과를 완료·실패 상태로 기록했습니다. 출고 기록과 연결된 후속 작업의 처리 여부를 확인하고, 실패한 이벤트를 식별할 수 있도록 구성했습니다.

결과

재고 현황·변동 이력부터 발주 예정·승인·주문까지 연결하는 도메인 구조를 구축했습니다. 현재 수량뿐 아니라 기존 보충 업무와 승인 조건을 반영해 발주를 판단하도록 구성했습니다.

출고와 후속 요청의 저장은 원자적으로 묶고, 실제 발주 판단은 커밋 이후 별도로 실행하도록 분리했습니다. 이를 통해 재고 변경과 후속 요청의 저장 정합성을 확보하고, 이벤트별 처리 여부와 실패 상태를 추적할 수 있도록 했습니다.

2. 대량 Excel 검증의 반복 DB 조회 개선

상황

단일 파일당 300건 미만을 전제로 설계한 검증 로직에 평균 1만 건 이상의 파일이 입력되면서, 검증에 10분 이상 소요됐습니다. 각 행의 카테고리·업체·제품 정보를 DB와 대조하면서 같은 정보를 반복 조회하는 구조가 처리 부담을 키웠습니다.

구현

데이터 조회와 행별 검증을 분리해, 검증 데이터 수집을 최대 5회 일괄 조회로 변경했습니다.

• 입력에서 고유한 카테고리명·업체 식별 정보·제품명을 추출하고, 대조에 필요한 기존 데이터를 일괄 조회했습니다.
• 조회 결과를 Dictionary로 구성해 각 행을 추가 DB 조회 없이 대조했습니다.
• 형식 오류·기존 데이터 충돌·파일 내부 중복을 행·셀 단위로 수집해 수정 위치와 사유를 반환했습니다.

결과

업무 검증 규칙을 유지하면서 반복 DB 접근을 줄여 대량 Excel 검증 시간을 단축했습니다. 동일한 대조 조건에서 검증 데이터 수집의 조회 호출을 7N+1회에서 최대 5회로 줄였습니다. N은 입력 행 수입니다.

3. RabbitMQ 기반 알림 처리와 재발송 관리

상황

외부 알림의 발송 결과를 추적하고, 실패한 작업을 업무 조건에 맞게 재처리할 경로가 필요했습니다. 주문이 생성되더라도 병원·공급사 알림은 실패할 수 있어, 주문 처리와 외부 발송의 책임을 분리해야 했습니다.

구현

알림 전용 Exchange·Queue와 TaskIQ 워커로 발송을 분리하고, DB의 업무 상태를 기준으로 재발송을 제어했습니다.

• 실행 경로 분리: 알림 기록을 저장한 뒤 내부 알림 ID를 큐에 전달하고, 워커가 외부 발송을 실행하도록 구성했습니다.
• 발송 결과 추적: 외부 요청 ID·발송 상태·실패 이력을 저장하고, 관련 알림의 처리 결과를 주문 상태에 반영했습니다.
• 조건부 재발송: 재발송 요청 시 지점 권한·주문 상태·기존 발송 상태·재발송 횟수를 검사해 허용된 작업만 큐에 전달했습니다.

결과

외부 발송을 업무 API에서 분리하고, 실패 이력 확인부터 조건부 재발송까지 운영 경로를 구축했습니다. 운영자가 현재 주문 상태와 발송 결과를 확인한 뒤 필요한 알림을 재처리할 수 있도록 구성했습니다.

1. 실시간 상담 코파일럿 구축

상황

상담 흐름에 맞춰 조언과 업셀링 제안을 제공해야 했습니다. 전사 조각마다 응답을 생성하면 대화 맥락이 충분하지 않은 상태에서 호출이 반복되고, 입력이 쌓일 때까지 기다리기만 하면 고객이 고민하거나 말을 멈춘 동안 안내가 갱신되지 않았습니다.

구현

• 전사 입력과 조언 생성을 분리: WebSocket으로 전달되는 중간·확정 전사를 구분하고, 키워드와 누적 대화량·문맥 판정을 조합해 생성 시점을 결정했습니다. 입력이 충분히 쌓이지 않은 상태에서 대화가 멈추는 경우에는 타이머로 조언 생성 여부를 다시 확인하도록 구성했습니다.
• 상담 맥락과 검색 자료를 응답에 반영: 조언·업셀링별 대화 버퍼와 이전 응답을 관리하고, 내부 시스템에서 검색한 피부과 자료를 상담 맥락과 함께 전달했습니다. 진행 중인 프로모션과 연계 시술을 안내하고, 예상 질문과 대응 방향을 상담 화면에 제공하도록 구성했습니다.
• 반복 응답의 생성 호출을 캐시로 줄이는 구조: 상담 입력과 검색 문맥을 기준으로 생성 응답을 캐싱했습니다. 캐시가 적중하면 저장된 응답을 반환해 해당 조언·추천의 LLM 생성 호출을 생략하도록 구현했습니다.

결과

실시간 전사를 상담 맥락에 맞는 조언·업셀링 제안으로 연결하는 코파일럿을 구축했습니다. 입력 처리와 생성 시점을 분리하고, 대화 중 대기 상황을 보완하는 타이머와 응답 재사용 경로를 함께 구성했습니다.

2. 주기적인 음성 세션 중단에 대응한 연결 구조 설계

상황

상담 중 약 1분마다 음성 모델의 응답이 중단돼, 이어지는 발화의 전사가 끊기는 문제가 발생했습니다. 하지만 WER·CER와 상담 핵심 용어를 기준으로 비교한 후보 중 해당 모델의 인식 품질이 가장 좋았고, 전사와 번역을 함께 처리할 수 있다는 장점도 있었습니다. 다른 모델로 교체하면 필요한 인식 품질을 확보하기 어려워, 선정 모델을 유지하면서 연결 구조로 중단에 대응해야 했습니다.

구현

• 반복되는 중단 주기를 기준으로 세션 전환 시점 결정: 중단 이후 재연결하면 연결을 복구하는 동안 입력 공백이 생길 수 있다고 판단했습니다. 약 1분마다 문제가 반복되는 특성을 바탕으로, 기존 세션이 약 50초 진행됐을 때 다음 세션을 미리 열어 음성을 전달하도록 구성했습니다.
• 두 세션에 동일한 음성을 전달해 전환 경계의 누락 방지: 새 세션을 시작한 뒤에도 기존 세션의 음성 입력을 바로 끊지 않고, 약 5초 동안 양쪽에 같은 음성을 전달했습니다. 세션 교체 시점에 걸친 발화가 사라지지 않도록 중복을 허용하더라도 누락을 막는 것을 우선했습니다.
• 겹쳐 생성된 전사를 정리해 연속된 문장으로 전달: 중첩 구간에서 두 세션이 생성한 전사 결과는 빠른 LLM으로 중복 구절을 정리했습니다. 세션별 출력을 그대로 노출하지 않고 이어지는 문장으로 전달해, 상담 화면에서 연결 교체가 드러나지 않도록 구성했습니다.

결과

다른 모델로 교체하지 않고도 선정 모델의 인식 품질과 번역 기능을 유지하면서 상담 전사를 이어갈 수 있었습니다. 상담 사용자는 세션 전환을 의식하지 않고 사용할 수 있었으며, 대신 중첩 구간의 음성 처리와 LLM 후처리에 추가 비용이 발생하는 절충을 선택했습니다.

유사 응답 중단 보고

공통 개발 기준과 기능별 의존 구조

상황

coding agent의 제안을 이어 반영하면서 로직 위치와 logging·local import가 흩어져 코드 읽기와 문제 추적이 어려웠습니다. 기능을 추가할 때마다 로직 배치와 계층 연결을 다시 판단해야 했습니다.

구현

반복되는 구조 판단은 템플릿의 기본값으로 제공하고, 제품별 정책과 예외는 기능 담당자가 결정하도록 나눴습니다. Router의 API 입출력, Service의 업무 처리, Validator의 검증, Repository의 SQL 실행을 분리하고 DI로 연결했습니다.

Generic Repository로 공통 CRUD를 제공하고 ORM entity와 raw query 결과의 경계는 typed DTO로 분리했습니다. 공통 응답·오류 계약과 모델·조회 규칙을 문서화하고, 계층형 Agent context·ADR·convention·runbook·반복 작업 skill로 필요한 기준을 찾도록 했습니다.

일반 기능에는 MVC를 유지하고, 도구 확장이 잦은 AI Agent에는 핵심 로직이 port를 호출하고 외부 도구·provider 구현을 adapter에 두는 구조를 안내했습니다. 공통 API·데이터 접근 계약은 유지하면서 도구 구현의 변경과 핵심 로직의 의존 방향을 구분하기 위한 선택입니다. 개발팀 회의에서 구조를 검토하고 받은 피드백을 구현에 반영했습니다.

결과

담당자가 공통 패턴과 문서를 기준으로 기능을 구현하고, 예측 가능한 로직 위치에서 문제 영역을 찾아 수정할 수 있게 됐습니다. 백엔드 담당자가 구현 과정에 계속 개입하던 방식은 담당자의 구현 결과를 피드백하고 배포를 지원하는 형태로 바뀌었습니다.

1. 선언적 트랜잭션 처리와 비동기 세션 수명주기 관리

상황

비개발자가 coding agent로 기능을 구현하는 과정에서 트랜잭션 처리 실수가 반복됐습니다. 세션을 종료하지 않거나 트랜잭션 범위를 과도하게 잡아 DB 연결을 오래 점유하는 문제가 발생했습니다. 기능마다 세션 생성·반환과 예외 처리를 직접 작성하는 방식으로는 일관된 처리를 유지하기 어려웠습니다.

구현

메서드에 데코레이터를 선언하면 공통 계층이 세션과 트랜잭션의 수명주기를 관리하도록 구현했습니다. 트랜잭션 경계를 Service 메서드에서 명시하고, Repository는 데이터 접근과 SQL 실행·flush에 집중하도록 책임을 분리했습니다.

• 세션 전달을 공통화했습니다. ContextVar에 현재 세션과 트랜잭션 상태를 보관하고 SessionProxy를 통해 접근하도록 구성해, 여러 계층에 세션 인자를 반복 전달하는 코드를 줄였습니다.
• 비동기 작업 간 세션 공유를 제한했습니다. 자식 task에 컨텍스트가 전파되더라도 같은 세션을 함께 사용하지 않도록 소유 task를 검사했습니다.
• 중첩 호출의 트랜잭션 정책을 구분했습니다. 기존 트랜잭션 참여, 별도 세션·트랜잭션 실행, SAVEPOINT 사용을 구분해 호출 관계에 맞는 처리 범위를 선택할 수 있도록 했습니다.
• 종료 처리를 공통 계층으로 모았습니다. 정상 완료·예외·취소 경로에서 commit·rollback, 세션 종료와 컨텍스트 복원을 처리하도록 구성했습니다.

결과

기능별로 반복하던 세션·트랜잭션 처리를 데코레이터 기반의 공통 처리로 전환했습니다. 구현자는 메서드에서 트랜잭션 정책을 선언하고 비즈니스 로직을 작성하며, 세션 반환과 예외 처리는 공통 계층에서 관리하도록 개발 방식을 정리했습니다. 코드 리뷰에서도 트랜잭션 경계와 비동기 세션 사용 규칙을 같은 기준으로 확인할 수 있도록 했습니다.

2. 환경별 인프라 분리와 변경 검증

상황

기존 운영 자원을 Terraform으로 관리하면서 의도하지 않은 자원 교체·삭제를 방지해야 했습니다. 여러 제품의 실행 환경과 공통 이미지 저장소를 함께 관리하고 있었으며, 인프라 설정과 서비스 배포 설정의 관리 주체도 구분할 필요가 있었습니다.

구현

제품군·환경별로 Terraform root와 remote state를 분리하고, 변경 계획과 실제 자원을 대조하는 검증 절차를 적용했습니다. 저장소는 통합해 관리하되 변경의 적용 범위는 환경별로 구분했습니다.

• 의도하지 않은 자원 교체·삭제를 적용 전에 확인했습니다. 변경 전 state snapshot을 보존하고, terraform plan과 실제 Azure 자원 구성을 대조해 예상하지 않은 삭제·재생성이 포함되면 적용을 중단했습니다.
• 인프라와 서비스 배포의 관리 책임을 분리했습니다. App Service 이미지 태그처럼 CD가 변경하는 값은 Terraform 관리와 충돌하지 않도록 구분하고, 기존 자원을 편입할 때 logging 설정도 코드에 보존했습니다.
• 배포 이후 실행 상태까지 확인했습니다. 환경에 맞는 배포 절차를 유지하고 health check·실행 식별자·로그를 통해 변경 결과를 확인했습니다.

결과

변경 계획에서 발견한 DB 교체와 logging 설정 제거가 실제 환경에 적용되지 않도록 처리했습니다. 제품·환경별 변경 범위와 배포 설정의 관리 책임을 구분해, 인프라 변경 시 확인할 대상과 적용 기준을 명확히 했습니다.

3. 운영 관리 효율화

상황

소수의 엔지니어가 사내 여러 서비스를 운영하고 있어, 서비스별 인프라를 개별적으로 관리하는 데 많은 리소스가 들었습니다. 인프라 작업의 처리 권한과 관리 책임을 한곳으로 모으고, 구성·변경·점검 절차를 일원화해 제한된 인력으로 운영할 수 있는 체계가 필요했습니다.

구현

인프라 변경을 공통 관리 체계로 모으고, 운영 상태 확인과 실행 자원 관리를 정비했습니다.

• 구성과 변경 관리를 일원화했습니다. Terraform으로 관리하는 제품별 인프라 구성과 Git 변경 이력을 하나의 저장소에서 확인하도록 정리했습니다. 인프라 작업은 공통 관리 절차로 모으되, 변경 적용 범위는 제품·환경별로 분리했습니다.
• 운영 상태를 확인하는 방식을 정리했습니다. App Service 진단 로그와 VM 컨테이너 로그를 환경별 Log Analytics로 수집하고, CPU·메모리·디스크·API health·5xx·DB 상태에 대한 알림 구성을 관리했습니다.
• 분산된 실행 자원을 통합했습니다. 서비스별 인스턴스 통합을 제안하고 적용된 구성을 운영해, 개별 인스턴스 유지에 드는 비용을 줄였습니다.

결과

서비스 인스턴스 통합으로 월 서버 비용 약 30–40% 절감에 기여했습니다. 인프라 작업의 관리 책임과 변경 절차를 일원화하고, 여러 서비스의 구성을 한곳에서 확인할 수 있도록 정리했습니다. 이를 통해 공통 설정 변경이나 보안 이슈 발생 시 제품별 영향을 점검하고 환경별로 대응할 수 있는 운영 기반을 마련했습니다.

1. 전사 AI 협업 체계 설계

상황

개별 구성원의 AI 활용은 늘었지만, 회사 차원에서는 업무 간 조율과 관리 부담이 커지고 있었습니다. 제품이 빠르게 늘어나는 가운데 업무 정보와 작업 결과가 산발적으로 쌓였고, 회의와 후속 소통으로 맥락을 다시 전달하거나 서로 맞지 않는 결과물을 조정하는 데 많은 리소스가 들었습니다.

개발 업무의 정보와 처리 흐름을 연결하는 것부터 시작해, 이를 전사 업무로 확장하기 위해 Mediness를 기획했습니다. 구성원과 AI가 공통된 업무 맥락과 기준을 바탕으로 협업할 수 있는 구조가 필요했습니다.

구현

회의·문서·의사결정·업무를 연결하고, AI의 실행 지원과 사람의 판단을 구분하는 협업 구조를 함께 설계했습니다.

• 업무 맥락을 연결했습니다. 회의 기록과 관련 문서, 의사결정, 실행 요청, 담당자와 후속 작업을 연결해 업무의 배경과 진행 상태를 함께 확인하도록 설계했습니다.
• AI가 업무 구체화를 지원하도록 구성했습니다. 요청과 회의 내용을 관련 맥락과 함께 활용해 실행안을 정리하고, 담당자와 수신자를 추천하는 흐름을 설계했습니다.
• 사람의 확정을 실행 기준으로 두었습니다. 우선순위·의사결정·업무 배정·승인은 사람이 확정하고, 확정된 내용을 후속 작업으로 연결하도록 책임 경계를 정했습니다.
• 개발 업무에서 전사 업무로 범위를 확장했습니다. 제품별 명세·작업·QA·릴리스 관리에서 출발한 구조를 회의·요청·승인 등 사내 공통 업무에도 적용할 수 있도록 구현 담당자들과 요구사항과 처리 흐름을 구체화했습니다.

결과

개인별로 분산된 AI 활용을 공통 업무 맥락과 승인 절차에 연결하는 전사 AX 구조를 마련했습니다. 개발 업무에서 운영하던 결정–작업–검증 흐름을 바탕으로, 회사 업무에서도 AI의 제안과 사람의 확정이 후속 실행으로 이어지도록 설계했습니다.

2. 의사결정부터 릴리스까지 연결한 개발 업무 관리

상황

현재 요구·진행 상태·과거에 선택한 기준을 확인하려면 담당자에게 다시 물어야 했고, 담당자가 바뀌면 구두 인수인계로 제품 맥락을 다시 구성해야 했습니다.

구현

제품별 결정·명세·작업·QA 승인·릴리스 근거를 연결하는 개발 업무 운영을 리드했습니다. 작업에서 결정 이유와 구현 범위를 함께 확인하고, 버전에서 포함된 작업과 검증 근거를 따라갈 수 있도록 관리했습니다.

• 작업과 책임을 연결했습니다. 작업 단위에 결정 이유와 개발 명세를 연결하고, 백엔드·프론트엔드·QA·운영 담당 영역을 구분했습니다. 설계 기록·운영 지침·coding agent 작업 문서도 함께 축적해 사람과 AI가 같은 제품 맥락을 읽도록 했습니다.
• 검증과 버전 확정을 연결했습니다. 버전별 기준 문서에 포함 작업을 묶고 명세와 담당 작업을 대조했습니다. QA 확인·승인과 릴리스 근거를 출시 조건으로 두고, 실제 완료 시점에 버전을 확정해 릴리스 노트를 자동 생성했습니다.
• 누적된 판단을 후속 업무에 활용했습니다. 일정·차단 이슈·릴리스 상태를 갱신하고, 유사 기능과 후속 변경에서 기존 결정·명세·구현 기준을 재사용하도록 운영했습니다.

결과

버전마다 포함된 작업과 결정·명세·QA 승인을 기록에서 확인할 수 있게 됐습니다. 현재 요구와 과거 판단을 다시 설명하는 반복 조율을 줄였고, 담당자가 바뀌어도 누적된 기록으로 업무를 이어가도록 했습니다. 기존 판단과 구현 기준의 재사용으로 초기 설계와 맥락 복원 부담을 낮추고 개발 소요 시간 단축에 기여했습니다.

3. 요구사항 기반 QA 판정 체계

상황

테스트 실행이나 API 성공 응답만으로는 요구사항 충족 여부를 판단하기 어려웠습니다. DB 저장 상태·사용량 정책·권한·AI 품질은 실행 결과와 별도의 근거가 필요했습니다.

구현

요구사항별 정책·필요 근거·판정 조건·후속 처리를 묶은 공통 QA 판정 기준을 설계·문서화했습니다. QA 팀의 실무 검토를 받아 기준을 정리하고, QA 실행 파이프라인의 테스트 케이스 확정 전에 적용하도록 연결을 설계했습니다.

• 실행 전에 필요한 근거를 정했습니다. 요구사항을 테스트 절차가 아니라 제품이 보장해야 하는 정책으로 정의했습니다. 정책 출처와 함께 화면·DB·로그·네트워크·AI 품질 중 판정에 필요한 근거와 조건을 정했습니다. DB 저장·사용량 차감·권한·부수 효과는 화면만으로 확정하지 않고 관련 근거를 대조하도록 했습니다.
• AI 품질을 별도로 판정했습니다. 응답 생성 여부와 품질 충족을 구분하고, 샘플·항목별 평가 기준을 사람의 검토로 교정하도록 했습니다. LLM judge 점수만으로 승인하지 않도록 기준을 두었습니다.
• 결함과 근거 부족의 후속 처리를 구분했습니다. 확인된 정책 위반은 수정 대상으로, 필요한 근거가 없는 항목은 추가 검증 대상으로 분리했습니다.

DB·사용량·권한·부수 효과와 이미 회귀한 항목은 API 계약·백엔드 통합·브라우저 smoke·DB 정합성·AI 품질 평가로 자동화할 기준을 정했습니다. 릴리스 전 보고에는 검증된 요구사항, 결함과 조치 상태, 남은 근거 부족, 자동화·수동 유지 항목을 남기도록 했습니다. 실행을 담당하는 QA 플러그인의 구현·유지는 QA 담당자가 맡았으며, AI QA 에이전트 팀 운영에는 함께 참여했습니다.

결과

실행 성공과 요구사항 충족을 구분하는 공통 판정 기준을 마련했습니다. 근거가 부족한 항목을 통과로 처리하지 않고, 수정할 결함과 추가로 검증할 대상을 나눠 사람의 출시 판단에 전달하도록 정리했습니다.