이스오타 : 해결사, 어려움을 극복하는 경험
중소기업 5년 ~ 11년의 이야기
해결되지 않은 문제점들
기존 회사 사이트를 ASP에서 Java, JSP로 리뉴얼하고 나서 해결되지 않은 문제들이 두 개가 있었다.
경력 3년에 퇴사하고 재입사 하는 시점까지도 대략 3~5년간 해결하지 못한 숙원과제 같은 존재였다.
매매 계약서 엑셀 업로드 오류
정말 애매한 문제였다. 10번 하면 한번 오류
어느 때는 30번을 해도 오류가 없고
어느 때는 한 번에 오류
너무 간헐적이며 정말 감도 안 잡힐 정도의 문제였다.
소스를 봐도 전혀 문제 될게 없었으며 아무리 구글에 검색해도 문제가 뭔지 몰랐다.
보통 구매사, 판매사가 1:1형식으로 거래하지만 보증서 금액이 높은 구매사는 여러 판매사와 엑셀로 업로드하여 진행을 했다.
특히 월말에 거래를 진행했으며 오류가 나면 해당 회원사는 극도로 예민했으며, 보증업체가 우리 회사랑만 거래할 수 있는 구조가 아니었다.
보증서 자체가 기금에서 책정되는 보증서이기에 우리 회사에서 거래가 원활하지 않으면 경쟁사에서 거래할 수도 있었다.
그래서 영업 직원, 콜센터 직원도 해당 업체가 거래를 하는지 수시로 모니터링을 하여 오류가 발생하면 빠르게 응대를 하였다.
무조건 해결해야 하는 이슈였다.
민B가 나에게 말씀하셨다. "무조건 해결하세요."
나 또한 항상 마음속에 언젠간 해결해 봐야지 생각을 하던 문제였다.
정말 진지하게 마음을 가다듬고 소스 한 줄 한 줄 계속 보고 또 보고 계속 보았다.
역시나 20번에 한번 오류 날까 말까,
50번 해보면 한번 오류 날까 말까 너무 간헐적이었다.
거의 이 정도면 월말에 업체가 거래할 때 제발 오류 없길 기도해야 하는 방법밖에 없어 보였다.
거의 한 달 동안 계속 소스를 보고 검색도 해보고 포기하지 않았다.
슬슬 오기가 생기기 시작했다.
검색하던 중 실마리 하나를 찾았다.
엑셀 업로드를 시키는 Method(어떠한 특정 작업을 수행하기 위한 명령문의 집합)가 jdk(Java 버전) 버전이 올라가면서 현재 우리가 쓰는 소스는 최신 Method였고 버전이 낮을 때 사용하던 Method가 존재하였다.
우선 민B에게 보고를 하였고
"구 버전 Method도 사용은 가능할 테니 한번 바꿔보는 게 어때요?"라고 말씀하셨고
반신반의한 상태에서 Method를 구 버전으로 변경하고 테스트를 진행했다.
테스트 결과는 100번을 시도해도 오류가 한 번도 나지 않았다.
민B에게 단 한 번도 오류가 나지 않았다고 보고한 후 운영서버에 반영하였다.
정말 신기하게도 구버전 Method로 변경 한 후로 단 한 번도 오류가 나지 않았다.
해당 문제를 해결하고 나서 구 버전도 조금은 신뢰해야겠다는 생각이 들었다.
인증서버 서비스 다운
특정 인증업체에서 인증서를 띄우는 라이브러리(기능을 모아둔 집합소)를 사용하였다.
구매사가 매매 계약서 작성할 때 판매사로 전송할 때도 인증서를 태웠고,
판매사가 승인할 때 은행으로 매매 계약서가 나갈 때도 인증서를 선택하여 비밀번호를 넣어야 넘어가는 구조였다.
하지만 거래가 제일 많은 월말에는 인증서버의 서비스가 꺼지는 현상이 있었다.
Nas(네트워크 결함 스토리지, 웹서비스) 중에 Tomcat을 사용하였다.
로그를 확인해 보면 인증서 창이 뜨면서 비밀번호를 입력할 때 라이브러리 DLL 충돌 오류라고 나왔다.
원인은 정말 말도 안 되는 타이밍에 두 개 이상의 업체가 인증을 할 때 DLL이 충돌 나는 현상이었다.
해당 인증업체한테 현상을 이야기하고 해결해 달라고 계속 요청을 해도 인증업체 측은 수십만 번을 돌려봐도 그런 현상이 없다고 답변이 왔다.
그래서 월말에는 개발팀 중 한 명은 점심도 김밥으로 대체하여 인증서버 서비스가 꺼지는지 계속 모니터링을 했다.
월말은 그렇게 넘긴다 쳐도 우리가 퇴근한 사이에 인증서버 서비스가 다운되면 업체는 콜센터도 전화를 받지 않기에 영업사원들에게 전화하여 엄청난 클레임을 걸었다.
우리 팀에 확인 요청이 오면 막내들 이S, 박S는 바로 원격으로 들어가서 서비스를 키곤 했다.
우리도 충분히 이해한다, 거래 금액이 억 단위니까 업체들도 아주 예민하다.
이 문제 또한 민B가 "주D, 해결하세요."라고 말씀하셨다.
이 문제는 엑셀 업로드보단 고민이 그리 오래 걸리지 않았다.
예전에 채용회사 있을 때 ASP는 형상관리(소스 관리) 툴이 딱히 없어서
개발한 소스들을 웹 서버 반영할 때 vbs(비주얼 베이직 스크립트)를 짜서 프로그램처럼 내가 소스를 수정한 날짜의 범위를 입력하여 경로를 지정해 주면, 해당 디렉터리에 있는 파일들의 수정 날짜를 확인하여 내가 지정한 폴더에 파일이 복사되는 프로그램을 사용하였었다.
순간 "vbs 사용해서 Tomcat이 만약에 꺼지면 Tomcat 서버에 가서 시작 파일을 실행할 수 있으면 어떨까?" 란 생각이 들었다.
우선 구글에서 "vbs port check"라고 검색하니 내가 원하는 글이 나왔다.
그다음 "vbs file excute"라고 검색하니 특정 폴더에서 파일을 실행하는 글을 찾았다.
그다음 "vbs loop sample"라고 검색하니 반복문 샘플 글을 찾았다.
이렇게 조각조각 글과 소스를 찾아서 처음 해보지만 vbs 코딩을 시작하였다.
우선 Tomcat 서비스가 켜져 있으면 8080 Port가 사용되었다.
윈도우 포트 확인 명령어 NETSTAT 했을 때 사용하는 Port들을 찾아서
loop(반복문)를 돌려서 8080 Port가 없다면 Tomcat 디렉터리에 Bin 폴더에 startup.bat 파일을 실행하게 설정하고 이 모든 작업을 체크하는 타이머는 10초로 설정하였다.
테스트는 쉬웠다. 인증서버 서비스를 그냥 끄면 10초 후에 자동으로 켜졌다.
크으, 가슴이 두근두근하면서 희열이 밀려왔다.
해결하고 운영서버에 내가 만든 vbs를 실행해놓아야 윈도우 내의 프로세스에 계속 실행 중이어야 체크가 가능하였다.
해결하고 나서 우리 팀은 밤에도 맘 편히 발 뻗고 잠을 잔 것 같다.
지원하려다 메인으로
내가 숙원과제를 하나하나 해결해 나갈 때쯤
최D(나의 선배)가 일주일에 두 번은 밤을 새워서 아침에 출근하면 자리에서 자고 있는 모습을 보았다.
우리 팀 전통이라고 해야 할까, 우리 독수리 오형제가 술자리에서 서로 얘기하며 만든 약속이 있었다.
밤새우고 자리에서 자고 있는 사람 있으면 누구든 먼저 발견하면 바로 뛰어가서 김밥 두 줄을 사서 책상 위에 올려놓자였다.
누구든 상관없이 우리 다섯 명 중에 하나이니까, 막내 두 명에게도 우리가 우릴 위해 만든 약속이니까 신경 쓰지 말라고 하였다.
물론 막내들이 밤새워서 일한다는 건 윗사람들이 욕먹을 짓이니 절대 그럴 일은 없었다.
최D가 밤새는 경우가 유난히 많아 보였다.
나도 출근하면서 자리에서 자고 있는 최D를 보면 바로 뛰어가서 김밥 두 줄을 사서 조용히 책상 위에 올려놓았다.
영D도, 동D도 출근하다 만나면 "어디 가세요?"라고 물으면
"야 최 D 또 밤새웠나 봐~! 김밥 사러 가는 중"이라고 답했었다.
그러던 중 날을 잡아서 최D와 대화를 했다.
"형님 뭔 일 있어? 요즘 왜 이렇게 밤을 세?"라고 하니
"요즘 사업개발팀 기획자랑 둘이서 프로젝트 하나 시작해서 프로토타입(리뷰용, 초기용, 시작 모델)으로 만들고 있는데 기획자가.. 어휴 너무 피곤해"라고 말했다.
"그럼 내가 지원해 줄게. 오래된 문제점도 다 해결했으니 시간 날 거야"라고 얘기했다.
민B에게 가서 최D 진행 중인 프로젝트 제가 지원하겠습니다. 보고를 하였다.
요즘은 프런트엔드, 백엔드라고 부르지만 그 당시에는 프론트단, 백단(백오피스단) 이라고 불렀다.
우선 최D가 프론트단을 구성하고 나는 백오피스단을 구성하고 대략적으로 개발하였다.
프로토타입 시연 이후 내가 프론트단, 최D가 백오피스단을 맡게 되었다.
지원하려다 본의 아니게 메인이 되어버렸다.
뭐 상관없었다.
최D랑 나랑은 워낙 일을 많이 해봐서 팀워크 하나는 최고였으니, 하지만 최D가 언급했던 기획자 이 사람이 보통 사람이 아니었다..
꿈꾸는 기획자
사업개발팀에 한D라는 기획자 여자분이 있었다.
이번 프로젝트로 같이 일하게 되었다.
겪어보니 최D가 왜 피곤하다고 한지 느껴졌다.
일단 기획자가 기획을 잘 못한다.
무슨 오류 화면에 말이 당근 먹고 놀라는 이미지를 주더니 재밌다며,
오류 화면에 설정해달라고 하질 않나
기획안 리뷰할 때 업무적으로 뭔가를 물어보면 대답을 못한다.
그리고 윗선에서 지적을 하면 무조건
"저는 개발팀에 얘기했는데 개발팀에서 안 해줬습니다."라고 회피한다.
꿈을꾸나? 꿈에서 얘기했나? 언어 순화를 해서 그렇지, 거의 미친X 같았다.
회피를 하려면 자기 팀 윗선을 팔아먹던가 뭐만 안되면 무조건 개발팀에서 안 해줬다고 보고를 한다.
하는 짓이 너무 어이없고 주간회의 때 뜬금 사업개발팀 이사님이 개발팀에서 안 해주는 이유가 뭐냐고 물으니 민B도 몹시 당황스럽다고 말씀하셨다.
"주D, 최D~ 앞으로 한D랑 회의하면 무조건 회의록 작성해서 메일로 보고해요."라고 하셨다.
우리 팀에선 한D를 꿈꾸는 미친X이란 별명을 붙여줬다.
프로젝트 오픈하기 일주일 전, 갑자기 한D가 내 자리에 와서 상품 분류 체계를 바꿔달라고 한다.
내가 무슨 소리냐 이거 바꾸면 모든 데이터가 다 꼬이는데 그리고 대분류, 중분류, 소분류 상위 레벨도 다 뜯어야 하는데 작업도 작업이지만 테스트 처음부터 다시 해야 한다며 거절했다.
갑자기 한D가 울기 시작한다.. 여기서 1차 당황.
쪼르르 사업개발팀 이사님한테 가서 울기 시작한다.. 여기서 2차 당황.
영업팀으로 가서 울기 시작한다.. 여기서 3차 당황.
부사장실에 가서 울기 시작한다. 여기서 4차 대 환장 파티
사업개발팀 이사님이 나에게 와서
"주D 아직 시간도 많은데 좀 해줘라~"이러고 가시고
영업팀 이사님, 부장님도 나에게 와서
"주D 여자를 울리면 쓰나 한D가 뭘 얼마나 잘못했길래~ 좀 해줘~" 이러시고
결국 민B가 부사장님에게 호출되고 민B는 부글부글 끓는 표정으로 오셔서
"주D 해줘요. 대신 일정 안될 것 같으면 일정 조절해 볼게요.. 하.."라고 하셨다.
상품 분류체계 변경하는데 계속 야근을 하고 작업이 마무리되는 시점에 한D에게 한마디 했다.
"앞으로 나랑 다신 엮이지 맙시다. 진짜.."
불행 중 다행인지 프로젝트는 별문제 없이 마무리가 되었다.
검색엔진
이번에 새로 오픈한 사이트가 내가 예전에 이스오타로 오타를 내었던 이스토어의 확장판으로 전자입찰 관련 사이트였다.
최종 오픈까지 한 상태인데 메인이 뭔가 밋밋하다는 얘기가 계속 나오다가
그 당시 네이버 실시간 검색 순위가 표기될 때였는데, 해당 사이트에 검색엔진을 붙여보자는 얘기가 나왔다.
민B와 계속 검색엔진에 대해 검색해 보고 찾아보는 중
쏠라 Solr(solra)라는 오픈소스 기반의 검색엔진을 찾았다.
검색엔진 전반적인 세팅은 민B가 직접 해주셨으며 나는 검색엔진을 소스에 연결하고 키워드 자동완성 기능을 만들고 검색엔진 설정 부에서 주기적으로 데이터를 업데이트하여 형태소 작업을 진행했다.
키워드 자동완성 기능을 만들 때는 밤을 꼬박 새웠다.
자리에서 자고 있는데 아침에 눈을 떠보니 내 책상 위에도 김밥 두 줄이 놓여 있었다.
처음 받아봤지만 엄청난 감동이 밀려왔었다.
아 이런 느낌이구나, 누구인진 몰라도 우리 독수리 오형제 중 세 명 중(진 D는 퇴사) 한 명이니까.
우리 끼리라도 이런 걸 만들길 잘했다는 생각을 했다.
오픈하고 나서 결국 활성화는 되지 않았지만 검색엔진을 구축했다는 거에 나름 자부심을 많이 얻었다.
오래된 문제점을 해결하기도, 도전과 극복의 과정들이 모두 경험이 되어 개발자로 살아가는데 나를 더욱 강하게 만들어준 것 같다.
