송영훈

PACS API 서버의 컨트롤러에는 비즈니스 로직, Sequelize ORM 쿼리, Oracle Raw SQL, DBMS 분기 로직이 한 파일 안에 섞여 있었습니다. 기능 수정 시 어느 쿼리가 어떤 DBMS에서 실행되는지 추적하기 어려웠고, DB 관련 버그를 고치려면 컨트롤러 전체를 건드려야 하는 구조였습니다.

PACS API 서버의 일부 핸들러는 하나의 요청에서 2개 이상의 테이블에 INSERT, UPDATE, DELETE를 수행했지만 트랜잭션이 없었습니다. 중간 단계에서 예외가 발생하면 앞선 테이블 변경만 남아 데이터 정합성이 깨질 수 있는 구조였습니다.

Windows PACS(FODICOM)와 웹 PACS(Cornerstone.js)는 렌더링 라이브러리가 달라 어노테이션 데이터 포맷이 완전히 상이했습니다. Windows는 '13^|2,2|2,4|...' 형태의 구분자 문자열, 웹은 { handles: { x, y } } JSON 구조로 저장됩니다. 두 제품을 동시에 쓰는 병원에서 의료진이 한쪽에서 그린 측정·마킹이 반대쪽에서 보이지 않아 양쪽에서 중복 작업을 해야 했습니다. 두 DB 스키마는 별도로 운영 중이었고, 라이브러리 교체 없이 호환을 만드는 방법이 있는지 자체가 불분명한 상태였습니다.

운영 중인 오더연동서비스를 NCP Kubernetes에서 회사 IaaS 서버로 이전해야 했습니다. 그런데 담당 개발자는 이미 퇴사한 상태였고, 소스코드 레포에는 버전별 폴더가 3개 있었는데 어느 것이 실제 운영 중인지 명세가 전혀 없었습니다. 테스트 명세 없음, 담당자 없음, 문서 없음 — 세 가지가 동시에 없는 상태에서 운영 중단 없이 이전을 완료해야 했습니다.

별도 인프라 담당자 없이 개발과 서버 운영을 병행하는 환경이었습니다. 서비스 이전 직후 쿼리 조회 속도가 기존 대비 현저히 느려지는 문제가 발생했고, GitLab CI를 IaaS에 연결하려면 내부망 포트를 외부에 노출하는 포트포워딩이 필요한 상황이었습니다. 간편한 방법이 있었지만 보안 문제가 명확했고, 그 판단과 대안 설득까지 직접 해야 했습니다.

PACS 웹 뷰어는 CT/MRI 검사 로딩 시 수백~수천 장의 DICOM 슬라이스 이미지를 병렬로 요청합니다. 기존 백엔드는 각 이미지 파일을 읽을 때마다 스토리지 장비 정보(ADVSTORAGEMGRTAB)를 DB에서 조회했고, CT 3,000장 기준 동일한 SELECT 쿼리가 3,000번 반복 실행되는 구조였습니다. 이로 인해 대용량 검사 조회 시 DB 커넥션 풀 고갈과 대기 시간 누적 위험이 있었습니다.

의료진이 검사 1건에 포함된 모든 DICOM 이미지(.dcm)를 한 번에 다운로드하는 기능이 필요했습니다. 초기 구현은 서버가 zip을 모두 만든 뒤 blob으로 응답하는 방식이었는데, 검사 1건에 이미지가 수백~수천 장에 달하다 보니 서버 처리 시간 동안 UI가 완전히 블로킹되는 문제가 있었습니다. 의료진이 다운로드 버튼을 누른 뒤 다른 조작을 전혀 할 수 없는 상태였습니다.

PACS 백엔드는 Node.js(Koa)가 요청을 받고, DICOM 디코딩·JPG 변환 같은 무거운 이미지 연산은 Python FastAPI 서버에 위임하는 구조였습니다. 평소 수십 장 이미지는 문제가 없었지만, 1,000~3,000장 규모의 검사 로딩이나 일괄 다운로드에서는 처음엔 빠르다가 후반부로 갈수록 응답이 느려지고 EADDRINUSE 또는 소켓 연결 실패가 간헐적으로 발생했습니다.

PACS 워크리스트 화면은 서버에서 받아오는 검사 목록 데이터를 Redux Toolkit의 createAsyncThunk와 reducer로 직접 관리하고 있었습니다. fetch, loading, error, page 상태를 모두 수동으로 다뤄야 해 보일러플레이트가 많았고, 컬럼 정렬도 현재 화면에 로드된 일부 데이터만 클라이언트에서 정렬해 전체 데이터셋 기준 결과와 달라지는 문제가 있었습니다.

PACS 뷰어는 Windows Server와 Electron GUI 앱을 전제로 배포되던 제품이었습니다. 해외 사이트에서 Linux 서버 배포 요구가 들어왔지만, 기존 구조는 Electron 실행 방식과 Windows 환경에 강하게 묶여 있었고 DICOM 처리 바이너리 의존성까지 함께 고려해야 했습니다.

20개 이상 병의원 고객사의 기본 정보, 설치 제품, 배포 상태, 지원 이력을 체계적으로 관리하는 사내 시스템이 없었습니다. 담당자별 스프레드시트와 개인 기록에 의존해 고객·제품·배포 이력이 분산되는 상황이었습니다.

현장 배포 후 일부 API가 동작하지 않는 문제가 발생했지만, 기존 로그는 Unix 마이크로초 타임스탬프, HTTP 요청, DB 쿼리, 에러가 한 파일에 섞여 있었습니다. 에러 스택도 남지 않아 로그만으로 장애 원인을 추적하기 어려운 상태였습니다.

LLM과 나눈 대화에서 커리어·기술 회고 소재가 계속 쌓였지만, 원문 저장과 요약, 위키 문서화 과정을 매번 수동으로 처리해야 했습니다. 개인 지식관리 흐름에 자동 인제스트 파이프라인이 필요했습니다.

개인 학습, 커리어 문서 정리, 일정·작업 자동화를 지속적으로 실험하기 위해 단발성 API 호출이 아니라 실제 생활과 개발 흐름에 붙는 로컬 AI 에이전트 운영 환경이 필요했습니다.

숙소 예약 플랫폼 클론 프로젝트 초기 인증 구조는 JWT와 사용자 정보를 localStorage에 저장하고, 요청 userId를 클라이언트가 직접 보내는 방식이었습니다. userId 조작으로 타인 정보가 조회되는 IDOR 취약점과 XSS 시 토큰 탈취 위험이 있었습니다.