2023.06월 회고

# CDW, PMS 연동

이번 라벨링 도구 배포의 핵심은 의료 플랫폼내에서 구축한 여러 서비스들을 하나로 동작하게끔 구현하는것인데,

먼저 데이터가 적재된 CDW와 데이터에 라벨을 마킹하기위한 위한 라벨링도구, 데이터를 분석하기 위한 WIDE를 통합해서 전체 프로세스가 서로 유기적으로 동작하게끔 구현하는것이 목표 였다.

지금까지는 라벨링 도구내에서 Frontend 파트와 협의의 통한 POC level의 구현이라, 별다른 큰 이슈는 없었고 소통도 수월했지만, CDW, PMS측과 함께 개발을 진행하면서 

조금 더 꼼꼼한 커뮤니케이션이 필요했다.

 

→ 아쉬웠던 점

사실, 전체 개발 볼륨을 지금 생각해보면, 지금 일정보다 조금 더 빠르게 완료할 수 있었던 부분이 있지 않을까 생각한다.

물론, CDW 및 PMS에서 작업결과를 주고받으며 진행해야했기 때문에 지연된 부분이 있었지만, 분명 내부적으로도 빠르게 풀어낼 수 있는 몇몇 순간들이 있었기때문에, 어떤 부분이 문제였는지 고민해보려한다.

 

첫째. CDW 및 PMS에서 전달해준 API들의 용도와 호출 및 응답값의 용도를 파악하고 어떤 순서로 호출해서 원하는 값을 얻을지에 대해 정리하는데 많은 시간이 소요되었다.

처음부터 전달받은 API들의 목적과 파라미터에 대해서 좀 더 구체적으로 집요하게 물어보고 이해했어야 했는데, 약간의 설명을 듣고 확실히 이해하지 못한 상태에서 쓸데없이 혼자 추리하는데 많은 시간을 허비했다.

이 부분만 빨리 이해하고 넘어갔어도, 작업 결과를 훨씬 더 빨리 확인할 수 있지 않았을까 한다.

둘째. CDW 및 PMS쪽에서 제공해준 API를 적용하고 테스트하는데 있어, 물리적인 작업 소요시간이 오래걸렸다.

PMS로부터 전달받은 dicom내 이미지 URL을 어떠한 방식으로 frontend에 전달할지에 대해, 어떻게 해야 빠르게 화면에 바인딩할 수 있을지에 대해 답이 떠오르지 않았다.

이미지 단위로 서버내에서 다운로드URL 호출 후 http response형태로 전달하면 해결될 문제였는데, byte로 decoding후 전달하다, byte가 너무 커 timeout되는 문제 등 별 삽질들이 있었고, 시행착오 끝에, 정상적으로 전달할 수 있었다.

PMS에서 제공하는 데이터의 URL은 외부에서 바인딩이 불가하기때문에, 서버내에서 다운받아 response 할 수 밖에없었지만, 대개의 경우에는 다운로드 URL 아닌, 이미지 자체 URL을 바로 전달할 수 있을것.

아무쪼록 다음에는, 질문을 부끄러워 말고, 집요하게 내용을 이해하고 문제를 빠르고 정확하게 정의하고 넘어가자.

 

 

# DICOM 개념 추가

중간에 프로젝트 메인화면에서 DICOM 개념이 추가되었는데, 이 변경사항은 전체 코드의 core가 흔들리는 부분이었기 때문에, 첫 기획 리뷰 당시에 공수 및 개발 난이도에 대해서 충분히 공감대를 형성했어야 했다.

첫번째, 기획 변동사항에 대해, 해당 내용의 개발볼륨이 크거나 정책적으로 중요한 변경이라고 판단된다면, cell리더에 선행적인 판단을 요청해야 한다.

간단한 개발내용이었다면, 크게 문제는 없었겠지만, 주요정책이 바뀌는 부분에 있어, 경험적 판단(좀 더 쉬운방향이 있을지, 실제 개발이 필요한 부분인지...등)이 필요한 부분이 있기때문에, 리뷰를 받기 전 cell리더에 공유가 된 내용인지 먼저 확인을 해야한다.

두번째, 리뷰 참석 시, 해당 변경내용에 대한 정확한 개발 볼륨을 예상할 수 있어야 한다.

이번에 가장 뼈아픈 부분이었는데, 큰 고민없이, 데이터 저장 시, 저장 구조만 바꾸면 되지않을까라는 안일한 생각을 했다.

실제로 변경된 부분이 core 정책이었기 때문에, state update, dicom 및 개별이미지 저장, 조회, AI라벨링 등 거의 대부분 API의 로직 및 쿼리를 수정해야했다.

이 부분에 대한 판단을 제대로 못했기 때문에, 작업 예상 공수와 개발 난이도에 대해 기획 및 frontend와 충분한 공감대를 가지지 못했고, 이로 인해 개발 시, 오해와 차질이 있었다.

확실하게 판단이 되지않는다면, 즉각적인 대답을 피하고 검토 후 답변하면 될 일이다. 급하게 판단하지 말고.   

# 방화벽...

보안이 엄격한 의료 도메인 서비스 특성 상 수많은 방화벽 기안을 올려야했다.

거기다, 공통 플랫폼 및 여러 병원이 각각 격리된 별개의 서버에서 구현되어야 했기에, 상신한 결재가 x N으로 진행되었는데

배포일정에 임박해서, 열리지 않은 방화벽을 다수 발견했다.

특히, 앞으로 병원이 추가될때마다 독립된 서버들도 그만큼 추가될 것이기때문에 서비스 별, 서버 별 방화벽 정책 관리페이지를 만들어서 관리를 하도록 하자.

# 슬슬 복잡해지는 코드와 모듈화의 필요성

하나의 프로덕트에서 승연씨와 각자 개발을 진행하고, 이에 대한 소통이 부족하다보니, 동일한 기능에 대해 별도로 개발한 코드들이 많이 늘어났다.

개발 진행 시, 공통적으로 사용하는 코드, 가령 dicom데이터를 AI라벨링 기능 돌리거나, 직접 라벨링 진행 시,

개별 이미지의 state update와 dicom 단위의 state update 기능과 같은 중복적으로 사용하는 부분에 대해 기능을 모듈화 하고

공통기능은 반드시 함께 작업하는 인원과 공유하여 중복 개발하는 부분을 줄이도록 하자.

 

# 마침

• 초기목표 : 6월 중순까지 의료 라벨링도구 운영기 배포
• 결과 : 일정 지연(약1~2주가량 지연)
• 원인 
  • API들의 구조와 사용방법에 대한 이해가 늦은 점
  • CDW/PMS 와의 커뮤니케이션 방식 미숙
  • 방화벽 정책 관리 소홀
  • 개발 볼륨 예측 실패
  • 모듈화되지않은 코드
  • 의료서버의 보안 정책에 대한 미숙지
• 개선방안
  • 의료 서버 구축 시, 보안정책(허용된 Header parameter항목 미리 확인) 확인할 것
  • 기획 리뷰 진행 시, 신중한 개발볼륨 및 일정 검토
    • 간단한 이슈 제외하고는 현장에서 확정하지 말 것
    • 팀간의 공유가 된 사항인지 확인 필요
  • 서비스 및 서버별 방화벽 정책 페이지 생성 및 관리
  • 최초 개발 진행 시, 반복적 로직에 대한 모듈화 처리하기
  • 기획 및 frontend와 업무 협의 전 개발 방향에 대한 대략적인 정책 및 부하를 미리 고민한 후 참석할 것