개발자라면 어떤 기초 지식을 습득해야 할까? 좋은 개발자가 되려면 어떤 사고 방식을 갖춰야 할까? 개발자를 꿈꾸는 당신을 위한 조언이 여기 있다. 한글과컴퓨터, 블리자드, 넥슨, 삼성전자, 그리고 유니콘 기업 몰로코의 박종천 개발자가 올해 30년을 맞아 발자취를 되돌아보며 개발자 지망생에게 작은 조언을 건냈다. 수많은 글과 멘토들이 말했을 법한 말들이지만, 알면서도 잊고 실천하기는 더 어려운 그 이야기를 들어보자 _편집자 주

개발자의 기본 소양

개발자 기본은 영어입니다. 그다음은 수학과 물리입니다. 코딩 교육이 붐이라 초등학생도 코딩을 배웁니다. 의문이 듭니다. ‘초등학생에게 코딩을?’ 터도 안 닦고 건물을 올리겠다는 말처럼 들립니다. 먼저 수학과 물리, 그중에서도 수학을 잘 알아야 합니다. 기본을 잘 만들고 나서야 프로그래밍 언어를 공부하고, 자료구조, 알고리즘, 운영체제, 하드웨어를 공부하면 됩니다.

알아야 하는 지식이 너무 많군요. 개발자는 평생 공부하는 직업입니다. 공부가 싫으면 다른 길을 고민하는 편이 시간 낭비를 줄이는 방법입니다. ‘나는 웹 개발자니까 하드웨어는 몰라도 돼’, ‘나는 운영체제는 몰라도 돼’ 이런 자세는 안 됩니다. 만든 프로그램을 쌩쌩 돌게 하려면 하드웨어를 알아야 합니다. 하드웨어 이론뿐만 아니라 예를 들어 안드로이드 앱을 개발한다면 제일 잘 팔리는 최신 삼성 갤럭시와 샤오미 홍미노트를 직접 만져보고 소프트웨어를 동작시키고 실생활에서 사용해보며 하드웨어 기능과 특징과 성능을 익혀야 합니다. 안드로이드 운영체제 버전별 기능(특징)도 알아야 하죠. 다방면으로 알아야 제대로 지식을 쌓을 수 있습니다.

다시 강조하지만 빠르게 세상이 변하므로 새로운 하드웨어, 새로운 운영 체제, 새로운 프로그래밍 언어를 빠르게 익힐 수 있는 능력을 갖추는 데 집중해야 합니다. 다음은 제가 주니어 개발자들에게 ‘개발에 대한 기본 지식이란 무엇인가’를 설명할 때 제시하는 목록입니다. 이 정도는 알아야 합니다.

현업은 기본 위에서 이뤄집니다. 예를 들어 자동차를 운전하려고 바퀴나 엔진을 직접 만들지는 않습니다. 핸들, 깜빡이, 엑셀, 브레이크, 차 크기, 바퀴 유무와 신호체계만 알면 운전할 수 있습니다. 개발도 마찬가지 입니다. 기본 지식을 잘 안다고 제로 베이스부터 모든 걸 직접 만들어 쓰는 게 아닙니다. 하지만 모든 소프트웨어는 기본 위에서 작동합니다. 기본을 알면 아키텍처가 달라집니다. 아키텍처는 소프트웨어 품질의 근본입니다. 정렬, 스택, 힙, 스레드, 네이티브 코드, 모델-뷰-컨트롤러 아키텍처(MVC) 등 표에서 언급된 내용을 공부해보세요. 이 정도는 알아야 소프트웨어 기본 지식을 갖췄다고 할 수 있습니다.

게임 개발자가 꿈이라면 기본 지식만으로 텍스트 기반의 게임을 만들어보세요. 예를 들어 화면에 글자 A가 왔다 갔다 하는 게임 말입니다. 유니티나 언리얼 같은 강력한 게임 엔진을 사용해 화려한 3D 그래픽 게임을 만들어보고 싶겠지만, 2D 텍스트 기반으로 게임을 만들어보세요. 그러면 기본 지식을 점검하고 활용할 수 있어 유용합니다.

일잘러가 되기 위한 크리티컬 싱킹

대개는 상사가 일을 시키면 ‘네 알겠습니다’하고 곧바로 일을 합니다. ‘크리티컬 싱킹’이라는 말이 있습니다. 우리말로는 ‘비판적 사고’ 정도로 번역할 수 있습니다. 크리티컬 싱킹은 주어진 일의 앞뒤를 생각하는 습관 입니다. ‘왜 이 일을 해야 될까?’, ‘이 일을 하다가 말면 어떻게 될까?’, ‘어떤 방식으로 일하는 게 최선일까?’ 문제의 상하좌우까지 고민하는 사고 방식을 습관으로 들이면 모든 일을 더 깊이 들여다볼 수 있습니다.

두 사람에게 같은 난도의 일을 주고 1년을 일하게 한다고 해봅시다. 둘 다 갓 대학을 졸업한 신입 직원이고 현재 역량이 같다고 합시다. 그러니까 둘 다 채용되었겠죠. 1년이 지나고 보면 둘의 역량은 같을까요? 차이가 난다면 ‘크리티컬 싱킹’이 그 차이를 만든다고 생각합니다. ‘삽을 들고 가서 열 번 땅을 파고 독을 묻은 다음에 돌아와라’하고 시켰을 때 그대로 하면 숙련도는 올라갑니다. 하지만 지식이나 경험은 잘 쌓이지 않습니다. 반면 ‘왜 10번만 파야 되지?’, ‘왜 삽으로 파야 하지?’, ‘곡괭이로 파면 안 되나?’, ‘꼭 파야 하나?’, ‘독을 왜 묻지’ 이런 질문을 하고 더 좋은 방법을 고민하면 어떻게 될까요? 관리자 입장에서는 전자가 편합니다. 시키는 대로 하니까요. 후자는 뭐 하나만 시키면 맨날 물어봅니다. 그래서 귀찮습니다. 그런데 1년이 지난 다음에도 전자한테는 여전히 설명을 길게 해줘야 합니다. ‘동쪽으로 열 걸음 가서 땅을 열 번 파고 독을 묻어라.’ 그런데 후자한테는 ‘김치를 잘 보관해봐’라고 하면 끝입니다. 땅을 파는 대신에 김치 냉장고를 구비해 보관할지도 모릅니다. 크리티컬 싱킹 습관이 들어 있으면 그 사람이 감당하는 업무 스케일이 계속 커지게 됩니다.

소프트웨어를 개발하면서 왜why, 어떻게how, 무엇what을, 누가who, 언제when까지 출시해야 하는지를 종합적으로 고려해야 합니다. ‘어떻게’에 매몰되면 좁은 영역에서 해결책을 얻을 수는 있지만 종합적인 관점에서 최고 혹은 최선의 해결책을 얻지 못합니다. 크리티컬 싱킹은 종합적인 관점에서 해법을 구하는 습관입니다. 같은 시간을 투자해도 상대적으로 더 큰 성장을 이끌어냅니다.

혹자는 ‘그거 주인의식의 다른 말 아닙니까? 회사의 주인도 아닌데 시킨 것만 잘하면 되지 주인의식을 가질 수 없어요’라고 말합니다. 네, 맞습니다. 회사에 대해 주인의식을 가질 필요는 없습니다. 대신 나에 대한 주인의식을 가져보세요. 이직을 하든, 창업을 하든 과거에 내가 한 일이 오늘의 나를 만듭니다. 화장품 하나도 성분을 보고 사는 시대입니다. 개발자를 채용하면서 어떤 프로젝트에 참여했는지가 아니라 어떤 기여를 했는지 확인하는 시대입니다. ‘그냥 시킨 것만 했어요’라고 대답하지 않으려면 나에 대한 주인의식, 즉 크리티컬 싱킹이 필요합니다. 그런 기여가 결국 나를 자연스럽게 성장시킨다는 거죠. 주인의식은 부차적인 겁니다. 주는 나의 성장인 거죠. 그래서 저는 말합니다. ‘프로젝트에서 최대한 오너가 되어라.’


출처 : https://goldenrabbit.co.kr/2022/01/05/%EA%B0%9C%EB%B0%9C%EC%9E%90%EB%A1%9C-%EA%B1%B0%EB%93%AD%EB%82%98%EA%B8%B0%E2%8B%AF-%EB%84%A4-%EA%B0%80%EC%A7%80-%EA%B8%B0%EB%B3%B8-%EC%86%8C%EC%96%91%EC%9D%84-%EA%B8%B0%EC%96%B5%ED%95%98%EC%84%B8/