4월 8일 리뷰 세션

• event sourcing은 event가 다수 발생했을 때 rollback 하기 위함인것 같은데, 현재 정적호스팅 상황에서는 3단계 (runBuild, createUrlRecord, createHttpCert)만 필요하니까, 그냥 rollback은 코드 상에 넣어도 되지 않을까요? (3단계 실패하면 1,2단계 rollback 하는 식으로)
• AWS 의존성 걷어내고, 추상화하는 것을 예제 코드로 설명 (아래 첨부)
• 계획하고 계신 headless CMS (서버를 no-code로 제공)과 정적 빌드 호스팅은 서로 의존성은 없는 듯. 별개 서비스로 생각
• 별개 서비스라도 한 github repository에 들어가 있는것은 ok. 나중에 routing 별로 인스턴스를 다르게 연결해서 load balancing 가능.
• 기본적으로 instance handler, URL record handler, HTTP cert handler 를 따로 따로 만들고, 서로가 서로를 전혀 모르게 만드는 아키텍쳐가 중요할 듯. 그걸 위해서 서로 소통할 때 이벤트를 주고받게 할 수도 있고, REST를 써도 되고, 그거는 상황에 따라서 적합한 기술을 사용 (직접 계획하고 구현해 보면서 고민 해 봐야...)
• 뭔가 기술/아키텍쳐를 채용할 때 "~~가 불편해서, ~~를 택했다" 라는 분명한 이유가 필요한데, 이에 대한 고민이 더 있었으면 좋겠어요.
• (재혁,현정님) 향후 Headless CMS 에는 squarespace 같이 프론트 요소를 눈에 보이게 옮길 수 있는 식의 서비스로도 확장할 수 있지 않을까 생각하심
• => 그거는 이번 1달동안 하시려는 서버단 API를 노코드로 제공해 주는것과는 완전 별개의 서비스가 될 거 같다.
• 현업 엔지니어 입장에서 봤을 때는 기존 서비스 유지가 안 되고 코드를 다 엎어버린건 조금 아쉽... 기존 것은 일단 유지하면서 새로운걸 만들어서 porting 하는 식은 어려웠을까요...? (현업에서는 어떻게 새로운 버전으로 옮겨갈지 고민도 많이 하기 때문에...)
• 질문 답변
  • 초기 설정 단계에서 어느 정도의 확장성을 고려하면서 프로젝트를 진행하는 게 맞는 걸까요?
    • Software Engineering at Google => 모든 코드의 생명은 다르기 때문에 그거에 따라 다르다...
    • 프로덕트가 얼마의 생명력을 가질건지, 그 안에서 어떤 기능들이 추가될 수 있는지 등등을 따져서, 그에 맞게 시스템 디자인을 한다.
    • 무한한 확장성을 고려하면 기반을 만드는데 시간이 너무 많이 걸리니까, 예를 들자면 일단 2년 동안 유지될 만큼을 가정해서 만들어 놓고, 새로운 기능을 붙이게 되면 그때가서 다시 고치는게 좋을지, 미리 그거도 고려해서 시간이 더 걸려도 확장 가능하게 짜는게 좋을지, 비교해가면서 최적의 방안을 찾는게 엔지니어의 고민
    • 일단은 향후 작업자들이 몇달 후에 또 이어받아서 할 거니까, 그 작업자들이 어떤 기능을 추가하고 싶을지를 예상해서 그거 정도를 커버할 수 있는 정도의 설계를 하는게 적합할 거 같아요.
    • 이 부분은 지금 재혁님과 현정님이 서비스의 방향성을 새로 정립하고 있으니까, 앞으로 서비스가 어떻게 크면 좋을지 (재혁 현정님 + 그리고 향후 작업자들에 의해서) 큰 그림을 그리시고, 그에 따라 결정되는게 좋을 듯 합니다.
  • 이벤트 기반 아키텍처를 초기에 적용할 때 생각해야 할 점이 있을까요?
    • event sourcing이랑 event driven architecture의 차이점?
    • 이게 근본적으로 왜 필요한지에 대한 고민?
    • event sourcing은 현재 상황에서는 다수의 step이 존재할 때 rollback을 쉽게 하기 위한 용도이고, event driven architecture는 요소들 간의 decoupling을 위한 것 같은데. => 참고 https://codeopinion.com/event-sourcing-vs-event-driven-architecture/
    • 현재 event sourcing 디자인 짜신거에서는 urlRecordHandler가 자기 앞 순서가 instanceHandler라는 점을 알아야 할 거 같은데요?
    • AWS 의존을 제거하기 위해 관심사 분리가 중요한 것. 꼭 event driven architecture나 event sourcing이 아니더라도...
    • 제가 봐 온 event-driven architecture의 use case는 대용량 log를 쌓을 때 Kafka 이용, 혹은 다수의 async worker들이 queue를 subscribe 하면서 message를 가져가서 오래 걸리는 job들을 처리할 때 등.
• 외부 로직 분리 예제

function createBuild() {
	buildUrl = runBuild(githubRepoUrl, npmVersion, envValues)
	createUrlRecord(buildUrl, userPublicUrl)
	createHttpsCertificate(userPublicUrl)
}

function runBuild(githubRepoUrl, npmVersion, envValues) {
	# AWS 관련 코드 하나도 없도록, "AWS를 모른다"
	status = buildService.run();
	if (status != 200) {
		orchestrator.send(buildFailed!);
	}
	orchestrator.send(buildFinish!);
}

• 지금은 노션, 깃헙 리드미, 슬랙 등 현재 진행상황과 앞으로 계획 등이 흩어져 있는데, 요걸 좀 정리하고 한 군데만 계속 최신화 하도록 해 놓으면 리뷰어가 세션 전에 파악하기도 좋을거 같고, 다음 작업자에게 넘겨줄 때도 편할 거 같습니다
• 아니면 작업중인 브랜치 공유만 미리 해주셔도 될거 같아요~~