포폴 만드는법

제목이 거창 한 것 같기는 하지만, 구인을 하기위해 이력서를 보거나 면접을 볼때 이런 구직자라면 “정말 뽑고 싶다” 하는 마음가짐으로 적어 봅니다. 회사의 규모에 관계없이 좋은 회사를 구직자가 선택 할 수 있는 좋은 “미끼”가 될 수도 있습니다.

제가 앞으로 언급하는 모든 내용들이 정답은 아니지만, 구직 활동을 위한 포트폴리오를 만드는데 있어서 조금이나마 도움이 되었으면 합니다. 취직을 처음 준비하는 분들을 기준으로 어떻게 준비하면 좋을지에 대한 기준으로 적어 보았습니다. 

 

무엇을 만들 것인가. 게시판은 좋은 시작이 될 수 있습니다. 

꼭 게시판 이어야 할 이유는 없지만, 구인을 하는쪽이나 구직을 하는 입장에서 서로 이해하기 편한 기능일 수 있습니다. 처음 시작은 로그인을 하지 않는 공개된 게시판을 만들어 보면 됩니다.

사실 경력직이 아닌 이상 처음 사회생활을 시작하는데 있어서 뭔가 화려하거나 새로운 기술을 썼다는 것보다는 어느 정도의 기본기를 갖추었는지, 어느 정도 완성도를 가지고 있는지 살펴봅니다. 그 합일점에서는 복잡한 요구사항을 설명해야 하는 새로운 프로젝트 보다는 게시판이 코드를 검토하는 사람의 입장으로 접근이 좀 더 쉬울 수 있습니다. 실제로 이력서를 보고, 다른 사람의 코드를 살펴보는 시간은 정말 길어봐야 10분 이상 가지지 않습니다.

 

어떤 게시판을 만들지 요구사항을 조금 상세하게 적습니다.

본인이 어느 정도의 게시판을 만들 수 있을지 본인의 능력에 따라 객관화 시켜보고, 실천 가능한 범위에 따라서 요구사항을 나열해 봅니다. 처음부터 거창하게 만들어야 할 이유는 없습니다. 최대한 단순한 게시판을 만드는 것을 목표로 합니다. 

처음 뼈대를 잡아보고 하나씩 추가/변형 시켜 나가보면 됩니다. 한번에 완벽하게 만들 필요는 없습니다. 

 

어떤 기술을 사용할지 Research하고 선택합니다.

게시판을 만들기 위해서는 아래 정도의 기술 선택이 필요해 보입니다.

• RDBMS - Free database 중에서 적용하고 싶은 걸 선택하면 됩니다.
• Backend language -  본인이 가장 자신있어하는 언어 중에 선택하면 됩니다.
• Frontend language - React, Angular, Vue 중에서 자신 있는 것을 선택합니다.

처음 시작하는 상황에서는 위 세가지 정도만을 고민하는 것으로 하겠습니다.

 

Github계정을 만들고, 모든 문서는 Repository안에 포함되면 좋습니다.

Github (https://github.com/)에 가서 게시판 프로젝트를 위한 Repository를 만듭니다. 문서는 처음 README.md에 만들 게시판에 대한 개략적인 설명을 채워 줍니다. 차근 차근 Frontend, Backend, DB scheme 자세한 설계사항을 README.md에 채우면 됩니다.

 

좋은 오픈소스를 고르는 빠른 방법

구글링을 하는 경우가 많을 것이고, github에서 많은 코드들을 살펴 볼 수 있을 것입니다. 예제가 될수도 있고, 템플릿 코드가 될 수도 있습니다. 제가 빠르게 판단하는 좋은 오픈소스의 기준은 얼마나 많은 Contributors가 repository에 참여하고 있느냐 입니다. 집단 지성이라는 전제하에 많은 참여는 좋은 코드가 나올 확률이 높습니다.

 

첫 설계를 시작 합니다.

이제 어떤 기술을 쓸지 정했고, Github repository도 만들었습니다. 시작이 반이니 설계를 시작해 보도록 합니다. 

개인적으로 Backend는 REST API로 만드는 걸 추천합니다. 다른 방법도 있긴 하지만, 나중에 확장을 하거나 변화를 주기 편하므로 일단 시작을 REST로 하는 것을 추천합니다.

설계를 위해서는 3가지 사항을 집중적으로 공부해야 합니다. 

 

1. REST API의 Best practice

REST API 원칙에 대해서 최소 3~4 일 정도의 시간을 투자해서 많은 문서들을 보는 것을 추천합니다. github에 있는 오픈소스를 보는 것도 방법이고, 유튜브나 여러 문서들을 상세히 살펴보는 것이 매우 중요합니다. 유명한 IT회사에서 OpenAPI Spec 문서를 보면서 힌트를 얻는 것도 큰 도움이 됩니다.

그래서 결과물은 적어도 어떤 endpoints들이 필요한지 README.md에 문서로 작성해 줍니다.

 

2. Frontend의 Best practice

Frontend는 HTML, CSS, Javascript만 있는 것은 아닙니다. 그 이상으로 Typescript를 사용하는 것이 장점인지, 어떤 패턴을 사용해야 하는지 Best practice를 살펴보는 것이 중요합니다.

예를 들어 React를 선택했다면 typescript와 redux pattern을 사용하고, 패턴에 대한 이해를 몇일 정도 충분히 공부할 시간이 필요합니다. 물론 문서를 README.md에 작성합니다.

 

3. DB 스키마 설계

사실 게시판 스키마 설계도 검색을 통해서 많은 정보를 얻을 수 있습니다. 하지만 데이터베이스 정규화와 함께 설계에 대한 서적을 읽으면서 스키마를 만들어 봅니다. 문서를 만들어 놓고, 나중에 사용을 위해서 스키마 생성 스크립트도 만들어 놓습니다.

Backend 개발하기

위의 단계가 완료되고 나면 공부했던 방식대로 최대한 패턴에 맞게 개발을 합니다. 

DB는 stored procedure를 만들어서 처리하는 것을 추천합니다. 

 

Backend 개발에 있어서 중요한 사항은 아래와 같습니다. 

• Route는 동사가 아닌 명사를 사용하는 것을 추천합니다. 예를 들어 덧글을 남긴다라고 봤을 때, POST {domain}/v1/comments 
• Controller-Service-Repository with dependency injection 패턴을 쓰는 것을 추천합니다. 
• Unit tests를 만들 수 없는 코드는 디자인이 잘못된 것입니다.
• KISS, DRY, YAGNI, SOLID 원칙 정도는 검색해서 최대한 정독을 해서 살펴보고 개발을 시작해 봅니다. 처음에 언듯 이해가 잘 가지는 않지만, 여러번 읽고 최대한 지켜보도록 노력하는 것은 도움이 됩니다. 
• Design pattern 관련 서적을 참고하는 것은 좋지만, 꼭 필요하다는 생각이 들때 사용하는 것을 추천합니다.
• Dependency injection framework은 사용하는 걸 추천합니다. Decoupling과 나중에 Unit tests를 만드는데 있어서 큰 도움을 줍니다.
• Unit tests를 위해서 Mocking framework를 같이 사용합니다.
• DB는 Stored procedure를 만들고, 코드내에서 stored procedure를 사용하지 않고 요청하는 쿼리는 피합니다.
• 보안의 이유로 SQL Injection과 같이 기본적으로 어떻게 구현해야 하는지 찾아보고 꼭 지키는 것입니다.

 

Unit tests

Unit tests는 TDD가 아닙니다. TDD는 선택사항이지만, Unit tests는 개발에서 매우 중요한 과정중에 하나 입니다. 개인적으로는 아무리 강조해도 지나치지 않지만, 지금 이 글에서 모든 장점을 나열하기에는 한계가 있습니다. 

적어도 두권 이상의 TDD나 유닛테스트 관련 서적을 읽어 보는 것을 매우 추천합니다. 하나 확실하게 말할 수 있는 것은 Unit test를 만들 수 없는 코드는 나쁜 디자인 입니다. 그래서 저의 경우는 구직자의 코드를 살펴볼 때 유닛테스트가 거의 완벽하게 작성되어 있으면 많은 플러스 점수를 줍니다. 

이건 일종의 완전한 코드를 만들겠다는 일종의 마음가짐 같습니다. 돌아가기만 하는 기능을 만들기 위해 노력하는 사람인가, 아니면 미래를 위해 조금 더디지만 완전한 코드를 만들기 위해 노력하는 사람인가의 차이인데 이건 코드를 보는 사람에서는 큰 차이로 느껴집니다. 아직은 많은 사람들이 이 실천을 잘 하지 않고 있습니다. 이 포인트가 좋은 회사에 좋은 조건으로 취직할 수 있는 첫번째 요건이라고 감히 이야기 할 수 있습니다. 제가 다니는 회사에서도 졸업자들의 면접을 많이 보지만, 유닛테스트 만큼은 당락 여부에 있어서 아주 큰 요소가 됩니다. 절대 작게 보지 말고, 최대한 Code coverage가 100프로 될 때 까지 노력해 보면 본인의 실력 향상과 취직에 큰 도움이 됩니다. 

 

Frontend의 개발과 Unit tests

Frontend 개발조차 정해진 패턴에 맞게 정확하게 개발하는 것이 중요합니다. React를 예를 들어 보겠습니다.

Action, Reducer, Container, View, Comopnent를 정확한 원칙으로 만들었느냐 입니다. 기능이 돌아가는 것과 비슷하게 관리 가능한 코드를 만들었는지도 중요합니다. 

물론 Frontend의 경우도 Unit tests를 만들어야 합니다. 오픈 소스 예제에 Unit tests가 포함되어 있는 경우가 있습니다. 시간을 좀 걸리지만, Interaction tests ( View, Component ) 까지 만들어 주면 큰 도움이 될 것입니다.

 

디자인은 최대한 심플하게! 그리고 배포해 봅시다.

만든 게시판의 배포해서 다른 사람들이 게시판을 볼 수 있게 해 주면 좋습니다. 하지만 지원한 포지션이 웹 디자이너가 아닌 이상 디자인이 화려할 필요는 없습니다. 

 

개발이 완료 되었으면 문서를 다시 보강 합니다.

보통 개발자분들은 문서 만들기 싫어합니다. 개발 딱 완료하고, 기능 잘 작동 하니 손 털고 다음으로 넘어갑니다. 하지만 첫 인상을 보여주는 입장에서 README.md에서 보여주는 것이 잘 작성된 문서라면 많은 플러스 점수를 받을 수 있습니다. 위에서 언급한 것을 토대로 저라면 아래와 같은 문서를 작성할 것입니다.

 

• 게시판 기능 설명
• Key summary
• • 포트폴리오에서 강조하고 싶은 내용들을 적습니다. 예를 들어 유닛테스트 Code coverage가 100%라면 적어도 됩니다. 
• Folder structure 소개
• Backend architecture
• • Routes/Endpoints 소개
  • Controller, Service, Repository, Store procedure 관계도
  • DB 스키마
• Frontend architecture
• • React라면 Redux pattern의 역할 소개
• 설치 방법
• 실행 방법
• 향후 추가 할 기능들

---

 

사실 위에서 말한 정도 라도, 정해진 패턴과 버그 없이 만들려고 한 완성도 그리고 유닛 테스트 및 문서까지 완성된다면 뽑을 의향이 있습니다. 이 포트폴리오는 이력서에 포함시켜서, 나중에 이력서를 검토해 보는 사람들이 github repository에 갔을 때 구직자의 실력과 스타일을 파악하는데 많은 참고가 될 것입니다. 남의 코드를 참조는 하나, 자신의 것으로 녹여보려고 해야 하며, 본인이 직접 만들고 이해한 것이 아닌 이상 면접을 볼 때 이미 판가름이 납니다.

 

그런데 아래에 제가 적으려는 내용은 추가적으로 더 했을 경우 플러스 점수가 가해지는 것입니다. 저는 힌트만 드리는 것일 뿐 찾아보고 공부하는 것은 본인이 직접 하시는 것을 추천합니다. 기본적으로 만들어진 게시판을 통해서 본인의 영역을 확장시켜 나가는 것입니다.

 

• 로그인/회원 가입 기능 추가 
• Authentication/Authorization 추가를 위해 JWT ( https://jwt.io/ )와 같은 Token을 REST API에 추가 하는 것입니다. 생각보다 큰 범위의 작업입니다. 보안에 관련 지식을 많이 요구하지만 개발을 완성하고 나면 얻는 것도 많고, 큰 플러스 점수가 있을 것입니다. 
• HTTPS를 위한 SSL 인증서
• REST API에 Swagger 입히기
• REST API의 문서를 위해서도 있지만, 다양한 언어의 client를 만들 수 있습니다.
• Docker 안에 frontend와 backend를 모두 포함시켜 보면 좋습니다.
• BDD 기반으로 Selenium tests 작성
• Android/iOS, react native, flutter와 같은 다른 클라이언트 개발Swagger를 응용해서 자동으로 만들어진 REST client를 사용해 봅니다.
• 이미 REST API를 통해서 개발되어 있기 때문에 다른 클라이언트를 개발해 보면 좋습니다. 물론 이 클라이언트에서도 유닛테스트는 같이 포함되어 있어야 합니다.
• 작성자가 작성한 게시글에 누군가 덧글을 달면 Push notification이 발송되는 기능 개발 앱을 개발했다면 Push notification을 받을지 안받을지 선택할 수 있게 해야합니다.
• Firebase를 이용하면 됩니다.
• 많은 사용자와 게시글 수 증가로 인한 시스템 Scaling을 어떻게 할지 디자인
• 정말 많은 사용자들이 늘어나, 덧글 Push notification을 아주 많이 발송해야 할 경우 어떻게 할지 디자인

 

제 의견으로는 처음부터 아주 거창한 것을 고민해야 할 필요는 없습니다. 괜찮은 회사의 경우 웹이어야 하나, 앱이어야 하나도 요즘에는 크게 의미가 없습니다. 저의 논점은 회사 입장에서 제대로 된 개발자를 뽑는 프로세스 및 마인드를 갖추었다고 하면, 신입을 뽑는데 있어서 Frontend와 Backend의 포지션도 그렇게 중요하지 않습니다. 얼마나 프로젝트를 만드는데 고민하였는가, 그 완성도는 기능과 상관없이 얼마나 탄탄한가. 한줄의 코드를 짜더라도 이 부분을 정확하게 이해하고 실행해 옮겼느냐 입니다.