스터디를 준비하며 캐시워크 CTO님과 대화한 내용. 이놈의 주둥이가 항상 문제다.
사내 개발 문화에 기여하기 위해 8주간의 자바스크립트 기초 스터디를 진행했다. 진행하는 동안 정말 눈뜰새 없이 바빴던 거 같다. 매주 진행 되었고 모든 발표를 혼자 준비해야 했기 때문에 주말동안 자료 준비와 발표준비를 마치면 곧바로 다음 발표가 기다리고 있었다.
발표의 난이도도 쉽지 않았다. 기초라는 이름을 지었지만, 쉬운 이야기를 하지는 않았다. 스터디 모집동안 “주제가 어렵다” 라는 이유로 참여하지 못한 인원이 있었고, 스터디 도중에도 2명이 마찬가지로 “어려운 내용” 때문에 중도하차를 했다. 끝까지 남은 대부분의 인원들이 2~6년차 개발자 분들/이였다.
정말 힘들었지만 끝마치고 나니 보람찼고 많은 것을 전달 드리지 못해서 스터디원들에게 죄송한 마음도 생기더라. 특히 스터디를 마무리하면서 스터디원분들이 감사하게 해주신 말들이 있는데 이게 굉장히 묘해서 많은 생각이 들었다. 이는 비단 우리만의 문제는 아닐 듯 해서 공유차 이 글을 쓰기로 마음 먹었다.
전하고 싶었던 것들
나는 기술의 숙련도만이 전부는 아니라고 생각하는 편이다. 스승들님들에게 그렇게 배워와서 그런거 같다.
가령 예를 들자면
1.
Javascript의 Event Loop를 이해하려면 C로 만들어진 libuv 모듈을 직접 써보는게 좋다.
2.
Functional Component 쓸 줄 아는게 대단한게 아니다. 대신 UI를 그리는 아키텍쳐들이 어떠한 이유로 함수형 프로그래밍을 통해 성공을 만들어냈는지 고민해봐라.
등등 “기저가 되는 기술” 그리고 “해결하고자 했던 문제를 찾고 해결하기 위해 고민한 것들”을 배우라는 이야기를 귀에 피가 날 정도로 들어 왔다.
2019년 9월 29일 개발자가 된지 “13일 째” CTO님과의 대화
때문에 내가 같은 경력의 남들보다 잘 설명할 수 있는게 있다면 그것밖에 없다. 새로 나온 ES2021 문법이나 react-query 혹은 NestJS 사용법은 남들보다 잘 알려줄 자신이 없다.
대신에 자바스크립트 기초 를 주제로 삼은 것이 그러하다. 우리가 새로운 것에 쉽게 적용 할 수 있게 “기저가 되는 기술”과 “해결하고자 했던 문제를 찾고 해결하기 위해 고민한 것들 ”을 함께 찾아 나서는 자리를 만들고 싶었다. 그러기 위해선 자바스크립트 기초라는 주제가 썩 적절해 보였다.
실제로 8주간 매주 2시간씩 시간을 빌려 진행한 스터디 주제는 다음과 같다.
•
프로그래밍이란 무엇인가, 연산과 메모리의 이해와 이를 통한 Lazy, Eager, Proxy, Memorize등의 서브루틴 활용 사례
•
재귀적인 사고에 대한 이해, 알고리즘 문제 해결 방식에서 메모리의 점유와 권한을 활용한 코드 작성 사례
•
제어문과 루프의 이해와 이를 통한 클린 코드의 재 이해 및 React, Express 예제 분석
•
설계란 무엇인가. 함수를 만드는 법. 값과 식별자의 차이와 제어의 역전
•
“typicode”의 예제를 통해 이터레이터, 제너레이터, 코루틴을 이해하고 자바스크립트로 OOP 바라보기
•
자료구조의 사용, 기능추가의 어려움
•
Javascript Tokenizer 이해 및 Parser 구현, 유한 오토마타와 프로그래밍 언어
막상 작성하니 주제는 거창하지만 내용은 별것 아니고 그럼에도 1년 전에 알았더라면 좋을 법한 것들을 잘 선정했다고 생각했다.
그리고 뒤돌아 보면 정말 정말 잘 선정한 것 같다.
나는 개념과 기술을 전달 드리고 싶었던 것이 아니다. 그럴 수 있을 만큼 많이 알지 못한다.
대신 분명하게 나는 또래의 다른 개발자들에 비해서 낯선 사고방식을 가지고 있다는 것을 알고 있었다.
지금껏 ”기술을 만든 사람”의 시야로 바라 보려고 해왔고, 이것을 전달하고 싶었다.
좋고 나쁨을 나 스스로 판단할 수는 없었지만, 오랜 시간 주니어 개발자인 경력직들에게 낯선 경험은 적어도 흥미로울 것이라 생각했다.
전한 것들 그리고 전해진 것들
스터디는 매주 진행 되었고, 1시간 30분에서 2시간 가량의 분량을 준비했다. 다음 주에 미리 예습했으면 하는 내용이 있다면 과제를 요청드렸다.
가령 1 주차에서는 작성한 코드가 CPU와 메모리에 어떤 영향을 주는지에 대해 살펴 보았는데, 이를 잘 이해했다면 다양한 방법으로 응용할 수 있으리라 생각했다.
때문에 다음과 같은 과제를 요청드렸다.
문제
School은 데이터가 크기 때문에 생성하는데 5초의 시간이 소요된다.
Student는 School 정보를 가지고 있다.
Student의 school은 생성하는데 많은 리소스가 소요되므로, 조회하는 경우에만 School을 생성하고자 한다.
예를 들어 student.id 혹은 student.name을 조회를 즉시 할 수 있다.
student.school를 조회하는 경우에만 로드하는 5초의 시간을 소요한다.
예시 코드
// 이전 코드
function sleep(ms) {
return new Promise(resolve => setTimeout(resolve, ms));
}
async function createSchool() {
await sleep(5000)
return {
id: 1,
name: '링커리어’,
location: '역삼’
}
}
function createStudent(id, name, school) {
return {
id,
name,
school
}
}
const school = await createSchool() // 5초의 로딩 소요
const student = createStudent(1, '김철수', school)
console.log('student', student.id)
console.log('student', student.school)
// 개선하려는 코드
const student = createStudent(...) // 로딩 소요 시간 없음
student.id
student.name
await student.school.id // 5초 로딩
JavaScript
이를 개선하는 과정에서 Lazy, Eager, Proxy, Memorize 같은 개념들을 직접 적용해보고 React 라던지 NestJS 같은 유명 오픈소스에서 세계적인 엔지니어들은 어떤 식으로 활용하는지 코드를 탐구해보았다. 뿐만 아니라 이러한 문제가 CS 전반적으로 나오는 개념이라고 생각해서 인프라에서도 어떤 식으로 적용되는지 잠깐 훓어보는 시간도 가졌었다.
이 때 발표 및 과제를 준비하면서 항상 신경썼던 부분은 함부로 용어를 쓰지 않도록 하는 것이였다.
위 포스트 내용에 많이 공감하는 편인데, 요점은 낯선 단어의 사용이 전달하려는 본질을 해치는 경우를 만든다는 것이다. Lazy라던지 Proxy 등의 낯선 용어와 복잡한 개념을 익숙해지기 전까지는 그냥 몸으로 익히는 훈련을 만들고자 노력했다. 용어를 배우고 적용하면 용어에 개념이 사로잡히지만, 몸으로 훈련하고 이후에 용어를 정리하면 더 넓은 의미로써 정확히 받아드릴 수 있으리라 믿기 때문이다.
물론 이후에 용어 정리는 반드시 필요하다. 개발자에게 어휘력은 정말 중요하다!
그리고 배운 이후에는 꼭 React 와 같은 유명 오픈소스와 같은 엔터프라이즈환경에서 어떻게 사용 되고 있는지 살펴보는 시간을 만들었다. 우리가 배운 것의 Best Practice는 이러하다 정도를 공유하고 싶었다.
다시금 말하지만 이러한 것들이 단순한 지식 전달에서 그치지 않고, 새로운 경험을 마주하고 “코드를 잘하는 상태”의 기준점이 올라가는 동기가 되었으면 했다.
스터디를 마무리하며 전달 받은 댓글
실제로 또 다른 눈으로 볼 수 있었다. 라고 말씀해주셔서 정말 다행이라고 생각했다. 조금 더 욕심 부려 보자면 스터디원분들 모두 부디 이 시각이 “세계적인 기준”으로 향한 것 이였으면 좋겠다. 내가 목표로 하고 있고 내 스승님들이 그래 왔던 것처럼 말이다.
내가 배운 것들
발표 준비는 만만한 게 아니다.
8주라는 긴 시간 동안 혼자서 커리큘럼을 만들고, 발표 공간 및 스케줄을 잡고 준비하는 경험은 매번 익숙해지지가 않는다. 원래라면 8주간의 “기초 스터디” 이후에 “수학 및 CS 기초” 라는 주제로 2~3주 정도 더 진행할 예정 이였는데 회사 일정 및 개인 일정과 겹쳐 “수학 및 CS 기초”는 아쉽게도 연달아 진행하지 못했다. 다 해낼 수 있으리라 생각했는데 기초 스터디 이후에 완전히 퍼져버렸다.
유감스럽게도 첫 번째 배운 것은
“혼자서 2시간분량의 발표 내용을 매주 준비하는 것은 정말 어렵다” 이다.
특히, 이 맘 때 회사일도 너무 바빠서 8주간 평일 주말 할 꺼 없이 새벽 3~4시는 되야 잠에 들 수 있었다.
그럼에도 불구하고 스터디를 준비하는 동안은 뭐랄까… 내가 없어지는 기분이 든다.
스터디원들이 즐겁게 공부할 생각을 하면 몸이 아픈줄도 모르고 정말 열심히 할 수 있었던거 같다.
유용한 지식과 헛 공부
스터디 동안에 들은 질문 중에 “내용은 좋은데 실무와 관련이 없어서 유용한지 잘 모르겠다.” 라는 답변을 들었다. 이 말을 들었을 때 설득력 있게 답을 드릴 수가 없어서 대답을 피했다.
그러게... 왜 이런걸 배워야 할까?
이후에 정당성을 찾기 위해 내 자신에게 다시 되물어 봤다.
가령 Generator 라던지 Parser 의 원리 라던지 혹은 Browser의 동작원리 같은 것을 알 필요가 있을까? 이걸 알면 내가 현재 직면한 문제에 대처할 수 있는 힘이 생길까? 나는 월드클래스급의 오픈소스 만들 생각이 없는데, 굳이 피곤하게 React 코드를 들춰 봐야할까?
이 딴 그림을 보고 이해하는 것이 정말 나와 내 동료들의 퇴근시간을 앞당겨주거나 월급을 올려줄 수 있는 걸까?
가령 브라우저 동작원리는 클라이언트 최적화 작업을 진단하는데 있어 가장 유용한 지도일 것이다. 이정표들에서 발생하는 작업들을 알고 있다면 어느 부분에서 문제를 발견하고 해결하면 좋을지 위 그림이 알려줄 것이다.
그렇다. 일단은 “상황이 오는 순간 적절하게 꺼내어 낼 수 있다면 도움이 된다.“ 인거 같다.
다만 클라이언트 최적화 작업이 굳이 필요하지 않는 경우에는 어떨까?
사내에는 클라이언트 팀에 CMS위주로만 하는 전문가분들이 계신다. 그들에게 이것은 그림 따위일까 지도일까?
굳이 닥치지도 않을 미래를 걱정해서 와닿지도 않는 지식을 머리속에 집어넣어야 할까? 현실로 다가오면 그 때 준비하는 것이 가성비 넘치지 않나?
혹은 “아는 만큼 보인다.” 라는 말처럼 잘 몰라서 어떻게 도움이 되는지 모르는 것이 아닐까?
글쎄...... 이 답을 하기에는 경험이 부족하다고 생각한다.
”아는 만큼 보인다” 도 맞는 말이고 “상황이 오지 않는데 굳이 배워야 하나”도 맞는 말이라고 생각한다.
가치관의 차이라고 봐야할까? 2~3년 뒤의 나는 어떤 답을 할까?
풍부한 표현력 그리고 미묘한 뉘앙스
스터디 자료를 준비하며 어느 순간 깨달은 것 중 하나가 세계적인 수준의 개발자들은 많은 경우에 풍부한 표현력을 가지고 있다는 것이다. 나는 이것을 깨닫는게 굉장히 중요한 일이라 생각해서 이를 전달 드리려고 애썼다.
요즘 청소년들의 어휘력의 문제점
요즘 청소년기의 학생들은 어휘력이 약하다고 한다. 좋을 때도 “대박” 나쁠 때도 “대박”으로 표현하고 있는 것들이 그러하다. 말만 통하면 되는 것 아니냐라고 생각 할 수도 있겠지만 구분없는 어휘는 상황을 풍부하게 표현하지 못한다.
가령 “대박 좋아한다.” 라는 말이 설명하는 상황은 꽤나 한계가 있다. 정확한 의미를 이해하려면 여러 문장을 읽어 문맥에 대한 이해를 넓혀야 한다.
그렇다면 “애틋하다.” 라는 말은 어떤가. 우리는 이 문장 만으로도 여러 상황을 미리 예측하고 문맥에 대한 이해도를 높일 수 있다.
개발자 분들 중에 문학을 개발과 비유하는 것을 꺼려하는 것을 알고 있다. 하지만 나는 분명 닮아 있다고 느낀다.
우리는 코드를 파악할 때 Context(문맥)을 파악하고 이를 넓혀 간다. 가령 함수의 인자로 참조를 넘겨준다면 해당 기능을 통해서 “참조 값의 상태가 변경될 수 있겠다”. 라던지 “인자로 전달되는 참조 객체는 인터페이스라고 불리는 특정한 형태를 가지고 있겠다” 등을 예측할 수 있다.
코드를 예로 들어보면 다음과 같다.
// 방법 1
class SomeSingleton {
}
const singletonInstance = new SomeSingleton()
// 방법 2
const singletonInstance2 = new class {
}
JavaScript
둘 다 싱글톤 객체를 만드는 것을 목적으로 둔다.
하지만 방법1 의 표현력은 애매하다. 마치 “대박” 처럼 상황과 비슷하다. 싱글톤이기 때문에 다른 곳에서 사용하면 안된다는 것을 알아 차리려면 별도의 설명이 필요하다.
반면에 방법2 는 문맥을 이해하기 위한 표현력이 풍부하다고 볼 수 있다. 애초에 다른 곳에서 구현 할수도 없을 뿐더러 오히려 singletonInstance2 는 싱글톤 객체를 사용하겠다고 개발자에게 먼저 알려 준다. 이를 바탕으로 어떤 기능을 하는지도 대략적으로 유추할 수 있다.
이러한 것처럼 정확하게 코드를 작성하게 되는 것이 읽는 사람으로 하여금 풍부한 내용을 전달 할 수 있게 되고, 반대로 작성자의 미묘한 뉘앙스를 눈치 채면 적은 양으로도 코드를 이해 할 수 있게 된다고 믿는 편인다.
때문에 이러한 것들을 스터디 내용 곳곳에 담으려 노력했었다.
뛰어난 개발자분들이 프로그래밍을 문학과 비유하는 것을 꺼려한다는 것을 알고 있다.
그럼에도 불구하고 나는 이것이 꽤 닮아 있다고 생각한다.
마무리하며
뭔가 서로서로 낯선 것들을 많이 경험한 2달이었던거 같다.
평소에 하고 싶은 말들을 많이 전할 수 있어서 즐거웠고 스터디 팀원분들이 너무 좋게 봐주셔서 감사하다.
그리고 아무래도 나는 혼자 잘하는 것보다 무언가 알려주는 것에 소질이 있는 거 같다.
알고보니 나는 재능충?!
- 끝 -