<div id="readability-page-1" class="page"><article><div><p>안녕하세요, LINE Plus에서 근무하고 있는 최연두입니다. 이 글에서는 시행착오 끝에 정착한 저만의 ‘일하는 방식’을 공유하려고 합니다. 다른 팀의 아무개가 일하는 방식이 궁금하신 분, 효율적인 협업과 코드 리뷰에 관심 있는 분들께 도움이 되길 바랍니다. 참고로 이 글은 작업 관리에 Jira를 사용한다고 전제하고 관련 개념과 용어를 사용하고 있습니다. 혹시 관련 개념과 용어가 생소하신 분들은 <a href="https://confluence.atlassian.com/jira" target="_blank">Jira Docs</a>를 참고해 주시기를 부탁드리며 시작하겠습니다.</p>
<h2 id="yondoo.choi3년차앱개발자가일하는순서를공유합니다-결론부터!">결론부터!&nbsp;</h2>
<p>저는 효율적이고 실수 없는 개발, 그리고 원활한 리뷰를 위해 이런 프로세스를 정립했습니다.</p>
<ol><li>기획서 리뷰 및 머릿속으로 기능 시뮬레이션</li><li>큰 단위의 작업 흐름 구성</li><li>작업 흐름을 Jira 티켓 등으로 가시화</li><li>티켓에 대해 PoC(proof of concept)/프로토타이핑 진행</li><li>작업 내역 셀프 피드백(변경 사항, 리뷰 용이성 등)</li><li>리뷰어를 배려한 기능 구현</li><li>PR(pull request) 작성</li><li>4~7번 반복</li></ol>
<h2 id="yondoo.choi3년차앱개발자가일하는순서를공유합니다-프로세스단계별설명">프로세스 단계별 설명</h2>
<p>제가 정립한 프로세스를 각 단계별로 살펴보겠습니다.</p>
<h3 id="yondoo.choi3년차앱개발자가일하는순서를공유합니다-기획서리뷰">기획서 리뷰</h3>
<p>"시작은 전체 흐름과 요구 사항을 명확히 이해하는 것에서부터!"</p>
<p>기획서를 꼼꼼히 읽어 기능의 목적과 작동 방식을 이해합니다. 이해가 안 되는 부분이 있거나 사용자 경험을 위해 더 나은 아이디어가 떠오르면, 기획자와 소통합니다.&nbsp;</p>
<p>기능이 작동하는 모습을 시뮬레이션할 때에는 실제 코드를 짠다고 상상하며 데이터 흐름과 화면 전환, 예외 상황은 어떻게 발생할지 시뮬레이션합니다. 예를 들어 각자가 사용하는 상태 관리 기법에 따라서 에러 핸들링을 처리해야 할 수도 있고 하지 않아야 할 수도 있습니다.</p>
<blockquote>팁
<ul><li>“이 기능이 이런 상황에서는 어떻게 작동하지?”라는 질문을 스스로에게 던져보세요.</li><li>에지 케이스(edge case)는 꼭 메모해서 기획자와 공유하세요.</li></ul>
</blockquote>
<h3 id="yondoo.choi3년차앱개발자가일하는순서를공유합니다-큰단위의작업흐름구성">큰 단위의 작업 흐름 구성</h3>
<p>"전체 흐름을 그리고 세부 작업을 만들어 보세요."</p>
<p>개발할 기능을 어떤 흐름으로 구현할지 간단히 기능의 흐름을 그려봅니다. 다이어그램이어도 되고 단순하게 화살표를 이용해도 좋습니다.</p>
<p>다음으로 데이터가 어디에서 오고 어떤 처리가 필요한지, 이벤트에 따라 상태가 어떻게 변할지 생각해 봅니다. 앞서 작성한 기능의 흐름도를 보며 하나의 주제로 엮일만한 것끼리 묶어 작업을 만듭니다.&nbsp;</p>
<p>마지막으로 지금까지 그린 기능의 흐름을 새로 정리한다는 마음으로, 전체 구조와 데이터 흐름을 간단한 다이어그램으로 표현합니다. 너무 정교할 필요는 없습니다. 앞서 만든 작업이 연결되도록 주요 단계별로 묶어서 큰 그림을 그려보세요.</p>
<blockquote>팁
<ul><li>종이에 대충 그려도 좋고, 화이트보드나 온라인 도구를 써도 괜찮아요.</li><li>너무 세세하게 그리려다 보면 오히려 진도가 안 나갈 수 있습니다.</li></ul>
</blockquote>
<h3 id="yondoo.choi3년차앱개발자가일하는순서를공유합니다-작업흐름을Jira티켓등으로가시화">작업 흐름을 Jira 티켓 등으로 가시화</h3>
<p>"전체 작업을 눈에 보이게 쪼개서 관리하세요."</p>
<p>앞서 그린 큰 단위의 작업 흐름을 바탕으로, 각 작업을 Jira 티켓(또는 사용하는 툴)에 등록해 구체적으로 관리합니다. 저는 기획서 전체를 하나의 <a href="https://www.atlassian.com/ko/agile/tutorials/epics" target="_blank">에픽(epic)</a>으로 만들고 그 하위에&nbsp;여러 이슈를 생성했는데요. 아래는 그중 일부를 예시로 가져온 것입니다.</p>
<p><img src="https://vos.line-scdn.net/landpress-content-v2-vcfc68aynwenkh3bno0ixfx8/5aec2227a5d74fefb9c3a64c146d8a24.png?updatedAt=1754450341000" width="742" height="256" alt="Jira 티켓 예시"></p>
<p>참고로 이 시점에는 티켓의 순서는 상관없습니다.</p>
<blockquote>팁
<ul><li>티켓 제목은 한눈에 알아볼 수 있게 간결하게 작성하세요.</li><li>티켓에 예상 소요 시간, 의존 관계 등을 적어두면 나중에 관리가 편해집니다.</li></ul>
</blockquote>
<h3 id="yondoo.choi3년차앱개발자가일하는순서를공유합니다-PoC와셀프피드백">PoC와 셀프 피드백</h3>
<p>"내 예상대로 작동하는지, 작업의 크기는 적절한지 점검해 보세요."</p>
<p>이제 PoC나 프로토타입을 만들어 보면서 앞서 생성한 티켓에 혹시 빠지거나 중복된 부분은 없는지, 예상치 못한 문제나 시나리오는 없는지 확인합니다.</p>
<p>완성된 결과물을 GitHub에 올려 작업량 혹은 변경 사항이 얼마나 되는지 확인해 봅시다. 양이 많다면 주제에 따라서 티켓을 유지 혹은 분리하거나 부작업으로 세분화할지 고민해야 합니다. PoC이기 때문에 테스트 코드도 없고 문서화를 위한 주석도 없습니다. 따라서 온전히 기능만을 위해 수정된 코드가 몇 줄인지 확인할 수 있는데요. 제 경우 이때 코드가 400줄을 넘어가면 작업량이 많거나 변경 사항의 규모가 크다고 판단합니다.&nbsp;</p>
<p>변경 사항의 규모가 크다고 판단한 경우, 먼저 코드에 여러 주제가 섞여 있는지 확인합니다. 만약 그렇다면 주제별로 작업을 분리하는 것이 좋습니다.&nbsp;그렇지 않고 한 가지 주제라면, Jira 티켓의 하위 작업(sub-task) 기능을 활용해 세분화합니다. 그 외의 경우에는 티켓을 혀재 상태로 유지하면 됩니다.</p>
<p>예를 들어 저의 경우, 앞서 예시 이미지 속 'Implement the scheduled stockout &amp; sale status page'는 PoC 이후 아래와 같이 세분화됐습니다.</p>
<p><img src="https://vos.line-scdn.net/landpress-content-v2-vcfc68aynwenkh3bno0ixfx8/837c0b2bf23c4d1380f52d56e23743c4.png?updatedAt=1754450379000" width="934" height="408" alt="'Implement the scheduled stockout &amp; sale status page' 세분화 예시"></p>
<p>그런데 왜 그냥 하나의 티켓으로 관리하지 않고 이와 같이 티켓을 분리하거나 세분화하는 과정에 시간과 에너지를 사용해야 할까요?</p>
<p>제가 속한 팀은 코드 리뷰를 중요하게 여기고 있습니다. 따라서 리뷰하기 쉬워야 작업이 머지되기 쉬운데요. 리뷰하기 쉬운 작업이란 다음과 같은 작업을 의미합니다.</p>
<ul><li>말하고자 하는 바가 명확한&nbsp; 작업</li><li>리뷰어가 이해하기 쉬운 작업</li></ul>
<p>위와 같은 조건을 갖추려면 규모가 큰 변경의 경우 적절한 크기로 티켓을 나누는 게 필요합니다. 즉, 티켓 크기 조정 단계는 저희 팀의 리뷰 문화에 입각해서 도출된 과정이라고 할 수 있습니다. 따라서 이 단계는 각자의 팀 상황에 맞춰 적절히 조절하며 진행하면 좋을 것 같습니다.</p>
<blockquote>팁
<ul><li>너무 완벽하게 만들 필요는 없습니다. ‘작동만 확인’하는 수준이면 충분합니다.</li><li>만약 문제가 발견된 경우 바로 티켓에 메모해 두세요.</li><li><code>git diff</code>나 <code>remote repository push</code>&nbsp;명령어 등을 활용해 변경 사항을 눈으로 직접 확인하세요.
<ul><li>푸시 후 PR 작성 버튼을 클릭하면 'github-domain.com/{company}/{repository_name}/compare/{branch_name}?expand=1'와 같은 URL을 볼 수 있습니다. 이 URL에서 아래와 같이 '?expand=1'을 지우면 변경 사항을 쉽게 확인할 수 있습니다.</li><li>github-domain.com/{company}/{repository_name}/compare/{branch_name}</li></ul>
</li><li>'이 PR을 내가 리뷰한다면 부담스럽지 않을까?'를 스스로 물어보세요.</li></ul>
</blockquote>
<h3 id="yondoo.choi3년차앱개발자가일하는순서를공유합니다-리뷰어를배려한기능구현">리뷰어를 배려한 기능 구현</h3>
<p>"작고 명확한 커밋, 이해하기 쉬운 코드로 리뷰어의 시간을 아껴주세요."</p>
<p>앞서의 과정은 바로 이 단계를 위한 과정이었다고 해도 과언이 아닙니다. 앞선 단계를 잘 진행해 오셨다면 티켓의 크기는 리뷰어가 리뷰하기 좋은 크기로 나뉘어 있을 것입니다. 따라서 작업의 주제에 맞춰 작업을 구현해 주세요.&nbsp;</p>
<p>다만 작업을 구현할 때에는 다음 사항에 유의해 주세요.</p>
<ul><li>커밋 단위는 너무 크지 않게(의미별로 쪼개기)</li><li>커밋 메시지는 명확하게&nbsp;</li><li>코드의 변경 순서도 논리적으로(예: 인터페이스 → 구현)</li></ul>
<p>작업하다 보면 '이 정도로 리뷰어를 배려해야 하나?'라는 생각이 드실 수도 있는데요. 이런 접근 방식은 아래와 같은 장점에 힘입어 나에게도 도움이 됩니다.</p>
<ul><li>일하는 방식이 구체화되면서 작업이 예측 가능해집니다.</li><li>히스토리를 파악하는 데 도움이 됩니다.</li><li>작은 단위이기 때문에 리버트(revert)가 필요한 경우 결정 및 실행이 쉽습니다.</li></ul>
<blockquote>팁
<ul><li>작은 커밋, 작은 PR은 문제가 발생했을 때 쉽게 원복할 수 있습니다.</li><li>리뷰어가 '이 PR은 읽기 편하다'라고 느끼는 감정이 차차 쌓여 신뢰로 돌아옵니다.</li><li>커밋 크기가 작으면 코드만으로도 이 커밋에 어떤 내용이 담겨 있는지 이해하기 쉽습니다.</li></ul>
</blockquote>
<h3 id="yondoo.choi3년차앱개발자가일하는순서를공유합니다-PR작성">PR 작성</h3>
<p>“PR을 작성할 때 리뷰어가 이해하기 쉽게 문서화한다고 생각해 보세요.”</p>
<p>PR을 만들 때는&nbsp;이 PR의 목적이 무엇인지 명확히 밝히고, 리뷰어가 알아야 할 사전 지식과 이슈, 테스트 방법 등을 상세히 적습니다. 만약&nbsp;테스트하는 방법이 복잡한 PR이라면 작동 영상을 첨부하는 것도 좋은 방법입니다.</p>
<blockquote>팁
<ul><li>PR 설명을 잘 써두면, 나중에 내가 히스토리를 다시 볼 때에도 큰 도움이 됩니다.</li><li>리뷰어 입장에서 '이 PR을 바로 이해할 수 있을까?' 고민하며 작성하면 좋습니다.</li></ul>
</blockquote>
<p>다음은 제가 사용하고 있는 PR 템플릿입니다.</p>
<pre><code>## Description
 
## Comments for the issue
### Causes
### Affected features to be checked
### Tests by the developer
 
## BTS(Github) issues</code></pre>
<h2 id="yondoo.choi3년차앱개발자가일하는순서를공유합니다-이프로세스에서동료와작업의방향을맞추는시점은언제가적당할까요?">이 프로세스에서 동료와 작업의 방향을 맞추는 시점은 언제가 적당할까요?&nbsp;</h2>
<p>“혼자 고민하지 말고, 동료와 미리 의견을 나누면 리뷰 시간이 짧아집니다.”</p>
<p>새로운 컴포넌트를 개발한다거나 여러 명이 관여하는 작업을 진행할 때에는 작업 흐름을 Jira 티켓으로 만들기 전에 간단하게 동료에게 설명하고 피드백을 받는 게 좋습니다.&nbsp;이 과정을 거치면 나중에 리뷰 단계에서 큰 수정 없이 빠르게 진행할 수 있습니다. 다시 말해서, 이 과정 없이 그냥 진행하면 나중에 수정해야 할 부분이 많아질 수 있습니다.</p>
<blockquote>팁
<ul><li>'이렇게 해도 괜찮을까?'라는 마음으로 너무 부담 갖지 말고 공유하세요.</li><li>동료의 피드백을 미리 받으면 리뷰 과정에서 발생할 수도 있는 불필요한 논쟁이나 수정이 줄어듭니다.</li><li>동료의 의견을 듣다 보면 내가 미처 생각하지 못한 부분을 미리 발견할 수 있습니다.</li></ul>
</blockquote>
<p>따라서 '동료와의 협업 과정'은 '큰 단위로 작업 흐름 구성'과 '작업 흐름을 Jira 티켓 등으로 가시화' 사이에 들어가는 것이 적절합니다.</p>
<ol><li>기획서 리뷰 및 머릿속 동작 시뮬레이션</li><li>큰 단위의 작업 흐름 구성</li><li><strong>(필요시) 개발 방향 콘셉트 공유 및 개선</strong></li><li>작업 흐름을 Jira 티켓 등으로 가시화</li><li>티켓에 대해 PoC/프로토타이핑 진행</li><li>작업 내역 셀프 피드백(변경 사항, 리뷰 용이성 등)</li><li>리뷰어를 배려한 기능 구현</li><li>PR 작성</li><li>5~8번 반복</li></ol>
<h2 id="yondoo.choi3년차앱개발자가일하는순서를공유합니다-추후보완하고싶은점">추후 보완하고 싶은 점</h2>
<p>확인 감사합니다. 그렇다면 본문의 가장 마지막 순서가 되는 게 좋을 것 같아서 동료와 작업 방향을 맞춘다는 내용의 세션과 자리를 바꿨습니다.</p>
<p>"추정한 작업 수행 시간과 실제 소요된 작업 수행 시간의 차이를 기록하자."</p>
<p>Jira의 티켓에는 시간을 기록할 수 있는 필드가 몇 개 있습니다. 이를 바탕으로 최초 추정한 작업 수행 시간과 실제 수행 시간을 비교해 볼 수 있는데요. 지난 3년간 이 부분을 크게 신경쓰지 못했습니다. 구체적으로 말씀드리자면, 작업 수행 예측 시간은 많이 적어 놓았는데 실제 수행 시간을 제대로 기록하지 못해 유의미한 데이터를 도출하지 못했습니다. 예를 들어 아래는 티켓 생성 당시 작업 소요 시간을 1d 4h(12h)로 예측했던 티켓인데요. 실제 작업을 수행한 뒤 실제 수행 시간을 기록하지 못해서 현재도 남아있는 시간이 1d 4h로 나타나고 있습니다. 앞으로는 실제 수행 시간까지 잘 기록해서 일정 산출 시 도움을 받을 수 있는 수준으로 끌어올리고자 합니다.</p>
<p><img src="https://vos.line-scdn.net/landpress-content-v2-vcfc68aynwenkh3bno0ixfx8/e30985578f4046bbbf566b6ba29994fe.png?updatedAt=1754450442000" width="1000" height="auto" alt="작업 수행 시간 미기록 예시"></p>
<h2 id="yondoo.choi3년차앱개발자가일하는순서를공유합니다-마치며">마치며</h2>
<p>이 방식의 핵심 목표는 작업을 작은 단위로 나누고, 동료와 자주 소통하며, 리뷰어를 배려하는 습관을 통해 신뢰할 수 있는 개발자로 성장하는 것입니다.</p>
<p>저는 주어진 업무를 어떻게 처리할지 도식화해보며 저만의 일하는 방식을 만들어 왔습니다. 코드 리뷰가 중요한 환경에서 위와 같은 작업 방식을 반복하다 보니 업무를 받을 때마다 자연스럽게 머릿속에 접근 방법을 그려 적절한 크기로 세부 작업을 분리하는 역량이 함께 길러졌습니다. 여기에 시간 측정 프로세스를 더한다면 앞으로 개발 기간을 더욱 정확하게 산정할 수 있을 것이라고 생각합니다.</p>
<p>조직마다 문화와 구성원이 다르기 때문에 일하는 방식도 다양할 것이라고 생각하는데요. 만약 저와 비슷한 환경에 계시다면 한 번쯤 제가 이 글에서 소개한 방법을 시도해 보시면 좋을 것 같습니다. 만약 환경이 다르더라도, 자신이 일하는 방식을 도식화해 보며 정리하는 경험 자체가 큰 도움이 될 것이라고 생각하기 때문에 한 번쯤 고려해 보시면 좋을 것 같습니다.</p>
<p>마지막으로 이 자리를 빌려 이와 같은 업무 프로세스를 정립할 수 있게 도와주신 김성진 님과 강희준 님께 감사 인사를 드리며 이만 마치겠습니다. 긴 글 읽어주셔서 감사합니다.</p></div></article></div>

LINE ENGINEERING

안녕하세요, LINE Plus에서 근무하고 있는 최연두입니다. 이 글에서는 시행착오 끝에 정착한 저만의 ‘일하는 방식’을 공유하려고 합니다. 다른 팀의 아무개가 일하는 방식이 궁금...

3년 차 앱 개발자가 일하는 순서를 공유합니다

댓글