디지털 브레인과 개발에 대한 질문 편지 (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을 넣는 경우도 있습니다.

디지털브레인에 관하여

저는 미흡하지만 옵시디언에 제텔카스텐 방식을 적용하여 수동으로 링크를 연결하여 작성중에 있습니다. 혹시 성현님께서는 어떻게 지식을 축적하고 계신지 궁금합니다. 작성하신 글을 통해서 수동으로 연결하지 않고 봇과 알고리즘을 통한 자동 연결 방식을 추구하신다고는 이해했습니다.

자동연결을 추구…하긴 했는데 그게 생각보다 제대로 된 구현체가 없었습니다. 저도 그냥 옵시디언에서 수동 연결하고 있습니다. 결국 중요한 것은 무엇이든 기록하는 습관인 것 같습니다. 결국 자신이 쓴 글은 자신이 기억하기 때문에 무엇이든 기록하면 지식이 되는 듯 합니다.

그와 별개로, 옵시디언이든 로그섹이든 노션이든 뭐든 너무 불편하다는 생각을 많이 합니다. 그래서 직접 SaaS로 만들고 싶은데 공사 규모가 너~무 커서 그냥 무기한 미루는 중입니다.

프로그래밍을 잘하는 방법

너무 막연한 질문이라 죄송힙니다. 저는 비전공자로서 기초가 부족하다고 생각이 들어 컴퓨터구조와 운영체제 책을 통해 배우고 있습니다. 이를 통해 제가 부족한 부분을 보완하면 조금 더 나아질 것이라 기대하고 있습니다. 성현님께서 생각하기에 프로그래밍을 잘하는 방법은 무엇이라 생각하시나요?

하루키의 "직업으로서의 소설가"에는 다음 구절이 있습니다.

좀 더 쓰고 싶더라도 20매 정도에서 딱 멈추고, 오늘은 뭔가 좀 잘 안된다 싶어도 어떻든 노력해서 20매까지는 씁니다. 왜냐하면 장기적인 일을 할 때는 규칙성이 중요한 의미를 갖기 때문입니다.

쓸 수 있을 때는 그 기세를 몰아 많이 써버린다, 써지지 않을 때는 쉰다,라는 것으로는 규칙성이 생기지 않습니다.

본질적으로 개발자, 특히 제품 중심 개발자는 소설가와 크게 다르지 않다고 생각합니다. 꾸준히 하는 것이 가장 중요합니다.

근데 꾸준히 할 때 중요한 점이 있습니다. 현대인들은 너무 삐까뻔쩍한 것들에 눈이 높아져 있다는 점입니다. 프로그래밍은 굉장히 느리고 고된 과정입니다. 인터넷에는 번쩍이는 것들이 수많이 있는데, 자신이 만든 제품은 너무 볼품없고 시간만 무한정 들어가는 순간들이 분명 찾아오실 것입니다.

그 과정을 잘 견뎌내는 것이 중요합니다. 그렇게 푹 고아내야 자신만의 창의와 개성이 서서히 우러나옵니다.

결국 다른 사람 관심 끄고 나만의 창의성과 개성의 성장에만 집중하는 것.

그리고 아주 천천히, 꾸준히, 멈추지 않고 나의 무능력함을 참아내는 것이 중요합니다...

저는 이를 너무 힘들고 고통스럽게 깨달았습니다.

마치며

괜시리 현학적인체 잘난체한 것 같아서 좀 죄송스럽습니다. 한줄로 쿨하게 깔끔하게 설명드리고도 싶지만, 그게 오히려 거짓말만 드리는 것 같아 이렇게 진솔하게 적어보니, 이에 너른 이해 부탁 드립니다.

무엇보다 저는 승현님의 두그열에 큰 응원을 보내고 싶습니다. 제게 이렇게 이메일을 보내는 결정을 내려주신 점에 감사드립니다. 저 또한 귀한 손님을 맞는다는 기분으로 이렇게 길게 글을 써 보았습니다.