[Conference] Google I/O Extended Incheon 송도 (24/07/28)

송도 컨벤시아에서 열린 GDG 주최 컨퍼런스에 다녀왔다!

Google I/O Extended Incheon 송도

https://festa.io/events/5477

I/O Extended 2024 Incheon | Festa!

 

연이 있는 발표자 분께서 초대권을 주셔서 다녀올 수 있었다 ㅎㅎ

사실 취준생 수준에서 알아듣기 힘든 내용이 많을까봐 고민도 했는데..

결과적으로는 다녀오길 잘 한 것 같다.

최근에 누군가 말씀해주신 컨퍼런스 발표 추천 기준을 생각해서 오늘 들을 세션들을 골라봤는데,

정말 전보다 많은 내용을 이해하고 온 것 같아 신기했다.

• 아무것도 모르는 기술, 또는 내용을 다 알것 같은 세션이라면 듣지 말 것
• 그냥 입문을 위한 설명 세션도 bad (내가 구글에서 공식문서를 읽는 게 나음. 굳이 현장에서?)
• 이 발표에 나의 생각을 바꿀만한 포인트가 있다고 생각하면 valuable함. 기술설명보다는 생각하게 하는 주제 추천. 이런 세션의 경우 현장감도 효과가 있음
• 현장감을 느끼고 싶은 주제 또는 발표자분을 직접 대면하고싶거나 질문하고 싶은 게 있을 경우

 

이대로 덮어두면 잊어버릴게 뻔하니

지극히 개인적인 관점에서 세션별 메모를 정리한다. 기억용으로!

 

 

---

 

1. 올리브영 전시영역의 꺾이지 않는 안정성

• 올영에도 자체 개발자가 있다
• 오늘 발표 내용 대부분은 올영 테크블로그에도 나와있다(올영도 테크블로그가 있는지 몰랐다,,)
• 외주를 맡기고 사용하다가 2021년 쯤부터 개발쪽에 신경쓰기 시작하기 시작한 것 같음

 

• 온라인몰의 전시영역 :
  많은 데이터를 담으며, (집계데이터를 비롯한..)
  빠른 속도를 요구하고, (3초의 법칙)
  비즈니스적(마케팅)으로도 중요한 역할을 함
• 올리브영 전시영역의 초기 아키텍처
  • 모놀리식 구조의 한계 : 커플링이 강해 장애가 전파됨 등
  • 온프레미스 : scale up, out이 어려움 -> 가용자원 모두 동원해도 세일기간 대처 어려움
  • enterprize legacy : 외주로 맡겨 사용해오던 프로젝트라 히스토리를 아는 개발자가 없음
  • 얼마나 느렸는데?
    • Main LCP90 : 3.37초
      100명 중 90명이 3.37초의 대기를 경험함 -> 3초의 법칙.. 너무 김
• 모놀리식 구조는 이런 문제들을 개선하고 테스트하기 위한 과정에 시간도 너무 오래 걸렸음
  => 빠른 개선을 위해 MSA도입 결정!

 

• MSA 장점
  • 인프라적 관점에서 유동적인 자원 조절 가능해짐
  • redis캐싱 : 성능저하 대부분이 RDB접근 영역에서 발생함을 캐치하고 도입
    • 이에 따라오는 Cache Stampede 문제라는 것이 있다고 함. 만료된 redis 키값을 사용해 데이터를 찾게 되는 상황에 대한 것..인듯.. ttl expired time?
      -> 이에 대한 대처로 Mongo DB를 같이 사용 -> 이부분 잘 이해 못했음  .. . .
• 개선된 부분들
  • 운영적 측면
    • 몽고DB 사용 -> json저장 용이, schemaless 로 유연 
    • 캐싱 데이터 세분화 : 같은 페이지 안에서도 자주 조회되는 데이터 위주로 캐싱
  • 다양한 고가용성
    • 캐시서버에 문제가 생겼을 때에도, 늦더라도 메인페이지 내용을 띄우는 것이 UX에 긍정적
      -> 서킷 브레이커..라는 걸 사용해서 redis캐시서버 - 몽고DB - RDB 순으로 응답이 없을 경우 차례로 다음으로 넘어가서 늦더라도 데이터를 받아올 수 있도록 플로우를 만듦
  • 등등..
• 그래서 얼마나 개선?
  평균 10초 걸리던 부분을 0.96초까지 내림 등

 

 

+) 나중에 내가 발표할 때 적용해보려고 발표자료를 어떻게 루즈하지 않게 구성하시는지도 봤는데,

• 영상자료를 사용하고
• 넣고 싶은 이미지가 있으면 chatGPT한테 만들어달라고 할 수도 있고
• 현실의 리얼한 멘트가 담긴 자료(댓글, 메세지, 후기 등..)
• 밈&짤 활용
• 결과 전/후 비교영상으로 보여주기
• 기술토크 마무리 후 소감이나 감상을 짧게 이야기하는 것도 괜찮은 듯
• 발표는 마지막에 3줄요약하라!는 말도 있었다

 

---

 

2. Web Application Service에서의 E2E 테스트 자동화 사례 공유

• 테스트코드 : 의도한 대로 작동하는지 확인하기 위한 코드
  • 장점
    • 살아있는 문서의 역할도 함
    • 개발자 스스로의 신뢰도 향상
    • CI/CD 파이프라인의 핵심 요소
    • 예외 처리 개선
  • 단점
    • 시간 x2 이상 (빠르게 서비스하는게 중요한 상황이라면 과감히 포기하는 것도..)
    • if 테스트가 놓치고 있는 시나리오가 존재할 경우, 개발자에게 잘못된 안정감을 주는 것이 됨
    • 테스트 규모가 너무 커져서 이해가 어려워지거나 테스트가 도는 데에 시간이 너무 많이 걸릴 수 있음
    • 테스트를 로컬에서만 돌리려고 구축하진 않음. CI 구축에도 시간이 듦
    • 잘못된 방향의 테스트에 고통받을 수 있음 ex) 내부 함수 호출 

 

• 범위에 따른 테스트 종류
  • 단위 테스트
  • 통합 테스트 : 단위테스트 + 인프라적인 요소
  • 기능 테스트 : 특정 기능 하나의 flow에 대한 테스트
  • E2E 테스트 : 회원가입부터 시작해서 유저가 경험할 수 있는 모든 기능 흐름을 처음부터 끝까지 다 해봄. 유저 관점. (기능 테스트와 E2E 테스트는 이분법적으로 나눠지기보다는 상황에 따라 쓰임)
• 목적에 따른 테스트 종류
  • 성능(부하)테스트
  • 보안 테스트 : sql injection 등... 테스트 시 보안관점에서 체크해야할 것들이 리스트업 되어있는 정부에서 제공하는 웹페이지가 있음. 찾아보자
  • 사용성 테스트 : 수동
  • 회귀 테스트 : 새로운 기능을 추가, 수정했을 때 기존 기능이 정상 작동하는지 확인하는 테스트

 

• 작성 시 팁
  • input, output 에 집착하기 보다는 이 테스트가 어떤 비즈니스를 해결해야 하는가에 집중하자! 네이밍할 때도.
  • Negative case, 예외 상황에 대한 테스트가 중요하다. 정상적인 흐름 외. ex) timezone 맞추기, 경계값 등..
  • 다양한 관점 : 유저는 우리가 예상하지 못한 순서로 조작할 수도 있음을 기억하고 테스트도 커버해볼 것
• CI 에 올려 자동화하지 않으면 반쪽짜리 테스트코드라고 할 수도 있겠죠

 

---

 

3. 기술주의자 vs 논리주의자

물리적인 기술에 기준하는가 vs 추상적인 논리에 기준하여 대상을 해석, 평가하는가

 

추상적인 것이 존재해야 구체적인 것이 존재할 수 있음

• 추상화 - 높은 수준 - 인간복잡도 높음(어려움) - 논리주의
• 구체화 - 낮은 수준 - 인간복잡도 낮음(쉬움) - 기술주의

**인간복잡도가 높다는 말은 이 글에서 사람이 이해하기 어렵다고 느낀다는 의미로 쓰임

 

ex1) 뛰어난 가수는?

• 가창력이 뛰어나고 음역대가 넓은 가수
• 가창력은 부족하지만 표현력이 뛰어나 사람들에게 감동을 주는 가수
  -> 논리주의 : 음악이 존재해야 가창력이 존재함.
  음악은 인간의 감정을 풍부하게 하는 것으로, 가창력은 감정을 풍부하게 하는 기술

ex2) 아래 두 코드는 Command Pattern일까?

// 첫번째 코드
Class SaveCommand {
	void Execute() {
    	...
    }
}

 

// 두번째 코드
Class Save {
	void Run() {
    	...
    }
}

 

• Command Pattern의 정의는 개체 자체가 명령인 패턴.
  첫번째와 달리 두번째 코드는 Command Pattern 에서 많이 쓰이는 네이밍을 사용하지 않았지만,
  개체 자체가 명령이 된다는 정의를 따르고 있으므로
  논리주의 관점에서 보면 두가지 모두 Command Pattern이 맞다.
• 하지만 두번째가 항상 옳다는 것은 아니다. 어떻게 판단하는게 자신에게 유리한지 상황에 따라 생각할 것

ex3) API로써, HTTP 통신의 단점은?

• 기술주의 : 데이터 전송 오버헤드, 비 압축 데이터 전송 시 등..
• 논리주의 : 통신계약이 너무 구체적으로 표현되어있어, 도메인에 맞게 적용하려면 무리가 많다. GET, PUT, POST, DELETE ... 이 중 어디에 넣을지 고민되는 요청들이 존재함

**HTTP 통신의 정의 : 도메인을 풀어낸 원격지의 API 호출 계약

**개발자 : 요구사항을 컴퓨터 언어로 풀어내주는 번역가

 

ex4) 아래 두 사례 모두 연속통합(CI) 인가?

• 빌드 자동화(Github Action 등으로) 사용해 통합하는 팀
• 빌드 자동화는 사용하지 않지만 매일 빌드 및 통합을 수동으로 하는 팀
  -> 연속통합 : 작업 결과물을 매우 자주 통합하는 것
  첫번째 팀은 자동화 툴을 사용하지만 얼마나 자주인지 알 수 없음. 빌드 자동화는 CI를 편하게 하는 도구일 뿐
  두번째 팀은 매일 하는 것이 보장되므로 논리주의 관점에서는 두번째가 더 연속통합을 하고 있다고 볼 수 있음

ex5) 로그아웃 API 에 대해 : 서버에서 아무 동작도 안하는데 호출을 해야할까?

-> 기술주의의 관점에서는 앞으로 발생할 비즈니스적인 요구에 방어할 수 있게 되었다고 답함(로그아웃 시 어떤 처리를 해줘야 하는 상황이 올 경우..)

 

• 논리주의자 : 높은 논리주의를 바탕으로 기술주의도 사용해 대상을 바라봄
  패러다임, 특징, 논리에 집착함. 거시적 관점. 인간복잡도 중시. 실제 가치 창출에 관심을 두고 인간적 입장에서 생각함
• 기술주의자 : 기술주의만 사용해 대상을 바라봄. 시작은 쉬운것부터 하는 것이므로 이걸로 시작하며, 여기서 10년차 이상의 극소수가 논리주의로 넘어간다고 봄
  성능, 기술, 최적화에 집착함. 미시적 관점. 시간, 공간 복잡도 중시. 신기술. 트렌드에 관심을 두고 기계적 입장에서 생각함. 특정 기술을 굉장히 사랑함

 

 

• 고급언어는 인간복잡도를 낮추기위해 등장했다.
• 클린 아키텍처의 저자 로버트 C. 마틴
  아키텍처에 대한 예시 코드는 하나도 제공하지 않았음 -> 논리주의자로서, 구체적인 건 그에게 중요치 않음을 의미

 

---

 

4. 왜 내가 만든 쿼리는 느릴까?

이 세션은 집중도 떨어져서 거의 못들었는데 ㅎㅎ.. 그래도 유의미할만한 내용만 몇줄 적자

 

• 튜닝은 복합적인 기술이다. 케이스에 맞는 방법이 있는것이지 그대로 적용한다고 다 되는 건 아님!
• 쿼리 읽는 순서 : from -> where -> on(join) -> select -> 그 외
• 클러스터 인덱스 : 인덱스 키 값을 기반으로 테이블데이터 행 전체를 정렬해서 저장
• sql의 select절에서 컬럼 순서는 성능과 상관 없음

 

---

 

5. 데이터독을 활용하여 애플리케이션에서 발생하는 모든것을 모니터링하기

사람이 계속 보고있을 수 없으니 필요해!

• Monitoring : 현재 상태에 대한 수치 확인. 내부 사정까진 x
• Observability : 시스템 내부 동작 이해에 중점. 문제 근본 원인을 파악하는 목적. 아래와 같은 효과가 있다!
  • 문제 해결 속도 향상
  • 전체 system 이해도 증가
  • 대규모 시스템 관리 가능
  • 문제 예방, 최적화

 

• APM : 서비스 전반에 걸친 문제 원인을 파악할 수 있음
  이게 없었으면 로그 하나하나 순서 생각해서 찾아가 뜯어봐야 하는데 너무 좋은 기능~
• RUM (Real User Monitoring) : 데이터독이 짱잘해줌. 사용자가 어떤 흐름으로 머물다 갔는지 화면을 마우스커서까지 그대로 보여줌

 

• 비싸지만 그만큼의 비용 절감 가능, 대학생은 공 ~ 짜 ~ 지금 써보세요!

 

 

---

 

정리는 여기까지다.

내가 컨퍼런스에서 어떤 걸 얻어가야하는지 조금 느껴졌던 날이었다!

가장 기억에 남는 발표는 기술vs논리주의자 였다. 예시들이 참 와닿았다.

나는 아직 모르는 게 정말 많고.. 공부할수록 새로운 게 계속 나오다보니
나도 기술에 집착하고 새로운 기술 신기한 기술을 자꾸 찍먹해볼까싶고 기웃거리는 느낌이 있었는데

앞으론 좀더 넓은 관점에서 공부할 수 있을 것 같다.

테스트에 대한 세션도 아직 테스트 왕초보인 나에게는 어떤 부분이 집중해야 하는지 더 이해하게 된 것 같다.

올리브영 세션같은 경험기는 항상 재밌다 히히

 

대학생 막차로 데이터독 써봐야지~~

즐건 컨퍼런스 끝!