이번에도 또다른 KT 프론트엔드 프로젝트의 소방수로 프로젝트를 진행하게 되었다.

이번엔 재택이라 소방수든 아니든 상관없이 충분히 프로젝트 수행이 가능할거로 봐서 진행했다.

기존에 진행해오시던 개발자분께서 JAVASCRIPT 의 특정 기술을 적용하지 못해서 어떤 특정 기능 구현이 안돼고 있는 상황이라 중간에 나에게 인수인계해주고 나가게된 상황이었다.

KT 프로젝트이면서 막바지 프로젝트긴 했지만 예상과는 다르게 시간을 충분히 여유롭게 줬던 프로젝트였다.

프로젝트 중간에 이야기를 들어보니 , PM님왈, 엄청 그렇게 시간이 빡빡하지는 않은 프로젝트라는 말로 나를 안심시켜줬고 .

다행히 화면 본수가 좀 되었지만 재택이라면 좀더 효율이 좋은 관계로 프로젝트를 완수 할 수 있게 되었다.

막바지 프로젝트 였음에도 많은 크리티컬한 이슈가 없이 원활하게 프로젝트는 마무리 되었다. 

프로젝트 성공의 요인으로는 이 프로젝트에 투입된 인력이 많았고 ( 퍼블리셔 분 따로 있었고 백엔드 개발자분 들 따로 계셨고 인력풀이 어느정도 구축되어있었다 )

PM 님이 수행 회사의 이사님이라 중간에서 조율하는데 토다는 사람없이 커뮤니케이션이 원활했다.

또한 애초에 프로젝트 수행 견적기간을 잘 뽑아서 기간이 충분했다.

물론 나는 프로젝트 막바지 2개월만 참여했지만 말이다.

프로젝트는 기존 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달 넘게 했던 그 프로젝트에 비해서는 괜찬았다.

코로나가 한창이던 시기 배달의 민족 프로젝트에 SI 로 들어가서 프로젝트를 하게 되었다.

조직문화 를 전문으로 관리하는 팀이 있어서 그런지, 분위기가 뭔가 수평적이고 좋았다.

( 수직적이고 명령조로 평소 일했던 사람이라면 일하기 어렵지 싶은 분위기였다. )

일하는 사람끼리의 커뮤니케이션은 슬랙 을 주로 사용했고 AWS 운영서버에, 젠킨스 빌드 배포 환경이었다.

보통의 SI 프로젝트와는 다르게 딱 고정된 장소에서 일해야하는건 아니라서 회사 건물 어디든 가서 일할 수 있었던게

일에 집중도 잘되고 일의 효율이 좋았다, 나중에는 코로나 때문에 거의 재택으로 일했었다.

프로젝트는 배민이 아닌 다른 수행회사에 소속되어 그회사의 다른부서 팀과도 함께 진행했는데 , 수행사 PM 님이 중간에 다른팀까지 협조를 구하느라

애를 먹고계셨다. ^^ , 나도 괜히 관련해서 좀 안다는 이유로 회의라고는 하나 싸움판인 싸움에 끼여서 싸우는데 중간에 끼여서 ... 헉스 힘들었다. 풀스택 으로 개발을 해본 입장에서 혼자 전체를 구현하는게 훨씬 편하겠다는 생각이 들었다. 괜히 클라이언트 앱 , 백 서버 나뉘어 있는데다 클라이언트 앱측 개발하는 수행사 측팀은 클라이언트 개발하는데 맞춰서 우리 요구사항대로 API 만들어 주라는 식으로 강압적으로 굴려고 하는거 같은데다 뭐로 개발하는지 스펙도 비밀이라고 안알려주고 요구사항도 정확하게 요청하지 않고 어림잡아 요구했다가 구현해주면 이게 뭐냐는 식으로 싸우자고 대드는 태도로 인해 더 난감했다.

백그라운드쪽 담당 수행사 차장님에게 이야기한 내용은, 저쪽팀은 무슨 회의를 저렇게 싸우자는 식으로 하는건지... 이래서... 일이 될지 차라리 관두겠다고 이야기 했다가 . 지금나가면 내쪽 업무는 다 갈아엎고 처음부터 다시 개발해야하는데 기간상 불가능해서 프로젝트 타격이 엄청나다고 부탁을 해서 그냥 있었다. ㅎㅎ

뭔가 또 반전인게 나중에는 수행사쪽 클라이언트 구현팀 쪽에서 공통쪽 SSL 처리하는 부분에서 막혀서 뭐가 안되는데 어떻게 해야하느냐고 SI 프리로 들어간 나에게 문의를 해왔다. 이 뭔 ... 이전에 싸우자고 대들더니 문의는 해오고... 암튼 프로젝트 전체 를 한번 경험해 봐서 공통쪽 SSL 모듈을 해결해주게 되었다.

또 한번의 고비는 프로젝트 막바지에 가서 UPDATE 나 INSERT 시 WHERE 절에 RANGE 타입의 조건을 걸어서

같은 테이블에 여러 업무에서 CUD 를 하면 테이블락으로 관련 서비스들이 일부 처리되지 않는 버그가 도처에 깔려있었다.

위의 에러로 인해 나에게 직접 연락오지는 않았지만 다른팀들은 이 껀으로 인해 이슈 되서 뭔가 싸움판이 될뻔했던거 같다.

프로젝트는 막판에 내가 보기에 뭔가 쪽나는것처럼 싸움판이 될뻔했던거 같기도 했다.

그래도 이 사항을 먼저 발견해서 알려주고 프로젝트 막바지에 급하게 이팀 저팀들 전부 쿼리들을 고쳐서

그래도 프로젝트는 잘 마무리 되었고 서로 평화롭게 끝나게 되었다.