디지털 브레인과 개발에 대한 질문 편지 (24誠鉉 2월)
2024-02-01에 받은 유승현 님의 편지 속 질의응답들이다.
프로그래밍 언어 및 프레임워크 학습에 관하여
저는 특정 언어나, 프레임워크를 배우려고 할 때, 공식 홈페이지의 문서를 보며 학습하는게 가장 좋다는 것을 알지만, 결국 강의나 블로그에 의존하게 되는 것 같습니다. 혹시 성현님께서는 새로운 언어나 프레임워크를 배워야 하는 상황에서 어떠한 방식으로 습득해나가시는 지 궁금합니다.
"공식 문서를 보며 학습하는게 가장 좋다…"는 것은 사실 우리가 직접 겪으며 배운 것이 아닌, 그렇게 대답해야 한다고 학습된 내용입니다. 저는 개인적으로 공식 문서를 보는 것이 최고의 방법이 아니라고 생각합니다. 오히려 공식 문서는 최후의 보루에 가깝습니다. 가장 최신의 정보를 담고 있지만, 가장 불친절한 정보입니다. 이제 막 프로그래밍을 배우고 계신다면 굳이 공식 문서에 집착하지 않으셨으면 좋겠습니다. 정보를 얻는 출처가 어디든, 자신이 무언가를 배우고만 있다면, 그리고 남에게 그것을 설명해줄 수 있다면 그것이 최고의 방법입니다. 저 또한 개발을 시작한지 첫 5년 이상 공식 문서보다는 유료 강의들에 집중하며 학습했습니다. 무료 강의/ 블로그보다 더 체계적이며 질문이 생겼을 때 질문이 가능하기 때문입니다. 한 가지 차이가 있다면, 저는 클론코딩보다 클놈코딩을 추천드립니다.
- 클론코딩: 강의를 베껴가며 제품을 따라 만든다. 끝. (예시: AirBnB 클론코딩)
- 클놈코딩: 강의를 우선 따라가며 클론코딩을 완수한 뒤, 거기에서 배운 점으로 나만의 제품을 출시해본다 (예시: AirBnB 클론코딩 후 우리 동네 노래방 예약 서비스 제작해보기)
물론 요즘 제 경우에는, 말씀드리기 조심스럽습니다만, 몇 년에 걸쳐 여러 프레임워크를 다뤄본 적이 있기에, 불친절한 공식 문서의 내용도 어느 정도 빠르게 파악이 가능한 편입니다. 또한 되게 성질이 급해서 (…) 일단 공식 문서를 이해하면 별도의 강의나 블로그를 보지 않고 바로 개발에 뛰어드는 편입니다. 마지막으로 저는 영어를 읽는데 있어 불편함이 없는데, 때문에 모르는 것을 그때 그때 검색을 해도 데이터를 충분히 얻을 수 있어 점점 커리큘럼이 있는 강의나 블로그 글들에 의존을 덜 하게 되는 것 같습니다.
아이디어를 구현하는 과정
Heimdall이나 Bing Chat for All Browsers과 같은 아이디어를 서비스로 구현하실 때, 아이디어 기획부터 디자인, 구현까지 정해져 있는 일련의 과정을 거쳐서 만들고 계신지 궁금합니다.
아직은 기획은 따로 하지 않습니다. 만들면서 그때그때 필요한 것을 찾아서 추가합니다 (물론 저도 이 작업 패턴 때문에 제 발에 걸려서 넘어진 적이 많습니다 😅) 기획은 옵시디언에 생각나는 것들을 막 끄적이는 단계이고, 또 디자인은 대부분 디자인 시스템에 위탁합니다 (iOS 앱의 경우 Apple Human Interface Guideline, 웹의 경우 shadcn/ui). 디자인을 위탁했기 때문에 기획과 개발에만 집중하고, 이에 이들은 거의 동시에 병렬로 진행됩니다.
또 MVP를 최대한 빠르게 구현해보려고 합니다. 이에 저는 항상 다음 사진을 보여드립니다.
가장 하단의 1번 스테이지를 만드는 것이 중요합니다. 하지만 대부분의 사람들은 첫 줄, 아니면 두번째 줄처럼 제품을 제작하고 싶어합니다. 특히 자신들이 애자일하다고 믿는 사람들이 두번째 줄처럼 제품을 제작합니다. 실질적으로는 맨땅에서 자전거 만들고, 다시 맨땅에서 오토바이 만들고, 다시 맨땅에서 자동차 만들고... 하는 식으로 체력만 잡아먹는 개발 방법입니다. 진짜 "애자일"한 것은 마지막 줄입니다. 못생기고 조악한데 돌아가는 제품을 빠르게 만들어야 합니다.
일단 돌아가는 MVP가 있으면, 그 위에 새로운 것을 추가하는 것은 굉장히 재밌습니다. 이 재미는 직접 느껴본 사람이 아니면 설명하지 못합니다.
사이드 프로젝트에 있어서 가장 귀중한 자원은 시간도 자원도 노력도 아닌 흥미입니다. 흥미가 떨어지기 전에 못생긴 MVP를 완성해야 합니다.
물론 경험이 없는 상황이라면 빠르게 구현하는게 어렵다고 생각하실 수 있습니다. 하지만 다시 강조드리지만 ① 못생긴 ② MVP 입니다. 예를 들어 Flutter 커뮤니티 앱을 만들고 계신다면 탭 내비게이션이 있고, 내 정보와 피드는 JSON에서 대충 정보 읽어오고, 화면에 렌더링만 잘 되는 것까지 만들면 그것이 MVP입니다. 디자인은 안드로이드/iOS 기본 디자인을 쓰는 정도면 충분합니다.
오픈소스에 기여하는 방법
깃허브 오픈소스 레포지토리에 기여를 하시는 모습이 멋있다고 생각합니다. 보통 어떻게 기여를 하시게 되는지 궁금합니다. 오픈소스를 사용하다가 보완할 부분이 눈에 보이시는 것인지... 아니면 사용 중 발생한 오류나 안되는 부분을 직접 고치시면서 기여하시는 건지 궁금합니다.
주로 뭔가가 작동 안 되거나 보완할 부분이 눈에 보이면서 시작합니다. 한참을 토끼굴을 따라 내려가다보면 깃허브 코드와 디스커션을 직접 보면서 문제를 해결하려고 시도하는게 있는데 그때 가끔 "뭐야 얘네 이거 잘못 구현했네?" 같은 순간이 옵니다. 간단한 수정이라면 패치 후 PR을 드리고, 복잡한 구현이라면 이슈만 주로 남깁니다. 또는 제가 무언가를 구현하고 싶은데, 한참을 조사하다가 그게 결국 오픈소스의 문제였음을 알게 되었을 때, 제가 원하는 기능을 구현해서 PR을 넣는 경우도 있습니다.