2021-07-21Lectures & Seminars18 minutes read (About 2667 words) 0 visits

[웨비나후기]7월 우아한테크세미나 : AAA

웨비나 소개 및 후기

아키텍처라는 말에 어려울까봐 지레 겁먹고 웨비나를 듣지 않으려고 했다.
하지만 현재 회사에서 MSA로 진행중이며 인프라와 아키텍처를 구축하는 팀장님들이 겁나 멋있어보였기에 궁금해졌다.
나도 언젠가 팀장님들처럼 척척 만들어보고싶다고 생각하면서 중간에 듣다가 너무 어려우면 알고리즘이나 풀어야지하면서.
그러나 왠걸. 너무 재밌다!

특히 레거시와 요구사항의 문제상황을 주고 15초동안 이 문제를 어떤 순서로 풀어갈 것인지 생각하는 부분에서 정말 많은 것을 배웠다.
연사님은 문제상황을 척척 해결해나가는 슈퍼개발자였다. 정말 멋있고 나도 그렇게 되고 싶었다.
웨비나 듣길 정말 잘했다.

Software Architect 두 분류

Architectus Reloaded
- 시스템의 무결성을 보장하는 한 명의 아키텍트
- 아키텍트 혼자 유일한 결정권자이기때문에 아티텍트가 처리해야 할 업무가 프로젝트의 병목이 됨
- 초반에 결정되고 다른 사람들은 그 계획을 따라가는 구조
Architectus Oryzus
- 프로젝트의 전반이 어떻게 돌아가는 지를 잘 알고, 이슈들을 발견하고 큰 문제가 되기 전에 미리 조치를 취할 수 있는 사람
- 개발자의 협력을 이끌어내는 아키텍트
- 개발팀의 멘토 역할을 하고 개발팀의 수준을 높여서 더 복잡한 이슈를 해결할 수 있도록 만드는 사람
- 한마디로 가이드!

좋은 아키텍트가 되기 위해서는 항상 공부해야한다.
연사님의 공부방법은 아래와 같다.

인프런
Medium
Likedin: 좋은 아티클 공유
Udemy: 한 달에 유료 강좌 1개정도는 들으려고 노력함
Book: 읽었던 기술 서적을 정리해 놓으면 좋다. ex) Lighthouse

Architecture란?

노련한 개발자가 나눠주는 시스템 디자인에 대한 이해
변경하기 힘든 것들
쉽게 바뀌어서는 안되고, 충분히 이해하고 만들어야 하면서도 중요한 것들

MSA패턴이 무조건 좋은 건 아니며 쿠버네티스를 쓴다고 다 MSA가 아니라고도 말씀해주셨다.
차라리 잘 키운 모노리스 하나 열 마이크로 서비스 안 부럽다고 한다.

사례1: CI/CD없는 4년된 사용 프로그램을 오픈소스로 전환하는 프로젝트

어떤 순서로 접근하면 좋을까?

스프링부트를 띄어서 가장 어려운 서비스부분을 PoC(Proof Of Concept: 사전에 검증하는 것)함
Jenkins를 써서 CI/CD부터 구축
OOP(Object-oriented programming: 객체지향 프로그래밍)/DDD(Domain Driven Design) 설계
설계는 아키텍트, 개발은 외주업체 용역
- 여기서 설계란 메소드, 클래스
- 외주업체 개발자가 아예 클래스를 만들 수 없도록 구조를 만듬. 만약 클래스 만들고 싶다면 아키텍트와 상의 후 아키텍트가 직접 배치를 고민하고 만들지 결정함)
DB 어려운 조회는 VIEW로 만들고 CQRS
- CUD는 JPA
- R는 MyBatis
애자일방식으로 진행하며 TODO LIST는 스크럼방식 사용

사례2: B2C인데 장애가 많고 바로 배포하는 프로젝트

1달만에 장애보고서 2번쓸 정도로 숫자가 맞지않고 개발하면 바로 배포하는데 공유하지는 않으며 코드리뷰는 하지만 설계는 하지 않는 상황.
어떤 순서로 접근하면 좋을까?

애자일이라서 항상 배포하는 게 맞지만 이건 전제조건이 있음. 단위테스트와 DDD, 통합테스트가 잘 되어있어서 CI/CD안에서 자동화되어있을 때 바로 배포할 수 있음 -> 그래서 정규배포로 변경함
User Story를 다시 작성함. 다시 AC(액셉턴스 크리테리아: 참과 거짓을 판단할 수 있는 명확항 문장)작성함.
- 우아한 ATDD 영상 추천 : https://www.youtube.com/watch?v=ITVpmjM4mUE
- User Story(Value Statement, Acceptance Criteria, Definition Of Done 포함)를 먼저 개발자가 작성 -> PM에게 확인을 받음 -> 소스 코드작성.
PO님과 핫도그를 먹으며 현 문제점과 해결을 위한 지속적인 노력함. 대화를 정말 많이했음.
DB를 같이 보면서 숫자를 맞춤
코드리뷰보다는 설계리뷰를 해봅시다
- 코드리뷰는 후행적이다

사례3: 10년이 넘은 레거시 프로그램으로 부하가 극단적으로 많은 프로젝트

새로운 시스템도 기존의 시스템과 연동해야 하며 Oracle중심으로 이루어져있고 수강신청시스템처럼 부하가 극단적으로 왔다갔다하는 상황.
어떤 순서로 접근하면 좋을까?

여기서 Oracle중심이라는 의미는 비즈니스 로직이 대부분 오라클에 있다는 뜻으로 변경이 까다롭다는 의미이다. 배우면서 하는 프로젝트는 생각보다 더더더 굉장히 빡시다는 것을 깨달았다고 하셨다.

극단적으로 부하가 왔다갔다하니까 서버리스가 훨씬 효과적일 수 있음 -> NoSQL로 선택
근데 서버리스로 가면 Java랑 맞지 않음 -> why? 워밍업시간이 오래걸림
따라서 node로 진행 -> But java개발자들이 바로 node로 업무하기에는 버겁기때문에 typescript를 사용
타입스크립트로 DDD -> java개발자들에게 도움을 주기 위해 직접 예시를 작성함
리액트를 새로 배울 시간에 그냥 템플릿 구매함으로서 프로젝트 시간 절감
오라클을 최대한 유지하면서 이벤트만 사용

사례4: 공통모듈이 있는 MSA인데 코드리뷰없고 단위테스트도 없는 프로젝트

어떤 순서로 접근하면 좋을까?

배포 의존보다 코드 중복이 나을 수 있음
- 공통모듈은 비즈니스 로직이 빠져있으면서도 절대 바뀌지않을 애들(유효성체크등)만으로 만들어야 함.
- 만약 이를 어긴 채 비즈니스 로직이 있는 공통모듈을 배포한다면 배포폭풍이 일어남.
- 차라리 코드중복이 낫다.
시스템 비용의 80%는 유지보수에서 나옴 -> 오픈소스로 감당할 수 있을지 오픈 소스 도입전 충분히 생각해야함
비즈니스 코드가 기술보다 더 중요할 수 있음
코드리뷰, 단위테스트도 없기때문에 소나큐브를 사용함
- CI할때 인텔리제이에서 Sonarqube 플러그인 설치하거나 CI 과정중에 자동화된 것을 넣는 것도 좋은 방법!

QnA

MSA로 전환할 때에 도메인, 조직의 규모, 모듈/서비스별 스케일 등을 고려하여 전환 전략을 짜고 분리된 시스템간의 상호작용을 어떤 방식으로 가져갈지를 선택하게 될 텐데, 이에 대해 참고할만한 가이드같은 것이 있을까요?

서비스를 잘못나눠두면 엄청고생하니, 먼저 크게 나눠놓고 모듈러 모노리스로 시작해서, 서비스를 정확하게 분리해야하는 상황이 오면 분리하세요
조직이 워터풀이거나 프로젝트기간이 정해져있거나, MSA 전환에 있어 strict한 개발방법론을 사용하면 안 맞을 수 있어요
작은 스타트업에서 홀로 백엔드 개발을 하고 있습니다. 가끔은 제 아키텍쳐의 방향이 올바른지 코드는 직관적인지 리뷰를 받고 싶은데 이런 활동을 할 수 있는 한국의 커뮤니티 플랫폼이나 유료 서비스가 있을까요?

저자에게 직접 연락해 조언을 요청하는 것도 방법입니다. 이메일을 통해 사정을 설명한 뒤 도움을 주실 수 있는 지 물어봤습니다. 누가 먼저 와서 도와주지 않기 때문에 내가 먼저 다가가서 물어봐야 합니다
개발 방법론을 언급해 주셨는데, agile 관련 전문성도 있으신데, 한 마디 해주세요 :)

칸반. 스크럼 등 잘 들여다보고 우리 조직에 무엇이 맞을지를 생각해봐야 할 것같습니다
비즈니스에 가장 많은 가치를 줄 수 있는 것에 가장 많은 우선순위를 두고 개발을 하게되는데, 여기에 애자일을 쓸 때 더 가치있습니다