미리보기

Sendtime (https://landing.sendtime.app)
B2BC SaaS / 스케줄링 커뮤니케이션 글로벌 웹 서비스

• 기존의 Java, Spring Boot, MongoDB, JPA로 개발된 애플리케이션 리팩토링 및 신규 기능 개발

• NoSQL 데이터를 정규화하고 코드의 구조를 레이어드 아키텍처 구성으로 개선

• 쿼리 위주의 비즈니스 로직을 애플리케이션 코드로 리팩토링

• 글로벌 서비스로서 다국어, 멀티 타임존을 고려한 설계와 기능 개발

• AWS ECS와 GitHub Actions를 활용한 컨테이너 기반 배포 파이프라인 구축

Umoh (https://join.umoh.io)
B2BC SaaS / 이벤트와 커뮤니티를 위한 글로벌 네트워킹 플랫폼

• 서비스 API 및 대시보드/어드민 시스템 기획/개발/운영

• Kotlin, Spring Boot, MySQL, JPA 기반의 신규 멀티 모듈 프로젝트 설계 및 개발

• Domain Model Pattern을 이용하여 도메인 오브젝트에 비즈니스 로직을 구현

• Clean Architecture를 적용하여 애플리케이션 로직이 외부 서비스와 기술 구현에 의존하지 않도록 구성

• Entity와 Aggregate, Domain Service를 이용하여 도메인 레이어를 구성

• 주요 도메인의 변경사항이 있는 경우 도메인 이벤트를 발행하여 처리

• 가장 핵심이 되는 도메인 오브젝트와 애플리케이션 로직에 대한 Test Code를 중점적으로 작성

• 핵심적인 로직 개발에는 TDD 방식을 사용하고, 필요에 따라 API, Repository 테스트를 구현

• 글로벌 서비스로서 다국어, 멀티 타임존을 고려한 설계와 기능 개발

[TDD와 Domain 모듈의 보호]

Sendtime 프로젝트에서는 Test Code가 없었기 때문에 구현에 대한 검증이나 변경에 대한 안전성을 확인하기 어려웠습니다. 그래서 Umoh 프로젝트에서는 Test Code의 중요성을 깨달은 만큼 TDD 방식을 통해 비즈니스 기획을 점검하며 개발하도록 규칙을 정했고, CI에서도 Test Code를 통과해야 Merge 될 수 있도록 구성했습니다. Test Code 작성은 최소한의 껍데기 코드만 작성해둔 상태에서 기획을 기반으로 한 작성해야할 케이스를 코멘트로 서술해두고, 실패하는 케이스를 만들고, 하나씩 성공시키도록 개발해나가는 방식을 선호했습니다.

또한 비즈니스 로직을 간결하게 표현, 구성하기 위해 활용도, 관심도를 고려한 도메인 레벨의 로직을 구성했습니다. 도메인의 구성 요소와 로직을 설계하면서 도메인 정의서를 작성하고 이를 지속적으로 업데이트 했습니다. 상태의 변화가 중요한 경우엔 상태 다이어그램을 작성했습니다. 이로 인해 비즈니스 로직은 해당 행위에 대해 가독성 높은 간결한 코드가 되었고, 도메인은 스스로 책임져야 하는 로직을 구성하고 있는 구조가 되었습니다.

선호하는 TDD에 대한 방법도 정리하고 꾸준히 적용해보고 있습니다. (https://zins.tistory.com/12)

[Test Code shouldBe Kotest? JUnit?]
약 80개 가량의 Kotest 기반 테스트 코드가 구성되었을 당시, 스프링 시큐리티의 @WithMockUser 와 같은 method 레벨의 애노테이션 삽입이 필요했는데 Kotest는 DSL 방식으로 테스트 코드를 구성하기 때문에 JUnit의 함수-메소드 스코프 기준으로 만들어진 Spring Test의 확장 기능을 간단하게 이용할 수 없었습니다. 본격적으로 API 개발이 필요했고, Spring Test의 확장 기능을 포기하는 것보다 Kotest가 아닌 JUnit으로 선택지를 바꾸는 것이 더욱 효율적이라는 판단에 모든 테스트 코드를 JUnit으로 전환했습니다.

전환하는 과정에서 Kotest의 장점인 shouldBe 와 같은 가독성 좋은 assertions 문법을 유지하여 각 라이브러리의 장점을 적극 활용했습니다. (https://zins.tistory.com/15)

[DIP(의존 역전 원칙)]
admin, api, domain, integration, security 등 멀티 모듈을 통해 불필요한 의존성을 방지하고, 각 모듈의 관심사가 적절히 분리되어 있도록 구성했습니다.
일부 기능에서는 Email, SMS 발송까지가 비즈니스 로직이기 때문에 애플리케이션(서비스) 계층에서 발송하는 로직이 필요했습니다. 따라서 send 메소드가 있는 NotificationFactory라는 Interface를 domain 모듈에 정의하고, SendGrid나 Kakao 알림톡과 같이 외부 API를 통해 실제로 발송하는 내용은 integration 모듈에서 NotificationFactory를 implements 받는 Notifiers로 구성했습니다.

DIP를 적용하여 domain 모듈에서 비즈니스 로직에 포함되는 Email, SMS 발송에 대한 send 메소드를 포함하여 Test Code를 구성할 수 있게 되었습니다. 실제 발송 로직의 구체적인 구현은 integration 모듈에서 구현하여 외부 API를 사용하는 만큼 기술과 구현의 변경에 유연하게 대처할 수 있게 되었습니다. 결과적으로 domain 모듈이 외부 모듈에 의존성을 갖지 않도록 하는 설계를 지킬 수 있었습니다.

위의 경우 외에도 PasswordEncoder와 같이 비즈니스 로직에서 필요하지만, 구체적인 구현은 외부에 의존하게 되는 경우 DIP를 적용하여 개선한 사례도 있습니다. (https://zins.tistory.com/17)

OLLA 2.0 (https://ol-la.com)

B2C 건축주와 건축사 매칭 및 시공 전 가상공간을 통해 건축주의 건축물을 미리 체험하는 웹 서비스

• 서비스 전반에 필요한 모든 IT 서비스 기획/개발/배포/운영

• 외주 개발사와 협업하며 OLLA 2.0 런칭 PM 및 기획/Backend 개발 담당

• 관리자 사이트 기획/개발/배포/운영 및 Slack Webhook, AWS SES를 활용해 내부 담당자에게 알림 제공 등으로 운영/마케팅 등 업무 자동화/효율화

• AWS 아키텍처 점검 및 개선으로 서버 비용 약 66% 감소

B2B 실시간 데이터 수집 및 분석을 통해 노후화 된 공장 생산성 최적화의 방향성 제시 웹 솔루션

• B2B smart factory 웹솔루션 가동 및 생산 데이터 API 개발

• 기존 Native Query를 JPA로 변경하여 적용

• Azure를 통한 server 배포

• 팀 인원 증가에 따른 협업 툴 Jira 도입 및 관리