<div id="readability-page-1" class="page"><div><h2 id="a5be">0–1 개월. 기초 다지기</h2><p id="bb49">Flutter를 익히기 위해서 다음과 같이 진행했다.</p><ol><li id="15b5">Dart 프로그래밍 언어 배우기</li><li id="2b98">Flutter 설치 및 개발 환경 설정</li><li id="cdcf">기본 위젯 사용</li><li id="1b5b">커스텀 위젯 만들기</li></ol><p id="c44e">이 시기에 나는 1–2개월 시기에 사용할 디자인 시스템을 코드로 변환했고, 팀원들은 숙제들을 하나씩 해치워가면서 조금씩 Dart/Flutter 개발자로 바뀌어갔다. 이전 경험이 있어서 꽤 빠르게 적응하는 것을 볼 수 있었다. 처음 이 프로젝트를 시작할 때는 프로젝트를 정상적으로 마무리할 수 있을까 싶었는데, 1개월 안에 이 프로젝트의 성공이 가능하겠다는 판단이 들었다.</p><p id="81f5">Flutter 개발 환경 설정 및 기본 위젯 사용도 능숙하게 해주셨다. 간단하게 마스터-디테일 인터페이스를 만들어 화면 전환, 상태 변경 등 기본적인 UI를 만들어보았고 이 역시 손쉽게 지나갈 수 있었다.</p><p id="cd8e">이 시기에 Flutter를 어떻게 사용하는가도 중요했지만, 일하는 방법에 대한 논의를 많이 했었다. 나는 외부에서 이 프로젝트 때문에 온 사람이었고 비즈니스 로직에 대한 이해는 원래 계시던 분들에 비하면 매우 낮았다. 때문에 내가 비즈니스와 관련된 어떤 것 부터 하자고 말을 할 수 있는 상황이 아니었고, Flutter를 알려드리면서 동시에 기존 앱에서 가장 먼저 해야하는 부분들, UI를 만들면서 고민했어야 하는 부분들을 질문하곤 했다. 그리고 각 개발자분들이 좋아하는 것과 잘하는 것 그리고 까다롭게 느끼는 부분들을 지속적으로 파악했다. 다들 잘 하셔서 새 언어에 대한 두려움만 없다면 문제 없다고 다시 한번 생각했었다.</p><p id="4556">4명이 재밌었던 것은 대부분 논의가 2대2로 갈렸던 것이다. 이래서 홀수가 좋았겠다보다는 다수결 상황이 안만들어져서 다행이다 라는 생각이 먼저 들었다. 내가 딱히 내세울 권위가 있지도 않고, 어쩌면 외부 사람이라 신뢰를 얻어야하는 숙제가 있어 기존에 계신 분들은 어떻게 결정을 했는지 궁금했다. 무언가 업무 분배를 하는 경우에는 이랬다.</p><p id="8dab"><strong>“좋아하는/맘에드는 티켓을 먼저 가져가 볼까요?” </strong>라고 제안했다. 재밌게도 다들 서로를 배려해 주셨고 질문을 바꾸었다.</p><p id="13fd"><strong>“하기 싫은거 먼저 골라주세요.”</strong></p><p id="35ed">우리는 이 때부터 일을 이렇게 선별했다. 잘 할 수 있는 것과 싫어하는 것(못하는게 아니라). 그리고 애매하게 모두가 싫어하는 일들은 특단의 조치를 취했다.</p><figure><figcaption>분분한 상황에 나왔던 동전던지기</figcaption></figure><p id="3050">“우리끼리는 어떻게 업무 분배하냐고 누가 물어보면 ‘동전 던지기’, ‘사다리 타기’로 해요 라고 말해야겠네요?” 라는 농담을 하긴 했는데 실제로 무작위로 결정하는게 나쁘지 않았다. 어느정도 공평하게 분배가 되어서 그랬을 수도 있겠다 싶고. <br> 이 시기에 우리는 미리 미래를 위해서 모노레포도 준비했다. 대략 1년 후에 일이 쏟아지는 시기가 되었을 때 잘 분리해둔 패키지가 두고두고 도움이 되었다. 모노레포는 <a href="https://melos.invertase.dev/" rel="noopener ugc nofollow" target="_blank">melos</a>를 사용했다.</p><h2 id="8160">1–2개월: 같은 흐름으로 UI를 만드는 방법</h2><p id="4f94">1개월차 이후에 팀에는 다음과 같이 UI 개발 흐름을 제안했다.</p><figure></figure><p id="76ec"><code>Page -&gt; Screen -&gt; Component -&gt; Widget</code> 이 순서인데 여전히 Page와 Screen은 조금 이름을 잘못 지은 것 같다. 하지만 안에서는 잘 통용되므로 나름대로의 약속이라고 봐야할 것 같기도 하다.</p><p id="54aa">우리는 다음과 같이 위젯, 컴포넌트 , 화면, 페이지를 만들어갔다.</p><ol><li id="a7e9">여러 디자인을 확인하고, 공통적으로 사용할 위젯을 만든다. 동시에 여러 패턴과 조합을 발견한다.</li><li id="17bc">공통으로 사용할 위젯을 코드로 작성한다. (텍스트, 버튼 등)</li><li id="845f">최소 단위 위젯들을 조합하여 컴포넌트를 만든다. (카드, 리스트 등)</li><li id="2813">컴포넌트를 화면에 배치하여 데이터가 있을 때 정상적으로 나오게 한다.</li><li id="ef43">페이지에서 API를 붙이고 화면으로 데이터를 전달하여 백엔드와 통합한다.</li></ol><p id="cde7">우리는 만들 화면(여기서는 Screen)이 수십개에 달하였고 아직 백엔드와의 통합을 하기에는 시기가 이르기도 해서 최대한 화면(Screen) 단위로 만들었다. 이 때부터 HTTP 요청을 위한 패키지를 만들기 시작했다. 나를 제외한 팀원들은 위젯과 컴포넌트를 공장처럼 찍어내기 시작했다. 이때 아주 속도가 많이 붙었다. 일이 많아서 서로 잡담은 줄었지만 어떻게하면 서로가 사용할 컴포넌트를 잘 만들지 고민들을 많이 나누었다. 처음부터 규칙을 세우지 않고 이 시기에 많은 규칙들이 나왔고 또 개선되었다. 우리 팀의 일하는 방법은 대부분 이 때 만들어졌다.</p><p id="7ccc">0–1개월 시기에 간단한 화면들을 계속 다시 만들어가며 연습했는데, 서로에게 사용하기 좋은 컴포넌트는 무엇일지 코드리뷰를 하면서 진행했었다. 서로 코드를 봐주시면서 서로가 다른 환경에서 일했구나 라는 이야기를 듣곤 했다.</p><h2 id="e1ac">2–4 개월 그리고 배포까지</h2><figure></figure><p id="e2a1">본격적으로 프로젝트가 진행되었고 다들 백엔드와의 통합, 기타 중요한 비즈니스 로직 적용 및 논의, 테스트 등으로 바빴다. 커밋 그래프를 보면 12월 중순에도 1월 말에도 미친듯이 일을 했다. 그럼에도 불구하고 다들 이전까지의 준비들이 있어서 일정한 분위기를 유지할 수 있었다. 누군가는 너무 잔인한 일정이라고 생각할 수도 있었는데 팀에서는 한번도 그런 이야기를 듣지는 못했다. 다만 기간 내에 잘 할 수 있겠다는 이야기를 해주셨다.</p><p id="459e">한참 후에 저 시기를 어떻게 보내셨는지 물어봤는데 적당히 바쁘고 좋았다는 말씀을 해주셔서 나쁘지 않았구나 하고 스스로 생각했던 적이 있다. 나는 약간 죽을 맛이었는데 이건 내가 비즈니스 로직을 파악하는데 시간이 필요해서 그러지 않았을까… 정도만 생각해봤다. 솔직한 느낌으로는 이거 잘 안되면 다 내 탓이지 않나 하는 마음으로 한 것 같기도 하다. 하지만 나는 혼자가 아니었고 함께 해주신 분들을 믿고 마무리까지 지치지 않고 달렸었다.</p><p id="0f4a">기존에 올라갔던 프로젝트를 성공적으로 Flutter로 빌드된 앱으로 바꾸었고 또 이상하리만큼 문제가 없었다. 우리 팀 외에 참여했던 모든 사람들이 꼼꼼히 봐주었기 때문이기도 하다. 배포일에는 배포 버튼이 눌린 이후에 이제 난리나는거 아닐까 조마조마 하기도 했다.</p></div><div><figure></figure><p id="d40f">2024년 02월. 온전히 출시가 된 이후에 2025년 05월까지 1년 조금 넘는 동안 약 30여회의 릴리즈가 있었다. 돌아보니 우리는 꾸준히 바빴고, 꾸준히 논쟁을 했으며, 어떻게 하면 더 좋은 서비스를 만들까 우리는 잘 하고 있는가 고민을 하기도 했다. 물론 잘못된 배포로 장애도 있었고 중간 중간 동력을 잃는 느낌도 받았다. 나도 약간의 탈진 상태에 빠지고 회복하기도 했다.</p><p id="c263">프로젝트를 진행하는 동안 앱개발을 해보거나 배우고 싶다는 이야기를 회사분들께 꽤 많이 들었었는데, 말로만 그러면 좋겠다고 했지 실제로 도움을 드린적은 없었다. Flutter 개발 가이드인 <a href="https://changjoo-park.github.io/learn-flutter/" rel="noopener ugc nofollow" target="_blank">Flutter 배우기</a> 는 함께 했던 분들에 대한 헌정이다. 팀에서 한번쯤은 고민했고, 대부분은 많이 활용했던 것만 담았다. 시간이 많지 않아 목차와 초안을 작성하고 Claude 3.7 sonnet의 도움을 많이 받았지만 퇴고할 부분이 가득하지만 그래도 최소한으로 담고 싶은 내용들은 있긴하다.</p><p id="d527">회사에서 워크북 또는 개발자 온보딩 용으로 사용할까 했지만 지금 우리 팀 분들은 모두 이정도 내용은 능숙하게 할 수 있어 그렇게 필요한 내용은 아니다. 다른 사람들에게 교육을 할 정도로 뛰어나기도 하고.</p></div></div>

Stories by ChangJoo Park on Medium

tl;dr Flutter 개발 가이드로 바로 가셔도 됩니다.
Welcome to Starlight
Flutter 배우기는 네이티브에서 Flutter로 전환하면서 익혀야 했거나 여러가지 선택해야했을 부분들을 정리한 페이지입니다. 아직 추가될 내용도, 수정해야할 내용도 많습니다.
아래 내용은 전환하는 과정 중의 일부를 적어두었습니다.
2년전, 네이티브 안드로이드와 iOS로 구현되어있던 앱을 Flutter 프레임워크로 전환하는 프로젝트를 하였다. 앱 자체는 역사가 좀 되어서 복잡한 비즈니스 로직이 있고 넓은 범위임에도 개발자 4명으로 잘 마무리 했다.
팀 구성은 이랬다.
나
네이티브 iOS 개발자 2명
네이티브 Android 개발자 1명
나를 제외한 3분은 전환하는 기회에 Flutter 를 처음 배우는 시기였다. 기한이 어느정도는 정해진 일이어서 나름의 4달짜리 마일스톤을 세웠었는데 다음과 같다.
0–1개월: Flutter의 기초적인 부분들을 다룸. 일부 화면들을 데모로 만들기
1–2개월: 전체 앱의 개발 패턴 수립 및 공유
2–4개월: 본격적인 프로젝트 진행 및 완료
4개월 — : 출시
0–1 개월. 기초 다지기
Flutter를 익히기 위해서 다음과 같이 진행했다.
Dart 프로그래밍 언어 배우기
Flutter 설치 및 개발 환경 설정
기본 위젯 사용
커스텀 위젯 만들기
이 시기에 나는 1–2개월 시기에 사용할 디자인 시스템을 코드로 변환했고, 팀원들은 숙제들을 하나씩 해치워가면서 조금씩 Dart/Flutter 개발자로 바뀌어갔다. 이전 경험이 있어서 꽤 빠르게 적응하는 것을 볼 수 있었다. 처음 이 프로젝트를 시작할 때는 프로젝트를 정상적으로 마무리할 수 있을까 싶었는데, 1개월 안에 이 프로젝트의 성공이 가능하겠다는 판단이 들었다.
Flutter 개발 환경 설정 및 기본 위젯 사용도 능숙하게 해주셨다. 간단하게 마스터-디테일 인터페이스를 만들어 화면 전환, 상태 변경 등 기본적인 UI를 만들어보았고 이 역시 손쉽게 지나갈 수 있었다.
이 시기에 Flutter를 어떻게 사용하는가도 중요했지만, 일하는 방법에 대한 논의를 많이 했었다. 나는 외부에서 이 프로젝트 때문에 온 사람이었고 비즈니스 로직에 대한 이해는 원래 계시던 분들에 비하면 매우 낮았다. 때문에 내가 비즈니스와 관련된 어떤 것 부터 하자고 말을 할 수 있는 상황이 아니었고, Flutter를 알려드리면서 동시에 기존 앱에서 가장 먼저 해야하는 부분들, UI를 만들면서 고민했어야 하는 부분들을 질문하곤 했다. 그리고 각 개발자분들이 좋아하는 것과 잘하는 것 그리고 까다롭게 느끼는 부분들을 지속적으로 파악했다. 다들 잘 하셔서 새 언어에 대한 두려움만 없다면 문제 없다고 다시 한번 생각했었다.
4명이 재밌었던 것은 대부분 논의가 2대2로 갈렸던 것이다. 이래서 홀수가 좋았겠다보다는 다수결 상황이 안만들어져서 다행이다 라는 생각이 먼저 들었다. 내가 딱히 내세울 권위가 있지도 않고, 어쩌면 외부 사람이라 신뢰를 얻어야하는 숙제가 있어 기존에 계신 분들은 어떻게 결정을 했는지 궁금했다. 무언가 업무 분배를 하는 경우에는 이랬다.
“좋아하는/맘에드는 티켓을 먼저 가져가 볼까요?” 라고 제안했다. 재밌게도 다들 서로를 배려해 주셨고 질문을 바꾸었다.
“하기 싫은거 먼저 골라주세요.”
우리는 이 때부터 일을 이렇게 선별했다. 잘 할 수 있는 것과 싫어하는 것(못하는게 아니라). 그리고 애매하게 모두가 싫어하는 일들은 특단의 조치를 취했다.
“우리끼리는 어떻게 업무 분배하냐고 누가 물어보면 ‘동전 던지기’, ‘사다리 타기’로 해요 라고 말해야겠네요?” 라는 농담을 하긴 했는데 실제로 무작위로 결정하는게 나쁘지 않았다. 어느정도 공평하게 분배가 되어서 그랬을 수도 있겠다 싶고. 
 이 시기에 우리는 미리 미래를 위해서 모노레포도 준비했다. 대략 1년 후에 일이 쏟아지는 시기가 되었을 때 잘 분리해둔 패키지가 두고두고 도움이 되었다. 모노레포는 melos를 사용했다.
1–2개월: 같은 흐름으로 UI를 만드는 방법
1개월차 이후에 팀에는 다음과 같이 UI 개발 흐름을 제안했다.
Page -> Screen -> Component -> Widget 이 순서인데 여전히 Page와 Screen은 조금 이름을 잘못 지은 것 같다. 하지만 안에서는 잘 통용되므로 나름대로의 약속이라고 봐야할 것 같기도 하다.
우리는 다음과 같이 위젯, 컴포넌트 , 화면, 페이지를 만들어갔다.
여러 디자인을 확인하고, 공통적으로 사용할 위젯을 만든다. 동시에 여러 패턴과 조합을 발견한다.
공통으로 사용할 위젯을 코드로 작성한다. (텍스트, 버튼 등)
최소 단위 위젯들을 조합하여 컴포넌트를 만든다. (카드, 리스트 등)
컴포넌트를 화면에 배치하여 데이터가 있을 때 정상적으로 나오게 한다.
페이지에서 API를 붙이고 화면으로 데이터를 전달하여 백엔드와 통합한다.
우리는 만들 화면(여기서는 Screen)이 수십개에 달하였고 아직 백엔드와의 통합을 하기에는 시기가 이르기도 해서 최대한 화면(Screen) 단위로 만들었다. 이 때부터 HTTP 요청을 위한 패키지를 만들기 시작했다. 나를 제외한 팀원들은 위젯과 컴포넌트를 공장처럼 찍어내기 시작했다. 이때 아주 속도가 많이 붙었다. 일이 많아서 서로 잡담은 줄었지만 어떻게하면 서로가 사용할 컴포넌트를 잘 만들지 고민들을 많이 나누었다. 처음부터 규칙을 세우지 않고 이 시기에 많은 규칙들이 나왔고 또 개선되었다. 우리 팀의 일하는 방법은 대부분 이 때 만들어졌다.
0–1개월 시기에 간단한 화면들을 계속 다시 만들어가며 연습했는데, 서로에게 사용하기 좋은 컴포넌트는 무엇일지 코드리뷰를 하면서 진행했었다. 서로 코드를 봐주시면서 서로가 다른 환경에서 일했구나 라는 이야기를 듣곤 했다.
2–4 개월 그리고 배포까지
본격적으로 프로젝트가 진행되었고 다들 백엔드와의 통합, 기타 중요한 비즈니스 로직 적용 및 논의, 테스트 등으로 바빴다. 커밋 그래프를 보면 12월 중순에도 1월 말에도 미친듯이 일을 했다. 그럼에도 불구하고 다들 이전까지의 준비들이 있어서 일정한 분위기를 유지할 수 있었다. 누군가는 너무 잔인한 일정이라고 생각할 수도 있었는데 팀에서는 한번도 그런 이야기를 듣지는 못했다. 다만 기간 내에 잘 할 수 있겠다는 이야기를 해주셨다.
한참 후에 저 시기를 어떻게 보내셨는지 물어봤는데 적당히 바쁘고 좋았다는 말씀을 해주셔서 나쁘지 않았구나 하고 스스로 생각했던 적이 있다. 나는 약간 죽을 맛이었는데 이건 내가 비즈니스 로직을 파악하는데 시간이 필요해서 그러지 않았을까… 정도만 생각해봤다. 솔직한 느낌으로는 이거 잘 안되면 다 내 탓이지 않나 하는 마음으로 한 것 같기도 하다. 하지만 나는 혼자가 아니었고 함께 해주신 분들을 믿고 마무리까지 지치지 않고 달렸었다.
기존에 올라갔던 프로젝트를 성공적으로 Flutter로 빌드된 앱으로 바꾸었고 또 이상하리만큼 문제가 없었다. 우리 팀 외에 참여했던 모든 사람들이 꼼꼼히 봐주었기 때문이기도 하다. 배포일에는 배포 버튼이 눌린 이후에 이제 난리나는거 아닐까 조마조마 하기도 했다.
2024년 02월. 온전히 출시가 된 이후에 2025년 05월까지 1년 조금 넘는 동안 약 30여회의 릴리즈가 있었다. 돌아보니 우리는 꾸준히 바빴고, 꾸준히 논쟁을 했으며, 어떻게 하면 더 좋은 서비스를 만들까 우리는 잘 하고 있는가 고민을 하기도 했다. 물론 잘못된 배포로 장애도 있었고 중간 중간 동력을 잃는 느낌도 받았다. 나도 약간의 탈진 상태에 빠지고 회복하기도 했다.
프로젝트를 진행하는 동안 앱개발을 해보거나 배우고 싶다는 이야기를 회사분들께 꽤 많이 들었었는데, 말로만 그러면 좋겠다고 했지 실제로 도움을 드린적은 없었다. Flutter 개발 가이드인 Flutter 배우기 는 함께 했던 분들에 대한 헌정이다. 팀에서 한번쯤은 고민했고, 대부분은 많이 활용했던 것만 담았다. 시간이 많지 않아 목차와 초안을 작성하고 Claude 3.7 sonnet의 도움을 많이 받았지만 퇴고할 부분이 가득하지만 그래도 최소한으로 담고 싶은 내용들은 있긴하다.
회사에서 워크북 또는 개발자 온보딩 용으로 사용할까 했지만 지금 우리 팀 분들은 모두 이정도 내용은 능숙하게 할 수 있어 그렇게 필요한 내용은 아니다. 다른 사람들에게 교육을 할 정도로 뛰어나기도 하고.

Flutter 개발 가이드 초기 버전을 출시하며

댓글