이름	Pleos25 (aka 현대차 컨퍼런스)
일시	2025년 3월 28일 (금) 10:00 ~ 18:00
장소	삼성 코엑스
홈페이지	https://devcon.hyundaimotorgroup.com/2025
일정

현대차그룹에서 진행한 컨퍼런스를 임직원으로 참여했다. Pleos는 쉽게 말해 자동차용 App 생태계이다. 이번 컨퍼런스 자리에서 그 생태계가 공개됐다.

기존 iOS/Android 와의 차이라면 "차량데이터"를 기반으로 app과 인터랙션 할 수 있다는 것이 특징이다. 따라서 "개인화"된 맞춤 앱이 실효성이 있지 않을까라고 생각했다.

키노트 때 포티투닷 & 현대차 송창현 사장이 먼저 기조연설을 진행하고 뒤이어 파트너사들이 중간중간 제품을 소개한다. 실제 제품들은 데모상태임을 감안해도 큰 기대가 되진 않았다.

또 다른 키워드는 역시나 AI 였는데 포티투닷의 자체 AI 기능을 통해 길안내, 문자 보내기, 리마인더 등이 가능할 것으로 보였고 네이버에선 네이버지도를 바탕으로 한 AI를 소개했다. 그 외에도 삼성의 SmartThings를 이용해 자동차와 핸드폰의 연결, 즉 핸드폰으로 내 차량 찾기 등이 가능해질 수 있다고 한다. 외에도 앱 생테계다 보니까 게임이 빠질 수 없었고 Unity, Microsoft 뿐 아니라 ProtoPie처럼 앱 디자인 툴도 참여했다. 

전시에서는 자율주행과 관련한 내용이 많았는데 현대차의 자율주행버스가 인상 깊었다. 관공서나 운수회사에서 사용하는 fleet 개념은 다양한 차량들을 원격제어 할 수 있는 형태로 버스, 택시의 운행기록, 사고 감지, 운전 점수, 공조장치 컨트롤 등 다양한 기능을 중앙 통제가 가능하도록 되어있었다.

이 외에도 다양한 프로그램이 존재했는데 특히 핸즈온 세션에서는 Pleos SDK로 제공되는 라이브러리를 이용한 Android 개발도 손쉽게 할 수 있었다. 

다만 추첨제가 아닌 신청하면 모두 올 수 있는 구조라 인파가 너무 몰려 정작 들어야 할 Track session은 못 들었다는게 함정..(4월 중 온라인 공개 예정)

자바공화국 배민도 Nest.js를 사내 공식 개발 프레임웍으로 지정했다는데..

장점

- 공식 문서 깔끔 (https://docs.nestjs.com/)
- DI, IoC, 데코레이터 등 OOP 개발에 용이
- 기능별 모듈화를 통한 직관적인 개발, 확장 가능성, 유지보수 용이한 개발 가능. -> 생산성 향상
- Typescript 기반으로 컴파일 오류 방지, 테스트 코드 작성에 용이하므로 TDD를 쉽게 적용 가능. (Express에서의 ts 세팅보다 매우 간단)
- Spring 과 유사한 UX로 추후 이벤트 플랫폼 개선시 유사한 아키텍처 구조 사용 가능.
- 아주 간단히 Swagger 초기 세팅으로 코드 수정시 자동 반영 (https://jhyeok.com/nestjs-swagger/)
- Webpack HMR로 필요한 부분만 비동기 핫 리로드 지원.
- Node Http 프레임워크 선택가능 (express, fasify ..)

단점

- 처음 접하면 러닝커브가 높을 수 있다.
- Express에 비해 작은 생태계, 낮은 점유율 (이지만 바짝 쫓아옴 2023.04 기준 Express 6만, Nest 5.5만 스타 - https://github.com/VanoDevium/node-framework-stars) 

와 이제 역전함~!

- 기획전 프론트에서 직접적인 DB 접근을 하지 않기에 ORM 사용 등에 제한적
- 동일한 기능을 위한 코드가 express보다 길다.

결론

프로젝트 성격에 따라 취사선택 해야 한다.

유연하고 확장성이 높은 Express는 작은 규모, 적은 기능의 어플리케이션이 적합하다.

반대로 Enterprise급, 여러 개발자가 빈번하게 기능 개발 등이 필요할 땐 Nest.js가 적합해보인다.

그러나 개인적으로.. 굳이 Nest.js 쓸 필요 있을까? 스타트업의 기술스택으로는 적합할 수도 있겠다. 초기 개발자가 적을 때 프/백 같이 할 수 있는 js/ts로 개발할 수 있으니. 근데 nest.js는 인력 풀이 좁아서 회사가 성장함에 따라 spring으로 바꾸는게 국룰이라 생각한다.

ChatGPT 피셜 :

Q) Nest.js 에서의 디버깅은 어렵다?!

A) 주로 아키텍처 및 디자인 철학의 차이로 인해 Express에 비해 Nest.js에서 디버깅이 더 어려울 수 있습니다. 다음은 Nest.js에서 디버깅이 더 어려운 것으로 간주될 수 있는 몇 가지 이유입니다.

1. 추상화 계층: Nest.js는 데코레이터, 모듈 및 종속성 주입과 같은 추가 추상화 계층을 도입합니다. 이러한 추상화는 응용 프로그램 구축에 대한 체계적이고 조직적인 접근 방식을 제공하지만 오류를 추적하고 디버깅할 때 응용 프로그램의 흐름을 이해하기 어렵게 만들 수 있습니다.
2. 복잡성: Nest.js는 프레임워크를 처음 사용하는 개발자가 탐색하고 이해하기 더 어려울 수 있는 더 복잡한 아키텍처를 가지고 있습니다. 이로 인해 학습 곡선이 길어지고 디버깅 중에 문제의 근본 원인을 찾는 것이 더 어려워질 수 있습니다.
3. 스택 추적: 추가 추상화 및 기능으로 인해 Nest.js의 스택 추적은 때때로 Express와 같은 단순한 프레임워크에 비해 해석하기 어려울 수 있습니다. 이로 인해 오류의 원인을 정확히 찾아내기가 더 어려워질 수 있습니다.
4. 툴링: Nest.js 에코시스템이 성장하는 동안 더 오래 사용되어 더 큰 커뮤니티가 있는 Express와 동일한 수준의 성숙한 디버깅 및 프로파일링 툴이 아직 없을 수 있습니다.

즉, Nest.js의 디버깅은 본질적으로 Express보다 어렵지 않습니다. 문제는 주로 프레임워크 설계의 차이와 Nest.js에서 도입한 개념에 대한 개발자의 친숙도에서 발생합니다. 개발자가 Nest.js에 더 익숙해지면 시간이 지남에 따라 디버깅이 더 쉬워집니다. 또한 Nest.js는 디버깅 프로세스 중에 개발자를 지원할 수 있는 훌륭한 문서 및 도구 지원을 제공합니다.

• Spring 과의 비교 https://blog.naver.com/PostView.naver?blogId=biud436&logNo=222611201210&categoryNo=201&proxyReferer=

<참고>

- https://blog.logrocket.com/nestjs-vs-express-js/
- https://velog.io/@leo3179/Nest.js-%EB%A6%AC%EB%B7%B0
- https://velog.io/@cm961115/NestJS-%EC%95%8C%EC%95%84%EB%B3%B4%EA%B8%B0
- https://choseongho93.tistory.com/318

https://tv.naver.com/v/33919001

발표 요약

: 장애 대응 최적화를 위한 네이버 검색엔진 시스템의 개선기 소개

AS IS - TO BE

기존은 각 프로세스의 배치 주기가 있기 때문에 이상 징후를 탐지하기 위한 시간 딜레이가 의사결정을 하는데도 영향을 주며 이로 인한 사용자들에게 장애 피해 발생.

기존 시스템의 문제점

1.기존 경보 시스템은 라벨을 직접 생성해서 모니터링 DB에 저장하고 있으며 다시 DB를 조회해 경보를 발송하고 있었음.

→ 이를 지표수집기가 자동으로 라벨을 생성하고 시계열 데이터 베이스에 저장하여 경보 발송.

2.전체 경보 처리가 될 때까지 경보 발송에 지연이 생기는 구조

→ 메세지큐 도입으로 실시간 스트리밍 처리. 기존 3분까지 걸리던 파이프라인을 1분 미만으로 단축.

3. 사용자 요청에 따라 쿼리를 조절할 수 없는 문제, 지표가 어떤 과정으로 계산된 것인지 알기 어려운 문제 등 존재

→ 시계열 DB를 활용해서 개발 편의성 개선 및 쿼리 커스텀 기능 제공

개발 편의성 개선
- 지표 계산을 위한 로직을 고수준 쿼리에서 처리 → 간결성
- TSDB 쿼리 및 템플릿들을 테이블로 관리 → 선언성
쿼리 커스텀 기능 제공
- 사용자 요청 시점에 TSDB로부터 지표 조회 → 실시간성
- 텍스트 템플릿을 사용한 TSDB 쿼리 변형 → 유연성

4. 기존 텍스트 템플릿은 사용자 요청에 따라 동적 쿼리 변경을 목적으로 하지만 중복이 생길 수 있고 핸들링하기에 시간 소요가 많음.

→ Victoria Metrics의 MetricsQL을 적용하므로써 강력한 기능인 With 템플릿을 사용하여 해결

위의 개선이 이루어지더라도 네이버같이 수천만이 이용하는 서비스에서는 TSDB 사용시 속도저하가 일어날 수 밖에 없음..따라서 API Server와 TSDB간의 성능개선 실시

오컴의 면도날(Occam's Razor)은 복잡한 현상을 설명할 때, 그 현상을 가장 적은 가정과 개념으로 설명하려는 원칙. 즉, "가장 간단한 설명이 가장 그럴듯한 설명이다" 라는 뜻

이름	Data pipeline with Open Source Kafka
일시	2024년 6월 29일 (토) 13:00 - 18:00
장소	지티플러스 9층 CCoE
홈페이지	http://www.gtplus.co.kr/about/notice/52
일정

• 카프카의 커넥터는 https://www.confluent.io/hub에서 다운받을 수 있음.
  free license말고 사내에선 confluent kafka를 쓰니까 commercial license까지 가능할듯? (어차피 제네럴 한 것들은 다 free임)
• KRaft 통해 더 이상 Zookeper를 사용안해도 될 듯? 이중관리를 안해도 되고 (사실 우리가 하는건 하니고 담당팀에서 하시겠지만...)
  성능도 월등이 뛰어나다고 함. 장애 조치도 매우 빨라짐
• 발표자료

이름	KotlinConf'24 Global in South Korea
일시	2024년 6월 29일 (토) 13:00 - 18:00
장소	건국대학교 학생회관 2층 Prime Hall
홈페이지	https://infcon.day/session/
일정

코틀린의 공식 컨프가 아닌 국가별 커뮤니티 세션.

jetbrain이 후원하니 얘네 스티커는 많이 받게 된다. 연사에 안드로이드 개발자가 많이 참여한 것 같다. 

Kotlin Compiler K2가 나옴 → 프론트와 백엔드도 코틀린 컴파일러가 다르다고 함.(wasm도 가능)

Frontend Intermediate Representation (FIR) 피르라고 읽음

제약을 포함한 스마트 캐스팅이 된다. 그리고 inline Lamda에서 스마트 캐스팅이 된다!!

|| 뒤에도 상위 타입으로 추론이 됨.

왜 자료 흐름 프레임워크에 중점을 두나요?

• 제어 흐름을 기술하는 것은 개발자의 주요 업무
• 스마트 캐스트는 인지 부하를 줄여준다
  • 추가적인 언어 구성은 없음
  • 점진적인 확장 가능

when 구문에서만 함수형 언어의 "가드" 개념을 도입하게 됨.

이름 기반 비구조화에서 componentN 호출하지 않도록 한다고 함 (2.2부터 가능할듯)

dataarg class  라는 것이 나옴. → 기본 함수의 파라미터만 바뀔 때 오버로드 하지 않도록 기존 파라미터를 Extendable

error object  가 도입이 됨. 대신 이 유니온 타입은 에러를 담을 때만 사용할 수 있다.

원시타입이나 참조타입 대신 Value Class 를 사용하는 방법을 이야기함 (코틀린 1.5 이상)

객체를 생성하지 않기 때문에 오버헤드가 없음.

• @JvmInline  어노테이션을 붙여야함. 
• 기본 생성 함수는 equals(), toString(), hashCode() 만 존재한다.
  • copy(), componentN() 이 없다. 
• 불변타입은 1개만 허용한다.
• === 레퍼런스 비교를 불허한다

발표 자료 공유

박준수(Version Catalog) - https://speakerdeck.com/junjaboy/gradle-version-catalog-with-kts-kotlinconf24-global-v0-dot-1

김희망(Project Valhalla) - https://speakerdeck.com/esperar/project-valhalla-value-class-gimhyimang

김용욱(Kotlin 2.0) - https://speakerdeck.com/dalinaum/recap-kotlin-language-features-in-2-dot-0-and-beyond-michail-zarecenskij

이선협(Kotlin Script) - https://speakerdeck.com/kciter/kotlin-script-hwalyonghagi

권혁준(Expressive Kotlin) - https://speakerdeck.com/davidkwon7/refactoring-to-expressive-kotlin

안성용(KMP Success + androidx room) - https://speakerdeck.com/fornewid/android-jetpack-supports-kmp

곽의진(Compose Multiplatform animation & sensor) - https://speakerdeck.com/kwakeuijin/tap-it-shake-it-fling-it-sheep-it-the-gesture-animations-dance

이름	World IT Show 2024(WIS 2024)
일시	2024.4.17(수) – 4. 19(금), 3일간
장소	코엑스
홈페이지	https://www.worlditshow.co.kr/main/main.php
일정

매년 코엑스에서 진행되는 월드 IT 쇼를 갔다왔다.

삼성, LG, SKT 등 대기업부터 아주 작은 소규모 스타트업까지 다양한 기업에서 참여한다.

3일간 아무때나 부스를 돌아다닐 수 있지만 나는 주로 부대행사에 초점을 두는데 이번에 꽤 흥미로운 아이템들이 보였다.

Software 뿐만 아니라 ICT, 헬스케어, AI, 로봇 등 다양한 IT 분야의 신제품 및 솔루션들이 출품하기 때문에 소비 트렌드를 읽을 수 있고 인사이트를 넓히는데 도움이 된다.

기억에 남는 아이템들은 모바일 여권 Trip.Pass

그로스 해킹 올인원 서비스를 표방하는 A/B 테스트 솔루션 핵클.

핵클은 회사로 초청해서 이야기도 들어봤다.

카메라 설치만으로 비전/음성 기반 생체 신호를 포착해 맥박, 호흡, 심리적 스트레스를 측정하는 엠마헬스케어

사이버펑크에 가까웠던 안구건조증 치료기 누리아이

수어를 텍스트로, 텍스트를 수어로 변환해주는 바토너스

이름	PostgreSQL Meetup SEOUL #1. PostgreSQL 100% 활용법
일시	2024년 4월 17일 18:30 - 20:30
장소	삼성역 섬유연합회 2층 컨퍼런스홀 C3룸 (서울 강남구 테헤란로 518)
홈페이지	https://www.meetup.com/pgmeetupseoul/events/300140824
일정

1. PostgreSQL Opensource에 기여하는 방법에는 코드 커밋만 있는 것이 아니라 테스트도 있다.
   어차피 postgres는 C로 만들어져서 잘 모름..PostgreSQL은 RDB가 아니라 ORDB라고 하는데 (객체 관계형 DB) 그렇게 써본 적이 없다..내가 느끼는 다른 oss rdb와 다른 점은 pg/sql로 함수 만들기가 쉽다..? 프로그래밍 하는 느낌
2. Logical Replication은 SQL문으로 말아주기 때문에 이기종간 복제가 가능하고 Physical Replication은 저장소에 저장하기 직전 단계를 가져와 복사한다. (바이너리 레벨에서 동일)
   Fail Over는 시스템 장애시 자동으로 백업 시스템으로 전환하는 기능이다. (Slave Node에서 stand by 상태가 active로 변경되는 것)
   발표하시는 분이 엄청난 고수라는 걸 느꼈다. 세션 마치고 현장에서 질문 20~30 개를 막힘없이 대답하심
   나는 클라우드 네이티브에서의 PG사용에 대해 질문했는데 그분 답변이"Cloud Native 환경에서의 Scale in, out은 어플리케이션이나 미들레벨에서 가져가야지 DBMS 레벨에서 가져가면 안된다. "라고함. 도커 이미지로 빠르게 부팅할 수 있는 클라우드 환경과 데이터를 복제해서 정합성을 보장해야 하는 DBMS는 스케일링하는 차원이 다르기 때문인 듯..
   미들웨어를 플렉서블하게 구성해야 한다고 이해했다.
3. PostgreSQL의 Extension중 하나인 Apache AGE 라고 하는 것에 들었다. PG는 Extension community가 매우 잘 되어 있고 활발하다고 한다. AGE를 설치하면 그래프 데이터베이스로써 사용할 수 있게 되는데 쉽게 말해 일반 RDB의 Row 형태로 보기 힘든 데이터를 그래프 형태로 데이터를 가공해 표현하는 것이다. 데이터 분석 쪽에서 유용하게 쓰일 수 있다고 생각했으나 개발자 레벨에선..? 전혀 쓸 일 없을 듯.. 아무튼 익스텐션은 잘 되어있는 걸로 

이름	Gitlab Korea 밋업 #18 - VSM으로 완성하는 DevSecOps와 SlackBot 자동화
일시	2023년 11월 28일 19시
장소	강남파이낸스센터 21층 대회의실 (개꿀)
홈페이지	https://festa.io/events/4332?q_mailing_7TZRproaY7L87HMKcwfbwHKXcbqy1uMLm8ybD=Rnv3wydphTEADua8Ni8dKQN8dJ1SxHVMRkt6fGYdBYzbcWuTRXJpjDCPm
일정

<GitLab X InfoGrab : DevOps>

1. DevOps VSM 소개
* VSM이란?
Value Stream Management

예를 들어 업무에 대한 백로그를 그루밍하고, 담당자를 할당하고, 코드 커밋을 하고, QA하고
 배포 하는 모든 일련의 과정을 보려고 하는 것임

Value Stream : 개발 생산성을 높여 지속적인 고객가치 제공을 위한 흐름, 이를 개선하는 프로세스
구글의 DORA4 에서 평가 기준을 만듦. 정량적(속도, 안정성), 정성적 평가가 존재
Gitlab Value Stream Analystic : 일에 대한 트래픽이 얼마나 몰리는지 확인할 수 있다.
Analystics Dashborad를 통해 데이터를 측정, 가시화
PR을 머지까지의 소요시간을 보고 어떠한 업무가 오래 걸릴 수 밖에 없었는지 확인 및 대비 가능하게.

warp up => 낭비(다운타임)을 줄이고 자동화(업타임)을 늘려 고객 만족 획득 기회 늘어남.
낭비 - 재작업, 반복작업, 고객에게 필요없는 고퀄작업, 오버 프로덕션, 대기시간, 불필요한 작업 등

---
GitLab을 통한 CI/CD를 이용한다면 이에 대한 플로우와 데이터를 시각화하여 보여주는 기능같음.

2. 자동화 구현 시연 
Triage 라는 봇을 활용해 MR 시에 openai api를 이용해 챗GPT가 코드 리뷰를 진행하는 과정을 데모로 진행.
정책에 의해 이슈 관리 자동화를 시도함.
라벨, due date등이 자동으로 설정

빌드, 패키지, 테스트, 보안검사 등을 파이프라인 자동화 진행을 통해 VSM 개선

Gitlab Compliance 프레임워크 : 파이프라인을 다양한 어플리케이션에 주입(유료)

3. 사내에서 업무 협업툴로 wiki를 사용하는만큼 노션 자동화엔 그닥 얻을 건 없었다는 점

밋업이 끝나고 다른 개발자 분들과 네트워킹을 했는데 재미있었다.

이름	OpenTRS: 프론트엔드 개발자라면 지금 바로 알아야 할 Front-End 취약점 극복 방안
일시	2023년 9월 14일 (목) 16:00 ~ 19:00
장소	더에셋빌딩 18층 (네이버D2SF) , 서울 서초구 서초대로74길 14
홈페이지	https://event-us.kr/theori/event/69964
일정

<프론트엔드 보안 위협 어떻게 극복할까?>

Part 1. Securing the Front Lines: Protecting Front-End Applications from Overlooked Vulnerabilities

• 왜 지금 Front-End 취약점이 중요할까요?
• Real world에서 발견된 Front-End 취약점 사례를 살펴보고
• 대응 자동화 방안 시연(데모)합니다
• Front-End security 에서 빼놓을 수 없는 "CSP" 에 대해서도 짚어드려요!

* nodejs 환경변수에 있는거 번들링 할 때 다 주입되나?
ex) process.env.TOKEN
* nextjs의 _buildManifest.js 안에 들어있는 routing navigation은 다 보인다.
* 디버깅을 위한 source map -> 위험하다고 하는데 외부 공개가 얼마나 위험한지?
-> apm 툴을 이용해서 source map을 넣어 디버깅하는게 best practice

* Content integrity (CSP, SRI)
-> src 태그에 integrity hash 하드코딩 하는 이유
-> 근데 로드하지 못하는 경우가 있는 리스크
-> headless browser 를 통해 먼저 스캐닝하고 시뮬레이션 해보고 가용성 확보해라.
CSP를 통한 외부 도메인으로부터 불러온 리소스 디텍션.

Part 2. How (Not) to Sandbox Node.js: vm2 Postmortem

• vm2 라이브러리 구현을 분석하고
• vm2 취약점의 case study를 해봅니다.
• vm2 사용 사례와
• vm2를 통해 OSS 의존성 및 공급망 보안 문제를 살펴봅니다

* vm 안에 어떠한 context라도 넣으면 
-> js로 만들어진 js패키지는 안전할 수 없다고 생각한다고함.
vm2를 사용하는 라이브러리를 사용하는 라이브러리 쓰면 개발자 잘못?
Q) 그럼 보안담당자가 어떻게 사전감지?
A) 현실적으로 모두 audit하는건 불가능..deploy cycle에 security가 들어가야 하는 것아닌가

Part 3. 보안적 관점에서의 Front-End 자격증명 정보 관리와 브라우저 데이터 저장소 선택의 장/단점

• 적절한 자격 증명 정보 관리와 브라우저 데이터 저장소 선택이 중요한 이유는 무엇일까요?
• Front-End 자격 증명 정보 관리와 브라우저 데이터 저장소 선택의 장단점을 살펴보고
• 공격 시나리오로 인해 발생 가능한 문제(Front-End 자격증명 정보 관리 취약점)의 장단점과 해결 방안을 제시합니다.

* JWT
* cookie, local-storage, session-storage 
* XSS는 아실거고..CSRF 아시나요

이름	Microsoft X GitHub Roadshow 2023 - Level Up with GitHub Copilot & Codespaces
일시	2023년 5월 15일 (월) 13:00 ~ 17:30
장소	코엑스 컨퍼런스룸 3F 300호
홈페이지	https://infcon.day/session/
일정

4가지 세션으로 이루어진 Github Codespaces 기반의 데모 위주 밋업이었다.

마소에서 각 세션에 대해 라이브 코딩을 진행하는 대담함을 보였으나 역시 오류 뻥뻥(...)

Microsoft는 Azure를, GitHub은 Codespaces와 Copilot을 홍보하는 자리.

라이브 데모 레포 : https://github.com/Azure-Samples/gh-codespaces-copilot-in-a-day-ko

Codespaces 데모 레포 : https://github.com/gh-productivity-workshops/PetSpotR

코드 버튼 클릭 후 Codespaces 탭에서 새 Codespaces를 생성하면 됨.

Codespaces는 브라우저 기반 IDE로 보임.(workspace 대신 code spaces!) 

Visual Studio Code와 같은 UI를 사용함. Extension 설치도 가능함. 별도로 로컬에 VSC를 설치하지 않아도 웹 브라우저 내에서 IDE를 사용한다는 점에서 편리해보임.

개발 자체를 Codespaces를 이용하고 Github Action등과 같은 서비스 연계, Credential도 public하게 관리하지 않는다는 것을 보여줌.

OpenAI와 Microsoft 협업으로 Azure AI라는 것을 만들어둠. ChatGPT API를 이용하는 것

Resource에 대한 정의는 json이나 yaml을 사용하지 않고 Microsoft에서 만든 bicep을 사용함. BICEP 확장자에 대한 이야기 (https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/overview?tabs=bicep)
GitHub Copilot을 잘 사용하기 위해선 주석을 잘 작성해야 함. 주석으로 명령을 하고  몇 초 뒤 작성코드의 예시를 뿌려줌. 그러나 작성해준 그대로의 코드를 온전히 사용한 적은 별로 없는 듯. Copilot은 완벽한 코드를 만들어주는 것이 아니라 내가 Review를 한다는 느낌으로 작성하라고 함

Codespaces 자체는 훌륭해보임(VSC user 한정). 컨테이너 환경이기 때문에 config잘 설정해두면 중복으로 설정할 필요가 없음. 즉 개발자마다 각각 개발환경을 구축할 필요가 없다는 점에서 starter kit의 역할을 해줄 수 있을듯. Docker container처럼 실행환경을 fix하는 것이 아니라 개발환경을 fix하는 것의 차이. 다만 브라우저 기반이라 사용하지 못하는 단축키가 많을 듯..?

이름	HashiCorp Strategy Day
일시	2023년 4월 11일 (화) 14:00 ~ 17:30
장소	양재 엘타워 6층 그레이스 홀
홈페이지	https://events.hashicorp.com/KRstrategyday2023
일정

우리 회사도 하시코프의 Vault를 사용하고 있다. 실무 적용과 관련해  Security실 김용재님이 직접 세션을 진행하였다.

하시코프의 공동창업자 겸 CTO인 '아몬 데드가' 라는 분이 직접와서 키노트를 진행한다길래 흥미가 생겨 참가하였다.

입장하자마자 다양한 다과와 음료, 샌드위치 등을 줘서 점심 못 먹고 참여한 사람이 좋아했을 듯.

메가존 클라우드 등 하시코프 제품과 연계해 솔루션을 제공하는 업체들이 각종 굿즈를 줬다. (아주 만족)

key note

- 다양한 클라우드 환경에서 인프라는 일관적인 접근방식을 취해야한다.
- As-is : 인프라 작업은 ticket 별로 ops의 작업을 기다려야함. 일주일씩 지나가버린다.
- To-be : ci/cd 파이프라인, api 구축 등으로 automation 하여 언제든 작업 가능.
- 자기네는 4가지 중요한 영역에 적합한 제품이 존재
Provisioning - Terraform, Packer. Packer를 통해 클라우드 플랫폼 종속성 탈피
Security - Vault(Machine to Machine), Boundary(Human to Machine)
Connectivity - Consul
Runtime - Nomad / K8S, Waypoint 

전세계 수천의 고객이 있으니 한번 츄라이 츄라이

Zero-trust

- 기본적으로 믿지 않는 다는 것
- Explicit authority, Default Deny Policy
- 기존의 모놀리틱 구조에서는 방화벽 안에만 있으니 웹서버의 계정, db의 계정이 그 안에 하드 코딩 되어있는 것이 괜찮았다. 허나 클라우드 환경이 되어가면서 외부 어택을 고려해야함. 
- 기본적으로 deny하고 인가된 계정만 allow 하는 것이 실용적이다.
- 또한 ip 기반으로 방화벽하던 모놀리틱 구조와는 달리 클라우드 컨테이너 환경에서는 ip만으론 변경이 잦기에 통제하기 어렵다. 따라서 identity based Control로 가야한다. 

김용재님 발표 세션
- Valut 만능 아니다.
- custom 반드시 필요하다. 현업에서 어떻게 적용해야 하는지 현실적으로 설명하심.

유튜브에 관련 영상이 올라왔다!(자막을 달아줄 법도 한데..)

그 뒤에 아모레퍼시픽 세션부터는 이슈 대응을 하느라 참여하지 못했다..

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

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

이름	오라클 밋업 - 폭주하는 트래픽을 오라클 클라우드로 안정적으로 처리한 올리브영 사례 알아보기
일시	2023년 3월 22일 (수) 14:00 ~ 15:00
장소	한국오라클 (아셈타워 15층)
홈페이지	https://eventreg.oracle.com/profile/web/index.cfm?PKwebID=0x823746abcd
일정

올리브영 x 오라클 밋업. 한시간 남짓 짧게 열린 밋업 세션.
* 올영 세일은 분기당 1회, 연 4회. (우리는 이제 빅 페스타 등으로 매달,,)
* 올영 인프라팀의 미션 : 올영 세일 기간 때만 인프라 확장을 통한 트래픽 감당
1. network -> 탄력적 증설 불가
2. server(ap) -> 탄력적 증설 가능
3. db -> 탄력적 증설 불가 -> 이게 문제

* 참고로 이당시 올영은 MSA가 아닌 모놀리틱 구조임.

해결 선택지도 3개
1. DB H/W 증가 -> 비싸
2. opensource DB -> 응 안돼
3. MSA 구축 -> 되겠니

mysql 처럼 Replication 구성하면 ?
1. 구성하기 위한 방법 CDC(Change data capture) -> Oracle GoldenGate
2. Replica License
3. Application 수정
- Dynamic Datasource : 동적으로 datasource 수정
- Spring AOP : @ReplicateDataSource 같이 어노테이션 만들어서 분기 처리 할 곳에 사용하기.

-Replication 적용할 때 insert/update 같은 DML 사용하면 Exception발생하니 주의.
-모든 어플리케이션에 걸지 말고 필요한 거에만 top20 적용.
-GoldenGate도 sec단위 지연 발생하니 결제 같은 critical service에서 사용하면 안됨.
-상품 전시, 리뷰, 검색, 쿠폰 등에 적용 가능.

그럼 결국 select 부하만 줄인건가? 만약 insert/update 트래픽이 늘어난다면?
-> 이커머스 특성상 트래픽의 90% 이상은 select 할 때 발생. 따라서 replication 전략이 가장 효율적



요새 OCI에 대해 저렴하게 좋은 기능을 제공한다는 평이 많다.
이번 기회에 자세하게 알아볼 수 있어서 좋았다.
실제로 우리회사는 모놀리틱 구조가 아니기 때문에 현실적으로 적용할 것은 별로 없었지만 만족한다.

일단 추천 알고리즘이 들어가기 시작하면 매우 복잡해진다. 여기선 아주 단순하게 구현할 수 있는 방법을 적어본다.

실시간으로 현재 인기 있는 게시글 상위 10개 정도를 추천하기 위해서 판단 기준이 필요하다.

• 구매순
• 조회순
• 좋아요순
• 댓글순

활동 로그를 이용한 실시간 적재

유저가 좋아요, 구매 등이 발생하면 이 테이블에 로그를 기록해 둔다. 

ACTIVITY_LOG_TABLE

Index는 POST_NO, CREATED_AT 두 컬럼을 사용한다.

유저가 게시글에 구매, 조회, 좋아요, 댓글이 달리면 기록하기 위한 테이블인데 물론 행동이 발생할 때마다 1 row씩 삽입하는 건 꽤나 비효율적일 것이다. 그래서 Redis 같은 Cache Store에 먼저 등록해 두고 일정 주기로 DB로 insert 할 수 있도록(Write-Back) ACTIVITY_CNT 컬럼을 두었다.

Redis 사용 전략

Value를 increment 만큼 증가시키는 HINCRBY 커맨드를 사용한다.

# 특정 사용자(77777)에 대해 views 증가
HINCRBY post:metrics:{postNo}:{userId} views 1

# 좋아요와 댓글은 삭제가 발생할 수 있다. 삭제 API 호출시에는 -1을 increment 해준다.
HINCRBY post:metrics:{postNo}:{userId} comment -1

# 모든 사용자 키 검색
KEYS post:metrics:{postNo}:*

다만 현재 키 계층구조에서 게시글 이후의 업데이트 대상 key만을 조회하려고 한다면 (모든 사용자 키 검색) 경우에 따라 사용하는 커맨드가 달라질 수 있다.

KEYS 커맨드는 Cluster Mode에서 사용할 수 없다. 정확히는 목적지 Node를 명시해야 해당 Node 에서만 탐색이 가능하다. 따라서 이 상황에서는 SCAN 명령어를 통해 조회하는 편이 낫다.

HGETALL 커맨드도 사용할 수 없고 키 조회 자체가 정책적으로 금지되어있다면 차라리 키만 SET에 담아서 DB에 insert 하고 지우는 방법도 있겠다.

# 메트릭을 저장할 Set 생성
sadd post:metrics post:metrics:{postNo}:{userId}
smembers post:metrics

5분 정도 주기를 설정해서 Redis에 누적된 데이터를 DB로 전송하는 스케줄링 작업을 세팅한다. 스프링 멀티모듈 사용하고 있다면 batch 모듈 만들어 작업할 수 있고 단일 작업이라 jenkins 같은 cicd 툴 이용해서 엔드포인트 호출하는 식으로 가능할 것 같다. cron 도 가능할 거고.

가중치를 이용한 분석 및 노출

특정 시간에 실시간 추천 게시글로 노출이 됐던 목록을 알아내려면 조회용 테이블이 따로 필요하다.

로그 테이블에 있는 데이터를 기준으로 조회 테이블에 데이터를 전부 다 넣고, 가중치에 따른 점수 계산을 실행한다.

그리고 기존 데이터는 inactive 상태로 변경한다. 

POST_METRICS_TABLE

Index는 POST_NO, SCORE, CREATED_AT 를 사용한다.

그리고 가중치를 조절할 수 있도록 테이블을 생성하고 admin 서비스를 통해 조절하게 한다.

POST_METRICS_WEIGHT_TABLE

그리고 초기 데이터를 넣어주면 된다.

 모바일 플랫폼의 한계

기존 운영정책 방식과 장애 대응 방식의 한계점

DevOps를 활용한 Lead Time 개선 : 사용자에게 변경사항이 전달하려면 다음 배포 일정에 도달

강제 업데이트 : 사용자 친화적인 UX가 아님

예외 사항 처리, Test Code : 외부 SDK, 단말별 이슈 등으로 모든 이슈에 대응하기 어려움

What is LiveOps?

네이버 앱의 철학과 이를 기반으로 생성된 LiveOps 솔루션

• 더 좋은 서비스를 빠르게 알리고 delivery 할 수 있도록 한다.
• 보다 안정적이고 최적화된 서비스를 운영할 수 있도록 한다.
• 사용자를 더욱 이해하고 개별 요구 사항을 충족할 수 있도록 한다.

이벤트를 Hooking하여 config에 설정한 내용을 실행시킴.  특정 타겟층만을 설정하여 해당 타겟층의 반응을 살펴보고 운영 유지 여부 결정.

Firebase remote config에서 제공하는 NRC SDK라는 솔루션의 개선버전. 미리 앱에 코드를 심어줘야하는 NRC와 달리 네이버의 NCE는 미리 코드를 심어줄 필요가 없다.

LiveOps Flow

크게 위의 3가지 side가 존재.

위 요소들을 가지고 웹 UI Server에서 조건식 설정. 

NCE(Naver Codeless Event)

Bytecode instrumentation(바이트코드 계기화)은 실행 가능한 프로그램 코드(바이트코드)에 대한 동적 분석을 수행하는 기술.

프로그램이 실행될 때 바이트코드에 추가적인 코드를 삽입하여 프로그램의 동작을 분석하거나 수정하는 것을 의미 (Scavanger의 원리)

LiveOps 도입 효과 및 향후 계획

LiveOps를 활용한 배포 프로세스NCE Event Hokking 시점 추가 및 전략 추가NCE Network I/O 기능 강화