[독백] 첫번째 이직, 그리고 첫 프로젝트 후기.

 

 

 

꼭 이직하고 싶던 서비스기반의 회사의 입사후 첫 프로젝트에 참여하게 되었다!

 

* 혹시 모르니 업무는 비공개로 작성ㅎㅎ

 

맡은 역할은 조회API개발과 화면개발이었다.

(아무래도 신입에게는 조회가 크게 사고칠 일도 없고(?) 무난하다고 생각했다. 개인적으론 너무 역할이 작아서 아쉬웠다.. 더 역량을 뿜뿜할 자신있는대..)

 

현 회사의 레거시 시스템은 C#(Monolithic)으로 되어 있고, 현 시스템의 경우 JAVA(MSA)로 되어있다.

 

이번에 진행하는 프로젝트는 레거시 환경에서도 지원을 해야되기 때문에 C#까지 개발을 맡게 되었다(두둥, C# 1도안해봄)

 

레거시 시스템의 경우 2019년까지 없애는 것이 목표라고 한다...

 

레거시와 현시스템 시스템의 구조가 다르기 때문에 테이블도 물론 다르다.

 

외부 플랫폼에서 받은 등록 데이터 항목은 레거시 시스템과 현 시스템 모두 같기 때문에 시스템 별로 똑같은 테이블을 2개 만들지 않고

 

하나의 테이블에 모두 insert 하기로 하였다 (아래 사진처럼)

 

그래서 SP(스토어 프로시저)내에서 시스템을 구분하는 필드를 기준으로 분기처리하여 데이터를 조회하도록 했다.

 

 

WBS 개발일정을 보면 JAVA쪽 4일, C#쪽 4일이었다.

 

팀장님께서 WBS를 공유한 뒤 팀원들에게 일정조율 의견을 구했다.

 

나는 기획서를 분석해보니 JAVA쪽은 2일이면 충분 할 거 같다는 생각이 들었고,

(배포는 WBS일정에 맞춰서 배포했다)

 

그대로 진행 했다. 굳이 줄일 필요는 없기에 ㅎㅎ..

 

JAVA쪽은 2일(풀타임)만에 개발완료 하고 바로 C#공부를 했다. 그래서 실제로 쓴 리소스는

 

JAVA 2일 C# 6일정도 인것 같다. 처음 접해보는 언어라 막연한 두려움 때문에 프로젝트 기간의 주말에 초조했지만 

 

야근없이 일정을 준수하며 개발을 완료했다.

 

QA기간은 프로젝트의 성격에 따라 QA팀이 진행 할 때도 있고, 기획자들이 진행 할 때도 있다. 

 

그리고 나서 운영서버에 배포후에는 꼼꼼히 모니터링하는 작업까지 진행한다.

 

모니터링 같은 경우 Jennifer soft의 솔루션을 이용해서 진행 했고,

 

LOG는 Tomcat의 catalina.out을 열어서 보지 않고 Kibana를 이용해서 분석하였다.

(메모장에 기가 막히게 쌓인 LOG를 볼려고 고생할 필요가 없다.)

 

정말 신기한 기술들이 많았다.. 공부 할게 진짜 많다라는 생각이 들었다.

 

서비스기반의 회사들은 어떻게 프로젝트를 진행하는지 한 싸이클을 경험해 볼 수 있는 값진 경험이었다.

 

 

 

 

어려웠던점은

 

여기서와서 처음 사용해보는 Spring Boot, IntelliJ, 이슈트래킹 JIRA, Git, MSA, Kibana, C#등

 

생소한 것이 많아서 고생했다. 주말에 혼자나와서 공부하기도 했다. 

 

전에 있던 회사의 경우 너무 old한 방식으로 개발을 하지 않았나 싶다...

( Old하지만 조직의 규모에 맞게 빠르게 개발이 가능했다 )

 

(실제로 이러진 않음 ㅋㅋ 사수가 있긴 하지만, 업무처리 프로세스나, 팀내 Role 정도만 알려준다.  내 사수는 구글쌤이다.

지금 까지는 기술적으로 안풀리는 문제는 구글링으로 혼자 잘 풀어가고 있다. 전 회사는 이런 삽질을 많이 안했다. 혼자 30분 찾아서 해결 할 거 사수에게 물어보면 5분이면 해결이 가능하니까.. 많이 의지한 것도 사실이다.)

 

특히 어려웠던 점은 레거시 시스템을 개발할 때였다.

 

JAVA쪽 조회 API를 찔러야 하는대

 

레거시는 모놀리틱 아키텍쳐 구조였고,

 

API를 이용하지않고 바로 DB를 call하는 형식이었다.

 

회사 내부에서 참고 할 만한 소스가 없어서 구글링을 겨우겨우해서 개발했다.

 

삽질 한 부분은 C#에서 API통신을 할 때 비동기와 동기 방식 2가지가 있는대

 

c#의 비동기 flow를 파악하느라 삽질을 많이 했다..

 

 

 

 

 

좋았던 점

 

첫번째는

 

보통의 작은 시스템의 경우라면 혼자서 서비스단위로 한 사람이 CRUD를 모두 개발하지만

 

여기서는 등록, 데이터 집계, 조회, SAP데이터 전송, 각 담당하고있는 화면에 신규 프로젝트 서비스 요소 추가등으로 

 

굉장히 분업화되어 있었다. 그래서 맡은 역할은 적지만 코드의 퀼리티에 많은 신경을 쓸 수 있다는 점은 좋았다.

 

하지만 이방식이 운영업무적으로 좋지 않은게, 하나의 서비스 전체를 모두 알고있는 사람이 없다는 점이다.

 

아마 PM정도만 알고 있을 듯하다.

 

 

두번째는

 

회사의 배포 프로세스가 

 

LOCAL → DEV(개발서버) → QA(QA서버) → STG(스테이지서버) → PROD(운영서버)로

 

나누어져 있는대 운영환경에서 문제가 발생할 요소들을 각 단계에서 catch 할 수 있어서 

 

안정적인 서비스를 배포 할 수 있어서 좋았다. 

 

확실히 경험상 개발->운영 처럼 바로 배포는 위험하다고 느꼈다.

 

 

세번째는

 

LOCAL에서 개발을 완료후 DEV 서버에 Merge시에는 항상 PR을 날려야 한다. 

 

PR(Pull Request)을 날리면 리뷰어 담당자가 코드리뷰를 해준다는게 좋았다.

(회사 방침임)

 

만약 리뷰어가 바쁠시 다른 팀원들과 따로 코드리뷰를 한다.

 

코드리뷰는 안정적인 서비스 배포 + 주니어 개발자의 성장에 꼭 필요하다고 생각한다.

 

하지만 착각하지 말아야 할게 코드리뷰어의 수준에 따라 리뷰의 질이 많이 달라진다.

 

그리고 리뷰어의 피드백이 모두 정답은 아니라는 사실이다. 

 

리뷰어도 본인의 코딩스타일 대로 피드백을 주기도 하기 때문이다.

 

그래서 너무 맹신하면 안된다.