Notice
Recent Posts
Recent Comments
Link
«   2024/12   »
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31
Archives
Today
Total
관리 메뉴

nomad-programmer

[etc/Stroy] 더 나은 개발자로 거듭나기... 4가지 소양 (개발자의 기본 소양) 본문

etc/Story

[etc/Stroy] 더 나은 개발자로 거듭나기... 4가지 소양 (개발자의 기본 소양)

scii 2023. 3. 8. 11:19

개발자라면 어떤 기초 지식을 습득해야 할까? 좋은 개발자가 되려면 어떤 사고방식을 갖춰야 할까?

개발자의 기본 소양

개발자 기본은 "영어"이다. 그 다음은 "수학"과 "물리"이다. 수학과 물리, 그 중에서도 "수학"을 잘 알아야 한다. 기본을 잘 만들고 나서야 프로그래밍 언어를 공부하고, 자료구조, 알고리즘, 운영체제, 하드웨어를 공부하면 된다.

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

다시 강조하지만 세상이 변하므로 새로운 하드웨어, 새로운 운영 체제, 새로운 프로그래밍 언어를 빠르게 익힐 수 있는 능력을 갖추는 데 집중해야 한다. 

개발에 대한 기본 지식이란 무엇인가?

분야 상세 지식
자료구조 스택, 힙
알고리즘 회귀 호출, 인덱스, 정렬, 이진 검색
운영체제 프로세스, 스레드, 뮤텍스, 세마포어
디자인 패턴 MVC 아키텍처
프로그래밍 언어 네이티브 코드, call-by-value, call-by-reference
경험 간단한 텍스트 기반 게임 만들어보기

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

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

일잘러가 되기 위한 크리티컬 씽킹 (Critical Thinking)

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

  • 크리티컬 씽킹
    • 이유 생각하기 -> 근거 평가하기 -> 문제 해결하기 -> 합리적인 결정하기 -> 상황 분석하기 -> 이유 생각하기 -> ...

두 사람에게 같은 난이도의 일을 주고 1년을 일하게 한다고 해보자. 둘 다 갓 졸업한 신입 직원이고 현재 역량이 같다고 하자. 1년이 지나고 보면 둘의 역량을 같을까? 차이가 난다면 '크리티컬 씽킹'이 그 차이를 만든다고 생각한다. '삽을 들고 가서 열 번 땅을 파고 독을 묻은 다음 돌아와라'하고 시켰을 때 그대로 하면 숙련도는 올라간다. 하지만 지식이나 경험은 쌓이지 않는다.

반면 '왜 10번만 파야 되지?', '왜 삽으로 파야 하지?', '곡괭이로 파면 안 되나?', '꼭 파야 하나?', '독을 왜 묻지' 이런 질문을 하고 더 좋은 방법을 고민하면 어떻게 될까? 관리자 입장에서는 전자가 편하다. 시키는 대로 하니까말이다. 후자는 뭐 하나만 시키면 맨날 물어본다. 그래서 귀찮다. 그런데 1년이 지난 다음에도 전자한테는 여전히 설명을 길게 해줘야 한다. '동쪽으로 열 걸음 가서 땅을 열 번 파고 독을 묻어라', 그런데 후자한테는 '김치를 잘 보관해봐'라고 하면 끝이다. 땅을 파는 대신 김치 냉장고를 구비해 보관할지도 모른다. 크리티컬 씽킹 습관이 들어 있으면 그 사람이 감당하는 업무 스케일이 계속 커지게 된다.

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

혹자는 '그거 주인의식의 다른 말 아냐? 회사의 주인도 아닌데 시킨 것만 잘하면 되지 주인의식을 가질 수 없어'라고 말한다. 맞다. 회사에 대해 주인의식을 가질 필요는 없다. 대신 나에 대한 주인의식을 가져보자. 이직을 하든, 창업을 하든 과거에 내가 한 일이 오늘의 나를 만든다. 화장품 하나도 성분을 보고 사는 시대이다. 개발자를 채용하면서 어떤 프로젝트에 참여했는지가 아니라 어떤 기역를 했는지 확인하는 시대이다. '그냥 시킨 것만 했다'라고 대답하지 않으려면 나에 대한 주인의식, 즉 크리티컬 씽킹이 필요하다.

그런 기여가 결국 나를 자연스럽게 성장시킨다는 것이다. 주인의식은 부차적인 것이다. 주는 나의 성장인 것이다. 그래서 이렇게 말하고 싶다. '프로젝트에서 최대한 오너가 되어라.'

도구를 사랑하지 마라

게임 하나에 분야별 다양한 개발자가 필요하다고 언급하였다. 사실 개발자는 그래픽도 볼 줄 알아야 되고, 데이터 베이스, 도구도 많이 알아야 한다. 소스 관리 도구라든지 비주얼 스튜디오, 유니티, 언리얼 같은 엔진도 알아야 한다. 무엇까지 알아야 할까? 프로젝트를 성공적으로 개발하는 데 필요한 모든 것이다. 당연히 사전에 모든 걸 알 수는 없다. 꾸준히 공부하는 수밖에 없다.

그렇기에 특정 언어나 도구와 사랑에 빠지면 안된다. 사랑에 빠지면 최적의 언어와 도구를 선택하지 못한다. 기술은 빨리 변한다. 프로젝트라는 과업 달성과 1~2년 후를 고려해서 선택해야 한다. '나는 정말 훌륭한 앵귤러JS 개발자야.' 5년 전에는 환영받았겠지만 지금은 리액트나 뷰가 대세이다. 앵귤러JS에만 머물러 있다면 새로운 직장을 찾기 어려 울 것이다. 도구도 마찬가지이다. 15년 전에는 비주얼 스튜디오와 이클립스가 양대 산맥이었다. 지금은 인텔리제이 같은 도구가 선택지를 넓혀준다. 현업에 바쁘더라도 6개월 주기로 새로운 기술과 도구를 확인하고 공부하는 기간을 갖길 바란다.

개발자의 도구는 역할과 프로젝트마다 달라져야 한다. 게임 클라이언트 개발자라면 유니티와 C# 혹은 언리얼과 C++를 알아야 한다. 서버 개발자라면 자바나 닷넷이나 파이썬을 알아야 한다. 도구는 어떤 자동화 프로세스를 채택하느냐에 따라 달라진다. 기술 흐름을 조망하고 큰 흐름을 계속 따라가야 한다.

지금까지 자바로 서버를 개발했다면 다음 프로젝트에 Rust 언어를 사용하는 것은 어떠한가? 스택오버플로우 2022년 개발자 리서치 결과에 따르면 Rust 언어는 배우고 싶은 언어로 올랐다. 오케스트레이션 시스템인 쿠버네티스, 컨테이너 시스템인 도커, 리뉴얼한 드롭박스에 사용되었다. 젯브레인즈에서도 비슷한 리서치 결과를 발표했다. TIOBEGitHub에서 발표하는 프로그래밍 언어 순위(흐름)를 참고해도 좋다. 여러 리서치 결과를 참고하면 더 객관적으로 흐름을 파악할 수 있다.

동향 파악도 크리티컬 씽킹과 연결된다. 다음 제품을 만드는 데도 쓸모가 있는지 생각하면서 기술을 체택해야 한다. 다음에도 유용한 기술이면 이직할 때 매력 포인트가 되어줄 것이다.

가정을 하나 해보자. 신기술을 적용하고 싶은데 상사가 옛 기술을 쓰라고 하면 어떻게 해야 할까? 크리티컬 씽킹이 습관화된 분이라면 설득의 묘미를 발휘할 것이다. "포트란으로 짜면 당장은 제가 개발할 수 있지만, 향후 제가 퇴사한 뒤에는 개발자를 구하지 못해 유지 보수가 어려울 겁니다. 한 달만 더 주면 Go 언어로 만들 수 있습니다." 만약 당신이 관리자라면 어떻게 할 것인가? 나 같으면 한 달을 더 주겠다. 이렇게 상사를 설득하면 본인에게도 이득이다. 이직 전선에서 포트란 개발 이력은 전혀 도움을 주지 못하는 반면, Go 언어 개발 이력은 도움을 줄 것이다.

새로 취업한 회사에서 사장되는 기술로 개발하라고 지시를 내리면 어떻게 해야 할까? 진지하게 빠른 탈출을 고려하든가, 다른 기술을 관철시켜야 하지 않을까? 전자는 본인을 위한, 후자는 본인과 회사 모두를 위한 선택지이다. 그저 시킨 대로 사장될 기술을 사용한다면 모두에게 불행을 가져다줄 것이다. 그렇다고 모든 개발에 신규 기술만 고집할 필요는 없다. 향후 5년 이상 유지할 서비스라면 최대한 미를 고려해 선택하고, 1년 미만 혹은 유지 보수 정도의 목적에는 기존 기술을 쓰면 된다.

왜 5년일까? 딱 5년일 필요는 없다. 어떤 분야에서 무슨 일을 하고 싶냐에 따라서 기준이 달라진다. 잠시 IT에서 5년이라는 시간을 생각해 볼까? 리액트, Vue.js, 파이토치, 쿠버네티스, GCP, 플러터, 코틀린, Go 언어. 5년 전에는 지금처럼 개발자에게 대중적으로 사용되는 기술이 아니었다. 아예 그 당시에 없던 기술도 있다. 하지만 지금은 각 분야에서 내로라하는 대표 주자가 되었다. 5년 전과 지금이 다르듯 지금과 5년 후도 다를 것이다. 내가 지속적인 공부를 반복해 강조하는 이유이다.

π자형 인재 되기

프론트엔드 개발자라고 해서 프론트엔드만 알면 안 된다. 백엔드를 조금이라도 개발할 줄 알아야 한다. 개발은 협업의 연속이다. 원활히 협업하려면 알아야 한다. 프론트엔드 개발자가 백엔드 개발자에게 안 되는 걸 무조건 해달라고 하면 어떻게 되겠는가? 분란만 나지 않겠나? 초당 10만까지만 받을 수 있는 시스템인데 '나는 당신 사정을 모르겠고 당장 천만 받아줘'라고 하면 안 된다. 풀스택 개발자까지는 안 되더라도 프론트엔드, 백엔드, 데이터베이스, 머신러닝, 클라우드, 안드로이드/iOS 전반에 대한 지식이 있어야 한다.

한 가지를 깊게 파서 잘하는 I자형 인재가 각광받던 시절이 있었다. 변화가 빠른 지금은 적어도 하나는 깊게, 나머지는 골고루 잘 아는 T자형 인재가 각광받고 있다. T자를 넘어 요즘에는 π(파이)자형 인재라는 말도 나왔다. 하나가 아니라 두 가지에서 전문성이 있어야 한다는 이야기이다. 프론트엔드 개발자만 π자형 인재가 되어야 한다는 게 아니다.

백엔드 개발자도 프론트엔드 개발을 할 줄 알아야 한다. 100세 코딩과 30년 커리어 패스 중 무엇을 로망하더라도 한 가지만 잘해서는 달성할 수 없다. 부전공을 선택하자. '프론트엔드 개발을 잘하지만 머신러닝도 깊게 익혀 두자', '임베디드 개발자지만 백엔드도 익혀두자' 이렇게 말이다. 시작은 I자형 인재이다. T자형을 거쳐 π자형 인재로 차근차근 나아가면 된다. π자형 인재가 되려면 눈물나게 노력해야 한다. 정말 힘들다.

공부는 할 때 해야 한다. 개발 초기 10년에 공부하는 것과 중간 10년에 공부하는 것은 속도가 다르다. '1년 안에 느는 영어가 당신의 모든 영어다.' 1년이 지나면 언어가 안 통해도 일이 된다. 그러고는 영어가 늘지 않게 된다. 그래서 처음 1년, 말이 안 통하는 가장 힘든 첫 1년 동안 집중해 영어를 공부해야 한다. 개발자 커리어 패스 30년 중에서 처음 10년, 모르는 게 가장 많은 시기에 최대한 많이 깊게 공부하자. 기본 지식이 선입견이 되고, 나이 먹게 되면 새로운 걸 받아들이는 속도가 느려진다. 그래서 개발 경력 초기에 공부하라고 재차 강조해본다.


아래의 링크 글에서 발췌...

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/

 

개발자로 거듭나기⋯ 네 가지 기본 소양을 기억하세요 - 골든래빗

개발자라면 어떤 기초 지식을 습득해야 할까? 좋은 개발자가 되려면 어떤 사고 방식을 갖춰야 할까? 개발자를 꿈꾸는 당신을 위한 조언이 여기 있다. 알면서도 잊기 고 실천하기는 더 어려운 그

goldenrabbit.co.kr

Comments