비개발자랑 일할 때 나타날 수 있는 충돌들
비개발자랑 일할 때는, 특히 나이가 많으신 분의 경우 여러가지 개발적인 측면의 컨센서스에 대해 설득하는 게 쉽지 않은 경우가 있습니다. 나중에 블로그에 자세하게 글을 쓸 거 같긴 한데 okky가 트래픽이 많으니까 일단 여기에 글을 작성합니다.
예시 1: 연구 시스템에서 Raw Data가 독립적이어야 하는 이유
주기적으로 csv 파일을 크롤링 중인데, 해당 csv 파일의 각 줄에는 해당 데이터가 크롤링된 시간 & 여러 데이터 칼럼들이 들어있었습니다.
상사: “XX님, 이거 엑셀에서 보기 불편하니까 이 칼럼은 소수점 반올림해서 잘라주시고요, 크롤링 시간대도 소수점 없애주세요. 그리고 이 칼럼의 제목은 “A값” 이라고 써져 있지만 실제로는 “A의 변화량 %”입니다. 엑셀에서 칸이 너무 넓어지는 걸 피하기 위해 그렇게 쓴 거에요.”
일단 급한대로 요구사항을 들어주고 legacy 프로그램과의 호환성을 지키기 위해 그렇게 개발했고, 결국 크롤링 과정에서 raw 데이터의 정보는 일부 loss 되었고, 이후 이러한 일이 발생하였습니다.
상사: “이거 데이터 시간 차이가 HTS에 있는거랑 1초씩 나는데, 프로그램 자체 bottleneck이나 증권사와의 통신 과정에서 무슨 딜레이가 있는 거 아닙니까?”
(알고 보니 로그를 뒤져보니 (예를 들어) 9시 7분 49.9초에 발생된 데이터를 9시 7분 50.02초에 스냅샷 크롤링을 했던 거였고, 엑셀에서는 소수점이 생략되었기 때문에 둘 사이의 딜레이는 0.1초(49.9~50.02)가 아니라 1초(49~50)로 표시됨)
이런 information loss 때문에 기술적으로 컴퓨터에서는 저장공간을 지나치게 차지하지 않는 선에서 가능한 한 훼손되지 않은 원본데이터를 저장하여야 하고, 연구자 입장에서 데이터나 featuring을 할 때 2차적으로 그때그때 원본 데이터로부터 값들을 생성해서 visualize하는 것이 좋다고 생각합니다. information loss 말고도 뭐 다른 이유들은 언제 feature값을 만드는 방식을 바꿀 지 모른다는 것도 있고(feature generation에 대한 여러가지 아이디어는 항상 나올 수 있으니까) 뭐 되게 다양합니다.
예시 2: 실행 시간에 대한 근거 없는 미신
상사: “REST API를 돌리면서 동시에 이런저런 연산도 막 하는데.. 그런 연산을 많이 집어넣다보면 이거 프로그램이 초당 N번 긁어오는 작업이 적체되는 딜레이가 생기는 거 아닙니까?“ (해당 연산량은 float 5~20개로 사칙연산 좀 하는 분량)
처음에는 timeit 같은 디버그함수 사용해서 해당 연산이 micro~milliseconds 단위에서 마무리되는 걸 보여주고 기존의 작업에는 전혀 차질이 없다는 것을 보여드릴까도 싶었습니다.
기존에 있던 전임자가 만든 legacy 프로그램이 threading을 잘못 구현한 거 때문에 생긴 delay를 몇달간 계속 봐오셔서 그런 건지, 아무튼 근거 없는 속도에 대한 미신과 의심을 끊임없이 받았습니다.
그래서 저는 로그를 좀 자세하게 구현하고, 프로그램 실행 log file을 보여드리면서 REST API 호출이 0.01~0.02초 내로 마무리된다는 점, 그리고 이런 요청들을 concurrent하게 보내기 때문에 매 REST API + calculation cycle이 0.1~0.2초 내에 마무리되기 때문에 전혀 문제없다는 말씀을 드렸으나..
그런 미신이 다소 줄었을 뿐, 사라지진 않았습니다. 앞으로도 컴퓨터가 상상 이상으로 정말 빠른 속도로 많은 것을 처리할 수 있는 존재라는 것을 인식하시기까지 꽤 오랜 시간이 걸릴 것이라 생각합니다.
상사님이 나쁜 사람이라고 생각하는 건 전혀 아닙니다. 특이하신 면모가 있으니 저한테 그런 인센티브가 담긴 채용 제안도 주신 것일거고, 근무환경도 정말 편하게 조성해주시고 대우도 잘해주시는 인간적으로도 좋은 분입니다. 하지만 그것과 별개로 개발과정에서 나타날 수 있는 의사소통의 기술적인 측면에서의 거리감은 꽤 컸고, 계속 조정을 해나가고 있습니다.
물론 전임자가 (너무 못해서) 상사님의 개발자에 대한 눈을 많이 하향시켰고, 그리고 그러한 미신(개발자가 차근차근 잘 구현할 수 있는 걸 불가능하다고 여겨서 시키지 않는 그런 게 많음)을 많이 갖고 있기 때문에 업무 난이도가 낮아진 건 편하긴 하지만.. 그래도 개발자로써 현 소프트웨어에 찝찝한 게 너무 많아서.. 시간 날때마다 이런저런 개선할 거 같네요.
설득에 관해서는 말로 하는 건 너무 힘들다고 생각하고, 기술적으로 이게 다 된다는 걸 보여주는 방법이 직빵인 거 같습니다. 일하기 시작한 지금까지도 contribution을 꽤 쌓았지만 앞으로도 contribution을 꽤 많이 쌓으면 이런저런 개선 시도를 더 많이 해볼 수 있을 것 같네요.
