나 지금 잘하고 있는 걸까? 더 열심히 공부해야 하지 않을까? 어떻게 하면 빠르게 성장할 수 있을까? 얼마나 오래 일할 수 있을까? 디자이너에서 개발자로 전직을 결심한 뒤, 뉴스 기사와 SNS를 통해 듣는 IT업계 개발자들의 소식은 빠르게 걱정으로 변했다. 실제로 내 주변에 있는 주니어 개발자는 어떤 과정을 거쳤고, 어떤 고민을 하고 있는지 듣고 싶었다. TIL, 자격증 취득, 개발 스터디, 사이드 프로젝트, 기술 글쓰기 등 다양한 방법으로 꾸준히 공부하고 있는 백엔드 개발자 K님을 만나서 묻기로 했다.
학교에서는 HTML부터 안드로이드 앱 개발 등을 배우고 연합동아리에서는 백엔드 개발을 배웠는데 프론트엔드보다는 백엔드 개발이 저한테 더 잘 맞는 느낌이었어요. 기획 내용에 따라 유저들에게 어떤 데이터를 제공해야 하는지, 데이터를 제공하기 위해 어떤 논리를 구현해야 하는지 고민하는 게 더 재미있었어요. 그래서 백엔드 개발을 하게 된 것 같아요.
포트폴리오를 준비했는데 혼자 만든 프로젝트는 없었던 것 같아요. 다른 사람들과 같이 한 작업이 많았어요. 연합동아리에서도 그랬고, 외부 교육에서도 그랬고 기획자, 디자이너, 프론트엔드 개발자, 백엔드 개발자가 한 팀으로 모여서 협업했거든요. 그때 만든 서비스에서 돌아갔던 코드를 제 Github에 올렸어요.
코딩 테스트는 온라인 강의를 들으면서 준비했어요. 알고리즘 이론을 학교에서 배웠지만, 학교에서 배워서 알게 된 것보다 모르는 게 더 많아요. 온라인 강의로 이론을 다시 공부하고 알고리즘 문제풀이 사이트에서 문제풀이 감각을 익혔어요.
처음에는 제가 혼자 풀 수 있을 때까지 매달렸어요. 그런데 실제로 시험이나 코딩 테스트에서는 정해진 시간 안에 문제를 풀어야 하니까 그렇게 할 수 없어요. 그래서 정해진 시간이 지나면 다른 사람의 답안을 통해서 해결법을 빠르게 습득하는 게 나을 것 같다고 판단해서 전자에서 후자로 공부하는 방법을 바꾸었어요.
온라인 코딩 테스트를 보진 않았고, 면접에서 화이트보드에 손코딩을 했어요. 그때 특정 언어에 한정해서 코드를 작성하는 게 아니라, 의사코드¹로 어느 개발자든 대충은 알아볼 수 있을 정도의 코드를 짜보라고 해서 그렇게 했던 것 같아요.
저는 광고 매매 서비스를 담당하고 있어요. 도메인은 광고를 구매하는 유저, 광고 구매를 대행하는 대행사, 광고 상품을 관리하는 어드민까지 세 가지로 나눌 수 있어요. 광고를 영업하는 부서의 요구사항을 PO가 구체화하면, 구체화된 내용을 토대로 개발자가 설계, 개발, 배포를 하는 과정으로 일하고 있습니다.
아무래도 유저들이 유료 결제를 해서 광고를 구매하는 서비스이다 보니까 돈과 관련된 데이터의 정합성을 유지하는 게 굉장히 중요한 일이에요. 사용자가 유료 결제를 통해서 충전한 유료 포인트, 영업본부에서 판촉을 위해서 무료로 제공하는 포인트 등 돈의 종류도 다양해요. 데이터의 정합성이 맞지 않으면 사용자의 경험도 저하시킬 뿐만 아니라 매출에도 타격을 입히기 때문에 요구사항이 구체적으로 어떤 건지 잘 알고 개발에 착수해야 하며 단위 테스트를 꼭 병행해야 해요.
Github를 이용하고 있어요. 코드리뷰도 업무의 일부입니다. 백엔드 개발자들끼리 코드리뷰를 주고받는데, 코드를 리뷰해주는 개발자를 리뷰어라고 하고, PR(Pull Request)를 올린 개발자를 리뷰이라고 할게요. 리뷰어가 “이렇게 변경하는 건 어떨까요?” “이렇게 하면 이런 문제가 있지 않을까요?”라고 의견을 제시합니다. 리뷰이는 리뷰어의 의견이 합리적이라고 판단이 되면 코드를 수정하고, 합리적이지 않다고 판단이 되면 수정하지 않는 사유를 제시해요. 물론 사유는 리뷰어가 보기에도 정당해야 하고요. 이런 피드백을 주고받은 뒤 리뷰어가 QA단계로 넘어가도 좋겠다고 판단했을 때 Approve(승인)을 해줍니다. 승인해준 리뷰어들이 2명 이상일 때 리뷰이는 그 PR을 닫고 QA 단계로 넘길 수 있어요.
코드리뷰는 자주 할수록 좋은 것이라고 생각해요. 왜냐하면 피드백을 많이 받을수록 새로운 의견, 더 나은 의견을 얻을 수 있고 예상치 못한 버그나 장애를 방지할 수도 있으니까요.
네. 그런데 본인이 보기에 코드가 지저분하지만 버그가 있는 건 아니기 때문에 승인해주는 개발자도 있고, ‘이 코드 너무 지저분해. 이렇게 다 바꿨으면 좋겠어.’라는 스탠스를 가지고 정말 세세하게 바꿔 달라고 요청하는 개발자도 있어요. 그리고 그 리뷰를 받아들이는 정도도 리뷰이마다 달라요. 수용적인 태도로 리뷰어의 피드백을 다 받아주는 개발자가 있는가 하면, 웬만하면 리뷰어의 피드백을 받아들이지 않는 개발자도 있어요. 개인적으로는 두 가지 태도 중 하나에 치우치지 않고 본인이 어떤 의도를 가지고 코드를 작성했는지에 따라 태도를 바꿀 수 있어야 한다고 생각해요.
잘 모르겠어요. 직원의 성장을 최우선으로 하는 회사는 손에 꼽히는 것 같아요. 예전에는 성장하지 못하는 것에 스트레스를 많이 받았어요. 예를 들어 5년 차가 돼서 구직시장에 뛰어들었을 때 ‘5년 차면 이 정도는 알아야 한다’ 같이 시장에서 요구하는 수준이 있잖아요. 제가 그런 수준에 도달하지 못할까 봐 걱정했고 그 수준을 재직 중인 회사에서 반드시 만들어야 한다는 강박도 있었어요. 하지만 이제는 내 성장은 내가 알아서 챙겨야겠다는 생각이에요. 결론을 말하자면, 성장하고 있는지 확신은 하지 않으나 내가 알아서 챙겨야겠다는 생각은 하고 있습니다.
공부하면서 부족함을 느껴요. 새로운 걸 배우면서 얻는 것도 있지만, ‘아 이걸 이제야 알았구나’ 하는 느낌 있잖아요. 그렇기 때문에 멈추지 않고 길게 해야 하는 거고요. 단기간에 공부해서 ‘나, 이만큼 이뤘어!’ 하고 멈추는 게 아니라, 꾸준히 조금씩 하는 습관이 있어야 해요. 저는 여가시간에 공부에만 매진하지 않아요. 하지만 그렇게 열정적이지 않아도, 가끔 쉬는 날이 있어도, 뭔가를 조금씩 배우는 습관을 지니고 있다는 게 중요한 것 같아요. 제가 하고 있는 것들이 지금은 미미해 보이겠지만, 나중에 뒤처지지는 않은 개발자가 되게끔 만들어 주겠죠?
자기 계발에 열정적이지는 않더라도 멈추지 않는 개발자요.
회사의 타이틀이 없어져도 개발자로서의 가치를 유지해주는 경험을 얻고 싶어요. 다른 회사로 이직을 하든 1인 개발자로 프리랜서를 하든, 어느 위치에서 일을 하든 간에 나만의 일하는 방식이 있고 기본이 잘 갖춰진 개발자가 되고 싶어요. 회사에서 거창한 프로젝트에 참여하거나 최신 트렌드 기술을 써보는 걸 원하는 게 아니에요. 일을 하는 데 필요한 기본적인 지식을 실무를 통해서 접하고 배운 걸 다시 적용함으로써 체화되는 경험을 회사에서 얻고 싶어요. 그러려면 평소에 하던 대로 일하면 안 돼요. 의문을 가져야 해요. 개발을 하다 보면 자주 접했지만 제대로 알지는 못하고 도구를 쓰는 경우가 많거든요. ‘이건 뭐지?’ ‘왜 이렇게 쓰지?’라는 의문을 품고, 찾아보고, 배운 것을 기록하는 습관이 몸에 배어야 해요.
제가 구직시장에서 요구하는 수준에 도달했는지 잘 모르겠다고 말씀드렸었죠? 제가 다른 사람들과 커뮤니케이션하는 스킬과 일을 효율적으로 하는 노하우를 가지고 있는지 확신이 없어요. 그분도 지금의 저와 비슷한 연차나 나이, 연령대를 지나왔겠죠? 그 시기에 저랑 같은 고민을 했는지가 궁금하고 어떤 방법으로 극복했는지, 그리고 지금은 그런 걱정이 없는지 묻고 싶습니다.
백엔드 개발 부서의 경우, 작년까지는 10%가 여성, 90%가 남성 개발자였어요. 최근에는 좀 늘었는데요, 회사에 새로 들어오신 분 중에 여성 개발자분들이 꽤 있어요. 그렇다고 성비가 드라마틱하게 나아지지는 않았어요.
당시에 직장 안에서나 밖에서나 여성 개발자들을 찾기가 되게 어려운 상황이었고요. 특히 저랑 같은 고민을 갖고 그 고민을 해소하기 위해서 여러 시도를 하는 분들을 찾기란 더 어려웠어요. 좀 신기했던 게, 개발자 신입 포지션으로 구직하고 있는 여성들은 굉장히 많이 알고 있었는데 실제로 현직에 있는 여성들은 찾기가 어려웠어요. 그래서 외로움을 많이 느끼고 있다가, 2018년 겨울에 개발자 포지션으로 구직 중인 여성들이 모여있는 카톡방을 통해서 헤이조이스 오프라인 행사가 있는 걸 알게 됐고 그 행사에 참석했어요. 행사에 네트워킹 시간이 있었는데 그때 만난 분을 통해 테크페미에 가입하게 됐어요. 그리고 테크페미 회원 중 한 분이 L모임에서 회원 모집을 하고 있다고 해서 L모임에도 가입했습니다.
테크페미에는 워낙에 회원 수가 많다 보니까 개발자분들도 많이 계세요. 백엔드 개발자분들도 많이 계시는 걸로 알고 있어요. 매일 알고리즘 문제 푸는 스터디 그룹도 있고. 느슨한 연대라고 해야 할까요? ‘같은 여성 개발자니까 우리는 항상 교류하고 매일 서로 도와준다!’ 이런 건 아니지만 혼자 하기 외로우니까 같이 했으면 좋겠다는 의미에서 함께 공부하는, 그런 느슨한 연대가 느껴져서 괜찮은 것 같아요. 조금 더 타이트한 연대가 생겨도 좋을 것 같고요.
연결이 됐으면 좋겠어요. 코로나19만 아니었으면 모여서 모각코도 하고, 서로 공부하는 것들 공유도 하고, 생산적인 활동들을 같이 할 텐데 정말 아쉬워요. 오프라인에서 만날 수 없으니 온라인으로라도 연대했으면 좋겠습니다. 만나고 싶습니다.
인터뷰어 후기
미래를 위해 지금을 희생하고 있다고 생각하면 억울해진다. 얼른 나아가고 싶은 마음에 숨 쉴 틈 없이 달렸다면 쓰러지는 게 자연스럽다. 지금 살려면 숨은 지금 쉬어야 하는 거니까. 자신만의 페이스를 찾고 때로는 멈추는 것이 오히려 이 길을 멈추지 않겠다는 의지일 수 있겠다고 K님을 보며 생각했다. 한 회사의 직장인이 아닌 직업인으로서 개발자로 오래 걷기 위해서, 오늘도 담담히 문제를 마주하고 더 나은 방법을 고민하고 있을 K님을 응원한다.
테크페미 김소희
¹의사코드(슈도코드, pseudocode)는 프로그램을 작성할 때 각 모듈이 작동하는 논리를 표현하기 위한 언어이다. 특정 프로그래밍 언어의 문법에 따라 쓰인 것이 아니라, 일반적인 언어로 코드를 흉내 내어 알고리즘을 써놓은 코드를 말한다.
출처: https://ko.wikipedia.org/wiki/