당신 근처의 조은 동료

안녕하세요. 소프트웨어 엔지니어 하조은입니다.

조은님은 어떻게 처음 개발을 하게 되었나요?

저는 원래는 컴퓨터 공학을 전공할 생각은 없었고, 원래는 '언론정보문화학부'라는 학부에 있었어요. 어쩌다 보니까 언론 쪽이 저랑 안 맞다는걸 깨달았어요. 그렇다면 어떤 분야가 좋을까 고민했는데 교양 수업으로 들었던 C 프로그래밍이 저랑 잘 맞았어요. 그때부터 개발을 조금씩 하게 됐어요. 당시에 버스 요금 계산하는 프로그램을 만들었는데, 조건문 만들고 조건문을 위한 반복문과 배열을 쓰는 것들이 되게 재밌었어요.

그때부터 개발자가 되어야겠다고 생각한건가요?

사실 저는 개발자가 되고 싶진 않았고, 당시에 약간 스티브 잡스 같은 사람이 되고 싶다는 생각이 있었어요. 어떤 프로덕트를 만드는 사람이 되고 싶다는 생각을 한 것 같아요. 마침 우리 학교에서 창업 관련된 학부들이 붐이었어요. 창업 경진 대회도 많아서 몇 번 나가게 됐는데, 그때마다 실질적으로 만들 줄 아는 능력이 있는 사람이 있는 팀이 상을 받는다는 느낌을 받았어요. 개발자가 있으면 상을 받기 쉽다고 생각했죠. 저는 그 당시에 프로그래밍도 조금 하는 편이고, 전공으로서도 언론보다는 컴퓨터 공학도 괜찮을 것 같았어요. 물론 수학은 정말 못하고 싫어하지만 해 볼 만하다는 생각으로 전공을 3학년 때 바꿨어요. 그래서 결과적으로 컴공으로 졸업하게 됐죠.

컴퓨터 공학 수업은 잘 맞았나요?

별로 안 맞았어요. 코딩을 하는 것 자체는 좋아했는데, 컴퓨터 사이언스를 이해하는 것에 대해 별로 관심이 없었어요. 그나마 데이터 구조는 재밌었어요. 데이터 구조는 많은 데이터 구조를 직접 같은 걸 구현해봐야 하거든요. 하지만 실제로 이론적인 컴퓨터에 대한 지식을 알고 싶진 않았어요. 지금 생각해 보면 저는 '컴퓨터 공학 기본 지식을 잘 안다'는 이런 게 아니라 '관련 용어를 대충 기억한다' 정도인 것 같아요. 그래서 나중에 문제를 봤을 때 어떤 용어를 사용하는지 키워드를 알게 되는 정도로 전공을 익혔던 것 같아요.

학교 시절 배운 것 중에서 가장 잘 배운 게 있다면?

수업 이름이 정확하게 안나는데 서비스를 직접 만들어보는 수업이 있었어요. 애자일 방법론을 알려주고, 프로젝트 하나를 한 학기 동안 하는 수업이었어요. 그때 저는 안드로이드 개발을 했었어요. 프로젝트에서 만들고 싶었던 건 카메라 앱이었어요. 사진의 구도를 맞춰주는 단순한 앱이었죠. 안드로이드를 선택한 이유는, 안드로이드는 어떤 컴퓨터든 쓸 수 있지만 iOS 개발은 맥을 써야했어요. 애플 노트북이 비싸서 안드로이드로 하는게 맞다고 판단했어요. 그 수업을 통해서 제가 전혀 모르는 분야에 대한 코딩을 하기 위해서 탐색하는 기회를 좀 얻을 수 있었던 것 같아요. 그전까지는 교수님이 다 알려준 언어였기 때문에 그냥 주워 먹었는데, 어느 시점 이후로는 제가 스스로 찾아 먹어야 되잖아요. 그 수업때 새로운 언어를 배우거나 새로운 기술을 익히는 데 필요한 검색 능력을 익혔어요.

다시 만약에 선택할 수 있더라도 컴퓨터 공학 전공을 할건가요?

모르겠어요. 근데 졸업을 컴퓨터 공학으로 하는 게 좀 유리한 것 같긴 해요. 확실히 취업 전선에서 타이틀을 내세우기가 되게 쉽다고 생각해요. 다시 선택한다면 졸업은 컴공으로 하고 컴공과 디자인 관련된 공부를 복수 전공으로 하면 좋을 것 같아요. 고객 경험(UX)을 중심으로 사고하는 방식을 익혀두는 게 유용한 제품 개발자가 되는 것에 도움이 된다고 생각해요. 그래서 복수 전공을 한다면 컴공과 디자인을 하지 않을까 싶네요.

졸업 후 처음으로 일하게 된 곳은 어디인가요?

졸업 전에 코딩 인터뷰 준비를 하고 있는데, 로켓펀치를 통해서 연락이 와서 마켓프레스(마플코퍼레이션)의 CTO랑 만나게 됐어요. 그때 사실은 일면식도 없는 사람이 메일로 연락이 와서 마켓프라스라는 회사에서 마플이라는 서비스를 만들고 있는 사람인데 만나보자고 연락이 와서 저는 약간 이상한 사람이라고 생각했어요. 제가 또 컴공이라고 돼 있으니까 기본적인 전공자한테 기대하는 수준이 있을 텐데 저는 그 수준에 한참 못 미치는 사람이라고 생각해서 메일을 봤을 때 거절했어요. 그랬는데 그분이 그건 아무런 문제가 되지 않는다 그래도 한번 얼굴이나 보자고 하셔서 만나게 되었죠. 작은 회사였으니까 면접 프로세스가 별로 없었어요. CTO 분과 이야기하다가 그해 7월부터 입사해 달라고 하셔서 졸업식 하기도 전에 들어갔죠.

마플은 프론트/서버 직군이 따로 구분이 없다고 들었어요.

맞아요. 마플은 기능 단위로 한 사람이 다 만들어요. 마플에서 서버 작업을 할 때는 NodeJS를 사용했어요. 그때 결제까지 해서 장바구니 기능을 제가 만들었는데 이런 방식이 잘 맞았어요. 직접 쿼리도 날리고, 결제가 발생하면 결제 이력을 DB에 적재하는 일들을 했는데 잘 맞았어요.

마플에서 함수형 프로그래밍했던 경험이 궁금해요.

마플에서는 함수형 라이브러리도 만들어서 사용했었어요. 여러 가지 시도를 했는데, 함수형 프로그래밍이 결과적으로 함수의 조합으로 새로운 로직을 짜내는 컨셉이라서 Lego JS라고 부를까 라는 이야기도 있었어요. 또, 알파벳들의 합처럼 만들려고 ABC JS라고 해서 A에는 어떤 함수들이 모여 있고 B에는 어떤 함수들이 모여있고 A와 B를 조합해서 사용하는 라이브러리도 만들었어요. 제가 만들었던 건 세 번째 버전부터였는데, Partial JS라는 라이브러리였어요. Lodash와 underscore의 장점을 합친 라이브러리였죠. 최근에는 FxTS까지 만들었더라고요.

마플에서 여러 가지 작업을 하면서 느낀 점이 있다면?

마플에서는 개발자들이 기획적으로 선택할 수 있는 자유도가 되게 높았어요. 정해져 있는 것들을 마음대로 바꿔볼 수 있고 제안해볼 수 있고 그래서 웬만한 픽셀 단위는 그냥 개발자들이 정했어요. 그런 형태가 지금 생각해보면 제품 자체에 대한 두려움을 없애준 것 같아요. 이 제품에 제가 한마디 보태는 게 진짜 문제 되지 않는다는 자신감을 준 셈이죠. 또 코드도 라이브러리를 직접 만들어 사용하다보니 제품 전체에 대한 이해도가 되게 높아지는 장점이 있었던 것 같아요. 그런 것들이 되게 이로운 경험이 아니었나 싶어요.

마플에서 가장 즐거웠던 경험

일단은 개발자 5명 밖에 없었고, 개발자들은 다 판교에 있는 작은 오피스를 썼어요. 제가 거기서 막내였는데 되게 좋은 형들이랑 일하는 기분이었고, 배우는 것도 많았어요. 제 입장에서는 자바스크립트의 기본기를 다질 수 있는 좋은 시간이었습니다. 그때 막 입사했을 때 처음에 한 책 두 권 쥐여주면서 공부하는 시간을 한 2~3주를 줬어요. 그래서 아무것도 안 하고 공부만 했고, 그때 자바스크립트 관련된 책들을 한 대여섯 번 읽으면서 기본기를 다질 수 있어서 좋았어요. "자바스크립트 닌자 비급"과 "자바스크립트 핵심 가이드"라는 책이 좋았던 기억이 있습니다.

그 이후에 뱅크샐러드로 이직을 결심하게 된 이유가 따로 있나요?

2018년에 디지털 노마드가 굉장히 핫했어요. 그 당시에 막 치앙마이 가서 한 달살이 하면서 노마드로 살다가 싱가포르 같은 데서 일하는 라이프 스타일이 멋지다고 생각 했어요. 저도 그걸 해보고 싶었어요. 그래서 한참 알아보고 있었는데, 그때 마침 헤드헌터에게서 연락이 왔어요. 그 헤드 헌터를 만나서 판교에서 카페에서 커피를 한잔하는데, 제가 받는 연봉을 보더니 세상 물정 모른다는 식으로 말하는 거예요. 그때 약간 충격을 받고 한번 재미로 면접을 보자 해서 봤는데, 막상 면접 보고 합격하니까 디지털 노마드고 뭐고 생각 안 나더라고요. 아무래도 재정적으로도 힘들었던 부분을 해결해 줄 수 있는 곳으로의 이동이 필요했던 것 같아요. 그래서 뱅크샐러드로 결정하게 되었어요.

뱅크샐러드에서 어떤 일들을 했는지 궁금합니다.

뱅크샐러드에서 처음에는 이벤트 트래킹하는 일을 했어요. 뱅크샐러드 내에서 웹뷰에서 엠플리튜드, 앱스플라이어 같은 도구로 이벤트를 적재하는 라이브러리를 만들어내는 일이었죠. 그리고 나서는 성장 스쿼드라는 매일 실험을 하는 조직에 갔었어요. 그렇게 실험을 하면서 3, 4개월 보내고 금융 비서팀에 갔죠. 금비팀에 가서 “이렇게 소비하다간 거지 돼요" 같은 다양한 소비 조언을 만들고 발송하는 일을 했어요. 그때 이제 처음으로 테크 리드의 역할을 해봤습니다. 그 후에도 솔루션 스쿼드, 투자 스쿼드, 보험 스쿼드, 건강 스쿼드를 갔다가 인증 스쿼드에 가게 되었어요. 인증 스쿼드에서 마이데이터 작업을 서영님과 함께했습니다.

테크 리드로 일하면서 느낀 점이 있나요?

저는 제가 테크 리드의 자질을 갖췄다고 생각하진 않았어요. 좀 더 의견을 자주 개진하고, 조금 더 레거시에 대해서 이해하고 있고, 다양한 분들과 협업하는데 능하다는 게 제 장점이었는데 그걸 좋게 봐주신 것 같다고 생각해요. 그걸 마침 필요로 해주셔서 테크 리드로 일했던 것 같은데, 그 과정에서 의사결정 하는 기준에 대해서 많이 고민했던 것 같아요. 어떤 식으로 해야 우리가 제품을 빠르게 그리고 정확하게 만들어낼 수 있냐는 고민을 했어요. 마냥 너무 완벽한 걸 만들어내려다가 시기와 안정성을 놓치느니, 복잡도를 낮추고 빠르게 만드는 것이 에너지를 덜 쓰지만 오래 갈 방법이라는 생각들을 많이 했던 것 같아요. 그때 이제 한참 실험에 대한 문화가 많이 열풍이었어서 그런 의사결정들을 계속 배워나갔던 것 같고, 그러면서 이제 테크 리드로서 의사결정들을 하는 방법에 대해서 이해할 수 있었어요.

서버 작업도 했다고 알고 있어요.

서버 작업은 사실 어쩔 수 없는 부분이었어요. 당시에 필요한 작업이 분명히 있는데 서버 리소스를 대줄 수 있는 상황이 아니었고 또 제가 서버 경험이 있는 사람 중의 하나였는데, Go는 전혀 몰랐지만 그래도 기본적인 개념을 알기 때문에 해볼 만하다고 판단했어요. 저를 도와줄 수 있는 분들이 계셔서 그걸 믿고 그냥 밀어붙였던 것 같아요. 그때 경험 덕분에 일하면서 필요한 서버 개발 작업을 조금 더 쉽게 제가 확인하고 이해하고 가끔은 도울 수도 있게 된 것 같아요. 그래서 그런 정도의 어떤 기회들을 확보한 것 같아서 되게 감사하게 생각하고, 이후에도 그럴 기회가 있는 사람들이 보이면 적극적으로 하라고 하는 편이긴 해요. 기회가 되게 좋았던 것 같아요.

뱅크샐러드의 개발 문화가 궁금해요

개발씬에서뿐만 아니라 기업으로서 선진화된 문화를 갖고 있다는 생각을 많이 해요. 예를 들면 레벨 제도나 PERF, 문서화 등의 문화도 있고요. 커뮤니케이션과 관련된 굉장히 사소하게 보이는 기법들을 잘하고 있는 것 같아요. JIRA와 같은 툴도 잘 쓰는 것 같아요. 또, 엠플리튜드를 통해서 이벤트를 열심히 보고 그걸 바탕으로 새로운 실험을 제안하는 게 굉장히 좋은 문화라고 생각해요. 실제로 다른 회사로 이직한 분들의 얘기를 들어봐도 그런 부분은 뱅크샐러드가 잘하는 게 맞다라고 하실 정도니까 되게 잘하는 점이라고 생각합니다.

만약에 다음에 이직하게 된다면 어떤 곳일까요?

지금도 좀 고민이긴 한데 아예 한 번 엄청 대기업으로 가볼까 라는 생각도 있어요. 아니면 아예 진짜 이거보다 훨씬 작은 데로 가서 한 20명? 있는 회사로 가고, 20명이 적어도 200명은 되겠다는 판단이 되는 어떤 아이템을 가지고 있는 회사로 가볼까? 이 둘 중에 좀 고민이긴 해요. 만약에 대기업을 선택한다면 결국에는 제 네임벨류를 올리는 데 도움이 되기 때문일 것 같아요. 어디 출신이라고 설명해서 도움이 되는 그걸 무시 못 하는 부분이잖아요. 아니면 아예 제대로 내가 거의 창업자처럼 일할 수 있는 곳으로 가서 실제로 내가 만약에 창업하더라도 그걸 활용할 수 있는 조금 더 작은 회사로 가보는 것도 좋겠다고 생각해요.

개발이란?

개발하기 어려운 건 사용자가 쓰기도 어렵다고 생각해요. '코드가 너무 어려워지면 어려운 제품이다. 코드를 단순하게 만들 수 있는 제품이 좋은 제품이다' 라는 생각을 하거든요. 개발자가 코드를 짜다가 분기가 너무 많아지면 유저도 어떤 케이스가 나올지 몰라서 어려워할 수 있어요. 물론 항상 그런 건 아니죠. 분기를 잘 숨겨서 유저가 심리스 하게 경험할 수 있도록 만들 수 있겠지만, 사실 코드가 복잡해질 때 제품이 어려워지고 있는건 아닌지 한번 의심해볼 수 있는 좋은 단서인 것 같아요. 사실 조금 좀 과장해서 말하자면 지금 이 시대의 개발이라는 도구는 좀 마술처럼 느껴지는 것 같아요. 우리가 보기에 굉장히 단순한 글이고 논리의 집합인데 그 결과물은 누군가에겐 굉장히 신비로운 무엇인가잖아요. 이게 어떻게 동작하는지 알 수 없는, 사실 저희도 저희가 작성하는 코드 그 외에 다른 이면의 세계는 모르는 부분이 많잖아요. 많은 논리들의 합이 합쳐져서 마치 마술처럼 보이는 것 같아요. 우리 입장에서는 굉장히 고수준의 언어만으로 저수준의 모든 것들을 한 번에 다룰 수 있다는 점에서 감사한 부분도 많은 것 같아요. 시대를 잘 타고났다. 다른 영상에서는 이 시대에 슈퍼 히어로라 말하는데 히어로까지는 아니지만 적어도 어떤 능력자처럼 보일 수 있는 좋은 도구인 것 같아요.

일을 처리하는 스타일은 어떤가요?

저는 약간 심각하게 일하지 않는 편이에요. 이게 필요한 기능이라고 혹은 이걸 해야 한다고 가져오면 '진짜?' 이렇게 생각하는 편이에요. '진짜 그렇게 심각한 문제인가? 꼭 해야 해?' 일단 이렇게 생각해봐요. 그렇게 해서 약간 진짜 얘기를 해보고 심각한지 아닌지를 따지고, 계속 물어보는 거예요. 일하기 싫어한다는 뉘앙스가 느껴질 정도로 그렇게 생각하는 편인데, 그게 사실 왜 그렇냐면, 우리가 하려고 하는 A라는 일을 하려다 보면 너무 파생되는 일이 많다는 걸 알기 때문이에요. 그래서 사실 나는 A,B,C라는 일만 처리하면 될 줄 알았는데 A- 부터 A-가 Z까지 있는 경우가 있어요. A라는 일의 크기가 보이는 거 이상이라는 생각이 들어서, 아무리 사소한 거라도 이거 별로 지금 안 해도 될 것 같은데 이렇게 말씀드리는 편인 것 같아요. 우선은 빠르게 안정화된 제품을 빠르게 만드는 게 먼저라고 생각하고, 그 이후에 실험하는 거죠.

협업하기 좋은 동료란 어떤 동료라고 생각하시나요?

저는 솔직한 사람이 좋은 사람이라고 생각해요. 본인이 느끼는 바를 분명하게 말해주는 사람이 좋아요. 어떤 코드에 대해서 이해가 안 간다, 이 코드에 대해서 나는 이게 더 좋은 방법이라고 생각한다든지 그런 피드백 적으로 솔직하게 말해주는 사람이, 서로에게 너무 도움이 되기 때문에 저는 좋은 사람이라고 생각하고 그런 사람하고 계속 일하고 싶습니다.

회사에서 잘 성장하는 방법이 있다면 어떤 게 있을까요.

늘 생각하는 건데, 그때 얘기가 나온 걸 명문화시켜버리는 게 제일 좋아요. 이걸 하기로 했어? 그러면 그냥 정리해서 비동기로 던져놔. 그게 일 잘하는 방법이라고 생각하거든요. 지금 하던 일에 흐름을 안 끊기려면 여기서 들어온 이 옆차기를 일단은 오케이하고 던져놓고, 그 다음으로 쌓여 있는 스택을 하나씩 꺼내 가지고 일을 해야 해요. 사실 우리는 싱글 스레드거든요. 옆차기로 들어온 일을 해결하는 방법은 비동기로 다 던져두고 나중에 하나씩 해결하는 거라고 생각해요. 모두 알고 있지만 실제로 하기 위해서는 지라라는 도구를 쓰거나 바로 정리해서 모두가 볼 수 있도록 하는 게 진짜 잘하는 방법인 것 같아요. 특히나 협업이 많은 팀에서요. 개인이 모든 일을 끝낼 수 있는 팀에서는 이렇게까지 할 필요 없는데, 요청사항이 많을수록 이렇게 해야 한다고 생각해요.

앞으로 어떤 걸 하고 싶은가요

일을 취미로 하고 싶어요. 일을 돈벌이 수단으로 생각하고 싶지 않아요.

작업할 때 선호하는 장소

오피스

쉬는시간에 무엇을 하시나요

유튜브 많이 봐요

구애받지 않고 새로운 일을 하나 할 수 있다면?

책 쓰고 싶어요

요즘 가장 중요하게 생각하는것

사랑

취미는?

드라이브

개발자가 되고 싶은 사람들이나 이제 막 개발을 시작한 사람들에게 해주고 싶은 말이 있다면?

모든 사람에게 맞는 건 아니다.

공유하고 싶은것이 있나요?

열심히 글을 쓰고 있는 블로그!