Git은 알려진 툴 중 가장 널리 사용되고 있는 형상관리 및 협업을 위한 도구이다. 개인이 혼자 프로젝트를 진행한다면 자신이 작성한 코드는 곧바로 메인 master 브랜치에 push와 commit을 해도 본인만 해당 버전에 대해 알아볼 수 있다면 크게 상관이 없다. 하지만 협업을 하거나 누군가에게 코드를 공유해야 하는 오픈소스 프로젝트라면 단순히 메인 브랜치에 commit만 남발했을 때 언제 리비전 되었고 무엇을 위한 수정이었는가 등에 대한 질문들을 무수히 받게 될 수도 있다. 이런 리스크는 깃 브랜치 전략(Git Branching Strategy)을 통해 어느 정도 예방할 수 있다. 더 많은 방법론이 존재하지만 가장 범용적이라 생각되는 4가지를 선별해 보았다. Git Flow 우선 Git Flow이다...
주요 개념 개발 서버(Development Server) 스테이징 서버(Staging Server) 프로덕션 서버(Production Server) 스테이징 서버(Staging Server)란 Production으로 가기 전 임시서버라 볼 수 있다. 즉, 운영환경에 적용하기 전에 확인하는 서버를 의미한다. 약어로 "ST 서버"라고도 부르기도 한다. 개발자 로컬PC -> (소스저장소) -> 빌드서버(CI서버) -> 개발서버 -> 테스트서버 -> 스테이징서버 -> 운영서버 간략히 아래의 그림과 같이 표현할 수도 있다. 참고 자료 https://ecogeo.tistory.com/tag/%EC%8A%A4%ED%85%8C%EC%9D%B4%EC%A7%95%EC%84%9C%EB%B2%84 https://conflue..
우선 Proxy Server(프록시 서버)란 클라이언트가 자신을 통해 타 네트워크 서비스에 간접적으로 접속하도록 해주는 서버이다. 서버와 클라이언트를 이어주는 역할을 수행하는 중계 서버로 볼 수 있다. 이 프록시 서버를 통해 보안성과 성능 및 안정성 향상 효과를 기대할 수 있다. 프록시 서버는 Forward Proxy Server와 Reverse Proxy Server로 나눌 수 있다. Forward Proxy Server 우리가 일반적으로 지칭하는 프록시 서버는 Forward Proxy Server를 의미한다. 포워드 프록시 서버는 클라이언트 앞에 연결된 부분이다. 아래 그림과 같이 사용자(You)에 해당하는 클라이언트가 인터넷 웹서버에 요청을 보내면 그 중간에 포워드 프록시 서버가 먼저 요청을 수신한..
RESTFul API를 구현하거나 네트워크 이미지를 사용하는 경우 종종 URL(Uniform Resource Locator)과 URI(Uniform Resource Identifier)라는 단어를 접하게 된다. 위 두가지와 함께 추가적으로 URN(Uniform Resource Name)이라는 것도 있다. 이를 이해하기 전 우선 우리가 인터넷 환경에서 자원을 식별하기 위해 사용하는 방법에는 Path Variable 방식과 Query Parameter 방식이 있다는 것을 알아야 한다. 아래는 Path Variable 방식의 예이다. /user/id /user/image /user/address 아래는 Query Parameter 방식의 예이다. /user?job=programmer /user?job=prog..
오버로딩과 오버라이딩은 이름이 비슷해 자주 헷갈리는 개념이다. 간단하게 말하면 오버로딩(Overloading)은 같은 이름의 메소드 여러개를 가지면서 매개변수의 유형과 개수가 달라도 되도록 하는 기술이고, 오버라이딩(Overriding)은 상위 클래스가 가지고 있는 메소드를 하위 클래스가 재정의해서 사용하는 것을 뜻한다. 오버로딩(Overloading) 우선 오버로딩(Overloading)은 같은 메소드라도 매개변수만 다르면 얼마든지 정의하고 사용할 수 있다. 하지만 너무 많은 오버로드 함수를 가지고 있는 것은 혼란을 야기할 수 있으므로 과도하게 사용하는 것은 좋지 않다. 오버로딩의 특징은 아래와 같다. 메소드 이름이 같아야 함 리턴형이 같아도 되고 달라도 됨 파라미터 개수가 달라야 함 파라미터 개수가 ..
주요 개념 Over-fetching Under-fetching REST-API GraphQL Over-fetching과 Under-fetching은 REST-API의 단점들 중 하나이다. 이 단점은 GraphQL을 사용해 극복할 수 있다. 간단하게 Over-fetching은 API를 호출 시 필요보다 많은 데이터(사용하지 않을)를 가져오는 것이다. 예를 들어 대기 오염 물질 중 미세먼지 데이터만 필요한데 온도, 습도, VOC, NO2 등의 다른 데이터까지 한 번에 받아오게 되는 경우가 있다. 그러므로 서버와 네트워크도 불필요한 자원이 추가되게 되고, 클라이언트도 필요없는 데이터를 수신해 자원을 낭비하게 될 수 있다. Under-fetching은 한 번의 통신으로 필요한 양의 데이터를 가져오지 못한다라는 ..
