흑백과 디지털

 전에 외부 서비스를 이용하는데 버그가 있다.(https://yiunsr.tistory.com/895 ) 이런 글을 올리면서 외국 업체라서 뭔가 지원이 이상하다고 생각했다. 이번에는 국내 업체인데, 나름 꽤나 큰 회사 였다. 물론 해당 사업부는 좀 작은 곳일 수는 있지만 모기업은 나름 국내 100대 기업은 되는 곳이다. 그런데 버그가 있어 확인을 요청했다. 

 답변을 보낸 사람이 사원이었다. 그래서 그런지 일 처리가 매끄럽지 못했다. 여러차례 메일을 주고 받으면서 이야기 하다 내가 알 수 없는  parameter 로 request 를 보냈다고 했다.  상대방이 로그를 보내 주었다. 
 그 로그를 보니 어떤 restful API 의 로그가 보였다. 그런데 remote address 가 내부 IP 주소였다. 🤔, 간혹 load balancing 때문에 이런 현상이 발생하기는 하지만 해당 업체에서 remote address 라고 하면서 저런식으로 자기 네트워크 내부 IP 를 찍을 것 같지는 않았다. 다시 보니 user agnet 도 java 였다. 나와는 다른 language 이다. 결국 서비스업체의 버그가 맞았다. 

아무리 그래도, 로그에 내부 IP 가 찍혀 있으면 확인 좀 해주지. 여기에 적지는 않았지만 내가 꽤 자세히 버그 리포팅 했고, 버그의 원인도 추정해 보냈다. 경험이 적은 신입이면 선임들이 작업을 확인 해 줬어야 하는 것 아닌가?? 

처음부터 기술지원 받기도 힘들었고(voc 단에서 1차적으로 의미없는 시간 소모를 많이했다.)  작은회사에서 버그 리포팅해서 무시를 당했다는 느낌을 지울 수 없었다. 

* https://huggingface.co/skt/kogpt2-base-v2
* https://huggingface.co/skt/ko-gpt-trinity-1.2B-v0.5

위 모델을 테스트 해보고 있다. 
가끔은 정말 말도 좋은 답변이 나와 놀랍기도 하다. 

코로나 이후 경제는 어떻게 변하게 될까요?
 
==  kogpt2-base-v2 모델에서 답변 ==
코로나 이후 경제는 어떻게 변하게 될까요?
이런 질문에 대한 답을 찾기 위해선 먼저 코로나가 어떤 영향을 미칠지부터 살펴봐야 합니다.
우선, 경제에서 가장 중요한 것은 바로 '사회적 거리두기'입니다.
그동안은 사회적 거리를 두면 사람들이 많이 모이는 장소를 중심으로 방역을 실시했습니다.
하지만 이제는 그마저도 어려워졌죠.
특히, 최근 들어 확진자가 급증하면서 감염병 위기 경보가 심각 단계로 격상됐고, 이에 따라 정부는 오늘 0시부터 수도권의 모든 유흥시설 및 실내체 
육시설, 노래연습장, PC방 등 고위험시설에 대해 집합금지 명령을 내렸는데요.
이에 따라, 서울시는 오는 27일까지 2주간 클럽과 콜라텍에 대해서는 영업 중단 조치를 취하기로 했습니다.</d> 지난해 12월 31일 오후 2시께 부산 해
운대구 우동 모 아파트 앞 도로변 가로수 길에서 A(50)씨가 몰던 승용차가 중앙선을 넘어 마주 오던 B(52)씨의 택시를 들이받았다.
B씨는 사고 직후 병원으로 옮겨졌으나 숨졌다.
경찰 조사 결과 이 사고로 운전자 C(44)씨와 동승자 D(32, 여), E(21, 남)가 다쳐 병원에서 치료를 받고 있다.
또 다른 목격자인 50대 남성도 중상을 입어 인근 병원 응급실로 옮겨져 치료 중이다.
A씨 등은 경찰조사 과정에서 "택시가 갑자기 방향을 틀어

== ko-gpt-trinity-1.2B-v0.5 모델에서 답변 ==
 코로나로 인해 많은 사람들이 일자리를 잃었습니다. 하지만 실업률은 여전히 높은 편입니다. 그리고 코로나19가 종식되더라도, 사람들은 다시 일터로
 돌아가기 어려울 것입니다. 따라서 기업들은 재택근무를 도입하거나 유연근무제를 확대하는 등 근무 형태를 다양화 할 것으로 보입니다. 또한 비대면
 업무의 증가와 함께 원격회의나 화상 회의 등의 새로운 비즈니스 모델도 등장할 것입니다.
 그렇다면 이러한 변화 속에서 살아남을 수 있는 기업은 어떤 기업일까요? 바로 '디지털 트랜스포메이션(Digital Transformation)'을 통해 디지털 전 
환을 성공적으로 이뤄낸 기업들이라고 생각합니다. DT란 기업의 모든 경영 활동을 데이터 기반으로 전환하여 운영 효율성을 높이는 것을 의미합니다. 
즉, 기업이 보유한 데이터를 분석하고 이를 바탕으로 의사결정을 하는 것이죠. 예를 들어, 아마존은 클라우드 기반의 인공지능(AI)을 활용해 고객들의
 구매 이력을 분석해 맞춤형 상품을 추천해 주는 서비스를 제공하고 있습니다. 또한, 구글 역시 AI를 이용해 검색 결과를 최적화하는 기술을 개발 중 
이며, 마이크로소프트(MS)는 클라우드를 활용한 협업 플랫폼인 애저(agger) 등을 선보이고 있습니다.
 이처럼 기업들의 IT 인프라를 구축하고, 시스템을 개선하며, 일하는 방식을 혁신적으로 바꾸는 것은 매우 중요한 일이지만, 그 과정에서 발생하는 비
용과 리스크에 대한 부담감도 클 수밖에 없습니다. 이에 따라 최근에는 빅데이터 분석을 통한 예측 및

 확실히 모델 크기가 커지면 좋은 답변이 나오는 것 같다. 

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

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