24.05 - 낚시

 

"현장은 상상을 초월한다"

 

기대와 설렘으로 입사한 내가 발생하는 CS들을 보며 왜 이런 이슈가 발생하지? 하며 이해를 못 하고 있을 때

 

가장 먼저 알려 준 마크(사수)의 말이다

 

여러 장비가 얽혀 동작하는 구조상, 그 자체만으로도 다양한 이슈가 발생하는데

 

거기에 사람의 실수를 끼얹으면

 

아수라장이 되는 것이지

 

자세한 기술적 동작은 설명할 수 없지만

 

대다수가 휴먼에러로 발생하여 초음파 영상이 정상촬영 되지 못하고

 

마미박스(장비)가 업로드하지 않는 경우가 발생하는데

 

병원과 사용자 모두

 

"아 모르겠고 복구해 줘"

 

라고 하니, 그동안의 복구 과정은

 

1. CS -> 마미박스 개발자에게 영상이 존재하는지 확인 요청

 

2. 개발자가 직접 장비에 접속하여 영상 확인 & 다운로드

    (장비가 오프라인이면 CS팀께 병원에 장비 온라인 요청을 요청)

 

3. 개발자가 다운로드 한 영상을 CS팀에게 전달

 

4. 영상이 복원 가능하다면 복원하여 개발팀에게 전달

 

5. 업로드

 

의 과정이었다

 

많지 않으니 이렇게 대응해 왔다였지만

 

장비는 수천 대고, 영업팀의 유능함 덕에 사업이 끝없이 확장되며 촬영 수가 증가 -> 자연히 이슈도 증가

 

CS와 개발자 간의 자원낭비를 참을 수 없었던 자동화 환자인 나는

 

마음껏 해 보라는 마크(사수)의 비호에 힘입어

 

개선을 거듭하여 출시를 했고, 매우 뿌듯하다는 그런 얘기

하고 나니 쉬운데(항상 그렇게 느끼는 건 왜지?)

 

막상 만들어갈 때는 제법 삽질을 했더랬지

 

서버가 터널링 서버를 통해 장비에 SSH 접속을 하는데 장비는 오프라인 상태일 수 있고 네트워크 상황 상 연결이 한 번에 이뤄지지 않을 수도 있어, 서버에 부담이 되지 않는 수준에서 일정 시간 반복을 하며 소켓 이벤트 응답을 받을 때까지 루프를 돌고 그렇게 받은 이벤트로 장비의 터널링 서버 접속 정보를 받아와 접속을 하는데, 터널링 접속 정보를 열어주는 이벤트조차 내가 반복하여 보내야 하고 응답이 지연되면 반복해서 보내는 터널링 접속 정보를 열어주는 이벤트가 중첩되기에 동시성을 고려하여 장비가 따로 저장하는 디비의 터널링 서버 접속값을 조회하여 이벤트를 멈추고 접속을 시도하게 해서 해결했는데, 막상 접속하여 경로에 접근시키는데 초음파 영상이 존재할 수 있는 경로가 두 곳이고, 파일명에 별칭이 붙어있을 수도 있어서 거기까지 고려하여 드디어 성공하나 싶었는데, SSH 보안 문제로 배포된 ECS에 직접 접속하여 실제 동작할 수 있는 명령어를 간신히 찾아 적용한 후 서버에 임시 다운로드하여 S3에 업로드 후 Pre-signed URL을 반환받게 하여 슬랙으로 각종 정보를 이쁘게 가공하여 메시지를 보내게 했다

 

최대한 간추려서 적었는데 몹시 장황하네

 

결론은

 

너무 재밌고 짜릿했다

 

더 어려운, 그리고 진짜 문제를 해결할 수 있는 작업을 계속하고 싶다