Elice AI 트랙 1차 스터디 (백설기 팀) 회고

이번 글에서는 제가 활동했던 elice ai트랙 6기 1차 스터디인 백설기 팀의 6주간 활동에 대해서 회고를 해보고자합니다.

0. 스터디 개설

엘리스 1차 스터디는 12월 5일부터 12월 8일 까지가 스터디를 개설하거나, 혹은 참여하는 기간이었습니다. 저는 여기서 내가 스터디를 개설할 것인가 혹은 다른 사람이 만들어둔 스터디에 참여할 것인가 에 대해서 고민을 했었습니다.

 

결론은, 내가 스터디를 만들자였습니다. 별 다른 이유는 없었습니다. 그저 내가 아는 지식들을 공유하고 싶었고, 내가 백엔드를 근 1년간 (정확히는 2022년 3월부터 시작했으니 이제 10개월 이겠지만요!) 공부하면서 얻은 노하우들을 공유하고싶다는 생각밖에 없었습니다.

 

그래서 일단 스터디를 개설했습니다. 스터디의 이름은 백설기 인데요, 백설기 이름의 의미는 아래와 같습니다.

백엔드 설계와 코딩, 기초부터 쌓자!

작명센스가 부족한게 티가나네요

 

굳이 스터디 이름을 저렇게 지은 이유라면, 제가 최근에 읽고있었던 개발서적을 보면서 문득 백엔드를 하려면 사실 기초적인 CS부터 쌓는게 제일 중요하지 않을까? 라는 생각이 들어서였습니다. 실제 예로 제가 읽고있던 그 개발서적에는 아래와 같은 문장들이 있었습니다.

카프카 역시 OS의 페이지 캐시를 활용하는 방식으로 설계되어 있습니다. 페이지 캐시는 직접 디스크에 읽고 쓰는 대신 물리 메모리 중 애플리케이션이 사용하지 않는 일부 잔여 메모리를 활용합니다. 이렇게 페이지 캐시를 이용하면 디스크 I/O에 대한 접근이 줄어들므로 성능을 높일 수 있습니다. - 실전 카프카 개발부터 운영까지 (고승범 저)

위의 문장은 현재 MSA 환경에서 크게 대두되고 있는 Kafka 라는 이벤트 브로커 미들웨어에 대해서 다루는 개발서적에 등장합니다. 아마 기초 CS를 모르는 상태에서는 아래와 같은 의문이 들지도 모릅니다.

• 페이지 캐시가 뭐지?
• 물리 메모리? 메모리는 원래 물리적인게 아닌가?
• 페이지 캐시를 이용하면 왜 Disk I/O가 줄어드는거지?
• Disk I/O는 왜 페이지 캐시를 이용하는 것에 비해서 성능이 떨어지는거지?

따라서 MSA니, Redis니, Docker니, 컨테이너 오케스트레이션 그런거 등등의 기술 스택을 따지기 이전에 우선 쌓아야할 것은 기초라는 생각이 들어서 스터디원과 같이 기초부터 닦아보자 라는 마음에 스터디를 개설하게 되었던 것 같습니다.

1. 생각보다 쉽지않은 스터디원 모집

백설기 스터디를 개설하였습니다. 이제 해야할 것은 스터디원을 모집하는 것이었는데요, 제가 스터디 소개를 너무 빡세게(?) 적은 탓인건지, 혹은 애초에 백엔드를 목표로 하는 사람이 적은 탓인건지는 몰라도 스터디를 개설하자마자 사람이 몰리던 프론트엔드, 복습 스터디에 비해서 좀 사람이 느리게 모집되는 경향을 보였습니다(결과적으로도 백엔드 스터디는 100명이 넘는 인원 중에서 저희 팀 한 팀밖에 안 나오더라구요).

 

내가 만든 스터디의 소개글이었던 것

게다가 조사해온 것을 바탕으로 주 단위로 발표를 진행해야하는 스터디다 보니 부담스러운 것도 아마 사실이었을겁니다.

 

그래도 다행인 점이라면, 스터디 모집 둘째날까지 저를 제외하고 대략 9분 정도에게 DM이 왔었고, 목표했던 7인 스터디를 만들 수 있게 되었습니다(다들 매우 감사합니다 ㅠㅠ).

2. 생각보다 비전공자가 많다

아마 제가 스터디를 운영하면서 제일 어려웠던 고민이 아니었을까 싶습니다. 저희 스터디는 총 7명으로 구성이 되어있는데요, 7명 중에서 저와 한 분만이 컴퓨터를 전공하셨습니다(사실 나는 복수전공이지만). 그 외에 5분 중에서는 문과 출신인 분도 계시고, 이과지만 컴퓨터와는 전혀 거리가 멀었던 삶을 사신 분도 계셨습니다. 

 

이런 사람들이 모여있는 스터디에서 공통 주제를 뽑아서 발표를 하는거란 영 진짜 쉽지가 않습니다. 누군가는 어? 이거 너무 쉬운데? 개꿀 ㅋㅋ 할수도 있고, 누군가는 아...너무 어려워요 ㅠㅠ GG치고싶어요 할수도 있기 때문입니다.

 

결국에 주제를 선정함에 있어서도 난이도 조절이라는 줄타기를 매주마다 해야했고, 백엔드를 설계함에 있어서 필요한 CS지식의 허들은 일반적으로 비전공자가 넘어서기에는 너무 높다는 특징도 있어서 이러한 부분도 매우 고민을 했던 스터디가 아니었나 싶기도합니다.

 

결론적으로는, 아래의 방침대로 스터디를 운영해보기로 결정했습니다.

상대적으로 쉬운 주제, 어려운 주제를 섞어놓자. 그러면 각자 수준에 맞는 주제를 선정해서 조사를 하고 발표를 하지 않을까...?

3. 아이스 브레이킹

12월 12일부터 본격적으로 백설기 스터디를 운영하기 시작했습니다. 아무래도 다들 처음보는 사람들이다보니 서로서로 어색한 상태였습니다. 그래서 일단 각자 친해지는것 부터가 스터디 운영의 시작이지 않을까해서 스터디 시작 첫 날에 아이스 브레이킹을 해보기로 했습니다.

 

다행스럽게도 저를 포함 5명이 아이스 브레이킹에 참여해서 서로서로 친해지는 계기를 가지기는 했습니다. 두 분은 하필 그 날에 일정이 있으셔서 참석을 못하셨긴했지만, 뭐 다음에 인사하고 친해지면 되니까! 하고 넘어갔던 아이스 브레이킹 시간을 가졌습니다.

4. 본격적인 스터디 운영의 시작 (1주차부터 6주차까지)

스터디 발표를 진행하기에 앞서서 스터디원 모두에게 당부했던 말들이 여러개 있었습니다. 잘 전달이 되었으면 좋겠다는 마음으로 아래의 사항들을 전파하였습니다.

• 모르는건 당연한거에요! 모르는게 생기면 언제든지 팀원들에게 질문을 하시면 정성들여서(?) 답변을 해드릴거에요!
• 발표 주제들에 대해서 크게 부담을 가지지 말아주세요! 그저 자신이 가능한 부분까지만 조사를 해오셔도 잘하시는겁니다!

12월 17일부터 발표를 시작했습니다. 첫주는 다들 몸풀기 식으로 CS 개요들로 시작을 했습니다. Network는 OSI 7 레이어가 뭔지, Database는 파일시스템과 무슨 차이가 있는건지, CPU가 뭐고 memory가 뭔지 등등 일단은 바닥부터 닦는다는 느낌으로 갔습니다.

 

그렇게 스터디가 순조롭게 흘러가는듯 보였으나, 제 생각에는 스터디 3주차, 4주차가 거의 고비가 아니었는가라고 생각이 듭니다. 3주차부터 엘리스 부트캠프는 Node.js 를 가르치기 시작하였는데요, 아무래도 바로 전까지 JS 실행 컨텍스트와 Promise, Async/Await 을 배우다가 바로 Node.js와 express 를 배우기 시작하였다보니 다들 수업만 따라가기도 매우 벅찬 상태였을겁니다.

 

그 상태에서 스터디에서 조사해오라는 주제는 점점 괴랄해지기 시작하니...다들 아마 매우 멘탈이 나가는 주간이었을겁니다. 3주차, 4주차의 조사 주제는 아래와 같았습니다.

• 3주차: JS 비동기와 Node.js 아키텍처 (Libuv가 이벤트를 처리하는 과정 등등..), 정렬, 연결리스트, Transport Layer, 깃 브랜치 전략, RESTful API, 쓰레드
• 4주차: 소프트웨어 아키텍처의 중요성과 Layered Architecture 구현해오기, TCP의 데이터 순차전송 보장 원리 (accumulated ack, 3-duplicated ACK, Timeout), 트리 자료구조, 프로세스 동기화 (뮤텍스, 스핀락, 세마포어)

Node.js passport에 대한 이해, jwt, session, cookie, router, middleware도 이해하기 어려울수도 있는데 저런 주제를 조사해와서 발표를 해야했으니... 난이도 조절 실패를 저질러버린게 아닌가라는 생각이 듭니다.

 

그래서 5주차 발표는 난이도 조절을 하기로 결심하게되었습니다. Agile 개발 방법론, B-tree와 인덱스, 리눅스 환경에 node.js 배포하기, SQL, 서버간 통신 (json, gRPC)에 대해서 주제를 분배하기로 결정합니다. 

 

저는 저런 주제로 분배를 하면 다들 쉽게 해올 수 있을것이라 생각했지만, 딱 하나의 주제는 난이도 조절에 실패해버렸습니다. 서버간 통신이 조사하기 쉬울거라고 저는 생각했지만, 저의 오산이었습니다. Json Serde가 왜 오버헤드가 큰지에 대해서는 비전공자로서는 조사해오기 힘들었던 것이었고, gRPC는 워낙 레퍼런스가 없다보니 그것도 조사해오기 힘들었던 것이었습니다.

 

6주차 스터디의 경우 설 바로 전 주차이기 때문에, 다들 Node.js 모자란게 있다면 복습을 했으면 좋겠고, 설 바로 다음이 프로젝트 기간이기 때문에 힐링을 하면서 서로 모여서 스터디 복기도 하고 회고도 하자는 마인드에서 조사 주제는 선정을 안하기로 하였습니다. 생각보다 회고 라는 행위는 중요하기도 하니까요!

5. 마무리

처음으로 돌아가서 생각해봅시다. 백설기 라는 이름의 의미는 백엔드 설계와 코딩, 기초부터 쌓자! 였습니다. 기초 CS는 제 생각엔 운영체제와 TCP의 3-way hansshake, 4-way handshake, 흐름제어, 혼잡제어 정도만 제외하면 매우 충분히 다뤘다고 생각은듭니다.  하지만 스터디를 설계했을 당시에 생각했던 이 정도는 다뤄야하지 않을까? 싶었던 것도 몇개 못 다룬것은 존재합니다. (MSA의 구성요소를 다루고 싶었지만, 다들 머리가 터질까봐 다루지 못했...)

 

저는 스터디를 운영하면서 몇가지 철칙을 지키려고 하였는데요, 그건 아래와 같습니다.

• 최대한 기록을 남기자. 나중에 다시 보더라도 생생하게 기억이 날수있게.
• 스터디원들을 배려하자. 각자의 출신 환경들이 매우 다르기 때문에 내가 스터디원들을 모두 제어할 수 있을거라는 생각은 하지말자.
• 욕삼은 자제하자. 내가 생각하는 기초와 다른 인원이 생각하는 기초의 위치는 다르다.

첫번째와 두번째는 잘 지킨 것 같지만, 돌이켜보면 세번째 철칙은 잘 지키지는 못했던 것 같습니다. 주제를 선정하면서도 항상 아...이 정도는 그래도 백엔드 엔지니어가 되려는 사람들이면 알아야하는거 아닌가? 라는 생각을 해버리면서 매우 어려운 주제를 선정해버린 적이 몇번 있었기 때문입니다.

 

본격적으로 이 글을 마무리 하겠습니다. 저에게 백설기 스터디는 매우 독특한 환경이었던 것 같습니다. 평소에는 제 주변엔 복수전공자, 소프트웨어 전공자, 그리고 현업자들만 있었던 환경이었다 보니 스터디를 운영하고, 스터디의 팔로워로 참여를 하여도 커다란 장벽은 없었던 느낌이었습니다. 하지만 이렇게 많은 비전공자와 함께하는 CS 스터디는 아예 처음이었기 때문에 제가 어떤 부분이 많이 모자랐는지도 깨닫게되는 그런 스터디가 아니었나 싶습니다.

 

이번 백설기 스터디를 운영해본 경험을 발판 삼아서, 다음의 나는 더 나은 사람으로 발전하자 생각이 듭니다. 긴 글 읽어주셔서 감사합니다!