유스콘 23 후기 (부제 : 좋은 개발자로 성장하기)

이번에 유스콘을 처음으로 오프라인 참석을 해봤습니다. 유스콘은 유쾌한 스프링이라는 오픈 카카오톡 커뮤니티에서 시작된 행사로 매년 많은 주니어 분들이 지식 공유를 위해 자원하여 발표 하고 있는 행사입니다. 

이번에 총 6개의 발표 세션을 들었습니다. 이에대한 후기를 좀 써볼가 합니다.

모두의 Server-Sent-Events

처음 들었던 세션은 server sent events를 hands on으로 따라쳐보면서 실습하며 뭔지 알아가는 시간을 갖는 발표였습니다. Server sent evnets는 websocket과 polling과 같은 기술과 비교되는 실시간성 알림같은 기능에 쓰이는 기술인데요. 

 

websocket과 달리 단방향 프로토콜이며 이벤트가 서버 -> 클라이언트 방향으로만 흐르는 단방향 통신 채널이라 polling 방식 처럼 주기적인 클라이언트 요청이 필요하지 않아서 큰 장점을 갖고 있다는 내용등을 듣고 실습해보면서 굉장히 흥미가 생겼습니다. 

출처 : https://velog.io/@max9106/Spring-SSE-Server-Sent-Events%EB%A5%BC-%EC%9D%B4%EC%9A%A9%ED%95%9C-%EC%8B%A4%EC%8B%9C%EA%B0%84-%EC%95%8C%EB%A6%BC

 

앞으로 더 공부해봐서 필요한 일이 있을 때 websocket과 함께 고려해보면 어떨까란 생각이 들었던 것 같습니다. 그리고 발표자도 준비를 많이 해오셔서 그런지 궁금한 질문에도 바로 해소 시켜주셨습니다. 굿 b

 

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

두 번째는 ELK 스택을 도입하여 이벤트 기반 데이터들 (구매 이벤트나 클릭 이벤트 등)을 쌓고 로그를 추출하여 활용하는 API를 만들면서 겪었던 문제나 고민등을 공유하는 발표였습니다.

내용을 들으면서 ELK에 대해 많이 배웠던 유튜브 강의를 공유해주셨던 점이 좋았습니다. 특히, ELK를 쓰면서 Elastic search를 사용하면서 Index라는 데이터를 모아놓은 집합의 개념이 있는데 이 때 인덱스 기반으로 타입을 구분하기 위한 mapping을 해주는 동작으로 인해 문제가 발생할 수 있다는 내용이 기억이 납니다. 

현재 필자도 회사 로깅 중앙화를 위해 ELK를 고려하고 있는데 반드시 이를 고려하여 인덱스 설계를 해야할거 같다 라는 생각이 들었습니다.

https://esbook.kimjmin.net/03-cluster/3.2-index-and-shards

3.2 인덱스와 샤드 - Index & Shards - Elastic 가이드북

위 사이트는 관련 공식 문서입니다.

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

필자를 포함한 많은 주니어 개발자들이 기술에 늪에 빠지기 쉬운데 실제로 발표자가 이런 늪에 빠져있다 빠져나오면서 느낀 자신의 생각을 공유하는 시간이었습니다.

제가 처음 회사 입사해서 다양한 기술적인 도전을 했던 경험이 있었고 그 과정에서 많은 실패를 겪었었는데 대부분 기술의 늪에 빠져 환경을 고려하지 못한 경우가 많았습니다. 

 

정말 필요한걸까? 지금 환경에 적합한 기술일까?를 고려하는 습관을 길러보면 좋을 것 같다란 생각이 들었습니다. 또, 기술은 그저 수단이고 기술은 학습에 수단으로 봐야지 기술에 집착해선 안된다는 문구도 인상적이었습니다.

 

그럼? 기술을 학습에 대상으로 봐야한다는 건 무엇일까요? 집착이랑은 다른걸까요? 

 

제 생각을 공유해드리자면 기술을 학습하는 이유는 뭘까요? 필자는 문제를 해결하기 위한 선택지를 늘리기 위함이라고 생각합니다. 그러니 선택지를 넓히기 위한 학습의 대상 그 이상도 이하도 아닌 것이죠.

그치만 남들도 하니 우리도 해야한다. 내가 배워봤는데 이게 성능이 더 좋으니 무조건 이걸 쓰는게 좋다 라는 등의 얘기는 집착에 가깝습니다. 기술에 집착하고 기술 사용에 대한 환상을 갖고 있기 때문에 오버엔지니어링의 늪에 빠지기 쉽죠.

 

결론적으로 기술의 늪에 빠지지 않기 위해선 기술은 학습의 대상으로 보고 집착하지 말자는 것입니다!

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

네 번째 발표 내용은 주어진 환경 내에서 주어진 지식을 갖고 문제를 해결한 경험을 공유하는 내용을 들었습니다. 당시 회사에서 서버에 대한 의존성을 분리하기 위해 Message Queue를 쓰려고 했지만 러닝커브나 일정 문제로 Database와 scheduler를 이용하여 데이터를 처리하는 방식으로 해결한 경험을 공유해줬습니다. 

 

이 부분은 저도 얼마전 docker swarm을 도입했을 때도 비슷한 경험을 했었어서 저도 공감이 많이 되는 내용이었습니다. Kubernetes의 러닝커브나 세팅 등은 많은 러닝커브를 요구했었는데요. 이러한 문제로 도입하는데 쉽진 않았습니다. 그래서 그 상황에서 최대한 문제를 해결하기 위한 가장 나은 솔루션이고 기존에 docker를 사용해봤기 때문에 제 지식에 있는 내용을 기반으로 최대한 빠르게 일을 진행했던 기억이 있었는데요. 

 

위 발표 내용도 그에 대한 내용들을 다루고 있어 이입하여 들었던 것 같습니다. 

너 납치 된 거야 (feat. Devops)

다섯 번째는 주니어 데브옵스분이 나오셔서 데브옵스가 무엇인지 설명하는 시간이었습니다. 아무래도 유스콘 특성상 대부분 백엔드 개발자였어서 데브옵스의 프로세스를 설명하고 개발자도 데브옵스를 왜 알아야하는지 위주로 설명을 하셨습니다. 

 

저는 회사에서 비슷한(?) 업무를 수행했다 보니 개발자도 데브옵스를 알아야한다는 생각에 많이 공감되었던 것 같습니다. 또한 데브옵스 엔지니어가 뭘 하는지도 정말 자세히 설명해주셨던거 너무 좋았던 것 같습니다. 사실 데브옵스 엔지니어가 없는 환경이라면 궁금할법한 내용이었던 것 같습니다. 

 

데브옵스를 직업이라고 오인하실 수도 있는데 데브옵스는 문제를 발견하고 해결하는 하나의 프로세스에 가깝다고 생각합니다. 그리고 발표에서도 나왔었는데 데브옵스는 철학이고 문화입니다. 문제를 해결하기 위한 모니터링 분석 개발 후 테스트 배포 등이 데브옵스 프로세스에 해당됩니다. 

그리고 데브옵스 엔지니어는 이 과정에서 반복되는 업무들을 개발자가 신경쓰지 않게 지원해주는 역할을 합니다. 개발자가 비즈니스 로직에만 집중할 수 있도록 반복적인 업무들 자동화 하는데 집중합니다. 

 

결론적으로 백엔드 개발자도 이러한 과정을 데브옵스 엔지니어가 지원해주지만 프로세스를 이해하고 있어야 고객에게 더 좋은 품질의 소프트웨어를 제공해줄 수 있는 개발 문화를 구축할 수 있다고 했던게 발표 내용에 결론이었던 것 같습니다. (내용 굿 b)

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

마지막으로, 버티컬 슬라이스 아키텍처를 도입하여 핵사고날 아키텍처의 복잡함을 해결해나가는 과정에 대해 발표를 했었습니다. 제가 공감했던 내용은 핵사고날의 복잡함이었습니다. 물론 핵사고날은 infra에 대한 의존성을 분리하고 유연하고 확장하기 좋은 코드 아키텍처라는 장점이 있습니다만, 요구사항에 요청 값 필드가 하나만 더 늘어나도 변경해야할 코드가 많아 시간이 오래걸린 다는 것입니다. 

 

이러한 문제를 해결하기 위해 버티컬 슬라이스라는 아키텍처를 도입하여 컨트롤러에서 모든 요청에 대한 간단한 처리를하고 반환하여 코드를 간결하게 만들어 오히려 유지보수성이 더 올라간 사례를 들었습니다. 물론 해당 아키텍처는 대규모 서비스에선 어울리지 않지만 규모가 작은 프로젝트에선 충분히 시도해봄직스러웠습니다. 

후기

다양한 발표를 들으면서 다양한 기술과 소프트 스킬을 배웠는데요. 정말 유익한 시간이었던 것 같습니다. 그리고 토비님과 자바지기님 만난것도 너무 좋았기도 했고 질의 응답도 많이 했었는데 정말 생각도 깊으시고 많이 배웠던것 같습니다. 

그리고 다양한 기술을 배운것도 좋았지만 더 좋았던건 네트워킹이었습니다. 제 블로그 구독자분도 만났었고 커뮤니티에서만 뵙던 분들을 실제로 보니 또 다른 느낌이기도 했습니다. 

 

앞으로는 이런 행사가 있다면 자주가고싶네요 .... !

 

마침.