Low level과 High level_개발자

요즘 문득 든 생각 중 하나다. 개발자에겐 로우레벨의 기술과 하이레벨의 기술 중 어느 것이 더 중요한가에 대한 생각. 이 이야기를하기 전에 먼저 보편적인 이야기를 하는 것이 좋아보인다. 저수준과 고수준의 기술이란 무엇인가 따져보자면, 소프트웨어 개발자에게 로우레벨이란 뭐 알고리즘, 하드웨어같은 것들이 있겠다. 하이레벨기술이 란 OOP, 디자인패턴이나 더 고수준으로가면 온갖 라이브러리들? 정도가 아닐까. 목수에겐 글쎄, 톱질하는법, 못질하는 법이 하이레벨이고 목재의 성질이나 가구를 사용하 는 인간의 신체구조? 이건 너무 갔나. 아무튼 이정도가 될 것 같다.

그럼 둘 중 뭐가 더 중요한가. 어떤 쪽에 더 무게를 두어야 하는가. 최근 나의 생각은 하이레벨에서 로우레벨로 넘어가는 중이다. 김포프님의 유투브영상에서 큰 영향을 받았다. 처음 나의 생각은 하이레벨이 더 중요하다는 것이었다. 고수준의 영역에서도 충분히 고민하고 연구해야할 것들이 많고 그것들이 사실은 실제 업무를 하는데에 있어 더 직접적인 것들이기 때문에 로우레벨에 얽매이는 것은 옳지 못한 생각이라 여겼다. 인터넷에서 관련 글을 보기도 했다. 개발자 기술면접에서 보통 알고리즘을 많이들 보 는데 이게 실제로 업무능력에 중요하기 때문이 아니라 짧은시간에 지원자를 테스트하기 좋은 도구이기 때문이고 이러한 문화가 미국에서 우리나라로 건너왔다는 내용의 글이 었다. 충분히 일리가 있는 내용이었고 한 동안은 이게 나의 생각이었다. 그런데 요즘 들어 몇몇 사람들을 만나고 이야기를 듣다보니 '기반'의 중요성에 대해 다시 한 번 생각하게되었다.

실제 프로그램이 돌아가는 로직을 알지 못하고 하드웨어의 프로세스를 알지 못하면 밑단에서 생겨나는 예상치 못한 문제들의 해결이 불가능해진다. 내가 짠 소스이지만 이 게 어떻게 돌아가는지 밑단의 밑단까지 이해하지 못하고 그저 'A버튼을 누르니 B가 튀어나왔다' 정도의 이해만 거치고 덕지덕지 사용하기 때문에 생겨나는 일들이다. 물론 이런 밑단의 문제들이 실제 개발을 하면서 얼마나일어나겠냐만은 이런 결정적인 순간의 장애를 해결할 수 있냐 없냐의 차이가 프로와 아마추어를 나누지 않을까.

버그의 문제뿐만 아니라 성능향상에 있어서도 로우레벨은 중요하다. 김포프님의 영상에선 언어통역을 예로들어 이야기 하셨다. 하이레벨만 아는 개발자의 경우 통역가를 가운데에 두고 실시간 대화를 하는 꼴이고 여기서 어쩔 수 없는 통역오류가 발생한다고 했다. 하드웨어의 성능향상은 더 이상 이전처럼 가파르지 않다. 무어의 법칙이 깨 지고 있는 것이다. 하지만 소프트웨어진영 쪽은 빅데이터, AI와 같은 새로운 고수준의 기술들이 등장하면서 요구되어지는 하드웨어 리소스의 성능이 높아지고만 있다. 결 국 소프트웨어 개발기술로 성능향상을 꾀해야 하는 것이다.

또한 하이레벨기술의 습득 면에서도 저수준은 중요하다. 실제 컴퓨터가 어떻게 생겨먹었고 어떤 프로세스로 돌아가는지, 프로그래밍이란 어떤 것인지 원론적인 것들을 이 해하고 있다면 그 위에 쌓아올려진 하이레벨의 기술들을 습득하는 일은 나의 머리속에 탄탄하게 자리잡힌 대들보에 쌓아 올리기만 하면 되는 것이다. 무너질 일이 없다. 쌓아올리는 일도 더 빠르다. 주먹구구식으로 그 때 그 때필요한 표면적인 지식들만 익혀나가다보면 언젠간 탄탄하지 못한 기초지식에 의해 무너지기 마련이다.

'내가 사용하는 도구'에 관한 이야기도 영상에서 봤다. 어떤 분야던지간에 전문가는 자신이 사용하는 도구에 관해서는 빠삭하게 알고 있어야 한다는 것이다. 레이싱선수 는 운전만 잘하지 않는다. 실제 차량이 어떤 구조로 되어있고 어떤 원리로 돌아가는지, 엔진이어떤 식으로 이루어져 있어서 이런 동작이 발생하는지에 대한 이해도 하고있 다. 스마트폰 카메라가 아무리 성능이 좋아지고 있다곤하나 아이폰 카메라로 셔터만 눌러가며 찍는 사람에게 프로사진가라는 호칭을 붙이지는 않는다. 아이폰 카메라를 쓰 는게 아마추어스럽다는 이야기가 아니다. 초점은 어떤 식으로 맞춰야 하며 빛은 어떻게 다루어야 하고 날씨에 따라 환경에 따라 사진이 어떻게 달라지는지 원론적인 부분 을 이해하고 있어야 진짜 프로 사진작가다. 헌데 SW개발진영에서 요즘들어 로우레벨의 이해는 우리의 영역이아니다라는 주장이 생겨나고있다. 하드웨어의 이해가 이제는 중 요하지 않다는 말로도 해석할 수 있는데, 개발자가 '사용하는 도구'는컴퓨터다. 셔터만 눌러대는 사진작가와 다를바가 없다.

그럼 이런 주장이 왜 생겨났을까. 이건 완전히 나의 주관적인, 문득 든 생각이다. 첫 째로는 뭐 깊이있게 노력하고싶지않은 개발자들의 변명이 어쩌다보니 공론화되어 힘이 실린게 아닐까하는 생각이다. 둘 째로는 '해커와 화가'라는 책이 생각났다. 개발자들에겐 굉장히 유명한 저서이고 내용도 매우 좋다. 개발에 관련된 여러가지 이야 기들을 실은 책인데, 내용 중 하나가 개발자란 무엇인가라는 것이다. 제목에서도 알 수 있듯이 작가는 개발자란 화가와 같다는 이야기를 한다. 프로그램 개발이란 결국 이 세상에 없는 무언가를 만들어내는 일이고 이 것은화가와 다를 바가 없다는 것이다. 그래서 책에서는 우리는 '새로운 것을 창조해내는 일을 하는 중이다'라는것을 잊지 말아야 한다는 이야기를 하고있다. 복잡한 로직을 만들어내고 기계처럼 동작을 지어내고 하다보니 프로그래밍의 본질에대해 망각하는 경우가 종종 생기는데 개발의 본질은 '창조'다. 맞는 이야기다. 개발자라면 새로운 것을 만드는 일에 흥미가 있어야 한다. 헌데 나는 여기서 조금의 오해가 생겨난게 아닌가 싶다. 이 책의 어디에도 로우레 벨이 중요하지 않다는 이야기는 나와있지 않다. 다만 우리가 하는 일의 본질적인 목적의식을 갖자는 것이다.

책에선 이런 이야기가 나온다. 화가가 되고 싶은 사람이 가장 처음 하는 일이 바로 붓을 드는 일이다. 물감의 화학적인 성질이 어떻고 캠퍼스에 붓칠을 하면 어떤 반응 을 일으키고 색이란 것은 어떤 원리로 우리의 눈에 보여지고 하는 것들을 먼저 공부하지 않는다. 화가가 되기 위해선 우선 붓을 들고 캠퍼스에 칠하는 연습을 하면 된다. 프로그래머도 마찬가지다. 프로그래밍을 하고싶다면, 세상에없는 어떤 새로운 프로그램을 창조하고 싶다면 일단 그 프로그램을 만드는 것만 생각하면 된다. 복잡할 것 없 다. 하지만 그렇게 되면말이 앞뒤가 조금 맞지 않는다. 로우레벨이 중요하다고 하면서 일단 눈에 보이는 프로그램부터 만들고 보라니.

나는 이렇게 생각하고 있다. 그러니까 프로그래머로 가는 길의 '정도'란 바로 이것이다. 나는 세상에 없는 어떤 새로운 프로그램을 만들고 싶어한다. 그래서 알아봤더니 프로그램을 만들기 위해선 프로그래밍을 배워야 한단다. 내가 만들고 싶은 것은 A버튼을 누르면B가 튀어나오는 프로그램이다. 프로그래밍을 좀 배워서 버튼을 만들고 동작 을 연결하는 법을 배웠다. 그럼 일단 버튼을 만든다. 동작을 연결시킨다. 다 만들었다. 이게 끝이다 사실. 여기서 로우레벨은 필요치 않다. 근데 이 다음이 중요하다. 시간이 좀 지나니 또 만들고 싶은 프로그램이 생겼다. 뭐 이것도 필요한 프로그래밍기술을 좀 익혀서 하면 되겠거니 해서 끄적끄적댔다. 다 만들고나서 봤더니내가 원하는 만큼의 퍼포먼스가 나오질 않는다. 몇 날 몇 일 고생해가며 알아봤더니 내가 하는 주먹구구 방식으로는 제대로된 구현이어렵단다. 이 주먹구구의 실제 밑단 원리를 이해하 고 그 부분을 손대야 한단다. 그럼 여기서 로우레벨을 익히면 되는 것이다. 결국, '필요성'에 의해 움직이자는 이야기다.

모로 가도 서울로만 가면 된다고, 로우레벨을 먼저 익히고 쌓아 나가든, 하이레벨을 익히다가 필요한 로우레벨을 익히든, 결국 개발만 잘 하면 된다. 하지만 필요성에 의한 움직임은 언제나 효율이 좋다. 왜 하는지 피부로 느끼지도 못하는데 일단 중요하다니까 하드웨어 공부하고, 알고리즘 공부하고 하는 것은 나의 기준에선 별로 옳지 못한 길이라 생각이 든다(알고리즘을 연구하는 것 자체에 흥미를 느끼는게 아니고 프로그램 개발이 하고 싶은 것이라면)

잠자기 전에 떠오른 생각을 의식의 흐름대로 적다보니 굉장히 두서없는 글이 되었는데, 아무튼 그렇다. 기반은 언제나 중요하다. 하지만 기반을 닦는 일도 결국 사람이 스스로 하는 것이다. 실제로 필요성을 느끼지도 못하면서, 왜 이렇게 노력하고 있는지도 모르면서 어떻게 최선을 다 할 수 있을까.