이력서 지원 시작, 독서: 소프트웨어 가치와 비용, 기존 이슈 작업 시작 및 신규 이슈

오늘은 프로젝트보다는 이제 이력서를 완성하고, 이력서를 드디어 지원하기 시작했다. 이전 노션으로 작성한 내 이력서를 PDF로 출력하는 과정에서 문제가 있었는데, 해당 문제를 약간의 꼼수(?)를 활용하여 완성하였다. 이력서를 완성하고, 이젠 지원 및 기업조사를 하는데 많은 시간을 소요할 것 같다. 그리고 오늘 대부분의 시간은 기업 조사 및 지원을 하는데 많은 시간을 소모했다.

 

이렇다고해서 (시간이 조금 줄긴했지만..)하루 루틴을 지키지 않은 것은아니다.. 오늘은 육각형 개발자를 독서했다. 오늘 독서한 부분은 양이 그렇게 많지는 않았지만, 과거 회상을 불러 일으키는(?) 내용들이었다. 하지만 과거만 떠올리는 것이아닌 미래도 그려볼 수 있는 그런 내용들이었던 것 같다.

---

독서: 소프트웨어 가치와 비용

오늘 독서는 육각형 개발자의 3장 소프트웨어 가치와 비용 및 4장 코드 이해 를 읽었는데, 그 중 기억에 남는 3장을 기록으로 남겨보려고한다.

 

소프트웨어의 가치에 관해 나는 어떤책인지 정확하게 기억은 나지 않지만, 행위가치와 구조 가치에 대해 이야기했던 것이 기억이 난다.

• 행위가치:소프트웨어의 주요 기능측면에서 나타나는 가치를 의미하며, 주요 목적을 달성하기 위해 중요하다.
• 구조가치: 소프트웨어 내부 구조와 관련이 있으며, 소프트웨어가 장기저긍로 유지 및 관리되고 발전하는데 중요한 역할을 담당한다.

 

그리고 두 가치 모두 중요하지만, 굳이 더 중요한 것을 이야기한다면 구조가치가 더 중요하다고 했던 것 같다. 그리고 나또한 구조가치가 더 중요하다고 생각한다. 왜냐하면, 내가 생각하는 행위가치는 마치 소프트웨어를 출시하는 것과 같다 생각하기 때문이다. 그런데 소프트웨어는 출시에서 끝이나는것이 아니라, 출시에서 시작하기에, 비교적 행위가치 보다는 이를 계속해서 발전시킬 수 있는 가치인 구조가치가 더 중요하다 생각한다.

 

그래서 나는 기능 개발보다는 소프트웨어 유지보수에 좀 더 많은 관심과 공부를 하기 시작했고, 지금은 코드 설계와 아키텍처구조에 관심이 많다. 이래서인지, 이번 3장의 소프트웨어 가치와 비용 부분이 좀 더 재밌게 읽혔던 것 같다.

 

소프트웨어 유지보수는 이전과 동일한 동작을 유지하는 것이 아니다. 변화하는 세상에서 유용함을 유지하는 것이다. - 제시카 커 -

 

---

지난 회사에서 담당한 프로젝트에 대한 회상

 

책을 보다보니 나는 자연스럽게 지난 회사의 프로젝트가 떠올랐다. 지난 회사의 프로젝트는 흔히들 말하는 레거시 프로젝트였다. 레거시를 정의하는 다양한 의미들이 존재하지만, 내가 생각하며 말하는 레거시는 어떠한 다양한 이유로 수정하기 어려운 프로젝트를 레거시 프로젝트라고 생각한다.

 

내가 담당했던 프로젝트는 2018년에 대개편이 한번 이뤄졌었다. 이말은 즉슨, 2012년에 창립된 이후, 6년만에 리뉴얼이 진행되었다는 말이다. 그렇다면, 2018년 리뉴얼 이후, 해당 프로젝트는 레거시 프로젝트를 벗어났을까? 아니다. 내가 본 프로젝트는 2014년과 2018년 사이에 여전히 머물러있다. 여전히 브라우저 종속성을 해결하지 못했고, 여전히 사용 언어의 버전은 2018년 리뉴얼 당시 이후, 단 한번도 버전 업데이트가 되지 못했다.

 

회사 입사 당시, 주요 업무는, 이미 개발된 기능들이 많아 해당 기능들을 유지보수였다. 그리고 나는 유지보수 업무를 나름 잘(?)하기 위해 코드를 열심히 분석했던 기억이 난다. (그리고 이것이 내 코드설계를 공부하고, 아키텍처를 공부하게 된 시작점이다.)

 

유지보수 업무(당시, 코드분석)를 진행하면서 나는 많이 불편한 점이 많았다. 왜 이렇게 되어있지? 혼자서 코드를 분석하면서 이 코드가 작성된 배경을 알지 못하고서는 이해할 수 없는 코드가 즐비했다. 다행인지 불행인지, 해당 개발을 처음부터 끝까지, 또는 해당 기능을 자기가 직접 수정한 사람이 바로 옆에 있었기에 물어보며 그 답을 얻을 수 있었다. 그리고 나는 질문을 하는 횟수가 많아지면 많아질 수록 리팩토링에 대한 욕구가 솟구쳐올랐다.

 

하지만 리팩토링은 쉽지않았다. 가장 큰 이유로는 테스트가 없었다. 단위테스트를 작성하기에는 분리되지 않은 하나의 큰 덩어리 메서드였고, 또 데이터베이스 중심의 유스케이스 구현으로 인해  단위테스트는 DB와 함께 진행하는 통합테스트가 되었다. 하지만 가장 큰 문제는 우리 프로젝트는 로컬에서 실행이 안됬다.

 

그 당시 프로젝트 설정은 모두 컨테이너 개발환경으로 Dockerfile 을 통해 필요한 종속성을 설치하고 사용했다. 사용하는 라이브러리는 모두 추출해서 로컬 가상환경에 설치를 하려고했지만, 우리가 사용하는 버전을 파이참에서 설치할 수 없었고, 다른 버전을 사용하니 호환성 문제가 생겨 할 수가 없었다. 사수님은 단위테스트 작성은 불필요한 일이라고 생각하는 사람이었기에 도움을 받을 수가 없었다..

 

하지만 나는 포기하지 않고 E2E 테스트 처럼 기능을 테스트 했고, 로직을 리팩토링했다. 그런데 이 과정은 그리 오래 지속되지 못했다. 그 이유는 결국 리팩토링을 하기에 엄두가 나지 않았기 때문이다. 시간도 정말 많이 소모되었고, 눈치도 받고, 시간도 정말 사용하고, 무엇보다 단위 테스트 없이 이 리팩토링에 대한 내 확신이 들지 않았다.

 

이야기가 길어졌는데, 내가 하고 싶은 말은 유지보수의 가장 기본이 되는 리팩토링의 비용이 정말 많이 들었으며, 신규 기능 추가는 말해뭐해였으며, 유지보수 비용을 줄일 방법을 찾지 않았다는 것이다.

 

 

---

유지보수 비용을 낮추는 방법

 

그렇다면 유지보수 비용을 낮추는 방법은 무엇일까? 먼저 내가 생각하는 유지보수 비용을 낮추는 방법은, 코드 품질을 높이는 것이다. 그리고 코드 품질이라함을 가장 쉽게 이야기할 수 있는 단어는 클린코드 라고 생각한다. 클린코드는 사람마다 다르게 생각할 수 있지만, 가독성과 유지보수성이 높은 코드라고 이야기할 수 있을 것 같다. 이것으로 이야기하면 오늘 잠을 정말 늦게 잘 것같기에... 이건 따로 정리해야할 것 같다.

 

선택에 따른 이로운 점과 불리한 점을 따져 우리가 만들고 있는 소프트웨어의 가치를 안정적으로 높일 수 있는 안을 선택해야한다. - 책의 일부분-

 

책의 내용을 이야기해본다면, 코드 품질은 유지보수 비용에 큰 영향을 준다고 한다. 그리고 다양한 프로그래밍 패러다임을 적용하는 방법, 코드 설계, 아키텍처 설계 등을 통해 유지보수 비용을 낮출 수 있다고 한다. 이렇게 보면 나는 내가 가고자하는 방향으로 잘 가고 있는 것 같아 기분이 좋았다.

 

앞으로 가야할 회사에서는 이 문제들을 많이 고민하고 또 해결해 나갈 수 있었으면 좋겠다.

 

---

기존 이슈 작업 시작 및 신규 이슈

 

처리되지 않은 이슈들

원래는 한참 전에 해결이됬어야하는 이슈들인데 아직 해결이 되지 않은 이슈들이 존재한다. 예상치 못한 다른 개발일정들에 밀려, 처리하지 못했다.(변명) 이 이슈들은 가능한 빨리 다음주 내로 처리를 할 수 있도록 노력해볼 계획이다.

 

그리고 새로운 이슈를 등록해야한다. 어제 작업하던 내용을 바로 Main 브랜치에 반영하기보다는 하나의 이슈로 작업하고, 기록을 남기는 것이 좋을거라는 생각이 들었기 때문이다.

 

할게 정말 많은데, 나는 점점 게을러 지는 것인지.. 능력이 떨어지는 것인지.. 마음이 급해진다..

---

이제 이력서를 넣기 시작하면서, 다시 새로운 프로젝트를 할 때처럼 설렌다. 비록 면접이지만, 다른 개발자들을 만나 개발 이야기를 할 수 있다는 점에서 특히 설레는 것 같다.

 

하지만 이를 위해서는 진짜 정신 붙잡고, 여렇 일정들을 잘 관리하고 더 부지런하게 움직여야한다. 다른 것말고, 내일은 오늘보다 더 부지런한 내가 되는걸 목표로!!