20일
소프트웨어의 복잡도가 올라가고, 한명의 머리로는 도저히 전체 내용을 알수 없는 소프트웨어들이 많아지면서, 소프트웨어의 버그를 찾고 수정하는 과정을 가만히 분석해보면 의사들이 질병을 진단하고 치료하는 것과 별다를바 없어 보인다.
그런데도 소프트웨어 개발자는 의사에 비해 상대적으로 권위가 없어서 의사였으면 겪지 않았을 황당한 상황에 자주 처한다.
질병을 확익하거나 버그를 확인하는 것은 처음에는 단순한 증상들로 시작한다. 문제는 이 증상의 원인이 뭔지 알수도 없고, 원인으로 짐작되는 것이 어떨때는 다른 원인의 결과일수도 있다. 그것만이면 다행인데, 때로는 그 증상들을 사용자(환자)가 제대로 설명도 안해줄 때가 많다. 그래서 의사는 환자가 오면, 증상들을 다시 한번 확인하고, 그런 증상이 생길만한 가장 흔한 질병 부터 하나씩 확인 해간다. 개발자도 마찬가지다. 가장 먼저 어떤 상황에서 문제가 생겼는지, 증상은 무엇이었는지 다시 확인하고, 가장 흔한 버그의 가능성 부터 확인하고 조치한다. 그런데 의사에게 “내가 왜 감기에 걸렸죠?”, “제가 왜 역류성 식도염에 걸렸죠?” 라는 질문을 던지는 사람은 드물지만, “왜 확인 버튼이 활성화가 안되죠?”, “왜 내 컴퓨터에서는 실행이 안되죠?” 라는 질문을 던지는 사람은 아주 흔하다 못해 대부분이다. 심지어 의사의 경우에는 “손을 잘 안씻으셔서요”, “너무 늦게 식사 하시고 바로 누워서요” 라는 답변에도 수긍하지만, 개발자의 “필요한 내용을 다 안채우셔서요”, “당신의 컴퓨터에 브라우저 버전이 낮아서요” 같은 질문에 수긍을 못하고, 어쨌든 고쳐달라고 하는 경우가 많다. 간략한 케이스들로 말하려니 심플한거지 실제로는 더한 경우들도 있다.
흔한 케이스가 아닌 경우에는 각종 검사 기법들을 통해서 좀더 자세하게 살펴본다. 의사라면 CT, 혈액검사, 소변 검사 등등의 각종 검사를 사용 할것이고, 개발자는 logger, Error Message, packet dump 등등의 방법을 써서 확인하려도 한다. 여기서도 개발자의 권위 없음이 서럽게 다가온다. 검사를 하고 결과를 보는데는 각기 리스크도 있고(물론 대부분은 안전하다) 시간도 걸린다. 그런데, 개발자한테는 유독 빠르게 문제를 알아내라고 다그친다. 그 과정에서 성능이 저하될만한 요소라도 있으면 서비스에 영향이 가면 안된다고 못하게 하는 경우도 태반이다.
마지막으로 결국 여차저차 해서 문제를 해결하면 의사는 칭찬을 받고, 개발자는 왜 그런 버그가 생겼는지 리포트를 쓴다. 때로는 그 과정에서 책임 떠넘기기가 일어 난다. 그걸 만드는 사람이니 당연히 그래야지 라고 생각할수 있지만, 현대의 소프트웨어는 사실 개발자 한명, 개발팀 한팀이 알수 있는 규모가 아니다. 어떤 소프트웨어의 90%이상은 남이 짠 코드가 차지하고 있다. 개발자가 일을 안한게 아니라, 그정도로 복잡하고 거대하다. 당장 “hello world” 하나 찍는 아주아주 간단한 프로그램 조차 os라는 거대한 소프트웨어가 없으면 아무것도 못한다.
아무리 뛰어난 의사라도 모든 사람을 한방에 치료해주고, 완벽하게 치료해줄수 없듯, 소프트웨어 개발자도 마찬가지이다. 소프트웨어개발자가 의사 취급은 못받더라도, 버그 왜 못고치냐고, 왜 뭐가 문제냐고 다그치지는 말아줬으면 좋겠다.
24일
js
- https://bundlers.tooling.report/
- https://www.gatsbyjs.com/
- https://nextjs.org/
- https://unpkg.com/browse/lit-html@1.3.0/
- https://www.skypack.dev/
k8s
TRPG관련
자작룰 관련 이야기이지만 게임 개발에서도 같은 맥락의 이야기 이므로 살펴 볼만 하다.
- [강의] 자작룰의 역사는 사실 인정투쟁의 역사죠. ㅎㅎ
- [일반] 자작룰 잘 만드는 방법
- 예시) 추라이 던전