Day 089 - Spring 심화 프로젝트 3단계 및 4단계 완료, 단순한 개발자가 아니라 창작자가 되고 싶다.

1. 프로젝트 진행 상황 및 계획[깃허브 링크]

🥇 Spring 심화 프로젝트 도전 과제 5단계 끝내기 (진행 중, 25.01.04 완료 목표)
🥈 Spring 심화 프로젝트 필수 과제 2단계 끝내기 (진행 중, 25.01.04 완료 목표)

🥉 Spring 심화 프로젝트 도전 과제 6단계 끝내기 (진행 중, 25.01.05 완료 목표)
4️⃣ Spring 심화 프로젝트 도전 과제 3단계 끝내기 (완료)

5️⃣ Spring 심화 프로젝트 도전 과제 4단계 끝내기 (완료)

 

2. 고민

Q1. 중복 코드는 왜 문제일까? 

A1. 중복 코드를 한 군데에 모아두면 그 부분만 고치면 되는데 방치하면 일일이 고쳐야 한다. 그 과정에서 시간도 오래 걸리고 수정할 부분을 빠뜨린다든지 잘못 고친다든지 인적 오류(휴먼 에러, human error)가 발생 가능성이 아주 높아진다. 예를 들어 중복 코드를 방치한 상태로 원래 오류 메시지가 'User is not found.'이었는데 기획이 바뀌어서 '사용자가 조회되지 않습니다.'로 고쳐야 한다면, 골치 아파질 수밖에 없다. 코드를 처음에 봤을 때 이해하는 데엔 걸리는 시간이 없어야 한다. 그런 의미에서 중복 코드 제거는 매우 적절한 작업이다.

 

Q2. '진짜 중복'과 '가짜 중복'의 차이는?

A2. '가짜 중복'이란 '현재는 겹치지만 앞으로 달라질 가능성이 아예 높은 중복'을 의미한다. 예를 들어 CreateRequestDto와 UpdateRequestDto가 있으면 처음에는 값이 똑같으나 점차 값이 달라진다. 이럴 때는 중복된다는 이유로 당장 제거하면 안 된다. '진짜 중복'이란 기능 하나를 추가했을 때 추가해야 할 부분이 두 군데 이상일 때를 의미한다. 처음에도 동일하고 앞으로도 변하지 않는 중복 코드가 진짜 중복이다. 진짜 중복은 하나만 수정하면 되는 코드를 여러 번 고쳐야 하므로 실수를 줄이고 시간과 인적 자원을 절약하려면 제거하는 편이 좋다.

 

3. 창작자가 되려면 어떤 고민을 해야 할까? 

 

“어떤 기능을 사용자에게 제공해야 할까?”

 

“어떻게 하면 좋은 서비스를 제공할 수 있을까?”

 

“우리가 제공하려는 가치를 고객이 제대로 경험하게 하려면 어떻게 해야 하지?”

 

“고객의 어떤 불만을 해소할지 기획 초기에 확실하게 잡고 가야 한다. 사용자에게 제공하려는 핵심 가치 하나를 딱 정한 다음, 다양한 기능이 붙어야 한다.” 

 

“구조 개선이 매출에 직접 영향을 끼치지 않으므로 설득하는 힘이 필요하다.”

 

"다른 서비스와 차별화할 만한 부분이 뭐가 있을까?”

 

4. 회고

"코드에서 많은 고민과 철학이 보이네요."

 

글과 마찬가지로 코드에 '나 자신'이 묻어났다는 말은 언제 들어도 늘 신기하다. '많은 고민이 보인다'라는 말에 정말 공감이 갔다. 무언가를 수정하는 메서드(method) 이름 하나를 지을 때도 'update', 'modify', 'edit', 'change' 중에 뭘 쓸지 고민했으니까. 사소하지만 헷갈리고 오타가 나기 쉬울 듯해서 알파벳 L이나 I가 여러 개 들어간 단어는 최대한 쓰지 않으려고 했으니까. 

 

도전 과제 마지막 단계는 '앞서 제시된 기능 말고 스스로 문제를 정의하고 해결하기'였다. 요구 사항을 읽으면서 이 과제를 할 때 어떤 고민을 해야 좋을지 꽤 오랫동안 생각했다. 기획자까지는 아니더라도 무작정 코드를 작성하기보다는 어떻게 하면 더 나은 서비스를 고객에게 제공할 수 있을지 고민하는 창작자가 되어야겠다고 다짐했다. 이런 마음가짐이 들어야, 개발자가 되겠다고 적지 않은 시간과 노력을 들인 만큼 건강하게 오래 일할 수 있을 듯했다.

 

마침 도서관에서 빌린 팀장 관련 책도 다 읽어서 반납할 예정이겠다, '기획' 관련 책을 한 권 빌려서 읽어보련다. 어떤 글이든 기획할 때마다 창작의 고통을 겪으면서도 즐거워한 지난날을 떠올리면서, 창작자로 거듭날 수 있도록.