개발자란 어떤 직업일까?
명품 가방을 만드든 일 vs 앱 만드는 일
명품 가방을 만드는 일
학교를 다닐 때 텔레비전에서 이태리 명품 가방을 만드는 곳에서 일하는 사람들에 관한 프로그램을 보고 정말 저런 직업을 갖는다는 것이 얼마나 멋진 일일까? 하면서 넋을 놓고 본 적이 있다. 하나의 가방을 만드는데 엄청난 노력과 만드는 이의 자부심이 느껴졌다. 한 가방을 완성시키기까지 꼼꼼하게 손으로 바느질도 하고 가죽을 제단 하기도 하는 것이 요즘의 눈에는 현실성이 없어 보이기도 하지만 그것을 완성하는 사람에게는 뜻 이 있고 혼이 담긴 물건이리라.
그 프로그램을 보고 한 때 나도 그런 멋진 공인이 되면 얼마나 좋을까 하고 생각한 적이 있었다.
도대체 그런 일을 하는 사람들은 어떤 사람들일까?
무슨 실력이 있어야 하고 기술이 있어야 하는 것일까?
자격증이라도 있는 것일까?
무슨 공부를 해야 저런 일을 할 수 있을까?
이들은 예술가인가? 아니면 그저 도안이 시키는 데로 따라 하는 사람들일까?
도안을 보고 그냥 하는 일이라면 나도 할 수 있지 않을까?
개발자는 무엇을 하는 사람들일까?
Web Developer 또는 Software Engineer
도대체 앱개발자(또는 엔지니어)는 무엇을 하나? 이런 질문을 자주 받는데 여기에 뭐라고 대답을 해야 할지 막막할 때가 많다. 누가 내가 하는 일을 물으면 "의사가 쓰는 앱을 만드는 일"라고 짧게 대답하기가 일쑤다. 내가 하는 일은 어떤 일인가?
데이터베이스 구축 - 어떤 앱이든 "데이터베이스"가 있다. 가령 브런치를 예로 들자면, 여기에 있는 글, 글을 쓰는 사람들, 글을 읽는 사용자들, 사용자들의 정보 - 이메일, 패스워드 등등, 여러 가지 정보를 체계적으로 모으고 저장과 관리하는 곳이 필요하다. 이런 곳을 데이터베이스라고 하고 나는 이를 구축하는 일을 한다. 데이터가 적으면 상관없지만 데이터베이스가 크게 늘어남에 따라 어떻게 구축하느냐가 중요해진다. 효율적으로 안전하게 데이터를 저장하고 빼서 쓰는 방법을 항상 고민해야 한다.
데어터 관리 - 구축해 놓은 데이터베이스를 관리한다. 데이터베이스는 항상 바뀐다. 내가 새 글을 쓰면 데이터가 늘어나고, 글을 지우면 소멸된다. 또 사용자 숫자가 늘어나기도 하고, 사용자가 본인의 프로파일을 바꾸면 업데이트를 하기도 해야 한다.
API 구축/관리 - API 즉 Application Programming Interface(다른 말로 "응용 프로그램 프로그래밍 인터페이스")라고 하는데 이것은 한마디로 서로 다른 시스템 또는 앱끼리 대화를 하는 "방식/방법"이다. 예를 들면 내가 지금 이 글을 쓸 때는 데스크톱(노트북)으로 쓰고 있지만, 가끔 핸드폰에 있는 앱으로 글을 불러오기도 한다. 이때 모두 매인 "서버"에 이 글을 보내달라고 요청을 해야 한다. 이때 내 핸드폰/컴퓨터 즉 "클라이언트"가 글을 달라는 요청을 "메인 서버" 즉 데이터베이스가 있는 서버에 한다. 그럼 서버가 응답을 하고 글(데이터)을 보내준다. 바로 이러한 대화의 요청/응답점을 API라고 하고 이를 구축/관리하는 일을 말한다.
https://madooei.github.io/cs421_sp20_homepage/client-server-app/앱의 퍼포먼스 최적화 - 가끔 앱을 쓰다 보면 한참을 기다려야 페이지가 뜰 때가 있다. 무엇이 잘 못 되었든, 아님 데이터베이스가 커서 그렇든 서버에 한 요청이 잘못되거나 늦게 응답이 와서 그렇다. 이럴 땐 어떻게 하면 빠른 응답을 보낼 수 있을까를 고민해야 한다. 또 요청이 잘못되었으면 그에 알맞게 응답을 하거나 아님 왜 요청이 잘못되었는지 파악하고 고쳐야 한다.
보안 - 회사에서 세워놓은 보안/안전 규칙에 따라서 소비자의 데이터를 보호하고 API가 보안 프로세스를 따르도록 해야 한다.
이메일 만들기 - 흔히 우리가 수많은 이메일을 받고 아무렇지 않게 생각하지만 이런 이메일 하나도 개발자의 손이 필요하다. 물론 작고 간단한 이메일들은 그렇지 않지만 복잡하고 특히 여러 가지 이미지와 링크가 걸려있는 이메일들은 개발자가 하나하나 조립해서 만든 것일 확률이 크다.
상품개발 참여 - 우리가 새로운 상품이나 기능을 만들 때 엔지니어로써 참여해야 한다. 예를 들면 브런치에 새로운 기능을 추가하려고 할 때 엔지니어로써 이런 기능은 가능하다/가능하지 않다를 조언하고 가능하면 얼마나 시간이 걸릴지, 어떤 인력이 필요한지 등을 알려야 한다.
앱 테스팅 - 사용자들이 어떤 것을 좋아할지 앱을 만드는 사람들은 잘 모른다. 그래서 테스트를 한다. 이런 작업을 AB testing이라고 한다. 하나의 이메일, 웹사이트 버튼, 색, 크기, 위치 - 이 모든 앱에 들어가는 컴포넌트를 다 테스팅한다고 해도 과언이 아니다. 어떻게 하면 사용자가 좋아할까? 어떤 문구가 좀 더 쉽게 사용자에게 다가갈까? 어떤 색상이 버튼을 좀 더 뚜렷하게 보이게 할까? - 이런 것들을 항상 실험하고 이용자들의 욕구에 맞춰서 변경하는 것이다.
디버깅(debugging) - 앱을 다 만들면 끝이 아니다. 고장 나면 고쳐야 하고, 느리면 빠르게 만들어야 한다. 이것을 디버깅이라고 하고 내 일상의 상당수가 디버깅을 하는데 쓰인다.
새로운 상품을 만드는 과정
새로운 상품 또는 feature(제품이나 서비스에서 하나의 단위를 뜻하는 단어. 예로 핵심이 되는 기능을 key feature라고 한다)를 만들 때 개발자가 참여하는 과정은 다음과 같다. 처음 상품 제안에서부터 상품이 사용자들에게 선보이게 될 때까지 생각보다 많은 절차를 거치고 개발자들의 참여도 크다.
엔지니어 입장에서 본 새로운 상품을 만드는 과정보통 사람들이 개발자가 하는 일이 제품 또는 feature를 만들기만 한다고 생각하지만 엔지니어는 거의 모든 Product Life Cycle에 참여한다.
어떻게 하는 일이지?
사실 개발자로서 가장 좋은 점이기도 하고 때로는 힘든 점은 항상 공부를 해야 하는 것이다. 거의 모든 일이 새롭거나 내가 아는 것을 바탕으로 해야 하는 새로운 일이기 때문이다. 그래서 경력자들이 일을 빨리 잘하는 것이다. 아무리 새로운 일이라고 해도 경력자들은 자신의 경험이나 아는 것을 바탕으로 빠르게 새로운 일을 적응하고 해결할 수 있기 때문이다. 아무리 똑똑한 신입이더라도 많은 경력 없이는 새로운 일을 파악하는데 시간이 걸리고 앞으로 나올만한 문제점(프로그램의 버그 bug 등)을 잘 예측할 수 없다. 이런 것은 일하면서 배우는 경우가 대부분이다.
개발자의 일이 항상 새로운 것을 배우고 조금씩이라도 기존의 앱을 발전(속도를 빠르게 한다던지, 복잡한 것을 쉽게 만든다던지)시켜야 하기 때문에 우리는 많은 시간을 배우는 일에 할애한다. 책으로 공부하거나, 컨프런스를 갈 수도 있고 구글이나 Youtube 또는 직장 동료나 선배에게 물을 수 도 있다. 다른 사람이 쓴 코드를 평가하는 것을 Code Review라고 하고 이 것이 내 일의 30% 정도가 된다. 리뷰를 하면서 나도 모르는 것을 배울 때가 많다. 내가 쓴 코드가 아니라 다른 사람들이 쓴 코드라도 내가 봐주고 서로 협력해서 쓴 것이기 때문에 문제가 일어나면 우리 모두가 책임을 진다. 그래서 협동력이나 서로 간의 믿음이 중요하다.
개발자로 좋은 점은 사무실에서 꼭 앉아서 일을 할 필요가 없다는 것이다. 실리콘밸리의 거의 모든 엔지니어일이 재택근무로 바뀐 것도 이런 이유이다. 물론 많은 큰 회사들이 다시 직원들을 불러들이고 있기는 하지만 지금 거의 모든 대다수의 엔지니어들은 100% 재택근무를 하고 있거나 사무실은 일주일에 한 번 정도 나가는 정도이다. 실리콘밸리의 재택근무에 대해서는 다음에 자세히 소개하겠다.
앱 개발자이 가방 만드는 일 같다고?
컴포넌트를 짜 맞추는 일
개발자의 일이 가방을 만드는 일이랑 같다고 하면 놀랄 분들이 많을 것 같다. 특히 매일 컴퓨터 앞에서 알고리즘이나 수학 같은 것을 할 것 같은데 하고 고개를 갸우뚱하실 분들이 많으실 것 같다.
물론 알고리즘이나 복잡한 프로그램을 짜는 것은 개발자 업무의 한 부분이다. 그러나 특히 앱 개발자의 일 같은 경우는 여러 가지 컴포넌트를 크기에 맞게, 쓰임세에 맞게 재단하거나 끼워 맞추는 일이 많다. 이런 이유로 앞서서 내가 하는 일이 비슷하지만 조금씩 다른 일들이라고 말한 것이다. 많은 부분이 어느 순간에 와서는 비슷한 일이 된다. 가령 작은 토트백을 만들다가 조금 큰 숄더백을 만드는 것 같다고나 할까?
비슷하고 같은 원리지만 다른 특징을 가지고 있는 상품을 만들어야 하는 경우가 대 부분이다. 많은 사람들이 내가 컴퓨터 앞에서 코딩만 하는 줄 알지만 실제로 내 일상에는 팀원과의 회의도 많고 지난 프로젝트를 뒤 돌아보는 일명 Retrospective 같은 회의도 많다. 서로가 지난 프로젝트를 뒤 돌아보고 잘 한점, 못 한점 등을 생각해 보는 자리이다. 그래야 다음 프로젝트에서 같은 실수를 하지 않는다. 물론 회사마다 또 팀마다 회의의 진행방향이나 회의를 하는 정도 도 다르지만 거의 모든 개발자가 communication이 중요하다는 데는 동의할 것이다.
Tools(기구 들)를 사용하는 일
가방을 만드는 기술자들이 사용하는 가위, 칼, 재단 자처럼 우리도 사용하는 툴(Tools)들이 있다. 이런 기구들을 얼마나 능숙하게 잘 사용하느냐에 따라 좋은 개발자와 능숙하지 않은 개발자로 나누어질 수 있다. 경력이 많은 개발자들은 이러한 기구들을 능숙하게 사용할 뿐만 아니라 새로운 기구를 사용하는데도 두려움이 별로 없다. 새로운 기구들은 보통 기존의 기구들을 바탕으로 새로운 기능들이 덧 붙여진 것들이 많기 때문이다. 그런 기구들을 얼마나 잘 사용하느냐가 개발자 능력의 큰 차이가 된다. 그래서 우리는 이런 Tools 사용법을 배우는데 상당한 시간을 쓴다.
개발자의 Tool Box - 출처 https://www.code-brew.com/이러한 이유로 몇 년 전부터 내가 하는 일이 명품 가방을 만드는 일과 비슷하다는 생각을 하게 되었다. 하나의 프로젝트가 끝나게 되면 맛보는 성취감이나 과정에서 알게 된 새로운 지식과 기술들은 나를 계속해서 뿌듯하게 하고 겸손하게 하기도 한다. 자신감과 겸손함이 없이는 절대로 좋은 프로젝트를 이끌 수가 없다. 그리고 다른 사람들을 배려하는 마음이나 본인이 알고 있는 지식을 나누어주려는 노력이 없이는 이 분야에서 인정받기 힘들다.
특히 이 분야가 언론에서 젊고 뭐든지 빠르게 해 나가는 "천재"들 만이 살아남을 수 있고 성공할 수 있는 것처럼 포장하지만 실제로 실리콘밸리에서 일하다 보면, 정말 실력 있고 인정받는 엔지니어들은 다들 열심히 노력하고 남들과 잘 일하는 사람인 경우가 대 다수이다. 우리가 컴퓨터로 일하고 다른 "언어"나 알고리즘을 이용해서 데이터를 사용하지만 이 분야야말로 사람들과 함께 문제를 해결해 나가고 협동해야만 프로젝트를 완성할 수 있다.
개발자라는 직업은 competitiveness(경쟁력)과 talent(능력)보다는 communicative and cooperative(대화와 협동)이 더 중요한 일이다.
아무리 똑똑한 엔지니어라도 다른 사람들과 함께 communication 할 수 없고 협동할 수 없다면 절대로 조직 안에서 성공할 수 없다. 실리콘밸리에 처음 오는 사람들이나 오고 싶어 하는 사람들도 이 부분을 잘 못 생각하는 경우가 많다.
이 글이 도움이 되셨으면 좋겠습니다. 읽어주셔서 감사합니다.
대문사진은 Photo by Lifetime Leather on Unsplash
