안녕하세요. 개발자 이종립입니다. 인터넷에서는 제 이름인 이종립을 약간 변형해서 기계인간 John Grib(존 그립)이라는 필명을 쓰고 있고요. 

몇 년 전까지만 해도 제가 개인적으로 성장하는 것에 초점을 맞춰 커리어를 쌓아갔었어요. 저는 SI 회사에서 개발자로 일을 하다 우아한형제들과 컬리에 합류를 해서 다양한 일을 하게 되었는데요. 언젠가부터 회사 동료들이 저를 시니어라고 부르더라고요. 그런데 저는 제가 시니어라는 자각이 없는 상태로 오랫동안 일해서 그런 호칭이 그다지 편하지가 않았어요. 

그런데 시니어라고 사람들이 부르게 된 배경에는 저 스스로 보기에는 아쉬운 게 많았지만 제가 하는 이야기들, 제가 작성한 코드들에 대해서 알게 모르게 다른 분들이 인정하는 게 있었더라고요. 그래서 제가 혼자서 성장할 때는 어떻게 했었나 돌아보게 됐는데요. 

---

위키

저는 제가 성장하는 데 가장 크게 기여한 도구로 위키(Wiki)를 만들게 됐다는 걸 꼽습니다. 제 기술 블로그는 다른 분들이 운영하는 기술 블로그와 달리 위키 형태로 이루어져 있어요. 일반적인 블로그와 다르게 제 블로그는 최근에 한 글자라도 수정을 했다면 예전에 쓴 글이라도 최신 글로 올라오게 됩니다. 

사실 예전에는 다른 분들이랑 똑같이 블로그를 만들었는데 글을 안 쓰게 되는 거예요. 블로그는 왠지 완성한 글만을 올려야 한다는 느낌이 있었는데, 중간 저장 상태에서 글을 그냥 올려볼까 하는 생각을 하다가 ‘이게 위키잖아?’ 싶었어요. 

그렇게 위키를 만든 게 2017년인데, 글이 지금 622개가 있습니다. 마냥 쉬운 일은 아니었는데 사실 쉬웠어요. 회사에서 일을 하다가 모르는 얘기가 나오면 빈 글을 하나 만들어 놓고 나중에 내용을 추가했고요. 이런 식으로 쓰다 보니까 처음에 쓰려고 했던 게 뭔지 알려면 목차가 있어야겠구나 싶었어요. 마지막으로 랜덤 버튼을 만들어서 넣었습니다. 그런데 이 세 가지, 위키 - 목차 - 랜덤이 조합이 되니까 전혀 예상하지도 못했던 어떤 시너지가 났습니다.

랜덤 버튼을 만들고 나서, 예상하지 못했던 글이 나오는 게 너무 재미있었어요. 그래서 몇 년 전 쓴 글이 튀어나오면 틀린 내용을 수정해서 업데이트를 합니다. 그렇게 예전에 쓴 내용을 복습하고, 부족한 글은 업데이트하면서 모든 글이 점진적으로 퀄리티가 좋아지게 됐어요. 

또 제 블로그에는 오른쪽에 글의 목차가 나오게 돼 있거든요. 매일 랜덤 버튼을 누르고 목차를 읽다 보니까 제 블로그에 있는 글에 어떤 목차가 있다는 걸 자연스럽게 알게 됐어요. 일하다 잘 모르는 개념이 나오면 저는 이 내용이 어떤 글에 있다는 사실을 알고 있거든요. 이 과정이 저한테는 굉장한 성장의 비밀 무기가 됐어요. 

주니어 때까지는 이게 잘 통했어요. 근데 시니어가 되니까 상황이 달라지더라고요. 저는 첫 회사였던 SI 회사를 빼고는 전부 스타트업에 다녔는데요. 주니어 때는 그냥 나한테 주어진 일을 열심히 해야겠다고 생각했어요. 

그런데 제가 우아한형제들에서 알게 된 김보윤 님이라는 기획자 분이 계셨어요. 그 분이 『마케터의 일』이라는 책을 한 권 선물해 주셨는데 이런 내용이 있더라고요. “축구 선수처럼 일해야 한다.” 수비수한테 공격 찬스가 오면 ‘앗, 나 수비니까 공격을 하지 말아야지.’ 이런 생각을 하나요? 얼른 공을 뻥 차고 나가서 어시스트를 하거나 골을 넣어야겠죠. 당연한 건데 잊고 있었어요. 

스타트업은 대기업과는 달리 굉장히 많은 일들이 구획 없이 일어납니다. 담당자가 없이 방치된 일도 많은데, 어떤 일을 할 때 답이 안 보인다면 결국에는 내가 담당해서 책임을 지고 끌고 나가는 게 궁극적인 해결책이라는 걸 꽤 나중에 알게 됐습니다. 그 사실을 깨닫고 나서부터 스스로를 시니어라고 생각하게 됐던 것 같아요.

---

PR & 코드 리뷰

그러다 컬리라는 회사에 가게 됐습니다. 다른 스타트업에 비하면 개발자도 많았고 시스템과 체계도 나름 갖춰져 있는 무척 좋은 회사였어요. 그렇게 입사하자마자 무엇을 해야 할까 고민을 했는데, 일단 첫날 가장 먼저 생각이 든 건 PR을 하나 보내야겠다는 거였어요. 스스로에게 주어진 일만 그냥 하는 개발자가 아니라 직접 일을 찾아서 하는 개발자라는 걸 알려주고 싶었어요. 

그때부터 시작이 됐어요. PR을 보내면서 다른 팀 팀장님하고도 이야기를 하게 되고, 친분도 생기면서 몇 년 후까지도 서로 도움을 주게 되는 관계가 되더라고요.

별개로 합류했을 때 아쉬웠던 것 중에 하나는, 이 회사에서는 다른 중요한 일이 너무 많다 보니까 여력이 없어서 코드 리뷰를 도입하지 못하는 상황이었습니다. 그래서 코드 리뷰를 도입해야겠다는 생각이 들어서 입사하고 두 달 내에 여섯 개 프로젝트 정도의 코드 리뷰를 하게 됐어요. 

아마 인프랩에서 향로 님도 그러고 계실 것 같은데요. 그냥 코드 리뷰를 하는 게 아니라 코드 리뷰라는 문화를 도입해야겠다고 생각을 했기 때문에 여러 가지를 생각해야 했어요. 이 활동을 정착시켜야 하는 만큼 리뷰를 받는 사람들이 기분이 나쁘면 안 되겠죠. 그럼 코드 리뷰를 싫어할 테니까요.

그래서 저는 제가 올린 PR부터 코드 리뷰를 진행했어요. 스스로 PR을 올리고 ‘여기 오타가 있네요, 문제 있어요’ 이런 식으로요. 다른 분들이 제 PR에 올린 리뷰를 보고 이렇게 할 수 있다는 걸 깨닫는 게 중요하다고 생각을 했어요.

그리고 다른 분들 코드 리뷰를 할 때는 굉장히 관대하게 했습니다. 코드에 대한 칭찬도 하면서 열심히 했는데, 처음에는 이게 잘 안 됐어요. 사람들의 기분을 신경 써야 된다는 걸 굉장히 천천히 깨달았어요. 만약 새 회사에서 코드 리뷰를 도입해야 된다면 칭찬과 솔직한 피드백의 비율을 8 대 2 정도로 가져갈 것 같아요.

---

BDD

저는 테스트 코드가 없는 환경에서 일하는 것의 어려움을 늘 생각하고 있었기 때문에, 여기서도 테스트 코드를 도입해야겠다고 생각했어요. 다행히 이미 테스트 코드가 꽤 있었는데 스타일이 좀 아쉬웠어요. 코드를 작성한 사람마다 스타일이 달라서 일관성이 떨어지고, 코드를 읽는 데 많은 에너지가 드니까요. 

그래서 테스트 코드 스타일 중에 제가 좋아하는 BDD(Behavior Driven Development) 스타일이 있습니다. 저는 Describe - Context - It으로 대표되는 스타일을 선호하거든요. 자바에서는 Describe - Context- It 스타일의 테스트 코드를 하는 회사가 제가 알기로는 거의 없었는데 이걸 어떻게 도입할까 하다가, @Nested Class를 사용해서 Describe - Context - It 구조의 테스트 코드를 만들 수 있다는 걸 알게 돼서 동료들과 함께 작업을 했는데 그게 너무 재밌었어요. 일정이 급하지 않은데도 재밌어서 밤새 테스트 코드를 작성하는 분도 있었고요. 저도 코드 리뷰를 하면서 굉장히 즐거웠던 기억이 납니다. 

이렇게 작성했던 테스트 코드는 나중에 비즈니스 상의 변화가 생겨서 API 입출력은 바뀌지 않으면서 내부만 바꿔야 될 때 굉장히 큰 도움이 됐습니다. 신뢰할 만큼 충분한 테스트 코드가 있다 보니까 안심하고 빠르게 리팩토링을 진행했던 경험이 있습니다.

---

일지

항상 스타트업은 문서가 부족합니다. 해야 할 일은 많은데 어떤 일을 어떻게 해야 되는지 알려주는 사람이 없는 경우도 많아요. 그래서 대기업들을 부러워하는 이유는 자원 자체보다는 체계를 부러워하는 경우가 많습니다.

그런데 체계는 다른 게 아니라 일을 하는 방법에 대한 가이드가 곧 체계가 된다고 생각해요. 그런데 체계를 만들어야지, 하고 문서를 쓰려고 하면은 문서가 잘 안 써져요. 블로그랑 위키의 차이처럼 각을 잡고 나가기 때문이죠. 

그래서 저는 처음에 일지를 써야겠다고 생각을 했어요. 그래서 매일 아침 컨플루언스(Confluence)에 일지를 하나 추가했습니다. 하루 종일 일을 하다 보면 기억해야 되는 주소라거나 특정 파일명 같은 메모를 그냥 그 일지에다 했어요. 그리고 퇴근하기 30분 전 일지를 정리하면서 그날의 중요한 사건 순으로 배치를 했습니다.

이렇게 하면 우선 인사 평가할 때 좋았어요. 보통 지난 6개월 동안 뭘 했는지 돌아보면 생각이 안 나요. 그런데 일지를 매일 기록해두면 목록을 보기만 해도 ‘아, 그동안 이런 일들이 있었지’ 하고 특정 일을 클릭해서 들어갈 수 있어요. 

이 일지는 다른 분들한테도 도움이 되는 경우가 많았는데요. 특히 새로 입사한 분들한테 “제가 몇 월 며칠쯤 어떤 일을 했는데 보시면 도움이 될 것 같아요” 하고 넘겨드리는 경우도 많아서 서로 작업을 하기에 도움이 됐었고요. 일지만 남기기는 아깝다 싶은 내용은 공식 문서로 만들기도 했습니다. 

---

히스토리

그러다가 일지 개념에서 발전한 히스토리 문서가 있으면 좋겠다고 생각을 하게 됐어요. 사실 사람들이 히스토리를 남기지 않는 이유는 그냥 귀찮아서가 아니에요. 남기고 싶어 하지만 어디다 어떤 사실을 남겨야 할지 모르기 때문에 망설이다가 잊어버리는 거예요.

그래서 처음에는 아주 단순하게, 특정 프로젝트를 진행하기 위해 해야 하는 것들을 날짜별 체크리스트로 만들었어요. 날짜마다 관련된 문서나 슬랙 대화 목록 등을 스크린샷을 찍어서 넣어뒀고요.

이렇게 작성한 체크리스트는 프로젝트 배포 이후에도 계속 유지를 했어요. 그리고 어떤 문제가 생겼다면 문제를 어떻게 인지했는지부터 해결했는지 문서로 정리해서 서브 문서로 만들어서 링크해놨습니다. 나중에 회사에 처음 와서 프로젝트를 새로 시작하시는 분들이나, 새로 팀을 이동해온 분들께 이 문서를 드렸더니 업무에 도움이 많이 됐다고 전해주셨고요.

그리고 이렇게 하면서 각각의 방법도 같이 문서를 남기면 좋겠다 싶었어요. 그래서 히스토리 문서에 각각의 방법에 대해 서브 문서를 만들어놨어요. 

이렇게 히스토리를 남기는 방법에 대한 선례가 생겼잖아요. 그러니까 그 다음 프로젝트에서도 이걸 보고 따라하는 식으로 비슷한 스타일의 문서가 조금씩 추가되었습니다. 이 문서들만 쭉 읽어보기만 해도 새로운 분들한테 온보딩도 되고 히스토리를 알 수 있다는 점에서 굉장히 좋았습니다.  

---

짝

그러다가 팀 이동을 하게 됐는데, 팀의 히스토리를 아무것도 모르고 도메인도 이해하지 못하는 상황에서 일정이 정해져 있는 프로젝트를 하는 상황에 내몰린 거예요. 그래서 ‘이렇게 된 김에 페어 프로그래밍, 짝 코딩을 해보자’ 하게 됩니다.

그리고 여기 옆에 계신 최선혁 님과 같이 짝 코딩을 시작하게 됐어요. 처음에는 선혁 님도 저도 걱정이 많았어요. 지금까지 짝 코딩을 하면 항상 망했거든요. 기분이 상하거나, 서로 바람직하다고 생각하는 코드의 스타일이 달라서 사이가 틀어지기도 했고요.

그런데 이번에는 굉장히 성공적인 짝코딩이었어요. 지금 코로나 때문에 다들 재택을 하고 있잖아요. 근데 재택을 하게 되면 집중력이 저하가 되는 게 가장 큰 문제점이죠. 그래서 위험을 감싸안으면서 출근을 해서 일하는 경우까지 생겼습니다. 

근데 저희는 IntelliJ의 Code with Me를 사용해서 원격으로 짝 코딩을 했거든요. 딴 짓을 못해요. 내가 딴 짓하면 이 분이 바로 알잖아요. 집중이 잘 된다는 것뿐만 아니라 실수를 서로 바로잡아주는 게 좋았어요. 동시에 문제를 푸니까 굉장히 퍼포먼스도 좋았고요. 

예전에는 짝 코딩을 하는 이유가 더 나은 코드를 만들고 서로에게 가르침을 주기 위해서라고 착각을 했었어요. 물론 그것도 나쁜 이유는 아니에요. 그런데 이번에는 제가 도메인을 잘 모르고 도움을 받아야 되는 상황이라고 생각해서 철저하게 선혁 님께 맞추려고 했어요. 그렇게 하니까 서로 자연스럽게 배려를 하게 됐습니다. 알고 보니 이게 이 프로젝트에서 맞는 방법이었던 거예요. 

그리고 우리가 다른 사람한테 내가 코딩하는 걸 보여주고 싶지 않은 마음이 들 때가 많아요. 이 사람이 내 코드를 보고 평가할 것 같다는 생각이 들기 때문이죠. 그런데 같이 짝 코딩을 하루 종일 하다 보니까 잘 모르는 문제는 구글링을 하잖아요. 저희는 서로 화면도 공유하면서 작업했기 때문에 자연스럽게 내가 무엇을 모르는지 짝에게 공개하게 됩니다.

그런 일들이 반복되다 보면 얼마나 많은 시간 동안 내가 모르는 걸 아는 척하면서 살아왔는지를 깨닫게 돼요. 그리고 그렇게 행동하면서 얼마나 많은 스트레스를 받았는지도 알게 되고요. 모른다는 걸 서로 오픈하면서 마음의 안정이 찾아오는 건, 얼마나 편하고 문제에만 집중할 수 있게 되는 일인지 경험해봐야만 알 수 있어요.

많은 사람들이 짝 프로그래밍을 코드 퀄리티를 위해 한다고 생각하는데요. 중요한 건 어느 관점에서 코드 퀄리티를 생각하는지입니다. 내 관점에서 좋은 코드는 상대방 입장에서 잘 안 맞을 수도 있거든요. 항상 코딩을 해놓고 “보기 어떠세요, 바로 이해가 가시나요?” 하고 물었어요. 선혁님도 똑같이 그런 말씀을 하시고요. 그런 일들이 반복이 되니까 서로 신뢰가 강력하게 쌓이더라고요. 무엇보다 굉장히 빠른 코딩이 가능했습니다. 일정이 촉박한 상황에서 굉장히 큰 도움이 됐어요.

그래서 만약 여러분들도 짝 코딩이 잘 안 됐다거나 아니면 뭔가 마음속에 짐이 많은데 회사에서 내가 부족한 걸 드러내고 싶지 않다거나 할 때는 마음을 열고 내가 모른다는 걸 솔직히 오픈하면서 해보시는 것도 좋은 경험이 될 수 있다고 생각을 합니다.

---

좋은 친구

저는 예전에 학창 시절에 친구가 없어서 고민이었어요. 그냥 친구가 아니라 좋은 친구가 있었으면 하는 생각을 늘 했거든요. 아마 많은 분들이 좋은 친구가 있으면 좋겠다는 생각을 하면서 살아가실 거예요. 그런데 좋은 친구가 잠깐은 있어도 오래 가지 않더라고요. 만나기도 쉽지 않았고요. 

근데 그러다가 20대 중반쯤엔가 문제를 깨닫게 됐어요. 내가 좋은 친구를 기다리니까 그렇구나. 좋은 친구라는 분들은 세상에 무척 드물어요. 그래서 좋은 친구를 만드는 가장 좋은 방법은 내가 먼저 좋은 친구가 돼야 된다는 걸 뒤늦게 깨달았어요. 그래서 그때부터 좋은 친구가 저한테 해주기를 바랬던 일들을 제가 친구들한테 하니까 그 친구들이 저한테 좋은 친구가 돼주더라고요. 놀라운 경험이었어요. 그 전에는 그냥 앉아서 좋은 친구가 다가오기만을 기다리고 있었기 때문에 제가 외톨이였던 거였어요. 

회사에서도 비슷하다고 생각해요. 만약 내가 좋은 동료가 많이 있기를 바란다면 좋은 동료가 많은 회사로 가야겠다고 생각을 할 수도 있을 것 같아요. 그런데 그렇게 좋은 회사로 가서 뛰어난 분들이 많은 곳에 가서 좋은 동료를 잔뜩 얻는 것도 괜찮은 전략이겠지만, 저는 내가 먼저 좋은 동료가 돼서 다른 동료분들한테 내가 알려드릴 수 있는 건 알려드리고 최선을 다해서 도와드리는 게 큰 도움이 된 것 같아요.

그래서 좋은 친구가 된다는 마음으로 내가 먼저 좋은 동료가 된다면 항상 주위에 좋은 동료가 있지 않을까 하는 생각을 하게 됐습니다. 그리고 그게 아마 스타트업에서 개발자가 회사랑 같이 성장을 하는 제일 괜찮은 전략이 아닐까 하는 생각을 합니다. 발표는 끝입니다. 감사합니다.

---

인프런 개발 파트와의 Q&A 💬

하루 일과가 궁금해요. 매일 24시간을 어떻게 활용하시나요?

이종립: 저는 출근을 하면 제일 먼저 그날 일지를 쓰기 위한 문서를 만들었어요. 최근에 짝 코딩을 할 때는 하루 종일 코딩에만 전념할 수가 있었거든요. 그래서 아침에 선혁 님이랑 바로 프로젝트 코딩을 시작했고요. 선혁 님이 브레이크를 많이 잡아주셨어요. 1시간 코딩하고 “이제 10분 쉬죠.” 하고요. 짝 코딩은 집중력이 저하되는 걸 방지하는 활동이기 때문에 시간이 흘러가는 걸 모르고 코딩하게 될 가능성이 있어요. 그래서 같이 중간중간 쉬는 시간 가지면서 일하다가 퇴근 시간 되면 퇴근했습니다. 물론 퇴근 시간 전후로 해서 그날 있었던 일들을 일제히 정리하고 하는 일들도 있었고요.

최선혁: 오늘 그냥 향로님 만나러 뵈러 왔다가 되게 부끄러운데요. (웃음) 저는 종립 님같이 의지력이 강하지 않아서 배우려고도 하고 따라하려고 했지만 의지력이 약해서 금방 며칠 만에 포기하고, 그런 사람이거든요. 모든 사람이 종립 님이 하는 이 많은 항목들을 알면서도 행할 수는 없지만 그래도 저 나름대로는 아침엔 할 일 정리하고 회사 업무를 하고요. 퇴근하고는 그 기술 서적 같은 걸 읽으려고 노력을 하고 있고, 중간중간 온라인 강의도 보고 개인 시간은 개발하면서 보내는 편이고요. 회사 일을 하고 나면 저녁에 녹초가 돼서 10시에 자기 전에 운동도 또 챙겨 하는 그런 식으로 하루를 보내고 있습니다.

이종립: 공부를 하는 게 공부를 해야 돼, 라고 생각을 해서 하는 게 아니라 글을 계속 추가하고 정리하면서 나한테 도움이 되는 걸 경험하다 보니까 너무 재밌어요. 그래서 계속하게 되는 것 같아요.

개인적인 공부를 할 때 공부를 계획하는 주기나 방법이 따로 있나요?

이종립: 저는 보통 공식 문서를 많이 보려고 하고요. 자바 가비지 컬렉터에 대한 흥미가 생겼을 때가 있었는데, 그때는 오라클(Oracle) 사이트에 올라와있는 공식 가비지 컬렉터 튜닝 가이드를 보고 번역을 해가면서 공부를 했었어요. 막상 밑에 있는 것까지 깊이있게 들어가는 분들은 많지 않은 상황에서 메모리 관리에 대해 신경을 쓰는 게 중요하다고 생각을 했거든요. 그런데 엉뚱한 소스로 파고든다면 큰일나잖아요. 그래서 저는 항상 공식 문서를 기준으로 한 공부를 무척 중요하게 생각해요. 

사실 이게 그렇게 빠른 종류의 공부는 아닐 수 있어요. 굉장히 시간이 오래 걸리는 무식한 방법일 수도 있지만, 그게 저한테 맞는 공부라고 생각을 하고요. 제 위키에는 항상 참고 문헌을 정리를 해두려고 하는 편이거든요. 그래야 나중에 다시 찾아 들어가서 공부를 할 수도 있고, 내가 그때 공부를 잘못했었다는 걸 깨달을 수도 있어서 가능하면 참고 문헌, 1차 저작 위주로 공부를 하려고 해요. 

그리고 필요하다면 소스 코드도 봅니다. 자바 가상 머신에 있는 가비지 컬렉터 소스 코드도 C++로 된 거 열어서 읽어보고, 소스 코드 발제해서 올린 다음에 주석도 달고요. 이렇게 하는 게 저에게는 그나마 마음이 놓이는 공부가 아닐까 생각합니다.

최선혁: 저는 종립 님 같은 학습 방법이 좋지만 모든 사람이 종립 님처럼 할 수는 없다는 주의입니다. 너무 스트레스를 안 받으셔도 될 것 같아요. 100명 중 99명은 그런 식으로 안 해도 되고 종립 님처럼 잘해놓은 블로그로 공부하면서 부족한 건 책도 읽으면 된다고 생각하는데, 이제 그런 식으로 하다 보면 이제 말씀하신 힌트가 있습니다. 공식 문서를 보시는 분들이 깊이가 달라요. 스타트업 같은 경우에는 결국은 회사의 성장과 품질이 곧 나의 성장이기 때문에 품질이 좋고 장애가 안 나야 되잖아요. 그러려면 이렇게 깊이 있게 공부하고 내 걸로 만드는 게 되게 중요하다는 걸 깨달았습니다. 같이 공부하시죠. (웃음)

최근에는 어떤 걸 공부하시나요?

이종립: JVM 공식 문서를 번역하려고 지금 준비하고 있는 게 하나가 있고, 그리고 이제 Clojure라는 새로운 언어를 시작을 했어요. 새로 간 그린랩스라는 회사에서는 Clojure를 쓰게 되니까 그렇게 두 가지를 공부하고 있습니다. 

최선혁: 컬리에서 쿠폰이라는 시스템을 MSA로 하면서 생각을 많이 했거든요. 나 자신에 대한 실력, 그리고 내 생각, 그리고 소프트웨어 아키텍처에 대한 것. 과연 클린 코드가 무엇인가, 누구를 위한 것인가? 헥사고널 아키텍처를 책으로 배워서 도입했는데 너무 어려워서 사람들이 이해를 못하고, 클린 코드를 했는데도 클린 코드가 아닌 게 돼버린 결과도 있더라고요. 그러면서 이제 어떤 기술보다는 도메인 자체나 책임에 대해 공부를 많이 했었고요.

그리고 최근에는 종립 님처럼 저도 Clojure 공부를 하고 있어요. 지금 그린랩스에 신선마켓이라는 B2B 쇼핑몰이 있어요. 그 쇼핑몰 서버 쪽은 다 Clojure로 되어 있다고 알고 있어요. 그렇게 헬로 월드부터 Clojure 공부를 하니까 새하얀 백지에서 if문부터 찍었던 오래 전으로 다시 돌아가는 느낌이 좀 들더라고요. 그래서 저도 Clojure 책 보고, 유데미 강의 들으면서 계속 그러고 있습니다.

두 분이 생각하시는 시니어 개발자는 어떤 개발자일까요?

이종립: 어려운 질문인데, 시니어 개발자 조건이 어디 문서나 법전에 적혀 있는 게 아니잖아요. 그래서 상황에 따라 달라진다고 생각하고, 어떻게 보면 그렇게 중요하지 않은 질문일 수도 있다고 생각을 해요. 그 사람이 무엇을 하고 있고 조직에 어떤 영향을 끼치는지가 중요하지, 난 이제부터 시니어야 하고 막 어깨 힘주고 다니지는 않을 거잖아요. 

그래서 내가 다른 사람들한테 영감을 주고 있는지, 아니면 프로세스를 개선하고 있는지, 동료들이 좀 더 즐겁게 일하는 데 도움을 주고 있는지가 더 중요하다고 생각을 합니다. 그래서 시니어라는 단어 자체를 언급하는 게 굉장히 조심스러워요. 특히 스타트업에서는 ‘내가 시니어니까 난 이것만 할 거야’라는 생각에 빠지게 되면 시니어가 아니라는 생각도 들고요. 그래서 회사라는 조직을 내가 풀어야 할 문제라고 여기고 같이 나서는 분일수록 시니어라는 신념에 좀 더 가까워지는 분이 아닐까 생각합니다.

최선혁: 최근에 고민을 많이 한 주제이기도 하거든요. 왜냐하면 저도 99년 말에 이제 개발을 시작해서 IT 버블 때부터 산전수전 다 겪었는데요. 컬리에 입사하고 나니까 뭔가 부끄러운 거예요. 5년차인 친구가 들어왔는데 너무 잘하는 거예요. 요즘 젊은 친구들은 이렇게 공부를 하는구나 하면서, 시니어라는 단어를 꺼내는 것 자체가 되게 부끄럽다고 생각을 했거든요.

그냥 예전에는 5년 되면 대리, 8년 되면 과장… 이랬는데 지금은 동등한 입장에서 시작하는 시대죠. 그리고 기존의 개발자들이 갖고 온 노하우들이라고 해도 이제 프레임워크가 다 해결해 주기 때문에 의미가 없는 시절이 되었고요. 시니어/주니어의 경계도 이제는 무의미한 것 같고요. 나이와 경력에 상관없이 서로 배워야 하고 내가 나이가 많다고 저연차 주니어 동료를 보고 ’그건 아니야’ 하는 마인드 자체가 있으면 안 된다고 생각하고요. 너무 강박관념에 싸여 있을 필요도 없다고 생각합니다.

다양한 언어와 기술을 써오셨을텐데, 어떤 기술을 좋아하시나요? 스타트업에서 기술을 선택하는 기준은 무엇인가요? 

이종립: 일단 제 언어 취향은 다른 분들이랑 많이 다를 거예요. 제가 제일 좋아하는 언어는 Bash Shell Script예요. 셸 스크립팅을 하다 보면 명령어끼리 파이프로 연결을 하고 중간에 분기를 내서 빼거나 아니면 결과를 리다이렉팅해서 표준 출력으로 출력을 하거나 파일로 출력을 하거나 그렇잖아요. 저는 여기서 굉장한 스릴과 재미를 느끼거든요. 모든 명령이 서로를 연결한다는 점이 되게 중요하다고 생각해요. 입력도 결과도 전부 스트링이어서 모든 명령들이 결과를 만들 수가 있는 거죠. 저는 여기서 굉장한 자유로움을 느꼈어요.

그리고 언어마다의 특성은 그렇게 중요하게 생각하지 않는 성향도 여기서 나온 것 같아요. 요즘은 마이크로서비스 아키텍처를 실천하고 있는 회사도 굉장히 많아서 API 포맷과 프로토콜만 잘 지킨다면 각각의 인스턴스에 들어가 있는 소스 코드가 어떤 건지는 그렇게 중요하지 않은 시대가 다가오고 있다고 생각하고요. 

결국 비즈니스 상황에 맞는 가장 적절한 언어를 고르는 게 중요하다고 생각을 해요. 왜냐면은 어떤 언어를 선택하건 퍼포먼스가 됐건 유지 보수가 됐건 그것은 블랙박스 컴퓨터 안의 일입니다. 그래서 회사 입장에서는 업계에서의 분위기, 비즈니스 요건 같은 것들을 종합적으로 선택해서 회사가 살아남고 안정적으로 엔지니어링을 할 수 있는 기술을 선택하는 것이 중요하다고 봐요. 그리고 제 개인의 호오는 회사와는 또 별개라고 생각을 하기 때문에 그런 걸 기준으로 기술을 선택하게 될 것 같습니다. 

최선혁: 저도 처음에 VBScript하고 asp, PHP 이런 식으로 시작하다 자바라는 걸 알게 되고 그러면서 시작을 했거든요. 그런데 요즘 들어서는 그렇게 너무 특정 언어에 국한해서 벽을 질 필요는 없는 시대인 것 같아요. 결국은 하나로 되잖아요. @Driven으로. (웃음) 너무 거기에서 나는 꼭 이거를 고집해야 돼, 이럴 필요도 없는 것 같고요. 그냥 비즈니스와 상황에 맞게 빠르게 결과물을 내고 성장하는 게 더 중요하다 생각하고요. 결국 핵심 원리는 다 똑같다고 보거든요. 

회사에서 새로운 기술 스펙을 공부할 필요가 있어서 회사 일과 별개로 빠르게 공부해야 하는 경우가 있으셨나요? 그럴 때는 어떻게 하셨나요?

이종립: 그런 경우는 항상 일어나는 것 같아요. 회사 일이랑 관련된 거면 회사 동료한테 물어보기도 하고요, 그냥 적당히 포기하는 게 되게 중요한 것 같아요. 공부만 계속하고 있으면 일을 못할 수도 있잖아요. 중간에 멈추는 지점을 판단하는 게 중요한 것 같아요. 저는 회사에서 일을 하는 게 제일 중요하다고 생각하거든요.

그래서 애초에 공부를 할 때 회사 일하고 완전히 동떨어진 거는 가능한 안 하려고요. 만약 회사에서 하는 일과 동떨어진 공부를 한다면 회사 일에서 아쉽게 될 거고, 반대로 회사 일에만 시간을 많이 들으면 공부가 제대로 안 돼서 마음이 굉장히 힘들 것 같거든요. 그래서 서로에게 도움이 되는 방향으로 공부를 하는 게 좋다고 생각을 합니다. 

코드 리뷰나 짝 코딩을 할 때 하지 말아야 될 것들은 무엇일까요? 

이종립: 많습니다. 정말 중요한 건 감정이죠. 어떤 말은 상대방을 위해 이야기하는 것 같은데 사실은 내 감정이 좋자고 하는 말도 있거든요. 이런 종류의 말을 철저하게, 가능한 한 안 해야 됩니다. 코드 리뷰를 할 때도 상대방이 기분을 상하지 않게 하는 게 굉장히 중요하고요. 

기분이 상하더라도 좋은 코드가 나오는 게 중요한 게 아닌가 생각할 수 있지만, 우리는 그냥 개발자가 아니라 문화를 만들어가야 되고 조직 자체를 엔지니어링을 해야 되거든요. 동료와 서로 신뢰할 수 있는 관계가 되고, 이 사람이 나한테 상처를 주지 않는다는 확신이 있어야만 서로의 코드에 대해 “이 코드는 좋지 않습니다”라고 말할 수 있거든요. 그 단계를 밟지 않는다면 순서에 어긋난다고 생각을 해요. 

그리고 내 입장에서 코드가 좋은 것보다 다른 사람들이 볼 때 좋은 코드인 게 더 중요하다고 생각합니다. 내 고집을 피우다 보면은 다른 사람들한테 상처를 주기도 하고 아니면 반대로 내가 상처를 받습니다. 결국 사람을 진짜로 움직이는 건 감정이라고 생각하거든요. 

그리고 최근에는 오래 전 프로그래밍 영웅들처럼 혼자서 모든 걸 만들 수 있는 시대가 아니에요. 결국 평범한 사람 여러 명이 힘을 합쳐 대단한 일을 하게 하는 게 중요한데, 이 톱니바퀴들이 녹슬고 빠져버릴 수도 있다는 생각을 합니다. 그래서 프로젝트 매니징을 하건 프로젝트의 일원으로서 일하건 간에 자신의 감정을 컨트롤하고 다른 사람의 감정을 있는 그대로 이해하고 받아들이는 게 되게 중요한 능력이라고 생각해요.

최선혁: 덧붙이자면 한국에는 존대 문화와 군대 문화가 있잖아요. 이걸 버려야 할 것 같아요. 외국처럼 서로 동등한 선상에서 일을 해야 코딩이나 이런 부분에 시행착오를 덜 겪지 않을까? 내가 너보다 나이가 많은데, 경력이 많은데 이러면서 서로 자존심 싸움이 되고 무시하고 다투면 좋은 페어가 될 수 없죠. 아무리 좋은 스쿼드라도 먼저 연애하듯 서로 상대방을 존중해 주면서 의견을 경청하는 자세가 돼야 좋은 짝이 되는 걸 느꼈거든요. 그런 마인드가 중요하다는 생각을 합니다.

이직할 회사를 고르는 기준은 어떻게 정하시나요?

이종립: 그 회사가 어떤 사업을 하고 있는지, 임금 체불 걱정은 없는지, 성장하는 회사인지, 자사 프로덕트를 가지고 있는지, 내가 흥미가 있는 종류의 기술을 사용하고 있는지가 중요했던 것 같아요. 물론 처우나 복지, 출퇴근 거리 같은 것들은 기본이라고 생각을 하고요.

최선혁: 그 회사 도메인을 내가 얼마나 사랑하는지나 잘 맞는지도 중요한 것 같아요. 돈을 정말 많이 주는데 불법 카지노, 불법 블록체인, 성인 동영상 제작… 이런 걸 하면 되게 스트레스 받을 거 아니에요. 저는 맛있는 거 먹고 요리하고 가족이나 지인들과 얘기하는 걸 되게 좋아하는 사람이거든요. 근데 컬리에 있으면서도 컬리에서 물건을 사서 먹는 게 너무 좋고, 회사가 성장하는 게 좋더라고요. 내가 아무리 열정적으로 일을 해도 비즈니스가 성장하지 못하면 많이 아쉽고요. 나와 맞고 회사도 같이 성장할 수 있는 게 많이 중요한 것 같아요. 도메인 관심사가 같아야 되는 게 일종의 궁합이라고 생각을 합니다.

그동안 많은 저연차 주니어를 보셨을 텐데, 폭발적으로 성장하는 주니어들의 특징이 있을까요?

이종립: 성격이 명랑합니다. 굉장히 밝아요. 그런 분들 특징이 사과를 잘해요. 밝게 웃으면서 사과하고, 감사 인사도 모르겠다는 말도 잘해요. 근데 이런 분들이 말만 그런 게 아니라 진짜 그렇게 생각을 하고 계시다 보니까 뭐 하나라도 더 가르쳐드리고 싶어요. 

아까 감정 말했었죠? 그것처럼 이분이랑 같이 있을 때 즐겁다, 뿌듯하고 보람이 느껴진다, 더 여러 시간 같이 일해보고 싶다는 생각으로 감정적으로 시간을 자꾸 보내게 되면서 내가 아는 것들을 계속 전달해 드리게 되는 것 같아요. 이런 분들한테는 저 말고도 다른 분들도 많이 알려주시더라고요.

물론 혼자서도 공부를 잘하는 분들이 있지만, 현대 사회의 특성상 다른 사람들의 도움을 왕창 받으면서 올라가는 사람들이 더 잘 될 거라고 생각을 합니다.

최선혁: 두 가지 종류가 있는 것 같아요. 하나를 알려주면 둘을 이해하는 똑똑한 친구들이 있는 반면에, 배우려고 하는 욕구가 강해서 스스럼없이 물어보는 분들이 되게 성장이 빨라요. 그런 분들한테는 저도 막 알려주고 싶거든요. 자만하는 주니어들보다는 배우려고 하는 분들이 지나고 보면 더 잘 돼 있는 것 같다는 생각이 들더라고요. 

결국은 다 인간관계인 것 같아요. 이 바닥이 좁아서 결국은 다 만나더라고요. 한 다리 건너면 다 알고 이래서. (웃음)

---