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

 

 

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

---

애플리케이션 아키텍처와 객체 지향 (KUSG 조용호님 발표)

• 도메인 레이어를 설계하는 방법
  • 절차지향(트랜잭션 스크립트)
    • 다루어야 하는 데이터와 데이터를 조작하는 프로세스가 별도로 존재함
    • 애너믹 데이터 모델(도메일이 로직이 아닌 속성 만을 가짐)
    • 서비스들이 DAO들을 주입받고 절차적으로 작성함
    • 테이블과 모델이 1대1로 매칭되는 구조이며, DAO는 테이블 데이터 게이트웨이에 해당함
  • 객체지향(도메인 모델)
    • 프로세스와 데이터를 하나의 덩어리로 묶어서 생각하는 것
    • 객체지향 기반의 도메인 레이어 설계가 필요함
    • 주어진 책임을 수행하며 협력하는 객체들의 공동체 집합이며, 메시지로 협력함
      • 애플리케이션 계층: 애플리케이션 플로우에 대한 로직을 담당함, 애플리케이션 경계에 해당하며 도메인 로직의 재사용을 촉진함
      • 도메인 계층: 비기술적인 순수한 도메인에 대한 로직을 담당함, 보호해야 하는 대상
    • 책임 할당은 기본적으로 가장 많은 정보를 갖는 객체에게 이루어져야 함
    • 도메인 모델에서도 데이터를 읽고 써야하는 것은 동일함
• 도메인 모델을 사용하는 경우
  • 객체-관계 임피던스 불일치
    • 객체 모델과 DB 스키마 사이의 불일치, 객체 패러다임과 관계 패러다임 간의 불일치
    • 데이터 관점에서의 가장 큰 미덕은 중복 제거, 애플리케이션 관점에서의 가장 큰 미덕은 유연성 + 변경 용이성
    • 따라서 객체지향적으로 갈수록 불일치가 심해짐
  • 데이터 매퍼(ORM)의 필요성
    • 객체와 데이터 간의 불일치를 해결하기 위해 존재하는 역할
    • 객체 모델과 DB 스키마 간의 독립성을 유지시켜줌, 도메인 객체는 DB에 대해 독립적임
    • DB 모델과 객체 모델 간의 간격이 큰데, 객체지향적으로 만들기 위해 도와주는 것이 데이터 매퍼이자 ORM
• 무엇을 선택할 것인가?
  • 절차지향 방식을 사용할 경우
    • 뚱뚱한 서비스(fat service) 문제와 도메인의 재사용이 어려운 문제가 발생할 수 있음
    • 이로 인해 테스트가 어려워질 수 있음
    • 기존 코드에서 일부를 변경해야 하기 때문에 사이드 이펙트가 발생할 수 있음
    • 암묵적으로 도메인 개념이 숨겨질 수 있음
  • 객체지향 방식을 사용할 경우
    • 컴포지트 패턴 등을 통해 기존 코드를 사용하지 않고 새로운 기능을 추가할 수 있음(OCP)
    • 추상화가 높은 수준을 향하여 객체들의 의존 방향이 분리됨(DIP)
    • 추상화된 객체들을 대상으로 효율적인 커뮤니케이션이 가능하고, 추상화된 도메인을 바탕으로 도메인 계층이 탄생함
    • 클래스를 통해 도메인의 개념이 명시적으로 표현됨
    • 변경에 유연하므로 도메인 모델로 구성하는 것이 좋으며, 같이 일하는 동료들의 수준을 고려해야 함
• 현실과 이상의 차이
  • 우리는 미래의 요구 사항을 알 수 없으므로, 대부분 현재 코드는 요구 사항 변경에 적합하지 않을 것임
  • 최대한 단순하고 깔끔하게 짜고, 요구사항이 들어왔을 때 싹 바꾸는 것은 불가능함
  • 따라서 변경이 발생할 때마다 끊임없는 리팩터링을 통해 변경하기 쉽게 개선시켜야 함

도메인 모델은 복잡성을 알고리즘에서 분리하고 객체 간의 관계로 만들 수 있다. 유효성 검사, 계산, 파생 등이 포함된 복잡하고 끊임없이 변하는 비즈니스 규칙을 구현해야 한다면 객체 모델을 사용해 비즈니스 규칙을 처리하는 것이 현명하다

- 마틴 파울러 -

 

출처: https://www.youtube.com/watch?v=26S4VFUWlJM

 

 

 

크롬의 암호화를 위한 양자컴퓨팅 도입

• Google의 모든 팀은 양자 내성 암호화로의 전환을 위해 웹을 준비하기 위해 준비중임
  • Chrome 116부터 TLS에서 대칭 비밀을 설정하기 위해 X25519Kyber768을 지원하기 시작함
  • 두 가지 암호화 알고리즘의 출력을 결합하여 TLS 연결의 대부분을 암호화하는 데 사용되는 세션 키를 생성함
  • X25519: 현재 TLS에서 키 합의에 널리 사용되는 타원 곡선 알고리즘
  • Kyber-768: 양자 내성 키 캡슐화 방법 및 일반 암호화를 위한 NIST의 PQC 우승자
• 에코시스템의 비호환성을 파악하기 위해 TCP 및 QUIC을 통해 Chrome과 Google 서버에 적용하고 호환성 문제가 발생할 수 있는지 모니터링하고 있음
• 지금부터 트래픽 보호를 시작하는 이유는 특정 암호화 사용은 데이터를 지금 수집하고 저장했다가 나중에 암호화 분석이 개선되면 해독하는 'Harvest Now, Decrypt Later' 공격 유형에 취약하기 때문임
• TLS에서 전송 중인 데이터를 보호하는 대칭 암호화 알고리즘은 양자 암호 분석에 대해 안전한 것으로 간주되지만 대칭 키를 생성하는 방식은 그렇지 않음
• 즉, Chrome에서 양자 내성 세션 키를 사용하도록 TLS를 더 빨리 업데이트할수록 향후 양자 암호 분석으로부터 사용자 네트워크 트래픽을 더 빨리 보호할 수 있음

출처: https://blog.chromium.org/2023/08/protecting-chrome-traffic-with-hybrid.html

 

 

 

넷플릭스의 90초

• 넷플릭스는 구독자가 접속하고 관심을 끌 수 있는 시간을 90초라고 주장함, 90초 안에 동영상을 보지 않으면 서비스 해지할 위험이 커짐
• 그래서 넷플릭스는 구독자들이 추천 알고리즘을 사용하지 않으면 10억달러의 손실을 입을 것으로 추정하며, 추천 알고리즘은 넷플릭스의 가장 중요한 자산임
• 2006년 넷플릭스는 추천 알고리즘 경진 대회를 개최했음
  • 우승 조건은 기존 넷플릭스의 추천 알고리즘보다 10% 향상된 알고리즘을 만드는 것
• 넷플릭스는 우승한 알고리즘을 사용하지 않았지만, 대회를 통해 “알고리즘이 투자 대비 수익이 더 이상 높아지지 않는 순간”이 있다는 중요한 사실을 발견했음

출처: https://rafikiresearch.blogspot.com/2022/04/column-9020220423.html#google_vignette

 

 

 

Vertical Slice 방식으로 GraphQL 애플리케이션을 TDD로 구현하기

• Vertical Slice 아키텍처란?
  • 계층이 아니라 기능별로 구현하는 방식, 각 요청을 개별적인 유스케이스로 취급함
  • 레이어를 가로질러 커플링하는 대신 슬라이스를 따라 수직으로 커플링함, 슬라이스 간의 결합은 최소화하고 슬라이스 내 결합은 최대화 함
  • 정원 가꾸기를 계속해서 하지 않으면 기술 부채
• TDD로 구현하기
  • 기본적으로 실패하는 인수테트 작성 → (실패하는 단위 테스트 작성 → 테스트 통과 → 리팩토링) * N 방식으로 구현함
  • 설계를 고려하지 않고 절차적으로 구현해서 테스트 클래스에 구현하기
  • 테스트 코드에서 구현을 한 후에 추출해서 모델(프로덕션) 코드로 옮김

 

출처:

https://www.youtube.com/watch?v=ASSp38BguWI

https://github.com/msbaek/vsa-tdd?fbclid=IwAR0XR06XG1o2NEizrnATj2Ed8D96jEcQn04dICisUlBVyk0ckfD4ZZ7PLUo

 

 

 

Top 10 Kotlin Questions 2024(2024 10가지 코틀린 주요 질문들)

1. Kotlin에서의 람다 표현식
   1. 함수를 명시적으로 선언하지 않고도 함수와 유사한 구조를 간결하게 정의할 수 있는 방법
   2. 이를 통해 함수를 인수로 전달하거나 변수에 저장할 수 있는 코드 블록을 만들 수 있음
2. Kotlin에서 고계함수의 개념
   1. 다른 함수를 매개변수로 받거나 함수를 결과로 반환할 수 있는 함수
   2. 함수를 1급 시민으로 취급하여 함수형 프로그래밍 패러다임을 가능하게 함
3. Kotlin에서 확장함수의 개념
   1. 소스 코드를 변경하지 않고도 기존 클래스에 새 함수를 추가할 수 있는 기능을 제공함
   2. 상속을 사용하거나 원본 클래스를 직접 수정하지 않고도 클래스의 기능을 확장할 수 있음
4. Kotlin에서 Sealed 클래스의 개념
   1. 상속 계층 구조를 그 안에 정의된 제한된 하위 클래스 집합으로 제한하는 클래스로
   2. 모든 서브클래스를 미리 알고 처리해야 하는 제한된 유형 계층 구조를 표현하려는 경우에 특히 유용함
5. Kotlin에서 object 표현식의 개념
   1. Kotlin의 object 표현식을 사용하면 사용자 지정 동작 및 속성을 가진 익명 개체를 만들 수 있음
   2. 새로운 named 클래스를 명시적으로 선언하지 않고 일회성 객체를 생성해야 할 때 특히 유용함
6. Kotlin에서 reified object 표현식의 개념
   1. reified 키워드를 제네릭 타입 파라미터에 inline과 함께 적용하면, 런타임에 일반 매개 변수의 유형 정보에 액세스할 수 있음(보통 타입 소거로 인해 타입 정보는 런타임 중에 사용할 수 없음)
   2. 이를 통해 프로퍼티를 확인하거나 함수를 호출하는 등 유형에 대한 작업을 수행할 수 있음
7. Kotlin에서 delegates의 개념
   1. 프로퍼티 또는 함수의 구현을 다른 개체에 위임하는 메커니즘을 제공함
   2. 상속을 사용하지 않고도 공통 동작을 재사용하거나 기존 개체에 추가 기능을 쉽게 추가할 수 있음
8. Kotlin에서 연산자 오버로딩의 개념
   1. 연산자 오버로딩을 통해 연산자에 대한 사용자 지정 동작을 정의할 수 있음
   2. 이를 통해 +, -, *, / 등과 같은 연산자에 대한 특수한 구현을 제공할 수 있음
9. Kotlin에서 꼬리 재귀의 개념
   1. 꼬리 재귀는 재귀 함수가 최종 연산으로 자신을 호출하는 기술임, 이를 통해 컴파일러가 재귀를 효율적인 루프로 최적화하여 스택 오버플로 오류를 방지할 수 있음
   2. 꼬리 재귀 최적화를 트리거하려면 재귀 함수에 tailrec 키워드를 선언해야 함
10. Kotlin에서의 클로저
    1. 프로그래밍에서 클로저는 해당 범위의 실행이 끝난 후에도 해당 범위를 둘러싼 범위의 변수 및 매개변수에 대한 접근 권한을 유지하는 함수를 의미함
    2. 클로저는 필요한 변수를 캡처하여 저장하고 나중에 함수가 호출될 때 액세스할 수 있고, 캡처된 변수는 그 상태를 유지하며 클로저 내에서 변수에 대한 모든 수정 사항이 보존됨

 

출처: https://medium.com/@mohit2656422/top-10-kotlin-questions-2024-365bc020198f