<div id="readability-page-1" class="page"><div><div><h2 id="258f" data-testid="storyTitle">우리만의 일하는 이야기 : 설계부터 개발까지</h2><div><a rel="noopener follow" href="/@ulim130_37270?source=post_page-----534ff4ae10a4--------------------------------"><div aria-hidden="false"><p><img alt="Yulim Yang" src="https://miro.medium.com/v2/resize:fill:88:88/1*g3N3PCatyv7qe-G42EOspA.jpeg" width="44" height="44" loading="lazy" data-testid="authorPhoto"></p></div></a><a href="https://medium.com/29cm?source=post_page-----534ff4ae10a4--------------------------------" rel="noopener follow"><div aria-hidden="false"><p><img alt="29CM TEAM" src="https://miro.medium.com/v2/resize:fill:48:48/1*TP1aY6ZJaPSPs3fKA6sYKA.png" width="24" height="24" loading="lazy" data-testid="publicationPhoto"></p></div></a></div></div><h2 id="d378">소개</h2><p id="b3a4">안녕하세요. <br>29CM 배송경험팀 (구 배송경험스쿼드) 백엔드 개발자 양유림입니다.</p><p id="cab2">여러분들은 누구와, 어디서, 어떻게 일하고 계신가요?</p><figure></figure><p id="bb66">저는 배송경험팀에서 백엔드 개발자로써 1년의 시간을 보냈습니다.<br>이 글에서는 그 시간들 속에서 차근히 쌓아올려진 우리만의 일하는 이야기를 들려드리려합니다.</p><p id="937a">공적이면서도 꽤나 사적인 이야기가 될 것 같아요.<br>남의 일기장을 훔쳐본다는 마음으로 가볍게 즐겨주시길 부탁드립니다.</p><p id="1240">( 이 이야기는 29CM 전체가 아닌, 배송경험팀 백엔드 개발자들의 이야기임을 명확히 밝힙니다! )</p><h2 id="e349">Part 1. 설계</h2><h2 id="ea8b">오프라인 끝장토론</h2><p id="2416">무신사는 재택근무 문화를 수용하고 있지만, 소프트웨어 설계 과정 만큼은 오프라인으로 모여서 진행하고있습니다. 함께 모여 직접 손으로 그리고 아이디어를 공유하며 상호작용하는 것은 서로의 의견을 더 잘 이해할 수 있어 도움이 됩니다.</p><figure></figure><p id="5553">이 과정에서는 단순히 설계를 다루는 것뿐만 아니라, 해당 작업을 진행할 때 사용할 용어나 코드에 적용할 Prefix 등을 함께 정의합니다.</p><p id="d732">물론 이러한 과정은 시간이 꽤나 소요될 수 있습니다.<br>하지만 이 작업이 충분히 견고하게 이루어지면, 이후의 실질적인 개발 시간과 코드 리뷰 시간을 줄일 수 있어요.</p><p id="b4d1">우리는 이러한 시간을 이보 전진을 위한 일보 후퇴로 느끼며, 이를 ‘끝장토론’이라고 부르기도 합니다.</p><h2 id="57e9">스켈레톤 클래스로 설계 리뷰 받기</h2><p id="3e23">개발 디자인을 완료하고 실질적인 개발이 시작되기 전, 우리에겐 추가적인 단계가 필요합니다.</p><p id="dbc7">바로 스켈레톤 클래스를 통한 설계 리뷰입니다.</p><p id="789c">스켈레톤 클래스는 기본적인 구조나 뼈대를 제공하는 클래스를 의미하는데, 내부는 비어있는 형태로 클래스를 작성하고 실질적인 구현은 주석으로 가정하여 표현합니다.</p><figure></figure><p id="5933">이 과정은 다음과 같은 목적을 가지고 있습니다.</p><ol><li id="577e">전체적인 설계 흐름 파악</li><li id="200c">네이밍과 Prefix 등의 정확성 확인</li><li id="d6d7">코드 스타일의 일관성 검토</li><li id="ca0b">다음 작업 예고</li></ol><p id="9ba5">이는 리뷰이를 돕기 위한 과정처럼 보이지만, 사실은 리뷰어를 돕기 위한 과정입니다. 스켈레톤 클래스를 통해 해당 기능의 전반적인 흐름을 이해하게 되면 추후 코드 리뷰 시 코드를 이해하는 과정이 훨씬 용이해집니다.</p><h2 id="0b2e">Part 2. 개발</h2><h2 id="b778">작소고 ( 작고 소중한 고민 공유 )</h2><p id="5ec7">함께 설계를 진행해도, 스켈레톤 클래스 리뷰를 받아도, 막상 구현이 시작되고 나면 고민되는 지점들이 생기기 마련입니다.<br>우리에게는 이런 고민을 자유롭게 나눌 수 있는 도구가 있습니다.</p><p id="4f0e">바로 “작소고 요청”입니다.</p><p id="cbd5">작고 소중한 고민을 공유하는 것을 의미하며, 누구나 자신의 이야기를 털어놓을 수 있는 시간입니다.</p><p id="ef6e">누구나 언제든 “저 작소고하고싶습니다!” 라고 외치면, 우리는 하던 일을 잠시 멈추고 모여 서로의 고민을 나눌 수 있습니다. ( 물론 참여가 필수는 아닙니다. )</p><figure></figure><p id="0a45">이렇게 고민을 나누다보면 종종 스스로 깨달음을 얻고 문제를 해결하는 경우가 많습니다.</p><p id="80e5">이런 과정을 우리는 “고무오리 디버깅”이라고 부르는데요. 개발자들이 코드의 버그를 해결하기 위해 자신의 코드에 대해 고무 오리에게 설명하는 것을 의미합니다. 이를 통해 스스로의 코드를 검토하고 문제를 발견하게 됩니다.</p><p id="1048">때로는 서로의 시간을 뺏어 죄송하다는 의미에서, <br>“고무오리 했습니다 죄송합니다!” <br>라는 재치있는 표현으로 상황을 해소하기도 합니다ㅎㅎ</p><h2 id="73d4">협업 이슈</h2><p id="7030">고민을 나누고자 할 때 단순히 말로만 이야기하는 것 보다는 문서로 공유하고 회의 결과까지 기록 해놓는 것이 훨씬 효과적이라고 생각합니다.</p><p id="9756">이러한 문서를 한데 모아 관리할 수 있는 페이지를 우리는 “협업 이슈” 라고 부르고 있어요.</p><figure></figure><p id="e67b">사소하게 이야기하고 넘어갈 것이지만 딱히 어디에 문서를 만들어 공유할지 모를 때, 언젠가 이야기했던 것 같긴 한데 무슨 내용인지 기억이 안 날 때,</p><p id="5562">이 페이지를 활용할 수 있습니다.</p><p id="6861">사소한 정보라서 흩어지기 쉬울 텐데 이를 한데 모아서 관리하고 추적할 수 있어 정말 유용합니다!</p><h2 id="ea2e">PR 템플릿</h2><p id="d52a">우리의 뇌는 용량이 제한되어 있기 때문에 각자가 코드를 개발하면서 이전의 논의를 종종 잊어버리곤 합니다. 따라서 서로의 코드를 리뷰할 때는 종종 그때의 상황과 배경을 다시 상기시켜야 하는데요. 이러한 어려움을 해결하기 위해 우리는 PR 템플릿을 사용하고 있습니다.</p><figure></figure><p id="4db2">PR 템플릿은 작성자가 코드 배경, 목적, 고민한 부분 등을 보다 일관되고 체계적으로 공유할 수 있도록 도와줍니다.</p><p id="7ded">PR 템플릿을 더 상세하게 작성할수록 리뷰어의 리뷰도 더욱 자세해집니다.<br>리뷰어의 리뷰가 더 자세해지면 실수를 찾아내는 확률도 높아집니다.</p><p id="5a27">PR 템플릿을 작성하는 것은 조금 귀찮은 과정일 수도 있지만 사실은 리뷰이를 보호해주는 수단이라고 생각해요. 리뷰어가 컨텍스트를 잘 이해할수록 실수를 잡아줄 확률도 높아지니까요.</p><h2 id="93d8">마무리</h2><h2 id="e495">여러분들은 누구와, 어디서, 어떻게 일하고 계신가요?</h2><p id="a02a">글의 초반에서 언급한 대로 이 글은 공적이면서도 꽤나 사적인 이야기입니다. 29CM의 배송경험팀에서 백엔드 개발자들이 1년여의 시간동안 일궈온 일하는 방식이기 때문이예요.</p><p id="d836">우리는 영원히 고정된 형태가 아니기에 언제든지 함께 일하는 사람이, 장소가, 상황이 변할 수 있습니다. 이에 따라 발생하는 변화를 언제든지 수용할 수 있었으면 좋겠어요. 다른 사람과, 다른 곳에서, 다르게 일하고 있다면 우리의 일하는 방식은 또 바뀔거예요.</p><p id="e7cf">지금 당장 완벽한 방식이 아닐 수 있어도 보다 더 나은 방식으로 일하려 노력하는 것 만으로도 좋은 일하는 방식이 아닐까요?</p></div></div>

29CM 기술블로그 - Medium

우리만의 일하는 이야기 : 설계부터 개발까지
소개
안녕하세요. 
29CM 배송경험팀 (구 배송경험스쿼드) 백엔드 개발자 양유림입니다.
여러분들은 누구와, 어디서, 어떻게 일하고 계신가요?
저는 배송경험팀에서 백엔드 개발자로써 1년의 시간을 보냈습니다.
이 글에서는 그 시간들 속에서 차근히 쌓아올려진 우리만의 일하는 이야기를 들려드리려합니다.
공적이면서도 꽤나 사적인 이야기가 될 것 같아요.
남의 일기장을 훔쳐본다는 마음으로 가볍게 즐겨주시길 부탁드립니다.
( 이 이야기는 29CM 전체가 아닌, 배송경험팀 백엔드 개발자들의 이야기임을 명확히 밝힙니다! )
Part 1. 설계
오프라인 끝장토론
무신사는 재택근무 문화를 수용하고 있지만, 소프트웨어 설계 과정 만큼은 오프라인으로 모여서 진행하고있습니다. 함께 모여 직접 손으로 그리고 아이디어를 공유하며 상호작용하는 것은 서로의 의견을 더 잘 이해할 수 있어 도움이 됩니다.
이 과정에서는 단순히 설계를 다루는 것뿐만 아니라, 해당 작업을 진행할 때 사용할 용어나 코드에 적용할 Prefix 등을 함께 정의합니다.
물론 이러한 과정은 시간이 꽤나 소요될 수 있습니다.
하지만 이 작업이 충분히 견고하게 이루어지면, 이후의 실질적인 개발 시간과 코드 리뷰 시간을 줄일 수 있어요.
우리는 이러한 시간을 이보 전진을 위한 일보 후퇴로 느끼며, 이를 ‘끝장토론’이라고 부르기도 합니다.
스켈레톤 클래스로 설계 리뷰 받기
개발 디자인을 완료하고 실질적인 개발이 시작되기 전, 우리에겐 추가적인 단계가 필요합니다.
바로 스켈레톤 클래스를 통한 설계 리뷰입니다.
스켈레톤 클래스는 기본적인 구조나 뼈대를 제공하는 클래스를 의미하는데, 내부는 비어있는 형태로 클래스를 작성하고 실질적인 구현은 주석으로 가정하여 표현합니다.
이 과정은 다음과 같은 목적을 가지고 있습니다.
전체적인 설계 흐름 파악
네이밍과 Prefix 등의 정확성 확인
코드 스타일의 일관성 검토
다음 작업 예고
이는 리뷰이를 돕기 위한 과정처럼 보이지만, 사실은 리뷰어를 돕기 위한 과정입니다. 스켈레톤 클래스를 통해 해당 기능의 전반적인 흐름을 이해하게 되면 추후 코드 리뷰 시 코드를 이해하는 과정이 훨씬 용이해집니다.
Part 2. 개발
작소고 ( 작고 소중한 고민 공유 )
함께 설계를 진행해도, 스켈레톤 클래스 리뷰를 받아도, 막상 구현이 시작되고 나면 고민되는 지점들이 생기기 마련입니다.
우리에게는 이런 고민을 자유롭게 나눌 수 있는 도구가 있습니다.
바로 “작소고 요청”입니다.
작고 소중한 고민을 공유하는 것을 의미하며, 누구나 자신의 이야기를 털어놓을 수 있는 시간입니다.
누구나 언제든 “저 작소고하고싶습니다!” 라고 외치면, 우리는 하던 일을 잠시 멈추고 모여 서로의 고민을 나눌 수 있습니다. ( 물론 참여가 필수는 아닙니다. )
이렇게 고민을 나누다보면 종종 스스로 깨달음을 얻고 문제를 해결하는 경우가 많습니다.
이런 과정을 우리는 “고무오리 디버깅”이라고 부르는데요. 개발자들이 코드의 버그를 해결하기 위해 자신의 코드에 대해 고무 오리에게 설명하는 것을 의미합니다. 이를 통해 스스로의 코드를 검토하고 문제를 발견하게 됩니다.
때로는 서로의 시간을 뺏어 죄송하다는 의미에서, 
“고무오리 했습니다 죄송합니다!” 
라는 재치있는 표현으로 상황을 해소하기도 합니다ㅎㅎ
협업 이슈
고민을 나누고자 할 때 단순히 말로만 이야기하는 것 보다는 문서로 공유하고 회의 결과까지 기록 해놓는 것이 훨씬 효과적이라고 생각합니다.
이러한 문서를 한데 모아 관리할 수 있는 페이지를 우리는 “협업 이슈” 라고 부르고 있어요.
사소하게 이야기하고 넘어갈 것이지만 딱히 어디에 문서를 만들어 공유할지 모를 때, 언젠가 이야기했던 것 같긴 한데 무슨 내용인지 기억이 안 날 때,
이 페이지를 활용할 수 있습니다.
사소한 정보라서 흩어지기 쉬울 텐데 이를 한데 모아서 관리하고 추적할 수 있어 정말 유용합니다!
PR 템플릿
우리의 뇌는 용량이 제한되어 있기 때문에 각자가 코드를 개발하면서 이전의 논의를 종종 잊어버리곤 합니다. 따라서 서로의 코드를 리뷰할 때는 종종 그때의 상황과 배경을 다시 상기시켜야 하는데요. 이러한 어려움을 해결하기 위해 우리는 PR 템플릿을 사용하고 있습니다.
PR 템플릿은 작성자가 코드 배경, 목적, 고민한 부분 등을 보다 일관되고 체계적으로 공유할 수 있도록 도와줍니다.
PR 템플릿을 더 상세하게 작성할수록 리뷰어의 리뷰도 더욱 자세해집니다.
리뷰어의 리뷰가 더 자세해지면 실수를 찾아내는 확률도 높아집니다.
PR 템플릿을 작성하는 것은 조금 귀찮은 과정일 수도 있지만 사실은 리뷰이를 보호해주는 수단이라고 생각해요. 리뷰어가 컨텍스트를 잘 이해할수록 실수를 잡아줄 확률도 높아지니까요.
마무리
여러분들은 누구와, 어디서, 어떻게 일하고 계신가요?
글의 초반에서 언급한 대로 이 글은 공적이면서도 꽤나 사적인 이야기입니다. 29CM의 배송경험팀에서 백엔드 개발자들이 1년여의 시간동안 일궈온 일하는 방식이기 때문이예요.
우리는 영원히 고정된 형태가 아니기에 언제든지 함께 일하는 사람이, 장소가, 상황이 변할 수 있습니다. 이에 따라 발생하는 변화를 언제든지 수용할 수 있었으면 좋겠어요. 다른 사람과, 다른 곳에서, 다르게 일하고 있다면 우리의 일하는 방식은 또 바뀔거예요.
지금 당장 완벽한 방식이 아닐 수 있어도 보다 더 나은 방식으로 일하려 노력하는 것 만으로도 좋은 일하는 방식이 아닐까요?
29CM CAREER
함께할 동료를 찾습니다.🚀
29CM는 ‘고객의 더 나은 선택을 돕는다’라는 미션으로 출발했습니다. 우리는 우리만의 방식으로 콘텐츠를 제공하며, 브랜드와 고객 모두에게 대체 불가능한 커머스 플랫폼을 만들어가고 있습니다. 이 미션을 이루기 위해 우리는 흥미로우면서도 복잡한 문제들을 해결하고 있습니다. 만약 우리와 함께 이 문제들을 해결해 보고 싶다면, 주저하지 말고 29CM에 합류하세요!
29CM 채용 페이지 : https://www.29cmcareers.co.kr
채용이 완료되면 공고가 닫힐 수 있으니 빠르게 지원해 주세요!
우리만의 일하는 이야기 : 설계부터 개발까지 was originally published in 29CM TEAM on Medium, where people are continuing the conversation by highlighting and responding to this story.

우리만의 일하는 이야기 : 설계부터 개발까지

댓글