블로그 모아보기 - 인프런

컴퓨터 공학(CS)이 중요할까요?

저는 학부 시절에 전공수업을 들으면서 항상 답답한 마음이 있었어요.논리회로, 컴퓨터 구조, 자료구조, 알고리즘, 운영체제, 네트워크 등 컴퓨터 공학에서 꼭 배우는 과목을 들을 때마다 너무 막연한 기분이었죠.분명히 한 과목을 들을 땐 해당 내용에 대해서 자세히 배우지만 너무 이론적인 것만 배우는 느낌이 들었고,"왜 지금 당장 결과가 보이는 내용으로 공부하지 않을까?"라는 질문을 했었죠.🧐CPU가 어떤 구조이고 어떻게 동작하는지 이론적으로는 배우지만 정작 CPU가 어떻게 생겼는지는 아무도 알려주지도 않고 스스로 찾아본 적도 없었어요.CPU뿐만 아니라 RAM, 하드디스크 등 주변장치가 어떻게 생긴 줄도 몰랐죠.다른 과 친구들은 "너 컴퓨터 잘 아니까 부품도 잘 알고 조립도 잘하겠네?"라고 종종 물어보지만 그렇지 않았죠.네트워크 수업 때는 모뎀, 허브, 라우터 등 전부 이론적으로, 기껏해야 그림으로 된 예시로 보니까 현실 세계랑 매칭이 잘되지 않았어요.교수님들은 학교에서 배우는 전공이 중요하다고 말씀하실 때 항상 따라붙는 말이 있었어요.컴퓨터 공학은 매우 복잡하므로 Divide and Conquer(분할 정복)로 접근해 하나씩 자세히 알아보는 것이 중요하다, 하지만 이렇게 하나씩 배운 개념을 조합해 전체적으로 볼 줄도 알아야 한다.당시엔 전체적으로 볼 줄 알아야 한다는 말이 크게 와닿지 않았었는데요. 첫 직장에서 백엔드 개발자로 일하는 순간부터 느꼈어요.회사에서 사용하는 기술 스택들은 처음 접해보는 것들이었고 말로만 듣던 AWS도 직접 만져봐야 했죠.이때 많은 기술 스택과 AWS에서 사용하는 용어들은 굉장히 혼란스러웠죠.하지만 용어만 다를 뿐 전공에서 배운 개념들은 그대로였어요.제가 고생했던 것은 "실제로" 이것들이 어떻게 연결되어 동작하는지가 머리에 잘 정리되어 있지 않았던 것이었죠.회사에서도 공부할 시간을 줘서 얼마 되지 않아서 정리할 수 있었어요.그때 교수님들의 말씀이 다시 생각났어요."하나씩 배운 개념을 조합하는 게 이래서 중요하구나~"라고요.회사에 적응하고 개발할 때도 학과에서 배운 내용이 직/간접적으로 도움 된 적이 많아서 그때마다 교수님들을 떠올렸죠.한 번은 사용자의 특정 요청 중 일부가 아주 가끔 중복돼서 들어오는 경우가 있었어요.똑같은 환경에서 테스트해봐도 확인해볼 수도 없었고 하루에 하나가 있을까 말까 했죠.저희 팀에선 이 문제가 한 달 넘게 해결하지 못하고 있었던 상황이었어요.저도 이 문제가 왜 발생하는지 골치 아팠었죠.🧟그러던 어느 날 문득 원인이 예측됐어요. 운영체제에서 배웠던 개념에서 떠올릴 수 있었어요.그래서 예측한 원인을 해결할 방법을 찾아 코드를 수정했고 지켜봤어요!똑같은 문제는 다시는 발생하지 않았죠. 👏 이렇게 실무에서 컴퓨터 공학(CS)의 중요성을 알게 되어 기본기가 탄탄해야 한다는 말에 극공감하게 됐어요.하지만 CS를 배우는 건 어렵고 지루해서 금방 포기하게 되죠.그래서 저는 수업에서 들었던 궁금증, 그때 알았으면 좋았을 것들을 그림과 예시를 들어가며 직접 만들기로 했어요.현재 준비하고 있는 강의는 네트워크인데요.이론적인 내용뿐만 아니라 우리가 일상에서 볼 수 있는 기기가 네트워크에서 어떤 용어로 쓰이고 어떤 역할을 하는지,큰 그림을 맞춰볼 거예요. 만약 CPU의 동작 방식을 배웠다면 위의 그림처럼 CPU가 실제로 어떻게 생겼는지도 알아야 헷갈리지 않겠죠?네트워크는 하드웨어와 소프트웨어가 공존하기 때문에 이렇게 하드웨어까지 알아가며 퍼즐을 맞춰갈 겁니다.이만 다음 강의인 "그림으로 쉽게 배우는 네트워크"를 준비하러 가보겠습니다.😊

개발 · 프로그래밍 기타･CS･전공자･비전공자･컴퓨터공학･그림으로쉽게배우는･네트워크

28

8

컴퓨터 네트워크 강의를 준비중입니다.

안녕하세요 "그림으로 쉽게 배우는 컴퓨터공학" 커리큘럼을 만들고 있는 감자입니다!지금까지 제가 만들어 온 모든 강의에서는 여러분의 이해를 돕기 위해 그림을 이용해 설명해 드렸습니다.그런데, 지금 제가 준비하고 있는 강의는 네트워크 강의로 물리적인 장치의 이해까지 필요합니다.보통 전공 수업에선 이론적인 내용 위주로 설명하므로 여러분의 컴퓨터에서 데이터가 실제로 어떻게 이동하는지 직관적으로 알기는 어렵습니다.따라서 네트워크의 이론적인 내용과 물리적인 흐름을 모두 쉽게 이해할 수 있도록 강의 방식을 업그레이드 해보려 합니다.저로서도 새로운 도전이니 여러분들이 많이 응원해주시고 피드백 주시면 좋겠습니다. 😄(가정집 내에 있는 통신단자함 내부)저는 여러분이 인터넷을 사용할 때에 여러분의 집에 있는 통신단자함부터 건물의 통신실, 통신사, 서버까지로 데이터가 어떻게 이동하는지 시각화해 직관적으로 보여드리고 싶었습니다.하지만 기존의 강의 방식으로는 이러한 흐름을 보여드리기에 한계가 있었습니다.(사진과 그림만으로 이러한 것들을 설명하려니 만족스럽지 않았습니다)그래서 저는 여러분에게 직관적으로 전달할 수 있는 가장 좋은 방법이 뭘까 이리저리 고민하다가 3D 모델을 이용해 보기로 했습니다.(서울에는 내 빌딩이 없지만 3D세상에서는 구글빌딩이 내꺼🤗)3D 모델링을 하면서 굉장히 재밌게 준비했습니다.여러분들에게 가장 효율적으로 설명해 드릴 수 있다는 생각에 두근거리기도 해요!이제 준비한 내용으로 네트워크 강의를 열심히 만들어보겠습니다.많이 기대해주세요 😀 (시중에서 팔지 않는 제품도 3D 모델링이면 자세하게 소개할 수 있습니다)

개발 · 프로그래밍 기타･네트워크･3D모델링･그림으로쉽게배우는컴퓨터공학･CS･컴퓨터공학

8

5

왜 CS 전공지식은 ‘개발자 기본기’로 꼽힐까?

컴퓨터 구조, 자료구조, 알고리즘, 운영체제, 네트워크, 데이터베이스 등은 컴퓨터공학 및 컴퓨터과학, 소프트웨어공학 등의 전공에서 반드시 배우는 주제로 꼽힙니다. 학교나 학과마다 커리큘럼에 차이는 있더라도 내용 자체는 모두 동일한 개념을 배우게 되는데요.이러한 CS 전공 지식은 컴퓨터 관련 학과에서의 전공 이해를 좌우할 뿐만 아니라, 개발자 채용을 위한 기술 면접 과정에서 주로 검증하는 핵심 개념이기도 합니다. 가령 서비스 개발자라면 비즈니스 로직을 구축하는 등, 프로그램의 구조를 만들고 문제를 해결하는 바탕이 되기 때문입니다. 이미 실무에 진출한 개발자들조차도 CS 전공 지식을 강조하는 이유가 여기에 있죠.다시 말해 CS 전공 지식은 개발자로서 필요한 문제 해결 역량을 결정하는 기본기 역할을 합니다. 대학생, 취업 준비생, 주니어 개발자 등을 막론하고 실력 있는 프로그래머가 되기 위한 든든한 뿌리가 필요하다면 CS 전공 지식에 주목해야 합니다.•••기술 면접 전, 실무 프로젝트 전 빠르게 기초를 정리하고 싶으신가요?지금 인프런 프리즘 [CS 전공 지식 로드맵]을 통해 학습해보세요. https://www.inflearn.com/roadmaps/643•••인프런 프리즘 브랜드 스토리 읽어보기 >>

개발 · 프로그래밍 기타･CS전공지식･컴퓨터구조･알고리즘･자료구조･운영체제･네트워크･데이터베이스･컴퓨터공학･인프런프리즘･InflearnPrism

5

2

90년대 컴퓨터 공학 이야기 (21) — 데이터베이스와 SQL

SELECT 만 알면 된다고…기억 속의 컴퓨터 공학 이야기들 중 마지막 이야기이다. 데이터베이스 과목, 그의 선수과목 개념이었던 알고리즘에 대한 기억으로 1990년대 학교에서 배웠던 전공에 대한 기억들을 마무리해 본다.알고리즘학부 2학년 때 자료구조를 배운 이후 ‘제대로’ 프로그래밍을 하기 위한 과정으로 알고리즘을 배웠더랬다. 두께가 위압감을 주는 책이었고 기억 속에는 아래의 모빌이 있다. 여느 과목처럼 앞에는 열심히 했지만, Graph정도까지는 꽤 긴장하며 보았지만, Greedy 와 NP-hard/complete 나오면서부터는 그냥 어려워 했던 기억들이다.https://en.wikipedia.org/wiki/Introduction_to_Algorithms처음에는 그냥 ‘주어진 문제를 조금 효율적으로 풀어 보는 방법’으로 접근했었지만, 이후 대학원 생활에서도, 그 후 사회 생활을 하면서도 자꾸 뒤돌아 보곤 했었고, 여러 가지 이유로 많이 쓰임이 있던 과목이라 하겠다. 실제로 졸업 후 10년 지나서 Google 의 면접을 보려 했을 때 이 악물고 보기도 했던 책이기도 한데, 지금은 역시 조각난 기억들만 남아 있다.INSERT / SELECT / DELETE학부 마지막에 database 과목을 배웠었다. 역시 어떤 책을 들고는 있었지만 어떤 교과서라는 생각이 들지는 않는데, SQL만 한 학기 내내 했던 기억이다. 그 중 정확한 뉘앙스는 모르지만 가장 강렬한 기억은, 당시 대학원생 형이 실습 조교로 들어와서 ‘니네들 앞으로 살면서 다른 거 다 필요없고, SELECT 만 알면 된다.’ 라고 했던 것이었고, 25년 넘은 작년에도 여전히 쓰이고 있는 SQL 을 다루며 새삼 그 선배의 말이 기억이 났다.SQL 을 programming language 로 놓을 거냐 아니냐의 사소한 논쟁도 있었지만, 여전히 2023년 기준 가장 많이 쓰이는 언어 중 하나임에는 틀림 없다 하겠고, 이제 어떤 툴들을 쓰더라도 자동으로 아마도 지원이 되고 있을 거다. 백엔드를 만지면 그래도 골고루 들여다 볼 기회가 있겠지만, 당시 선배의 말대로 SELECT 만 알아도 되는 상황이 된 것도 맞는 거 같다. AI 시대에는 SQL 을 잘 쓰게 하기 위해 GPT 사용법(?) 등을 배워야 하게 되면 사람 — GPT — SQL — DB — 기계 의 미래가 와 있다 싶긴 하다.https://spectrum.ieee.org/the-top-programming-languages-2023is_deleted자료구조와 알고리즘 시간에 가장 시간을 많이 들이는 것이 delete 구현이었다. 상태가 안 깨지게 하고, 메모리 반납도 잘 하고 등등에 search 가 훨씬 자주 일어날 거니까 잘 유지해야 하고 등의 사연들이 많았더랬고, 시스템을 구현하려 할 때 가장 머리가 아픈 것들이었더랬다. 하지만, DB 수업에서 가장 할애를 많이 했던 부분은 어떻게 하면 복구를 가능하게 하느냐 였고, 사회에서 만난 서비스들도 실제 지워도 복구가 필요한 경우 어떻게 할 거냐 그렇다면 그 백업 데이터는 어떻게 하고 등등… 실제 데이터를 안 지우고 지운 척 하느냐로 많이 접근했었다.한편으로 꽤 허탈했던 기억인데, 많은 경우 is_deleted 필드를 추가하면서 기능들이 구현 가능했다. 나중에 알고 보니 Kernel 내에 page memory, NAND 플래시 내에서도 같은 concept 들이 이미 널리 쓰이고 있었더랬다. 도화지에 지우개로 하나씩 지우는 게 아니라 흰색 물감을 뿌려 버리는 느낌이랄까. 탈퇴한 유저가 새로 가입하면 이전 것을 재활용하냐 마냐 등의 이슈와 함께 몇몇 법안 관련해서는 정말 지웠느냐 등을 가지고 여러 레이어에서 이슈가 있을 것이고, 그래서 “지웠느냐?” 라는 질문에 오해들이 생겼더랬다.ps.개별 서비스를 만들 때는 티가 안 나지만, 이후 scale 이라는 걸 경험할 기회가 생겨서, read-only 로 freezing 이 되면 극강의 read-performance 들을 발휘할 수 있는 것들이 생겼고, 이는 도메인이 바뀌거나 generation이 바뀌어도 비슷한 고민들이 계속 반복되는 걸 보면, 다 피가 되고 살이 된다 뭐 이런 말이 맞는 거 같긴 하다. 앞 에피소드에서 이야기했던 tradeoff 와도 맞닿아 있는 모습이라 하겠다.

교양･90년대･컴퓨터공학

2

90년대 컴퓨터 공학 이야기 (12) — WCET (최악 실행 시간) 분석

세상 일 모른다…90년대 후반 대학원 꼬꼬마 석사 과정을 진행하면서 맡았던 주제는 WCET ( Worst Case Execution Time ) analysis 였다. Wikipedia ( https://en.wikipedia.org/wiki/Worst-case_execution_time ) 에는 2008년부터 보이는데, 내가 이 과제를 연구실 선배들로부터 전해 받으면서 공부했던 게 이미 1995년이었으니.. ( https://ieeexplore.ieee.org/document/392980 ) 그 사이의 시간대가 좀 비어 있긴 하겠다. 조금 어려운 이야기가 앞쪽에 하나에 세상 일 모른다는 일 두 가지 이벤트들..대략 기억을 더듬자면, RTOS 세상에 여러 개의 task 들이 각각 함수를 기준으로 수행이 될 때 ‘잘 예측된 값’을 실행하기 전에 알 수 있으면 효율적인 scheduling 이 가능하다.. 라는 것이었고, 컴퓨터 구조를 simulator , cache emulation 등을 이용해서 ‘프로그램’을 만들고, 이론적인 방법들로 풀어 나가는데, 벤치마크로 사용된 소스코드와 그것의 compile 된 코드를 입력으로 받아 worst case scenario 를 만들어서 예측해 내는 방식이다. 마지막 비교는 workstation 에 실측 장비를 물리적으로 붙여서 하는 비교까지.Safer , Tighter , with Reasonable Cost예측하는 방법론으로서 위의 3가지 덕목을 맞추어 나가야 하는데, 1차원 적으로 code path만 보고 판단하던 시기에서 instruction / data cache 를 emulation 하고, superscalar processor 같은 다양한 pipeline을 emulation 하면서 tight 하게 만들어 가는 게 선배들의 연구. 거기에 내가 보탠 것은 loop bound, loop 내의 condition 을 더 전해 주면 특정 benchmark 에서 조금 더 tight 해 진다는 주장(?).정확히 기억나지 않지만, insertion sort 의 경우 N² 로 over bound 되는 것을 줄여준다 정도여서 몇몇 특정 benchmark 에서 효용이 있더라 정도의 적당한(?) 결말인데, 이를 위해서 컴파일러를 여러 phase 뜯어 고치고, MIPS cross compiling 등의 노하우들을 쌓았던 기억들. 이후 연구실 교수님들과 선후배님들은 NAND flash 등으로 확장해 나간다.실제 controller 들에 MIPS 등이 내려오게 될 때 쓸모 있는 scheduling 일 수 있겠지만, 학교에서의 연구는 현실과 좀 거리가 먼 걸 하기도 했으니… 석사 과정에서 배움이 짧아 고생을 많이 했었지만, 저 목표들은 아직 기억이 좋게 남아 있고, 이후에도 자주 접하게 된다. 엔지니어링스럽지 않은가…세상 일 모른다 (1) — 에너지 도메인으로방법론의 핵심은 각 instruction 별로 일어나는 behavior 들을 각종 simulation / emulation 을 통해 binary code level analysis 를 하는 것이고, 마지막 결과물의 단위는 nano second, clock 수 등이었다. CPU 가 달라질 때마다 다른 것들을 구현해야 했기에 abstract machine layer 를 구현하고 여러 시스템을 펼쳐 놓고 비교하는 일들을 많이 했는데, 고전적인 기계에서의 오차 대비해서 복잡한 시스템의 새로운 instruction 들을 다루는 데 한계가 많았고, 새로운 CPU 는 cross compile 이 잘 안 되어 거기서 오는 난이도 등등…아마도 90년대 후반에 갑자기 CPU 의 발열, 에너지 소모 등이 화두로 뜨게 되었다. 에너지 소모는 원래 있던 이슈들이었겠지만, 모바일, 임베디드가 되면서 다시 화두에 미리 돌려 보기 전에 사전 검사의 의미로 이 앱을 실행시키면 밧데리가 얼마나 소모하는지를 미리 측정하고 계획을 잡는데, 거의 같은 개념을 적용하게 된다. 컴파일된 코드를 사용하는데 있어 명령어별 에너지 소모량을 고려해서 곱하기 대신 더하기로 풀어 쓰게 하는 기법들이나 조금 느리더라도 에너지 소모가 적으면 유용하게 받아 들여 지면서 다양한 컴파일러의 기법들이 재소환되는 세상이 벌어지게 된다. timing 대신 energy 로 놓아도 쉽게 적용이 되던 걸 보면 교수님들을 비롯한 대가들의 이해 방식에는 여전히 보고 배울 점들이 많다는 생각이다.세상 일 모른다 (2) — scaling이후 회사에 다니면서 학문의 영역과는 점점 멀어지게 되었지만, 당시가 또 폭발적인 정보의 양과 함께 패러다임의 전환의 시기를 맞으며, 또 많은 깨달음과 함께 부질없음을 겪게 된다. 위의 접근들은 겨우 5% , 10% 예측을 올려서 utilization 을 그만큼 올리자 뭐 이런 노력들이었다면, 주변의 환경들은 무지막지한 방식들로 변화해 왔다. 특히 메모리가 부족하면 하나 더 붙여서 쓰면 되고 등의 접근 같은 거라 뭐 이런 것들도 나름 scaling 이라 부를 수 있겠지만…얼마전 깨어지기 전까지 무어의 법칙은 계속해서 사용량을 늘려 왔고, 다양한 병렬처리들이 가능하게 되면서 , 이제 와서는 ‘누구나’ (비용만 감당할 수 있다면) 전 세계의 문서들을 가지고 학습 시킬 수 있게 되었고, 밧데리도 신소재 리튬이온은 이전의 것들 대비 순식간에 10배 이상의 용량까지 지원하게 되면서 몇 %씩 이삭 줍듯 모으던 노력들이 머쓱하게 되는 상황이 되어 버렸다. 변화의 한복판에 여전히 있어 신기하면서도 마냥 즐겁지 않은 건 사실이지만, 다른 의미로 세상 일 모르는 것이리라 싶다. 10년쯤 후에 다시 돌아보자..

교양･90년대･컴퓨터공학

2

90년대 컴퓨터 공학 이야기 (1) — 80년대 이야기 — 퍼스널 컴퓨터

90년대 컴퓨터공학과를 다니면서 모은 에피소드들이지만, 기억은 80년대의 몇몇 단어들에서 시작한다.퍼스널 컴퓨터 경진대회1985년 국민학교에서 방과후 학습으로 산수경시반을 뽑았는데, 당시 부산에서 인근 구청에서 있던 수학경시대회가 없어지는 바람에 컴퓨터반으로 변경되어 운영이 되었고, 퍼스널 컴퓨터라는 것을 접하고 경진대회라는 것도 접하게 되었다. 지금 있는 올림피아드의 원형일 것이고, 당시 운도 좋았어서 1986년에는 부산 대표로 서울 잠실이라는 곳을 처음 올라오는 경험도 하게 되었다. 마치 과거 시험을 보듯이 넓은 공간에 각자 컴퓨터를 들고 와서 4시간인가 시험을 치르는 자리였고, 여기를 오기 위해 구 대회, 부산 시 대회 등을 거쳐야 했었다.첫 출전 당시 버그로 인한 탈락의 아픔이 있었고, 이를 극복해 보고자 지역에서 여러 번의 시도를 하며 중학교 2학년까지 여러 가지 기량을 쌓음과 동시에 컴퓨터 게임과 더 친해지게 되었다. 전국 대회와의 인연은 더이상 닿지 않았지만, 마지막 대회에서 구 1위까지는 올라갔던, 나름 해피 엔딩.삼성 SPC 1000우리 집에서의 첫 삼성 제품은 이 컴퓨터였다. 학교에서 접하고 나서 서울 전국대회 출전권을 따고 나서 부모님을 졸라서 인연이 닿은 첫 컴퓨터. 테이프를 이용한 낯선 기계음, 그것이 끝나면서 시작되는 게임들, 흑백 화면에서 펼쳐지는 dot 의 아기자기함 등… 국민학교를 함께 했고, 각종 대회에 같이 다녔으며 아쉬움과 실패를 경험하게 했던 기억들.컴퓨터학습매달 용돈을 받거나 벌어야 했던 첫번째 이유. 가끔씩 자매품인 학생과 컴퓨터 도 있어서 매 달 둘 중 어느 것을 사야 하나 고민을 했던 경험도 있고, 더 고급진 책도 있었던 기억이지만, 적당히 재미난 내용들, 신기술, 거기에 게임도 섞여 있었음. 무엇보다 이 책이 가진 의미는 소스 코드들에 있었고, 이를 타이핑하면서 인내심을 알게 모르게 키워 왔던 게 나중에 값지게 쓰였던 것 같다.Apple II+중학교 때 경진대회를 위해 졸라서 하나 새걸로 장만했던 기억인데, 이 때 제품이 정확하게 뭐였는지는 기억이 없다. IIe 였던 거 같기도 하고… 툭툭거리는 키보드가 마음에 들었었고, 플로피 디스크의 신세계를 여기서 경험하게 되었다. 경진대회를 빙자했지만, 게임 중독으로 가기 일보 직전이었던 거 같다.Lode Runner, Ultima 4, Ultima 5, Ogre나의 중학교 생활을 함께 했던 동지들. Lord British , thou art , 그리고 각종 게임용 spell , ingredient , weapon , dragon , …— -이후 나는 수험생 모드로 입시에 전념하면서 90년대를 맞이한다.

90년대 컴퓨터 공학 이야기 (3) — Trade-off

입학 전의 공학?중학교 때는 남학생들은 “기술”이라는 과목이 있었고, 고등학교 때 선택과목으로 “공업”이라는 게 있었다. 다니던 고등학교는 공업 대신 “상업”을 가르쳤던 학교였기에 대학 입학 전의 공업에 대한 이미지는 스크류드라이버+못질과 납땜을 해서 만들어 보았던 AM라디오키트 정도이겠다. 레고는 기억이 없고, 지금보다 훨씬 덜 화려했던 과학상자를 만졌던 기억도 있겠고, 용돈이 생기면 아카데미 프라모델을 만들며 놀았던 어린 기억들이 있다.고등학교까지의 엔지니어링검갈빨주노초파보회백 저항값을 읽는 정도가 선행학습이었고, 하드웨어의 아주 기초를 접했다면 접한 거라 할 수도 있겠다. 컴퓨터 과를 들어왔지만, 공학이라는 게 뭔지에 대한 깊은 고민을 한 것도 아니었고, 단지 자연대보다 남녀 성비가 좀 더 치우쳐져 있는 곳이라는 정도, 그 와중에 컴퓨터공학은 10% 의 여학우들이 있어 신기해 했으며, 남중남고를 나온 나에게는 누나들이 생겼다는 것도 신선한 충격이었다.Trade-off어린 병아리 시절, 1학년에 전공 과목은 ‘컴퓨터 공학 개론’ 이라고 하면서 C 언어를 배우는 과목이라고 했다. 학교에 오면 컴퓨터를 만질 수 있었고, 터보C 같은 걸로 숙제를 해서 디스켓으로 제출하면 된다고 하셨다.지도교수님이신 학과 2회 졸업생이셨던 민상렬 교수님을 잊을 수 없고, 기억 속에 여러 부분의 지분이 있으신데, 첫번째 에피소드가 이 trade-off 라는 단어이다. 중간에 하이픈이 있는 게 맞는 건지 없는 게 맞는 건지도 모르겠지만… 엔지니어로 평생 필요하게 될 근본적인 개념의 단어를 몇 개 알려 주마… 라고 하시면서 알려 주신 첫번째 단어였다. 모범생은 아니었고, 수업 시간에 다른 내용들이 많아서 단어들을 많이 알려 주시진 않았지만, 이 첫 단어의 임팩트가 강하게 남아 있다.인터넷 사전이 없이 영한사전을 뒤져가며 익히던 시절의 나에게는 신조어였고, 이 세상에 공짜는 없다는 것, 공학이 과학과 다른 점에서 중요한 개념이라는 것, 수학과 비교가 앞으로 왜 계속 필요한 지 등을 알게 되었고, 아이러니하게 회사 생활 하면서 결정을 내리는 일들이 많아지게 되면서 계속 되뇌어지는 단어이다.이후 알고리즘 시간에 시간 공간 복잡도를 다루면서 열심히 쓰이고, 이후 논문이라는 것들을 읽게 되면서 세상을 이해하는 데 많은 쓰임이 있었고, 지금도 많은 깨우침이 여기서 나온다 하겠다. 지금의 나에게 누군가가 엔지니어링이란 무엇인가 라고 묻거나 혹은 단어 하나만 고르라면 이 단어를 주저없이 이야기할 것이다.작년에 비전공자들이 전공자들을 이해하고자 할 때 필요한 내용들을 가지고 온라인 강의를 만들어 보고자 하는 게 있어(https://fastcampus.co.kr/dev_online_newcomputer) 작은 역할을 맡았는데, 그 때 처음으로 맴돌았던 키워드가 이것이었고, 이것을 시작으로 코스를 구성할 수 있었다.

교양･90년대･컴퓨터공학

0