9 Log

현업에서 느낀 유지보수 업무의 문제점과 개선 방안. 운영중인 서버에서 사용자가 발견한 이슈가 가장 큰 우선순위를 가진다. 이런 경우는 있어서도 안되지만 운영팀에 넘어와서 정말 많이 봤다. 1년 전 CDW 운영팀으로 넘어와서 처음 넘겨받은 레거시 소스가 운영기임에도 불구하고 문서화된 설계가 많이 부족한 POC적 성격이 강한 소스코드였고, QA관리가 제대로 되지않아 기획서에 정의된 기능이 제대로 작동하는 경우가 거의 없었다. 대게 가능한 10가지 경우의 수 중 자주 사용할만한 2가지 경우의 수에서만 작동하는 식이었다. 이렇듯 레거시 소스가 기획서에서 찾아볼 수 있는 일반화된 입력에 대해 수행 불가한 경우가 많아서 이슈를 처리하기 위해 Confluence위키나 주석을 찾아보면, 정리된 내용이 소스코드에 구현된 내용과 다른 경우가 허다했다. 따라서, 유지보수라는 명목하에 사실상 구현이 미비한 기능의 신규 개발을 수행한 적이 많았으며, 레거시 소스의 문서화 미비로 공수 산정은 어려웠으며 실제 공수는 항상 예상 공수보다 길어져만갔다. 위와 같은 문제가 발생하게된 주요 원인을 나는 3가지 정도로 정리한다. 소스코드 문서화 미비 (ex, 입 출력 범위가 명확하지 않은 API 명세서, 컴포넌트 명세서 혹은 관련 표준안의 부재) 버전관리 역량의 부족 이 부분은 또 세부 적으로 나눠서 설명할 필요가 있다. 첫 째로, 커밋을 한 이후에 자신이 인입/수정하고 싶은 라인이 제대로 반영되었는지 확인을 해야하는데 확인들을 잘 안하고 push한다. 대게 머지 커밋시에는 확인을 안하는 문제가 있었으며, 문제 제기를 해도 머지시 브렌치에 인입/수정 됐던 라인들이 conflict가 안나도 반영이 안될 수 있다는 인식이 부재한 캐이스 였다. 두번째로, 커밋된 내용 확인을 하더라도 공백 제외 옵션을 켜놓고 보는 경우를 많이 봤다. 특히 IntelliJ를 사용하는 개발자들이 주로 그랬는데, 이는 공백만 변경한 의도치 않은 라인들이 커밋에 섞여들어가 타인의 커밋내용과 불필요한 confl...

NextJS의 4가지 Rendering 방식과 그 구현 Next.js는 React 기반의 프레임워크로, 다양한 종류의 렌더링을 지원하며 쉽게 구현할 수 있도록 도와줍니다. 1. 4가지 렌더링 방법과 그 구현 방법 Static Generation (정적 생성): 정적 생성은 빌드 타임에 페이지의 HTML을 생성하는 방식입니다. 동적 데이터를 포함할 수도 있습니다. 구현 방법: // pages/about.js function AboutPage ( { data } ) { return ( < div > < h1 > About Page </ h1 > < p > {data} </ p > </ div > ); } export async function getStaticProps ( ) { const data = 'This is dynamic data.' ; return { props : { data, }, }; } export default AboutPage ; Server-side Rendering (서버 사이드 렌더링): 서버 사이드 렌더링은 요청이 들어올 때마다 서버에서 페이지의 HTML을 생성하는 방식입니다. 동적 데이터를 포함할 수 있습니다. 구현 방법: // pages/blog/[slug].js import { useRouter } from 'next/router' ; function BlogPost ( { post } ) { return ( < div > < h1 > {post.title} </ h1 > < p > {post.content} </ p > </ div > ); } export async funct...

Node.js 웹 서버가 JAVA 웹 서버보다 성능이 뛰어날까? Node.js 웹 서버가 JAVA 웹 서버보다 성능이 뛰어나다는 소문에 대한 진실을 파해쳐겠다. 이 글에서는 해당 소문을 재시하는 다양한 사람들의 근거와 진실 여부를 파악하여 결론을 도출하겠다. 1. 많은 사람들이 그 이유를 제대로 설명하지 못한다. 아래는 여러 블로그 글들을 읽어보고 가장 많이 사람들이 근거로 드는 내용을 정리 한 것이다. Node.js는 싱글 쓰레드 기반의 논블로킹 방식의 I/O를 사용하고, 멀티 쓰레드와 블로킹 방식 I/O를 사용하는 자바 웹 서버보다 빠르다. 왜냐하면 멀티 쓰레드 방식은 컨텍스트 스위치 오버헤드가 있기 때문이다??? 정말 어이없다. 이는 더 성능이 빠른 이유가 될수 없고, 그나마 싱글 쓰레드 기반인 Node.js가 멀티 쓰레드 기반인 자바 웹 서버 처럼 여러 요청에 대한 동시적인 처리를 할 수 있는 이유가 될 뿐, 이 사실 자체로는 더 나은 성능을 나타내는 이유가 될 수는 없다. 생각해보라, 논블로킹 방식의 I/O를 지원하는 것도 결국 Node.js가 내부적으로 멀티 쓰레드를 구현하고 있다라는 의미 밖에 안되고, 이도 마찬가지로 자체적인 컨텍스트스위칭이 필요할 것이다. 즉, 단순히 논블로킹 싱글 쓰레드라서 블로킹 멀티 쓰레드보다 빠르다는건 논리적으로 근거가 빈약하다 2. 내가 여러 기술 스펙들을 읽어보고 정리해 보았다 개인적인 주장이니 어디가서 정답인양 말하지 말라. 2.1. NodeJS가 비동기 I/O 시스템 콜의 활용성이 더 좋다. 본래 태초에 OS가 등장 했을 때는 I/O 시스템 콜 [1] 은 동기 요청 방식만 제공하였었다. 프로그램은 I/O요청에 대한 비동기적인 처리를 위해 별도의 쓰래드를 생성하는 것이 일반적이 었다. 그리고 이러한 비동기 방식의 사용자 I/O 요청이 보편화 되자 이를 표준화한 POSIX 1.b의 AIO 도 등장하여 이를 따르는 많은 OS들에서 더욱 쉽게 비동기 I/O 요청을 사용할 수 있게 되었...

전세보증보험 의 종류 와 특징 1. 전세보증보험 은 전세보증금반환보증 이다 정식 명칭은 전세보증금반환보증 이다. 그러나 임차인에게 전세 사기등의 사고가 발생했을 시 전세보증금의 반환을 보장해주는 일종의 보험 처럼 작용하기 때문에 임차인들 사이에서 주로 전세보증보험 이라는 별명으로 불리는 듯 하다. 전세보증보험 을 들면 계약 만기 시 전세금을 돌려받지 못하는 사고가 발생했을 때, 일정 조건하에 보장된 금액만큼을 임대인을 대신해서 임차인에게 대위변제 해주고 임차인을 대신해서 임대인에게 해당 금액만큼의 구상권을 행사하게 된다. 2. 전세보증보험 은 전세자금보증 과는 다르다 흔히, 은행에서 전세 대출을 받기위해 심사를 통해 가입하게되는 전세자금보증 은 대출 만기시 임차인이 대출금을 상환하지 못하는 사고가 터졌을 때 기관이 임차인을 대신해 보증된 금액만큼의 전세보증금 을 대위변제해주고 임차인에게 그 금액에 대한 구상권을 행사하게 된다. 임차인이 임대인으로 부터 전세보증금 을 돌려받았는지 여부는 중요하지 않고 오로지 은행의 자산만 보호해주는 보험인 것이다. 그러나 전세자금보증 을 임차인이 대출시 가입할 수 밖에 없는 이유는 가입을 안하면 은행이 전세자금대출 특유의 높은 한도의 저금리 대출 을 해줄수 있는 이유이기 때문에 가입을 하고 보증할 수 있는 금액만큼 대출해주게 되는 것이다. 3. 전세보증보험 의 종류 전세보증보험 을 제공하는 기관은 크게 3가지 이며, 각각 자신만의 이름이 있다. HUG : 전세금반환보증 HF : 전세지킴보증 SGI : 전세금보장신용보험 4. 각 전세보증보험 별 특징 *목적물 유형별, 보증금액별 세부 조건등은 미기입 기관 보증료율 보증한도(보증목적물) 보증한도(지역별) HUG 0.128% ~ 0.154% 주택가격 x 담보인정비율(90%) – 선순위채권 수도권 7억, 이외 5억 HF 0.04% 주택가격의 90% - 선순위채권 총액(선순위근저당권설정액과 선순위임대차보증...

Github Page가 제공하는 의존성들 1. Github Page가 제공하는 의존성을 왜 알아야하는가 Github Page를 사용할 때, 사용자는 Github Page가 기본적으로 재공하는 Gem 패키지들만 사용해야한다. Github Page의 빌드 서버에 설치된 Gem 패키지 목록을 관리하거나 사용자가 제공한 Gemfile내의 의존성 설치를 위한 Bundle install을 실행할 수 있는 옵션을 제공하지 않는다. 서버 기능, 성능, 용량에 제한을 두기위해서는 어쩔수 없는 조치이기도 하다. 따라서 우리는 Github Page가 제공하는 의존성을 알아야한다. 2. Github Page가 제공하는 의존성들 다음 링크에서 확인 가능하다. https://pages.github.com/versions/ 현재 기준으로 다음과 같은 의존성을 제공한다. Dependency Version jekyll 3.9.3 github-pages-health-check 1.17.9 github-pages 228 html-pipeline 2.14.3 jekyll-avatar 0.7.0 jekyll-coffeescript 1.1.1 jekyll-commonmark-ghpages 0.4.0 jekyll-default-layout 0.1.4 jekyll-feed 0.15.1 jekyll-gist 1.5.0 jekyll-github-metadata 2.13.0 jekyll-include-cache 0.2.1 jekyll-mentions 1.6.0 jekyll-optional-front-matter 0.3.2 jekyll-pagina...

1. Javascript의 this 키워드도 대체로 자기 자신(객체)을 가리킨다 보통 Java 같은 객체지향 언어에서 this 가 가리키는 대상은 this 을 선언한 해당 메서드를 수행 중인 자기 자신(객체)이다. Javascript 에서 this 는 이와 비슷한 역할을 한다. 우선, 기본적으로 Javascript 의 this 키워드는 다른 객체지향 언어와 마찬가지로 this 가 선언된 메서드를 수행 중인 객체를 가리킨다. function person ( ) { this . name = '강아무개' ; //person클래스의 생성자 메서드에서 선언. 즉, 생성자를 통해 생성할 person 객체를 가리킨다. } //ES6 문법에서 등장한 class 선언 문법 class person { constructor ( ) { this . name = '강아무개' ; //마찬가지로 this는 새로 생성할 person 객체를 가리킨다. } } 2. Javascript this를 메서드 블록 밖에서도 사용할 수 있다 Javascript에서의 this 는 특별하다. 자신의 객체를 가리키는 this 의 용도상 메서드 선언 블록에서만 this 를 사용해야 하는 게 보통의 언어지만, Javascript는 this 를 사용자 코드 어디에서든지 사용이 가능하다. 메서드를 포함한 모든 종류의 함수 내부에서 사용되며, 함수 밖 전역에서 단독으로 사용될 수도 있다. 2.1. 함수 내부에서 사용된 this 키워드 함수 내부에서 사용된 this 키워드는 호출 형태에 따라 참조하는 값이 달라진다. 2.1.1. 객체의 메서드로서 호출될 때 this 는 함수가 어떤 객체의 메서드로서 호출될 때, 해당 객체를 참조한다. ES6의 클래스 문법 또는 리터럴 방식으로 메서드를 선언할 수 있다. 메서드로 선언되지 않은 함수들도 동적으로 임의의 객체에 메서드로 할당될 수 있다. Javascript의 객체는 메서드를 프로퍼티로 가...