프로젝트는 기존 PROC , 오라클 프로시져 , 쉘스크립트 를 JAVA JPA 로 변환하는 프로젝트였고 나는 프로젝트 막바지에 또 소방수로 투입되어 왔다. 지금 이 프로젝트를 수행하는 PL 은 극심한 스트레스로 죽을듯한 고통을 겪고있었다.
엄청난 대량의 데이터를 다루는 PROC , 오라클 프로시져 , 쉘스크립트 를 JAVA JPA 로 전환해야 하는건데
JPA 는 어떨땐 정상작동하다가 또 어떤 특이한 케이스가 걸리면 정말 예상밖으로 오작동을 해댔다.
또한 로직을 JAVA 로 잘 변환했다고 생각했지만 기존 로직을을 돌린 결과 데이터와 신규로 만든 JAVA JPA 배치 실행 결과 데이터가 일치하지 않아 왜 그런지 찾는데 많은 시간이 걸렸다.
MYBATIS 를 쓰는게 훨씬 안전하고 개발속도가 빨랐을 거라고 같은팀에서 이구동성으로 이야기 하게 되었다. JPA가 너무 약속된 대로 동작하지 않았기 때문이었다.
파워가 필요할땐 힐템-맛집효능 ( 구글 플레이 )
효능으로 맛집찾기
기존 PROC, 오라클 프로시져 로 돌리던 로직을 JPA 로 변경하는 제법 큰 덩어리를 완료해줬더니
실행해보니 PROC 나 프로시져로 돌리면 몇초면 끝나는 작업이 JAVA JPA 로 최대 30분이 걸릴정도로 느렸다.
결국 현업에서도 뭔가 프로젝트 방향을 선회하여 완전히 JPA 로 가는게 아닌 SELECT ... INSERT ... 같은 쿼리를 허용하는등 의 타협이 있었다.
프로젝트 막바지에 투입되어 , 두달 가까이 처음 몇주만 널널한척 하길레 칼퇴할 수 있는 안전한 프로젝트인줄 알았다가 , 프로젝트 투입 후 일주일 정도 후가 되서야 일정때문에 많은 어려움을 겪고 있다는 사실을 그때서야 알려줘서 , 짐 다 싸들고 온 판에 그냥 가기도 그래서 , 끝까지 야근만 하다 끝냈다. ㅎㅎ
절대 하면 안되는 조건인 , 이전의 다른 SI 후기를 본사람도 있겠지만 야근하고 집이 멀어서 퇴근도 못하고 시끄럽고 추운 찜질방에서 뒤척이며 잤다가 다시 아침6시부터 일어나서 밥먹고 부리나케 와서 다시 밤 12시 까지 전력질주로 달리는걸 1달 넘게 했던 그 프로젝트에 비해서는 괜찬았다.
일하는 사람끼리의 커뮤니케이션은 슬랙 을 주로 사용했고 AWS 운영서버에, 젠킨스 빌드 배포 환경이었다.
보통의 SI 프로젝트와는 다르게 딱 고정된 장소에서 일해야하는건 아니라서 회사 건물 어디든 가서 일할 수 있었던게
일에 집중도 잘되고 일의 효율이 좋았다, 나중에는 코로나 때문에 거의 재택으로 일했었다.
프로젝트는 배민이 아닌 다른 수행회사에 소속되어 그회사의 다른부서 팀과도 함께 진행했는데 , 수행사 PM 님이 중간에 다른팀까지 협조를 구하느라
애를 먹고계셨다. ^^ , 나도 괜히 관련해서 좀 안다는 이유로 회의라고는 하나 싸움판인 싸움에 끼여서 싸우는데 중간에 끼여서 ... 헉스 힘들었다. 풀스택 으로 개발을 해본 입장에서 혼자 전체를 구현하는게 훨씬 편하겠다는 생각이 들었다. 괜히 클라이언트 앱 , 백 서버 나뉘어 있는데다 클라이언트 앱측 개발하는 수행사 측팀은 클라이언트 개발하는데 맞춰서 우리 요구사항대로 API 만들어 주라는 식으로 강압적으로 굴려고 하는거 같은데다 뭐로 개발하는지 스펙도 비밀이라고 안알려주고 요구사항도 정확하게 요청하지 않고 어림잡아 요구했다가 구현해주면 이게 뭐냐는 식으로 싸우자고 대드는 태도로 인해 더 난감했다.
백그라운드쪽 담당 수행사 차장님에게 이야기한 내용은, 저쪽팀은 무슨 회의를 저렇게 싸우자는 식으로 하는건지... 이래서... 일이 될지 차라리 관두겠다고 이야기 했다가 . 지금나가면 내쪽 업무는 다 갈아엎고 처음부터 다시 개발해야하는데 기간상 불가능해서 프로젝트 타격이 엄청나다고 부탁을 해서 그냥 있었다. ㅎㅎ
뭔가 또 반전인게 나중에는 수행사쪽 클라이언트 구현팀 쪽에서 공통쪽 SSL 처리하는 부분에서 막혀서 뭐가 안되는데 어떻게 해야하느냐고 SI 프리로 들어간 나에게 문의를 해왔다. 이 뭔 ... 이전에 싸우자고 대들더니 문의는 해오고... 암튼 프로젝트 전체 를 한번 경험해 봐서 공통쪽 SSL 모듈을 해결해주게 되었다.
또 한번의 고비는 프로젝트 막바지에 가서 UPDATE 나 INSERT 시 WHERE 절에 RANGE 타입의 조건을 걸어서
같은 테이블에 여러 업무에서 CUD 를 하면 테이블락으로 관련 서비스들이 일부 처리되지 않는 버그가 도처에 깔려있었다.
위의 에러로 인해 나에게 직접 연락오지는 않았지만 다른팀들은 이 껀으로 인해 이슈 되서 뭔가 싸움판이 될뻔했던거 같다.
프로젝트는 막판에 내가 보기에 뭔가 쪽나는것처럼 싸움판이 될뻔했던거 같기도 했다.
그래도 이 사항을 먼저 발견해서 알려주고 프로젝트 막바지에 급하게 이팀 저팀들 전부 쿼리들을 고쳐서
한가지 작업을 지연시키는 요소는 32비트 노트북PC에서 로컬테스트 시 웹로직을 작업자PC에 띄워
테스트 하느라 개발속도상 지연이 가끔식 생기게 되었다.
( SSD 하드 였다면 그래도 괞찬았을 텐데 그당시 SSD가격이 비싸서 미리 준비는 안해뒀었다)
삼성전자 직원분들은 대부분 친절한 분들이 많았다.
어려웠던 점은 다른 외주 프리랜서들끼리 편가르기와 싸움이 있었고
휘말리게 되는 점이었다.
몇 년 후 두번째 삼성 프로젝트는 투입인원이 나포함 3명에 개발환경은 창문하나 없는 지방의 사무실 이었다.
교통환경이 좋지 않아 6시 나 9시에 운행하는 셔틀을 타야했기 때문에
어쩔수 없이 6시면 칼퇴근을 해야했고
프로그래머 인원이 적어서 기술조사와 로직코딩 노가다 등을 혼자 다 해야하는 상황이었다
( 고객사측의 책임분이 있었지만 처음부터 잘모른다고 해왔고
고객사만의 특이 기술에 대해 물어봐도 자세히 모른다는 답변으로 삼성특유 api 호출용 jar 모듈을 만들때
지연발생시 도움을 얻지 못했다.
또 운영 환경에 배포할때 원격컴에 들어가서 또한번 원격으로 배포하는 과정에서의
수동 복사과정이 힘들다며 원격 배포를 내가 직접 해야했다. 자동배포시스템이 없었던)
특히 삼성은 사양서 작업이 많다. 사양서 작성 툴도 정음한글이라는걸 써야 하는데
빠르고 편한 툴이 아니라 사양서 노가다 작업도 상당했다.
이러한 위험요소에 대해서 사전에 알지 못했던게 상당한 위험이었다.
어려웠던점은 처음에 칼퇴근을 하면 안됐었는데 퇴근시간 조정이 셔틀시간 마추느라
맘대로 되는게 아니어서 6시에 퇴근하며 시간을 보낸게 실수였다.
프로젝트 막바지 한달에 일반화면개발작업과 산출물작업에 더해 운영환경에 소스 배포와
삼성 특유의 암호화된 API 호출 방식을 적용해야하는기술조사관련한 문제에 부딛쳐
한달 내내 주말없이 밤 12시에 퇴근했는데, 퇴근할때 셔틀은 못타고 읍내의 찜질방에서 자야했다.
프로젝트 마지막 1달은 정말 치열한 사투를 벌였고 두뇌를 계속 사용하는 작업이기 때문에 잠이 오는 상황에서도 똑바로 정신을 차리고 두뇌를 최대한 가동하여 하나하나 정확히 구현해내야 했다. 모든 상업용 소프트웨어를 개발한다는 것은 치명적 버그나 결함이 있으면 안되고 특히 이번프로젝트는 수송비 배송비 등의 돈을 정산하는 프로그램이기 때문에 모든 상업용 프로그램이 그렇겠지만 정확하게 구현되어야 한다.잠을 못자서 잠까지 쏟아지는 번아웃 그로기 상태에서도 두뇌를 풀가동하기 위해 엄청난 체력을 사용해야했고 계속 한달을 싸워서 겨우 마무리 할 수 있었다.
정말 마음이 타들어가는 처절한 한달이었고. 엄청난 압박과 매일매일 싸워서 겨우 끝마칠 수 있었다.
이후 이 프로젝트 경험이 트라우마로 작용해 SI 프로젝트 투입은 여러번 신중히 생각하게 되었고 또한번 이런 프로젝트를 진행할 생각은 먼지한톨만큼도 없게 되었다..
스트레스엔 힐템-맛집효능 (구글플레이)
프로젝트에 총 투입되는 개발자 수가 적어서 혼자서 이것저것 다해야하는것과
지리상 퇴근시간을 맘대로 조정할 수 없는게 위험요소였다.
야근 쉽게 볼게아니다. 한달내내 기간을 맞추려 야근하는 것은 말아톤을 100미터 달리기 하듯이 전력질주를 하는 기분을 느낄 수 있다. 아침일찍 출근해서 새벽1시 자기전까지 한달 내내 하는 마음이 타들어가서 그로기상태가 되도 미칠듯이 달리는 사람 미칠 짓 이었다. 잠이 와도 잘 수 없이 뇌근육을 사용하며 전력질주 마라톤을 했던 기억이다.
당시 병원검사에서는 대장 용종이 몇 개 발견되었고
의사 왈, 젊은사람이 왜 벌써 용종이 나오는지 의아해 했다.
엄청난 스트레스와 야근으로 몸이 나빠진건 당연할거로 생각됐으니 내 생각에도 이상하진 않을정도였다.
