[TechNews] 유용한 개발 관련 아티클 및 영상 #20

1. 유용한 개발 관련 아티클 및 영상 #20

---

에이비엔비 아키텍처의 역사(A Brief History of Airbnb’s Architecture)

• 초기 버전(RoR 기반의 모놀로식 아키텍처)
  • 이러한 구조로 인해 다음과 같은 장점들을 느낄 수 있었음
    • 시작하기 쉬우므로 초기에 반드시 필요한 구조였음
    • 민첩한 개발에 적합했음
    • 복잡성을 관리할 수 있었음
  • 하지만 엔지니어링 팀이 빠르게 커짐에 따라 다음과 같은 상황들이 생겼음
    • 코드들이 더욱 긴밀하게 결합되기 시작했고 데이터의 소유권이 불분명해졌음
    • 예를 들어, 어떤 테이블이 어떤 애플리케이션 기능에 의해 소유되는지 파악하기가 어려웠음
    • 모든 개발자가 애플리케이션의 모든 부분을 변경할 수 있게 되면서 변경 사항을 추적하고 조율하기가 어려워졌음
  • 이로 인해 다음의 문제들이 발생했음
    • 항상 수백 명의 엔지니어가 모노레일에서 작업하고 있었기 때문에 배포가 느리고 번거로웠음
    • 에어비앤비는 각 엔지니어가 변경 사항을 테스트하고 프로덕션에 배포하는 책임이 있기 때문에 변경 사항이 서로 상충되어 큰 혼란이 발생했음
    • 엔지니어링 생산성이 떨어지고 개발자들 사이에서 불만이 높아졌음
• SOA로의 진화
  • SOA는 클라이언트가 일종의 게이트웨이에 요청을 하고 게이트웨이가 이러한 요청을 여러 서비스와 데이터베이스로 라우팅하는 느슨하게 결합된 서비스 네트워크임
  • SOA를 도입함으로써 서비스를 개별적으로 구축 및 배포할 수 있게 되었고, 서비스는 독립적으로 확장할 수 있으며 소유권이 보다 명확하게 정의되었음
  • 그리고 체계적인 접근 방식으로 서비스를 설계하기 위한 원칙을 정하여 준수했음

 

출처: https://medium.com/@mananshah3654/a-brief-history-of-airbnbs-architecture-bce6d0405f9c

 

 

 

애자일 이야기: 팔방미인의 고뇌

• 주변에는 다양한 관심사 때문에 괴로워 하는 친구가 종종 있고, 이런 경우에 "팔방미인이 제대로 하는 건 하나도 없다"(Jack of all trades, and master of none)는 표현을 쓰곤 함
• 하지만 명시적으로 범주를 구분하고, 기존의 범주구분에 맞지 않는 사고를 하면, 그것은 사회에서 쉽게 공격당하거나 불편을 당하게 됨
• 그리고 이런 경험을 몇 번 하다보면 편하게도 아예 사회적 범주틀에 고스란히 들어맞는 생각만 나게 됨. 범주는 우리에게 사고의 도구가 되기도 하지만 동시에 사고의 족쇄가 되기도 함
• 하지만 이것 저것 잡다하게 공부한다고 생각했던 사람이 실은 한 덩어리를 공부하고 있는지도 모르는 법임

출처: https://web.archive.org/web/20230324174007/http://agile.egloos.com/2580241

 

 

 

.NET 개발자가 시도해보고 느낀 Spring 생테계

• 해당 유튜버는 보안 관련을 좋아해서 Spring Security로 시작함 (하필...)
  • 공식 문서가 너무 부실하다고 함
  • 검색하면 자주 나오는 유명한 리소스인 baeldung도 별로라고 함
  • "What the fuck is a bean?"이 웃겼음 Spring이 역사가 오래된 만큼 고유의 용어들이 많은데 이런 사소한 용어들이 진입장벽으로 작용하는거 같음
  • 결론은 Spring Security는 별로고 .NET이 훨씬 낫다
• 다음으로 JPA를 시도해 봄
  • 처음에는 Spring Boot의 starter를 써야 한다는걸 몰라 해맴
  • 스프IntelliJ의 도움으로 JPA까지 설치하고 CrudRepository를 만드는데 method 이름을 바꿔서 동작 안 함... (findAll -> list)
  • 뭔지 모르겠고 그냥 튜터리얼에 나온대로 method 다 지우고 JpaRepository 만들었더니 됨! 여기서 감탄함 .NET에서는 이 과정에서 많은 boilerplate 코드가 필요하다고 함
• 결론적
  • Spring은 자동으로 마법처럼 자동으로 되는 것이 너무 많아 아는 사람은 편하지만 역설적으로 진입장벽이 너무 높은거 같다고 함 (Convention over Configuration)
  • 또 공식 문서나 블로그의 질이 안 좋다고 함

 

출처: https://www.youtube.com/watch?v=wRep_S7oVIA&pp=ygUeZG90IG5ldCBkZXZlbG9wZXIgdHJpZXMgc3ByaW5n

 

 

 

Event Driven Architecture에서 Event와 Message의 차이

• 전달되는 정보의 차이
  • Event는 상태의 변화라는 사실을 전달함
  • Message는 다른 서비스에 기능 처리를 위한 요청을 전달함(Command와 Query와 유사함)
• 통신 토폴로지
  • Event는 다른 서비스가 사용할 수 있도록 broadcast 되며, 일반적으로 pub-sub 패턴을 사용함
  • Message는 정해진 두 서비스 간의 상호작용으로 이루어짐
• payload의 오너십
  • Event의 경우 payload는 발행한 서비스에 의해 소유됨
  • Message의 경우 payload는 구독한 서비스에 의해 소유됨
• 응답 처리
  • Event는 응답을 기대하지 않으며 Fire and Forget 방식으로 동작함
  • Message는 경우에 따라 응답을 블로킹하거나 비동기 방식으로 응답을 기다릴 수 있음

 

출처: https://medium.com/simpplr-technology/event-driven-architecture-the-hard-parts-events-vs-messages-0fcfc7243703

 

 

 

전문가의 함정

• 전문가의 필요성
  • VC들이 도입하는 벤처파트너는 주로 특정 분야의 전문가를 영입해서 이 분야의 회사를 발굴하고, 검토하고, 실사하고, 투자하는 역할을 하는 사람들임
  • 벤처파트너가 필요한 이유는 특정 단계를 지난 회사를 검토할 땐 그 분야에 대한 지식, 경험, 그리고 네트워크가 어느 정도 필요하기 때문임
  • 이런 한계에 부딪히면 이 분야에 대한 전문가 영입에 관해서 이야기를 해보는데, 결국엔 하지 말자는 같은 결론으로 돌아옴
• 전문가의 한계
  • 대부분의 많은 전문가들은 본인들이 아는 것만 알고, 모르는 건 너무 모르는 경향이 있음.
  • 그리고 본인들이 모르는 걸 모른다는 걸 잘 인정하기 싫어하고, 별로 알려고 하지 않음.
  • 워낙 똑똑하고, 그 분야에 대해서 공부도 많이 했고, 경험도 많기 때문에, 본인들이 모르거나 처음 접하는 건, 거의 즉각적으로 “저건 안 돼요.” , “내가 전에 비슷한 걸 해봐서 아는데, 안 되는 거예요.” 등의 반응을 보임
  • 한 분야에 대해서 오랫동안 공부하고, 생각하고, 경험한 분의 통찰력을 빌리기 위해서 전문가의 도움을 받는 건데, 오히려 미래의 가능성에 투자해야 하는 벤처 투자 결정에 방해가 되는 경우가 잦음
• 전문가의 함정을 역으로 이용하기
  • 특정 분야에 대한 전문가가 그 분야의 스타트업에 대해서 절대로 안 된다고 하면, 오히려 그런 회사에 투자해야지 크게 성공할 수도 있음
  • 한 명의 전문가가 안 된다고 하면, 이 분야의 다른 전문가들도 안 된다고 할 확률이 높고, 이럴 경우, 많은 VC들이 이런 의견을 기반으로 투자하지 않을 확률이 커질 것임
  • 오히려 이런 회사에 투자하면, 그리고 우리가 예상하지 못 한 다양한 요소와 우연이 일어나고, 여기에 운까지 작용해서 이 회사가 성공한다면, 역사에 남을 대박 투자가 될 수 있음
  • 이 글은 특정 분야의 전문가들을 비난하는 내용도 아니고, 벤처 파트너 프로그램을 비난하는 내용도 아님. 아주 뛰어난 전문가들도 많고, 벤처 파트너 프로그램을 잘 운영하는 VC도 많지만, 그 동안 이 업을 하면서 관찰한, 전문가들이 자신의 생각과 경험에만 빠져서 다른 큰 기회를 놓칠 수도 있다는 현상에 대한 고찰임

 

출처: https://www.thestartupbible.com/2024/05/the-expert-fallacy.html