곰개발자
2019-12-22 10:06:46 작성 2019-12-22 23:20:53 수정됨
28
13386

취직 준비를 위해 좋은 포트폴리오 만드는 방법


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

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


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

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

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

    이미 REST API를 통해서 개발되어 있기 때문에 다른 클라이언트를 개발해 보면 좋습니다. 물론 이 클라이언트에서도 유닛테스트는 같이 포함되어 있어야 합니다.

    Swagger를 응용해서 자동으로 만들어진 REST client를 사용해 봅니다.

  • 작성자가 작성한 게시글에 누군가 덧글을 달면 Push notification이 발송되는 기능 개발 

    Firebase를 이용하면 됩니다.

    앱을 개발했다면 Push notification을 받을지 안받을지 선택할 수 있게 해야합니다.

  • 많은 사용자와 게시글 수 증가로 인한 시스템 Scaling을 어떻게 할지 디자인

  • 정말 많은 사용자들이 늘어나, 덧글 Push notification을 아주 많이 발송해야 할 경우 어떻게 할지 디자인


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

42
63
  • 댓글 28

  • traces
    36
    2019-12-22 17:08:37

    좋은 글 잘 읽었습니다~

    그런데 궁금한 점이 있는데요, 중간에 "DB는 stored procedure를 만들어서 처리하는 것을 추천합니다." 라고 쓰신 것에 대해 이유를 알 수 있을까요~?

    0
  • 곰개발자
    2019-12-22 21:24:21

    여러가지 이유가 있습니다. caching 되어 있어 있거나, network traffic이 적거나, logic을 분리하면서 optimization 하기 편하거나 컴파일 없이 db수정으로 될 수 있는 부분도 있고, SQL injection 공격에 좀 더 낫습니다. 

    0
  • 39Song
    659
    2019-12-22 22:01:46

    취준생인데 좋은 글 감사합니다~!

    로그인, 회원가입, crud게시판(검색+목록갯수+페이지네이션) 같은 기능을 구현하고

    로그인 RSA 적용, github을 이용한 협업, AWS EC2 호스팅, DB 설계 등을 해보고 어떤 것을 더 해야하나 고민을 했는데 감이 잡혔습니다!

    공부를 할수록 재미 성취감도 있지만  부족함을 느끼고 공부할게 더 많아지는게 느껴집니다...ㅠ

    0
  • Frudy
    4k
    2019-12-22 23:06:59 작성 2019-12-22 23:07:31 수정됨

    오우야.... 되게많군요. 감사합니다.

    한참 뉴비레벨이었군요. ㅜㅜ

    0
  • Yuu2
    2019-12-23 09:13:09

    열심히한 전공자기준인거 같네요.

    6개월 배우고 하기엔 허들이 높은거같은데요?

    2
  • 항상어렵지
    204
    2019-12-24 14:27:19

    이제 1년하고 한두개월 지난 초급 개발자 입장에서 이글을 읽어보니 내가 과연 이걸 다 할 수 있을까 싶네요.

    짬짬히 공부하며 만들어봐야겠습니다.

    좋은글 감사합니다.

    0
  • 으째
    59
    2019-12-26 09:26:56

    stored procedure? free database?

    0
  • 성남FC
    390
    2019-12-26 09:50:48

    포폴 만들어야지 만들어야지 하다가 쓰신글 보고 바로 시작 했습니다.

    정말 감사합니다 !!!

    0
  • 고고씽~
    335
    2019-12-26 11:22:39

    글쎄요..

    개발 20년차이고 사업본부장을 맞고 있지만

    저정도를 다 할 수 있으면 그냥 고급인데요??


    개발자 초급에게 저정도를 요구하는 것은 중소기업에서 국제 회계자격증에 

    영어, 중국어, 일본어 마스터에 무역 실무 완벽하게 할수있고 영업까지 가능한 인재를 월 200에 구한다는 소리와 같습니다.


    정말 저정도 하는 인재를 뽑는거 맞아요?

    구글 다녀요? 아님 마소?? 페이스북??

    내가 MIT 전산과 수석 졸업한 학생을 데리고 프로젝트 해 본적 있습니다.

    MIT 전산과 수석 졸업생과 프로젝트 경험 있어요??

    그 학생이 잘하지만 어떤 수준인지 아세요?

    그 학생과 다른 학생이 서울대 전산과 수석 졸업생이었는데 그 학생도 수준이 어떤줄 아세요?


    그리고 글쓴이도 저 부분을 완벽히 할줄 아세요?

    대부분의 전산직의 90%가 SI인 상황에서 저 스팩을 맞춘다는게 가당키나 하나요?

    우리 회사 주요 고객이 삼성SDS , 전자, 물산 등입니다.


    그 회사 초급 수준이 어떤줄 아세요?

    꿈 같은 소리로 취준생 사기 꺽는 소리랑 집어 치우고 현실적인 대안을 말씀하세요.


    취준생 여러분 개발은 원래 힘듭니다.

    눈에 보이질 않아요. 우리 세대는 개발기술과 같이 성장했기에 개발 습득에 대한 익점이 상당했습니다.

    지금 취준생들은 아주아주 이미 꽉 짜여진 개발 기술에 쫓아 가는 것도 힘든 상황입니다.


    너무 급하게 생각하지 말고 기초를 잘 습득한다는 자세로 임하세요.

    초급 수준은 거기서 거기에요.

    내가 주로 눈 여겨 보는 사람들은 태도를 봅니다.


    업무를 대하는 태도, 사람을 대하는 태도, 개발을 대하는 태도 등등...

    초급은 초급읭 영역이 있습니다.


    너무 겁먹지 말고 차근 차근 하세요.

    3
  • 곰개발자
    2019-12-26 12:22:20 작성 2019-12-26 12:52:19 수정됨

    고고씽~ 

    좋은 말씀 감사합니다. 제가 적은 것을 모두 다 할 수 있는 취업 준비생은 없다는 것에는 동의 합니다. 

    제 글의 논점은 최대한 가지고 있는 실력 범위 내에서 완성도를 높이는데 중점을 두는 것이 좋다는 것이었습니다.

    본부장님 이시면 한국 IT가 어떻게 돌아가고 있는지 잘 알고 계실 거라 판단됩니다. 

    제가 생각하는 한국 IT 회사의 문제점을 솔직히 말씀드리면, 기존에 구시대적인 생각을 가지고 있는 경력만 많은 분들이 초급, 중급, 고급과 같이 기준도 명확하지 않은 잣대로 구분지어서 실력으로 인정받고 그에 따르는 연봉을 받을 수 있는 문화가 막히고 있다는 것입니다. 돈은 실력으로 받는 것이지, 경력 연차로 받는 것이 아니거든요.

    경력의 연차는 숫자에 불과합니다. 저도 많은 면접을 봐오면서 아주 많은 사람들을 만나 보았고, 성실히 공부한 졸업자가 경력 10년 되는 사람보다 괜찮은 실력을 가진 케이스를 많이 보았습니다. 저 위의 포트폴리오 대로 노력한 신입 친구들도 많이 보았습니다.

    왜냐하면 한국은 대학교 졸업 했으면 거기서 거기겠지 라고 깔고 보는 습성이 강하거든요. 그래서 실력있는 젊은 개발자분들이 한국에서 일 안하고 해외로 나가는 이유이기도 하겠습니다. 

    좋은 지적해주셔서 감사합니다. 어찌보면 제가 적은 저 포트폴리오 방법은 구시대적인 회사를 제외하고, 열린 마인드를 가지고 있는 실력대로 인정해 주는 좋은 회사를 선택하기 위한 방법이라고 하는게 맞아 보입니다.

    5
  • miraee05
    144
    2019-12-26 12:53:51

    매번 좋은글 써주셔서 감사합니다. 웹쪽에서 항상 어떻게 개발을 하면 잘 할수 있을까에 대한 고민이 많았는데, 제가 생각했던 부분이 잘 들어있고 또 정리도 잘 되어있는것 같습니다.


    일례로 처음 프로젝트에 브라우저 테스팅(셀레늄은 아니고 헤드리스 브라우저)로 시작했다가 피드백이 조금 느린거 같아 현재는 스토리북으로 변경하고 아주 만족스러웠습니다. 써주신 글을 보니 테스트에 적합한 테스팅 도구를 쓰신다는 것이 제게는 아주 인상 깊었습니다. 이전에 버렸던 도구를 조금 더 활용해 봐야겠습니다.


    다른부분에 있어서도 평소 실천하고 있지만 확신이 없었던 것들이 많은데, 덕분에 방향성이 잘 잡히게 된것 같습니다

    1
  • 고고씽~
    335
    2019-12-26 14:29:48

    #곰개발자님

    제 언사가 좀 거칠었습니다.

    어린 친구들에게 너무 과한 의무를 지우는 것 같아서 안쓰런 마음에 그런것 같습니다.


    요즘 어린 친구들이 괜히 주눅들고 그럼 모습이 괜히 안쓰럽습니다.

    머리도 좋고 센스도 좋은 친구들이 자신들의 실력도 뽑내보지 못하고 이리 저리 눈치만 보는 상황도 저도 맘이 불편합니다.


    우리나라가 SI 위주의 사업 구조에서 벗어나지 못하는 한 이런 일이 주로 되리라는 것도 자명합니다.

    하지만, 진흙탕속에서도 꽃이 피듯이 이런 처박한 환경에서도 누군가는 튀어 나가리라 봅니다.


    실수해도 괜찮다 좀 돌아가도 괜찮다고 우리세대가 뒤를 받쳐줘야 할것 같습니다.

    곰개발자님께서도 좋은 의도로 글을 쓰셨는데 괜히 객적은 글 적어 민망합니다.


    건승하시길바랍니다.

    5
  • Anonymousss
    193
    2019-12-26 19:08:44

    저도 이제 취직 6개월차지만 이걸 이정표로 삼아도 될 것 같네요.... 비전공 국비출신이라 그런지.... 컴공 졸업생분들은 신입 때 저 정도 포폴을 완성해서 가진 분이 있나요?

    0
  • 보보보보
    669
    2019-12-27 00:13:06

    게시판도 게시판 나름이긴하겠네요 ㅋㅋㅋ

    근데 제 생각은 조금 다르긴합니다.

    저 실력으로 단순 게시판으로 승부하기엔 조금 아쉬운 느낌이랄까요...

    전체적인 틀은 마치 잘 제시된 로드맵처럼 깔끔한 것 같아요

    0
  • 자라선
    1k
    2019-12-27 09:57:09

    이미 지났지만 스토어드 프로시저를 강구하는 이유를 잘모르겠습니다.

    위에도 적어주셨지만 이해가 안가는게

    sql 인젝션은 현재 이미 보편화된 수많은 JPA덕에 사실 대체할수있고

    컴파일을 하지 않고 즉 무중단배포로 수정할수있다는 이유는 그다지 좋은 예시는 아닌것 같습니다

    네트워크 트래픽을 최소화할수있다는 말씀 또한 그렇구요..


    오히려 데드락의 위험성을 증가시키는게 아닐까 합니다.


    댓글이 공격적이라면 죄송합니다. 제가 스토어드 프로시저의 이해도가 낮거나 잘 모르는 신입이지만 정말 궁금해서 댓글 달아봅니다!

    0
  • 곰개발자
    2019-12-27 10:40:00 작성 2019-12-27 11:16:05 수정됨

    // 자라선

    질문 감사드립니다. 

    SQL 인젝션부터 설명 드리겠습니다. 일단 일반 쿼리나 stored procedure의 경우는 injection을 방어 할 수 있습니다. 실수를 적게 유발 시키지 않을 수 있다는 의미입니다. 

    JPA는 ORM의 영역인데 이건 Architecture 선택의 문제입니다. 저는 개인적으로 ORM을 선호하는 편은 아닙니다. 이유를 길게 적는 건 다음 기회에 제가 하겠지만, 간단하게 이야기 하자면 프로젝트가 커질 수록 유지보수 하기가 힘들다는 단점을 경험했습니다.

    무중단 배포라의 것의 함의적인 의미는 로직이 분리되어 있다는 것입니다. 그 말은 별도로 stored procedure의 테스트를 작성하기에 용이할 수 있습니다. 

    이전에 SI를 하다가 경험했던 일 중에 하나 입니다. 저 조차도 stored procedure가 상식이라고만 기계적으로 인식하고 있었습니다. 10개 넘는 협력 업체 팀들이 본인의 서비스 안에서 쿼리를 날리고 있었는데 결국은 db가 죽거나 deadlock이 걸리는 문제가 발생했습니다. 

    해결방안은 갑 업체에서 10개 업체를 쪼아서 코드에 있는 쿼리를 다 가져오라고 하고, execution plan 다시 돌려보면서 1주일동안 모든 업체가 밤새면서 작업을 했던 기억이 있습니다.

    저는 이 문제를 처음에 Architcture 선택을 잘 못 하여 하나씩 부채들이 쌓인 큰 재앙으로 생각합니다. Stored procedure를 만들고 성능 측정 logging 및 테스트 툴만 제대로 있으면 최대 1시간 이내에 잡을 수 있는 문제를 말이죠.

    복잡한 쿼리를 날려서 보내는 것보다 stored procedure 보내는게 네트워크 트래픽의 절감에는 도움줄 수 있다는 의미입니다.

    특히나 데드락은 Stored procedure를 잘 못 만든 개발자의 잘못이지 이 방법을 사용해서 발생하는 문제는 아니라고 생각합니다.



    0
  • 자라선
    1k
    2019-12-27 11:11:12

    @곰개발자

    성의있는 답변 감사합니다.

    소, 중 프로젝트만 생각하고있었는데 대형 프로젝트에서는 그런 이슈가 있나보군요

    아키텍쳐까지 넘어오니 할말이 없네요 ㅋㅋ;;


    이참에 스토어드 프로시저의 활용법에 대해서 다시 한번 알아봐야겠습니다.

    직접 경험하신 내용을 토대로 답변 주신거 감사합니다. 역시 경험담 만큼 신뢰할수있는 내용이 없는것 같습니다.

    1
  • 초보괴발자
    82
    2020-01-04 14:09:28

    답변 달아주신 것 보고 왔습니다. 

    궁금한 점이 많은 개발자들을 위해 이렇게 자세히 적어주셔서 감사합니다. 

    0
  • B급 개발자
    633
    2020-01-04 20:18:00 작성 2020-01-04 21:50:06 수정됨

    굉장히 좋은 글이군요. "취직 준비를 위한 포트폴리오 만드는 방법" 이 아닌 "제대로 된 프로젝트를 구축하기 위한 A부터 Z까지" 라고 제목을 붙여도 좋을 만큼 모든 과정에서의 원칙을 제시하고 있네요. 여기엔 언급된 용어들만 공부해도 많은 도움이 될 것 같습니다. 많이 배우고 갑니다.

    그리고 stored procedure에 대한 견해 또한 일부 공감합니다. 보는 관점에 따라서 충분히 살아있는 기술인데 우리 주변에서는 해 보지도 않고 부정적으로 보는 인식이 다분히 있는 것 같습니다. 다만 장점으로 설명하신 부분이 오히려 단점이 될 수도 있고 특히 DBMS에 의존적이기 때문에 시스템의 수명이 다 되는 등 기술에 대한 교체가 발생할 경우 이관 이슈가 발생할 수 있는 점은 고려해 봐야 한다고 생각합니다.

    0
  • [개발새발]
    277
    2020-01-12 13:57:28

    취준생입니다. 그리고 어제 취준을 위한 포트폴리오 기능 구현까지 완료했습니다. 잠시나마 들뜬 마음이었지만.. 오늘 이 글을 보며 상당히 많은 부분이 미흡했다는 것을 자각하게 됩니다.

    하지만 윗분들 그리고 곰개발자님께서도 말씀해주셨듯이 위의 모든것을 담아낸 포트폴리오를 신입이 만들기란 현실적으로 많은 어려움이 있습니다.

    다만, 이 글이 너무나 좋은 점은 대부분의 신입이 가지고 있는 매우 비슷한 게시판 포트폴리오에 스스로 국한되지 않도록 방향성을 제시해주는 것입니다.

     지난 한달동안 나름대로 구현한 코드들을 새로운 관점에서 리팩토링하고 더 나은 프로그래밍 패턴을 공부할수 있는 좋은 기준점이 될 것같습니다

    곰개발자님께서도 어려운줄 알면서도 "취준을 위한"이라는 표현을 쓰신 것에서 어쩌면 한국의 개발문화를 새롭게 이끌어갈 세대에 대한 진심어린 애정이 아닌가 싶습니다. 


    (다만, 혹시 아직 포트폴리오를 시작하지 않은 취준생 여러분들은 해당글에 너무 부담갖지 않으셨으면 좋겠습니다. 저도 포트폴리오 만들기 전에 디자인패턴이나 아키텍쳐에 대해 너무 거창하게 생각하다보니 스스로 늪에 빠지게 됩니다. 우선, 처음이시라면 구현하고자 하는 기능을 최대한 구현해보고 그다음 리팩토링하는 것이 더 효율적인 방법이 아닐까 합니다 ㅎㅎ 올해에는 모두 다같이 취업합시다 ㅎㅎ)



    0
  • 주니별
    50
    2020-01-19 17:54:08

    좋은 글 감사합니다.

    전 국비과정 약 1달반 남겨놓은 상황에서 마지막 프로젝트를 어떻게 시작할지 고민중이었습니다.

    뭔가 기능이나 알고리즘 같은 게 거창한 걸 해야하나 싶었는데, 이 글을 보고 그런 생각이 싹 사라지네요.

    REST라던가 유닛테스트 등 알긴 알았지만 솔직히 귀찮아서 제대로 공부도 안하고 사용하지 않은 채

    기능만 잘 동작하게 대충 코드 짜고 있었는데 다시금 저를 돌아보게 됩니다.

    기본부터 다시한다는 생각으로 마지막 프로젝트 도전해보겠습니다. 감사합니다. 😊

    0
  • Rayor
    120
    2020-01-23 10:23:26

    요즘 하루에 한번 이 글을 다시 정독하면서 방향에 대해서 배우고 있습니다.

    곰개발자님의 글이 깜깜한 바다에서 비춰지는 등대같아요 ㅠㅠ.. 감사합니다

    0
  • ignoreOrange
    1k
    2020-02-11 16:51:39

    이글을 이제 보내요 감사합니다

    가이드처럼 보면서 개발에 임하겠습니다.

    0
  • 음메리카노
    16
    2020-03-03 09:53:20

    좋은글 잘 봤습니다.

    0
  • 도돌이표11
    2
    2020-03-03 14:08:45 작성 2020-03-03 14:37:21 수정됨

    나머진 공감합니다만, DB에서 stored procedure를 사용하란 말엔 의문이 생기네요. 

    저는 stored procedure로 구성된 레거시 쿼리를 파악하기 너무 힘들었어요. 사이드이펙트를 몰라서 수정하는 것도 너무 힘들었고, 히스토리도 알기 어려웠습니다.

    그래서 저는 stored procedure로 풀 수 있다 하더라도 어플리케이션에서 코드레벨로 해결하는 방향으로 진행하고 있습니다.

    그러면 장점이, 테스트코드에서 우선 로직의 무결성이 보장되기도 하고, 이후에 참여하는 인원이 로직을 파악하기 더 쉽고, commit 단위로 히스토리 파악이 쉽다고 생각합니다.

    0
  • mcauto
    2
    2020-03-03 22:52:43 작성 2020-03-03 23:09:21 수정됨

    좋은 글 잘 읽었습니다! 

    하지만 stored procedure 사용에 대해서는 반대하는 입장입니다.

    1)버전 관리, 2)가독성(글을 읽는 순서는 위아래, SQL은 from where select 순에 nested면 더)으로 발생하는 단점들이 장점보다 크다고 생각합니다.

    추가로 SQL 학습은 다음과 같은 이유로 ORM을 사용을 권장합니다. 

    1) Model 객체의 설계 스킬
    2) ORM이 만들어주는 모델에 최적화된 query와 그 실행 계획 분석을 통한 스킬
         (DB 종류에 따라 자동으로 SQL을 바꿔서 볼 수 있음 ex) mysql, mssql, postgre, oracle)

    SQL 인젝션은 prepared statement와 post condition validation check를 사용하는게 좋을 것 같습니다.

    말씀해주신 대규모 프로젝트에서 여러 서비스가 하나의 DB를 바라보고 query를 날려서 발생한 문제에 대한 경험은 전체적인 시스템 설계의 문제로 보입니다.

    제가 모든 상황을 다 알지 못해서 이야기하기에는 조심스럽지만, 개인적인 생각으로는 REST API 서비스 하나가 DB를 바라보고 다른 서비스들이 REST API 서비스를 요청하도록 설계했다면 어땠을까 합니다.





    0
  • 음 지나가는 1년차 개발자인데요, 글쓴이의 글과 댓글들을 보면서 무조건적으로 글쓴이의 포트폴리오를 옹호하진 않지만 큰 틀에서는 되게 알찬 내용들을 적었다고 생각을 해봅니다ㅎㅎ
    백엔드 개발자로 지원한 저도 여러 면접과 지원을 하면서 느낀점이 github, rest api, rdms, unit test, jwt token 사용 경험등이 좋은 플러스 요소들로 작용한거 같았거든요.

    추가적으로 요구하신 내용들도 물론 실무에서 알면 좋은 지식과 테크라고 생각을 하고 오랫만에 좋을 글 읽고 갑니다ㅎ

    0
  • 호빵
    332
    2020-05-21 18:29:38
    정말 좋은 글 잘 읽었습니다 
    0
  • 로그인을 하시면 댓글을 등록할 수 있습니다.