ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 컴퓨터 공학에 접근하는 방법
    소프트웨어 엔지니어링 2019. 3. 11. 11:05

    학부 시절에 학교에서 연 세미나에 참석 한 적이 있다. 이 세미나에선 실리콘밸리에서 일하는 한국인 엔지니어들이 와서 자신의 경험과 취업 경로에 대해 이야기 해 주었다. 강연자 중 한 분이 AAFMG (Apple, Amazon, Facebook, Microsoft, Google)중 하나에 재직중이셨고, 그 때문에 나도 세미나 시작 전 부터 기대하고 있었다. 하지만 그 분의 강연 후 나는 많이 좌절하고 말았다. 그 분은 어려서부터 알고리즘 대회에 나가 수상한 경력이 있었고, 국내 최고 대학 중 하나에 진학하셨으며 대학원 진학 후 어떤 컨퍼런스에서 AAFMG에게 면접 제의를 받아 입사 한 경우였다. 전부 나와는 동떨어진 이야기였다. 그 분은 알고리즘을 정말 잘하셨기 때문에 AAFMG 면접을 통과하는 것은 당연 해 보였다. 반면 나는 대학에 입학해서 처음으로 프로그래밍 언어를 배웠다. 게다가 자료구조, 알고리즘 강의에서는 연습 문제의 답을 외워서 풀어서 딱 성적만 받았다. 당시 세미나가 열렸을 때 나는 고학년이었는데 그 때도 알고리즘은 너무나 무서운 벽이었고 사실 지금도 그렇다. 그래서 세미나 후 기분이 좋지 않았다. 그리고 그 세미나가 있은 후 하나 결심 했다. 만약 내가 잘 돼서 혹시 AAFMG중 하나에 들어가게 된다면, 나 처럼 아무런 컴퓨터 백그라운드 지식이 없이 처음 컴퓨터 공학을 배우는 사람들을 위해 글을 쓰겠다는 것이었다. 그래서 이 포스트를 통해서, 내 결심을 실천 해 보려한다.


    주의! 이 포스트는 주관적인 견해가 많이 담겨있으며, 개인의 경험을 바탕으로 작성되었다. 이 포스트는 절대적인 가이드라인이 아니다. 그냥 저 사람은 저런 과정을 거쳤구나 정도로 가볍게 읽어주길 바란다.

    컴퓨터 공학에 접근하는 방법

    예상 독자

    컴퓨터 공학을 공부를 시작하는 사람들.

    목차

    • 컴퓨터 공학 커리큘럼 (기본 교양 제외)
      • 프로그래밍 언어
      • 자료구조, 알고리즘
      • 운영체제, 컴파일러, 컴퓨터 회로, 네트워크, 데이터베이스
      • 소프트웨어 공학, 소프트웨어 설계(디자인)
      • Modern Software - 분산 시스템, 클라우드 시스템, 임베디드 시스템, 보안, 인공지능, 웹. 등등
    • 컴퓨터 공학 공부가 힘든 이유
      • 추상화 (Abstraction)
      • 자료구조와 알고리즘
      • 시스템 이해
    • 컴퓨터 공학 접근 방법

    컴퓨터 공학 커리큘럼 (기본 교양 제외)

     대부분의 컴퓨터 공학 커리큘럼은 다음과 같다. 대학교 커리큘럼이든 혼자 배우는 사람이든 대부분 아래와 같은 커리큘럼으로 학습을 하게 될 것이다.

    • 1년차: 프로그래밍 언어: 가장 기초적인 컴퓨터의 빌딩 블록(Building Block)을 배운다.
    • 2년차: 자료구조, 알고리즘 : 프로그래밍 언어로 문제를 효율적으로 해결하는 방법을 배운다. 자료구조와 알고리즘은 프로그램의 기본적인 빌딩 블록이 된다.
    • 2~3년차: 운영체제, 컴파일러, 컴퓨터 구조/회로, 네트워크, 데이터베이스 : 자료구조와 알고리즘을 이용해 더 큰 프로그램(=시스템)이 어떻게 만들어지는지 배운다. 이 과정에서 조금씩 프로그래밍 언어의 역할, 자료구조의 역할, 알고리즘의 중요성등이 이해되기 시작한다. 또 이들을 이용해 만든 시스템들이 어떻게 동작하는지 배운다. 하지만 여전히 운영체제, 컴퓨터 구조/회로, 네트워크 등등은 무슨소리인지 알 수 없다.
    • 3~4년차: 소프트웨어 공학, 소프트웨어 설계(디자인) : 규모가 큰 프로그램을 만드는 방법을 배운다. 규모가 크기 때문에 어떻게 설계하느냐가 쟁점이 된다.
    • 4년차: 분산 시스템, 클라우드 시스템, 임베디드 시스템, 보안, 웹. 등등 : 위에서 배운 모든 것을 활용해 만들어진 다양한 시스템들에 대해 배운다. 하지만 이전에 배운 개념이 제대로 없다면 모든것이 애매모호한 시기이다. 이 시기에는 "난 정말 아는게 하나도 없군.. 대학원에 가야하나?"하고 고민하는 시기이기도 하다. 

    프로그래밍 언어

    보통 컴퓨터 공학 공부는 프로그래밍 언어를 배우는 것으로 시작한다. 그것이 C이든 Java이든 크게 상관없다. 이 과정에서는 어플리케이션을 만들기 위한 기초 빌딩 블록(Building Block)을 배우고 그 블록(변수, 조건문, 반복문)을 이용해 무언가를 만들어 보는 것이 중요하다.  이 단계에 있는 학습자들은 컴퓨터가 뭔지 모를 확률이 높다. 그냥 "아 이렇게 하니 돌아가네", 또는 "이걸 쓰면 이렇게 출력이된다", 정도까지만 이해가 가능하다. 어떤 책에서 로컬 변수는 레지스터 또는 메인 메모리에 할당된다고하고, 다른 책에서는 malloc/new 등을 하면 메인 메모리에 할당된다고 100번 나와봤자, 그 의미가 무엇인지 이해되지 않을 수 있다. 괜찮다. 그건 당연한 일이다. 이 시기에는 그냥 무언가를 만드는데 초점을 맞추면 마음에 부담이 덜 된다.

    자료구조, 알고리즘

     프로그래밍을 어느정도 할 줄 알게 되었다면 자료구조와 알고리즘을 배운다. 이 때의 목표는 본인에게 익숙한 프로그래밍 언어를 이용해 다음과 같은 실습을 해 보는 것이다. 이때 자료구조를 선행해야 알고리즘을 공부하는 것을 추천한다. 왜냐하면 보통 알고리즘은 특정 자료구조를 이용해 구현하는 경우가 많기 때문이다. 따라서 어떤 자료구조의 장단점과 목적을 알지 못한다면 알고리즘 구현이 더 어렵게 느껴질 수 있다.

    1. 자료구조를 구현한다.

    2. 본인의 프로그래밍 언어가 제공하는 자료구조 라이브러리를 이용해 알고리즘을 구현 해 본다.

    구체적으로 자료구조와 알고리즘을 어떻게 공부하면 좋을지는 다른 포스트에서 다루도록 하겠다. 대체적으로 1) 자료구조와 알고리즘을 구현 할 줄안다. 2) 자료구조와 알고리즘을 사용 할 줄 안다. 3) 자료구조와 알고리즘의 성능 및 장단점을 분석 할 줄 안다. 이렇게 세가지를 중점적으로 공부하게 된다. 여기까지를 소프트웨어 엔지니어링 기본(Software Engineer Fundamental)이라고 부른다. 기본이라함은 다른건 몰라도 얘네는 꼭 알아야 한다는 것이다. 언어 + 자료구조 + 알고리즘이 현대 어플리케이션의 기본 빌딩 블록이다.

    운영체제, 컴파일러, 컴퓨터 회로, 네트워크, 데이터베이스

     이 단계에서는 프로그래밍언어 + 자료구조 + 알고리즘을 이용해 만들어진 더 큰 프로그램/시스템에 대해 배운다. 이 단계에서는 자원(cpu, memory, disk..등등)을 어떻게 효율적으로 나누어 사용 할 것인지(운영체제) 또는 데이터를 어떻게 전달 할 것인지(네트워크), 언어를 어떻게 다른 언어(주로 기계어)로 바꿀 것인지(컴파일러), 데이터를 어떻게 저장 할 것인지(데이터베이스)등에 대해 배운다. 즉 여기서부터는 기본 빌딩 블록을 이용해 어떤 문제를 어떻게 효율적으로 해결하느냐가 공부의 중점이 된다. 우리가 직접 해결하는건 아니고, 대부분 엄청 두꺼운 전공 서적을 읽으며 과거에 컴퓨터 공학자들이 어떤 문제를 어떻게 해결했느냐를 이론적으로 배운다.

    소프트웨어 공학, 소프트웨어 설계(디자인)

     이 단계에서는 사람들과 어떻게 협업 할 것인가(소프트웨어 공학), 큰 프로그램을 만들기 위해 어떻게 설계를 할 것인가에 대해 배운다. 소프트웨어 공학은 프로젝트 매니지먼트적인 성향이 있어 '코딩이 아니니 별로 중요하지 않다'라고 생각하는 경향이 있는데 아주 중요하다. 소프트웨어 라이프사이클이나, 프로젝트의 스케쥴, 요구사항, 구현, 테스팅등을 계획하는 방법에 대해 배운다. 

    소프트웨어 설계에서는 그래서 어떻게 하면 나중에 코딩을 덜 할 수 있게 설계를 할 것인가?에 대해 배운다. 프로그램은 그냥 만들어 놓고 끝나는게 아니다. 계속 유지 보수해야하고, 때로는 기능을 더 붙여이거나 떼어야하고, 다른 프로그램과 연결해야 하는 등 한번 만든 후에도 해야 할 일이 계속 생긴다. 이 때 미래에 최대한 일을 덜 하기 위해서(..) 현재 어떻게 프로그램을 설계/구현 해야 하는지에 대해 배운다. 

    이 부분에서 협업을 위한 도구와 디자인 기법(git, 디자인패턴, UML, 소프트웨어 아키텍쳐 등등)에 대한 이야기를 한다.

    Modern Software - 분산 시스템, 클라우드 시스템, 임베디드 시스템, 보안, 인공지능, 웹. 등등

     이 단계에서는 보통 오늘 날(modern) 사용하는 소프트웨어/시스템에 대해 배운다. 많은 양의 데이터를 어떻게 처리 할 것인지(분산 시스템), 자원을 어떻게 더 효율적으로 사용 할 것인지(클라우드/임베디드 시스템), 데이터를 어떻게 지킬 것인지(보안), 웹 어플리케이션을 어떻게 만들 것인지 등등에 대해 배운다. 

     그러나 여기까지 다 배웠어도 여전히 모르는게 많은 느낌이 든다. 나는 그랬다. 클라우드 컴퓨팅이 어쩌고 PaaS가 어쩌고 SaaS가 어쩌고 하는데 정말 구름같은 느낌이 들었다. 실제로 겪어보기 전까지는. 아마도 많은 컴퓨터 공학도들이 나처럼 이론과 실제 사이의 갭 때문에 고민 하고 있을 지 모른다.


    컴퓨터 공학 공부가 힘든 이유 

    추상화 (Abstraction)

     컴퓨터 공학 공부가 힘든 이유는 우리가 아래에서 위로 배우는 것이 아니라 위에서 아래로 배우기 때문이다. 무슨 뜻일까? 컴퓨터는 무엇으로 이루어져있나? 전자회로로 이루어져 있다. 그러면 컴퓨터를 진정으로 이해하기 위해서는 전자 회로를 먼저 배워야 한다. 전자 회로를 배워 CPU는 어떻게 돌아가고, 메모리는 어떻게 만들어져있고, 얘네 둘이 어떻게 정보를 교환하고, 레지스터는 무엇인지 배우고 나서, 이진수로 프로그래밍을 약간 해 보고, "아 이진수 프로그래밍이 이렇게 힘들구나~"하고 느낀 후 이 점을 개선할 방법을 찾아본다. 그 개선점이란 이진수가 아닌 언어로 프로그래밍을 작성하는 것일 텐데, 이 때 우리는 컴파일러의 중요성과 작동 방법에 대해 고민 할 것이다. 우리가 직접 고급언어를 어떻게 만들것인가, 컴파일러를 어떻게 만들것인가에 대해 고민했으므로 우리는 사용하는 언어가 정확히 무엇을 하는지 이해하게 될 것이다. 

    또 회로를 각 그룹당 하나씩 주고 공유하게 만들어서 서로 먼저 프로그램을 돌리겠다고 싸우게 만든 후, 이를 자동화 해 줄 운영체제의 필요성과 목표에 대해 배운다. 그리고 운영 체제에 대해 배우면 이해가 더 쉬울 것이다. 또 컴파일러/운영체제를 디자인 하면서 데이터를 어떻게 사용해야 하는지 알고리즘은 뭘 써야하는지 고민하면서 자연스럽게 자료구조와 알고리즘의 중요성에 대해 이해 할 것이다. 그리고 오늘 날의 프로그램은 운영 체제에 의존하기 때문에 운영 체제를 이해하는 우리는 본인의 프로그램이 어떻게 돌아갈 것인지 정확히 알고 있을 것이다.

    아쉽게도 대부분의 커리큘럼은 거꾸로 되어있다. 시간상의 제약 때문일 수도 있고, 컴퓨터공학도인 우리가 전부 알 필요가 없어서 일지도 모른다. 아무튼 우리는 일단 프로그래밍 언어를 배우며 시작한다. 우리는 이 프로그램이 컴퓨터에서 어떻게 돌아가는지 모르기 때문에, 프로그래밍을 하면서도 찝찝한 기분을 가지고 있을 것이다. 메모리가 어쩌고 CPU가 어쩌고 하는데 가시적인게 없으니 그냥 그런가보다 싶다. 이런 '사용은 하고 있는데 어떻게 작동하는지는 모르겠는 것'을 컴퓨터에서는 추상화(Abstraction)라고 부른다. 우리가 바보라 그런게 아니라 애초에 이해하지 못해도 써먹을 수 있도록 설계되었다는 뜻이다. 컴퓨터 공학에서는 추상화에 대한 개념이 계속 나온다. 내 코드가 CPU에서 어떻게 동작하는지 모른다. 그래서 답답하다. 우리와 같은 초보자들은 내가 정말 몰라서 모르는 것인지 원래 몰라도 되도록 설계된건지 구분하기가 힘들다. 이러한 특성이 컴퓨터 공학을 공부하기 힘들게 만든다.

    자료구조와 알고리즘

    이는 자료구조와 알고리즘을 배우면서도 계속된다. 그래도 여기까진 괜찮을 것이다. 자료구조와 알고리즘은 코딩을 해서 이해 할 수 있기 때문에 적어도 "이게 무슨 소리지?"하는 의문은 좀 덜 들 것이다. 그치만 자료구조/알고리즘은 프로그래밍을 고작 1년정도 한 사람 한테는 여전히 어려운 과목이라서 중간에 계속 "아 컴퓨터는 내 길이 아닌가보다", "이거 가지고 정말 먹고 살 수 있을까", "다른 애들은 잘 하는 것 같은데(특히 어려서부터 알고리즘 한 사람들..) 나만 헤매나", 이런 생각이 계속 든다. 적어도 나는 그랬다. 심지어 자료구조의 리스트에서 나온 화살표가 포인터(레퍼런스)라는 것을 학기가 끝나갈 때 쯤 눈치챘다. 그렇게 어영부영 연습문제를 외워 성적만 간신히 딴 후 배운건 하나도 없이 지나가버렸다. 그리고 이후에 면접준비를 할 때마다 다시 공부해야 했다.

    시스템 이해

    진짜 난관은 운영체제, 컴파일러, 컴퓨터 회로, 네트워크..이 녀석들을 공부 할 때 찾아온다. 우리는 한번도 운영체제, 컴파일러, 컴퓨터 회로, 네트워크가 없는 컴퓨터를 만나 본 적이 없기 때문에 얘네가 왜 필요한지, 얘네들의 설계가 왜 중요한지 마음에 와 닿지 않는다. 그리고 대부분의 커리큘럼이 위의 과목들을 한 학기~ 두학기에 걸쳐서 같이 배운다. 그래서 살인적인 학기를 마치고 난 우리의 상태는 아래와 같다.

    배우긴 배웠는데 이 중에 제대로 아는건 하나도 없고 이렇게 지식들이 나눠진 상태로 머릿속을 돌아다니는 상태 일 것이다. 그리고 또 다시 고뇌의 순간이 찾아온다. 이걸 다 배우긴 했는데 면접에서 혹시라도 해당 과목에 대한 질문을 받는다면 제대로 대답 할 자신은 없다. 더 이해하려면 어떻게 해야 하는가? 대학원에 가야할까? 다시 공부 해야 할까? 인터넷 강의를 들어야 할까?

    모든 컴퓨터의 요소들은 어떤 문제를 해결하기 위해 고안되었다. 하지만 우리는 '문제'에 대해 깊게 고민 할 기회가 별로 없다. 이런 문제가 있었고 이렇게 해결했다라고 책에 나오면, "아 그래? 그랬구나. 근데 어쩌라고?"이런 반응이 나온다. 그런 문제를 겪어 본 적이 없기 때문에. 이런 갭을 어떻게 채워나가야 할까?

    컴퓨터 공학 접근 방법 

    지금부터 말하는 접근 방법은 경험을 통해 깨달은 것이다. 사람마다 어려운 부분이 다를 수 있고 어떤 사람은 전혀 공감하지 못 할 수도 있다. 이 섹션에서는 내가 컴퓨터 공부를 하면서 겪었던 어려운 부분과, 미리 알았다면 좋았을 법한 것들에 대해 이야기 해 보겠다.

    모르는 것에 대해 조바심 내지 말라

    지금 여러분이 이해하는 시스템이 물음표로 가득찬 위의 그림과 같아도 괜찮다. 오늘날의 컴퓨터는 수백 수천명의 공학자들이 수백 수천개의 문제를 해결하기 위해 수 년동안 고민하고 협업하여 만들어진 결과물이다. 한 사람이 몇 년동안 공부해서 전부 이해하는데는 당연히 한계가 있다. 나도 이 포스트를 쓰며 나처럼 모르는게 많은 사람이 포스트를 쓸 자격이 되는가에 대해 고민한다. 또 지금 내가 포스트를 쓰는 이 순간에도 내가 모르는 다른 시스템들이 우후죽순처럼 생겨나고 있을 것이다. 하지만 중요한 것은 어떤 툴을, 어떤 시스템을 몇개나 알고 있느냐가 아니다. 중요한 것은 우리가 그 시스템을 이해 할 수 있는 역량이 있느냐이다. 배우는 단계에서 kubernetes니 docker니, git이니 이런 산업에서 사용하는 툴/시스템에 너무 연연하지 않아도 된다. 중요한건 저런 시스템을 이해 할 수 있느냐 없느냐이다. 계속해서 공부하다 보면 모든 퍼즐이 들어맞는 순간이 온다. 대신 계속해서 열심히 공부해야한다. 계속해서 회로와 운영체제는 어떤 관계인지, 회로와 컴파일러는 어떤 관계인지, 운영체제와 컴파일러는 무슨 관계인지, 각각의 컴포넌트 사이에 대해 계속해서 고민해야만 퍼즐이 들어맞는 순간이 온다. 그 순간이 오면 (예를들어) System.out.println/prinf/print가 어떻게 동작하는지 이해 할 수 있게 된다.

    에러에 익숙해져라

    개발환경설정에서 나는 에러, 코딩하다가 나는 에러, 런타임 에러. 에러는 계속 날것이다. 여러분이 소프트웨어 엔지니어로 살게 된다면 거의 매일 에러를 보게 될 것이다. 에러의 수준이 다를 뿐이지 에러가 난다는 것은 변함 없다. 에러를 해결하는 과정 자체가 공부이다. 그러니 에러가 나는 것에 익숙해지고, 그 에러를 해결하는 능력(Troubleshooting)을 키워야 한다. 

    자료구조, 알고리즘에는 끈기가 필요하다

    [자료구조/알고리즘 연습]

    처음 알고리즘을 시작하는 사람들의 경우 "쉬운 알고리즘도 짜지 못하는 나는 이 쪽에 재능이 없나보다"라고 생각하기 쉽다. 하지만 이제 겨우 언어를 하나 정도 배운 사람이 알고리즘을 짜는건 당연히 힘든 일이다. 처음 알고리즘 문제풀이를 시작하면 입력과 출력조차 이해하기 힘들다. 그래서 결국 답을 보게되고 이 문제를 이해하지 못한 자신을 책망한다. 그렇게 하면서 답 코드를 익히고 다음에 잘 풀면 되는데 그러다 포기하는 사람들이 많다는 것이다. 나도 포기 할 뻔한 몇번의 고비를 넘긴 후 여기까지 왔다. 그리고 깨달았다. 답을 봐도 괜찮다. 답을 보고 이해 하면된다. 답을 보고 이해했다면 다음에 비슷한 문제가 나왔을 때 풀 수 있을 것이다. 답을 봐도 이해를 못했다면 못푼다. 그렇게 하다보면 코딩 실력도 늘고 결국 알고리즘 실력도 늘게 된다. 3개월 이상 꾸준히 한 문제씩 풀어봐라. 그러고도 처음 알고리즘 시작 했을 때와 실력이 같다면 그 때 진로 변경에 대해 고민해도 늦지 않을 것이다. 내가 알고리즘을 어떤사람보다 더 잘/빨리 푸는 이유는 전에 비슷한 다른 문제들을 많이 풀어봐서이지 내가 알고리즘적인 사고가 다른 사람들보다 특출나서가 아니다. 어떤 사람들은 정말 알고리즘적 사고가 발달되어 있어 특별한 노력 없이도 알고리즘 문제를 척척 해결 할 수 있을지 모른다. 아쉽게도 나한테 해당되는 얘기는 아니었고, 그 부분은 내가 (또는 나와 비슷한 처지의 사람들이) 계속해서 개발해야 할 끝나지 않는 숙제이기도 하다.

    Seeing is Understanding

    [리눅스의 task_struct 코드 - 보통 운영체제에서 말하는 프로세스의 코드부분]

    여러분이 배우는 컴퓨터와 관련된 모든 것들은 하드웨어와 소프트웨어로 구성되어 있다. (프로젝트 매니지먼트 제외) 소프트웨어는 코드로 작성되어 있다. 운영체제도, 컴파일러도, 네트워크도, 전부 하드웨어가 아닌 일정 부분은 코드로 작성되어 있다. 제발 코드 부분을 봐라. 코드를 전부 보고 해석하라는 뜻이 아니다. 내가 이론으로 배우는 것들이 결국 큰 분량의 '코드'에 불과하다는 사실을 깨달으라는 것이다. 이 사실을 깨닫지 못하면 큰 시스템을 만나게 될 때마다 뜬 구름 잡는 느낌만 계속 받을 것이다. 여러분이 지금 보고있는 브라우저도 누군가 작성한 코드이다. 여러분의 윈도우즈도 누군가 작성한 코드이다. 이 사실을 이미 알고있다면 다행이고 아니라면 빨리 깨닫길 바란다. 나는 내가 짠 반복문 구구단이 내가 사용하는 프로그램과는 전혀 상관없는 무언가라고 생각했다. 나는 리눅스의 코드를 까서 task구조체를 보기 전 까지 내가 사용하는 리눅스와 책에 나오는 운영체제는 다른것이라고 생각했다. 이론과 실습의 갭을 채우기 위해서는 스스로 코드를 까 보아야 한다. 예를들어 네트워킹을 보자. TCP/IP니 패킷이니 윈도우니 하는것들이 나온다. 얘네들 다 어디에 있는가? 네트워크 인터럽트 핸들러 및 디바이스 드라이버 코드에 작성되어 있다. 학교에서는 시간상의 제약 때문에 이론만 /가르치는 경우가 있다. 아쉽게도 이런 이론과 실습의 갭을 스스로 채워가는 수 밖에 없다.

    모든것은 계약(contract)이다

    컴퓨터의 모든것은 어떤 계약(contract)로 이루어져있다. 예를들어 여러분이 어떤 함수를 짜면 그 함수는 a와 b라는 매개변수를 받아 x라는 기능을 한다. 이게 바로 계약이다. 이 함수를 사용하는 다른 프로그램은 항상 a, b라는 매개변수를 넘겨야한다. 그러면 그 두 변수로 어떤 기능을 수행한다. 이렇게 컴퓨터의 세계에서는 어떤 기능과 이 기능을 사용하는 녀석 사이에 계약이 존재한다. 이것을 네트워크에서는 프로토콜(Protocol)이라고 부르고, 프로그래밍 언어에서는 함수, 또는 라이브러리/API라고 부른다. 이런 계약/약속의 개념을 이해하면 컴퓨터 공학을 이해하기 더 쉬워진다.

    코딩 != 소프트웨어 엔지니어링

    코딩은 소프트웨어 엔지니어링의 기본이다. 즉 코딩을 어느정도 할 줄알아야 소프트웨어 엔지니어가 될 수 있다는 뜻이다. 하지만 코딩이 소프트웨어 엔지니어링의 전부는 아니다. 여러분이 무슨 알고리즘 대회에 나가서 몇개의 상을 휩쓴 것은 여러분이 알고리즘을 잘 푼다는 뜻이지 소프트웨어 엔지니어링을 잘 한다는 뜻은 아닐 수 있다. 소프트웨어 엔지니어링은 그보다 더 복잡한 것이다. 코딩, 시스템 이해, 시스템 디자인, 협업, 오퍼레이션, 프로젝트 관리등 소프트웨어 엔지니어링에는 다양한 면들이 존재한다. 코딩과 더불어 이런 다양한 부분들이 소프트웨어 엔지니어로서의 역량으로 간주된다.

    [퍼즐이 맞춰지는 순간..]

    컴퓨터 공학을 공부하는데 더 좋은 팁과 가이드라인이 인터넷에 많이 존재한다. 이 포스트에서 말한 것들은 대부분 나의 경험에 기반한 것이므로 누군가는 공감하지 못 할지도 모른다. 사람마다 이해력이 다르고 페이스가 다르기 때문이 이 과정이 절대적일 수 없다는 점을 강조하고 싶다. 동시에 컴퓨터 공학은 알고리즘적 사고가 가능한 소수를 위한 학문이라는 통념도 깨고 싶다. 나도 엄청난 경험이 있는게 아니라 뭐라고 단정짓기는 힘들다. 물론 흥미의 여부로 인한 개인차는 있을거라 생각한다. 현재는 컴퓨터 공학에 재능이 있으면 좋겠지만 그렇지 않아도 충분히 알고리즘적 사고를 개발 할 수 있다고 생각하는 쪽이다. 분명한 것은 컴퓨터 공학을 공부하는 과정이 쉽지만은 않다는 점이다. 이를 인지하되 조바심내지 않고 차근차근 공부하다 보면 본인이 원하는 목표에 더 가까워지지 않을까 하고 조심스럽게 생각 해 본다.


    댓글

f.software engineer @ All Right Reserved