* 이해의 편의를 위해 포지션명 ‘프론트엔드 엔지니어’는 ‘프론트엔드 개발자’로 지칭합니다.
안녕하세요. 뉴닉 프론트엔드 엔지니어 하코입니다. 뉴닉 뉴스레터 하단에서 독수리 이모지를 맡고 있어요 🦅. 뉴닉 프론트엔드 개발자는 제품셀과 개발팀에 소속되어 있습니다. 저는 올해 초 신규 앱을 런칭한 이후로 제품 MVP를 만들고 있어요.
며칠 전은 제가 입사한 지 딱 1주년이 되는 날이었어요. 앱 런칭을 준비하고, 앱을 런칭한 이후에는 기능 개선을 반복하느라 1년이 훌쩍 지나갔는데요. 오늘은 지난 1년 동안 뉴닉에서 프론트 엔지니어로 일하면서 어려웠던 점, 그리고 좋았던 시도 몇 가지를 소개해드리려고 합니다.
일하며 어려웠던 경험 😅
🕰️ 개발 작업 시간 추정하기
뉴닉 제품셀은 2주 단위로 스프린트(Sprint) 업무를 하고 있습니다. 스프린트는 업무 방식을 가리키는 용어로, 애자일 방법론에서 나온 개념이에요. 불확실한 시장에서 조직 리소스의 재고를 낮추고, 제품을 시장에 빠르게 출시하는 데 초점을 맞춘 업무 방식입니다.
제품셀에서 스프린트가 시작되면 ‘스프린트 계획’ 미팅을 하는데요. 이번 스프린트에 달성해야 할 목표를 정하고 직무자들이 할 작업을 계획해요. 그렇게 2주간 업무를 하고 나면 마지막 날에 ‘스프린트 회고’를 진행하는데요. 이번 스프린트에서 아쉬웠던 점과 배운 점 등을 돌아보고 다음 스프린트 때는 어떻게 일할지 얘기를 나눠요.
이전에는 스프린트 계획 미팅에서 감에 의존하여 내부·외부 배포 일정을 대략 추정했어요. 예를 들면:
PM·디자이너: “새로운 북마크 기능 시안 나왔어요!”
나(하코): ‘두 스크린에서 아이콘 추가 + 새로운 스크린에서 북마크 목록을 출력하는구나. 음… 이 정도면 다음주 화요일까지는 내부배포 가능할 것 같은데? 🤔’
하지만 실제로 그런 일은 잘 일어나지 않았다…
제 관점으로 봤을 땐, 당시 작업 예상 시간과 실제 소요 시간 사이에 차이가 발생한 이유는 크게 세 가지였던 것 같아요.
- 새로운 개발 스택(React Native)과 앱 환경에 관한 이해가 낮음
- 기획/디자인 변경이나 기술 이슈 등 예상치 못한 상황이 일어남
- 생각보다 구현의 복잡도와 작업해야 할 양이 큰 경우
작업 일정이 예상과 어긋나는 일이 몇 차례 반복되니 셀 작업 일정에도 문제가 생겼어요. 스스로도 부담이 컸고요.
↔️ 잦은 컨텍스트 스위칭
‘일주일 지난 코드는 남이 짠 코드다’라는 격언이 있습니다. 자신이 짠 코드를 시간이 지나고 다시 보면 매우 낯설게 느껴지는 마법…😇
개발 작업을 하다 보면 나의 외부/내부 상황으로 인해 작업이 끊기는 상황은 흔하게 벌어지는데요. 외부적인 상황에선 미팅이 대표적입니다. 작업을 하던 중 잠시 미팅을 다녀오면 작업 흐름이 뚝 끊기고 몰입도가 떨어질 때가 있어요.
작업 흐름이 끊기는 일은 또 있는데요. 개발을 하다 보면 더 개선하고 싶은 아이디어가 문득 떠오르거나 다른 문제를 발견할 때가 있어요. 이때 하던 작업을 멈추고 샛길로 빠지면 작업의 흐름이 끊기고 업무 우선순위를 잊을 수 있고요.
업무 복집도 혹은 개발자 성향에 따라 다르겠지만, 저는 멈춘 작업을 다시 동일한 호흡으로 이어가려면 두 가지가 필요했어요.
- 그 코드로 어떤 동작을 만들려고 했는지 재차 확인하고 (Why)
- 어디까지 왔는지 코드의 맥락을 살피기 (Where, How)
이런 시간 비용이 발생하는 상황이 쌓이다 보면 주의가 산만해지고, 작업에 몰입하기 어렵겠죠. 작업 효율과 결과물에도 영향이 있을 수 있고요.
몰입도가 낮아지는 것에 관해 문제의식을 느낀 이후로는 의식적으로 노력했던 것 같아요. 미팅이 많은 날에는 이 미팅에 내가 진짜 필요한지, 나에게 우선순위가 더 높은 업무는 없는지를 한 번 더 생각하게 됐어요. 작업할 때도 샛길로 빠지지 않도록 하고요. 예를 들어 A를 작업하다가 B, C 작업의 필요성을 느끼면 To-do 혹은 백로그 카드를 만들고 곧바로 하던 작업을 다시 이어갔어요.
사소하게 여겨질 수 있는 부분이지만, 멈췄던 작업을 빠르게 다시 시작하는 것의 중요성은 여러 번 강조해도 지나치지 않은 것 같아요.
💪🏻 제품이 성장하면서 겪은 어려움
작년에 지푸라기로 지은 움집 같던 앱의 화면이 현재 40개까지 늘어나면서 세미-초가집이 되었습니다. 움집이 세미-초가집이 되는 과정에서 프론트엔드 개발 업무의 효율에 대한 고민이 있었습니다.
- 다른 업무자가 짠 코드를 수정할 때 기능이 불안정해지는 문제
- 코드 스타일이 달라 코드를 이해하고 작성하는 데에 시간이 지나치게 많이 소요되는 문제
- 테스트 비용이 커지는 문제
이런 문제를 해결하기 위해 동료들과 코드 이해도를 개인·팀 차원에서 높일 수 있는 여러 가지 방법을 고민했습니다. 프로젝트에서 사용하는 코드 컨벤션을 맞추기도 했고, 코드의 맥락을 리뷰 단계에서 파악할 수 있도록 문서를 템플릿화했어요. 특히 테스트코드를 적극적으로 도입해 유닛테스트를 짜기 시작하면서 위와 같은 고민을 어느 정도 해결하기 시작했는데요. 앞으로도 동료들과 함께 잘 챙겨가야 할 과제라고 생각합니다.
🦅 시도했을 때 효과가 좋았던 것
👏 커뮤니케이션에 노력 한 스푼
코로나19 유행으로 많은 업계 동료들이 온라인으로 원격근무를 하고 있습니다. 저는 원격근무를 하면서 미팅할 때 동료들의 반응과 상황을 즉각 파악하는 데 어려움이 있었던 것 같아요. 온라인으로만 소통하는 기간이 길어지면서 가끔은 동료들과 단절된 기분이 들기도 했고요.
평소 사무실에 있을 땐 툭 가볍게 물어보기 쉬운 것도 온라인상으로는 망설이게 되더군요. 이런 어려움을 개발팀 리더에게 알렸고, 저도 동료들에게 다가가고자 했습니다. (단절감이 힘든 사람 나야 나-)
위 이미지는 예전에 개발팀 슬랙 채널에 올린 메시지입니다. 이때 동료들이 방에 들어와 참여해주었어요. (따땃한 동료들🧡)
이외에도 슬랙 곳곳에서 동료들끼리 잡담을 나누는 채널이 활성화되었어요.
사내 슬랙 채널 중 누구나! 언제든! 아무말을 주고받는 ‘아무말’ 채널이 있는데요. 이 채널 덕분에 웃는 일이 많았어요. 덕분에 어려운 시기에도 간간이 웃으며 잘 지나 보낸 것 같아요.
동료들과 주고받는 발전적 피드백 이외에도, 저는 시시때때로 고마움을 전하려고 노력하는 편이에요. 바쁘거나 힘든 시기에는 평소보다 마음의 여유가 나지 않을 때가 있는데요. 이럴 때일수록 서로에게 건네는 다정한 한마디가 다른 동료에게 힘이 될 수 있고, 반대로 저도 그런 다정한 한마디를 받으면 효능감이 크게 들었거든요.
👣 개발 일정 추산, 불확실성에서 Step by Step으로 멀어지기
개발하는 데 드는 시간을 실제와 가깝게 추정하는 건 여전히 어려운 부분입니다. 그러나 몇 가지 시도를 통해 좀 더 가까워지는 경험을 했어요.
- 요구 명세를 이해하는 데 시간 충분히 쓰기
- 디자인 시안을 구체적으로 뜯어보며 백엔드 동료와 개발 계획·일정 세우기
- 불확실성이 큰 작업을 먼저 하기
1번의 경우에 대해 조금 더 설명해 드리고 싶은데요. 여기에는 소통 과정이 포함되어 있습니다. 혼자 끙끙대며 해석해보려다가 시간을 허비했던 경험, 다들 한 번쯤은 있으시죠? 이런 문제를 해결하기 위해 저는 PM, 디자이너와 필요한 논의를 퀵하게 먼저 파악하는 습관을 들였어요. 물음표를 느낌표로 바꾼 뒤에 개발을 시작하면 중간 커뮤니케이션과 컨텍스트 스위칭을 훨씬 줄일 수 있다는 걸 배웠고요.
요구 명세를 이해하고 난 이후, 개발팀 동료들과 문서·시안을 놓고 개발 계획을 세워요. 이 단계에서 작업의 난이도와 크기의 윤곽이 좀 더 구체적으로 드러납니다. 그리고 문제가 생길지도 모르는 구현 이슈를 미리 발견하기도 해요. 그럼 파악한 내용을 토대로 팀 리더와 일정을 조율합니다.
불확실성이 큰 작업을 먼저 하는 이유는, 문제가 생겼을 때 좀 더 유연하게 대응할 수 있기 때문인데요. 사전에 문제가 발견되면 동료들에게 도움을 청해 해결할 수 있고, 리더에게 미리 알려서 일정을 조율할 수 있겠죠.
🐚 함께 고민하는 팀 분위기 만들기
저는 뉴닉에 입사하기 전에도 크지 않은 규모의 스타트업에서 개발을 해왔는데요. 작은 개발 조직에서 팀원들이 학습하기 좋은 환경일수록 퍼포먼스가 빠른 속도로 향상된다는 것을 경험을 통해 배웠습니다. 학습이 잘 일어나는 배경에는 팀원들끼리 서로 배운 것을 나누고 발전시키는 좋은 팀 문화가 있었고요.
그래서 새로운 조직에 입사하거나 새 동료가 합류하는 경우 함께 고민하는 분위기를 중요하게 생각하게 되었어요. ‘함께 고민하기’가 강한 강도로 일어나는 작업 중 하나가 바로 ‘페어 프로그래밍’ 입니다. 작년 2021년, 뉴닉에 처음 입사하고 다른 프론트엔드 개발자 동료 뉴와 어색-한 사이였을 때 페어 프로그래밍을 처음 시작했습니다. 당시에 어색하면 ‘페어 프로그래밍 함 합시다-’ 하는 버릇(?)이 있었어요. 밥 한번 먹자는 말 처럼 페어 한번 하자는 말을 무척 좋아합니다. 감정이 격해지는 상황도 물론 있지만, 함께 치열하게 고민하며 그 벽을 잘 넘으면 동지애가 싹트거든요.
일을 하면서 사람들은 각자 부족함을 느끼고 누군가의 도움을 필요로 합니다. 저는 동료가 뭔가 곤란해 보이면 ‘무슨 일 있나요?’ 하고 물어보고 싶어지는데요. 생각해보니 다른 동료들에 비해 제가 해온 경험이 적기 때문에 문제가 생겼을 때 누군가의 도움이 절실하게 필요로 한 적이 있었어요. 그때 동료들에게 고민을 얘기해 해결한 기억이 강한 인상으로 남았고, 신뢰가 두텁게 쌓인 것 같아요.
지금 제품셀과 개발팀 동료들은 업무하는 데 결정에 문턱이 생기거나 고민되는 점이 있으면 소통 채널에 자유롭게 공유하고요. 함께 고민하며 의견을 주고받아요.
+ 뉴닉의 회고 문화
뉴닉에는 활발히 회고하는 문화가 있어요. 작게는 미팅 단위, 크게는 전사 단위로 회고 미팅이 이루어져요. 회고를 진행하는 방법 또한 굉장히 다양한데요. 각 업무 상황과 프로젝트 성격에 적합하다고 생각되는 회고 방법론을 리더가 선택해 미팅을 주도합니다.
제품셀은 한 스프린트가 끝나면 셀장의 리딩에 따라 2주 동안 했던 업무를 회고해요. 이번 스프린트 목표를 얼마만큼 달성했는지, 사용자에게 어떤 영향이 있었는지 등에 대해 이야기를 나누며 동료들과 이해 수준을 맞추고요. 회고를 마무리하면서는 KPT(Keep, Problem, Try) 회고 방법론을 중심으로 좋았던 점과 문제점을 공유하고, 개선을 위한 액션 아이템을 정해요. 최근에 참여했던 회고 미팅에서는 앱스토어에서 심사를 반려하는 기준을 다시 짚어보기도 했고, 바쁘게 일하며 동료들과 서로 간과했던 부분을 인정하고 보완할 방법에 대해 얘기를 나눴어요.
요즘 다른 개발자들을 만나면 성장을 어떻게 정의하고 있는지 묻곤 하는데요. 어제 몰랐던 문제를 오늘 알았다면 한 걸음 나아간 거고, 어제의 고민이 오늘은 더 이상 고민이 아니라면 그 또한 성장하고 있는 증거라는 생각이 들어요. 그런 점에서 회고는 팀과 개인의 성장을 위해 꼭 필요한 요소가 아닐까 싶습니다.
여러분은 어떤 회고와 성장을 기대하시나요? 뉴닉은 앞으로도 새로운 동료들과 더 단단히 성장할 수 있기를 기대하고 있습니다.
이 글을 읽고 뉴닉 조직, 제품팀 혹은 개발팀에 대해 궁금한 점이 있다면 댓글로 달아주세요. 보내주신 피드백은 다음 글을 쓰는 데에 반영하겠습니다. (개인적인 고민은 hako@newneek.co로 메일을 보내주세요! 아는 한에서 성실히 답변드릴게요.)
채용합니다
저희 팀에 관심이 생기셨나요? 지금이 기회입니다. 뉴닉 제품팀에서 현재 채용을 진행 중입니다. 뉴닉 제품팀에서 함께 성장하고 싶은 분이라면 주저하지 말고 지원해주세요!
