금요일퇴근을 하고 있는데 연신 Teams 물류센터 방에서 뭐가 안된다는 글이 계속 올라왔다. 누군가 처리하겠지 하고 있는데 물류 개발자 중에 막내 개발자가 대응을 했다. 막내이지만 워낙 훌륭한 개발자라 잘 처리하겠지 하고 퇴근을 했다. 그리고 좀 잠잠해지는 것 같았다. 그저 대량 입고 와 대량 출고가 있어서 비동기 처리가 좀 지연이 되어 그런가 보다 했다. 종종 있는 일이기에…
집에 도착해서 저녁을 먹는데 Slack에서 개발자들의 논의가 계속됐다.문제가 종료된 것이 아니었다. 화상 채팅으로 논의가 계속되었다. 개발팀장님에 전화로 설명을 해 주셨다. 보안 개선을 위해 설정 변경을 하다가 오류가 발생해서 Kafka 메시지가 중복으로 쌓였고 일부 리스너에서 중복 메시지 방어를 제대로 못하고 있다는 것이었다.
WMS(Warehouse Management System)에서 발생한 이벤트(입고, 재고이동, 출고 등)를 커머스에서 리스닝하고 있는데 여기서 문제가 있으면 커머스의 재고가 틀어질 수 있다(다행히 재고의 SSOT(Single Source Of Truth)는 WMS이다).재고가 더 많아지거나 작아질 수 있는 것이다.
이때 제일 큰 문제는 과판이다. 과판은 실제 재고보다 많이 팔리는 것이다. 이런 경우 강성 클레임이 들어올 수 있고, 이전 회사에서는 이런 경우 회사에서 해당 상품을 구매해서 고객에게 보내드린 경우도 있다. 그런데 한정판의 경우는 구매 자체가 불가해서 큰 문제가 될 수 있다. 재고가 늘어난 경우 발생 가능한 과판보다 위험은 적지만 재고가 줄어든 경우 재고가 있음에도 품절로 여겨져서 판매를 못하는 미판이 발생할 수 있다. 이건 후에 재고를 제대로 맞추면 해결할 수 있다.
카지노 게임 추천와 카지노 게임 추천의 여파가 파악이 되었으니 이를 정리해서 대표님에게 공유드렸다.
간단하게 메시지를 작성해서 보내드리고, 전화를 드려서 설명을 드렸다. 대표님은 상황을 이해를 하시고 조속한 해결을 요청하셨다. 그리고 메시지로 "감사합니다"라는 말씀카지노 게임 추천 맺음을 하셨다. 카지노 게임 추천가 나서 미안함에 어쩔 줄 모르는 개발자들에게 늘 이렇게 대응에 수고한다고 고맙다고 말씀하신다. 이럴 때마다 더 카지노 게임 추천를 나지 않게 노력해야겠다는 생각이 든다.
근본적 해결책을 적용하기에는 시간이 걸리니 일단 리스너를 중단시켜서 더 이상의 문제 발생을 막았고, 능력자인 팀장님이 급하게 방어로직을 추가하여 배포를 했다. 그리고 리스너를 재개했다. 카지노 게임 추천가 발생하면 원인을 찾겠다고 시간을 보내는 경우가 있다. 카지노 게임 추천가 발생하면 최대한 빨리 정상화하는 것이 최우선이다. 빨리 정상화하느냐고 원인을 못 찾았다면 우리가 실력이 부족한 것이다. 우리 실력이 충분하다면 빠르게 카지노 게임 추천 해소를 하면서도 원인을 찾을 수 있을 것이다.
방어로직을 배포한 후 좀 안정이 되어갔다. 이때가 밤 11시 즈음이었다. 나만 그런지 모르겠지만 더 이상 집중이 어려웠다.나는 개발자들에게 오늘은 이만하고 내일 사무실에서 보여서 문제를 해결하자고 했다. 이때 나는 내일 반드시 출근해야 하는 분을 지정했다.
정말 오랜만에 토요일에 출근을 했다. 사무실에는 팀장님이 이미 출근해 있었다. 한분씩 도착하는데 바나나를 사 오는 분, 맛난 빵을 사 오는 분도 계셨다. 빈손인 내가 미안했다. 이때 내가 감동한 것은 어젯밤에 내가 필참으로 지정하지 않았지만 토요일 아침 9시에 동료들을 돕고자 자발적으로 출근한 개발자가 2분이 더 있었다는 것이었다. 도메인 지식과 데이터 조사, 보정 역량이 뛰어난 분과 어제 인프라 설정 작업을 진행한 DevOps 분이었다. 이 두분들은 안 오셨으면 어땠을까 싶을 정도로 큰 도움이 되었다. 특유의 역량카지노 게임 추천 데이터 보정을 위한 준비를 너무 잘 해 주셨고, 검증을 위한 환경을 매우 빠르게 구축해 주셨다. 너무 고마웠다. 이런 게 팀웤, 동료애라고 생각했다.
우리는 누가 먼저라고 그러자고 한 것은 아니지만 큰 모니터가 있는 회의실에 둘러앉았다.
나는 먼저 내가 이해하고 있는 게 맞는지 정리를 해서 공유하고 확인을 받았다.
엔지니어인 개발자들이 취할 방법은 "과학적 접근법"이라고 생각한다. Dave Farley의 “Modern Software Engineering: Doing What Works to Build Better Software Faster”를 보면 과학적 접근법은 다음과 같은 절차를 따른다.
Characterize(특징화): 현재 상태를 관찰
Hypothesize(가설): 당신의 관찰을 설명할 수 있는 서술, 이론을 만듦
Predict(예측): 가설을 기반카지노 게임 추천 예측
Experiment(실험): 예측을 테스트
맞는 것을 증명하는 수학과 달리과학은 반증가능성에 기반하여가설을 세우고 틀리지 않음을 증명해 가는 것이다.
나는 카지노 게임 추천가 발생했을 때 가정을 먼저 세운다. 그리고 그 가정을 검증해 나간다. 이번에도 가정을 세워서 함께 하는 동료들에게 설명해서 합의하는 과정을 거쳤다. 그리고 가정들을동료들과 나눠서 검증해 나갔다. 그리고 가정이 맞을 경우 발생 가능한 위험을 나열했고, 이에 대한 해결책을 찾아갔다.
그러면서 재고와 관련된 현업 전문가에게도 연락해서 상황을 설명하고 조언을 구했다. 이 분은 개발에 관련된 용어를 잘 이해하는 분이었고, 회사의 이력에 특히 물류센터에 대한 이해가 많은 분이라 큰 도움이 될 것이라고 생각했다. 역시 큰 도움이 되었다. 개발자들의 시각과 다른 시각으로 조언을 주셨다. 이러한 다양성이 반영된 의견을 포함해서 우리는 해결책에 접근했고 개발조직, 현업 전문가, 물류센터 리더 등의 이해당사자들의 합의를 얻었다.
함께 실행 안에 대한 방향을 정하고, 각자의 몫을 수행했다. 가장 중요한 작업은 Pair로 진행했다. 오류를 최소화하기 위함이었다. 그리고 혼자 작업한 부분이 미심쩍거나 동료의 리뷰가 필요하면 정리한 내용을 큰 모니터로 보면서 설명하며 리뷰를 받았다. 그리고 이 작업에 참여하지 않은 분들을 위해서 다소 어렵거나 복잡한 작업은 영상카지노 게임 추천 기록을 했다.
마지막으로 월요일 출근 후 진행해야 할 후속작업들을 정리했다.
회의실이라는 한 공간에 같은 시간에 있어서 매우 밀접하게 소통하며 협업을 할 수 있었다. 각자의 집에서 원격카지노 게임 추천 하거나, 메신저등을 통해서 비동기적카지노 게임 추천 일하는 것에 비해 엄청난 퍼포먼스가 있었다.
금요일 퇴근 후 자정이 넘도록 고생하고, 또 토요일에 출근해서 함께 해준 동료들에게 정말 감사했다.
하루의 마지막은금요일과 마찬가지로 오늘 취한 조치 내역과 향후 진행 계획을 관련자 분들에게 공유하면서 마무리했다.
"실리콘밸리를 그리다" 연재 중 "(12) 사고를 쳐도 혼나지 않는 회사"에 나오는 이야기이다.
인프라 설정 작업을 한 DevOps 엔지니어는 자신 때문에 카지노 게임 추천가 발생했다고 자책을 하고 있었다. 점심 식사 후에 6명의 식대를 본인이 계산하고 하려고 하기도 했다. 나는 그분에게 "외발 자전거를 타고 피자를 배달하다 떨어뜨린 배달원은 잘못이 없다"라고 말했다. 작업을 한 개인의 잘못이 아닌 것이다. 개발본부 전체의 책임이다. 만일 누군가 징계를 받거나 개인적인 책임을 져야 한다면 그 사람은 개발본부장인 나일 것이다. 만일 이런 일로 개인의 책임을 묻는다면 누가 책임의 여지가 있는 하려 들것인가?
이번 카지노 게임 추천 처리에서 한가지 아쉬운 점이 있었다면 카지노 게임 추천 시 원복할 수는 없었나이다.나는 배포, 변경 작업을 할 때 reversible을 강조한다. 즉, 적용 후에 문제가 발생하면 최대한 빠르고, 안전하게 이전 상태로 되돌릴 수 있는 준비를 하고 배포, 변경 작업을 하자고 한다. 되돌리는 준비를 위해 시간이 더 소요되더라reversible을 확보하자고 한다.
정히 reversible을 준비할 수없는 상황이라면 최대한 두 명 이상이 작업하자고 한다. TDD에서 말하는 Triangulate처럼 한 명이 작업하면서 놓칠 수 있는 부분을 방지하기 위해서 적어도 한 명이 같이하는 것이다. 나도 실수를 하면 안 되는 자동화되지 않은 작업을 할 때는 내가 하는 일을 이해할 수 있는 분과 함께 한다. 하고자 하는 것을 설명하고, 각 단계를 진행할 때마다 설명하고, 확인을 받는다. 마치 비행기 기장과 부기장이 복명복창하면서 체크리스트를 하나씩 진행하는 것처럼 말이다. 이렇게 함으로써 실수를 줄이고, 실수를 했을 때 빠르게 발견할 수 있다. 체크리스트에 대한 내용은 Mark Seemann의 "Code That Fits in Your Head : Heuristics for Software Engineering"에 자세히 설명되어 있다.
WMS를 담당하는 막내 개발자는 금요일 퇴근 후에 여자친구분과 영화를 보러 갔었다고 한다. 극장에 가서 팝콘을 사서 입장 바로 전이였다고 한다. 그런데 카지노 게임 추천가 심상치 않아 보이자 택시를 타고 집으로 가서 카지노 게임 추천 대응을 했다고 한다. 정말 미안하고 고마웠다.토요일에도 아침 9시부터 저녁 7시 넘어서까지 함께 고생을 했다. 정말 요즘 찾아보기 힘든 책임감과 열정을 지닌 젊은 개발자 분이다. 다시 한번 감사드린다.
카지노 게임 추천가 시작된 금요일 저녁 퇴근길 지하철에서 우연히 주변에서 들은 이야기가 생각난다.
“그래도 적어고 그 회사로 이직하면 MyBatis는 안 쓰겠지”
우리 회사에서는 무슨 기술을 쓰는지 보다어떻게 문제를 경제적이고 효과적카지노 게임 추천 해결하는지에 더 중점을 둔다. 그래서 JPA도 쓰지만 MyBatis도 쓴다.
다음과 같은 구조를 나는 이것을 Micro CQRS라고 부른다.
CUD(Create Update Delete)는 JPA로 Normalized 된 테이블을 다루고, R(Read)은 MyBatis로 Denormalized 한 방식으로 처리한다. 쿼리가 복잡해지는 이유는 CUD 때문이 아니라 R 때문이다.그런 복잡한 쿼리는 JPA보다는 MyBatis가 더 효과적이다.
JPA에 구현체 중 가장 많이 사용되고 있는 Hybernate가 예전에 자신들의 우월함을 보여주기 위해 내건 포상이 있었다. Hybernate가 작성한 프로그램 보다 JDBC로 작성한 프로그램이 더 빠른 것을 보여주면 1만 달러의 상금을 준다는 것이었다. 하지만 그 포상금을 받은 사람은 한 사람도 없는 것으로 기억한다. 그런데 이 포상건에 제약 조건이 2개가 있었다. batch와 보고서성 조회 쿼리는 제외한다는 것이었다. 다시 말하면 Hybernate(ORM)는 batch와 보고서성 조회 쿼리에는 적합하지 않다는 것이다. 그러니 굳이 복잡한 쿼리를 JPA, JPQL, QueryDSL 등으로 작성하기보다 SQL을 직접 사용하기 용이한 MyBatis를 사용하는 것이 더 효과적이라고 생각한다. 이런 경우 SQL이 더 읽기도 쉽다. JPA로도 할 수는 있지만 이런 경우는 MyBatis가 더 효과적이다.
퇴근길에 만난 분이 아닌 분이었다면 이 얘기를 꼭 해 주고 싶었다.