[MainProject D+7] 상시 멘토링 회고(?)

💡 오늘의 회고는 일기형식에 가깝다.

메인프로젝트를 진행한지 벌써 7일차에 접어들었다. 지난 수요일 팀이 결정되고 일요일까지 우리는 열심히 기획을 했었다. 사용자 요구사항 정의서도 작성하고 코드 컨벤션도 지정했다.

그리고 월요일에 우리는 사용자 요구사항에서 우선순위를 지정해 분리하고 1순위에 해당하는 우선순위들만 ERD테이블을 작성하고, API명세서를 작성했다.

그리고는 멘토링때의 조언으로 추상화 작업을 먼저 실행한 후 구현화 작업을 진행하기로했다.

추상화를 먼저 진행하는 방식은 매우 생소했고 우리는 갈피를 잡지 못했다. 그래도 나름 회의 이후에 작업 워크 플로우를 세워봤는데 우리가 생각한 선 추상화 후 구현화는 다음과 같았다.

1. 1차 우선순위에 해당하는 기능 구현에 필요한 인터페이스 작성 및 erd작성
2. 추상화 -> 구현화 작업(작성한 인터페이스 바탕으로 Impl 구현클래스 작성)
3. 2차 우선순위에 해당하는 기능 구현에 필요한 인터페이스 작성 및 erd 추가 수정
4. 추상화 -> 구현화 작업
5. 위의 과정을 반복 수행한다.

우리는 위의 방법을 채택해서 사용했는데 이는 단지 인터페이스를 먼저 만들었다 정도였다. 멘토님이 말씀하신 추상화 작업과는 거리가 멀었다.🥲 멘토님께서 말씀하신 선 추상화 작업은 전체 요구사항에 대한 흐름을 파악하고 어떻게 유연하게 설계할 수 있는지, 테스트에 용이한지등을 따져봐야했었다.

우리의 위의 과정이 도출된 이유는

• 익숙하지 않은 선 추상화 작업
• 정확하게 이루어지지않은 세부 기능 기획

이었다.

그러나 생각해보면 사용자 요구사항 정의서와 기능은 언제든지 개발함에 있어서 변경사항이 있을 수 있다. 그렇기에 폭포수 모델방식이 아닌 에자일방식으로 개발을 하려하지 않았는가?

우리의 방식은 추상화라기보단 정해진 구조의 선 인터페이스 설계에 불과했다. 우리는 요구사항 정의서를 보고 ERD를 가장 먼저 설계했다. 그리고 그 이후의 추상화 작업은 이미 구조화된 데이터구조를 보고 그냥 추상화가 아니고 구조에 맞게 데이터 전달을 위한 인터페이스를 만든것일 뿐이었다.

멘토링 OT에서 오늘과 비슷한 이야기들을 듣고 메인프로젝트때 기능 구현을 하기 위한 코드들로만 프로젝트를 완료하는 것보다 멘토링을 할 수 있는 기회가 있을 때 좋은 개발자로 성장할 수 있는 마인드 셋팅과 개발 접근 방식을 습득해가자고 하셨다.

그러나 회의를 거치면서 여전히 기간 내에 프로젝트를 어느정도 완수를 해야겠다는 생각. 다른 프로젝트도 진행하겠지만, 구현가능한 부분을 빨리 끝내고 구현해보고 싶었던 기능들을 실험실처럼 이것저것 해보며 구현할 생각에 눈이 멀어져갔다.

취업을 준비하는 입장에서 이렇게 추가로 현재의 우리기준에서 새로운 기능을 개발해나가서 스프링 이렇게 할 줄 알아, 이런거 이런식으로 구현해본 경험이 있어요를 어필하기 위함이 우선시 되었다.

좋은 개발자가 되고싶고, 그러기 위해 어떤 노력을 했는지 나의 비전과 가능성을 제시할 수 없는 그냥 모두가 하는 CRUD를 만들어본 취업 준비생이 되는 거였다.

사실 오늘 내가 맡은 가계부관련 CRUD기능에서 회원정보를 받아오는 것을 제외한 repository, service를 작성하고 repository와 service에 해당하는 Test코드까지 작성을 완료한 상태였고, 이미지 업로드 기능을 push하고 controller작성까지 하려던 참이었다. ㅋㅋㅋㅋ ㅜ

하지만 이런기능은 따지고보면 모두가 작성할 수 있는 포트폴리오에서 눈에 띄지도 않는 코드일 뿐일 수 있다. 어떻게 고민했고, 왜 이렇게 구현이 됐는지 스토리텔링 없이 단지 공장에서 금형에 찍혀나오는 공산품들처럼 말이다.

개발과정이 아닌 공산품을 찍어내는거에는 기계에 고민거리와 스토리텔링은 없으니 말이다.

그래서 나는 아직 일주일밖에 지나지 않았고 시간이 충분히 남았다고 생각해서 우리가 선정한 모든 요구사항에 대한 흐름을 파악하고 우리가 생각해낼 수 있는 모든 추상화작업을 시도해보고 싶어졌다.

기능을 찍어내기위한 개발이 아니라 전체적인 구조를 고민하고, 우리가 설계한 인터페이스들에서 코드 중복은 없는지, 전체적인 흐름 내에서 어떻게 구현해야할지 충분히 고민해 보는 시간을 보내면 좋을 것 같다.

이렇게 들으면서도 아직 추상화 후에 구조화 하는 것이 어떤 것인지 감이 잘 잡히지는 않는다.

또 다시 백지에서 추상화 작업을 한다고해도 어느정도 구조적인 틀에 박혀있을지도 모르겠다. 하지만 추상화 작업이 정확하게 무엇인지 파악도 하지 못했고, 이번이 처음이니 어떻게 처음부터 잘할 수 있겠는가. 이 전보다 조금 더 발전했음을 느끼고 스스로 느껴지는 것이 있으면 성공한 방식이라고 생각한다.

그래서 새로 적용해보고 싶은 방식은

새방식!?

- 1. 전체적인 요구 사항에 대해서 흐름을 파악한다.
- 2. 리스트업 된 요구사항에 대해 하나씩 인터페이스를 작성한다.
- 3. 작성하며 이것이 왜 필요해서 작성되었는지 주석으로 메모해둔다.
- 4. 인터페이스에 작성된 메서드를 구현하기 위해 어떤 파라미터가 필요한지, 이 요구사항에서 어떤 것을 클라이언트에 넘겨줘야할지 작성해본다.
- 5. 인터페이스에 작성된 파라미터들과 반환값들을 생각하며 ERD테이블을 작성해본다.
- 6. 개발을 진행하며 변경되는 사항에 대해 요구사항, API명세서, 그리고 데이터 구조를 조금씩 변경해가며 진행한다.

어찌보면 이전과 과정이 큰 차이가 없을수도 있고, 같은 말을 다르게 한 것일 수도 있다. 그래도 피드백을 받고 다시 배워나가면 되니까, 오늘의 피드백으로 이런 생각들과 고민을 시작으로 발전했음을 느끼면 그것만으로도 성공한 것이 아닐까.

화이팅😎