개발은 코딩이 아니었다
사람보다는 기술을 다루는 게 더 쉽다.
참 단순한 사고였다. 컴퓨터 개발자는 컴퓨터를 다루니까 사람을 다루는 일보다는 쉽겠다는 취준생의 어린 생각이었다. 하지만 회사에 들어와서 깨달은 점은, 그 분야가 어디가 되었든 관리자는 존재하고, 개발 세계에서 관리자란
결국 컴퓨터를 다루는 '사람'을 관리하는 사람
이라는 것이다. 솔루션은 개발자가 뚝딱뚝딱 뿅-해서 탄생되는 것이 아니라 하나의 상품이 시장에 나오기까지 수많은 사람들의 회의와 의견 조율, 합의를 거쳐서 나오기 때문에 개발자가 개발하는 부분은 단계가 7개가 있다면 중간에서 하나의 단계에 지나지 않는다. 우선, 어떤 상품을 만들어서 누구를 타겟팅하여 시장에 내놓을 것인가에 대한 분석을 진행한다. 분석이 끝나면 솔루션에 들어가는 모든 것을 제로베이스에서 만드는 것이 아니기 때문에 필요한 것은 외부에서 사들이고 개발이 필요한 부분은 SI 개발자가 만들어야 하지만 또 그 안에서도 외부 솔루션 툴을 이용해서 개발해야 하는 영역도 있기 때문에 외주 솔루션 업체로부터 회의와 배움의 시간을 지나 무엇인가를 만들게 된다. 개발의 시간이 오면 나에게 주어진 할당량을 이어폰 끼고 하루 종일 개발만 하다가 집에 가는 시간이 오게 된다. 아마 취준생 때 그렸던 개발자의 모습은 아마 이 단계의 개발자가 아닐까 싶다.
이 개발 과정이 끝나면 내가 그렸던 상상 속의 개발자의 모습이 끝난다. 그 이후로는 내가 만든 부분이 내가 아닌 다른 사람이 조작을 해도 작동하는지, 전체적인 관점에서 흘려보내면 제대로 돌아가는지 등등 테스트의 단계가 이어나간다. 그리고 만약 이 설루션을 맡는 다른 개발자(SM 개발자)가 있다면 그 사람에게 지식 공유도 해야 한다. 그 이후로는 클라이언트의 현재 사용 시스템(ASIS 시스템)과의 데이터 이행은 어디서부터 어디까지 할 것인지, 우리 시스템(TOBE 시스템)에 맞게 데이터를 이행하기 위해 ASIS와 TOBE 간 질의응답 시간을 거쳐 커스터마이징을 해야 한다. 그러고 나서는 어디에 서버를 설치하고 오픈은 언제 할 것인지 등등의 과정이 있다고 한다. 사실 이 이후의 부분은 우리 설루션이 해외에 오픈을 해보지 못하고 끝났기 때문에 정확하게 알진 못하고 회의시간에 귀동냥으로 들은 것이 전부다. 이 모든 과정을 관리하고 통솔하는 것이 PM, 또는 관리자다.
2년 간 이 일련의 과정을 겪으면서 깨달은 것은,
생각보다 개발자가 컴퓨터로 개발을 하는 영역이 적다
는 부분이다. 하지만 내가 생각했던 '개발'을 프로그래밍 언어로 소스 코드를 고치는 것이라고 상상했기에 2년 동안 나는 그 '개발'의 정의를 다시 해야 하는 시간을 겪었다. 내가 생각했던 부분은 흔히들 말하는 '코딩'이었던 것 같다. 하지만 내가 겪은 개발은 단순하게 '코딩'이라는 단어로 묶이지 않았기에 내가 생각하는 개발의 과정을 써 내려가 보고 싶다.
이 부분에 있어서 나는 팀장님께 굉장히 좋은 방식으로 작은 성취감부터 큰 성취감을 경험할 수 있는 기회가 많았다. 이 시절의 나는 Java, Spring, Querydsl, operating system, jpa, docker, linux, container, network 이런 식으로 단어가 나열되어 있을 때 카테고리가 어떻게 묶이는지 하나도 몰랐다. 지금에서야 operating system, network가 저 사이에 껴있으면 이상하고, linux/docker랑 결이 비슷하고 jpa, querydsl / java, spring이 결이 비슷하다는 것을 깨닫게 되었지만 그때까지만 해도 이것들이 대체 무엇인지, 보통 명사(컴퓨터 기본 구조에 포함되는 용어)인지 고유 명사인지 알 길이 없었다.
하루는 팀장님의 지시로 Docker를 개발 서버에 깔아야 했다. 나에게 주어진 것은 그냥 깡통 서버 하나였다. 전원만 들어오는 본체 하나, 그게 전부였다. 이 시간을 통해 나는 operating system이 무엇인지 알게 되었다. 본체에 os를 깔기 위해 usb를 만들어서 부팅을 하고 거기에 Cent OS7(Cent OS Linux)이라는 오픈소스 os를 깔아야 컴퓨터가 돌아갈 수 있다는 것을 알았다. 그렇게 os를 깔고 나니 까만 바탕이 나타났고 os를 깔 때 까만 바탕에 흰 글씨(CUI: Character User Interface)로 조작하기 싫으면 우리에게 익숙한 아이콘이 있는 방식(GUI: Graphic User Interface)을 깔아야 하는구나 처음 알게 되었던 것 같다. 그렇게 CUI 환경의 os를 깔고 나니 구글에 'cent os7 docker 설치' 이런 키워드들로 블로그를 따라서 docker를 설치했다. 내게 주어진 임무는 docker를 깔아라는 임무였으므로 정말 docker만 깔고 끝냈다. 하지만 이 일련의 과정을 거치면서 hello-world 이미지를 pull 받아서 컨테이너가 뜬 것을 보았을 때의 성취감은 엄청났다.
단순하게 내게 주어진 업은 '개발 서버에 Docker를 깔아라'였지만 내가 몰랐던 용어를 알게 되고 기본 개념도 익히면서 소소한 성취감이 들었던 것 같다. 비전공 출신의 개발자여서 남들은 알고 있던 지식이었을지언정 나에게는 뼈가 되고 살이 되는 지식이었기 때문에 기분이 좋았다. 물론 이 작은 업무는 시작에 지나지 않았다. 그 이후로 주어진 업무는 점점 더 많은 지식을 눈덩이처럼 굴릴 수 있게 해 주었고, 그 화룡점정은 우리가 서비스하는 모든 프로그램들을 이미지로 만든 다음에 서버로 띄우는 것이었다. 다섯 개의 spring boot 컨테이너, nginx 컨테이너, oracle db 컨테이너를 gitlab CI/CD를 이용해서 개발 서버의 Docker에 띄울 수 있게 만들어야 했다. 이 업무를 통해서 이전 업무의 연장 선상으로 docker network의 구조, volume mount, CI/CD의 개념, front-ent/back-end의 구분, spring boot configuration 등등을 배울 수 있었다. 특히나, xxx.yml 파일을 많이 사용하게 되었는데 들여 쓰기 열심히 한 이 파일 하나가 수십 가지의 기능을 하는 것을 보면서 컴퓨터의 세계란 참 무궁무진하구나란 생각이 들었다.
며칠 전에 갑자기 팀장님이 docker swarm으로 두 대의 물리 서버가 하나로 관리될 수 있는지 파악해 보라셨다. 말 그대로 '파악'을 하라고 하셨기 때문에 두 대의 물리 서버를 manager와 worker로 묶어서 gateway 서버가 두 개의 물리 서버에서 돌아가는 back-end 서버에 도달하는지만 확인해보았다. 하기 싫어서 3일 정도 외면하다가 집중해서 해보니 되길래 된다고 말씀드렸다. 어쩌면 이때 외면할 수 있었던 배짱도, 결국에 해냈던 것도 시간이 지나면서 쌓인 경험치 덕분 아니었을까.
그래서 나는 '개발'을 한 마디로 정의해보라고 하면 '그거 좀 어렵네요'라고 대답할 것 같다. Java 언어로 if-else를 타이핑하는 것, docker를 설치하는 것, os와 linux를 구분하는 것, 컨테이너 간 통신을 할 수 있도록 포트를 여는 것, 머릿속에 존재하는 아키텍처를 직접 테스팅하면서 가능성을 보는 것, 그리고 그 모든 지식을 쌓아서 하나의 솔루션을 탄생시키는 것, 이 모든 것이 개발의 영역이 아닐까 싶다.
사실 이 사고의 끝이 내가 유학을 가고 싶게 만든 이유이기도 하다. 왜냐면 이렇게 개발의 영역이 방대하다면 과연 나는 이 수많은 개발 영역에서 어떤 것에 전문성을 가질 것인가에 대한 고민이 깊어졌다. 지금이야 주니어 개발자니까 시키는 것 다 해보면서 성취감을 얻지만 10년 뒤의 나는 Null Pointer Exception을 두 시간 만에 잡았다고 좋아할 수는 없기 때문이다. 그래서 나는 10년 뒤에 무엇을 전문적으로 하지..?