[ WIL ] 1-4 리뉴얼 및 리팩터링 프로젝트 진행의 난항, API 개발과 성능 최적화 강의 완강 및 후기, 내가 생각하는 개발과 올해 개인 OKRs

벌써 1월의 마지막을 향해가고 있는데, 1월달의 첫 WIL 이라니.. 스스로 반성을 하게 되는 지금이다.. 지난 1~3주차 동안에도 역시나 정말 많은 일들이 있었다. 그 중 가장 중요한 이벤트는 내 앞으로의 처우에 대한 내용이 아닐까 싶다. 이 부분은 인턴 계약 종료 3일전에 이야기를 들어보게되었는데, 정말 개인적으로 많이 아쉽고 화가 나는 부분이다. 자세한 내용은 본문에 한번 작성을 해보도록하고, 지난 3주간 큰 일들을 정리해보면 다음과 같다.

 

• 리뉴얼 및 리팩터링을 위한 테스트 작성과 CI 구축 에서 다시 처음으로
• 스프링부터와 JPA 를 활용한 API 개발과 성능 최적화 강의 완강 및 후기
• 다시금 생각해보는 내가 생각하는 개발에 대하여

 

 

---

리뉴얼 및 리팩터링을 위한 수 많은 준비와 액션 이후 다시 처음으로

 

지금 회사에 입사를 한 23년 11월 28일 입사 이후 지금까지 정말 난항이 많았다. 사전에 이야기된 업무를 진행하는 것이아닌 전혀 다른 업무를 진행하게된 것, 인턴이라는 직책에서 갑자기 핵심 프로젝트의 리뉴얼을 주도하게 된 것(이것도 우여곡절이 정말 많았다..), 잘 진행되는 줄 알았는 평가에 대해서, 정규직 전환 직전(3일전) 갑자기 모든 과정과 이야기를 번복하는 경험 등등 내 스스로 돌이켜보니 정말 어이없는(?) 경험들의 연속이었던 것 같다. 

 

개요

나는 현 회사에 지인의 추천으로 면접을 진행하고, 정식 입사를 하게 되었다. 다만 입사를 하는데 있어 서로 오해한 부분(이것도 지금 생각해보면 정말 말이 안되는 부분이었다. 정규직을 인턴으로 생각한다는게 말이 되는가..) 수습기간을 인턴으로 대신하며 다만 기존의 수습 3개월을 2개월로 줄여서 한다는 조건 하에 정식 입사를 하게되었다.

 

애초에 내 성격이 알려줘야만, 시켜줘야만 움직이는 성격이 아니기에, 별 말 없이도 혼자 주도하여  프로젝트를 분석하고 궁금한 내용을 정리하여 질문하며 입사 초기 시간을 보냈다. 이 작업은 내가 맡아 진행하게될 프로젝트를 진행에 도움이 될 것이라 생각했기에 스스로 주도적으로 더 움직인였던 것 같다. 하지만, 상황을 파악하면 할 수록 내가 하는 프로젝트의 목적과 이유가 불분명해졌다. 입사 이전 이야기 하고 예측했던 상황과는 정말 많이 달랐고, 현재 프로젝트 상황을 고려할 때, 내가 담당하게될 프로젝트를 따로 분리해서 개발하는 것(사전에 이야기 된 내용)은 장점은 없고, 손해만 존재하는 상황이었다. 

 

이와 관련하여, 백엔드를 담당하는 사람들과 이야기를 나눴고, 다른 개발자와 팀장은 그렇다면 개선점을 이야기하고 해결책을 제안하고 있는 내 상황(난 프로젝트를 분석하고 질문했을 뿐이였다..) 을 현재 진행예정인 프로젝트 리뉴얼과 리팩터링에 참여해보는 것은 어떻겠는가? 를 제안했고, 나는 고민을 하다 이를 받아들였다.

 

 

리뉴얼 및 리팩터링 진행

나는 이렇게 프로젝트 리뉴얼 및 리팩터링 프로젝트에 참여하게 되었다.  리뉴얼 및 리팩터링 프로젝트는 양날의 검이었다. 프로젝트에 대한 이해 없이는 진행할 수 없다는 점이 내겐 가장 큰 도전 이었고, 리뉴얼 이라는 주제의 프로젝트는 개인적으로 가장 해보고 싶던 업무이었기에 시작하는데 있어 (큰)기대 반 걱정 반이었다.

 

프로젝트를 이해하고 업무 속도에 맞추기 위해 정말 많은 노력을 했다. 내가 부족했고 알고싶었기에.. 야근은 물론이었고(하다보니 야근이 되어있었다.) 모르는 내용은 정리해서 해당 담당자에게 찾아가 물어보고 상황과 문제점 그리고 지금 진행을 하기 위해 필요한 것들을 준비했었다. 그리고 이 과정은 정말 순탄하지 않았다.(정말로...)

• 기존에는 이미 1차 리뉴얼이 진행되었는데 목적 없이 개인적인 주관에 맞춰져 이뤄진 상태였다.(=기획없이 자기가 맘에안들어서 바꿨다.)
• 작성된 문서가 존재하지 않았다. 해당 기능 개발의 목적과 배경을 이해하기 위해서는 이해관계자를 찾아가야 했다.
• 개발 협업하는데 있어, 협업 툴(Github)에 대해 다들 익숙하지 않았다. Branch 전략, Issue, PR 을 사용하고 있지 않았고 할줄 모르는 상황이었다.
• 기능을 리팩터링하는데 있어 기존 동작을 대체함을 검증할 수 있는 테스트가 존재하지 않았다. 그리고 A 리팩터링 작업이 진행되었을 때 이후 B 리팩터링 작업 이후 A 작업이 영향을 받지 않는 다는 검증 (CI;Continuous Intergration) 이 없었다.
• 기본적인 아키텍처에 대한 구조가 없고 설명할 수 있는 사람이 없었다. 그저 우린 MSA 로 갈거야! 라는 말만 반복.. 혹은 모듈화를 진행할거야.. 만 반복하는 상황이었다.

 

이에더해 소프트웨어 팀은 1월 CES 로 인해 나만 남겨둔채 8일 간 회사를 떠났다. 분명 떠나기 전, 피드백에 대한 형식을 정하고 약속을하고 떠났건만, 이는 전혀 지켜지지 않았다.

 

그래도 내가 해야 할 부분들은 분명했다.  나는 리뉴얼 및 리팩터링의 목적을 설정하고, 이에 맞는 전략을 세운 뒤, 이를 빠르게 진행하면 되는 것이었다. 그리고 하나씩 해결해 나갔다.

• 단순 모듈화를 진행한다는 말이 아닌, 어떤 아키텍처 특성을 위해 모듈화를 진행하는지를 분명하게하고 해당 목적을 충족시킬 수 있는 내가 생각하는 가장 효율적인 방법을 제안했다.
• 단순히 Github 에 코드만 올리는 것이 아닌 효율적으로 이를 사용하기 위해, 해야할 업무(Issue)를 정의하고, 작업한 업무에 대하여 서로 리뷰를 거치는 과정(PR) 을 정의하여 기존의 문제점(코드 로직을 작성한 사람만 알고 있으며, 사전 버그 예방 미비, 개인 별 Issue 를 정의하는 것이 다름)을 개선하고자 하였다. 그리고 이 과정에 있어 가장 큰 어려움이 될 작성과 관련하여 템플릿을 제안하고 이를 통해 진입 허들을 낮췄다.
• 현재 프로젝트 분석 간 다양한 버그와 에러가 발견되었는데, 이를 탐지하고, 코드 로직의 에러의 사전 탐지 및 기존 동작에 대한 정상 작동을 검증하기 위한 테스트 작성의 중요성에 대한 이야기 및 이를 바로 적용할 수 있도록 CI(Git Action Script 활용)을 하였다.
• 개인적으로 프로젝트를 이해하기 어려웠던 이유는 너무나도 주관적인 아키텍처 구성으로 인한 프로젝트의 파악이 되지 않았다는 것이다. 이를 개선하기 위해 현재 시스템의 개발 진행상태를 고려하여, MVC 아키텍처를 제안하였고, 미래의 목표(MSA)를 고려햐여 내부 패키지 구조 설계를 도메인형으로 묶어 구성하였다.
• 문서 작성적인 부분에 대하여, 기록이 될 수 있는 ADR(Architecture Decision Record) 에 대한 제안과 작성 가이드를 제안했다.

 

해당 작업들은 모두 병렬적으로 이뤄졌다. 프로젝트를 이해하면서, 각각의 작업과 문서로 기록을 하는 것은 정말 시간과의 싸움이었다.  그래도 하나하나 진행하다보니, 이제는 코드 수준까지 고려하며 이야기 할 수준까지 올 수 있었다.

 

 

갑자기 다시 처음으로

저 작업들을 하는데 약 한달이라는 시간이 소요되었다. 이 모든 작업은 주도적으로 미팅을 잡고 함께 이야기하며 정하면서 나아갔었다. 그런데 1월 초 CES 를 떠나기 전, 갑자기 다시 요구사항 정의를 하는 것을 진행하게되었다. 정의도 아닌 이해를 하는 것을 진행하여 정리한 것을 보고싶다고 했다. 몹시 당황스럽긴 했다만, 내겐 그런 당황할 시간도 아까웠고, 당장 내일 떠나는 인원들에 대해서 무엇을 원하는 것인지, 무엇을 확인하고 싶은지를 분명하게 확인을 하고자 했다. 그리고 이 작업은 또 다시 2주간 진행했다.

• 리뉴얼 프로젝트의 요구사항 정의, 품질요건 정의 를 거쳐 이제 Data Flow 를 정의하던 중 발생했다.
• 해당 요구는 내가 로직을 제대로 이해하고 있는지 보고싶고, 이를 문서로 남기고 싶다고 했다.
• 나는 코드로서 계속해서 전체적인 흐름과 어떤 기능이 필요한지 나열하고 이를 클래스로 묶어 작업을 진행하고있었는데 이것이 아닌, 실제 우리 프로그램을 사용한다는 사용자 입장에서의 분석을 원했다.

 

그리고 나는 이를 진행했다. 오히려 어쩌면 코드를 분석하며 진행할 내용을 분리해서 시간을 준다고하니 나는 오히려 좋았다. 좀 더 자세하게 파고 들고, 분석과 해결책에 대한 고민을 동시해 할 수 있었다. 계속해서 상황을 공유하고 피드백을 요청하기도 했고, 다른 부서의 동료들에게도 물어보며 앞으로 점점 나아가고 있다고 생각했다. 그러나 정규직 전환 3일 전, 갑자기 일방적인 인턴 연장을 이야기했다.

 

그 이유는 지난 상황은 모르겠고, 내가 원하는 결과물을 못보면 안된다라는 기준 때문이라고 한다. 지금까지의 상황에서 이 기준이 합리적이지 못하는 것도 이해한다는데, 일방적으로 이야기를하고, 이야기를 진행함에도 절대 생각의 변화는 없음을 표현했다. 이 과정은 결국 진정으로 맨처음으로 다시 돌아가게 된 것이다. 이 사람이 원하는 것이 무엇이지 계속해서 물어오고 이를 스무고개처럼 맞춰가고있었는데, 진짜 내가 생각한 정답은 다른 것이라고하니; 정말 화도 많이 나고 어이가 없었다.

• 자신은 프로젝트의 핵심로직을 내가 새롭게 작성할 수 있는지가 궁금하고 이를 보고싶다.(진작에 이야기하던가;)
• 핵심 로직을 작성하고 핵심 로직을 이용하는 모든 유스케이스에 대한 테스트코드를 작성해달라.

 

요구사항은 내가 못해낼 것이라는 생각은 안한다. 얼마나 어렵고 오래걸리든 정해진 시간내에 해낼 자신이 있다. 다만 이 과정이 너무나 합리적이지 못하고 윤리적이지 못한 것이라는 생각이 들어 이야기를 많이 하며 내 시간을 쏟았다는 것이 지금도 화가 난다.

 

이 후, 인사 담당자 및 대표와 이야기를 나눴고, 나는 지금 솔직하게 이곳에서의 미래가 상상이 되질 않는다. 결국 자기가 원하는대로만 할것이며, 평가는 모두 자기 고집대로 간다는 것이 이곳에서의 미래를 모두 지워버리는 것 같다. 일단 2월까지의 계약은 끝 마무리를 위해 진행한다고 했는데, 진지한 준비를 해야할 듯하다.

 

무튼 그래서 나는 약 1일정도의 개인 업무시간이 주어졌는데, 테스트 작성을 효율적으로 하기위해 TestMother 를 중심적으로 먼저 개발했다. 아직 원하는 Input 데이터를 손쉽게 만들어내는 것까지 만들어내지는 못했지만, 그래도 거의 다 완성이 된 것 같다. 이것이 완성되면, 이제 테스트 코드를 작성하며 원하는 코드를 작성해 낼 수 있을 것 같고, 기초 작업은 설 전까지 해보려고 한다.

 

---

스프링부터와 JPA 를 활용한 API 개발과 성능 최적화 강의 완강 및 후기

 

갓영환 선생님의 JPA 강의를 완강했다.

 

Java 를 공부하면서 개인적으로 가장 공부해보고 싶었던, JPA 에 대한 공부를 해당 강의를 공부하면서 많이 공부해 볼 수 있었다. JPA 를 공부하기 전에는 ORM 이 거기서 거기 아냐? 그냥 쿼리 작성하고, 쿼리작성하면서 문제가 생길 수 있는 부분은 N+1 이전부일테니깐 크게 어렵지 않을거야. 라는 생각을 갖고 있었는데, 이번 강의를 공부하면서 나의 안일한 생각을 고칠 수 있었다.

 

 

나는 Python 를 사용하는 Django 를 사용하면서 ORM 을 처음 알게 되었다. ORM 은 기능을 만들고 사용하는 것은 쉽고 유용했다. 하지만 사용 간 직면하게 되는 다양한 이슈(Lazy, Eagger Loading, N+1 Query 문제 등)이 많았다.와 관련하여 이야기(꿀팁..)를 듣고 싶은 욕구가 컸었다. 그러나 Django ORM 와 관련된 강의는 없었고, 나는  다른 ORM 을 통해 해당 이슈를들 공부해 볼 생각은 해보지 못했다. 그저 직접 경험해보는 문제들만 해결하는 것이 전부였다.

 

그리고 시간이 흘러 지금, 나는 Java 와 Spring 을 활용한 서버 개발에 관심이 많아졌고, 이번 강의를 통해 욕구를 해소하는데 큰 도움이 되었던 것 같다.

 

새롭게 알게된 내용

강의에서는 API 의 버전에 따라 사용하는 방법이 다른데, 각 버전별 문제점을 언급하고, 다음 API 버전에서 이전 버전에 대한 문제점을 개선해 나간다. 그리고 이 최적화를 하면서 아직 경험해보지 못한 문제에 대한 인지와 해결책들을 공부할 수 있었고, 정리해본다면 다음과 같다.

• 엔터티를 직접 노출하는 것은, 엔터티가 변할경우 API 스펙이 변경된다는 것과 같다.
• DTO 를 통해 API 스펙을 지정할 수 있다.
• JPA 에서 FetchJoin 을 통해 쿼리를 최적화(1+N 쿼리 문제 해결)을 하는 방법은 offset, limit 을 통한 페이징이 불가능하다.
• ToOne 관계는  FetchJoin 을 통해 최적화를 진행하고, Collection 은 지연로딩을 유지하나, batch fetch size 혹은 @BatchSize 를 통해 최적화한다.

 

이외에도 최적화를 진행하는 순서, 엔터티 조회방식을 우선시 하는 이유 등 정말 꿀팁들이 많았다. 이번 강의 공부를 통해 특정 언어에 한정된 내용 뿐만아니라, 공통적인 개발에서도 적용될 수 있는 내용들을 공부할 수 있어서 특히 좋았던 것 같다. 월급이 들어온다면, 다른 강의 QueryDSL,  JPA 활용1 편도 구매해보고 싶다.

 

---

다시금 생각해보는 내가 생각하는 개발에 대하여

 

 지금 회사에서의 팀내 동료들은 내가 생각하는 개발과 다른 개발을 생각하고 있는 것 같다. 어떤 차이일까? 스스로 생각해보면서 내가 생각하는 개발에 대하여 많이 고민하게 되었다.

 

나는 개발은 문제를 해결하기 위해 존재한다 생각한다. 문제는 특정할 수 없고 예측 불가하다. 그러나 개발자는 어떤 문제든 해결해 낼 수 있는 사람이라는 것은 분명하다. 그리고 문제를 해결하는 과정에서, 두 종류의 개발자가 존재한다 생각한다. 첫번째는 기술 중심 사고를 통해 문제를 해결하는 개발자, 두번째는 문제 중심의 사고를 통해 문제를 해결하는 개발자 이다. 

 

기술 중심의 개발자

내가 생각하는 기술 중심 사고의 개발자는 특정 기술을 사용했더니 문제를 풀 수 있었어. 라는 사람을 기술 중심의 개발자라고 생각한다. 이러한 유형의 개발자는 기술에 집착(?) 하여 문제 해결에 최적의 선택을 하지 못할 가능성이 높다. 

 

문제 중심의 개발자

문제 중심의 개발자는 내가 이상적으로 생각하고, 내가 되고자 하는 개발자의 유형이다. 문제의 본질을 파악하고 이에 따른 최적의 기술을 사용하는 개발자이다. 불필요한 기술의 사용을 줄여 다양한 비용을 줄이고, 고객에게 가치를 제공할 수 있다.

 

그래서 내가 생각하는 개발은?

나는 앞서 이야기 한 것 처럼 문제 중심의 개발자이고 싶고, 문제 중심의 개발을 하고 싶다. 어떤 문제가 존재하고, 어떤 잠재적인 문제점들이 존재할 수 있는가? 를 중심으로 사고하고 행동하고자 한다. 그리고 다양한 문제들에 대해서 가장 중요한 문제는 바로 현재 직면한 문제라고 생각한다. 그래서 내가 생각하는 개발은 현재 문제를 해결할 수 있는 사람이자, 더나아가 잠재적인 문제를 예방하여 가치를 제공하는 것이라고 생각한다.

 

이번 회사에서도 마찬가지로, 사전에 이야기된 프로젝트를 진행하기 위해 해결해야할 문제, 직면한 문제점, 발생할 수 있는 문제점을 파악하고 이를 하나씩 해결해 나가고자 했다. 하지만 이는 얼마가지 못했다.

 

지금 회사에서는 고객 중심의 개발이라는 생각을 중심으로, 가장 중요한 현재 문제에 집중을 못하고 있었다. 당장 쳐내야 하는 문제를 쳐낸다고 하지만 그 문제가 발생하는 본질에는 관심이 없었다. 그래서 나는 현재 직면한 문제의 본질을 궁금해했고 해결하고자 했다.(물론 내게 주어진 업무는 하면서 말이다.) 하지만 오히려 나는 본질을 파악하지 못하는 사람이 되어있었다. 그리고 이것이 이번 불상사의 원인이라고 한다.

 

이번 경험을 통해 나는 내가 생각하는 개발과 이곳에서 생각하는 개발을 다시금 생각해볼 수 있는 좋은 시간이 되었다. 그리고 남은 한달 동안 잘 판단을 해야할 것 같다. 특히 내가 왜 입사 후 회사의 겉과 속이 달랐다 생각이 들었는지 에 대한 분석과 이것을 중심으로 이곳에서의 미래를 잘 결정해야겠다.