[평생교육원 전환] 프로젝트 회고(2108 ~ 2111)

회고는 QNA 식으로 진행합니다.
기업의 구체적인 내부 사항은 다루지 않습니다.
내용은 계속해서 수정해 나갑니다.

어떤 프로젝트를 진행했나요?

소속 회사가 평생교육원으로 전환하면서 시작한 프로젝트였습니다. 코로나19 상황에서 주 서비스가 오프라인 모임이었던 우리에겐 중요한 이슈였어요. 평생교육원으로 전환하게 되면, 학교나 학원시설과 같은 취급을 받기 때문이죠. 그렇게 되면 안전하게 방역을 지키며 더 많은 유저들에게 이 좋은 프로덕트를 제공할 수 있게 됩니다.

하지만 평생교육원으로 전환하면 많은 것이 바뀌어야 했어요. 제일 큰 변동 사항은 프로덕트의 형태와 환불 정책이었죠. 우리 기존 시스템은 해당 변동 사항에 맞춰 변화를 가져다 주기 어려운 형태였어요. 사실 적용한다고만 하면 빠른 시간에 적용할 수 있었지만, 나중에 또 이런 변화가 생기면 발빠르게 대응할 수 있는 유연한, 확장성이 좋은 서비스를 만들고 싶다는 욕심이 생겼습니다.

• 변경된 정책이 궁금하시면 해당 링크에서 볼 수 있습니다!

기존 시스템(작성 중)

기존 시스템에 대한 Architecture 입니다. 몇 년 동안 이어져 온 구조이지만 항상 문제라고 생각했던 부분이죠.

무엇이 문제인가?

1. 모든 서비스가 백엔드 한 곳에 의존합니다.
   - 백엔드 한 곳에 장애가 발생하면 유저 페이지, 어드민 페이지 등의 모든 서비스가 먹통이 되어버립니다.
2. 각각의 도메인에 대한 구분이 모호했습니다.
   - 특정 도메인이 어디부터 어디까지 관여하고 있는지 알기 위해선 코드의 모든 부분을 봤어야 했습니다.
   - 변경이 일어나도 어디부터 어디까지 변경해야 하는지 감이 잘 오지 않았죠.

해당 구조에 대한 문제는 사실 말해도 말해도 계속 나올 정도입니다. 위에서 언급한 문제는 당시 우리에게 화두되었던 높은 응집도와 낮은 결합도에 대한 문제였고, 해결이 이루어져야 한다고 인지한 상황이기에 언급했습니다.

응집도와 결합도란?(진행 예정)

그래서?
우리는 기존 방식에서 벗어난 아키텍쳐를 구성하기로 했어요.

변경된 시스템(작성 중)

진행하면서 어떤 점이 어려웠나요?

거의 다 어려웠지만, 테스트를 기반으로 하는 개발이 제일 어려웠습니다.

어디부터 어디까지 테스트를 해야 하고, 어떤 종류의 테스트를 해야 하는지 조차 모르던 상황이었던 터라 이런 환경이 낯설고, 더 힘들었습니다. 하지만 당연히 해야하는 작업임과 동시에 제일 중요하니 더 갈고 닦아야 겠지요! 이번 배포를 통해 테스트의 중요성을 더욱 뼈저리게 느꼈습니다.

과거 3달 전과 비교 했을 때 달라진점 또는 생각의 변화가 있다면 무엇인가요?

1. 감(?) 이라는게 조금은 생긴 것 같아요.
   이전에는 어떤 시스템, 서비스를 구현하기 위해서 그저 만들기만 하면 되는 줄 알았는데, 우리 서비스에서 어떤 식으로 적용되어야 하고, 어떤식으로 작업하는게 더 효율적이고 이로운 방향으로 나아가는지 바라보게 하는 시각을 갖게 된 것 같습니다. 아직 한참 부족하지만 큰 틀로 봤을 때 중요한 부분을 인식하는 시각을 만들어 나가고 있는 느낌이 듭니다.
2. 테스트의 중요성을 뼈저리게 느낍니다.
   이전에는 코드를 작성하고 실제 동작이 되는지만 테스트해 잘 되면 내보냈고, 그러면 되는 줄 알았습니다. 하지만 이제는 그게 아니라는 것을 몸으로 깨달았어요. 실제 동작이 잘 된다 하더라도 안 보이는 부분에서 어떤 장애를 내고 있을 지, 그게 정말 맞는 방법인지 확인할 수 있는 것은 테스트 밖에 없다고 느꼈습니다. 물론 1번 질문에서 답한 것 처럼 더 갈고 닦아야 하지만 중요성을 몸으로 느꼈다는 점이 저에겐 가장 큰 포인트인 것 같아요.
3. 테크유닛의 사람들을 더욱 신뢰할 수 있게 된 것 같아요.
   이전에는 서로 어떤 작업을 하던 붙어있었던 경우가 대부분이고, 나누더라도 불안한 감정이 있었던 것 같아요. 하지만 이제 초반 설계를 빡세게 하고, 작업을 나누면 그런 불안한 감정이 생기지 않습니다. 이런 부분에서 내가 같은 팀원들을 믿게 되었구나 라고 생각하는 듯합니다. 사람 믿는 것을 힘들어하는 저로서는 좋은 현상이라 생각해요.
4. 우리가 같은 그림을 바라보고, 같은 생각과 같은 단어를 나눈다는 것이 얼마나 중요한 것인지 깨달았습니다.
   이전 몇 번의 작업을 통해 같은 목표를 받고, 같이 작업을 나누더라도 바라보는 시각이 엄청 다르다는 것을 알았어요. 그런데도 딱히 이 부분을 고치려 하지 않았어요. 왜냐면 의식을 못했으니까요. 이번 설계에 같이 그림을 그리면서 알았습니다. 같은 목표를 바라보더라도 분명히 다른 생각들을 하고 있을거라고... 우리 유닛 리더님의 위대한 영도력으로 ㅋㅋㅋㅋㅋㅋ 우리가 같은 그림을 바라보고 같은 생각, 같은 단어를 공유한다는게 같은 목표를 나아가기 위해 얼마나 중요한 지를 깨달았습니다.

현재 자신있게 설명 할 기술적 도구나 내용은 무엇인가요?

JSR-303, Valid4j, Mockito를 이용한 테스트, DDD의 계층구조, 다이어그램의 중요성, Queue 의 역할.. 근데 설명하면서도 계속해서 제가 모르는 것을 발견할 것 같아요. 일단은 이 정도입니다.

지난 시간 성장하기 위해 무엇을 노력 했고 그것의 성과는 무엇인가? 측정 할 수 있나요?

1. 2개의 프로젝트를 진행하고 있어요.
   하나는 개인이고, 하나는 팀인데 모두 스프링부트를 기반으로 진행하고 있습니다. 일단 닥치는 대로 무언가를 했던 것 같아요. 책을 봤는데, 뭔 소리인지 하나도 모르겠어서 일단 뭔가 만들어봐야 겠다고 생각했습니다.
2. 최대한 의식적으로 단축키를 사용하려고 합니다.
   작업하는데 트랙패드 쓰는게 의외로 시간을 많이 잡아먹는다고 하셨는데, 저도 공감하게 되었어요. 웬만한 상황에서 단축키만을 쓰려고 합니다.
3. 작업 중 눈 앞에 두 개 이상의 상황을 비추지 않으려 노력합니다.
   요즘 이런 저런 개인적인 일들이 많아 신경이 많이 쓰였습니다. 그래서 더 의식적으로 하나에 집중하려 했습니다. 탭도 한 번에 3개 이상 띄우지 않고자 하고, 화면도 하나만 쓰니 집중이 잘 됐습니다. 노력이라고 하기엔 뭐하지만 의식적으로 하고자 했다는 점에 노력이라 부르고 싶어요.
4. 업무를 최대한 분할하려 합니다.
   최대한 쪼갤 수 있을 만큼 쪼갠 다음 순차적으로 하나씩 처리하고, 여러번 사이클을 돌고자 노력합니다. 한 번에 완벽하게 하려는 행위보다 여러번 진행하며 완벽하게 다듬어 가는 것이 중요하다는 것을 느끼고 실제로 그렇게 수행하려 노력합니다. 계속 걸리는 부분이 있어도 어디 적어논 다음 신경끄고 다음으로 넘어가요. 그리고 한 단계씩 깊이를 내려가며 그 작업의 완성도를 견고하게 만들어 갑니다. 아직 많이 부족합니다만, 노력하고 있습니다.
5. 스터디를 합니다.
   시작한 지 얼마 안 됐지만, 성장에 대한 갈증을 계속 느끼는 중이라 평교 프로젝트, 개인 프로젝트, 팀 프로젝트를 하며 일정이 빽빽한 와중에도 하고자 했습니다. 몸은 못 할 거 같다 소리치는데 머리가 먼저 반응하더라구요. 빨리 하자고 ㅋㅋㅋㅋㅋㅋ 저도 놀랐습니다.

솔직히 말해서 성과는 이번 프로젝트에 나왔다 생각합니다. 사이즈가 작은 프로젝트도 아니였으며, 이 시간에 가능할 거라 생각하지 않았습니다. 하지만 테크 유닛 모두가 죽어라 노력했고, 결과는 나왔습니다. 이 점에서 저는 충분히 성과라고 생각합니다. 우리 유닛 리더분이 말씀하셨던 것 처럼 우리는 뿌듯해도 좋을 것 같습니다.

팀에서 이것만은 잘하고 싶다하는 것이 있나요? 있다면 무엇인가요? 없다면 왜 없나요?

기술적인 부분과 기술적이지 않은 부분이 있습니다.

기술적인 부분은 TDD 를 기가막히게 잘하고 싶습니다.

제 개인적인 욕심으로는 유저에게 많은 것을 가져다 줄 수 있는 개발자가 되고 싶은데, TDD는 유저에게 어떤 걸 가져다 줄 수 있는지 먼저 인식한 상태에서 그걸 충족한 기능이 개발되었다는 가정하에 테스트를 짜기 때문입니다. 물론 만드는 과정에서 바뀌긴 하지만 저에겐 '유저'가 원하는게 무엇인지 인식한다는 점에서 매력적으로 다가왔어요. 최강의 TDD 유저가 되고 싶네요.

기술적이지 않은 부분은 큰 그림을 인식하고 옳은 방향을 제시할 수 있는 사람이 되고 싶습니다.

시야를 넓히면 우리가 무엇을 해야 하는지, 어떤 것을 바라보며 가야할 지 더욱 명확해 지는 것을 이번 프로젝트를 통해 깨달았어요. 동시에 희열을 느꼈습니다. 저는 먼저 유저들이 어떤 것을 좋아하는지 알고, 그 좋아하는 것을 제공해주기 위해 어떤 방향으로 가야하는지 인식하고 싶습니다. 이 것들을 큰 그림이라고 생각해요. 저는 이런 큰 그림을 그리는 사람이 되고 싶습니다.

팀에게 바라는 점이 있나요?

저도 아직 부족한 점이긴 하지만 서로에게 더욱 집요했으면 합니다. 가끔은 우리가 명확히 인지하지 않았음에도 피곤하다며 그냥 넘어가는 경우가 있는 것을 보았어요. 저는 오히려 그런 상황이 더 위험하고, 그런 상황에서 오히려 더욱 집요해야 한다고 생각합니다. 그런 상황에서 겨우 한 두개 쯤이야 라고 생각해도 겨우 한 두개가 나중에 거의 시스템을 갈아 엎을 수준의 똥으로 커질 수 있기 때문입니다. 그리고 그런 상황에서까지 집요할 수 있다는 것은 평소 집요함이 몸에 박혀있다는 것이겠죠. 저는 익숙하지 않은 지금 집요함을 의식적으로 진행했으면 좋겠습니다.

이전 3개월동안 보고 듣고 경험한 모든 기술의 이름을 브레인스토밍해주세요.

개발 방법(?)

• 처음 작성하는 것을 보고 충격받은 TDD
• 도메인을 기반으로 설계하는 DDD 기법.
• 그리고 DDD 의 Layered Architecrue(Presentation, Application, Domain, Infrastructure)
• 한 gradle 프로젝트 내에 여러 모듈을 담는 Multiple gradle project

라이브러리

• 값에 대한 유효성을 검증하기 위한 Valid4j, JSR-303
• 로그를 기록하는 Slf4j
• 클래스 내 속성을 생성하는 생성자를 어노테이션 하나 만으로! AllArgsConstructor
• 꼭 생성해야 하는 속성만 생성하는 어노테이션! RequiredArgsConstructor
• 테스트를 더 편하게 진행할 수 있도록 하는 Assertions, Mockito
• 스프링부트와 데이터베이스의 연결을 위한 jdbc, 그리고 명령을 수행하는 repository

기타

• 그리고 같은 그림을 인식하기 위한 다이어그램(상태 전이, 클래스, 시스템, 시퀀스, 유스케이스 등)
• 메시지를 담는 Queue, 그 메시지를 발행하는 Pulisher, 그리고 그 메시지를 소비하는 Consumer
• ElasticBeanstalk 의 환경을 설정할 수 있도록 하는 ebextensions
• 직접 정의한 명령을 순차적으로 수행할 수 있도록 돕는 make(makefile)