[트레바리] 다양한 Type 의 Notification 전송 시스템인 Notifier 프로젝트를 회고하며

목차

• 나는 무엇을 회고하는가
• 나에게 칭찬한다 (Keep)
• 기술적인 배움
• 무엇이 문제였는가? (Problem)
• 다음 프로젝트에서는? (Try)

나는 무엇을 회고하는가

Notifier AS-IS와 TO-BE

• AS-IS
  • 트레바리의 크루는 SMS 를 보내기 위해서 직접 외부 SMS 모듈 (Senders, Twillio) 를 직접 들어가서 문자를 전송한다.
  • 또한 Legacy System 에 의해 전송된 문자에 대한 확인을 위해 직접 SMS 모듈로 들어가서 확인한다.
• TO-BE
  • 문자가 잘 보내졌는지를 트레바리의 Admin 에서 확인할 수 있도록 한다.
  • Notification 을 하나의 시스템에서 보낼 수 있도록 하고 실패한 메시지는 retry 를 수행하게 한다.
    • Scheduling 을 통해 문자를 보내고 State Check 를 통해 문자의 상태 update
  • Notification 을 보내는 외부 모듈에 의존되지 않는 범용적 설계한다.
    • Slack, ToastSMS, Senders, Twillio 가 아닌 어떤 외부 모듈이 사용되는지가 중요하지 않게 되는 모듈 개발
    • 심지어 SMS 인지 Kakao 인지, Mail 인지 또한 의존하지 않게 되어야 함

 

나에게 칭찬한다 (Keep)

 

이번 Notifier 프로젝트를 진행하며 스스로 잘 했다고 생각하는 것들이 몇가지 있고, 이들은 다음 프로젝트까지 이어져도 좋다고 생각한다.

 

1. 매일 회고를 했던 것

 

나는 입사 이후 매일 마다 오늘 한 것과 오늘 배운 것을 노션에 정리했고 업무를 진행하며 머리를 때리는 것들에 대해서 적어나갔다.

 

나는 이렇게 정리하는 것이 오래 못 갈것이라고 생각했다.

 

신입 이라는 열정과 뽕에 차서 시작한 회고였지만 의외로 꽤 잘 지켜져서 놀랍다.

 

이젠 출근하면 노션에서 페이지부터 작성하고 템플릿을 복사한다.

 

이렇게 나만의 업무 루틴이 되어버렸는데, 내용이 길던 짧던 한달동안 꾸준히 이어졌다는 사실만으로 스스로 칭찬해주고싶다.

 

2. 바쁜 와중에도 개인 공부를 했던 것

 

나는 Ukov 를 통해서 트레바리에 합류하게 되어 정확히 따지면 트레바리와 동시에 Ukov 의 소속인 것이다.

 

Ukov 는 인턴쉽을 연계해주는 프로그램이기도 하지만 Ukov 단원들끼리 미니 창업을 하는 프로젝트 또한 업무와 병행해서 해야했다.

 

퇴근 후에는 2일에 한번씩 오후 10시부터 새벽 1~2시까지 회의를 하며 매우 힘든 일정을 보내왔는데 그 와중에도 개인적인 공부는 놓지 않았었던 것에 대해서 스스로 칭찬해주고싶다.

 

3. 내가 생각했을 때 옳다고 생각한 코드를 작성한 것

 

Notifier 프로젝트를 진행하며 스스로 뿌듯했던 기억이 몇번 있었다.

 

그것은 바로 다른 분들이 짜놓은 코드를 내 생각에 맞게 다시 구현하거나 바꿔놓았을 때다.

 

한 번은 테크 팀의 리더가 짜놓은 코드가 있었는데, 내 스스로가 생각했을 때 이 코드는 무언가 바뀌어야 한다고 생각했고 실제로 바꿔놓았던 적이 있었다.

 

결국 다음날 지적받았다

 

하지만 집에 와서 곰곰히 생각해보니 오히려 잘했다는 생각이 들었다.

 

만약 내가 코드를 그렇게 바꿔보지 않았더라면 나는 프로젝트가 끝날때 까지 그 클래스가 가진 책임과 역할에 대해서 이해할 수 없었을 것이다.

 

기술적인 배움

 

1. 객체와 협력이 무엇인지 조금이라도 알것 같다.

 

이번 프로젝트에서 가장 크게 배운 것이 바로 객체의 협력이다.

 

아직 TDD 를 완벽히 이해하지는 않았지만, 테스트 코드를 써내려 가는것. 어떤 객체가 말하고자 하는 것에 대해 아주 조금 느낌이 올것 같다.

 

사실 글로 써내려갈 정도는 아니지만 이제는 테스트 코드를 보면 sut 가 무엇과 협력하는지를 먼저 확인한다.

 

즉, sut 가 하는 행위에 대해서 무엇이 필요하고 그것이 과연 sut 와 협력하는 것이 올바른지를 생각하는 힘이 점점 길러지는것 같다.

 

2. 결정하지 않는 것이 무엇인지 조금 알것 같다.

 

내 매일 회고에는 또 이런 말이 있다.

 

좋은 아키텍쳐는 결정하지 않는 것.

 

이는 OCP 를 의미한다고 생각한다.

 

결국 특정 구현을 생각하지 않아야 한다는 것이다.

 

Spring Data 프로젝트에서 JPA를 쓰던 JDBC를 쓰던 R2DBC를 쓰던 고려하지 않고 이들을 추상화 하였다.

 

JPA 에서는 H2DB를 쓰던, MySQL 을 쓰던 고려하지 않는다.

 

Notifier 에서는 NHN Toast 를 쓰던 Twilio 를 쓰던 고려하지 않는다.

 

무엇이 아쉬웠는가 (Problem)

 

1. 매일 회고를 작성했던 것

 

회고는 매일 작성해서 뿌듯하지만 사실 진정한 회고가 아니었다. 그냥 업무 리스트를 적고 감명깊게 들었던 내용들을 글로만 정리한 것 뿐이다.

 

적어도 회고를 한다면 오늘 내가 무엇을 배웠는지 다시 한 번 “생각” 을 하고 되짚어야 했지만 그러지 않았다.

 

그래서 지금 다시 돌아보면 회고 내용중에 바로 오늘 느낀 점에 내용이 이틀 연속으로 등장 하는 회고도 있었다.

 

2. 일정에 쫓긴다

 

Notifier 프로젝트는 지금껏 내가 경험했던 여타 프로젝트와 비교할 수 없을 정도로 빠른 템포로 진행되었다.

 

내가 적었던 매일 회고에는 이런 말이 있다.

 

“비즈니스를 하는 개발자는 빠른 Delivery 가 중요하다. 처음부터 완벽하게 만들려고 하는 순간 소프트웨어가 하드웨어처럼 딱딱해질 수 있다.”

 

빠른 Delivery 가 중요하지 코드를 신경쓰지 않는 Delivery 가 아니라고 느꼈다.

 

그래서 지금도 코드를 보면 부끄러울 정도로 하드 코딩으로 구현한 로직이 매우 많이 존재한다.

 

이건 촉박한 일정과 별개로 생각하기 싫었던 것은 아닐까 한다.

 

이와 근본은 다른 내용이지만 클린 코드의 1장을 읽을 때, 와우 포인트가 생각나서 적어본다.

 

깨끗한 코드를 짜지 못한 것이 일정 때문인가? 일정 핑계, 압박 핑계를 대지 말아라. 일정 조율에 실패한 것도 나쁜 코드를 생산하는 근본이 된다. 결국 좋은 코드를 사수하는 것 역시 우리 개발자의 몫이다.

 

이 문제는 아직 더 고민을 해봐야 한다고 생각한다.

 

결국 무언가를 빨리 할 수 있다는 것은 손에 충분히 익어야 가능하고 그만큼 코드에 대한 피지컬? 이 좋아야 한다고 생각한다.

 

아직 스스로 기술적으로는 익지 않았지만 결국 시간과 노력을 통해 채워나가야 할 부분이라 생각한다.

 

3. 꼼꼼하지 못하다.

 

첫 배포때 사소한 실수가 너무나도 많이 있었다.

 

바로 EB와 Github Action 을 연동할 때 였는데, 차분히 스크립트를 읽었더라면 아래와 같은 상황은 안 벌어졌을것 같다..

 

이외에도 코드단에서 보면 내가 짠 코드들은 대부분이 겉만 멀쩡하다는 생각을 많이 했다.

 

알고리즘 PS 를 할 때 Test Case 1번 2번이 주어지는데, 그냥 printf 로 1번 2번 TC 를 출력한다는 느낌?

 

조금만 더 생각하면 예외인 상황이 바로 발생한다.

 

이게 바로 데이터적으로 생각해서 코딩을 해서가 아닐까 싶다.

 

데이터적으로 생각한다?

 

어떤 특정 상황을 상정하고 특정 데이터를 생각했기 때문이다.

 

3. 이해하지 않았는데 이해했다.

 

다른 분들이 어떠한 기술적인 이야기를 하며 설명을 할 때 많은 부분에서 이해가 가지 않았던 부분이 존재했다.

 

하지만 고개는 끄덕이고 있고 입으로는 이해가 됐다고 한다.

 

사실 고민이 많이 된다. 내가 이해가 되지 않는 부분을 하나 하나 이야기 한다면 프로젝트는 앞으로 나갈 수 없다..

 

결국 이 문제는 많은 부분에서 드러났다.

 

어떠한 Task 가 주어지고 내가 그 Task 를 수행해야 할 때, 해당 Task 로 해결해야 할 문제와 전혀 다른 방향을 고민하고 해결하려 했었다.

 

이 상황에서 오히려 더 많은 의사소통 비용이 발생했고 결국 계속해서 일정이 늦춰지게 되어 이번 프로젝트의 가장 큰 패착중 하나라고 생각한다.

 

4. 기술적인 Try 를 하지 못한것.

 

이번 Notifier 프로젝트에서 기술적으로 Try 할 수 있는 것은 명확했다.

 

바로 내가 처음부터 관심이 많았던 Spring Cloud Config

 

하지만 시도조차 하지 못했다. 아니 할 수 없었다.

 

한 때 Spring Cloud Config 를 도입하고싶어 문서를 잠시 봤는데, 이런 생각이 들었다.

 

‘내가 지금 이것을 하는 것이 맞는가? 당장 한 시간 전에 짠 코드도 리팩토링이 안되어있는데?’

 

그럼 리팩토링을 했는가?

 

대신 잠을 잤던것 같다.

 

다음 프로젝트에서는?

1. 복명복창

 

군대에서 복명복창을 가장 먼저 배운다.

 

복명복창은 군대에서, 상관이 명령을 내리면 그 명령을 받은 수명자가 명령자에게 그 명령 사항을 반복하여 말하는 것이다.

 

예를 들어서 “너! 가서 불 끄고 문 닫고 나와!” 라고 한다면 나는 “예, 불 끄고 문 닫고 나오겠습니다.” 라고 하는 것이다.

 

나는 “어떠한 Task 가 주어지고 내가 그 Task 를 수행해야 할 때, 해당 Task 로 해결해야 할 문제와 전혀 다른 방향을 고민하고 해결하려 했었다.” 라는 문제를 또 다시 겪지 않기 위해서는 의도적으로라도 복명복창 마인드를 가지려 한다.

 

물론 군대처럼 하지는 않겠지만.. 그래도 최소한 어떤 Task 가 애매할 경우 내가 이해한 내용을 다시 한 번 되짚고 가려 한다.

 

이게 오히려 더 많은 의사소통의 비용이 발생하겠지만 최소한 업무가 손에 잘 익고 눈에 보일 때 까지는 해야겠다 다짐한다.

 

2. 이번 회고에서 Try 한다는 것은 꼭 하자

 

사실 회고 스크립트를 최초로 작성했을 때, 복명복창 이외에도 몇가지가 더 있었다.

 

하지만 그런 것들은 집중하지 않으려 한다.

 

내 SRP 를 위반한다.

 

다음 프로젝트에서 내가 집중하려는 것은 내가 해야할 Task 를 명확히 인지하고 주제에 벗어나는 일들을 최소화 하는 것이다.