Environment
이 데이터를 참조하는 하위 메뉴 21개 — 대시보드, 기성관리, 주간·월간 공정보고, 공정표관리, 자원투입현황 등
Controller → Component → Service → Mapper 레이어 아키텍처 기반 개발
- 액티비티 — 공정표상의 작업 단위 (예: 3층 슬래브 타설)
- CBS — 공사비 내역 항목. 그 작업이 실제로 쓴 자재·인력·장비
- 보할 — 배분율. 한 작업이 여러 날에 걸칠 때 오늘 몫이 몇 % 인지
- 공정률 — 공사가 몇 % 진행됐는지 / 기성 — 진행한 만큼 청구하는 공사대금
프로젝트 설명
건설 현장은 매일 “오늘 어느 공정을 얼마나 했는지”를 기록합니다. 이 기록이 공정률이 되고, 공정률이 곧 발주처에 청구할 공사대금(기성)의 근거가 됩니다. 작업일지는 그 기록을 받는 화면입니다.
그래서 이 메뉴의 수량 하나를 잘못 잡으면 그 오차가 공정보고·자원투입현황·대시보드·기성 청구까지 그대로 번집니다. 작업일지를 참조하는 하위 메뉴가 21개입니다. GaiA-CaiRos 메뉴 가운데 가장 복잡하고, 가장 중요한 메뉴이며, 업무 분석부터 개발, 운영까지 전 과정을 담당했습니다.
작업일지는 “오늘 무엇을 얼마나 했는가”를 적는 문서지만, 그 숫자가 곧 공정률이고 기성 근거입니다. 화면을 만들기 전에 현업 담당자와 실제 작성 절차를 따라가며 무엇이 계획이고 무엇이 실적인지, 실적이 언제 확정되는지부터 합의했습니다.
계약번호와 작업일지 ID 를 공통 키로 갖는 마스터 아래에 액티비티·내역수량·자원·사진을 배치했습니다. 자원 실적이 420만 행까지 쌓이는 구조라, 조회 경로마다 계약 단위로 먼저 좁히는 것을 설계 원칙으로 잡았습니다. 하위 메뉴들이 같은 실적 데이터를 저마다 다시 집계하는 구조라, 성능과 정합성 문제는 모두 이 집계 경로에서 발생했습니다.
.png)
개발 항목
이 메뉴의 핵심 난이도는 같은 수량이 세 군데(액티비티 보할 · CBS 내역 · 자원 실적)에 동시에 존재하고 서로를 파생시킨다는 점이었습니다. 하나를 고치면 나머지 둘이 따라와야 하고, 따라오지 않으면 그 오차가 하위 메뉴 집계로 그대로 번집니다. 아래 항목 대부분이 이 연쇄를 어긋나지 않게 만드는 작업입니다.
- 액티비티 보할 로직과 수량 산정 방식 개선
- 보할 ↔ CBS 수량 양방향 재계산, 보할 기반 자원 금일수량 계산
- 액티비티 추가 시 연관 CBS 항목 자동 추가
- 실적 산정 기준 개선(전자결재 의존 제거) 및 공정률 실시간 재계산
- 실적 100% 도달 시 액티비티 종료 자동 처리
- 작업일지 개요·액티비티(CBS) 화면 리뉴얼, CBS/자원 조회·저장
- 작업일지 자동 생성 배치 — 공휴일 제외, 작성자·날씨 자동 설정
- 프리마베라(Primavera) 공정 데이터 연계 — 공정표 액티비티를 원천으로 삼아 임의 항목 생성 차단
- 자원 조회 방식 개선(전기·통신·소방 내역서 항목 대응)
- UbiReport 를 대체하는 자체 PDF 리포트 서비스 개발
- 모바일 작업일지 화면 리뉴얼
성과
현업 성과 — 사람이 하던 일이 어떻게 바뀌었나
도입 전 현장은 매일 엑셀에 작업 내역을 적고, 수식을 걸어 공정률을 직접 계산하고, 그 작업이 공정표상 어느 액티비티에 붙는지 일일이 대조했습니다. 아래는 그 작업이 어떻게 바뀌었는지입니다. (운영 현장 5곳 · 하루 5건 작성 기준)
- 작성 시간 40분 → 10분 (75% 단축) — 공정률 자동 계산, 연관 CBS 항목 자동 매핑으로 현장은 실제 작업 내용만 입력
5개 현장이 매일 작성하므로 월 약 50시간의 현장 작업 시간이 회수됨 (5건 × 30분 × 20영업일 환산) - 이중 입력 제거 — 한 번 입력하면 21개 메뉴가 채워짐 — 같은 수량을 주간·월간 공정보고, 기성 청구, 대시보드에 문서마다 다시 옮겨 적던 작업이 사라짐. 작업일지가 이 21개 메뉴의 유일한 원천이 되어 문서 간 숫자가 어긋날 여지 자체를 제거
- 계산 기준 통일 — 엑셀은 현장마다 수식이 조금씩 달라 본사 취합 시 숫자가 맞지 않았음. 계산을 시스템이 맡으면서 모든 현장이 같은 기준으로 산출
- 수기 작성 → 자동 생성 — 매일 새로 만들어야 하는 문서를 공휴일 제외 날짜로 자동 생성하고 작성자·날씨를 미리 채움
- 현장에서 바로 입력 (모바일) — 사무실로 돌아와 다시 입력하던 것을 작업 직후 현장에서 처리. 기억에 의존해 옮겨 적으며 생기던 오차도 함께 감소
- 공정률 반영 며칠 → 입력 즉시 — 실적 확정이 전자결재 승인에 묶여 공정률이 며칠씩 밀렸고, 현장은 화면을 믿지 못해 엑셀을 따로 관리했음. 결재를 확정 절차로만 남기고 실적은 입력 즉시 반영하도록 기준을 바꿔 현장이 화면 숫자를 근거로 쓰기 시작
- 리포트 출력 장애 월 30건 → 0건 — 외부 솔루션(UbiReport) 서버 다운과 긴 로딩으로 현장이 출력 자체를 포기하던 상황. 자체 PDF 서비스로 전환해 외부 서버 장애와 무관하게 출력되며, 라이선스 비용도 함께 제거
시스템 성과 — 그 규모를 감당하게 만든 것
- 420만 행 규모에서 집계 998ms → 115ms (약 8.7배) — “계약으로 먼저 좁힌다”를 이후 모든 대량 집계 화면의 점검 기준으로 적용
- 공정표와 실적의 기준 일치 — 프리마베라 공정표의 액티비티를 원천으로 삼아 공정표에 없는 작업이 실적으로 생길 수 없게 차단. 본사 공정표와 현장 실적이 같은 기준 위에서 관리됨
- 데이터 정합성 결함 차단 — 액티비티를 하나씩 지우면 연결된 작업내역이 남아 수량이 어긋나던 문제 해소. 원인 유형(“일괄 처리 경로만 고치고 개별 처리 경로를 빠뜨림”)을 팀 점검 항목으로 등록해 다른 메뉴에서의 재발까지 차단
문제 해결
성능목록 조회 2.1초 지연
cw_daily_report_resource 에 cntrct_no 인덱스가 없었고, 목록 쿼리의 집계 CTE 가 계약 필터 없이 전체를 집계해 Parallel Seq Scan 으로 떨어짐정합성액티비티를 지웠는데 작업내역이 되살아남
업무 기준공정률이 며칠씩 밀려 현장이 화면 숫자를 믿지 않음
Environment
공공가이아(PGaiA) — 결재 연동
cw_daily_report_qdb.work_qty)- 기성 — 공사가 진행된 만큼 나눠 청구하는 공사대금 (1차·2차… 회차로 청구)
- 기성내역서 — 이번 회차에 무엇을 얼마나 해서 얼마를 청구하는지 적은 문서
- 원가계산서 — 그 금액이 어떻게 산출됐는지 근거를 푼 문서
- 선급금 · 공제금 — 미리 받은 돈과 이번 청구에서 빼야 할 돈
프로젝트 설명
건설은 공사가 다 끝난 뒤 대금을 한 번에 받지 않습니다. “이번 달까지 30% 했으니 그만큼 주세요” 하고 진행한 만큼 나눠 청구합니다. 이것을 기성이라 하고, 그 청구를 만드는 화면이 기성관리입니다. 회차(1차·2차…)마다 청구서를 만들어 발주처 결재를 받습니다.
이 업무의 특징은 카이로스 혼자 끝낼 수 없다는 점입니다. 얼마나 했는지(실적)는 작업일지에서 올라오고, 그게 얼마인지(금액) 계산한 내역서와 원가계산서는 외부 시스템인 유레카가 만듭니다. 카이로스는 그 사이에서 회차를 관리하고 받아온 내역을 결재에 올려 확정합니다. 그래서 외부 시스템이 응답하지 않을 때 업무를 어떻게 지킬 것인가가 이 메뉴의 핵심 난이도였습니다.
기성은 카이로스 혼자 끝낼 수 없는 업무입니다. 회차를 열고 → 유레카에 내역서를 만들어 달라고 요청하고 → 유레카가 작성을 끝내면 그 결과를 받아와 → 결재에 올려 확정하는 왕복 구조입니다.
CAEU0013 registerPrgpymntDtls — 해당 회차의 기성내역서를 작성해 달라고 유레카에 요청CAEU0014 retrievePrgpymntDtls — 유레카가 작성한 기성내역서와 원가계산서를 받아 화면·DB 에 반영CAEU0001 updatePrgpymntAprv 로 유레카에 통보해 양쪽 상태를 맞춘다CAEU0009 deletePrgpymnt — 기성을 지우면 유레카 쪽 내역서도 함께 정리개발 항목
성과
- 연동 실패가 업무 저장을 되돌리지 않게 됨 — 외부 송신을 커밋 이후 실행으로 옮겨, 유레카가 응답하지 않아도 기성 저장은 유지
- 모든 기성 송신이 이력에 남음 — 요청·응답·성공여부가 자동 적재되어 실패한 건만 골라 재전송할 수 있게 됨
- 운영 기성·계약내역서 화면 정상 오픈 — 환경별 도메인 설정을 4종(local·dev·test·prod)으로 정리해 이후 변경은 프로퍼티만 수정
- UbiReport 라이선스 의존 제거 — 기성 리포트를 자체 PDF 서비스로 전환하고 다건 재생성에 실시간 완료 알림(SSE) 적용
문제 해결
운영 장애운영에서 기성·계약내역서 유레카 화면이 열리지 않음
eureca.contractListViewDomain·eureca.paymentListViewDomain 에 API 도메인 값이 들어가 있어, 화면 요청이 화면을 서비스하지 않는 주소로 나갔음구조연동 실패가 업무 저장을 되돌리는 문제
발견 · 기록연동 이력에서 계약 삭제와 기성 삭제를 구분할 수 없다
CAEU0009 로 남은 건이 계약 삭제인지 기성 삭제인지 알 수 없음. 장애 추적 시 어느 업무에서 나간 요청인지 특정이 안 됨deleteCnstwk)와 기성 삭제(deletePrgpymnt)가 같은 인터페이스 식별값을 쓰고 있었음Environment
- 변경계약 — 공사 중 금액·기간이 바뀌면 원계약을 고치지 않고 차수를 더해 관리한다
- 도급사 — 발주처와 직접 계약한 시공사 / 하도급 — 도급사가 다시 맡긴 협력업체
- 유레카 · PAD · PNS — 계약정보를 함께 써야 하는 사내·외부 시스템 3곳
프로젝트 설명
계약은 모든 업무의 시작점입니다. 계약이 등록돼야 그 계약에 딸린 작업일지·기성·공정보고가 생깁니다. 그리고 계약정보는 우리만 쓰는 게 아니라 회사 안팎의 다른 시스템 3곳도 같이 써야 합니다. 그래서 계약을 저장하면 그 정보가 세 시스템으로 함께 나갑니다.
문제는 세 시스템이 같은 계약정보를 서로 다른 규격으로 요구했다는 점이었습니다. 보낼 값의 정의를 한 곳에 모아 통일하는 것이 이 작업의 핵심이었습니다.
계약 화면에서 저장 한 번을 누르면 세 시스템으로 요청이 나갑니다. 그런데 세 시스템이 요구하는 항목 이름·일시 형식·필수값·도급사 처리 방식이 모두 달랐습니다. 그래서 메뉴마다 각 시스템용 요청 값을 따로 만들고 있었고, 계약 항목이 하나 늘면 세 곳을 각각 고쳐야 했습니다. 한 곳을 빠뜨리면 그 시스템만 조용히 옛 값을 받았습니다.
- 같은 계약정보인데 시스템별로 요청 값을 만드는 코드가 따로 있었다
- 항목이 겹치는데도 이름과 일시 형식이 서로 달라, 어느 쪽이 정본인지 코드만 봐서는 알 수 없었다
- 도급사를 몇 건 보내는지, 어떤 도급사를 보내는지 기준이 흐렸다
- PAD 로 나가는 요청이 아이큐브와 사실상 같은 자료인데도 별도 규격으로 관리됐다
- 보낼 값의 정의를
ContractSyncData한 곳에 모았다 — 계약·공사·프로젝트 원본을 담아두고, 각 시스템이 요구하는 모양은 여기서 만들어 준다 - 일시 형식을 명세서가 요구하는
yyyyMMddHHmmss하나로 통일했다 - 도급사는 한 건만 보낸다로 규칙을 정했다 — 신규 등록은 그때 등록한 대표 도급사, 그 외에는 계약의 대표 도급사
- PAD 요청을 아이큐브와 같은 요청 자료로 통합했다
- 공사담당자 ID 기본값처럼 실행 환경(운영/개발)에 따라 달라지는 값은 값을 만드는 쪽이 아니라 보내는 쪽에서 정하도록 책임을 분리했다
송신 흐름
네 가지 업무 행위를 ContractSyncComponent.sync() 한 곳으로 모았습니다. 순서에 의존하는 부분이 하나 있어 그것만 명시적으로 다룹니다.
CREATE_CONTRACT 계약등록 · UPDATE_CONTRACT 계약수정 · CREATE_CHANGE 변경계약등록 · UPDATE_CHANGE 변경계약수정CAEU0007 registerCnstwk · CAEU0008 registerCntrct · CAEU0009 deleteCnstwk)개발 항목
CAPD0003 · CAPD0004)성과
- 계약 항목이 늘어도 고칠 곳이 한 군데 — 세 시스템으로 흩어져 있던 요청 값 정의를 한 곳으로 모아, 한쪽만 빠뜨려 옛 값이 나가는 누락이 재발하지 않는 구조로 전환
- 계약 저장 교착 재발 없음 — 외부 송신을 커밋 이후 실행으로 옮겨 “트랜잭션 안에서 외부 시스템을 호출하지 않는다”를 팀 규칙으로 문서화
- 필수값 누락 · 보증금 미입력 · PNS 등록 오류 해소 — 시스템별 필수값을 요청 생성 지점에서 함께 채우도록 정리
- 어느 시스템으로 무엇이 나가는지 코드만 보고 알 수 있게 됨 — 클래스명 · 설정 · 연동 이력의 시스템 이름을 일치시킴
문제 해결
구조이름과 실체가 다른 연동 — 아이큐브 이름으로 PNS 로 나가고 있었다
PnsClient 로 분리하고 전용 설정 파일(pns-*.properties)을 신설 / 같은 기준으로 연동 전수를 훑어, 수집처가 바뀐 CSI 사고사례 연동도 함께 정리장애계약 저장이 응답 없이 멈춤 (자기 교착)
연동 결함필수값 누락·예외 케이스로 전송이 실패하던 건
Environment
- 송신 창구 — 외부로 나가는 모든 요청이 반드시 지나가는 공통 통로
- 연동 이력 — 언제 · 어디로 · 무엇을 보냈고 상대가 뭐라 답했는지 남기는 기록
프로젝트 설명
카이로스는 혼자 돌아가는 시스템이 아닙니다. 계약·기성·실정보고·안전 데이터가 5개 외부 시스템과 수시로 오갑니다. 그런데 이 송신 코드가 메뉴마다 따로 흩어져 있었습니다.
그래서 생긴 문제가 이겁니다 — 어떤 건 보낸 기록이 남고 어떤 건 남지 않았습니다. 상대가 “못 받았다”고 하면 우리가 안 보낸 건지, 보냈는데 상대가 놓친 건지 확인할 방법이 없었습니다. 실패한 건만 골라 다시 보내는 것도 불가능했고요. 사람이 보지 않는 배치 송신일수록 누락이 많았습니다.
해결 방향은 “기록을 잘 남기자”가 아니라 “기록을 잊을 수 없게 만들자” 였습니다. 모든 송신이 공통 창구 한 곳을 반드시 지나가게 하고, 그 창구가 이력을 자동으로 남기게 했습니다. 개발자가 기억해서 붙이는 일이 아니라 구조상 빠질 수 없는 일로 바꾼 것입니다.
문제는 “연동이 안 된다”가 아니라 어떤 건 이력이 남고 어떤 건 남지 않는다는 것이었습니다. 장애가 나도 무엇을 보냈는지 확인할 방법이 없었습니다. 모든 송신을 공통 클라이언트 한 곳으로 통과시켜, 이력 적재를 잊을 수 없는 구조로 바꿨습니다. 업무 메뉴별로 흩어져 있던 외부 송신을 공통 창구 하나로 모아 요청·응답과 성공 여부가 이력에 자동으로 남고, 수신(IN) 방향도 같은 창구를 거치므로 한 테이블에서 양방향 이력을 추적할 수 있습니다.
SSO 로그인 — 무중단 전환
아이큐브 포털에서 CaiRos 로 넘어오는 로그인을 기존 TokenID 방식에서 JWT 로 옮기면서, 이미 로그인해 있는 사용자를 끊지 않는 것이 조건이었습니다. 둘 중 하나를 고르는 대신 순차 폴백으로 설계했습니다. JWT 를 먼저 시도하고 실패하면 기존 TokenID 경로로 폴백하므로, 포털 측 전환 시점과 무관하게 로그인이 유지됩니다.
개발 항목
성과
- 이력 적재를 잊을 수 없는 구조로 전환 — 모든 외부 송신이 공통 창구를 지나며 요청·응답·성공여부와 함께 자동으로 남고, 신규 연동은 창구 사용이 기본값이 됨
- 실패한 건만 골라 재전송 가능 — 장애 시 무엇을 보냈는지 확인할 수 없던 상태를 해소
- SSO 무중단 전환 — JWT 우선 검증 + 기존 TokenID 폴백으로 이미 로그인해 있는 사용자를 끊지 않고 이행
- 어느 시스템으로 무엇이 나가는지 코드만 보고 알 수 있게 됨 — 클래스명 · 설정 · 연동 이력의 시스템 이름을 일치시킴
문제 해결
구조이력이 남지 않는 송신 경로
구조이름과 실체가 다른 연동
프로젝트 설명
담당 선임과 리더가 연이어 퇴사하면서 시스템을 단기간에 인수받았습니다. 인수 문서가 충분하지 않아, 코드와 운영 이력을 역추적해 구조를 다시 정리하고 문서로 남기는 것부터 시작했습니다. 어느 서버에 무엇이 올라가 있는지, 장애가 나면 어느 로그를 먼저 보는지가 아무 데도 적혀 있지 않은 상태였습니다.
이후 개발과 함께 배포·서버 운영·장애 대응을 맡고 있습니다. 운영에서 만나는 문제는 개발과 성격이 다릅니다. 재현이 안 되고, 로그만 남아 있고, 사용자는 이미 불편을 겪은 뒤입니다. 그래서 증상을 덮지 않고 원인까지 내려가는 것과 같은 문제가 두 번 오지 않게 기록으로 남기는 것을 원칙으로 삼았습니다.
담당 업무
- Jenkins 배포 환경 설정 및 관리 — 다중 서버 대응 구성, 배포 스크립트 정비, dev 젠킨스 결함 개선
- Linux 서버 운영 — 운영 WAS 2대·NCP·개발·테스트 서버와 DB 3대 (총 8대)
- 서버 장애 원인 분석 및 대응 — 운영 서버 디스크 용량 문제 해소, 개발/운영 로그 관리
- 삭제 첨부파일 물리삭제 배치 개발 — 보관기간 경과분만 회수, 수동 실행 스크립트 병행
- DB Lock 발생 원인 분석 및 해결 / SQL 성능 이슈 대응 / 운영 데이터 오류 분석
- 고객·현업 요청사항 대응 / UbiReport 리포트·에이전트 서비스 운영
- 서버 인프라 구성도 — 어느 서버에 무엇이 올라가 있는지 문서화
- 장애 대응 절차 — 증상별 확인 순서와 로그 위치
- 배포 프로세스 — 브랜치 승격 규칙과 배포 스크립트
- 결함 이력 문서 체계 — 메뉴별로 원인과 재발 방지 기준을 누적
- SVN 소스의 Git 이관 및 형상관리 전환
- 데이터 접근 계층 JPA → MyBatis 전환 및 검증
문제 해결
구조데이터 접근 계층 이원화 — JPA 와 MyBatis 가 같은 테이블을 함께 쓰던 문제
rgst_dt · chg_dt · rgstr_id · chg_id)도 어느 경로로 저장했느냐에 따라 채워지기도 하고 비어 있기도 했음@PrePersist · @PreUpdate)에서 채우고 있었는데, 이 콜백은 JPA 를 통과할 때만 실행되므로 MyBatis 로 저장하면 호출조차 되지 않았음 / JPA 로 읽은 엔티티는 트랜잭션 동안 영속성 컨텍스트에 남는다. 그 사이 MyBatis 가 DB 를 직접 수정해도 JPA 는 알지 못하고, 커밋 시점의 변경 감지가 캐시에 있던 옛 값으로 UPDATE 를 다시 날려 방금 쓴 값을 덮었음 / 변경되지 않은 컬럼까지 UPDATE 문에 포함되는 것이 기본 동작이라 덮어쓰는 범위가 넓었음. @DynamicUpdate 는 문제가 드러난 6개 엔티티에만 개별로 붙어 있는 상태였음@Mapper 어노테이션 정리 ② Mapper 인터페이스·XML 네이밍 정규화 ③ mybatisSession 직접 호출을 Mapper 인터페이스로 전환 ④ JPA Repository 및 잔존 인프라 제거 / 감사 컬럼은 XML 에 명시적으로 기록하도록 옮겨 저장 경로와 무관하게 같은 값이 남게 함 / 엔티티는 JPA 어노테이션 없는 순수 POJO 로 정리하고 매핑은 XML 이 전담@Column 188, @Id 100, @Entity 58, @GeneratedValue 21, @PrePersist·@PreUpdate 9, @DynamicUpdate 6) / 저장 경로가 하나뿐이라 “어느 쪽으로 저장했는가”에 따라 결과가 달라지는 경우가 사라짐 / 신규 개발 기준을 문서로 고정 — 엔티티는 순수 POJO, 데이터 접근은 Mapper 인터페이스만, 감사 컬럼은 XML 에 명시어느 쪽으로 저장했느냐에 따라 결과가 달라지는 상태에서는 개별 증상을 하나씩 막아도 다음 증상이 다시 나옵니다. 저장 경로를 하나로 만들자 덮어쓰기와 감사 컬럼 누락이 함께 사라졌습니다.
장애계약 저장이 멈추고, 뒤따른 요청 8건이 연쇄로 매달림
pg_blocking_pids() 로 어느 세션이 어느 세션을 막고 있는지 뿌리까지 추적 / jstack 으로 애플리케이션 스레드가 어느 호출에서 멈춰 있는지 확인 / 잠금 보유자가 DB 대기가 아니라 idle in transaction 상태임을 확인교착의 원인은 외부 시스템이 느린 것이 아니라, 행을 잠근 채로 외부를 호출한 것이었습니다. 송신을 커밋 이후로 옮기자 잠금 구간과 외부 호출 구간이 겹치지 않게 되어 교착 조건 자체가 사라집니다.
운영 개선지운 첨부파일이 디스크에 계속 남아 용량을 잠식
지우기 전에 세 가지를 확인한다 — ① 업로드 폴더 안에 있는 파일인가(경로 이탈 방지) ② 아직 그 파일을 쓰고 있는 자료가 있는가 ③ 파일이 실제로 존재하는가
배치가 실패했을 때 운영자가 직접 돌릴 수 있는 수동 실행 스크립트(개발·운영 각각)와 관리 엔드포인트를 함께 만들었음
BATCH, 업무구분 「첨부파일 물리삭제 배치」) — 사람이 보지 않는 배치라 무엇을 몇 건 지웠는지가 유일한 단서이기 때문“되돌릴 수 없는 작업에는 되돌릴 수 있는 기간을 둔다”가 이 작업에서 얻은 기준
성능대시보드 관리기준 성과분석 조회가 수십 초
AS MATERIALIZED 로 선언해 한 번만 계산하고 재사용하도록 변경 / 왜 이 힌트가 필요한지를 쿼리 주석으로 남겨 나중에 무심코 제거되지 않게 함운영 데이터새로고침하면 상단 계약명이 “데이터 없음”
통화 녹취 솔루션을 제공하는 투티스에서 진행한 프로젝트입니다. 관리자 페이지 기능 개발과 고객사 기간계 시스템 연동을 담당했습니다.
Environment
주요 업무
- 관리자 페이지 기능 개발 — 메뉴 추가, 통계 화면, 이미지 조회 기능 구현
- 고객사 기간계 시스템과 RESTful API 연동 — POST/JSON 기반 연동 로직 다수 구현 및 응답 처리 체계화
- 서버 인프라 배포 — Tomcat 기반 서버 환경 구성 및 배포 프로세스 적용
- 데이터베이스 성능 최적화 — PostgreSQL·MyBatis 기존 쿼리 보수
성과
- 녹취 파일 청취 기능 추가 — 서버에 저장된 녹취 파일을 스트리밍 방식으로 제공해 관리자 페이지에서 직접 청취
- Embedded DB 도입 — 조회 테이블을 Embedded DB 로 구성해 코드 수정 없이 설정 파일만으로 컬럼 반영
- 사용자·관리자·운영자 매뉴얼 제작 및 교육 진행, 고객사 내 PostgreSQL 도입 성공
- 관리 효율성·유지보수 부담 개선에 기여하여 프로젝트 추가 계약 성사
화면
클라이언트 UI 전면 개편과 신규 기능 개발을 단독으로 진행했습니다. Angular·TypeScript 를 처음 다루는 환경이었고 팀 내에 도움을 줄 선임이 없었으나, 타 부서 선임의 피드백과 기존 코드 분석으로 기존 기능에 영향을 주지 않고 완료했습니다.
Environment
주요 업무
- 클라이언트 개발 — Angular·TypeScript 기반 UI 전면 개편
- 서버 API 구현 및 클라이언트 연동 — 데이터 조회용 서버 API 와 클라이언트 요청 로직 동시 개발
- 스마트폰 상태 정보 실시간 표시 화면 구성, MariaDB·MyBatis 기반 조회 쿼리 설계
- 이미지 포함 문자 전송 기능 구현
성과
- 완성도 높은 클라이언트 구축으로 사용자 경험(UX) 및 기능성 향상
- 영업 부서에서 본 솔루션으로 1년간 3건 계약 성사 — 제품의 실질적 가치 입증
- 실시간 상태 모니터링 도입으로 이상 발생 시 신속 대응 가능
화면 — 로그인 개편 전후
화면 — 콜 업무
화면 — 후처리 · 문자 업무
Environment
주요 업무
- 관리자 페이지 보안 강화 — 동일 ID 로그인 시 접속 중 IP 추적 및 자동 로그아웃 기능 구현
- 웹소켓 통신 고도화 — 클라이언트 → 서버 → 스마트폰 명령 전달 효율화
- 보안 인증서 적용 — HTTPS(SSL) 리눅스 서버 환경 구성 및 설정
- 데이터베이스 성능 최적화 — MariaDB·MyBatis 기존 쿼리 보수
성과
- 동일 ID 중복 로그인 차단 및 IP 추적으로 안전한 서비스 이용 환경 확보
- 기존 고객사 클라이언트와 연동하여 더 직관적이고 편리한 서비스 제공
화면
화면 이미지 자리images/p06-eduwill-01.png
화면 이미지 자리images/p06-eduwill-02.png
JB금융지주·롯데손해보험·신한캐피탈·집토스·예탁결제원의 RPA 과제를 기획·구축·개발·유지보수했습니다. 그중 롯데손해보험 2차 개발이 대표 과제입니다.
수행 과제
롯데손해보험 RPA 2차 개발
- 고객 인터뷰 및 프로세스 분석 — 업무 프로세스를 분석해 자동화 가능 여부를 검토하고 최적의 도입 방안 수립
- 프로세스 설계 및 기획 — 업무 흐름을 시각화해 적용 범위와 기대 효과를 정의, 봇의 단계별 동작 설계
- RPA 개발 및 운영 — UiPath 기반 VB.NET 자동화 로봇 개발, Orchestrator 연동으로 상태 모니터링·배포 자동화
- 관리자 교육 — 고객사가 직접 운영할 수 있도록 운영·개발 교육 진행
일정마감을 앞두고 계속 들어오는 추가 요구
언론 보도
