221020 지도 심화기술 제외 기술스택 결정 완료

샨티(shanti)·2022년 10월 20일
0
post-thumbnail

하루를 마무리 하기 전, 오늘 있었던 일들을 잔잔히 되짚어봅니다.
성공과 실패의 모든 요소에서 '배울 점'을 찾아내어 기록하고,
더 성장하는 내일의 나를 위해 'action plan'을 세웁니다.

어제 집에서 기술스택을 더 알아보다가 소파에서 잠들어버린 바람에 새벽에 약간 조급한 마음으로 성수 코딩도장에 도착했다.
나름 마음에 정해두었던 데드라인이 있어서.. 넘기고 싶지 않다는 생각에 오전부터 빠르게 리액트와 그 외 보충하고 싶었던 자료들을 검색하고 정리해서 1차 기술스택 결정 및 자료 조사를 마무리지었다.
지도 구현과 관련해서는 클러스터링 등 아직 모르는 개념들이 많아서 프로젝트를 진행하면서 더 공부를 해야할 영역으로 남겨두었다. 이번 계획을 가지고 개발에 돌입하겠지만 스크럼 책에도 나와있듯이 완벽하게 끝까지 가는 계획은 없다. 끊임없이 과정 중에 수정되어야 하고 유연하게 적용되어야 하고... 하루 하루 '동작하는 코드'를 만들어내기 위해 결과중심적으로 움직일 것을 다시한번 다짐하면서!!

오늘 정리한 백엔드 개발 관련 프레임워크, 프론트엔드 개발 관련 언어 & 라이브러리, 기타 기술스택 정한 내용을 아래와 같이 공유한다.


백엔드 관련 프레임워크

하나. Spring

  • 자바 웹 애플리케이션을 개발할 수 있는 프레임워크. 오픈소스

  • 스프링은 경량 컨테이너로서 자바 객체와 라이브러리 등을 직접 관리함. 또한 WAS(Web Application Server. 웹 애플리케이션과 서버 환경을 만들어 동작시키는 기능을 제공하는 소프트웨어 프레임워크) -> 스프링에는 예로 톰캣이 내장되어 있어 애플리케이션을 구동할 수 있도록 함

  • (알아가기) 경량 컨테이너란?
    컨테이너란 어떤 환경에서나 실행하기 위해 필요한 모든 요소를 포함하는 표준 소프트웨어 패키지. 애플리케이션의 코드를 관련 구성 파일, 라이브러리 및 앱 실행에 필요한 종속성과 함께 번들로 제공함(경량 인프라를 제공하여 어떠한 환경에서도 애플리케이션이 잘 실행될 수 있도록 컨테이너를 사용하여 약간의 수정, 또는 전혀 수정하지 않고도 여러 환경에 애플리케이션 배포 가능)

  • 한국에 한정되기는 하나, 전자표준 프레임워크이고 개발과 관련된 공공사업 전반에 적용되므로 수요가 큼

  • Spring의 주요 특징들(세부내용 생략)

    • DI(Dependency Injection)
    • IoC(Inversion of Control) 컨테이너
    • POJO(Plain Old Java Object) 기반 구성
    • AOP(관점지향 프로그래밍) 지원

둘. Django

  • 파이썬 기반 프레임워크. 오픈소스
  • 사이트 맵, 컨텐츠 관리, 사용자 인증 등을 자동으로 처리해주는 다양한 기능 갖춤
  • 많은 보안 기능이 포함되어 있어 클릭재킹, SQL Injection과 같은 일반적인 보안상 오류를 방지해줌

셋. Node.js

  • 기존에 자바스크립트에 있어서 유일한 런타임(프로그램이 실행되는 환경)은 ‘브라우저'였음. Node.js가 브라우저 밖에서 자바스크립트를 사용할 수 있는 환경을 제공하게 되면서 자바스크립트로 클라이언트&서버사이드를 개발할 수도 있고 애플리케이션도 만들 수 있게 됨
  • 정의. 크롬 V8 JavaScript 엔진으로 빌드 된 자바스크립트 런타임
  • 자바스크립트를 웹 브라우저에서 독립시킨 것으로 Node.js를 설치하면 터미널에서 node.js를 입력하여 브라우저 없이 바로 실행 가능. 한 가지 언어로 전체 웹페이지를 만들 수 있다는 점에서 의의가 있음
  • 특징(세부내용 생략)
    - 논 블로킹
    - 싱글 스레드-비동기 방식
    - event loop
    - 내장 HTTP 서버 라이브러리 포함

Spring을 선택한 이유

  • 백엔드 개발로 선택한 메인 언어가 자바
    따라서 자바 기반의 애플리케이션 프레임워크인 Spring을 우선 선택

  • 스프링부트 프로젝트 생성 시 다양한 의존성 주입
    내장서버 톰캣, 레포지토리 활용을 위한 JPA 인터페이스, 보안을 위한 Spring security framework, 개발 시 가볍게 활용할 수 있는 DB관리 시스템 H2 DB 등. 위 사항들을 활용할 수 있어 개발자가 일일이 프레임워크, 인터페이스, 라이브러리를 관리하지 않고도 주입된 것을 '활용'하며 개발에 집중 가능

  • DI를 통해 생산성을 꾀할 수 있음
    외부에서 의존성을 주입하므로 초기 '의존관계'를 설정하고 나면 이후 의존관계를 관리하는 것은 스프링이 담당


프론트엔드 언어 및 관련 프레임워크, 라이브러리

프론트엔드(Front-End)

  • 사용자가 볼 수 있는 화면, 즉 사용자 인터페이스(User Interface, UI) 영역
  • 프론트엔드는 사람들이 웹 애플리케이션을 쉽게 사용할 수 있도록 기술적으로 구현되어 있어야 함
  • 주 사용 언어로 JavaScript, TypeScript, HTML, CSS(프로그래밍 언어는 아님) 등

프레임워크 / 라이브러리 사용 이유

  • 과거의 웹 페이지와는 달리 최근 웹은 단순 정적 웹페이지가 아니며 유저와의 다양한 인터랙션이 일어남. 사용자와의 활발한 인터랙션이 없는 정적 웹페이지라면 굳이 라이브러리가 필요하지 않을 수 있으나 인터랙션이 없는 페이지가 과연 현대 시대에서 유효할 것인가
  • 각 요소(리액트의 경우 DOM 요수)를 직접 관리하거나 코드를 정리하는 것이 어려움
  • 대표적으로 Angular, Ember, Vue, React 등

관련 프레임워크 or 라이브러리

하나. 리액트(React)

  • 컴포넌트 기반. 라이브러리
  • 버츄얼 돔 방식에 있어서는 뷰와 공통점을 가짐
  • 특징
    - 컴포넌트 기반
    웹 UI를 컴포넌트라는 단위로 구성하며 이 컴포넌트는 재사용성이 뛰어남
    - 버츄얼 돔(Virtual DOM)
    버츄얼 돔 개념이 없다면, HTML 파일에 변경이 가해진 횟수 만큼 DOM 노드가 변경된 이후 과정 역시 그 횟수만큼 진행됨. 잦은 변화가 일어날 경우 성능 저하
    버츄얼 돔은 view에 변화가 생기면 그 변화가 실제 DOM에 적용되기 전 버츄얼 돔에 먼저 적용시킨 뒤에 최종 결과만 실제 DOM에 전달함으로써 성능 저하를 피함
  • 자바스크립트에서 HTML과 유사한 형태로 코드를 작성할 수 있는 JSX 기반 컴포넌트 구문을 사용하므로 코드가 직관적이고 가독성이 좋음

둘. Vue

  • 프레임워크
  • 러닝커브가 리액트에 비해 낮은 편이고 입문자들이 사용하기에 쉬움
  • 특징
    - 단일 파일 컴포넌트
    - HTML 기반 템플릿 구문
  • 작고 가벼운 애플리케이션을 개발하거나, 시장 진입 단계에서 필요한 프레임워크를 선택할 때 적합

셋. Angular

  • 프레임워크. 타입 스크립트 기반
  • 크로스플랫폼 애플리케이션을 만드는 데 사용할 목적으로 만들어졌음
    - 크로스플랫폼 애플리케이션 개발이란? 한 가지 개발 언어와 프레임워크로 각기 다른 플랫폼에서 애플리케이션을 구축하는 것(<->네이티브 애플리케이션 개발)
  • 프로젝트 생성, 테스팅, 빌드, 배포까지 모든 기능을 제공함

JavaScript + React를 선택한 이유

  • 큰 커뮤니티, 기업이 지원하는 점
    페이스북(현 메타)이 개발 및 지원하고 사용자가 확대되어 커뮤니티가 크다는 장점. 지속적인 버전 관리가 가능하고 사용자가 많다는 점은 레퍼런스, 확장 라이브러리의 규모, 참고 자료의 pool이 크다는 점과 연결됨. 현재 개발하려는 서비스에 '지도' 관련 기능이 추가되어야 하며 이 기술 구현의 난이도가 상당한 만큼 참고자료의 필요성이 높다고 생각하여 위 장점이 매력적으로 느껴졌음

  • 타 언어와 비교했을 때 얻을 수 있는 장점과 이득이 크다고 생각
    Angular의 경우 프로젝트 생성, 테스팅 빌드, 배포와 같은 기능을 종합적으로 제공하나 배포와 관련해서는 다양한 대체재 및 이미 개발자가 경험해 본 타 서비스가 있으며, 타입스크립트 언어 이해도가 없는 상황에서 해당 언어를 기반으로 한 프레임워크를 선택해야 하는 당위성이 떨어짐
    Vue는 러닝커브가 낮다는 장점이 있음. 다만 현재 구현하려는 서비스의 규모를 고려했을 때 view를 구성하는 코드가 하나의 파일에 모두 정의된다면 추후 서비스 유지보수 및 리팩터링과 관련한 부분에서 단점으로 부각될 것으로 예상


DB 관련: PostgreSQL

해당 DBMS 선택 이유와 근거

  • 완전한 무료 오픈소스
    상업 목적이 아니며 엔터프라이즈 규모로 개발하고 있지는 않으므로 무료임이 보장되는 오픈소스를 활용하려고 함

  • 지도와 관련된 자료형 등 다양한 데이터 타입 지원
    서비스 개발 초기 완벽하게 정의하기 힘든 DB의 형태나 스키마(SQL 사용 시) 때문에 좀 더 유연한 NoSQL인 mongoDB를 고려하였으나 PostgreSQL을 이미 사용해 본 상태에서 조사중 지도 관련 데이터 타입인 Geometric, Text search(텍스트 검색 관련), JSON 형태의 타입을 지원하는 것을 확인하였으므로 해당 DBMS 선택


오늘 기술 스택을 모두 정했고 노아님과 함께 기획 단계에 대해 간략히 이야기를 나눴다.
예전에 활용하려 했던 기획서가 노아님이 주신 예시와 비슷해서 얼른 만들고싶단 생각이 들었다.
시간이 좀 오래 걸릴 것 같지만.... 주말 내에 기획서를 모두 마무리지어야지!

기획서를 만들면서 이 서비스를 '왜' 만드는 것인지를 계속 상기해봐야겠다.
물론 취업준비를 위한 '포트폴리오'용 서비스이나 이를 통해 내가 배우고자 하는 것이 무엇인지, 고객들에게는 이 서비스가 '왜' 의미있고 가치있는지를 반복적으로 떠올리면서.

흔들리지 말고 고!!!

profile
가벼운 사진, 그렇지 못한 글

0개의 댓글