[SOPT] 앱잼, 라이온하트 개발 중간 회고

 

 

SOPT 앱잼, 1차 회고

LionHeart

 

IT 동아리 SOPT에서 경험하게된 앱잼의 합숙 1주차가 지나며,
한 주간 라이온하트 서버를 개발하면서 겪은 감정과 경험을 글로 녹여내는 시간을 가지려고 한다.

 

 

🦁 라이온하트?

 

라이온하트는 예비 아버지를 위한 육아 아티클 서비스이다.

아버지들을 위한 육아 정보 커뮤니티가 거의 존재하지 않고, 아버지들은 정보를 얻을 수 있는 공간이 너무나도 적다.

 

가장 활발하게 정보가 유통되는 맘카페라는 공간을 이용하지 못하면 예비 아빠들은 스스로 정보를 찾아나서야 하는데 이것은 너무 막막한 상황이다.

 

때문에 예비 아버지들을 위한 하루 10분 육아 아티클 서비스 ‘라이온하트’는 세상에 너무나도 필요한 서비스라고 생각이 들었고,

이러한 생각에 지원하여 함께하게 된 라이온하트 서버파트에서 1주간 겪고 느낀 생각들을 정리해보고자 한다.

 

---

🦁 라이온하트에 지원하게 된 이유

 

우선 자세한 기록을 위해 내가 라이온하트에 지원하게 된 이유를 자세히 기록해보려 한다.

 

라이언하트의 기획안을 읽으며 처음으로 아버지들은 맘카페에 가입하여 정보를 얻을 수 없다는 것을 알게 되었다.

때문에 나도 나서서 ‘관련 서비스가 정말 부족한지’, ‘예비 아버지들은 정보를 어떻게 얻고 있는 지’ 등에 대해 알아보고자 기사들을 탐색하였고 그 과정에서 이러한 기사를 하나 발견했다.

 

“남자는 가입 못하는 맘카페, 아빠에게도 필요해”

“남자는 가입 못하는 맘카페, 아빠에게도 필요해”  - 베이비뉴스

 

엄마들은 맘카페에 가입하여 신뢰성이 낮지만 빠른 피드백과 소통이 가능한 반면,
아빠들은 맘카페 가입이 불가능하기 때문에 그러기가 어려우며, ‘100인의 아빠단’이라는 남성 양육자 모임이 존재하지만
활동 기간에 1년 제한이 있어 그 이후에는 정보 공유가 잘 이루어지지 않는다는 내용이었다.

 

또한 의외로 남성 육아 관련 서적이 많이 팔린다는 통계를 바탕으로 젊은 아빠들도 육아를 참여하기를 원하지만 ‘책’이라는 수단 외에는 방법이 많이 없다는 내용도 함께 포함되어 있었다.

 

• 아버지들도 육아를 위한 정보 탐색에 관심이 많구나
• 그런데 아직도 어버지들을 위한 육아 정보 공유가 많이 부족하다.
• 이러한 정보의 불평등함을 해소하고 싶다.

이 기사를 읽으며 든 생각이다.

예비 아버지들은 육아에 적극적으로 참여를 원하지만,

아무리 육아를 위한 다양한 서비스가 출시되더라도 의외로 정보를 얻을 곳이 없어 방황하고 있다는 현실이 안타까웠으며,
이러한 내용은 라이언하트의 따듯한 기획 의도를 더욱 마음 깊이 느끼게 해주었다.

 

"작은 변화들이 모여 세상을 변화시킨다" 라는 가치관을 가진 나의 인생에서 라이온하트라는 길은 꼭 걷고싶은 길이었고 함께 풀어나가고 싶은 문제였다.

 

 

---

🤔 아쉬웠던 점

1주 동안 개발을 하며 아쉬웠던 점을 기록해보고자 한다.

여기 기록된 내용들은 모두 다음 주차에선 반복하지 않으려 다짐하고자 적는 내용이다.

 

💭 빠른 개발을 위해 테스트 코드를 생략

테스트 코드를 생략하고 개발하게 되면, 당장에는 빠른 개발이 가능할 지 몰라도 언젠가 테스트 코드 생략 스노우볼이 점점 커져 결국 우리를 향해 돌아온다는 것을 알고 있음에도 불구하고 이를 생략하고 개발한 점에 대해 많은 반성을 하게 되었다. 남은 1주간 테스트 코드 작성 요령을 학습하며, 개발해 온 기능들과 엣지 케이스에 대해 테스트 코드를 작성해보려한다.

 

💭 간단한 수정 사항 발생 시, 이슈,브랜치를 생성하지 않고 develop 브랜치에 push

develop 브랜치에서 버그 또는 오타 등 수정 사항이 발생하면 이슈와 브랜치를 생성하여 수정 후, develop 브랜치에 merge 하는 것이 일반적인 방식으로 알고 있다.

하지만 이번 라이온하트 개발 시에는 그렇게 까지 정교하게 이슈와 브랜치 관리를 하지 못해온 것 같아 지나고 보니 너무 아쉽다는 생각이 들었다. 남은 1주간은 이를 잘 지켜가며 개발해나가야겠다고 생각이 들었다.

 

 

---

😊 만족스러웠던 점

아쉬움을 기록함에 이어서, 다음으론 우리 팀과 나 자신에게 칭찬해주고 싶은 내용이다.

 

💭 2개 이상 도메인의 Service Layer에서 사용하는 메서드는 Utilization

라이온하트는 서비스 메서드 중, 아티클ID를 통해 아티클을 조회하고 존재하지 않는 아티클ID에 대한 예외 상황을 검증하는 findArticleById 라는 메서드가 존재한다.

해당 기능은 ArticleService 뿐만 아니라 ArticleBookmarkService에서도 필요한 메서드이다.

이렇게 2개 이상 도메인의 Service Layer에서 사용되는 메서드는 해당 도메인의 ServiceUtils 클래스를 따로 두어 관리하도록 하였다.

 

@NoArgsConstructor(access = AccessLevel.PRIVATE)
public class ArticleServiceUtils {

	public static Article findArticleById(ArticleRepository articleRepository, Long articleId) {
		return articleRepository.findArticleById(articleId)
			.orElseThrow(() ->
				new NotFoundException(
					MessageUtils.generate(NOT_EXIST_ARTICLE_ID_ERROR_MESSAGE, articleId),
					NOT_FOUND_ARTICLE_EXCEPTION));
	}
}

이렇게 관리했을 때의 장점은 다음과 같다.

• Repository만 DI 시켜주면 해당 도메인의 Service 레이어의 로직까지 사용이 가능하다.
• 클래스 간, 의존성이 줄어든다
  • 원래 AService, ARepository 모두 DI 받아야할 상황에서도 ARepository Bean만 DI받아도 됨.

 

💭 CRUD에서 'R'기능과 'CUD' 기능의 클래스 분리

DB에 관한 로직인 CRUD 로직 중, 단순한 읽기(Read) 로직은 변경 감지나 스냅샷 저장 등의 기능이 필요하지 않다.

하지만 Service 레이어에 @Transactional 메서드를 붙이게 되면 CRUD 구분 없이 모든 메서드에 공통적으로 변경감지, 스냅샷 저장 등의 기능이 추가된다.

 

때문에 Service 클래스를 C,U,D 로직을 수행하는 Service 클래스와 R 로직을 수행하는 RetrieveService 클래스로 분리하고,

RetrieveService의 클래스 상단에는 @Transactional 어노테이션에 (readonly =true) 속성을 추가해 변경감지/스냅샷 저장 등 불필요한 기능을 동작하지 수행하지 않도록 하여 성능을 향상시켰다.

 

💭 코드 리뷰 문화

우리팀은 코드 리뷰를 상당히 정교하고 깊이있게 진행하였던 것 같다. 메서드명에 대한 고민, 최소 기능 단위 메서드화를 위한 고민, 지키지 못한 컨벤션 체크 등 개발의 모든 부분을 함께 해왔다.

쏟아지는 코드 리뷰 과정이 지칠 때도 있었지만, 이러한 과정은 부족함이 조금씩은 존재했던 서로의 코드를 더욱 빛나고 정교하게 만들어 주었으며, 라이온하트 서버 팀원들을 더욱 단단하게 만들어주었다고 생각한다.

 

💭 dev환경 prod환경 서버 분리

gitActions의 CI,CD 로직을 dev환경과 prod환경으로 분리하여 develop 브랜치에 push하면 EC2 dev인스턴스, main 브랜치에 push 하면 EC2 prod인스턴스에 배포되도록 분기처리하였다.

실제 회사에서 클라우드에 서버를 배포/관리하는 로직을 슬쩍 본 기억이 있는데, 이와 유사한 방식이었던 것으로 기억했고 나도 같은 방식으로 구현해보고 싶었지만 실력이 부족하여 하지 못했었다.

하지만 이번 기회를 통해 이렇게 개발 서버와 운영 서버를 분리하는 경험을 할 수 있어 너무 유익한 시간이었다.

 

 

---

🔥 앞으로의 Develop 방향

 

✨ 결제 기능

아직 해본 경험은 없지만, 결제 모듈은 금전적인 부분이 들어가는 예민한 기능이기 때문에 추가를 위해 많은 공부가 필요할 것으로 생각된다.

하지만 언제나 그렇듯 우리는 해낼 것이다.

 

✨ AutoScailing

대학 강의에서 간단히 배웠던 EC2 AutoScailing을 다시 학습하여 적용해보고자 한다.

이전에 적용했던 오토 스케일링은 간단한 서버에 대해 적용했던 경험이었기 때문에, Blue/Green방식으로 정교하게 배포해놓은 지금과 같은 서버의 구조는 아직 어떻게 확장성을 쥐어줘야할 지 가늠이 안된다.

하지만 이 또한 해낼 것이다. 세상에 안되는 것은 없다.

 

✨ 관리자 아티클 작성 기능

지금은 DML을 사용해 DB 아티클 데이터를 삽입하고 있는데, 관리자 아티클 작성 페이지와 관련 API가 추가될 예정이다.

서버측에서 시간 여유가 생기면 관련 기술 학습을 통해 간단한 아티클 작성 페이지 정도를 개발하게 될 수 도 있는데, 어떻게 되던 화이팅해볼 예정이다.