2023 인프콘 후기

2023년 8월 15일 화요일, 인프콘 2023 에 다녀왔다.
약 7,8천명 가량이 지원하고 1700명 정도를 뽑았다고 한다. 운좋게도 당첨되었다.
 

2023 인프콘 총 평가

여러가지로 알찼던 것 같다.
열정 가득한 IT 산업 종사자들과 자리를 함께해본 경험이 이번이 처음인지라 인상깊었다.
 
가장 좋았던 점은 참여자 중심으로 설계가 되어있고, 그 부분에 대해서 고심한 흔적이 느껴져서 좋았다.
 
https://www.inflearn.com/conf/infcon-2023

인프콘 2023 - INFCON 2023

 
여기서 미리 어떤 세션을 들을지,  해당 세션에 대한 내용에 대해서도 미리 파악할 수 있고, 시간표도 짤 수 있는 기능을 제공해주어서 강의를 들을 때 수월했다. (그런데 미리 짜간 시간표대로 하나도 안들었다. 하핳)
 
정말 굳이 지적하자면, 이벤트 중복 참여 관련해서 문제가 있다고 느꼈다.
집에 와서 보니 중복 굿즈가 있었는데 현장이 정신없다보니, 참여했는지 안했는지 헷갈려서 여러번 참여한 것 같다.
이 부분 관련 시스템을 구축해도 좋을 것 같다. (컨퍼런스 참여자, 협력사 모두 공리적으로 손해인 것 같다.)
 
아무튼 정말 얻어간 것이 많았고 정말 만족했던 알찬 컨퍼런스였다.
 
또 굿즈도 알차게 많이 받을 수 있어서 좋았다.
 
짱짱한 협력사가 많아서 티셔트 3벌, 담요, 부채, 스티커, 손톱강화제, 인프콘 7주년 기념 이벤트 상품들, 우산, 수건, 휴대폰 거치대 등등... 다양한 물품들도 많이 받을 수 있었다.
 
최고.
 
인프랩에 대한 기업 비전에 대해서 좀 더 알게 된 것 같다.
참여자와 협력사, 주최한 인프랩 모두 윈-윈 할 수 있는 자리였다고 생각한다.
 

인프콘 꿀팁

굿즈 & 스탬프 잘 받는 법

부스 투어 할 때는 구글폼을 통해서 내 신상 정보들을 넘기고 좋은 굿즈를 받을 수 있었다.
턴이 빠르기 때문에, 줄이 길어도 생각보다 대기 시간이 길지 않다.
 
 

굿즈 관련

이번 2023 인프콘에서는 빨리 굿즈 소진이 된 부스가 극소수 있었는데, 일단 굿즈 소진 관련해서는 다음 컨퍼런스 때 경험이 쌓이다보면 기업 측에서 잘 준비해줄 것이라 믿기 때문에 굿즈를 못받을 가능성은 앞으로 적지 않을까 감히 예상해본다.
 
나같은 경우에는 2-3시 쯤에 부스 투어했을 때 딱 모든 것이 적당했다. (사람 수, 대기 시간, 굿즈 소진률 등)
처음 시작 할 때쯤 시간에 발 디딜 틈 없이 가장 인파가 많았고 굉장히 혼란했다. 상황 보고 유도리 있게 판단하면 될 것 같다.
 
진정한 굿즈 꿀팁은 가챠 잘 뽑을 수 있는 운이 좋은 사람이 되는 수밖에 없다. ㅠ.ㅠ
가챠로 키크론 키보드를 주거나 아니면 주사위 굴려서 인스탁스 카메라나 귀여운 컵같은거 주던데 너무 갖고싶었다.
나는 맛난 까까 받았다. 만족한다.
 
그리고 2층에는 어떤 것이 있는지도 꼭 파악하자! 
당근마켓 세션이 꽁꽁 숨어있어서 찾기 좀 어려웠다.
 

스탬프 관련

사람이 많고 줄이 길어서 시간 내로 채울 수 있을까? 라는 생각을 했는데, 생각보다 시간이 널널하니 전혀 조급해할 필요가 없다.
 

시간 배분 팁

일단 세션 모두를 듣는다는 것은 막상 가보니 거의 헤르미온느나 할 법한 발상이라고 느꼈다.
점심시간 1시간 + 부스 도는 시간 1시간 정도 잡고 2시간 정도는 여유 시간을 두길 추천한다.
정말 흥미있는 세션 3개+ 정도로 잡으면 될 것 같다.
 
 
나같은 경우에는 이렇게 미리 시간표를 짜갔는데, 식사시간도 고려하지 않고 짜서 좀 지금 보니 비현실적인 시간표로 보인다.
 

 또 내가 좀 즉흥형이라 그런지 ... 시간표를 거의 보지 않고, 팜플렛보고 즉흥적으로 가고 세션 내용이 듣다가 별로 흥미가 생기지 않으면 다른 세션으로 넘어가기도 했다.
 
정말 꼭!! 듣고 싶었던 강의 1~3개정도 골라서 이것 만큼은 놓치면 안된다. 하는 최소 타협 지점을 정하면 현장에서 시간 배분하기 더 편할 것이다.


나는 만약 다음에 또 참여한다면 미리 세션들 내용과 해당 시간대에 어떤 것이 준비되어있는지 생각해보고 식사 시간을 고려하고 정말 딱 3개 정도만 고르고 유동적으로 행동할 것 같다.
 

추천하는 준비물

휴대폰, 지갑, 간단한 필기용품들로 구성하길 추천한다.
 
보조배터리도 있으면 괜찮을 것 같은데, 휴게존이 마련되어있었고 충전할 곳이 있었다. 충전기를 챙겨가도 될 것 같다. (근데 자리 싸움 있을듯)
 
저번 년도를 보니 큰 가방이 있었으면 좋았을 거라는 글을 보고 에코백을 따로 챙겨갔는데, 이번 인프콘에서는 자체적으로 가방 큰 것과 물을 지급해줬다.
짐을 최대한 간추리고 싶다면 그냥 참여 QR 코드가 있는 휴대폰, 지갑만 들고 걱정없이 빈 손으로 가도 충분할 것 같다.
 
그리고 간단한 필기 관련 물품을 챙겨갈 것을 추천한다.
노트북, 노트, 아이패드 등 다양한데 나는 아이패드 미니 6를 가져갔다. 정말 !! 만족했다.
내 판단으로는 세션이 유투브에 그대로 올라가니까 대충 키워드 중심 / 궁금한 의문점들 / 내 생각 위주로 필기해야겠다고 판단했다.
그래서 나와 비슷한 성향이라면 간단한 수첩 정도로도 충분할 것 같다.
 
 
 

인프콘 제대로 뽕 뽑는 법

인프콘을 진짜 제대로 뽕뽑으려면 세션 다 듣는게 아니라 (어차피 유툽 올라오니까) 흥미있는 세션 몇개만 골라다가 QnA 시간을 잘 이용하자.
 
현장에서 연사님과 직접 만나서 다른 개발자분들과 함께 질의응답하는 기회를 얻는 것 자체가 이번 컨퍼런스에서 얻어갈 수 있는 것들 중 가장 값진 것이라 생각한다.
 
QnA 시간에 강의 시간 상 다루지 못했던 부분이나, 놓쳤던 부분에 대해서나, 여러가지 인사이트를 QnA 시간에 가장 많이 얻을 수 있었다.
양보다 질로 승부보기를 권한다.
 
 
 

들은 세션 정리

인프콘 2023 발표/프로그램 시간표 - INFCON 2023 (inflearn.com)
 
 
오프닝 때는 인프런 기업 비전 및 기업 홍보를 들었다.
세션때는 의도한건 아니지만, 타입스크립트에 대해서 세션을 많이 듣게 되었다.
고민했던 부분에 대해서 들을 수 있어 만족한다.
 

소프트웨어 설계를 위한 추상적, 구조적 사고

소프트웨어 설계를 위한 추상적, 구조적 사고 - INFCON 2023 (inflearn.com)
잠깐 들어갔는데 자리가 없어서 서서 잠깐 들었다.
내가 배우고자 했던 주제나 내용들과는 조금 다른 것 같아 다른 세션으로 이동했다.
 
 
 

타입스크립트는 왜 그럴까? - 집합으로 이해하는 타입스크립트

타입스크립트는 왜 그럴까?: 집합으로 이해하는 타입스크립트 - INFCON 2023 (inflearn.com)
 
any, unknown, never 에 대해서 더 자세히 알 수 있는 세션이었다.
 
구글링할 때 업캐스팅이라는 말을 제대로 이해하기 어려웠는데 근본에 대해서 배울 수 있어서 좋았다.
 
전체 집합인 any 와 unknown 그리고 우리가 통상적으로 일반적인 타입들, 그리고 공집합인 never 타입
그리고 AND 와 OR 연산자로 타입추론을 할 수 있다는 것에 대해서 배웠다.
 
그리고 보통 any 말고 unknown, never 는 사실 거의 사용해본 경험이 없는데 제대로 알게되었다.
 
 

• unknown 타입

unknown 같은 경우에는 정확한 타입을 알기 어려울 때 사용한다는 것 을 배웠고
QnA 때 듣기로는 오히려 any 보다도 더 자주 사용하신다고 했다.
나는... 솔직히 보통 타입 가라치고 나중에 타입 추가해야지~~~ 마음으로 unknown 은 거의 안쓰고 주로 any 타입을 썼는데 오잉 신기하다~ 생각했다.
 
unknown 같은 경우에는 typeof 연산자를 통해서 타입 좁히기로 자주 사용하신다고 한다.
근데 궁금했던게 NaN 같은 경우에도 number 로 파악하는 것으로 알고있다. (이런 자스의 골 때리고 바보같은 점이..... 귀여움), 그런 경우에는 typeof 보다는 타입 별 분기처리로 타입을 좁힌다는건가? 했다.
중간부터 들은거라 타입 좁히기라는 것을 맥락으로만 파악해서 QnA 때는 묻지 않고 대충 타입 별로 분기처리하면 되는거니까 isNaN 조건을 if 문에 더 걸어주시지 않을까?? 생각했다.
상관없나??
아 근데 물어볼걸..
 
아무튼 잡솔 그만하고
 

• Never 타입

모든 타입 변수에 저장 가능하다. (내가 이해한게 맞다면, 다운 캐스팅이므로 - 강의 보길 추천한다.)
근데, 업캐스팅은 불가능하다.
 
 
그러니까 Never 타입으로 선언하면 어떤 형태의 값도 저장하지 않는 세기의 반항아 같은 타입이다.
나는 사실 이 타입의 존재를 언제 알았냐면, reduce 문을 비동기적으로 처리하려고 시도한 적이 있는데, never 어쩌구 타입 에러로그를 보여줘서 나는 오!!! 컴파일 에러인가??!?!? 했었고 아 약간 리턴 잘못하면 이런 타입으로 검증해내는구나~ never 가 나오면 뭔가 내 로직이 맛이 간거구나~~~ 로만 생각했다.
 
근데!! 정말 신기한 꿀팁을 배웠다.
호출되지 않아야 하는 함수를 만들 때 never 타입을 사용한다고 한다.
 
그러니까 뭔 말인고 하면
never 타입의 인자를 받는 함수를 통해서 호출되지 않아야 하는 지점에 지뢰탐지기처럼 사용해서 타입 세이프하게 구현할 수 있다.
특히 switch 문에서 분기처리를 안심할 수 있게 하는 함수로 사용할 수 있다. 정말 신기했다.
 
대충 정리해보자면
 

type animal = '강아지' | '고양이' | '기타등등'; // (enum 도 가능)

const 네버함수이름 = (인자 : never ) => {  
  // ... 에러 던지기 
  }



switch (expr: animal) {
  case '강아지':
	// 실행
    break;

  // 케이스 분기 처리

  default:
    네버함수이름(expr)
}

이렇게 코드를 쓰면
스위치 문에 들어오는 값을 enum 이나 type 으로 선언해주고 나서 분기 처리할 때,
 
만약 내가 실수로 분기 처리를 못한게 있다면  default value 에 값이 들어오게 될 것이다.
그러면 저 네버함수가  never 타입 (공집합의 타입)만 가능한데 다른 타입의 값이 인자로 들어오다니! 너 누구냐!!? 하는 느낌으로 빨간줄을 보여준다.
 
일종의 든든한 테스터인 셈이다.
 
약간 뭔 느낌이냐면
 
지금 와서는 안될 곳에 들어왔는데? 하는 저승사자 같다.
 
 

• any 타입

타입스크립트를 자스처럼 써놓고 any 스크립트라고 부르는 것을 봤을 것이다.
타입 생각하기 귀찮아~ 나중에 추가할래~ 하는 귀찮음의 동의어같다.
딱히 신기한 내용은 없었다.
 
타입 단언에 대해서 들었는데
any, unknown 같은 경우에
as any as ~
as unknown as ~
 
진짜 최악의 경우에 사용한 적이 몇 번 있었다.
집합론적으로 타입스크립트를 이해하고 나니 저게 본질적으로 어떤 의미인지, 왜 any, unknown 로만 타입 단언이 되는지 위 내용을 통해서 알게되어서 좋았다.
타입에도 뭔가 규칙이 있었다니 대단한걸!
저거 의미 차이가 있나? 하고 궁금했었는데 세션을 들어보니 딱히 의미 차이는 없는 것 같다.
 
 
 
 
타입스크립트는 그리고 구조적 타입 시스템이라서 프로퍼티를 기준으로 타입을 정의하는데, 대충 벤다이어그램으로 따져보자면 프로퍼티가 적을수록 제약이 적으니까, 
프로퍼티 A 를 가진 객체 A'
프로퍼티 A 와 B 를 가진 객체 B' 가 있다면
A' 가 B' 를 포함하는 관계로 생각하면 된다.
 
그리고 사실 예전에 삽질하면서 찾아봤던 부분이 강의에서 나와서 기뻤다.
타입스크립트 Interface, Type의 차이와 관련 연산자 (타입 합칠 때 & 사용) — Dorito's Dev (tistory.com)
 
인터섹션과 유니온 연산자에 대해서 이야기가 나왔는데 사실 이건 중고딩때 AND, OR 집합에 대해서 배운 내용이라 직관적으로 이해할 수 있을 것이다.
 
그리고 QnA 시간 때 질문 했던 내용으로는 다음과 같다.
 
1. interface 와 type 성능 차이
예전에 면접을 보면서 저 내 블로그 링크 삽질 부분에 대해서 이야기 하니까 엄청!! 좋아하시면서 막 마지막에 interface 와 type 차이로 캐싱 차이가 있다고 찾아보면 재밌을거라고 하셨었는데 
캐싱 차이가 뭐 크게 생각해야되나? 궁금해서 여쭈어봤는데 딱히 신경 안써도 되는 것 같다.
 
 
2. class, type, interface 같은 경우에 어떤 경우에 무엇을 사용하는지
테스트할 때 모킹 객체를 왜 class 는 잘 안쓰지?? 했었는데
이야기 들어보니까 약간 class 는 까리한 비싼 종이책. 이런 느낌이고 (막 재사용성... 등등 굳이?? 이런 느낌)
자스에서 일반 객체로 정보를 저장하는건 약간 마구 정보가 날라가든 말든 상관없는 갱지에 쓰는 느낌!
이런 느낌으로 이해했다.
 
그리고 뭐 또 type 과 interface 중 뭘 더 선호하느냐, 어떤 경우에 뭘 사용하느냐 - 따위의 저 위 내 블로그에 썼었던 글과 비슷한 질문을 다시 여쭤봤었는데 비슷한 대답이 나왔다.
- 취향껏, 팀 컨벤션을 따를 것
 
근데 보통 인터페이스를 선호하신다고 했다.
 
 
질의 시간에 외부에서 오는 객체를 타입세이프하게 검증할 때는 Zod 라이브러리를 추천하신다고 간단하게 언급하셨는데, 
이후 당근 기업의 세션에서 Zod, Ts-pattern 으로 타입 세이프하게 코드를 작성하는 것에 대해 운좋게도 말씀하셔서 추가적으로 정보를 얻을 수 있어서 좋았다.
 
 
 
3. as와 satisfies 연산자의 차이
이거는 사실 아직 안써보셨다고 하셨다.
그리고 이펙티브 타입스크립트 책을 추천해주셨는데, 다음에 한번 읽어봐야겠다.
 
근데 사실 회사에서는 뭔가 쓰는 것들이 업데이트 하나하나에 굉장히 민감하고 보수적이어서, 레거시 서버중에서는 타입스크립트 @4.7 사용하고 있는 것도 있다.
그래서 satisfies 연산자 궁금하고 써보고 싶긴한데 현업에서 사용하기에는 좀 버전업 시 사이드이펙트가 클 것 같다. 도입하려면 좀 내가 지식과 짬이 더 쌓여야하지 않을까?
 
 
 

인프런 아키텍처

이 세션에서는 강의 전반적으로 듣길 추천한다.
스쿼드 모델은 사실 스타트업 여러곳들에서 쓰는 팀 구조로 알고 있는데 이때 장단점에 대해서 알 수 있었다.
 
회사에서 레거시 서버가 2개가 있어서 항상 레거시 어떻게 유지보수하고 개선하느냐, 이런 주제가 자주 나왔었는데
그때마다 다른 기능 개발에 밀려서 항상 후순위로 밀려있는 부분이기도 했고 또
내 담당 업무 중에 레거시 서버를 새 서버로 마이그레이션 하는 작업이 있어서 이 세션이 가장 흥미로웠다.
이 세션에서 많은 인사이트와 시행착오들에 대해서 알 수 있었다.
 
또 레거시 걷어내는 것의 책임 주체는 어떻게 할당하고, 어떻게 문제를 쪼개어 해결해나갔는지, 그 문제를 해결하기 위해서 어떻게 infra structure 를 구성했는지에 대해서 알 수 있었다.
 
서버를 그대로 여러개 만들어서 기능별로 서버를 분리해서 조금씩 API 를 쪼개서 마이그레이션하는 방식으로 해결해나가고 있다고 한다.
 
 
아무튼 
플루미에 대해서 영업을 하셨고.. 작년에는 테라폼 영업하셨는데 바로 바꿨다고 말하기 쑥쓰럽다고 하셔서 좀 웃겼다.
 
그리고 내부 API 통신이 불필요하게 L7 계층에서 일어나 리소스, 트래픽 낭비가 일어나는 문제가 있었는데 private 로드 밸런서 문제로 해결하셨다고 한다.
 
또 공개/비공개 성격의 API 이냐에 따라 레포를 나누어 public/private 로드밸런서를 다르게 연결해서 해결했고
 
또 기능 1개를 쓰는데 여러개 API 를 호출하게 되는 문제들은 이벤트큐를 사용해서 해결하셨다고 한다. 다만 제한조건이 멱등성있고 비동기적인 API 에서만 적용이 가능하다고 한다.
 
인증 / 권한 문제는 최대한 한 곳에서 관리할 수 있는 API Gateway 를 사용하셨다고 한다.
 
 
 
또 관리포인트를 줄이기 위해 최대한 DB 를 쪼개지 않으셨다고 한다. 그 때 어떤 서버 - 쿼리에서 문제가 발생했는지 디버깅하기 어려워서 계정을 쪼개고 슬랙에 알리는식으로 관리하신다고 한다. 
 
그리고 비지니스의 독립적인 플랫폼 성격의 API 는 DevOps 조직에서 Go 로 해결 하셨다고 한다.
 
 
 
인프라에 관심이 있고 만약 이해가 안간다면 강의를 보시길 추천한다.
나는 설명을 잘 못하고 정확한 정보도 아니고, 대충 생각 정리용으로 적는거라 맥락 축소가 많은 듯.
 
강의와 함께 좀 맥락과 함께 본다면 이해하기 쉬울 것 같다.
 
 
그리고 거의 2시간 가량 개발자분들과 QnA 를 진행했다. 데브옵스, 인프라 관련 많은 인사이트를 얻을 수 있었다.
* 간단한 메모와 기억에 의존하며 쓴 것이다 보니 부정확한 부분이 많을 것 같습니다. 만약 관련 정보에 관심이 있으시다면, 참고용으로만 부탁드립니다!
 
질문 한 것은
1. 모노레포를 사용하실 때 패키지매니저 yarn berry 를 사용하시는지? 어떤 패키지 매니저를 사용하시는지?
nestjs 에서는 뭔가 기능을 자체적으로 지원을 해줘서 사용할 필요가 없다고 한다.
 
사실 취준 때 프론트엔드 Next.js 과제를 일주일정도 구현 해본 적이 있는데 그때 요구사항에 yarn berry 패키지 매니저가 있어서 잠깐 사용해본 적이 있었다.
그때 yarn berry 가 뭔지 검색할 때 모노레포 키워드 관련 이해못하고 대충 읽고 넘겨서
어? 의존성 관리랑 레포 관리하기 더 편하다고~? 나중에 꼭 써봐야지! 좋은거 아니야~ 로 정도만 생각했는데 듣고 좀 놀랬다.
 
말씀하시는 것 토대로 왜 nest js 에서는 yarn berry 도입 필요성이 없는 건지 더 찾아봐야겠다.
 
 
 
2. 정규화 문제
뭔가 DB 관련해서 레거시 처리는 어떻게 했는지 궁금해서 여쭈어보았다.
 
막 DB 라는게.. 뭔가 내가 입사하고 나서 DB 봤을 때 공부했던 거랑 실무랑 많이 달라서 놀랬는데
예를 들자면 컬럼 이름을 snake 형식으로 해야된다! 그래서 막 테이블은 무조건 snake 쓰고 그래야 하는 줄 알고 
[NestJs] Competing naming styles: mySQL snake 스타일을 typeORM 엔티티에서 Camel case로 매핑하기 — Dorito's Dev (tistory.com)
 
 
요런 라이브러리 갖다써서 막 했는데 저런 라이브러리는 블랙박스의 영역이라 최대한 지양하고 있다는 사실도 새롭게 배웠었다.
 그리고 실무에서는 컬럼명 컨벤션으로 카멜 케이스 쓰고 계셔서 신기했다. 그리고 그게 훨씬 더 합당한 선택이라는 것을 부정할 수 없었다. 
* 참고사항 
내 실무 경험이 정답이 아니고 회사마다 다르다는 점을 잊지말자!
인프랩에서는 DB 컬럼명의 경우, snake 케이스가 컨벤션이고 해당 라이브러리를 사용하고 계신다고 한다.
 
 
아무튼 내가 하고 싶은 말은 막 실무에서 특히 스타트업에서는 인생은 실전이다!!! 이런 느낌인지라 DB 가 막 이상적이지는 않은 상태인 것 같다.
DB 정규화나 fk 키나 ERD 관련 조차도 파악하기 어렵고, 정말정말 많이 거대한 레거시고 테이블을 건드는 것 자체가 뭔가 엄청나게 많은 비용이 드는 것 같다.
DB 트리거 기능을 사용해서 값을 동기화 시키며 조금씩 처리한다고 하는데,
트리거를 많이 쓸수록 서버 성능이 저하될 여지는 없을까? 이런 궁금증도 들었다. 어렵당..
근데 이게 가장 최선인 것 같다는 생각은 들었다.
 
* 참고사항:
회사에서 레거시 주제로 이 부분 관련 여쭈어보았다.
내가 이해한 바로는 여러가지 이유로 논리적으로 엔티티를 wrapping 해서 custom repository 처럼 사용할 것이라고 말씀하셨다.
(왜냐하면 오늘 잠깐 지나가듯이 들은 이야기라서 정확한게 아닐 수 있다. 좀 더 찾아보고 공부해 볼 필요성이 있겠다.)

 
3. Typeorm 
Node.Js 를 사용하는 분께 ORM 이야기를 하면 하나같이 다들 수심이 깊어지는 표정과 함께 한숨을 쉬시는 것이 조금 웃겼다.
진짜로 근데 너무 버전업때마다 너무 버전 호환 고려 안하고 혼돈 파괴 아수라장을 만들어서... 아무튼 
이거는 온갖 시도를 다 해보셨는데 커뮤니티도 크고 뭐.. 타협해서 결국은 Typeorm 을 사용하신다고 한다. (microORM 이 가장 기능적으로는 마음에 드셨다고 하심)

- 외래키 관련
논리적인 외래키 사용하신다고 하셨다.
근데 TypeOrm 외래키 관계 없으면 안되는걸로 알았는데 최근에는 @JoinColumn() 으로 외래키가 없어도 된다고 하셨다.
 
그게 버전 언제부터인지... 오늘 깃허브 Typeorm 이슈란 살짝 간절하게 찾아봤는데 시간이 없어서 제대로 원하는 정보를 찾지 못했다.
 
제발, 부디... 쓸 수 있었으면... 더 찾아볼 예정.
 
 
* 추가
댓글 피드백을 통해서 내용을 추가하게 되었다! 감사합니다 m (_ _) m
TypeORM에서 연관관계 유지한채 FK만 제거하기 (w. NestJS) - https://jojoldu.tistory.com/m/605
글을 참고하면 된다.
 
추가적으로 구글링해보니 참고할만한 링크도 있어서 아카이빙해두어야겠다.
 
- 참고하면 좋을 해당 이슈 깃허브 문서
Option to disable foreign keys creation · Issue #3120 · typeorm/typeorm · GitHub
 
- 공식문서 (0.3 기준)
https://typeorm.io/relations-faq#avoid-foreign-key-constraint-creation
 
 
 
- 여기 문서를 참고해보면 version 0.2.31 (2021-02-08) 부터 사용할 수 있는 기능이라고 한다.
https://github.com/typeorm/typeorm/issues/3382#issuecomment-878324031

사실 예전에 저 옵션에 대해서 찾아본 적이 있었는데, 그때는 내가 지금보다도 더 기본적인 ORM 사용법이나 DB 구조 설계에도 미숙해서  뭔가 잘못 이해해도 한참 잘못 이해했던 것 같다. 
 
그리고 공식문서를 좀 더 꼼꼼히 읽어봐야겠다 ㅠ.ㅠ 
(인덱싱 관련해서... 0.2.42 (2022-02-16) 버전때 adds entity-schema support for createForeignKeyConstraints (#8606) (f224f24), closes #8489  기능이 추가됐다. 엔티티 컬럼으로 추가하는건 0.2.42 때인듯)
 
내일 해봐야지!!
- 좋긴한데, 버전 0.2 에서 find option 이 너무 불편하다... ㅠㅠ 0.3으로 마이그레이션 우짜지..

 
4. 환경변수 관리
환경변수 같은 경우에는 정말 다양한 방식이 있는 것 같고 또 CI 구축 관련해서 좀 더 알아보고 싶어서 여쭈어봤다.
AWS Cloud Config 를 사용하신다고 한다. 그리고 CI 가 잘 되어있으셔서 도커로 테스트 하시니까 로컬에서는 서버를 잘 안쓰신다고 하신것으로 기억난다. (확실하지 않음)
 
 
 
그리고 다른 분들 질의 응답에서 배운 것들이나 알아보고 싶은 키워드는
- B쿼리
데이터 처리/ 로깅 관련 데브옵스 측면에서 중요한 키워드 같았다. 처음 들어봄
- 로깅 관련 키워드로는 Cloud front → S3 저장
- datadog 로 SQL 이나 어플리케이션 로그
- RDS 스냅샷
- Cloudwatch → Elastic watch 로 어떻게 뭐 하신다고 함
 
키워드만 적어가지구.. 저걸로 구글링해보면 잘 나올 듯!
트랜잭션 롤백 관련해서도 이 키워드, 주제랑 같이 나왔었다.
만약 이 파트를 내가 찾아보게 된다면, 저 키워드를 포함해서도 함께 검색해봐야겠다.
 
MSA 판단 여부
에러 전파 범위 여부로 판단해서, 레거시 처리하는 서버들도 MSA 라고 부르지 않으셨다. 만약에 에러 전파가 되는 것이라면 MSA 로 정의내린다고 하셨다.
 
- Fargate 대신 EC2 를 선택한 이유
EC2 가 가격 대비 컴퓨팅 파워도 세고, 로깅하기 편하기 때문이라고 하셨다.
데브옵스 조직이 타 회사에 비해서 큰 편이라고 하셨는데, 그 부분에 대한 자신감 같기도 했다.
 
 
- 영상 전송 기술 스택 관련
HLS 붙여서 6초마다 잘라서 stream 으로 암호화 해서 송출한다고 한다.
* 수정: 촬영된 영상을 6초단위로 잘라서 HLS 로 암호화 해서 보낸다고 한다! (Stream X)
DRM 라이센스 ~ 펠리컨 서비스 ~~ 쓰심
이 주제 관련 관련 키워드는 이후 필요하면 찾아봐야겠다 생각했다.

- 비싼 데이터독을 사용하는 이유
node 관련 서비스만으로 따지면 또이또이기 때문임
뉴밸리 이런 서비스도 노드는 가격 비싸다 하심
 
- SasS IasS 
키워드로 찾아봐야됨
 
* 추가

• infrastructure-as-a-service (IaaS): 가상 머신과 인프라 지원서비스형 인프라(IaaS)에는 클라우드 IT의 기본 구성 요소가 포함되어 있으며, 일반적으로 네트워킹 기능, 컴퓨터(가상 또는 전용 하드웨어), 데이터 저장 공간에 대한 액세스를 제공합니다. IaaS는 IT 리소스에 대한 최고 수준의 유연성과 관리 제어를 제공하며, 오늘날 많은 개발자에게 익숙한 기존 IT 리소스와 가장 유사합니다.
• platform-as-a-service (PaaS): 고객의 애플리케이션을 배포하는 완전 관리형 서비스서비스형 플랫폼(PaaS)을 사용하면 기본 인프라(일반적으로 하드웨어 및 운영 체제)를 관리할 필요가 없으므로 애플리케이션 배포 및 관리에만 집중할 수 있습니다. 리소스 조달, 용량 계획, 소프트웨어 유지 관리, 패치 또는 애플리케이션 실행과 관련된 기타 차별화되지 않은 과중한 작업에 대해 걱정할 필요가 없으므로 효율성을 높일 수 있습니다.
• software-as-a-service (SaaS): 클라우드 기반 애플리케이션서비스형 소프트웨어(SaaS)는 서비스 제공업체가 실행하고 관리하는 완성된 제품을 제공합니다. 대부분의 경우 SaaS를 언급하는 사람들은 최종 사용자 애플리케이션을 의미합니다. SaaS 제품을 사용하면 서비스가 유지되는 방식이나 기본 인프라가 관리되는 방식에 대해 생각할 필요 없이 해당 소프트웨어를 어떻게 사용할 것인지만 생각하면 됩니다. SaaS 애플리케이션의 일반적인 예로는 이메일 제품에 추가되는 기능을 관리하거나 이메일 프로그램이 실행되는 서버 및 운영 체제를 유지 관리할 필요 없이 이메일을 주고받는 데 사용할 수 있는 웹 기반 이메일을 들 수 있습니다.

어렵다. (아무리 읽어도 이해하기 쉽지않다,,)
 

- (TL;DR) 재밌었던 오프더레코드
스타트업에서 백엔드로 node 를 쓰는거 추천하신다고 하셨는데, 이유가 구인 입장에서 인재를 가져올 수 있는 풀이 좀 더 나은 상황이기 때문이라고 하셨다. 자바 쓰는 대기업들에 인력 풀 쏠리니까 구인 시 기업끼리 경쟁이 조금 힘들지만, 노드스택을 쓴다면 노드 스택 쓰는 회사중 인프랩이 가장 자신이 있으므로 기업끼리 구인 경쟁이 상대적으로 덜해서 좋은 인재 끌어오기 쉽다고 말씀하셨다. (기억에 의존한거라 맥락이 다를수도..)
 
약간 구직자나, 구인하는 회사 입장이나 경쟁하게 되는구나, 회사입장에서도 그런 생각을 하다니 신기했다.
뭔가 구직 시장이나 연애 시장이나 비슷한 느낌.. 
 
개인적으로 또 뿌듯했던 감정을 느꼈는데 강의내용들이 대부분 이해가 가서 좀 감격했다.
또 막 갠적으로 들으면서 어? 이거 이벤트큐 쓰면 되지않나!??! 했는데 바로 다음 장에서 이벤트 큐로 해결했다. 이러셔서 진심 뿌듯했다. 우하하!!! ~~~
 

당근마켓 기업 세션 - TypeScript로 실제 세상에 존재하는 타입 만들기

우리는 소프트웨어 엔지니어입니다 | 당근마켓 - INFCON 2023 (inflearn.com)
 
Software Engineer, Backend 김경덕 : TypeScript로 실제 세상에 존재하는 타입 만들기

• TypeScript로 실용적인 타입을 만들고 안전하게 다루는 방법을 이야기해요.

이 강의를 중반쯤부터 들었는데 Zod, Ts-Pattern 을 어떻게 활용하고 타입 세이프하게 
인터페이스를 type마냥 이리저리 써서 적절한 객체 선언, 그리고 타입 마다 분기처리를 하는게 너무 신기했다.
이건 강의 보길 정말 추천한다.
 
 
인프런 공식 유투브에 잘 업로드 되어있다.
https://youtu.be/wm8bpujQjKM

 
대략적으로 정리해보았는데 정말 알차고 재미있었다.
 
그리고 네트워킹때도 재밌는 이야기를 나눌 수 있어서 좋았다. 공짜 과자도 주고, 귀여운 토끼인형 그리고 뱃지를 열심히 만들었다고 어필하는 인프런 직원분이 너무 인상깊고 귀여웠다. 
 
사고없이 성황리에 잘 마무리되어서 이번 인프콘 관계자분들도 많이 뿌듯하셨을 것 같다.
 
다음 인프콘도 기대되며 그때도 당첨됐으면 좋겠다.
 
이상 읽어주셔서 감사합니다.