5년 후, 10년 후 개발자로써 어떤 모습이 되길 희망하는가?
경력이 제로였던 때 면접에서 이런 질문을 받았다. 그 당시 창업하여 성공하는 것이 목표이고, 그것을 이루기 위해 개발자로서 개발 팀장 정도(?)는 되어보고 싶다고 대답했다. 별로 구체적이지 못하고 회사에 도움이 되는 내용이 아니었기에 좋은 결과를 얻지 못했다.
이 글은 산드로 만쿠소의 소프트웨어 장인 을 읽고 생각해본 커리어 성장에 대한 내용으로 책에서 설명하는 글이 다소 포함되어있다.
커리어
책에서는 소프트웨어 장인으로서 커리어 사다리라는 개념으로 보았을 때 다른 직무를 목표로 하는 것은 사다리를 오르는 것이 아닌 오르던 사다리를 옮겨 타는 것으로 비유하여 커리어의 전환이 좋지 않다고 평가한다.
잠깐 개발자라는 직업을 선택하게 된 계기를 이야기해 보면 초등학교 저학년까지 거슬러 올라가야 하는데, 그 당시 무릎에 특이 질환이 발병해서 오랜 기간 병원 생활을 하였고, 교육보다 무릎 건강에 최우선시하여 다니고 있던 모든 학원을 중단하게 되었다. 중학교에 올라가서 마침 자유학기제가 시행되니 더욱이 학업에 대한 목표 의식과 흥미를 갖기 힘들게 되었던 것 같다. 중학교는 주소지 정보에 따른 자동 배정이라 운명에 맡겨야 했지만, 고등학교는 자소서나 면접까지 봐가면서 신중히 선택하는 요소였기에 진로에 대한 고민을 하게 되었다. 수능을 내가 준비할 수 있을까부터 인서울이 아니었을 때를 생각해 보았을 때 병역특례도 받고 후진학까지 할 수 있는 특성화 고등학교가 더 메리트 있다고 생각했다. 개인 시간의 대부분을 컴퓨터 앞에 보내고 작은 IOT제품으로 부스를 여는 등 열정이 있었고, 무엇보다 집 안에서도 학교가 보일 정도로 가까웠기에 그 학교를 고려를 안 하여야 안할 수가 없었다.
어떤 개발자가 될지 생각해보았을 때 훌륭한 개발자가 되고싶다고 생각했다. 업무로써 커뮤니케이션 능력이나 현재의 개발실력도 중요하겠지만, 오래 유지하기 위해서는 아래 두가지가 가장 중요하다고 생각한다.
- 끊임없는 탐구에 대한 열정
- 항상 더 나아지기를 원해야한다
하지만, 탐구에 대한 열정을 비뚤어지게 표현하는 것은 옳지 않다. 이력서 스펙 채우기는 업무를 하면서 그 업무에 맞지도 않은 기술을 자신의 이력서 채우기를 위한 목적으로 억지로 적용하는 것들을 말한다. 신기술이 나왓다며 무작정 써보면 좋을 것이라며 주장하기 보다는 최소한 그 기술을 개인적으로 사용해보고 이해하여 정말 도움이 되는 기술인지 판단해야할 것이다.
직장은 커리어를 위한 지속적인 투자다. 단순히 일하는 곳이 아닌 배움과 성장의 장이다. 마음이 급해져 낚시하듯이 여러 회사에 맹목적으로 이력서를 넣는 것은 아무런 지성 없이 주식을 매수하는 것이나 다름없다. 최소한 월급은 받겠지만서도 배우는 게 없으면 자신의 가치가 정체되거나 경력에 비해 떨어질 수 있다. 그 대신 내가 일하고 싶은 회사의 형태가 어떠해야 하는지 항상 생각해야 하고,, 현실에 부딪혀, 내가 아직 그런 일을 하기에는 부족하다는 이야기를 들었을 때에도 시간을 두고 다시 준비하고 도전해야 한다.
주위 개발자들의 이야기를 들어보면, 개발자로 평생 먹고살 것이라는 사람도 있는 반면에, 개발 경험을 살려서 PO로 전향하겠다는 사람도 있었고, 한국을 뜨겠다는 사람도 있었다. 본인이 정한 일이니 스스로 만족할 수 있다면 괜찮다고 생각한다. 그치만 개인적으로 개발이 아닌 다른 직무를 목표로 한다고 해서 지금 필요한 배움을 유기하거나 미래를 위해서 현재를 버리는 일은 있어서 안 된다고 생각한다.
개발자로서 유능해지고 싶기도 하지만, 창업도 생각을 지운 것은 아니다 남의 돈을 받아먹고 사는 게 편하다고 하지만, 의미 있는 스톡옵션을 받고 일하는 게 아니라면 한 회사에서 쌓아온 것들은 퇴사하면 그만이고 사적인 것을 제외하고 다른 모든 것들이 회사에 종속되게 된다.
개발을 할 수 있다는 것만으로도 창업하는데 이점이라고 생각한다. 사이드프로젝트로 하다가 수익 모델을 만들어서 사업자를 내게 될 수도 있고, 대학교의 지원을 받거나 국가 지원금 등으로 초기자금 없이 시작해 볼 수 있다.
시간관리
개인
미래 5년 정도의 대략적인 목표를 IF루트로 여러 세계선을 만들어 보았다. → 월 단위로 목표가 생기고 체크리스트를 만들었다. → 목록들이 미뤄지는 경우가 빈번하다는 것을 발견했다. → 취미나 노는 것에 빠져 아예 손도 못 대고 넘거가기도 했다. → 항상 시간이 없다며 핑계 대기 시작했다.
이전의 시간 관리에 있어서 악습에 지배되고 있었는데 최근에 1일 1커밋을 해보면서 3주가 지나자 당연한 것이 되었고, 못하게 되는 상황이 더 힘들지, 매일 진행하는 건 어렵지 않다고 느꼈다.
예전에 TV에서 보았던 집사부 프로그램이 떠올랐다. JYP가 사부로 나오는 편이었는데 그는 본인만의 루틴을 가지고 있고, 오랫동안 그것을 반복했다고 한다. 그런데 그것이 괴롭고 힘든 것이 아니라 이미 익숙해져버려서 오히려 루틴을 지키지 않았을 때가 더 힘든 지경에 다달았다.
루틴 만들기 자체가 재미있는 과정이라고 생각한다. 기존의 정해지진 않았지만, 몸은 기억하고 있는 루틴을 계획한 대로 변경하기란 쉽지 않을 것이다. 그럼에도 반복하고 그것을 기록하여 나중에 되돌아보면 뿌듯한 마음이 생기고 이 뿌듯함을 유지시키고 싶어서 계속 반복할 것이다. 직장생활을 하면서 회식이나 야근이라는 변수가 있을 수 있다. 꾸준히 해야하는 것들 중에서 이런 불확실한 요소에 의해 방해받지 않기 위해 운동 이나 1일 1커밋 등을 아침에 해두고 일을 시작하는 등 루틴에 방해되는 요소를 줄여나가야 한다.
항상 시간이 없다고 하지만, 시간은 만드는 것이다.
책에서 무지의 5단계에 대해서 설명한다. 그리고 그것의 대표적인 대응방법이다.
무지의 5단계 대응
- 무지에 대응하는 습관을 들여라
- 꾸준히 시간 만들기
- 모두 같은 시간이 주어진다. 어떻게 쓰느냐차이
여기서 말하는 4단계에서는 운의 영향이 크게 작용하는 것 같다. 모르는 것을 모른다는 것은 개인이 결코 쉽게 해결할 수 있는 문제는 아니지 싶다. 우연히 접한 매체나 인맥을 통해서 일단 한 번 영향을 받아야 하니 운이 좋지 않으면 출발점이 늦어지거나 아예 시작도 못 할 수 있다. 하지만, 여러 단계를 거쳐 0단계에 이르면 변명이 불가능한 온전히 시간을 쓰지 않은 본인의 책임이다. 여러 유혹과 안 좋은 습관들로 인해서 시간 내는 게 어려울 수 있고, 무지를 채우기 위해 다른 무지를 방치할 수도 있다. 그것에 영향받지 말고 일단 지금 할 수 있는 것을 루틴을 만들며 하는 태도가 가장 빨리 나아갈 수 있을지도 모른다.
회사
프로젝트를 하다 보면, 여러 외부의 상황에 의하여 마감기한이 필수로 생기기 마련이다. 기한내에 완료할 수 있냐는 질문에 ‘네’라고 답하면 상사는 그 말을 믿고 다른 상사와 약속을 해버린다. 정직하지 못 하면 회사 전체에 피해를 입힐 수 있다. 이슈가 있으면 문제 상황을 투명하게 즉시 공유하는 것이 이득이다.
그렇다고 항상 ‘아니오’라고만 대답하는 것은 프로다운 태도가 아니다. 대답하기 전에 문제를 분석해서 대안을 함께 제시하여야 한다. 실용적인 대안을 찾아낼 수 있는 것이 아니어도 불완전한 아이디어가 단추가 되어 다른 사람들이 쓸만한 대안을 만들어 내는 데 도움이 되는 경우도 있다.
대안을 제시하려면 상대보다 더 잘 알아야한다. 그냥 수치적으로가 아니라 상대방을 이해시킬 수 있을 정도로 알고 있어야 한다.
개발자에게 있어서 압박은 피할 수 없다. 기간을 늘리고 안정적으로 배포하기보다, 버그가 있더라도 일정안에 전달하는 편이 낫다고 느낀다. 빨리하는 것과 허술한 것은 다르다.
만약 정말 마감기간이 변경 불가능한 상황이라면 정책적으로 출시 예정을 알리거나 수작업으로 해결가능 하게하여 시간을 벌 수 있다.
단순함을 추구하며 상대방의 언어로 말해야 한다. 관리자나 제품 오너라면 유지보수 비용 절감, 릴리즈 주기 단축, 릴리즈 신뢰성 증대
관리자에게는 그들의 전문 분야가 있다. 개발자가 공식적인 작업목록에 TDD등을 추가하는 것은 어리석다. 테스트 코드를 작성하는 것도 공수에 포함된다.
무언가가 마음에 들지 않는다면 바꾸어라. 그것을 바꿀 수 없다면, 그에 대한 당신의 생각을 바꾸어라. - 마리 엥겔브레이트 (태도의 변화)
팀원들과 불만만 털어놓은 적이있다. 예전의 누군가가 설계한 테이블이 결과적으로 조회 성능에 악영향을 끼치고 있고, 신규 업무에 있어서 방해되는 요소가 있었다. 다시 생각해보면, 그렇게 설계한 것들이 조회 성능에 악영향을 끼칠 정도로 데이터가 쌓였다는 점은 감사해야할 것이다. 어떻게 개선해야할지 생각하고 바꾸는 과정이 성장에 도움이 된다. 상사와의 대화나 팀의 문화에서도 그렇다고 생각된다. 바꾸고 싶은 부분이 있다면 누군가 해결해주겠지라고 생각하고 있기 보다는 직접 노력해야 자그하만 변화라도 생길 것이다.
EX 프로그래밍 과 팀
페어 프로그래밍
페어 프로그래밍에 대한 내용을 읽었을 때 포켓몬스터의 학습장치가 떠올랐다. 학습장치는
배틀에 참가하지 않는 포켓몬에게도 경험치와 노력치를 배틀에 참전한 것처럼 나눠준다. 약한 포켓몬의 레벨을 올리기 좋은 도구. 그래서 약한 포켓몬에게 장착한 채 주력 포켓몬으로 스토리를 진행해도 레벨이 쑥쑥 오르는 것을 볼 수 있다. - 나무위키 학습장치
이처럼 게임 진행에 있어서 가장 편리한 도구로 볼 수 있다.
코드 리뷰와 비교해 볼 때도 리뷰를 하고 받는 사람의 태도를제외하여도 누군가 혼자서 끙끙대서 만든 결과물을 타인이 따로 시간을 들여 설명을 해주고, 수정이 필요한 부분을 알려주면, 그것을 보고 이해한 다음에 수정해야 하는데 이때흐름 끈김현산이 빈번하게 발생한다. 개발은 파도처럼 아이디어가 크게 몰아치고 잔잔하게 머리를 비우는 활동도 중요하다고 생각하는데, 큰 게 올 타이밍에 리뷰요청이 오면 어떻겠는가? 그에 비해 페어 프로그래밍은 서로 같은 내용에 대해 고민하고 빠른 피드백 자주 쓰는 단축키까지 물어 볼 수 있어서 실제로도 빠르게 성장하는 경험을 하여 중요하다고 생각한다. 함께할 사람이 없는 환경에서도 요즘엔 코파일럿과 같은 개발에 도움을 주는 AI가 상용화되어 있으니 내가 싼 코드를 어떻게 리펙터링 할 수 있을 지 바로 비교해 볼 수 있으니, 이전보다 성장하기 좋은 환경이 되었다.
TDD
TDD의 도입이 힘든 어느 팀의 예시이다.
개발을 하기 앞서서 API 엔드포인트 명세서가 필요하다. 도움이 될 만한 것을 요구하였더니, 포스트맨 설정 .json파일을 받았다. 아마 오랜 기간 머물며 본인이 개발할 때 직접 테스트하기 위해 만들어둔 것인 모양이다. 프로젝트에 마감 기한이 있고, 공수를 산정하여 기한을 프로젝트 오너에게 알린다. 기획서를 보며 구현하다가 부족한 부분은 자기 생각이 더해져 완성해 간다. 중간 회의에서 상황을 공유하였더니, 기획 의도와 다르다며 수정을 요구받고 추가로 사소한 변경 사항이 생겼다. 출시일은 변경되지 못하기 때문에 시간을 맞추기 위해 야근까지 하며 완성한다. 출시 후 사소한 휴먼에러로 인해서 재배포를 한다. 회고하며 테스트 코드가 필요하다는 건의가 올라오지만, 공수 시간이 늘 것이라는 말에 의견은 거절당한다. 어느 팀원은 QA 팀이 있으니 맡기면 되지 않느냐고 한다.
프로젝트가 한 번 만들고 끝나는 상황이라면 모를까. 지속통합배포가 기본인 상황에서 프로젝트 크기가 커지면 커질수록 하나의 변경 사항에 대한 나비효과를 예측할 수 없고, 기능을 추가하면서 고려해야 할 코드들도 늘어난다. TDD를 사용하게 되면 사소한 실수로 생겨나는 오류를 방지해주는 것은 기본이고, 테스트 코드를 작성하면서 사전에 요구사항과 비용에 대한 더 나은 이해를 요구하며 지식 공유와 빠른 피드백 루프를 할 수 있다. 그 결과 개발자의 예측에 의한 오버 엔지니어링을 막아주고, 전체적으로 릴리즈가 자동화되어 빨라지게 된다. 무엇보다 가장 큰 이점은 사람이 일일이 테스트하는 것을 방지해준다는 점이다.
TDD도입에 망설이는 가장 많은 요인으로는 그럴 시간이 없다는 것인데, TDD가 익숙해진 개발자는 그냥 개발하는 개발자들보다 비슷하거나 오히려 더 빨리 일을 완료한다는 점을 명심하는 것이 좋을 것 같다.
채용
좋은 팀원에 곁에 있으려면 대우도 중요하지만 일단 채용부터 해야 한다.
면접은 좋은 팀원보다 최악의 팀원을 배제하는 것이 더 큰 이유라고 한다.
개발자의 면접에 있어서는 역시 코딩을 어떻게 하는지가 중요한데, 간혹 직무능력과 관계없는 테스트를 요구하는 회사들이 있다. 그런 것의 내용으로는 인터넷 접속을 막고 보는 시험, 종이에 코드를 작성하게 하는 것, 익숙하지 않은 환경제공이 있는데 면접관 본인도 할 수 있음이 의문일지언정 실무에서 사용하지 않는다. 이런 것들은 좋은 팀원을 놓칠 수 있는 위험이 있다.
실제로 면접에서 메모장 코딩을 겪었는데 일부러인지 윈도우 노트북을 건네받았다. 맥북에 키맵핑을 해서 사용하는 데에 익숙해져 있었기에 습관에 의한 조작실수로 프로그램 창에 팝업이 뜨는 등 당혹스럽기도 했다. 초기 맴버가 서울대 창업 동아리 출신들이시라 본인들은 가능하겠다 싶었지만, 기분은 썩 좋지 못했다.
팀의 사기
C레벨: 프로젝트 책임자는 그가 맡은 업무이니 그의 결정에 따라야한다.
디자이너는 여러 프로젝트에 동시에 참여한다. 수정을 요구하면 다른 업무가 있기 때문에 반영이 늦춰진다.
각자의 자리에서 따로 일하며, 소통은 슬렉을 사용하고 있음에도 굳이 업무적 소통을 메일로 이해관계자를 추가해서 보내야 한다. 이처럼 다양한 이유로 개발자들을 포함한 전체 팀에 악순환이 반복되면, 일에 대한 열정이 떨어지게 된다. 사기 낮은 개발자들에게 열정을 불어넣으려면, 외부로부터 소프트웨어 장인을 수혈받는 것이 좋은 방법이다. 꼬치꼬치 업무지시를 하는 관리자와 다르게 장인은 그저 페어 프로그래밍을 한다거나 개발자들의 멘토로 행동하거나 항상 소프트웨어에 관해서 이야기하고 자기 계발 활동을 공유한다.
배움
어느 조직은 말한다. 회사는 배우러 오는 곳이 아니라 일하러 가는 곳이라고. 하지만 조직이 배움의 터이고싶다 → 프로젝트가 성장함에 따라 그냥 인원을 갈아 끼우는 것은 지속 통합하는 프로젝트에 악영향이 간다. 관리자들은 개발자에게 명령하는 것이 아닌 권한을 주어 스스로 배움의 문화를 만들 수 있게 해야 한다.
내부 학습 모임 만들기나 초기에 그것이 어렵다면, 펫 프로젝트 만들고 있다는 사실을 알리고, 아침이나 저녁 시간에 개발하며 주변에서 흥미가 생기도록 유도할 수 있다.
그건 내 업무가 아닙니다
글쓴이를 잘 안다는 사람이 글쓴이는 손해 못 보고 사는 타입이란다 생각해 보니 맞는 말이다. 중고 시장에서 내가 생각한 적정가가 아니면 구매하지 않는다. 무리하게 깎으려 하다가 판매자가 기분이 상해서 차단당하는 경우도 있었고, 판매하는데 주변에서 “중고면 이만큼 가격을 낮춰야지” 하는데도 내가 생각하는 물건의 가치에 합당한 가격을 받으려고 한다. 바로 구매 의사가 오진 않지만, 기다리다 보면 대부분 가치를 알아본 구매자가 나타난다.
업무에서도 이런 경향을 나타냈었다. 아무리 보아도 직무와 관계없는 일을 요청받았을 때 별로 기분이 좋지 않았다. 이런 일을 하려고 들어온 게 아닌 데라고까지 생각하였다. 되돌아보면 단기적으로는 손해보지 않더라도 장기적으로는 별로좋지 못한 것 같다.. 그건 내 업무가 아닙니다라는 태도는 좋지 않다. 항상 더 많은 것을 제공하여 더 많은 일을 수행해서 내 주변의 모두가 더 나아지도록 노력해야 한다. 내가 대신하여서 남들보다 빨리 끝낼 수 있다면, 주변에서는 더 많은 일을 할 수 있다. 그리고 그런 노력을 계속하다 보면, 주변의 시선을 받게 되어 나중에 무언가를 바꾸기 위해 제안하였을 때 동참하는 사람들이 늘어날 것이다. 하지만 그러한 요청이 주업무가 되어 환경을 바꾸기 힘든 상황에 이르렀을 때, 성장을 고려하여 퇴사를 생각해 볼 수 있다.
그것도 모르세요?라는 식의 질문은 좋지 못하다. 항상 나의 부족함을 인지하고 상대방을 이해시킬 수 있어야한다.
소프트웨어 개발자는 우리가 살고 있는 세상이 진화해 나가는데 꼭 필요한 존재다. 단순히 좋은 코드만 만드는 것이 아닌 산업 전체에 선한 영향력을 가져다주는데 열정을 가지고 있으면 좋겠다.