본문 바로가기

개발회고

 (19)
문서화에 대해 아무도 알려주지 않는 것들 역주 : 이 글은 What nobody tells you about documentation 을 번역한 글입니다. 오타 및 오역 지적 환영합니다. 아무리 문서 작업에 노오력을 쏟아봤자 방향을 잘못 잡으면 소프트웨어의 품질에는 전혀 도움이 되지 않습니다. 좋은 문서 작업을 위해서는 반드시 알아두어야 할 비결이 있습니다. 바로 문서를 단순히 그냥 '문서’로 퉁치는 인식이 바르지 않다는 겁니다. 문서에는 네 가지 종류가 있습니다. 튜토리얼, 하우-투 가이드, 해설, 기술 레퍼런스가 바로 그 네 가지입니다. 이 네 가지는 각기 다른 목적이나 기능을 가지고 있고 각각의 작성을 위해서 서로 다른 접근법이 요구됩니다. 이것들이 뭘 의미하는지를 이해하는 것은 문서화의 질을 향상시키는 데에 큰 도움이 됩니다. 서론 문서..
재현되지 않는 문제 유추 장애 보고를 받으면, 제일 먼저 테스트 서버에서 문제를 재현한다. 보통 여기서 재현되지 않으면, 개발자들은 더 깊이 들여다 볼 생각을 하지 않는다. 다른 해야 할 일이 많기 때문일까? 포기가 너무 빠르다는 느낌도 받는다. 그렇지만, 지금까지 재현되지 않는 문제를 몇 가지 꼽아 보면, 이런 유형이 발생했을 때 큰 도움을 받을 수 있을 것이다. 첫째, DB의 에러로 인한 트랜잭션 오류 지금은 해소했던 것인데, Oracle Package에 전역 변수를 사용하니, 새롭게 컴파일 할 경우 꼭 1회씩 패키지 버려짐 현상이 발생했다. 이로 인해 해당 Package가 실행되지 않아 메시지가 발송 안되는 것은 어쩔 수 없었다지만, 이것이 전체 트랜잭션에 영향을 주었던지, 해당 주문 취소가 모두 롤백됐다. 문제는 이 사이..
상품 속성 변경에 따른 사고 이번 사고의 원인은 D-3 상품이 D-1 으로 변경된 데에 따른 것이다. 애시당초 D-3 상품이란 게 있었느냐는 게 문제 검토의 시작일 것이다. 대체 D-3 상품에 대한 기획은 시스템 운영팀과 협의가 됐기에 그렇게 한 것이었냐는 것이다. 그냥 입력란에 아무 텍스트나 넣어질 수 있어서 3을 넣었다면 곤란하다. 어쩌면 그런 입력체계를 만들어준 것이 문제인지 모르겠다. 여기를 일단 Combo로 제한해야 할까보다. D-4, D-5 를 막기 위해. 본래는 D-1 과 D-2 상품만 존재했었는데, 어느 순간 D-3가 추가되게 된 것이다. 책임은 누가 지며, 이에 따른 추가 개발은 어떻게 진행되어야 하겠는가 이다. 일단 미봉책 수준으로 SAP에 전송되게 만들었지만, 아무도 이 사안의 중요성에 대해 알지 못한다. 뭔가 ..
왕따, 외로움? 요즘엔 상급자도 왕따 당한다. 꼰대라는 낙인으로 왕따 당한다. "나때는.." 뭐 이런 얘기는 하덜 안해도, 그리고 아무리 주의를 해도 저들은 안다. 그런게 몸에 배어 버린 꼰대이기 때문에 표현만 안할 뿐 같은 종자라고. 어쩌면 이걸 세대간의 갈등으로 볼 수 있는 건가 싶기도 하지만, 어쨌든 소통이 좀 불편하다뿐 나는 이런 현상 자체에서 초라함이나 외로움을 느낄 여유가 없다. 그런 건 일종의 사치라고 느껴진다. 직장은 전쟁터다. 직장을 전쟁터로 인식하는 나는 하루에도 계속해서 쏟아지는 오류를 직면하면서 제이슨 본이 되어 날아오는 칼을 피하고, 완전 제압을 위해 애쓸 뿐이다. 그러다 보면 어떤 저녁은 까맣게 지새워 집에 들어가지 못할 때도 있다. 새로운 마케팅 방법과 판로가 개척되어서인지 생각지 못한 오류가..
최악의 상황 맨붕이란 게 이런 건가 싶은 상황에 맞닿뜨렸다. 정말 생각하고 싶지 않은 상황들이 너무나 연속적으로 터졌다. 화요일 주문물량이 제일 많은 편인데, 그게 돌지 않아 수동으로 돌려주어야 했다. 다른 개발자가 만든 생성 로직을 보니 가관이었다. Sysdate+2가 곳곳에 있어 Sysdate+1해주어야 했고, 어떤 것은 Sysdate-1도 해주어야 했다. 십수군데를 그렇게 바꿔야 했는데 그만 두 군데를 놓친 것. 이의 결과는 어마어마 했다. 결제는 됐는데 주문상세는 만들어지지 않은 상황. 애시당초 그 프로그램을 만들었던 친구는 기존 주문 마스터를 삭제하자고 했고, 나는 딱히 어찌해야할지 몰라 맨붕이 왔다. 그렇대도 1700건을 다시 수동 취소해야 하는 것은 아니라고 생각이 들어 프로시저를 별도로 짰다. 그런데 ..
실패에서 배우기 실수가 잦으면 실력이라는데, 나는 기어이 실력으로 고착 시키려 하는가? 지난 목요일 업체 지원이, 임직원 할인쿠폰을 발급받지 못한 분이 있다고 하여 확인해 보니, 그와 유사한 사람들이 무려 125건이나 됐다. 쿠폰을 수동으로 발급해줬다. 고객에게 삽입쿼리를 주고 요청했다. 절차상 문제는 없었다. 그런데 문제는 내가 준 쿼리 내용에 문제가 있었다. 10000원 할인이었기에, give_cnn은 10000이 들어가야 했으나, 실수로 100%가 들어갔다. 이는 5회차 무료쿠폰을 줄 때 넣는 값이었다. 꼼꼼히 살피지 못해 빚어진 실수다. 이 문제의 쿠폰은 바로 일요일 주문메시지 발송에서부터 에러를 일으켰고, 결국 매출이 확연히 준 것을 확인한 팀장이 강과장에게 연락한 이후에야 우리에게 연락이 왔고, 부랴부랴 짐싸..
거기는 제 담당이 아닌데요 영화 에서 봤던 인상적인 장면 중 하나가 업무 범위 역할에 대한 주인공의 인식이었다. 주인공은 FBI다. 그러나 멕시코 조직폭력배 소탕작전에 투입되면서 CIA와 함께 일을 하게 되는데, 절차도 없고 막무가네 식인데 나름 전략은 있는 상황에 직면한다. "이런식으로 일하는 법이 어디있냐"고 따지거나 "이런 건 내 영역이 아니다"라거나. 이런 역할과 범위를 경찰 FBI, CIA를 나열해 놓고만 봐도 그림이 그려진다. 개발의 영역에서도 범위와 역할은 어느정도 명확하다. 그것은 최초 해야할 일을 나누기 위한 조치에서 시작한 것이지 막상 일을 하다보면, CIA가 FBI의 도움을 받듯이 서로 도와가며 해야 하는 것이다. 물론 상호 도움을 줄 때에는 도움 받는 쪽은 더욱 감사한 마음을 가져야 일은 원활히 흘러 갈 것이..
쇼핑몰 개발 관리 역할(1/2) 회사에서 관리하는 쇼핑몰은 국내 TOP에 드는 홈쇼핑이다. 그러나 내가 파견나온 곳의 쇼핑몰은 규모가 그만큼은 아니다. 고객은 늘 우리에게 묻는다. "거기에서는 어떻게 하나요?"라고. 그런데 어찌보면, 규모의 문제가 가장 큰 것일 수 있어서 고질적인 병폐는 항시 존재한다. 거기는 열할분담이 명확하고 배포기준, 테스트 절차, 팀간 분업이 오랜 시간을 거쳐 확립된 사례라 할수 있을 것이다. 그래서 패널, 이벤트, 인프라, MC, PC, 기간계 등의 영역 나눔이 있고, 고객도 이 절차를 알고 있어 어떤 개발에 들어가고자 하면 설계나 운영방안이 명확한 셈이다. 그러니 공수도 합리적으로 뽑히고 업무도 여유있게 할 수 있다. 여기 쇼핑몰의 문제는 바로 소수의 관리 인력이 감당해야할 범위가 너무 많다는 것이다. 그래..

티스토리툴바