혼자 작업하는 것과 같이 작업하는 것에 엄청난 차이가 있다

혼자 작업을 한다는 것은 나의 잘못이 타인에게 퍼질 일은 없을 뿐더러

하다가 도저히 못하겠다 싶으면 그냥 레포지토리를 삭제하면 된다. 응?

같이 작업을 하면서, 혹은 앞두면서 가장 두려운 것은

누구의 실수로 인해서 코드가 로직이 박살이 나는 것이다.

협업을 하면서 실력이 상대적으로 낮은 사람의 입장에서 (물론 협업을 할 수 있다는 동일한 능력 선상에서) 더 편하다.

반대로 도메인에 대해서 조금이라도 더 고민해보거나

먼저 프로젝트를 시작하고 협업자가 나중에 참여하는, 오픈소스 같은 환경에서는

처음에 코드 베이스를 가지고 있던 사람의 입장에서도 불안하고,

나중에 협업에 참여한 사람의 입장에서도 모두 불안하다.

뭐, 아무튼 이번 글은 K-NET 동아리에서 디스코드 봇 스터디 같은 프로젝트를 하면서

앞으로 참여하게 될 사람들을 맞이하기 위해서 제목과 같이 모노레포를 구성하는 도전기를 작성한 것이다.

현재 상황

discord-bot-general에서 현재 구현된 상황은 이렇다.

현재 상황

아직 기본적인 기능은 구현하지 않은 상태라 dev 브랜치로 분기하지 않은 상황이다.

디스코드 애플리케이션에서는 따로 개발 전용 토큰을 제공하지 않기 때문에

각각 배포용 애플리케이션과 개발용 애플리케이션을 만들어 사용자 입장에서 구축해야한다.

그러다보니, 현재 AWS에서 구축한 부분을 복제해

배포용과(main 브랜치) 개발용(dev 브랜치)으로 나눠, 만들어야한다.

복제 후 요청을 처리할 lambda를 dev용으로 다시 설정해야한다(integrated request)

현재까지 알아본 바로는 AWS 컴포넌트 중에서 복제가 가능한 것은 AWS API Gateway 밖에 없었다.

AWS의 CloudFormation을 이용한 방법도 있었지만, 스케일링을 할 필요까지는 없어서 일단은 새롭게 만들었다.

AWS Lambda는 기존에 main 브랜치에서 개발되어온 만들어진 이미지 컨테이너 URI를 통해 만들 수 있었다.

이제 남은 것은 AWS ECR을 새로 빌드해 올리는 것인데 아직 안했고,

머리를 정리하려고 글을 썼다.

Future

계획한대로 한다면 앞으로 이런식으로 될 예정이다.

API Gateway를 하나로 만들어, POST 메서드를 각각 하나씩 만들어

하나의 Gateway로 운영 할 수도 있다는 생각도 해봤지만,

앞으로 이 봇이 단순히 Webhook을 이용한 봇 서비스를 외에도

내부에서 API에서 다른 람다를 호출하는 형식의 서비스 확장이 충분히 이루어 질 수 있으니,
(REST 형태의 마이크로 서비스 or ARN을 참고해 다른 AWS 컴포넌트 호출)

분리하는게 맞다고 생각한다.

정리

하나의 레포로 정식 릴리즈와 개발 단계의 애플리케이션을 만든다는 생각에

“이게 모노레포(mono-repo)인가?” 라는 생각도 들었지만,

생각해보니, 아직은 모노레포 단계는 아니고

방금 언급한 마이크로 서비스를 구축하면 디스코드와 직접 맞닿아 있는

현재의 람다 함수(discord-bot-with-webhook)를 공유하는 서비스를 중심으로

여러 다른 함수나, 컴포넌트가 추가되면 그렇게 될 것 같다(라는 상상을 했다).

…

파이썬 교육을 핑계로 디스코드 봇 강의를 진행중인데

이게 마치 프런트-백엔드 같은 느낌인가 싶다.

앞으로 기능을 추가하는 다른 사람들이 백엔드의 백엔드니깐, 내가 상대적으로 프론트엔드가 맞나?

간단하게 진행할 줄 알았던 이 교육이 내 욕심으로 이렇게까지 AWS 서비스와 브랜치 전략까지 도달하게 될 줄 몰랐다.

ㅋㅋ