들어가기 전에

안녕하세요! 이 글은 패스트캠퍼스에서 진행하는 2024년 3월 캠프콘: 프론트엔드 편 강연을 듣고 해당 내용을 요약 정리하고 후기를 작성한 글입니다. 발표를 들으며 제가 느끼기에 중요한 내용이나 계속 기억하고 싶은 내용을 메모하여 벨로그 게시물로 남기게 되었고, 이 과정에서 제가 추후에 읽었을 때 이해하기 쉽도록 저의 해석이나 추가 설명을 덧붙인 부분도 있기에 발표자 님이 의도하신 워딩이나 맥락과 완벽하게 일치하지 않을 수 있습니다. 만약 오류나 잘못된 부분을 발견하신다면 댓글로 제보해주시면 감사하겠습니다. 🤧

일정 : 2024.03.26(화) 19:00 ~ 21:30 (온라인)
발표자 : 하조은 님 (현 당근마켓 소프트웨어 엔지니어-FE)

함께 일하고 싶은 개발자가 되기 위한 7가지 습관

0. 소개

1. M사 (50인 규모의 스타트업, 풀스택)
2. B사 (200인+ 규모의 금융 회사, 프론트엔드)
3. 당근마켓 (300인+ 규모의 서비스 회사, 프론트엔드)

발표 시작에 앞서 조은 님께서 거쳐온 회사를 소개해주셨다. (**실례가 될 수 있어 이전 직장은 이니셜 처리했습니다.)

3년 차에 첫 번째 이직을 하시고 풀스택에서 프론트엔드 개발자로 전향하며 팀에서 매니저 역할과 면접관 경험을 하셨고, 6년 차 이후 현재 재직 중이신 당근마켓으로 다시 이직을 하며 현재까지도 실무자로 면접에 참여하신다고 한다.

즉 조은 님께서는 개발자이면서 면접관으로 일 했던 경험을 하셨고, 여전히 하고 계신다.
그렇다면 면접관은 어떤 사람이고, 어떤 일을 할까?

• 함께 일 하고 싶은 개발자를 찾는 사람
• 채용 시장에 마음에 드는 사람이 나오면 먼저 연락하기도 한다. (커피챗 or 면접 제안)

오늘의 발표는 조은 님께서 면접관으로 계시며 느꼈던,
함께 일 하고 싶은 개발자가 되는 7가지 습관에 대한 내용이다.

이는 함께 일 하고 싶은 개발자의 7가지 특징이라고 할 수도 있다.
더불어 조은 님의 개인적 견해이며, 정답은 아니라는 점을 말씀하시며 발표가 시작됐다.

1. 작은 일부터 시작하기

분할 정복 하는 사람

첫 회사에 간다면 낯선 환경과 낯선 코드를 마주하는 상황에 처한다.
이는 재직자도 피할 수 없으며, 이직이나 팀 변경 혹은 새 프로젝트를 시작할 때에도 동일하다.
실제로 기업에서는 팀 변경도 잦고 프로젝트가 기획되었다 엎어지는 일도 다반사이며, 누군가 작업하던 레거시 코드에 투입되어 기여해야 하는 상황도 빈번하다.

이러한 상황에서 어떤 개발자가 좋을까?
👉 누구나 할 수 있지만 아무도 하지 않은 일부터 시작하는 사람이 좋다.

(1) 관찰하기

• "프로그램의 구조는 그것을 제작하는 조직의 구조를 반영한다." - 콘웨이의 법칙 (Conway's law)
• 조직을 살피고 코드를 살펴보자.

가령 이 조직은 어떤 분위기인지를 먼저 살피는 것이 코드와 프로그램을 이해하는데 도움이 될 수 있다.

(2) 질문하기

• 이유가 없는 코드는 없다. 그것이 느낌표 하나일지라도. 물어보고, 질문하자.
• 개선 방법을 제시하고 직접 해결해보자.

이 때 개선 방법은 누구나 할 수 있는 일이면 좋다. 간단한 번역이나 주석 한 줄일지라도 실제 기업에서는 당장 나에게 할당된 업무를 처리하기 바빠 쉬운 일도 의외로 하지 못하는 경우가 많다. 작은 일이라도 내가 할 수 있다고 판단되면 시도하자.

(3) 기여하기

• 작게 시작하고, 빠르게 공유하자 ➠ 옳은 방향으로 가고 있는지 점검하는 것 ➠ 리뷰어를 배려하는 일

예를 들어 코드의 PR 단위를 작은 단위로 진행한다면 리뷰어가 코드를 이해하기 쉽다.
반대의 경우는 이해가 어려울 뿐더러 좋은 리뷰를 받기 어렵다.
작은 일을 하나씩 하다보면 코드에 대한 이해가 높아지고 자신감도 충전된다.

"개발은 분할 정복이다. 작은 일부터 하나씩 해결해가자."

2. 의미를 확인하고 질문하기

제품에 대해 고민하는 사람

(1) 기업에서 만들고 있는 제품을 이해하고 있는 개발자

이런 개발자는 같이 일하고 싶을 가능성이 높다.
동료 개발자 뿐 아니라 기획이나 디자인 등 타 직군에서도 같이 일 하고 싶어한다.

(2) 제품에 대해 질문하고 고민하자

• 타켓 유저는 누구인가?
• 해당 제품으로 어떤 반응을 얻고자 하는가?
• 반응을 얻기 위해서는 어떤 기능을 제공해야 하는가?
• 각 기능 중 가장 효과가 좋은 것은 무엇인가?

제품의 타겟 유저는 관심있는 기업의 언론 홍보 내용이나 대표 홈페이지를 통해 쉽게 접근할 수 있다. 쿠팡과 당근의 초기 타켓 유저는 '육아를 하는 어머니들'이었다. 가까운 이웃으로부터 쉽고 빠르게 긍정적인 반응을 얻고자 했다.

가령 쿠팡의 와우회원 서비스에서는 어떤 가치를 제공해야 하는지, 당근마켓에서는 왜 지역 정보를 계속해서 노출하는지를 생각해보자. 그런 생각을 통해 제품이 제공해야 할 기능을 도출할 수 있다.

이러한 고민을 해본 사람이라면 개발자 이상의 실력을 보여줄 수 있다. 더 나아가 1. 고민한 내용을 정리하여 팀에 공유하고 문서로 남기고, 2. 식사 시간 등을 통해 자신의 생각을 나누고 제품에 대해 함께 고민해보자 단순히 업무 시간에만 일을 하고 마는 것이 아니라 일상의 작은 틈을 통해 제품을 생각하고 고민할 때 더욱 성장할 수 있을 것이다.

3. 두괄식으로 말하기

시간을 벌어주는 사람

• 회의는 개발을 비롯한 집중 시간을 빼앗는다.
• 회의는 이해 범주가 늘어날수록 회의도 많아진다.
• 그러나 회의는 의견 합치를 이끌어내는 중요 수단이다.
• 회의는 적고 짧게 하는 것이 중요하며, 이는 개발 시간을 확보하게 해준다.

그러기 위해서는 어떻게 해야 할까?

(1) 두괄식으로 말하자

• 핵심을 먼저 말하여 회의 시간을 단축하자.
• 메신저의 경우에도 메세지를 효과적으로 전달하자.
• 장황하게 설명하면 회의가 생긴다.

👩🏻‍💻: 이거는 이렇고... 저거는 저래서... 이거는 이렇게 해서 저렇게 이렇게... 저거는 저렇게...
😧 : "잠깐 시간 괜찮으세요? 요점이 무엇인가요?"

(2) 상대방은 내가 하는 일에 관심이 없고 잘 모른다는 것을 기억하자

• 듣는 이가 누구인지 배려하여 이야기하면 시간을 아낄 수 있다.

가령 한 개발자가 기획 파트와 프로젝트에 대해 이야기 할 때, 개발 용어를 난무하며 설명한다면 기획자는 이해하기 위해 질문이 이어지고, 이어지고, 이어지고... 결국 시간이 늘어나게 된다.

관심을 얻고 자신이 하는 일을 설명하는 것이 가장 어려운 법이지만, 최대한 듣는 사람이 누구인지를 배려하여 눈높이에 맞춰 이야기 하자.

4. 기계처럼 단순하게 일하기

복잡한 상황에서도 흔들리지 않는 사람

회사에서 쏟아지는 개발 업무를 침착하게 해결하려면 어떻게 해야 할까?
업무를 관리하는 본인만의 기준이 필요하다.

조은 님께서 업무를 관리하는 방법 🗒

• Main Queue : 계획한 일을 처리한다. 스프린트/업무 주기에 맞는 일을 데드라인에 맞춰 처리.
• Side Queue : 시급한 일을 처리한다. 코드리뷰 혹은 hotfix 처리 등.
• Backlog Queue : 계획하지 않았거나 시급하지 않은 일을 처리한다.

위와 같이 업무 기준을 나눴을 경우, 함께 일 하는 동료들과 업무 우선순위에 대해 이야기 할 때에도 어렵지 않게 대처할 수 있다.

🤔 : "00님, A업무를 오늘까지 완료해주실 수 있나요?"
👩🏻‍💻 : 급한 B업무가 오늘까지 처리되어야 해서, A업무는 그 이후에 진행하겠습니다.

추가적으로 Jira와 같은 프로젝트 매니지먼트 도구를 활용해보자.

물론 팀 마다 일정을 관리해주시는 분이 계시기도 하지만 업무 일정 관리를 스스로 할 줄 아는 개발자는 가치가 크다. 업무의 유형을 나누고, 우선순위를 정하여 집중해서 일 하자.

5. 완벽보다 완성을 목표로 하기

결단하는 사람

(1) 포기가 필요한 순간

예를 들어, 코드 리뷰를 요청드려아 할 때에는 아래의 것들을 생각해볼 수 있다.

• 나의 작업이 무엇에 집중하고 있는 브랜치인가?
• 목적에 맞는 PR인가?
• 동료가 이해하기 쉬운 작업인가?

또 서비스를 개발하는 때라면 이런 것들도 생각해볼 수 있다.

• 핵심 사용자 경험(UX)은 무엇인가?
• 가장 먼저 만들어야 하는 경험은 무엇인가?
• 당장 포기할 수 있는 건 무엇인가?

(2) 포기한다는 것은?

결국 포기한다는 것은 선택과 집중을 한다는 것이다.
집중 할 것을 정한 사람만이 할 수 있는 멋진 선택이 '포기'다

경력자는 무엇을 포기해야 하는지 아는 사람이며, 완벽보다 중요한 완성을 위해 결단하는 사람이다.

6. 큰 그림 보기

멀리 보는 사람

(1) 높이 나는 새가 멀리 본다

• 멀리 볼 줄 아는 개발자가 오래간다.
• 크게 볼 줄 아는 개발자가 채용된다.

(2) 코드보다 중요한 것은?

• 개발자의 건강
• 서비스의 성공

(3) 서비스 개발은?

• 단거리 스프린트가 아닌 장거리 마라톤이다.
• 코드만으로 해결할 수 없다.
• 시니어 개발자들은 "코드를 안 짜고 문제를 해결하는 사람이 최고"라고 말한다 ➠ 뛰어난 역량

(4) 관계를 쌓는 것 또한 큰 그림이며 역량

• 회사 내 여러 사람에게 관심을 가지자.
• 회사를 잘 아는 사람이 존중 받을 수 있고, 인정 받을 수 있다.
• 개발에만 매몰되지 말자.

7. 코드와 자신을 분리하기

코드 밖에 있는 사람

(1) 코드를 사랑하지 마세요

내가 작성한 코드를 갑자기 누군가 와서 뜯어고친다면 당연히 불편할 수 있다.
그러나 이것을 헤쳐나가는 것이 개발자의 숙명임을...
코드는 내 것이 아닌 회사의 자산이며, 나의 자아와 동일시해선 안 된다.

(2) 코드 퀄리티와 제품 생산 시간의 균형

제한된 시간 내에서 수준 높은 코드를 작성하는 것이 큰 역량이다.
사전 과제를 n일 이내로 해내라고 요구하는 것도 이와 같은 이유다.

(3) 코드 작성만이 개발자의 일이 아니다

• 개발자가 할 수 있는 일은 굉장히 많다.
• 요구사항 분석, 설계, 구현, 테스트, 배포, 장애 대응 등...

요구사항을 분석과 설계 단계에서는 여러 분야의 사람과 대화하며 의견을 조율하고, 프로젝트 전반에 대한 계획을 세운다. 코드는 잘 작성하지만 타 분야의 동료들과 대화가 되지 않는 개발자는 함께 일할 수 없을 것이다.

구현이 끝나고 기능을 테스트 할 때는 스스로가 그 서비스의 Big Fan이 되어 실제로 사용해보고, 이 경험을 바탕으로 기능을 보완하거나 다른 아이디어를 도출해낼 수 있다.

배포 후 서비스가 정상적으로 돌아가는지도 늘 확인해야 한다. 배포를 잊고 있다가 누군가 와서 내가 담당했던 부분에 대해 이야기 한다면? 그제서야 배포가 되었구나 인지할 것인가? 사용자에게 소비될 예정인 나의 코드에 지속적으로 관심을 가지자.

장애 대응을 담당하는 온 콜 주간이라면 서비스 장애에 대해 리포팅하고, 담당자를 찾아 연락해야 한다. 이 업무 또한 코드만 잘 짠다고 해서 할 수 있는 일은 아니다.

코드 작성은 언제나 대체될 수 있는 일이다.
그러므로 코드 외 개발자의 일, 코드 외 할 수 있는 일을 더 많이 발굴하자.
그리고 물론 코드도 잘 작성해야 한다.

후기

이전의 나

커리어리에서 가끔 개발자들의 이야기를 읽으며 조은 님을 알고 있었다. 그래서 이번 캠프콘 연사자 중 조은 님이 계시다는 것을 보고 더 기쁘고 관심이 갔다. 그리고 역시나 좋은 내용이었고 많은 도움이 되었다.

작년 10월 부트캠프를 수료한 이후 프론트엔드 개발자로 취업 준비를 시작하며 내 나름의 시선으로 이력서와 포트폴리오를 정리하고, 여러 기업에 지원서를 넣으며 기업들이 나를 알아주기를 바래왔다. 그러나 얼어있는 채용 시장에서 겨우 7개월 간의 부트캠프 경험만을 가진 나는 그저 그런, 흔한, 눈에 띄지 않는 개발자였다고 생각한다. 그리고 그 이유는 조은 님께서 말씀하신 7가지 습관을 내가 가지고 있지 않기 때문이다. 혹은 가지고 있더라도 내가 깨닫지 못했거나 그 모습을 서류나 면접에서 보여주지 못한 탓일지도 모른다.

앞으로의 나

조은 님의 강연을 듣고 개발자로서 앞으로의 내 모습을 보다 입체적으로 상상하게 됐다.

이 전까지는 막연하게 내가 원하는 어느 기업에 합격해서, 동료들과 함께 개발을 하고, 서비스에 기여하고, 이름도 알리고.. 내 실력으로 또 다른 나(비전공자로서 개발을 준비하는 사람들이라던지)에게 도움을 주고 등등 단편적인 부분에서만 생각했지만

강연 이후로는 가까운 미래에 어떤 주니어가 될 것인지, 어떤 시니어가 될 것인지, 어떤 리더가 될 것인지, 그러기 위해서는 어떤 노력을 해야 하는지, 그 중 가장 먼저 할 수 있는 것이 무엇인지와 같은 것들을 계속 생각하게 됐다. 그리고 그러다보면 나도 모르게 매력적으로 보이는, 함께 일 하고 싶은 개발자가 되어있지 않을까 하는 기대도 해본다.

물론 단 시간안에 저 질문들에 대한 해답을 전부 내놨다는 건 아니다. 스스로에게 질문을 던져놓고 아직 답하지 못한 것도 많다. 그래도 중요한 것은 개발자라는 직업인으로서만이 아닌, 그냥 개발 하는 사람 자체로서 다른 방향에서 사고해볼 수 있었다는 것만으로도 큰 수확이 되었다고 생각한다.

먼 미래이지만 나도 언젠가 조은 님처럼 누군가에게 방향을 설정해주고 도움이 되는 개발자이자, 시니어, 리더, 멘토가 되어있기를! 그리고 그러기 위해서 부단히 노력해보아야겠다.