흑백과 디지털

 회사에서 외부  고객 관계서비스를 사용하고 있다. 이 서비스의 API 를 이용해서 회사 시스템과 연동하고 있는데, 이 API에서 잘못된 값을 response 하고 있었다.  Response 된 항목중에 첨부파일 개수를 알려주는 값이 있는데, 이 값을 잘못 보내주고 있었다.
 이 업체가 외국 업체인데 뭔가 일 처리가 답답했다. 우선 버그를 수집하는 사람이 개발자가 아니라보니 한 단계 거쳐서 이슈가 전달되었다. 그리고 버그 사항과 무관한 조언을 듣게되었다.(API 버그라고 했는데, 브라우저 cache 와 쿠기를 지워서 테스트 해보라는 말을 듣었다. 아무래도 그냥 매뉴얼 같다. ). 그리고 불필요한 스크린샷을 요구했는데, Postman(https://www.postman.com/) 으로 API 를 테스트해본 스크린샷을 달라고 했다. 그리고 전달하니까 API KEY 가 노출되어 있다고 가려서 스크린샷을 달라고 했다.(이건 버그수집하는 사람이 직접해서 개발자에게 넘길 수도 있지 않은가.)
그리고 이거 해봐라, 저거 해봐라 하면서 우리를 테스터로 부려 먹었다. 오늘 처리가 되었다는 연락을 받았는데, 우리가 전달한 case 에 대해서만 처리해 두었다.  다른  Item에 대해서도 첨부파일 개수가 잘못된 경우가 있었는데 처리해 주지 않았다.  
  내 추정으로는 이 버그는 파일을 첨부할 때나 삭제할 때,  해당 DB 의 row 에서 첨부파일개수가 증가하거나 감소하는 형태로 되어 있었을 것이다. 그런데 어떤 case 에 해당 첨부파일개수 증감이 이루어지지 않는 case 가 있었던 것 같다. 
그래서 이미 잘못된 data에 대해서는 어쩔 도리가 없었던 것 같기는 하다. 그런데, 첨부파일이 확실히 존재는 하고 있고, 해당 서비스에서 정상적으로 보여주고 있기 때문에 다른 table 데이터를 이용해서 다시 재 계산할 수 있을것 같다. 그 정도는 확인 해 주었어야 하는데, 이 것을 안해주었다. 

 왠지 모르겠지만 외국업체에 이런 것을 요청하면 일 처리가 뭔가 깔끔하지 않는 것 같다. 

 원래 서비스 서버에 배포되면 안되는 코드인데, git를 다루다가 실 서비스 서버에 배포되어 버렸다. 이것을 한동안 모르고 있다고 퇴근하는 길에 알게 되었다. 어쩐지 git 명령어 에러가 발생하더라. 이 에러를 해결하는 과정에서 인터넷에서 못도 모르고 그냥 명령어를 사용하다가 문제를 일으킨 것 같다. (사실 왜 이렇게 되었는지 모르겠다.)

 그래서 급하게 집에서 작업해서 수정했다. 왜 이리 급하게 작업해야 하는게 많은지 모르겠다. 급하게 작업하다보니 실수도 많아지고, 기술부채가 많이 쌓이는 것 같다. 

  생각보다는 쉬었다. 그동안 이게 굳이 필요하냐는 생각이 있었는데, 있으면 편할 것 같긴하다. 굳이 필요하냐는 생각을 할때는 python type hint 을 그다지 이용하지 않았을 때이고 jsx문법을 접하면서 typescript 를 접할 때이다.   그러다보니 스크립트 언어에 strong type 이 필요하냐는 의문이 있었다. 그런데 배워보니 그렇게 까지 어려운 것도 아닌 것 같다. 그리고 jsx 문법에서 얻은 거부감이 굳이 typescript 에 까지 가질 필요가 없다는 생각이 들었다. (jsx 문법에 대한 거부감은 아마 굳이 html 으로 충분히 표현가능한 것을 굳이 이런 것을 도입해야 하느냐는 생각 때문인 것 같다. 내 기준에서는 html 은 프로그래밍 언어이고, 그것도 꽤 좋은 프로그래밍 언어라는 생각이 있다. ) 
 다만 브라우저에서 바로typescropt 를 지원하지 않다보니 환경 설정의 불편함은 존재하는 것 같다. 예전에 IE 같은 브라우저는 vbscript 를 지원했었는데, 그런 것 처럼 다른 언어들도 지원하면 좋을 것 같다.