24.05.26~24.06.02

업무

TIPS - 챗봇 애플리케이션 설계

R&D 과제를 수행했다.

해당 과제는 크게 1) 추천 알고리즘 개발 2) 챗봇 구현 및 기존 앱과 연결 로 나눌 수 있는데

1)은 작년에 얼추 마무리가 지어 둔 상태라, 2)를 맡아 작업하게 되었다.

 

약 3일 정도 애플리케이션을 어떻게 설계할 것인가 에 대해 고민했고,

(다양한 방법을 구현했다 지웠다를 반복하다...)

최종적으로 domain - application - adapter 로 각 계층의 역할과 책임을 분리하는 구조(헥사고날 아키텍처)를 도입했다.

 

domain과 application 로직 작성을 완료하였고,

다음 주부터 각 모듈들을 사용해 본격적으로 next js로 구성한 view 로직을 구현할 예정!

 

정기 결제 테스트 및 배포

정기 결제 BE 개발이 완료되어 staging 환경에서 테스트를 진행했다.

크게 문제가 발생한 부분은 없어서 → 다음 주 production 환경에 배포할 예정.

 

회고

왜 프론트 개발은 괴로울까?

왜 프론트엔드 개발은 괴로울까?

 

왜 프론트 작업은 시간이 흐를수록 기능 추가/수정 비용이 기하급수적으로 늘어날까?

왜 프론트 작업은 사용자에게 테스트를 맡길까?

왜 프론트 작업은 비대하고 복잡한 모듈들과 함께 이뤄져야만 할까?

6개월이 지난 프론트 코드들

답은 간단하다.

→ 그렇게 코드를 작성하기 때문이다.

따라서 우리에게는 '그렇게 코드를 작성하지 않을 방법'이 필요하다.

 

여기서

'그렇게 코드를 작성한다'라는 것은

1. 중요한 부분(비즈니스 로직)과 그렇지 않은 부분이 얽혀있음.
2. 아무런 테스트도 이뤄가 이뤄지지 않음.
3. 각기 다른 추상화 레벨의 모듈들이 함께 존재함. 

을 의미한다.

 

그리고 '이를 막을 방법' 은

1. 중요한 부분 을 어떤 식으로 구성할 것인지 계획(=설계).
2. 이를 코드 작성자 전원에게 공유.

를 뜻한다.

 

이번 TIPS 작업을 하면서 가장 주의했던 부분은 아래 두 가지였다.

1. 비즈니스 로직과 그 외의 영역(아무래도 view일 테다)을 분리한다. 반드시!
2. 비즈니스 로직에 대한 테스트 코드를 작성한다.

이를 가장 잘 달성할 수 있는 방법으로 헥사고날 아키텍처를 선택했고,

이틀 정도 작업한 현재까지는...

여러 고민이 들 때도 있지만, 굉장히 만족스럽다!

 

대부분의 비즈니스 로직이 domain과 application에 작성되어 있기 때문에

해당 정책을 테스트하기도 무척이나 쉬웠고 (복잡한 mock이나 spy가 끼어들 여지가 없다!)

세부 구현체가 아닌 port에 의존하기 때문에 adapter에 작성된 실제 구현을 얼마든지 바꿀 수 있어 좋았다.

 

특히 코드를 작성하다 보면,

컴포넌트 내부에 특정 라이브러리에서 파생된 코드들이 기하급수적으로 늘어날 때가 잦은데...

해당 아키텍처 내부에서는 이를 추상화하고, 정의된 메서드들만 제공하기 때문에

각 컴포넌트에서 사용할 때 아무런 인지적 부담이 없다는 점이 굉장히 매력적이었다.

 

하지만 당연히, 모든 SW 관련된 개념들이 그러하듯 은탄환은 절대 존재하지 않는다.

→ 해당 아키텍처 내에서 작업하며 느낀 점을 계속해서 기록하며 개선해나가자!