42가 아니라면 그렇게 갑자기 개발자라는 길로 오지는 않았을 것 같아요. 이전에 교육 기획 일을 했기 때문에 ‘교육’이라는 게 제게 엄청나게 강한 키워드였는데요, 동경하던 혁신 교육 모델을 라이센스로 그대로 들여온다고 하니까 잘 체험해보자는 생각이었죠. 기대와 달랐던 것은 ‘친절하지 않다'는 것. 42에 대해 알고 있던 건 ‘교수자가 없고 학습자 중심이다' 이 정도였는데, 막상 들어와서 보니 교수자라는 존재가 없는 걸 넘어서 학습자에 대한 교육적인 배려라는 개념 자체가 없었어요(웃음). 42의 근본적인 가치는 뭐라고 해야 하지? 야생성? 42에서는 실무 현장과 학습하는 공간의 오차를 줄이는 데 관심이 있었어요.

이게 제가 생각했던 이상적인 교육의 가치와 충돌하는 부분이 너무 많았어요. ‘어떻게 이렇게 불친절 할 수 있지' 이런 생각도 많이 들었고요. 팀 프로젝트를 등록해야 한다는 걸 몰라서 많은 사람이 ‘빵점’을 받았을 때, 저는 당연히 정정해줄 줄 알았어요. 제가 살아온 사회의 상식선에서요. 그런데 그때 슬랙에 올라온 공지 네 글자가 ‘할많하않'이었거든요. 이렇게 대처하는 걸 보고 당황하고 분노했다가, 시간이 지나고는 공감하고 존중하게 되고. 그런 과정이 제겐 의미 있었던 것 같아요. 본과정에선 이런 강렬하고 인상적인 사건이 많이 없어서 오히려 아쉬웠어요.

1기 1차로 들어와서 1년 동안 열심히 42만 한 케이스입니다. 지난 3월에 이너서클을 돌파하고 나서는 42가 채워주지 못한 것들을 공부하고 준비하고 있어요. 취업하려니 갖춰져 있지 않은 건 우선 알고리즘이에요. ft_container에서 STL을 구현해본 건 코딩 테스트를 응시하는 데 도움이 되기는 했지만, 그래도 부족한 면이 있어서 부랴부랴 준비했어요. 지금은 push_swap이라는 과제가 생겨서, 교육과정이 PS(problem solving)이랑 더 연결된 것 같아요. 또 다른 건 42 안에서 한 것만 가지고 포트폴리오를 채우는 데는 한계가 있다는 점이에요. 어떤 서비스를 개발·운영하고 있는지에 대한 포트폴리오가 있어야 하는데 그 부분이 없어요. 직무 관련 최신 기술도 비슷해요. 데브옵스로 나아간다면 도커나 쿠버네티스를 다뤄본 경험, 루비 온 레일즈 개발자를 할 거면 마지막 ft_transcendence를 한 게 도움이 될 텐데요, 프론트엔드로 간다고 하면 직무 관련 기술을 익히기 어려운 것 같아요. 사실 이번에 ft_transcendence가 개정되고 타입스크립트로 리액트를 다뤄볼 수 있게 되면서 더는 유효하지 않은 말이 된 것 같긴 하지만요(웃음).

42 교육과정을 거치면서 개발을 배우는 데 강한 역량이 생기고, 근본적인 CS 지식을 갖추게 되는 건 사실이에요. 최신 기술을 학습하는 시간이 굉장히 단축되는 데 대해서는 늘 감사하게 생각해요. 42에 대해서 회의를 느끼는 분은 교육과정에서 다루는 것이 ‘옛날 기술'이라고 얘기하는데요. 저는 공부하면 할수록 옛날 기술부터 시작해서 한 단계씩 나아가는 흐름이 있다고 느껴져요. 그러니까 지난 컴퓨터 기술의 역사를 체험한다고 해야 하나? 옛날 기술을 배우는 것과 기술이 변화하는 과정을 따라가는 것은 다르니까 이 학습 자체가 가진 가치에 대해 크게 의심하지 않았어요.

코로나로 클러스터가 닫힌 상황에서 ft_transcendence를 진행했어요. 처음에는 온라인 협업이 잘 안 됐죠. 주 2회 미팅을 하는데, 서로 제대로 하는지도 잘 모르겠더라고요. 그래서 컴퓨터를 하고 있는 거라면 디스코드에 하루 종일 접속을 유지하기로 했어요. 필요할 때 연락을 취하는 게 아닌 연결된 상태를 디폴트로 가져간 게 제일 잘했던 선택인 것 같아요. 나중에는 음성 채널도 1클러스터, 2클러스터 등등 나눠놓고, 밥 먹을 때는 ‘식당 채널’에 들어가 있는 식으로 로컬라이징 했어요. 모두가 적응을 마치니까 클러스터 나오는 것보다 편해지더라고요. 원격으로 있으면서도 같이 존재한다는 느낌을 강하게 받으니까요.

팀 프로젝트를 할 때는 무조건 모든 태스크에 최소 2명이 배정됐어요. 두 사람 이상이 라이브쉐어로 같이 접속해서 대화하며 코딩할 수 있게끔요. 혼자 작업하는 순간이 아예 없도록 한 거죠. 혼자 코딩하면 막히는 것에 대해 물어볼 수도 없고 동기부여도 떨어져요. 그 사람이 작업하고 있는지 안하고 있는지, 빨리 끝내고 쉬고 있는지 알 수가 없고요. 아, 그런 것도 있어요. 이 과제를 빨리 끝내는 게 중요한 게 아니고, 협업적 역량을 최대한 많이 길러야 한다고 생각했어요. 그래서 일부러 팀 최대 인원인 5명을 모두 채웠고, 좋은 코드에 대한 토론을 최대한 많이 하려고 했죠.

무엇보다 동료학습에서 중요한 건 문제를 해결하는 과정에서 본 레퍼런스를 공유하는 것이라고 생각해요. 실제 프로젝트를 하다보면 ‘스택 오버플로우'류의 사소한 문제 해결 관련 자료가 중요해지거든요. ft_transcendence 과제를 할 때는 디스코드를 이용해 카테고리도 나누고 해시태그도 달아서 자료를 올렸어요. 자료를 공유해도 어떤 의미인지 알기 어렵거나 다시 찾아보기 어려운 문제가 있어서 고안한 방법이었죠. 레퍼런스를 어느 수준으로 참고할지에 대한 관점도 중요한 것 같아요. 저는 아예 답이 안나오는 문제를 제외하고는 해외 카뎃들의 레퍼런스를 참고하지 않았어요. 참고해야 할 경우에도 팀원 중 한명 정도만 봤어요. 한 사람이 가진 레퍼런스 수준으로 떨어뜨려서 이야기를 하는 거죠. 우리 모두가 보게되면 다들 그 레퍼런스를 신경쓰게 되니까요. 특정 코드에 갇히지 않으려고 노력했던 것 같아요.

당장 취업을 위해 적성에 맞는 분야인 프론트 위주로 학습하고 있지만, 장기적으로는 교육 창업을 하고 싶어요. 그래서 서비스 초기 빌딩에 대한 개발 전반 역량을 기르는 것도 큰 관심사예요.

최근에는 ‘회사에 들어가서 실무 하는 느낌을 주는' 스토리텔링 기반의 학습 콘텐츠를 만들고 있어요. 일단은 자바스크립트 콘텐츠를 만들고 있고, 잘 된다면 구글 오피스 등 프로그램 외의 분야로 넓혀나갈 수 있겠죠. 이너서클 과제 중에서 비슷한 예가 딱 하나 있는데요. CPP 모듈의 문제입니다. ‘은행에 입사했는데, 코드가 일부분 손실돼있는데 이 부분을 복구하라' 이런 스토리텔링이 들어가 있어요. 그러면서 그 회사에서 그 개발자가 만들었을 때 썼었던 테스트 파일을 줘서, 테스트 파일 로그를 돌려가며 분석해서 과제를 해결해야 하는데요. 이건 내가 정해진 과제를 구현하는 게 아니라 ‘일을 한다'는 느낌을 줬어요.

요즘은 개인적으로 ‘개발을 배우는 과정에서의 행복’이 중요한 가치라는 생각이 들어요. ‘어떻게 빨리 익힐 수 있을까' 이런 고민도 중요하지만 ‘어떻게 해야 이걸 받아들이는 과정이 행복할까’에 대한 고민이 시간이 지날수록 더 중요하게 느껴져요. 사실 이런 고민은 기술 자체가 진짜 재밌는 분들, 고민 없이 꾸역꾸역한다는 분들에게는 해당 사항이 없어요. 저는 그런 쪽은 아니라서 이런 점을 중요하게 여기는 것 같아요.

‘월간 윤종신’처럼 한 달에 하나씩 서비스를 만들면 인생이 참 재밌겠다 싶어요. 교육 쪽에서 제대로 된 서비스를 만들어서 확산해나가고 싶지만, 그것 외에도 흥미로운 콘텐츠와 비즈니스 모델들도 만들어보고 싶어요.