# 인프콘 당첨
처음으로 인프콘 2024 에 당첨되어 인프콘에 갔다왔다.
사전 신청자 1만 명 중, 수용 가능한 인원 1천800여명이라고 하니.. 당첨되는게 어려운 것 같다.
회사동료들과 같이 신청했지만.....ㅋㅋㅋ 운좋게 나만 당첨이 되어서 갔다오는 후기! 🍀
# 시간표 만들기
일단 듣고싶은 발표들로 시간표를 만들었다.
# 인프콘 도착
전날 QR코드가 문자로 온다. 회사 근처라서.. 뭔가 회사가는 느낌인 것 같았지만 코엑스 들어가니까 새로운 풍경에 사람이 정말 많았다.
QR코드를 찍으면 이렇게 인프콘 쇼핑백과 함꼐 귀여운 스티커와 물, 시간표와 스템프 받는 팜플랫을 주신당!
기업부스 에서는 이벤트가 많아서 사람들이 엄청 많다...
제일 많았던건 무신사! (나도 50%확률로 굿즈를 받았다 😎)
# 인프콘 시작
오프닝을 보고 듣고 싶었던 프로그램을 들으러 갔다!
1. React Native와 함께 인프런 앱 새로 만들기 (10:30 - 11:10)
React와 React Native에 관심이 있어서 들었던 프로그램이다.
새롭게 인프런앱을 만들면서 만났던 이슈들에 대해서 얘기를 들을 수 있었다. 끄적끄적 메모를 해놨는데.. 공부를 하면서 부딪히는 일이 있지않을까? 아마도 리액트 개발하시는 분들이였으면 이슈에 대한 공유로 더 많이 알았을 것 같다. 리액트 네이티브 개발방법에는 2가지가 있다. 인프런에서는 기본 CLI 로 선택하고 코드젠을 사용해서 만들었다고 한다.
- Expo CLI : 버전 업그레이드, 네비게이션, 빌드 배포 시스템, 코드푸시, 몇몇 서드파티 관리를 쉽게 할 수 있는 Framework (추가 네이티브 모듈 사용이 불가)
- React Native CLI : 기본기능들, Native 모듈 사용가능 (다양한 라이브러리 사용할수 있음, 높은 자유도)
발표중에 기억에 남는 건 앱에서 동영상보는 기능을 서드파티에 대한 신뢰도가 낮았기 때문에 react-native-video 라이브러리를 사용하지 않고 직접 네이티브로 플레이어를 만들고 구현했다고 한다.
2. 실리콘밸리의 개발 문화 및 서바이벌 전략 (11:25 - 12:05)
Apple 다니고 있는 미쿡엔지니어 님 발표를 들으러 왔다. 실리콘밸리에서 가장 많이 사용하는 언어는? 파이썬 이라고 한다.
실리콘밸리의 개발문화 요약하면 이렇다!
- 혁신 중심 : MVP 제품개발과 신속한 반복을 통해 제품을 빠르게 출시하고 시장에서 피드백을 받아 개선해 나가는 방식
- 협업&커뮤니티 : 오픈소스 기여, 강력한 네트워킹
- 최신기술 : 최신기술과 트렌드를 빠르게 받아들이고 제품에 적용, 고도의 자동화, 다양한 업무 도구
- 스타트업 정신 : 도전을 장려하는 문화, 적극적인 Risk Taking
- 다양성과 포용 : 다양한 배경의 인재, 포용적인 문화
- 꾸준한 자기개발 : 최첨단 기술의 빠른도입,멘토링과 피드백
3. 경력이 늘수록 CS이론이 중요해지는 이유 (12:20 - 13:00)
개발자의 기본기에 대해서 다시한번 생각해보게 되었다.
| 기본기 충실 | 기본기 부족 |
| 새로운 프레임워크가 놀랍지 않음 | 새로운 프레임워크가 나오면 다시 학습모드 |
| CS근본은 여전히 변함없음 | 원리와 별개로 표면 현상을 암기 |
| 상대적으로 환경전환이 매우 수월함 | 상대적으로 환경전환이 다소 어려움 |
CS 공부를 하지 않으면 결국 개발자로 살아가는동안 후회를 한다.
- 모든 개발자에게 CS이론은 중요하다 (성능, 장애대응, 설계)
- 최초 나느 왜 개발자가 된 것인지 다시 생각해볼 것 (취업, 밥벌이, 개발자)
- 분야에 따른 차등을 인정하더라도 최소한의 지식은 필수 (더 잘 해내고 싶다면...)
목표에 대해 진지하게 다시 생각해 볼 것
- 애초에 나는 어떤 이유로 갭라자가 되려는 것인지 스스로에게 질문
- 앞으로 얼마나 오랫동안 개발자로 살아갈 것인가?
- 다양한 분야에 대해 알아가고 자기 분야에 대한 '독보적' 전문성 확보
4. 멀티패러다임 프로그래밍 언어의 시대: 객체지향과 함수형을 섞어야할 때! (14:00-14:40)
프로그래밍 언어는 과거에 주로 함수형 언어, 객체 지향 언어, 절차지향 언어로 나뉘었다.
그러나 오늘날에는 이러한 경향이 바뀌고 함수형과 객체지향 기능을 모두 가진 하이브리드 프로그래밍 언어가 나오기 시작하면서 이제는 Java, C#, Scale, TypeScript, JavaScript, Kotlin, Swift 등 대부분의 주요 프로그래밍 언어들이 멀티패러다임 언어가 되었다.
타임스크립트로 Tagged Templates를 만들면서 멀티패러다임으로 개발하는 사례를 소개해주셨다.
👀 예시로 직접 라이브코딩 해주셔서 더욱더 기억에 남았다.
5. 클린 스프링 : 스프링 개발자를 위한 클린코드 전략 (15:00 - 15:40)
클린코드 뿐만이 아니라 개발자로서 어떤 팀원 어떠한 사람이 되어야 하는지 생각해볼 수 있는 시간이였다.
기술을 통한 성장은 곧 클린 코드 이다.
Clean Code That Works! 작동하지 않는 클린 코드는 없다.
클린 코드란?
- 읽기 좋은 코드
- 이해하기 좋은 코드
- 확장하기 좋은 코드
- 유지보수하기 좋은 코드
유지보수하기 좋은 코드는 확장하기 좋고, 안전하고, 신뢰할 수 있고 좋은 성능으로 발전시킬 수 있고, 상호 호환성이 뛰어나서 변경하기 쉽다. 개발 생산성과 유지보수성은 서로 영향을 주는 관계이다. 부채가 지속적으로 효과를 발휘하려면 리팩터링(부채상환)이 동력이 되어야 한다. 시작은 어떻게할까? 개발 시작은 빠르고 간단하게가 좋다. 일부 기능을 완벽하게 만드는 것으로 시작하지 말자.
- 익숙한 기술로
- 핵심 기능이
- 동작하는
- 가장 단순한 코드를
- 리팩터링 하기 좋게 작성
내가 만드는 도메인에 필요한 기술을 빠르게 만드는것이 중요하다. 유지보수성과 생산성의 균형을 잡아줄 리팩터링을 잘하려면?
테스트코드를 작성하라.
나만을 위한 클린코드는 없다. 클린코드의 많은 원칙은 상황에 따라 다른 기준을 가지고 있다.
팀과 함께 결정하고 탐험하고 학습하고 성장한다 -> 탐험하는 과정(새로운 경험)
Grate teams make great people.
좋은팀을 만들면 그속에서 좋은 팀원(사람이) 된다.
6. 하루에 1억 건 이상을 처리하는 견고한 포인트 시스템 구축하기 (16:00-16:40)
버즈빌의 (리워드 광고 플랫폼) 에서 개발하면서 개선하는 과정을 설명해주셨다.
포인트 시스템의 요구사항을 개발해야 한다면 '데이터 모델링을 어떻게 할까?' 라는 생각이 들었다.
여러문제가 나올때마다 개선하는 과정이 이 정말 일하면서 느꼈던 그대로라 집중해서 들을 수 있었다. MySQL vs NoSQL 대해서 고민이라던지, DynomoDB 선택, 분석계 분리 DynamoDB -> Data lake(S3) 이야기를 들을 수 있어서 좋았다.
- 단일 테이블 설계로 트랜잭션 제거
- 2회 -> 1회로 쓰기 횟수 최적화
- 낙관점 잠금을 통해 잠금 획득/반환 비용 제거
- 관리형 NoSQL 서비스 사용을 통해 분산처리 구현을 위임
7. 지난 4년간 6번의 무진장 행사를 통해 성장한 DevOps 이야기 (17:00 - 17:40)
무신사 SRE팀 이야기를 들을 수 있었다. 장애경험을 통해 느낀점과 앞으로 해결할 문제들에 대해 이야기 했다.
무신사의 트래픽은 메인 LB 기준 분당 10만~100만 단위의 요청이 있다고 한다.
Scale-Up vs Scale-Out
일반적인 상황에서는 기존 워크로드의 Scale-Out만으로도 충분하다. 하지만, 평소의 10배 이상의 요청을 처리해야 한다면? 200, 300대 넘는 인스턴스를 Blue/Green 배포라도 한다면..? Scale Up을 해야한다.
너무 작은 인스턴스
- Subnet의 IP는 충분한가?
- GC를 사용하는 런타임의 어플리케이션은, Heap이 지나치게 작으면 Major GC가 일어날 가능성이 높아짐
- DB의 커넥션 개수 제한 : 어플리케이션의 Connection Pool * 최대 Scale-Out 대수
너무 큰 타입을 요청하면
- 확보 가능한 인스턴스 타입별 수량 부족 - 높은 타입의 인스턴스일수록 확보 가능한 대수가 적음
- 어플리케이션이 실제로 인스턴스의 자원을 전부 소비 가능한지?
- 64GiB 인스턴스에 Max HeapSize 2G짜리 어플리케이션이 실행된다면? 비싼 인스턴스가 무용지물
- 인스턴스가 아무리 커도, Port 수는 똑같다 (자원을 많이줘도 네트워크는 하나이기 때문에)
적정 스펙 산정은 어렵다.. 이전 무진장 세일 전/후 트래픽의 변화량을 측정
-> 최근 평시 트래픽에 단순 대입해 보며 예상치를 측정했지만… 생각보다 맞지 않음
예상 필요 CPU Core 수 : 92
실제 사용 CPU Core(Max) : 62
결론은 Over Provisioning (a.k.a 안전빵)
이벤트 오픈 이후에 실시간으로 증설 계획을 반영하자!
CPU 사용량을 기반 증설의 한계로 인해 부하 발생 시, 증설이 될 정도로 CPU를 사용하는지 확인이 필요해서
K6 부하 테스트(Spike ,stress, Breakpoint 등) 도입 하였고 Datadog를 활용해서 결과를 확인한다.
장애경험을 통해 느낀점
- DB는 항상 어렵다
무진장 관련 장애 중 가장 많은 Case : Connection 부족, CPU Load, Long Query로 인한 지연 등 - 어떻게 해결했나? 모놀리식 DB를 분리
- 무한정 부하를 받을 수 있는 DB는 없다
지속적인 튜닝, 부하 분산, 적절한 Cache와 같은 정공법으로 해결해야 함
# 후기
정말 좋은 경험이었다. 혼자가서 네트워킹이나 이런건 하지 못했지만.. 빠짐없이 듣고왔다!
온라인 말고 첫 오프라인에서 컨퍼런스라서 더욱더 기억에 남을 듯 하다. 그리고 귀여운 굿즈들도 get...😊
일을 하면서 고민했던 내용들을 다시한번 생각해보는 계기가 되었고 좋은 생각과 영향을 받았다.
'기록' 카테고리의 다른 글
| 내가 Velog에서 Tistory로 옮기는 이유 (2) | 2024.08.17 |
|---|