개발자는 코드를 작성하는 일보다는 코드를 읽은 일에 훨씬 많은 시간을 소요한다. 2017년에 나온 measuring programing comprehension 논문에 따르면, 약 60%의 시간을 코드 해석에 사용한다고 한다. 자세한 내용은 논문을 보면 되는데, 실험 논문이어서 대략 실험 결괴 중심으로 보면 금방 읽을 수 있다.
코드를 읽을 때 프로그래머의 뇌는 장기기억, 단기기억, 작업기억공간(워킹 메모리)로 구분된다. 장기기억에는 오랫동안 축적된 프로그래밍적인 개념 및 지식들이 녹아있고 단기기억에는 지금 읽고 있는 코드들이 저장되고 작업기억공간에서는 이 둘을 혼합하여 해석이 이루어지기 시작한다. 조금 더 디테일하게 설명하면 장기기억을 기반으로 가설을 세우고 그 가설에 단기기억이 들어맞는지 확인하고 가설을 수정하고 검증하고 의 반복작업이 진행된다.
챕터2: 신속한 코드 분석
코드를 오랫동안 기억하기 위해서는 코드 내에 체계가 존재 해야 한다. 무작위로 배치된 체스 판은 체스 고수에게도 초보자에게도 모두 복기하기 어렵지만, 체스의 주요 행마법을 중심으로 배치된 경우 체스 고수는 금새 복기할 수 있다. 일종의 chunking으로 무작위성 내에서 구조를 파악할 수 있으니까. 즉 장기기억에 얼마나 많은 양의 지식이 구조적으로 축적되어 있는지에 따라서 기억할 수 있는 양이 커진다 라는 단순명쾌한 사실이다. 코드가 주요 디자인패턴 기반으로 개발되어 있을 경우 디자인패턴을 알고 있을 때 해당 코드를 복기하는 것이 쉬워지는 이유도 같은 맥락이다. 이미 알고 있는 구조에 새로운 기억이 잘 접착되니까.
또한 코멘트의 중요성도 언급되는데, 코멘트가 코드를 읽는 시간을 늘리기는 하지만 코멘트가 코드를 이해하는데 많은 도움이 된다는 실험적 결과를 언급한다. 음 궁금해서 코멘트의 개념을 도입한 첫번째 프로그래밍 언어가 무엇인지 찾아보고 있는데요. 아직 찾지 못했습니다. chatgpt는 pl/1 이라고 하는데, 신뢰가 가지 않네요 흠.
챕터5: 코드를 더 깊이 있게 이해하기
요르마 사야니에미 교수는 핀란드의 대학교수로 HCI(Human Computer Interaction)과 컴퓨터 교육 쪽을 주로 연구하는 교수인데요. 코드 대 변수를 다음과 같이 11가지로 그룹핑하였습니다. 원래 의미를 담기 위해 영어로 작성하였습니다. 몇가지 비슷한 의미가 있기도 하지만 대략적으로 다음으로 분류된다는 것을 인식하고 아래 내용을 사용하여 변수이름을 지으면 좋을 것 같아요. 이 또한 하나의 구조화전략이니까요.
fixed value, stepper, flag, walker, most recent holder, most wanted holder, gatherer, container, follower, organizer, temporary.
챕터6: 코딩 문제 해결을 더 잘하려면
하나의 문제를 풀기위한 방법은 여러 가지 입니다. 문제를 정확히 정의하고 비용함수를 정의했다고 할 때, 해당 시점에서 해당 목적함수를 최대화하는 방법은 단 한 가지일 것입니다(물론 시간이 지나면 그 목적함수가 달라집니다만). 문제를 푼다는 것은 바로 이 솔루션을 찾는다는 것을 의미하죠.
하나의 문제가 있을 때 해당 문제는 어떤 관점으로 바라보느냐에 따라서, 그리고 어떤 관점으로 모델링을 하느냐에 따라서 다른 문제가 됩니다. 혹은 다른 난이도를 가진다고 말할 수 있겠네요. 간단히 말하자면, 매트랩을 사용하면 모든 언어는 행렬의 조합으로 보이고 자바를 사용하면 모든 언어는 클래스의 조합으로 보이죠. 프로그래밍이라는 것도 결국 하나의 모델링인데요, 언어를 선택하는 것부터 모델링의 시작입니다(다른 말로는 설계라고 할 수 있겠죠). 물론 언어를 고른 다음에는 어떤 방식으로 설계하는지에 따라 또 달라지게 되겠습니다만.
문제를 풀기 위해서는 문제를 풀기 위해 작업기억공간에 만들어 낸 멘탈 모델(정신 모델)이 중요합니다. 가령, Tree를 떠올려보면 사실 트리는 컴퓨터 내에 존재하지 않습니다. 그냥 메모리 내의 값만 바뀌는 것이니까요. 그런데 우리는 메모리 값을 기억하는 것이 아니라 트리 를 기억하죠. 여기서 트리는 다시 말해, 실제로는 존재하지 않지만, 해당 문제를 풀기 위해 우리가 만들어낸 추상적인 모델을 말하죠. 즉, 멘탈 모델을 말합니다. 책 내에서는 정신 모델을 좀더 엄밀하게, “풀어야 할 문제를 추론하기 위해 사용할 수 있는 작업공간 내의 추상화”라고 소개합니다. 깔끔한 표현이죠. 제일 중요한 표현은 추상화 입니다. 추상화를 깔끔하게 표현하는 말은 “그렇다 치고”라고 생각하는데요. 걔가 뭘 하는지는 모르겠지만 그렇다고 치고 걔 주변을 생각한다는 느낌에서 특히 그렇습니다.
지금은 제가 프로그래머로서 일하고 또 나쁘지 않은 실력을 갖추고 있다고 생각하지만, 처음에는 변수에 값을 assign해주는 것부터 어려웠습니다. 당시 저보다 먼저 배웠던 친구가 박스에 값을 넣는 것이다 라고 설명해주었는데 그 설명이 더 어려웠던 기억이 나네요. 변수를 박스로 비유한 것이 그가 설명을 위해 차용한 멘탈모델인 셈일텐데, 제가 그 멘탈모델을 받아들이지 못했던 기억이 납니다. 지금은 그가 그 멘탈모델을 차용한 이유도 이해하고 그 멘탈모델을 제가 이해하지 못했던 것 또한 이해가 됩니다. 사실 멘탈모델은 한 가지만 존재하는 것이 아니니까요. 관점에 따라 여러 가지의 멘탈 모델이 존재할 수 있고, 지식이 쌓여감에 따라서 과거의 모델은 폐기되고 새로운 모델이 생성됩니다. 이렇게 쓰고보니 과학혁명의 구조 에 나온 패러다임이론이 떠오르네요.
결국 모델에 대한 이야기입니다. 문제를 풀 때 단일한 하나의 아름다운 모델만 존재할 수 없습니다. 만들어진 모델 조차 틀릴 수 있음을 이해해야 하죠. 그리고 세상에는 우리가 선택할 수 있는 많은 모델링 기법들이 있습니다. 네트워크로 모델링할 것인지, 매트릭스로 모델링할 것인지, 페트리 넷으로 할 것인지, 시퀀스 다이어그램으로 할 것인지, 디자인패턴으로 할 것인지 등 수없이 많죠. 생각해보면 공학은 결국 모델링에 대한 얘기인 것 같아요. 이렇게 쓰고나니 더 명확합니다. 매우 당연히 하나의 현상을 설명할 수 있는 모델은 여러 가지 존재할 수 있다는 것이 아주 명확해집니다.
개념적 기계는 멘탈모델과 유사해보이지만, 컴퓨터에 가까운 개념 입니다. 일반적으로 프로그래밍 언어를 설명할 때 사용되는데요, 컴퓨터가 작동하는 방식 을 개념적 기계라고 말합니다. 가장 분명한 차이는, 프로그래밍 언어의 실행과 관려되어 있기 때문에 일관적이고 정확한 행동을 한다는 것이죠. 하드웨어의 동작에 대한 프로그래밍적인 추상화 라고 이해하는 것이 더 쉬울 듯합니다. 프로그래밍 언어별로 참조, 메모리 주소 등에 따라 달라지는 부분이 생기는데, 이 경우 언어 별로 다른 개념적 기계를 가진다고 할 수 있겠죠. 그리고 프로그래밍 언어에 익숙한 사람일수록 멘탈 모델과 개념적 기계간의 차이는 사라지게 됩니다.
어떤 멘탈모델을 고르느냐에 따라서 대상을 이해할 수 있는 정도는 달라집니다.
챕터7: 생각의 버그
장기기억(LTM)에 담겨있는 정신 모델은 새로운 정보를 이해할 때 도움을 줍니다. 이를 보통 전이(transfer)라고 부릅니다. 이미 프로그래밍 언어 하나에 익숙할 때 새로운 프로그래밍 언어를 배우는 것이 쉬운 것은 그런 이유죠. 물론 쉽지만 두 언어의 개념적 기계가 다르기 때문에 멘탈 모델을 수정하며 접근하는 것이 필요합니다. 그리고 당연하지만 장기기억 내의 지식이 얼마나 숙달되어 있는지에 따라서 트랜스퍼는 더 빠르고 강하게 일어납니다.
딥러닝 분야에서 transfer learning 이 유행이던 시절이 있었습니다(아직도 유행인가요?). 개념적으로는 이미 특정 분야에 학습된 모델을 사용해서 다른 분야에 적용한다는 것인데 이 개념을 느슨하게 잡고 각자 다들 나도 트랜스퍼 러닝 한다, 라고 말하던 시절이 있었습니다. 그래서 저는 트랜스퍼 러닝 전문가 라고 말하면 다 거짓말 쟁이라고 생각하는 경향이 있습니다.
트랜스퍼는 항상 긍정적인 방향으로 일어나는 것이 아닙니다. 개념적 기계는 다르고, 따라서 정신적 모델 또한 다르게 존재하기에 새로운 언어를 배울 때 기존의 정신적 모델과 동일하다는 가정 하에 접근하게 되면 현상을 완전히 설명할 수 없어 충돌되는 상황이 발생하게 됩니다. 이를 부정적 전이라고 보통 설명하죠. 쉽게 말하면 선입견으로 인해 새로운 현상을 정확하게 이해하지 못하는 상황이 부정적 전이 입니다.
돌이켜보면 고등학교 시절 배웠던 수학에서 x=2 는 정의였으며, 바꿀 수 없는 것이었던 반면, 프로그래밍에서는 그냥 하나의 대입일 뿐이었죠. 그래서 기존의 정신모델에서는 해당 변수의 값을 변경할 수 있다는 사실 자체가 매우 기이하게 여겨졌습니다. 이것이 바로 부정적 전이의 한 예가 되겠네요. 부정적 전이를 깨닫고 새로운 정신 모델로 변경하는 과정을 개념 변화 라고 부릅니다. 패러다임 시프트 와 비슷한 맥락이죠.
중요한 것은 내가 가지고 있는 멘탈 모델에 구멍이 존재할 가능성이 있다는 것을 인지하는 것이죠. 틀릴 수 있습니다. 그리고 틀리면 정신 모델을 뚝딱뚝딱 고쳐서 새로운 모델을 생성하면 그만 입니다. 자 발전했습니다. 너무 기쁘지 않나요?
챕터8: 명명을 잘하는 방법
개발자로서 자주 부딪치는 어려운 일은 변수 이름 짓기죠. 논문 how developers choose name 에서는 동일한 작업에 대해서 여러 개발자가 개발한 코드를 비교하여 동일한 작업 하에서도 변수 이름이 달라지는 현상이 있다는 것을 실험으로 증명하였습니다. 변수 이름과 함수 이름이 개인이 수행해야 하는 첫번째 문서화인 셈이죠.
좋은 이름이 무엇인지는 모호하지만, 나쁜 이름이 무엇인지는 상대적으로 명확히 정의할 수 있습니다. 저는 패턴보다는 안티패턴을 통해, 즉 소거법을 통해 좋은 변수 이름 짓기를 가능하게 할 수 있다고 생각합니다.
또한 전체 코드베이스 내에서 코드 변수명은 일관성이 있어야 합니다. 일관성 없이 좋은 변수명이 있는 코드베이스보다는 일관성 있게 나쁜 변수명이 있는 것이 더 좋다는 언급이 인상깊네요.
nmcntlst 와 같이 consonant만 남기는 형태보다는 좀 길더라도 name_count_list 로 변수 이름을 명명하는 것이 인지부하를 감소시키는 더 효율적인 방법입니다. 읽는 시간을 줄이는 것은 중요하지 않습니다. 이해하는 시간을 줄이는 것이 중요하죠.
relating identifier naming flaws and code quality 연구에서 잘못된 변수 이름이 많은 코드일 수록 버그가 많다는 사실을 발견했습니다. 물론 이 것이 변수 이름을 잘 지어야 버그가 없다라는 주장을 하는 것에는 무리가 있어요. 가령 시간이 없어서 빨리 프로젝트를 진행해야 했을 경우 이로 인해 변수 이름도 대충 짓고 버그도 많아질 수 있죠. 둘다 종속 변수일 수 있으니까요. 다만, 그러함에도 변수 이름이 많다면 이 코드는 버기할 지도 모른다고 의심해볼 수는 있습니다.
챕터9: 나쁜 코드와 인지 부하를 방지하는 두 가지 프레임워크
코드 스멜은 작동은 하지만 개선의 여지가 있는 코드를 말합니다. 마틴 파울러의 책, 리팩토링 에서 고안된 용어죠. 파울러가 언급한 22가지의 코드 스멜을 테이블로 정리해두었습니다. 메서드, 클래스, 코드 베이스 레벨에서의 문제점을 거시적으로 정리하자면, 보통 메소드 내에 너무 많은 코드가 정리되어 있는 경우, 클래스 내에 너무 많은 메소드가 있는 경우 코드 스멜이 있다고 할 수 있죠. 이렇게 너무 많은 기능이 포함된 경우를 여기서는 신의 메소드, 신의 클래스 라고 표현합니다. 뭐 그냥 코드 스멜 일 뿐이고 가독성과 유지보수성이 좀 어려워질 뿐이지 에러를 발생시키지는 않잖아? 라고 생각할 수 있습니다. 다만 an exploratory study of the impact od antipatterns on software changeability 논문을 보면, 이 안티패턴이 실제 버그 발생 가능성과 큰 관련이 있음은 물론, 추후 수정될 가능성도 높다는 것을 발견했습니다. 즉, 코드 품질이 코드의 안정성을 높인다 라는 것을 말하죠.
결과적으로, 코드 품질을 향상시킬수록 장애가 발생할 가능성은 낮아집니다. 단지 가독성이 개선되고 신규 기능을 빠르게 개발할 수 있다는 장점 외에도(물론 이 것도 엄청나게 큰 장점입니다만) 장애를 발생시키지 않고 안정적으로 서비스를 운영할 수 있도록 해준다는 것도 아주 큰 장점이죠. 그리고 우리가 아는 것처럼, 버그는 초기에 발견할 수록 들여야 하는 비용이 감소합니다. 당연한 말이지만, 자세히 설명하자면 코드 리뷰할 때 발견하는 것과 배포 한 다음에 발견하는 것의 비용 차이는 매우 크죠. 따라서, 코드 품질을 잘 관리해서 코드 리뷰 하기 전에 아예 버그를 발생시키지 않는다면 더 큰 비용 절감이 있는 셈입니다. 다만, 버그를 발생시키고 해결하는 것은 실제로 일이 있었고 일을 해결했기 때문에 일을 한 것인데요, 버그를 발생시키지 않도록 하는 것은 일(버그) 자체가 발생하지 않기 때문에 마치 아무 것도 하지 않은 것으로 보일 수 있습니댜. 그 일을 하든 안하든 아무 차이가 없는 것이죠. 개발이 메인이 아닌, 본업이 개발이 아닌 회사에서 개발팀이 가지는 딜레마가 이런 종류인 것 같습니다. 만약 “장애 0건” 이면 아 해당 팀은 필요가 없으니 해체한다, 와 같은 개념인 셈이죠. 장애 0건을 유지하기 위해서 무수히 흔들어야 하는 오리의 발움직임은 아무도 알아주지 않습니다. 쓰고보니 굉장히 넋두리가 되었군요 하하.
코드의 인지 부하를 측정하기 위한 다양한 방법이 정리되어 있습니다. 작업이 어려울수록, 즉 인지부하가 커질수록 깜박임이 줄어드는데요, 이는 인지 부하가 높을수록 시각적인 자극을 최대한 증가시키려고 하기 때문입니다. 눈을 깜박이지 않을수록 시각적인 정보값이 커지기 때문이죠.
인지 부하를 줄여야하는 것을 LTM 맥락에서 설명하자면, 최대한 장기기억공간과 익숙한 형태로 데이터가 전달되어야 이를 처리하기가 쉬워지는데요, 안티패턴이 존재하면 이를 처리하는 과정에서 충돌이 발생하여 인지부하가 커집니다. 따라서, 코드 스멜을 줄여서 인지 부하가 발생하지 않도록 하는 것이 장기기억공간을 효과적으로 사용하도록 하기 위해서 필요합니다.
챕터10: 복잡한 문제 해결을 잘하려면
내용 중, 작은 것들을 알아내는데 시간을 많이 쓰지 않을수록 어려운 문제들을 쉽게 풀 수 있다 라는 말이 인상깊네요. 가능한 작고 반복되는 문제들은 자동화하여, 인지부하를 줄여나가야 합니다.
책에서는 기억을 3가지로 구분합니다. 절차적 기억(a를 하고 나면 b를 해야 한다), 일화적 기억(과거에 어떤 개발하다가 장애가 난 적이 있었다), 의미적 기억( 1+1 은 2다) 로 구분하는데요. 책에서는 의미적 기억들을 반복하여 절차적 기억으로 변경하는 것을 자동화 라고 명명합니다. 한번 절차적 기억으로 변경하고 나면, 그 기억은 인지부하를 거의 발생시키지 않습니다. 따라서, 반복되는 지식이라면 인지부하를 발생시키지 않는 방향으로 처리해야 다른 복잡한 문제에 에너지를 더 쏟을 수 있겠죠. 조금 결이 다른 이야기이기는 한데, 저의 경우 매우 복잡한 배포프로세스를 수동으로 진행하면서 상당히 높은 수준의 인지부하가 발생하는 것을 경험했습니다. 이를 자동화해버린 다음에는 인지부하가 크게 감소하는 것을 확인했죠. 결이 다르지만, 충분히 훈련되지 않은 절차적 기억은 인지부하를 크게 발생시키게 되고, 따라서 이 인지부하를 삭제하기 위해 스스로 학습을 반복하거나, 아니면 완전히 외주를 통해 자동화하는 것이 필요합니다.
John sweller의 논문인 the use of worked examples as a substitute for problem solving in learning algebra 를 언급하며, 풀이된 예제(worked example)가 학습에 도움이 된다는 사실을 말합니다. 우리는 암묵적으로 “그냥 프로그래밍을 많이 하면 실력이 좋아진다”라고 말하지만, 이것이 사실이 아닐 수 있다고 말합니다. 다른 사람이 작성한 좋은 코드를 읽는 것이 더 빠르게 성장할 수 있는 방법일 수 있다고 말합니다. 저 또한 항상 다른 사람의 것을 보지 않고 스스로 풀어보는 것이 더 좋은 성장이라고 생각하며 살아온 것 같은데요, 더 좋은 코드를 읽고 더 좋은 문제 해결 사례 들을 보면서 외연을 넓히는 것이 필요하지 않을까 싶습니다.
챕터11: 코드를 작성하는 행위
이전 챕터에서도 비슷한 이야기가 있었지만, 프로그래머에게 업무중단은 심각한 업무비효율을 초래합니다. 특히 메시징앱의 사용이 증가되면서 업무 중단 자체가 매우 일반적인 일이 되어버렸죠. 개발이라는 일은 마치 미세회로을 연결하는 것과 같아서, 미세 회로 까지 도달하기 위해서는 일정 시간이 필요한데, 업무 중단이 발생하면 그 시간을 잃고 다시 집중하기 위한 시간이 필요해집니다. 뇌가 충분히 활성화되었을 때 메모리에 저장된 내용은 업무 중단으로 인해 모두 휘발되고 맙니다. 따라서 저는 가능하면 브랜치를 생성해서 내용을 어딘가에도 작성해서 커밋을 해두는 습관을 가지고 있습니다. 그렇지 않으면 잊어버리니까요.
어떤 사람들은 주석을 상세하게 작성하는 습관이 좋지 않다고 말합니다. 글쎄요. 저는 그런 사람과 함께 일하고 싶지는 않습니다. 아름다운 하나의 로직만이 존재하는 세계에서는 그럴 수도 있지만, 사실 현실에서는 다양한 의사결정이 발생합니다. 특히, 각자가 가진 정보가 비대칭적이기 때문에, 의사결정의 결과가 달라질 수 있죠. 따라서, 개발 과정에서 판단한 의사결정 결과를 해당 결과 내에 투명하게 공유해야 합니다. 그래야 다른 사람이 해당 내용을 바탕으로 더 나은 의사결정을 할 수 있을 뿐 아니라, 업무 중단 이후에도 이전의 시점으로 빠르게 재개할 수 있도록 도움을 줍니다.
챕터12: 대규모 시스템의 설계와 개선
코드 베이스의 특성과 코드 베이스를 대상으로 하는 활동들이 해당 특성을 어떻게 변경시키는지를 이야기합니다.
오류 경향성: 일반적으로 정적타입이 동적타입에 비해서 오류가 발생할 가능성이 낮다고 말합니다. 이처럼 특정 코드베이스가 어떤 언어, 프레임워크를 쓰느냐에 따라서 오류에 취약할 수 있으며, 이런 정도를 말합니다. 사실 이는 코드베이스 자체보다는 기술 스택에 따라 결정되는 것으로 보이기는 합니다.
일관성: 변수/메소드 이름들이 얼마나 일관성있게 선언 및 정의되어 있는지를 말합니다.
분산성: 한 메소드 내에 너무 많은 라인들이 있어 분산도가 낮을 경우 프로그래머의 인지 부하가 증가하게 됩니다.
숨겨진 의존성: 현대의 프로그래밍은 모두 이미 잘 만들어진 프레임워크에 기반합니다. 따라서, 의존성이 숨겨지게 되는데요, 뿐만 아니라 특정 라이브러리를 사용한다면 그 라이브러리를 사용한다는 것을 명확히 명시해놔야 하는데, 이러한 부분들이 작성되어 있지 않을 경우에는 숨겨진 의존성이 높은 상황이 되죠.
잠정성(provisionality)의 경우 “개발을 하는 동안 생각하는 것이 얼마나 쉬운지”를 말합니다. 가령 파이썬의 경우 변수 타입을 선언할 필요가 없기 때문에 비교적 가벼운 인지 부하의 상태로 개발을 진행할 수있죠. 코드를 빠르게 작성할 수 있고 이를 중간중간 확인하면서 진행할 수 있도록 하는가? 를 말합니다.
점도: 특정 시스템을 변경하는 것이 얼마나 어려운가? 에 대한 차원으로 잠정성과 유사한 부분이 있습니다.
점진적 평가(progressive evaluation): 주어진 시스템에서 부분적인 작업을 확인하거나 실행하는 것이 얼마나 쉬운지를 말합니다. 이 또한 잠정성과 관련이 있죠.
역할 표현력: 프로그램 내의 서로 다른 부분들과 역할을 어떻게 빠르게 파악할 수 있는지를 말합니다. 간단히 말하자면, syntax highlighting이여기에 포함되겠네요.
위에 열거한 관점들 외에도 여러 관점이 더 있고, 또 서로 동시에 달성하기 어려운 관점들도 있습니다. 어떤 관점은 특정 기술 스택에서는 어쩔수 없이 약화되기도 강화되기도 하고, 개발과정에서 각 코드베이스의 특성은 강화 약화되기도 하죠. 중요한 것은, 결국 모든 코드의 특성은 트레이드오프이며, 프로젝트의 특성에 따라 어떤 부분을 강화하는 방향으로 나아갈 것인지가 결정된다고 봅니다.
챕터13: 새로운 개발자 팀원의 적응 지원(온보딩)
새로운 개발자가 팀에 들어왔을 때 팀의 업무에 적응하기 위한 가이드를 제공합니다. 특별한 내용은 없었고, 그저 “전문가의 저주”로 말해지는 한번 기술을 익히고 나면 그 기술을 배우는 것이 얼마나 어려운 것이었는지를 잊어버리는 현상이 온보딩을 힘들게 한다는 것이 중요한 가르침이었던 것 같습니다. 사실 이 부분을 뺀 나머지는 특별하지 않았어요. 특히 기술업계일수록 신입을 일종의 테스트한다는 명목으로 상세히 알려주지 않고 스스로 개척하게 하는 면이 큰 것 같습니다. 돌이켜보면, 테크 업계뿐만 아니라 학교 수업에서도 늘 그랬던 것 같네요. 초보자에게 인지 과부하를 주지 않는 방식으로 강의가 진행되었어야 했는데, 사실 대학교의 강의는 늘 그런 식으로 진행되었던 것 같아요. 그래서 되짚어보면, 오히려 외부의 강의들인 패스트캠퍼스나 유튜브에서의 강의들이 더 온보딩을 가능하게 만들어주는 것 같습니다. 다른 이야기들이지만, 대학교라는 시스템이 정말 미래가 있는걸까요? 책 이야기와는 별로 관련있는 내용은 아니지만요.
마치며
개발에 대한 마음가짐, 내가 개발을 함에 있어서 긍정적 부정적 영향을 미치는 많은 요소들을 이해할 수 있는 좋은 책이었습니다. 특히, 개발 과정에서 어려움을 겪고 있다면 이제 “아 내 능력부족인가”가 아니라, 지금 내가 너무 많은 인지부하를 가지고 있는 것은 아닌지 확인할 수 있을 것 같아요. 그리고 책 마지막에는 관련하여 읽어보면 좋은 다음과 같은 책들이 추천되어있습니다.
댓글남기기