[230826] 유스콘 2023 컨퍼런스 후기

2020년부터 시작된 유스콘(YOUTHCON) 행사. 올해도 어김없이 제이슨이 주관한 2023년 유스콘 행사가 시작됐다!

2021년에는 아무것도 모르는 상태로, 2022년에는 우아한테크코스 학생 신분으로 들었었는데, 올해는 신입 개발자 신분으로 듣는 거라 또 다른 느낌으로 다가올 듯하여 기대에 부푼 마음으로 참가해보았다.

 

유스콘 2023 행사 일정표는 아래와 같다.

https://frost-witch-afb.notion.site/YOUTHCON-23-a026c94d997e46db9396283ed869a922

YOUTHCON'23

참고로 Hands-On Lab 에 해당되는 트랙2 일부 세션들은 실습형이므로 30명 인원제한으로 진행됐다.

 

 

작년과 마찬가지로 올해도 약 100명의 인원을 오프라인으로 초청했으며, 온라인/오프라인 모두 진행된다고 한다.

다행히 나는 오프라인으로 참여할 기회를 받았다.

오프라인 초청 메일

 

작년이랑 다른 점은, 이번에는 우아한형제들 루터회관이 아닌 우아한형제들 테크살롱 (우테코 선릉캠퍼스, 성담빌딩 13층)에서 진행됐다는 점이다. 또, 이번에는 원활한 소통 및 관리를 위해 오픈채팅방이 생겼다! (유스방 오픈채팅방의 실명방이나 다름없지 않을까?ㅋㅋㅋ)

 

커피 반입이 안된다!

유스콘 2023이 무료 행사여서 스태프분들이 사실상 행사를 위해 봉사 및 열일해주시는 건데, 커피 외부반입 쓰레기까지 나오면 진짜 힘드셨을 것 같긴 하다. 그러한 포인트에서 충분히 이해되는 룰이었다. 대신 물을 많이 제공해주었다.

 

작년에는 우아한테크코스 4기 수료생분들이 발표하는 세션이 많았다. 아무래도 작년에는 2022년 12월 31일에 세미나가 열려서 그랬을수도? 올해는 우테코 5기 학생분들이 수료하지 않은 시점이라 테크코스 수료생분들의 발표는 없었다. 

참고로 작년 2022 유스콘 후기는 여기서 볼 수 있다.

https://kth990303.tistory.com/407

[221231] 유스콘 2022 웨비나 컨퍼런스 후기

 

이제 유스콘 2023 후기를 작성해보도록 하겠다.

---

축사

백기선님, 백명석님, 토비님이 축사영상을 찍어주셨다!

 

영상 중에 가장 와닿았던 내용은, 백기선님께서 말씀하신 `기술 개발 결핍은 어떻게 보면 가장 채우기 쉬운 결핍일 수 있다.` 라는 부분이었다. 요즘, 개발자는 기술뿐만 아니라 커뮤니케이션 등 다양한 역량이 요구된다고 느끼고 있어서 그런지 해당 문구가 가장 와닿았다. 

 

근데 사실 나는 기술 개발도 아직 부족해서ㅋㅋㅋㅋㅋㅋ

열심히 공부하면서 즐겁게 개발하다보면 어느새 성장해있길 기대하며..

---

트랙1 - 성장해서 서비스를 만들려고 했다가, 서비스를 만들면서 성장한 이야기

제목이 정말 요약이 잘 돼있다고 생각한다.

성장한 후에 서비스를 만드려다가, 서비스를 만들면서 야생형으로 성장한 경험을 풀어주시는 세션이다.

 

개인적으로 정말 공감되는 세션이었다.

나도 야생형으로 성장하는 걸 좋아하는 타입인지라, 해당 부분에 있어 발표자님과 나의 가치관 및 생각이 거의 일치했다.

 

개발자로서 공부해야될 것은 너무나도 많다. 

이를 다 공부하고 서비스를 만들기 시작한다면 사실상 만들지도 못하고 공부만 하다가 인생이 끝날 수도 있다. (너무 극단적인가..?)

하지만, 서비스를 만들면서 결핍을 채우다보면 어느새 서비스가 완성되며 차차 개선해나가는 재미 및 성취감을 느낄 수 있어서 시너지 효과가 난다고 생각한다. 예를 들어 구현을 완료했지만, 뭔가 A 부분에 있어서 느리다? 비동기로 처리할 수도 있어보이는데? 하면서 이를 학습한다든지.

 

끝나고 Q&A 시간에 아래 질문이 들어왔다.

 

`개발을 먼저 할 경우, 이를 통해 구현된 애플리케이션이 품질은 안좋아도 돌아는 가므로 방치할 수도 있어보인다.

개발 전에 공부가 되어야 좋은 품질로 돌아가게할 수 있을 듯하다.`

 

정말 예리한 질문이라 생각돼서 와닿았다. 질문해주신 분 의견과 마찬가지로, 충분히 이럴 수 있다고 생각하며 특히 개발품질이 좋지 않은 상태로 방치하는 부분은 개인적으로 가장 경계해야 하는 마음가짐이라 생각한다. 개발자는 무언가가 계속 불편해야 성장할 여지가 있다고 생각하기 때문! 무언가 느리거나 불편하다면 이를 개선하기 위해 구글링을 한다든지, 동료개발자와의 협업 및 코드리뷰를 통해 이를 개선해나가야 한다고 생각한다. 이렇게 하다보면 한걸음 씩 나아가 어느새 많이 성장해있는 자신을 발견하지 않을까 싶다.

 

노션에 정리한 내용을 참고하고 싶다면 아래에서 확인할 수 있다!

https://clean-nutria-44b.notion.site/b79a589960a14689850893ddc80e0fa9?pvs=4 

성장해서 서비스를 만들려고 했다가, 서비스를 만들면서 성장한 이야기

---

트랙1 - 그렇게 개발자가 된다

좋지 않은 개발문화의 팀에서 고민하다가, 스스로 개발문화를 도입하여 성장해나가는 일대기를 풀어주신 세션이다.

발표자님께서는 스스로 개발문화를 설립하고 도입하여, 팀원이 없는 상황이지만 자기 스스로 그 문화를 지켜나가며 개발 역량을 기르셨다고 한다. 또, 2년차에 서버 리드를 맡으시면서 개발역량 뿐 아니라 다양한 역량을 키우시며 성취해내신 자신을 돌아보며 매우 만족해하셨다고 한다. 정말 뛰어나신 분이라 생각이 든다.

 

개발문화는 정말 중요하다고 생각한다.

 

나는 개인적으로 내가 가고싶은 회사, 내가 가고싶은 팀을 선택할 때 `개발문화`가 굉장히 큰 기준 중 하나였다.

성장하고 싶은 사람에게 좋은 팀원, 좋은 코드리뷰 문화, 좋은 학습공유 문화가 있어야 나뿐만 아니라 팀원들 모두 성장하여 시너지를 내고 더 열심히 개발할 수 있다고 믿기 때문이다.

 

아직 나는 주니어 개발자이기 때문에, 개발 역량 외의 역량은 어떻게 키우는지 궁금했다.

그래서 Q&A 시간에 `서버리드를 하실 때 개발 역량 외에 다른 역량을 키웠다고 하셨다. 개발 역량 외의 역량을 어떻게 키울 수 있었는지?`에 대해 질문을 드렸다. 발표자님께서는 마음가짐에 따라 달라진다고 답변해주셨다. 커뮤니케이션 역량, 일정관리 역량 등 자신이 중요하다고 생각되는 부분에 관심을 쏟으면 그만큼 역량이 키워질 것이고, 한층 더 시야를 넓히며 바라볼 수 있게 될 것이라는 의미로 받아들였다.

(만약 아니라면... 코멘트로 댓글 부탁드려요 발표자님! 🙇🏻‍♂️) 

 

 

노션에 정리한 내용을 참고하고 싶다면 아래에서 확인할 수 있다!

https://clean-nutria-44b.notion.site/97524088954343439fd2c3538013a25f?pvs=4 

그렇게 개발자가 된다

---

트랙1 - ELK 스택을 활용해 통계성 데이터 제공하는 API 구현하기

ELK 스택을 적용하여 데이터를 제공한 일대기를 풀어주신 내용이다.

우리 팀에서는 ELK를 쓰진 않는다. ElasticSearch를 사용하는 팀에게 이벤트로 데이터를 넘겨주는 정도는 존재하지만, ElasticSearch, LogStash, Kibana 중 어떤 것도 쓰지 않는다. 그래서 그런지 ES 쪽에 오히려 더 궁금해져서 듣게 된 세션이다 ㅎㅎ

 

사실 나는 Hadoop, Spark, ES 셋 다 써본적이 없다. 

그래서 Hadoop, Spark 대신 ES를 선택한 이유가 무엇일지, 셋은 어떻게 다를지 궁금했다. 사실 내가 검색, 데이터 또는 카탈로그 팀이었다면 이에 대해 깊게 공부하고 선택 기준을 고민했을텐데 말이다ㅋㅋㅋ 아쉽게도 나는 해당 팀이 아니기도 하고, 우리 팀에서는 최근에 ES에서 Loki로 바꾼 걸로 알고 있기 때문에 ES, Hadoop에 대해서는 자세히 모른다.

 

발표자님께서 ELK를 쓰신 이유는 아래와 같다고 말씀해주셨다.

• NodeJS
• search, aggregation 필요성
• 빅데이터 프로세싱보단 Analytics, 시각화에 집중

 

아무래도 hadoop 이 자바 오픈소스 플랫폼이고, spark도 nodejs로는 상대적으로 적합하지 않은게 한몫했을 것 같다.

 

세번째 포인트는 사실 긴가민가했는데, 아래 글을 보고 납득이 됐다.

Hadoop, Spark로 주로 데이터를 선별 및 프로세싱하고, ES로 검색 및 통계를 내는 데에 적합한 것 같다. (아래 글을 참고했다.)

https://stackoverflow.com/questions/29202768/why-hadoop-or-spark-there-is-elasticsearch

Why Hadoop or Spark? There is ElasticSearch

 

그 이후로는 ES 적용 도입기에 대해 쭉 설명해주셨다.

여기서부터는 사실 다 이해하지는 못해서 따로 포스팅에 적진 않을 듯하다. (노션에도 크게 적은 건 없다 ㅜㅜ 멍청한 나 자신!)

 

ES를 관리하는 쪽이 아닌, 간접적으로 접근하는 나에게는 개인적으로 Q&A 쪽이 와닿았다.

우리 팀에서 ES에게 이벤트로 데이터를 제공해주었는데, ES가 뻑나서 데이터가 유실된다면 어떻게 처리할지? 그리고 ES를 관리하는 입장에서 비용 측면이나 오래 소요되는 쿼리 및 데이터가 들어오는 경우는 어떤 경우인지, 그리고 어떻게 처리하는지? 등의 질문이 있었다. 특히 후자의 질문은 나랑 같이 세션을 들은 학교 선배님께서 질문을 해주셨다. 선배님 팀에서도 ES를 관리하는 쪽이라기보단, 데이터를 제공해주는 팀이기 때문에 이러한 부분이 궁금하다고 하셨다.

추후에 해당 질문에 대한 답변 이야기도 들을 기회가 있으면 좋겠다는 생각을 했다.

 

여담으로 Q&A 시간에 질문이 올 경우, 발표자님께서 질문을 한번 다시 정리해준 후 답변을 해주셨는데 이 부분이 굉장히 인상깊었고 좋았다.

 

ES 적용 내용에 대한 부분은 이해하지 못했지만, ELK와 Hadoop, Spark 선택 기준 및 데이터처리 방법에 대해 다시 고민할 계기를 주어서 좋았던 세션이었다.  

 

노션에 정리한 내용을 참고하고 싶다면 아래에서 확인할 수 있다!

https://clean-nutria-44b.notion.site/ELK-API-5f53cd6ec00a4d44a37a8bea2e8a73ff?pvs=4 

ELK 스택을 활용해 통계성 데이터 제공하는 API 구현하기

---

트랙1 - 개발 그 이상의 가치 - 주니어 개발자의 사실과 오해

개발자에게 있어, 기술은 중요하다. 하지만 기술에 강박적으로 집착할 필요는 없다. 개발자에게 기술은 전부가 아니기 때문!

커뮤니케이션 역시 개발자에게 있어 중요한 역량이라는 발표내용이었다.

 

커뮤니케이션이 정말 중요하다는 것을 요즘 느끼고 있다. 

개발자들은 개발자들끼리만 일하는 것이 아닌 기획자, 디자이너 등 다양한 직군과 함께 일하기 때문이다. 전문용어로 알 수 없게 얘기하는 것보다, 쉽게 풀어서 모두가 상황을 이해할 수 있게. 무조건 안된다고 말하는 것보다는 대안을 제시하며 다같이 고민해보는 방향으로!

 

발표를 듣다보니 DDD 중 일부가 생각이 났다. DDD에서도 이를 정말 강조했다. 기획자와 개발자 모두가 상황을 함께 고민하며, 커뮤니케이션을 원활하게 함의 중요성을 매우 강조했다. 유비쿼터스 언어를 지정하여 하나의 용어를 모두 하나의 의미로 명확하게 이해할 수 있도록. 그래서 그런지 우리 팀에서는 명확하게 의미를 내포하는 약자가 좀 많은 편이다. (한집배달을 나타내는 약자, 특정 쿠폰을 나타내는 약자 등등.)

 

발표자분께서 추천해주신 `오늘도 개발자가 안된다고 말했다` 책도 시간날 때 한번 읽어봐야겠다.

 

 

여담으로 발표자분께서 우테코 4기 동기였던 토닉 형과 같은 회사, 같은 팀이었다!

덕분에 토닉도 유스콘 2023에 참가했다고 한다. 오랜만에 토닉을 만나서 반가웠고, 토닉 팀원분과 함께 얘기를 나눌 수 있어서 뜻깊은 시간이었다. TMI로 토닉은 평일에 팀원분과 함께 클라이밍, 주말에는 축구를 뛰는 만능열정운동맨으로 활동하고 있다고 한다ㅋㅋㅋ 담에 클라이밍 같이 하기로 약속했다 ㅎㅎ 빨리 부상이 다 낫든지 해야지...

 

노션에 정리한 내용을 참고하고 싶다면 아래에서 확인할 수 있다!

https://clean-nutria-44b.notion.site/1c95cad22d234244b66107bd915e2ce5?pvs=4 

개발 그 이상의 가치 - 주니어 개발자의 사실과 오해

---

트랙1 - 주어진 환경 내에서 최대한 문제 해결하기

특정 문제를 해결하기 위해 MQ를 도입하려다가, 제한적인 상황으로 인해 무리하게 MQ 도입하는 선택지보단 DB 연동 선택지로 오히려 문제를 잘 해결할 수 있었던 일대기이다.

 

발표 요지는 `새로운 기술을 도입하지 말자!` 라기보단, `주어진 상황 내에서의 최선의 선택지를 택하자!` 라고 생각한다.

앞 세션 발표와 비슷하게, 꼭 기술에 강박적으로 집착할 필요는 없다는 부분과 일맥상통한 발표라는 생각도 들었다 ㅎㅎ 

 

요즘은 취업을 위해 작은 규모의 사이드프로젝트에서 MSA를 적용하고 Kafka, MQ를 도입하는 경우가 많은 듯하다.

이를 도입하는 이유가 `재밌어서! 한번 해보고 싶어서!` 이면 매우 좋은 취지라 생각한다. 하지만 `이런 걸 해야 취업이 될 수 있어서` 라는 취지면 꼭 그럴 필요가 없다고 생각한다. 실제로 트랜잭션과 Java, CS만 공부하고 Redis, MQ 등을 아예 공부하지 않고 매우 좋은 대우를 받으며 입사한 선배님 일대기를 들어서 그런지 더 그렇다고 생각한다.

 

정말 MSA, 멀티모듈이 필요한 급의 규모인지? 단일 모듈로는 어려운지? Kafka, MQ가 꼭 필요한지? AWS SNS/SQS나 아니면 단순 API, 또는 스케줄러를 쓰는 방법이 오히려 낫진 않을지? 등 가장 최선의 선택지 에 대해 고민해보는 것도 좋다고 생각한다.

 

`전 GitHub CTO, "지난 10년간 가장 큰 아키텍처 실수는 풀 마이크로서비스로 전환한 것` 라는 제목의 글도 있기도 하고 말이다...

https://news.hada.io/topic?id=7839 

전 GitHub CTO, "지난 10년간 가장 큰 아키텍처 실수는 풀 마이크로서비스로 전환 | GeekNews

 

근데 사실 나도 멋진 기술 도입해보고 싶고 ElasticSearch, Kafka 막 공부해보고 싶고 그렇긴 하다ㅋㅋㅋ

무언가를 검색할 때 like 쿼리 말고 elasticsearch로 정확하게, 그리고 빠르게 검색되는 원리가 되게 궁금하긴 하다.

 

하지만 지금 쓰이는 기술 공부하기에도 양이 많아서, 후에 정말 필요해지면 공부하자! 생각하는 중이다. 아니면 나중에 여유가 생겨서 심심할 때 한번 쭉 훑어보면서 공부해봐야겠다 ㅎㅎ

지금은 팀 도메인 공부랑 Spring Batch 공부에 거의 전념하고 있는 듯?

 

노션에 정리한 내용을 참고하고 싶다면 아래에서 확인할 수 있다!

https://clean-nutria-44b.notion.site/1ccf23bba4424c8a9888ac62114e467d?pvs=4 

주어진 환경 내에서 최대한 문제 해결하기

---

트랙2 - PostgreSQL의 Scan 작동 원리 파헤치기

제목대로 PostgreSQL의 index scan, bitmap scan 원리를 살펴보는 시간이었다.

MySQL에는 존재하지 않는 Postgre의 Bitmap Scan에 신기해하며 들었던 기억이 난다 ㅎㅎ

 

Postgre의 옵티마이저에서 정렬도가 낮고 스캔 범위가 적을 때에는 Bitmap Scan을, 정렬도가 높으면 Seq Scan을 때리는데, 이러한 scan 원리를 살펴보는 시간이었다.

처음에는 MySQL의 index skip scan이 postgre에는 없길래 `어?` 하면서 봤는데, 아무래도 bitmap scan으로 이를 극복한 것 같다. 다만 bitmap scan은 비트맵 페이지를 차지하는 공간이 필요하기 때문에 이는 감안해야 할듯?

되게 신기한 스캔 방법이라 생각한다.

 

나는 아직 MySQL vs PostgreSQL 에 대한 고민을 많이 하고 있고, 이에 대한 정답을 찾지 못했다.

(물론 내가 DBA가 아니기도 해서 선택권이 많진 않다. 하지만 사이드프로젝트를 한다면? 그래도 mysql, postgre 중에 고민을 엄청 할듯하다.)

 

우리 팀 내에서는 MySQL 위주로 쓰고 있긴 하다. 하지만 Postgre도 버전 업데이트될 때마다 엄청난 발전을 하고 있다. 

이번 세션을 들으면서 Postgre의 bitmap scan이 되게 신기하고 좋게 느껴졌다. 동시에 `그럼 MySQL은 postgre의 bitmap scan을 대체할만한 방법이 뭐가 있을까?` 하는 생각이 들었다. Index skip scan? 아니면 또다른 내부적인 무언가?

 

Postgre 대신 MySQL을 쓰는 사람들은 왜 MySQL을 쓰는지, 반대로 MySQL이란 선택지 대신 Postgre를 쓰는 사람은 왜 Postgre를 쓰는지 얘기나누는 시간이 있어도 재밌을 듯하다.

 

 

노션에 정리한 내용을 참고하고 싶다면 아래에서 확인할 수 있다!

https://clean-nutria-44b.notion.site/PostgreSQL-Scan-3a8c268a734243f38257a704248c3fd4?pvs=4 

PostgreSQL의 Scan 작동 원리 파헤치기

---

트랙2 - 복잡함은 끝, 간결함의 시작: 버티컬 슬라이스 아키텍처

헥사고날 아키텍처에서 버티컬 슬라이스 아키텍처로 전환한 일대기를 풀어주신 세션이었다.

헥사고날 아키텍처 경험이 사실상 없다시피 하여 들을지말지 고민했는데, 듣길 잘했다. 다행히 헥사고날 아키텍처에 대해 이론적으로 알고만 있어도 꽤 재미있게 들을 수 있는 세션이었다.

 

헥사고날 아키텍처의 지나치게 많은 세팅(mapper, interface 등), API 스펙 변경에 따른 생산성 저하 이슈에 따라 아키텍처를 버티컬 슬라이스로 변경했다고 한다. 버티컬 슬라이스 아키텍처를 이번 세션에서 처음 들어봤는데, 하나의 클래스에서 하나의 feature를 적용하는 아키텍처라 한다. 그렇기 때문에 주로 컨트롤러와 서비스 레이어 로직을 하나의 클래스에 두고, 그 클래스에서 DB repository 계층과 소통한다고 한다. 특히 발표자님께선 작은 규모의 프로젝트에서 버티컬슬라이스 아키텍처는 좋은 선택지가 될 수 있다고 얘기해주셨다.

 

Q&A 중에서 기억에 남는 질문은 아래와 같다.

`버티컬 슬라이스 아키텍처에서는 @Controller에 @Transactional이 사용되기 때문에 외부 API와 소통할 때에도 커넥션을 물고 있다는 단점이 존재한다`는 것. 와우, 개인적으로 트랜잭션에 관심이 많아서 그런지 굉장히 재밌는 질문이라고 생각이 들었다. 질문자분이 정말 대단하다고 느껴지기도 했고!

사실 layered architecture였다면 @Controller, @Service 분리하고 osiv를 끄면 해결되는 문제. 하지만 버티컬 슬라이스 아키텍처라면 컨트롤러 메서드, 서비스 메서드를 분리하고 그 메서드에만 @Transactional을 붙여야 되는데 그렇다면 모든 메서드를 public으로 바꿔줘야 한다. 아니라면 커넥션을 조금 더 감수하든지. 하지만 발표자분께서 작은 규모의 프로젝트에 적합하다고 하신 데엔 이유가 있다고 생각한다. 해당 커넥션을 감수할 수 있게 커넥션풀을 관리하는 대신, 생산성 및 의존성 관리를 확실히 챙길 수 있다면 버티컬 슬라이스 아키텍처도 좋은 선택지가 될 수 있다고 생각한다.

 

또, 큰 규모에서는 feature가 굉장히 많아 도메인 로직이 새어나가거나, feature에 따른 스파게티 아키텍처 및 코드가 될 수 있다고 생각한다. 그래서 작은 규모에 적합하다고 하신 듯! (아니라면 코멘트 남겨주세요! 코멘트 적극 환영 🙇🏻‍♂️)

 

개인적으로 아키텍처에 대해 이것저것 고민해볼 수 있어서 재밌었고, 특히 Q&A 시간이 정말 재밌었다 ㅎㅎ

버티컬 슬라이스 아키텍처를 구글링해보니 레퍼런스가 상당히 적었어서 알 기회가 없었는데, 발표로 버티컬 슬라이스에 대해 접근하고 얘기 나눌 수 있는 시간이 있어서 의미있었다고 생각한다.

하지만, 나는 아직까진.. 레이어드 아키텍처와 버티컬 슬라이스 아키텍처 둘 중 하나 고르라고 한다면! 바로 전자를 택할 것 같긴 하다.

 

노션에 정리한 내용을 참고하고 싶다면 아래에서 확인할 수 있다!

https://clean-nutria-44b.notion.site/c2c29d5d7d2248308a0db16418334840?pvs=4 

복잡함은 끝, 간결함의 시작: 버티컬 슬라이스 아키텍처

---

마치며

jojoldu(향로)님, 토비님과 함께 찍은 사진!

개인적으로 2021, 2022는 기술적으로 많이 얻어갔다면, 2023은 네트워킹 및 개발 외적인 역량으로 많이 얻어갈 수 있다고 생각한다.

2021, 2022, 2023 모두 뜻깊고 의미있게 다가왔다.

 

개발바닥, 유스방에서 온라인으로만 뵐 수 있었던 유명인사분들을 실제로 뵐 수 있어서 매우 영광이고 기뻤다.

마치 연예인을 만난 느낌!

 

또, 개발 컨퍼런스다보니 오랜만에 학교선배님, 그리고 우테코 크루들 얼굴 볼 수 있어서 기뻤다. 거의 우테코 정모 느낌도 들었다 ㅎㅎ

베루스, 오찌, 우디는 스태프로 있었고 토닉, 스컬, 로마, 애쉬를 만날 수 있었다.

포비, 리사도 만날 수 있었다. 리사는 4기 수료식 때 얼굴만 뵙고 인사는 못드렸었는데 오늘 컨퍼런스 시간에 얘기나눌 수 있어서 좋았다. 다음에 사내 슬랙으로 인사드려야겠다 :)

 

그리고 따로 후기에 적진 않았지만, 시니어분과의 네트워킹 시간도 매우 의미있었다.

피로곰님, 루기님을 실제로 뵐 수 있어서 되게 신기하고 뜻깊은 시간이었다.

SI, 연차에 따른 역량 등 다양한 Q&A가 오갔다. 스컬과 함께 루기님께 devops 관련 질문도 드릴 수 있었다.

 

2022 유스콘과 다르게 네트워킹 시간이 많아서 더욱 재밌고 인상깊게 행사에 참여할 수 있었다.

행사를 위해 테크살롱 룸 세팅해주신 스태프분들, 그리고 행사 주최해주신 제이슨께 정말 감사했다. Jason 만세 :)

내년 2024 유스콘도 오프라인으로 참여할 수 있길!