일상다반사

클론 프로젝트가 가진 장점에 대해서

dev4us — Sun, 4 Jul 2021 23:51:44 +0900

(당신이 사이드 프로젝트를 시작해야 하는 이유에서 이어지는 시리즈)

지난 포스트에서 예고했듯, 이번 포스트에서는사이드 프로젝트를 시작하려고 하는 분들에게 도움이 될만한 주제인클론 프로젝트에 대해 소개해보려 한다.

# 창작의 고통

사이드 프로젝트를 시작하기로 마음 먹었다면 실행에 옮기기 전 제일 먼저 필요한 단계는 무엇일까?

아마 어떤 서비스를 개발할지 고민하고 선정하는 과정일 것이다.

개발자라면 누구나 ‘참신한 아이디어’, ‘많은 유저들이 유익하게 이용할 서비스’ 개발을 꿈꿀 것이다.

하지만 아이디어를 구상하는 과정에는 꽤 많은 시간이 소요되며, 단순히 학습이 목적인 개발자들에게는 하나의 스트레스 요소로 자리 잡을 수 있다.

또한 피로함과 지연되는 개발 시작 시점에 지쳐 사이드 프로젝트를 시작하고 싶던 욕구마저 사라질 수 있다.

그럼 어떻게 사이드 프로젝트를 바로 시작할 수 있을까?

# 클론 프로젝트가 갖고 있는 장점

필자 또한 위와 같은 내용으로 꽤 오래 고민을 하였고 가장 쉽게 접근할 수 있는 방법이라고 결론을 내린 것은 클론 프로젝트였다.

그럼 클론 프로젝트란 무엇일까?

클론 프로젝트란 이미 개발되어 있는 서비스를 주제 삼아 서비스의 기존 스택이나 새로운 스택을 적용하여 나만의 서비스로 복제하듯 개발해보는 것을 말한다.

예를 들면, 이미 ‘카카오톡’ 서비스가 존재하지만 해당 서비스를 나만의 스택으로 ‘카카오톡’의 전체 또는 일부분의 기능만을 다시 개발해본다는 뜻이다.

이러한 클론 행위에는 어떤 장점이 있을까? 아래에 필자가 생각하는 클론 프로젝트의 장점을 적어보았다.

1. 개발에만 집중할 수 있다

하나의 서비스가 개발될 때 필요한 포지션은 개발자 뿐만이 아니다.

기획자, 디자이너, 프론트엔드 개발자, 백엔드 개발자 등등 다양한 포지션이 협업하여 하나의 서비스가 만들어지기 때문에 홀로 사이드 프로젝트를 진행하는 개발자라면 다른 포지션의 부재를 느낄 수 있고, 부담감 또한 느낄 수도 있다.

허나 클론 프로젝트에서는 이미 운영 중인 서비스를 클론하는 것이므로 기획 단계는 기존 서비스의 컨셉을 빌릴 수 있으며디자인 단계 또한 기존의 서비스의 UI, 리소스를 이용하는 방식으로 본인이 학습하고자 하는 내용만을 다뤄볼 수 있다.

이렇게 클론 프로젝트는 개발자가온전히 개발자의 역할만을 할 수 있게끔 도와준다.

2. 보다 쉬운 경험 어필

다른 이에게 진행하였던 사이드 프로젝트에 대해 설명해야 할 경우가 있다면 내가 직접 개발한 서비스보다 클론한 프로젝트를 설명하는 것이 조금 더 수월할 것이다.

"저는 Node를 기반으로 한 OO 서비스를 만들어보았으며 계정 관리, 실시간 채팅, 인맥 관리 등의 메신저를 개발해보았습니다." 보다는 "저는 Node를 기반으로 작은 규모의 카카오톡을 개발해본 경험이 있습니다."가 듣는 입장에서는 프로젝트 내용을 쉽게 이해할 수 있다.

개발할 때 기존 서비스의 내용을 기준으로 생각하며 개발하듯 듣는 입장에서도 기존 서비스의 내용을 먼저 떠올리기 때문이다.

# 클론 프로젝트 팁 & 노하우

1. 익숙한 서비스를 선택하자

클론할 프로젝트를 선정할 때에는 내가 익숙한 서비스를 선정하는 것이 중요하다.

기획, 디자인 등 타 포지션의 역할에 대한 부담감은 줄어들지만 서비스 내 각 UI의 기능, 목적을 전혀 알지 못한다면 기능에 대한 분석으로 시간을 소요하거나 헤메는 경우가 생길 수 있다.

이와 같이 기능을 구현하는 데 혼란을 겪거나 추가적인 시간을 소모하고 싶지 않다면 익숙하거나 평소에 관심이 있어 자주 둘러보았던 서비스를 선택하는 것이 좋다.

2. 압박감을 느낄 필요 없다

사이드 프로젝트에 대한 포스트를 작성할 때 비슷한 맥락으로 작성한 바 있지만 마찬가지로 클론 프로젝트를 진행할 때에도서비스 내 모든 기능을 구현하기 위해 매달릴 필요가 전혀 없다.

본인이 개발해보고 싶은 특정 기능이 있다면 서비스 내 해당 부분만을 개발해보며 학습하여도 전혀 상관없다는 뜻이다.

사이드 프로젝트는 언제나 부담감을 느끼지 않는 선에서 진행하는 것이 좋다.

# 마무리

지금까지 클론 프로젝트에 대한 내용을 작성해보았다.

클론 프로젝트가 본인에게 맞는 스타일이라고 생각된다면 지금 바로 시작해보자.

클론 프로젝트를 마치고 서비스 개발자를 만나볼 기회가 생긴다면 구현에 있어 어려웠던 부분이나 개선점에 대해 논해볼 좋은 기회가 올 수도 있지 않을까?

필자는 생각한다.

끝

JavaScript's GC (Garbage collector)

dev4us — Tue, 29 Jun 2021 23:23:02 +0900

우리는 언어를 이용하여 다양한 어플리케이션을 개발하며 필요한 수 많은 변수, 함수 같은 데이터를 선언합니다.

필요에 의해 데이터를 할당하고 사용하는 과정은 개발자의 몫이지만, 더 이상 필요로 하지 않는 데이터는 어떻게 될까요?

제일 좋은 방안은 더 이상 필요가 없는 데이터를 정리하여 쾌적한 환경을 유지하는 것일겁니다.

그러면 이러한 메모리를 수거해주는 역할은 어디서 수행되며 어떤 것이 불필요한 메모리라고 판단할 수 있는걸까요?

이번 포스트에서는 위 역할을 수행해주는 Garbage Collector에 대해 알아보겠습니다.

가비지 컬렉터(Garbage Collector)란 위에서 언급한 듯 메모리 할당을 추적하고 할당된 메모리가 더 이상 필요 없어졌을 때 이에 할당된 메모리를 회수하는 작업입니다. (이하 GC)

이 작업은 Javascript 내에서 자동적으로 실행되어 메모리 관리를 하는 특징을 가지고 있습니다.

그러면 한가지 의문이 생깁니다.

특정 메모리가 사용 중인지 또는 이후에 사용될 지 GC는 어떻게 알고 정리할 수 있는 걸까요?

혹시나 실수하여 사용하고 있는 데이터를 소거하는 경우는 없을까요?

아래 GC가 이루어지는 자세한 과정을 함께 보며 궁금증을 해소해보도록 하겠습니다.

# 메모리 구조

먼저 선언이 이루어진 뒤 해당 데이터는 메모리의 빈 공간에 할당될 것입니다.

이 할당되는 공간을 힙 메모리(Heap Memory)라고 합니다.

힙 메모리는 위와 같이 구성되어 있습니다.

(실제로는 Large Object Space, Code Space 등 공간이 더 존재하지만 GC가 발생하는 영역만을 그렸습니다.)

이 중 New Space(Young Generation)는 새로 만들어진 데이터가 우선적으로 저장되는 공간입니다.

2개의 Semi Space로 이루어져 있으며 'to'와 'from'의 태그를 통해 분류가 가능합니다.

Old Space(Old generation)는 New Space에서의 1차적인 GC(Major GC)가 이루어진 이후에 데이터가 저장되는 공간으로서 'Old Pointer Space'는 다른 객체를 참조하는 객체가 저장되는 공간이며 'Old Data Space'는 문자열과 같은 다른 객체를 참조하지 않는 데이터들이 저장되는 공간입니다.

# New Space 에서의 Minor GC

데이터 할당이 시작하면 두 종류의 Semi-space 중 to 영역에 메모리 할당이 이루어집니다.

이후 더 이상 To-space에 메모리 할당이 불가능할 경우 Minor GC가 실행됩니다.

Minor GC가 시작되면 To-space에 생성된 객체들은 모두 From-space로 이동됩니다.

이후 객체 그래프를 순회하며 어플리케이션에서 사용 중인 메모리를 찾아내어 다시 To-space로 이동시킵니다.

이 과정에서 To-space에서는 자동으로 압축을 진행합니다.

(A, B, E 사이에 빈 공간이 존재하지 않음)

이는 조각화 현상을 막아 데이터 적재에 용이하게 보관하기 위함입니다.

이후에 From-space에 남아 있는 객체들은 모두 Garbage로 판단하고 삭제합니다.

이와 같은 방식을 Scavenge 알고리즘을 통한 Minor GC라고 합니다.

# Old Space 에서의 Major GC

위와 같은 Minor GC가 이루어진 뒤 다시 To-space에 더 이상 메모리를 할당할 수 없는 상황이 발생하면 같은 Minor GC가 실행됩니다.

하지만 두 번의 Minor GC를 거친 뒤 소거되지 않은 메모리는 별도의 공간으로 이동되어 관리됩니다.

이 별도의 공간은 Old Space로서 Major GC라고 불리는 다른 방식을 통하여 관리됩니다.

Major GC는 마찬가지로 Old Space 영역이 가득 찼을 때 발생하며 Mark, Sweep, Compact 단계로 이루어져 있습니다.

1. Marking Phase

먼저 Marking Phase 에서 객체 별 참조 여부를 확인하여 'White, Gray, Black'으로 마킹을 진행하는데 White는 GC가 아직 탐색을 진행하지 못한 객체를 의미하며 Gray는 GC가 탐색은 마쳤으나 참조하고 있는 객체의 유무를 확인하지 못한 상태, Black은 참조하고 있는 객체가 존재함을 확인한 상태를 나타냅니다.

모든 객체는 'White' 상태로 시작되며 먼저 Root 객체를 Gray로 마킹합니다. 이후 인접 객체를 Gray로 마킹한 뒤 실제로 참조 관계가 있을 경우 Black으로 마킹합니다.

2. Sweep Phase

Sweep Phase에서는 위 Marking Phase를 거치고 난 뒤 White로 마킹되어 있는 객체를 모두 제거합니다.

(실제로는 Free Space로 이동시키며 Free List에 해당 메모리를 추가합니다.)

3. Compact Phase

Compact 단계에서는 Minor GC 때와 마찬가지로 조각화 현상을 방지하고 추가적인 메모리를 확보하기 위해 진행됩니다.

# 왜 Minor GC, Major GC 두 가지 방식으로 GC가 실행될까요?

물론 한 가지 일관된 방식으로 메모리가 관리된다면 좋겠지만 위 Minor GC는 속도가 빠르다는 장점을 가지고 있는 방면에 GC 과정 중 물리적인 데이터 백업을 필요하므로 메모리 공간에 대한 오버헤드가 존재합니다.

그래서 보다 큰 메모리 영역이 필요한 Old Space에서는 Mark-Sweep-Compact 알고리즘(DFS)을 이용한 방식인 Major GC를 필요로 하는 것입니다.

# 글을 마치며

이로써 Javascript에서의 Garbage collector 동작 방식에 대한 설명이 끝났습니다.

위 내용을 통하여 알 수 있는 점은 참조라는 개념이 굉장히 중요하다는 것을 알 수 있습니다.

더더욱 Javascript의 경우 'prototype와 같은 절대적 참조'나 '속성값과 같은 지정적 참조'가 존재하기 때문에 일반적인 객체보다 더 확장된 범위로 고려하여 생각하는 방식이 필요할 것 같습니다.

또한 Javascript 내에서 GC는 자동적으로 실행되어 메모리 관리를 진행해주지만 개발자가 메모리 관리에 대한 부분을 전혀 신경 쓰지 않는다면 메모리(memory leak)이 발생하여 어플리케이션의 성능 저하나 심각한 오류를 초래할 수 있다는 점을 꼭 염두해야 합니다.

결국 GC를 통하여 메모리를 회수한다는 것은 비결정적인 동작이기 때문입니다.

끝.

당신이 사이드 프로젝트를 시작해야 하는 이유

dev4us — Thu, 27 May 2021 13:00:27 +0900

이번 포스트에서는 사이드 프로젝트의 중요성에 대해 적어보려 한다.

사이드 프로젝트 또는 토이 프로젝트라는 용어가 낯선 이들에겐 새로운 흥미를,
이미 알고 있었지만 실천하지 못한 이들에겐 다시금 동기를 부여해주는 포스트가 되리라 믿는다.

(이하 사이드 프로젝트로 명칭을 통일)

# 사이드 프로젝트란 무엇일까?

사이드 프로젝트란,
규모와 수익성과는 상관 없이 스스로 원해서 개발해보고 싶은 서비스, 적용해보고 싶은 기술 스택 등을 남에게 등 떠밀리거나 눈치 볼 필요 없이 스스로 자기 개발을 하는 기회를 마련하는 나만의 프로젝트를 뜻한다.

또한 서비스 개발에 대한 부담이 없기에 '이런 서비스를 만들어보면 어떨까?, 이런 기능은 왜 없을까?' 와 같은 아이디어도 구현의 대상이 될 수 있고, 내가 자주 사용하는 서비스를 내가 원하는 스택으로 개발해보는 클론 코딩 또한 시도해볼 수 있다.

필자의 경우는 부서 내 협업하여 개발하는 경험을 하지 못했기에 남들과 협업하며 개발하는 경험을 사이드 프로젝트 팀에서 활동하며 경험을 쌓고 타 팀원들의 경험과 노하우를 공유하는 기회를 가진 적도 있다.

당신이 아직 사이드 프로젝트에 대한 매력을 충분히 느끼지 못하였을 수 있다고 생각하여 아래 필자가 사이드 프로젝트를 진행하면서 직접 느꼈던 점들을 적어보았다.

# 시작하기에 충분한 이유

1. 아는 것과 하는 것은 큰 차이가 있다.

'길을 아는 것과 길을 걷는 것은 큰 차이가 있다' 영화 매트릭스에서 인용해온 대사다.

필자의 입장에서는 서적이나 영상을 통해 관심있는 기술에 대해 공부하는 것으로 '나는 이제 이 기술에 대한 공부를 마쳤다.'라고 말하는 것은 전혀 시원하지 않은 부분이었기에 작은 규모의 프로젝트를 개발한 후 '드디어 이 기술에 대한 맛은 느꼈다.'라고 느낀 적이 많다.

학습에 대한 만족의 기준은 각자 다르겠지만, '반드시 이 기술을 내 것으로 만들겠다, 내 실력을 확인해보고 싶다'와 같은 욕심이 생긴다면 본인에 대한 피드백과 그 기술의 장점과 단점 등을 직접 체험해보고 이후에 돌아보았을 때 그 경험이 나를 마중나오는 느낌을 직접 느껴보길 필자는 권하고 싶다.

2. 처음부터 완벽한 소스는 없다.

'트렌드를 따라가며 새로운 기술을 학습한다'가 개발자로써 경험을 쌓는다는 것의 전부가 아니라 같은 기능을 구현하더라도 이전보다 깔끔하고 문제없는 코드를 작성하는 것 또한 개발자로써의 중요한 성장 과제라 생각한다.

그 경험을 현업에서 쌓는 것 또한 좋은 방법이지만 보다 도전적인 개선을 시도해보고 싶을 때 사이드 프로젝트는 더 유용하다.

시험적으로 개선한 소스를 적용시켜 볼 수 있고 효율과 개발 능률을 따질 수 있는 개발자의 리스크 없는 훌륭한 놀이터가 되는 것이다.

3. 걸음마 또한 경험이다.

사이드 프로젝트를 딴 짓이라고 부르는 이들도 있다.

하지만 이 딴 짓은 많은 사용자에게 유용하고 선호 받는 서비스가 되는 주춧돌이 되는 경우도 있다.

그 예로 우리가 흔히 사용하는 'Gmail, instagram, Unsplash' 또한 사이드 프로젝트로 시작된 성공한 훌륭한 사례의 서비스들이다.

하지만 필자가 말하고자 하는 부분은 위와 같은 유종의 미를 거두려 노력하는 것을 강조하는 것이 아니다.

위에 언급한 서비스들과 같이 본인의 프로젝트에 대해 큰 매력을 느껴 더욱 발전 시켜 나갈 수도 있겠지만, 마무리하지 못하더라도 얽매이지 않고 '좋은 경험을 하였다' 정도로 마무리하여도 좋으니 전혀 부담을 느낄 필요가 없다는 말을 전하고 싶다.

# 마무리

사이드 프로젝트에 대한 필요성과 매력 어필이 충분히 되었을지 궁금하다.

이미 개발에 대한 숙련자나 사이드 프로젝트를 평소 생각하고 있던 개발자가 매력을 느꼈다면 바로 실천이 가능하겠지만 사이드 프로젝트를 이번 포스트를 통해 처음 접하는 독자은 '그래서 어떻게 시작하라는거지..' 라는 생각을 했을 수도 있다.

필자 또한 시작만 권유만 하기에는 해당 포스트를 작성하며 욕심이 생겼다.

앞으로 사이드 프로젝트를 시작하는 자들에게 도움이 되는 포스트들을 종종 작성해볼 예정이다.

끝