2018년 11월 11일 일요일

GDG Devfest Seoul 2018 후기

- GDG Devfest 2018

동기 추천으로 GDG Devfest 2018에 참석하였다.
  About DevFest
  GDG 행사 중 가장 큰 개발자 축제인 DevFest Seoul 2018이 올해는 'Digital Wellbeing' 이라는 키워드 아래 
  11월 10일 토요일 세종대학교 컨벤션센터에서 열립니다!

  GDG DevFest는 GDG 커뮤니티에 의해 매년 개최되는 개발자 행사 중 하나로, 
  구글 기술과 관련된 세션, 해커톤, 코드랩 등의 형태로 구성됩니다.

  GDG DevFest 는 앞으로 9월부터 11월까지 3개월에 걸쳐 전 세계에서 진행되며, 참석자들은 Android, Firebase, Google Cloud Platform, TensorFlow, 
  웹 개발 등의 Google 개발자 기술 콘텐츠를 접하게 됩니다. GDG DevFest 는 국내 개발자들을 한자리에 모아 서로 지식을 교환하고, 
  아이디어를 공유하고, 기술에 대한 열정을 표출하는 장이 될 것입니다.
사실 10월에 Goole Cloud Submit Korea에 등록하여 참석할 수 있는 기회가 있었지만, 평일에 진행하였고 너무 어려울 것 같아 가서 멍만 때리다 올 것 같아서 포기했었다.
다음 기회에 꼭 가보고 싶다는 생각을 하던 찰나에 동기가 GDG Devfest에 대해 알려주었고, 토요일 진행 + 강연 내용도 좀 더 이해할 수 있겠다고 생각되어 바로 등록하였다.
티켓가격은 블라인드 티켓 15000원 , 일반 20000원이었다. (블라인드티켓은 선착순인가?ㅋㅋ)
세종대에서 진행하였고, 마침 세종대에서 2018 행복얼라이언 DAY 라고 각종 콘서트와 플리마켓을 하여 입구부터 사람들이 많았다.
이런 IT 행사는 처음이었고, 새로운 경험이어서 설레는 마음을 가지고 참석하였다. 이번 행사는 뱅크샐러드, 요기요, 카카오페이, 구글코리아 등 많은 기업들이 스폰하는 것 같았는데, 채용홍보(?)나 설문조사 참여 등을 하는 것 같았다.
기본적인 기념품(담요)

ㅋㅋ 모든 설문조사 다 참여해서 스티커 다 받음.

요기요와 카카오페이(카카오뱅크였나)에서는 명함으로 추첨을 해서 상품을 주었다. 요기요는 무려 에어팟;;;
카카오는 라이언인형
CRACKER에서도 에어팟추첨인 것 같았는데 담첨자 발표는 나중에 하는 것 같았음.
요기요는 행사 중간 쉬는시간에 바로 추첨을 하였는데, 그 자리에 당첨자가 없으면 다시 뽑는 방식으로 처음에 2명이나 자리에 없어서 다시 뽑았는데 열기가 대단했다. 당첨자 바로 안나오면 사람들 개좋아함ㅋㅋㅋㅋ
(나 역시...ㅋㅋ)
1시 45분부터 시작이었고, 4개의 장소에서 5번에 걸쳐서 진행되었다. 물론 듣다가 멍때린 부분도 있었지만, 재미있어서 엄청 집중한 부분도 있었다. 코드랩과 명상도 있었다.

https://devfest-seoul18.gdg.kr/timetable

좋은 경험이었음!!


- 후기

  1. 와 씨 서비스 하나에 이렇게 세세하게 고려해야하구나
  2. 난 빡대가리야.. 공부해야 할 게 넘 많다 헤헤ㅔ헤헤헤ㅔ
  3. 사람엄청많았음 (중학생도 봄. 나보다 잘하겠지 ㅠㅠㅠㅠ부러움)
  4. 처음가봤는데 꿀잼. 자극 개쩔음. 이런 IT컨퍼런스(?)/행사에 주기적으로 참석해야겠음.
  5. 세종대 이쁘다. 학교 다시 다니고 싶당 열심히 좀 다닐껄....


- 내가들었던 세션

1. Chrome Devtools를 활용한 성능 측정과 개선

크롬 개발자도구에 audit를 통해 웹 페이지에서 성능을 느리게 할만한 것들을 찾아 성능 측정 가능함.
개선을 하려면....
  • lazyloading : 사용자 브라우저에 보이는 이미지만 로딩하고 다른 이미지들은 사용자가 스크롤하면서 이미지에 가까워지면 로딩됨
  • 이미지 최적화
  • 부드러운 이미지 개선
이와 같은 방법을 제시하며, 이에 맞는 API를 소개해줬음.

2. 함수형프로그래밍과 안드로이드 테스팅

이 세션에서는 안드로이드 테스팅방법에 대해 중점적으로 다루었음.
두가지 테스트로 나뉨
local test >> 이번세션에서 중점적으로 설명
instrumented test (하드웨어 기기나 에뮬레이터에서 실행되는 테스트 )
순수함수가 테스팅에 용이하다
안드로이드는 테스팅이 어렵다 -> 가능한 부분만 분리하여 테스팅
테스트를 위해서는 함수의 독립성이 필요하다.
테스트 전략
  • 테스트 불가능한 코드는 view단에 작성
  • view는 최대한 패시브하게
  • 함수 내에서 외부 변수 줄이기
  • 함수는 input에 대해 특정한 return 값을 갖도록 작성해야함

3. 마이크로서비스 아키텍처에 서비스메시 끼얹기(Istio)

이 세션에서는
  • 마이크로서비스
  • 개발자가 개발에만 집중하는 방법
    '생산성'을 높이려면? -> 정교한 설계 or 서버리스 or 마이크로서비스 아키텍처
    마이크로서비스 아키텍처
    : 하나의 큰 애플리케이션을 여러 개의 작은 애플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처
    ex) amazon, netflix
    
    쉬운 예로 이커머스(자바스프링)에 추천기능(nodejs)을 도입하고자 할 때 같은 서버? 공간? 이 아니라 다른 환경에서 구축하여 네트워크를 통해 정보 전달&공유할 수 있게
    서비스 메쉬?
    : 마이크로서비스 아키텍처를 적용한 시스템의 내부 통신이 Mesh 네트워크의 형태를 띄는 것에 빗대어 Service Mesh로 명명
    서비스 메쉬는 서비스간 통신을 추상화하여 안전하고, 빠르고, 신뢰할 수 있게 만드는 전용 InfraStructure Layer
    -> 추상화를 통해 복잡한 내부 네트워크를 제어하고, 추적하고, 내부 네트워크 관련 로직을 추가함으로써 안정성, 신뢰성, 탄력성, 표준화, 가시성, 보안성 등을 확보함.
    마이크로서비스 아키텍처의 문제점은 '네트워크' ->이 네트워크를 신뢰하면 안되고, 불안정하다는 가장하에 구상을 해야함
    ex) 1번과 2번이 네트워크를 통해 통신하는데, 1번이 2번을 호출하는데, 2번이 응답을 못하거나 속도가 느려진 상황일 때 1번은 계속 2번의 응답을 기다리는 형태가 기다린다.
    그러면서 서킷 브레이커의 개념을 소개함 ex) 2번이 문제가 있으면 서킷브레이커가 중간에서 1번의 호출을 끊거나 장애가 전파하는 것을 방지
    재시도 -> no code user Proxy
    재시도하는 과정을 코드를 통해 시도하지 말고 프록시에 맡겨라 (서비스메쉬) ex) 1번서비스는 프록시에 요청을 보내고 프록시끼리 통신하면서 이 과정에서 재시도나 네트워트 제어? 등 다양한 기능을 제공? 지원?
    서비스메쉬 LINKerd (무거움) envoy (작고 빠름) Istio (더 편리하게)
    각 장단점 소개하면서 Istio의 간단한 실습?을 보여줬음

4. Use JavaScript More Strictly (TypeScript,flow)

typeError는 누구나 겪는 에러
-> 타입을 미리 체크해서 human error 를 방지하자
JavaScript -> 타입이 실행 중에 정해짐 -> 동적언어, 느슨한 언어
static type 이 인기가 있어짐
flow vs typeScript facebook / MS React, Vue 등 / Angular, VSCode 등
두가지를 소개하며 typeScript를 회사에 적용하여 타입체크를 하는 했던 썰을 얘기함
  • 자주 나오는 오류 순위
  • 느낌점 등
오픈소스 웹브라우저 프로젝트 -> 크롬은 크로미움 코드를 사용하여 개발됨 (블링크 및 V8 등을 기반으로 함)
소스만 15기가 / 아이맥 5K기준 빌드만 3시간이라고함
크롬은 멀티프로세스 아키텍처 -> 한 페이지에서 오류가 발생하더라도 모든 브라우저를 다운시키지 않게 함 모든 탭, 윈도우, 플러그인들이 각각 구분된 환경에서 실행되기 때문에, 어느 한곳에서 문제가 발생하더라도 다른 브라우저에 여파가 미치지 않음
마지막세션은 너무 멍때림...

2018년 11월 7일 수요일

유닉스 리눅스 파일,폴더 권한권리


자신의 파일과 디렉토리 상태 확인
ls -l 

ex)

drwxr-xr-x  5 sg  staff  160 11  7 23:09 Java8TestCode
drwxr-xr-x  5 sg  staff  160 11  5 18:57 WPP

목록들 중 가장 왼쪽 현재 파일의 권한을 나타낸다.

위의 예제로 보면 
     d                  rwx                     r-x           r-x 
파일타입      파일소유자권한     그룹권한   익명권한

으로 볼 수 있다.

파일 타입은
-: plain file으로 일반파일(실행파일도 포함)
d: directory 으로 디렉토리 형식
l: link 으로 다른파일을 가리키는 링크파일
p: pipe 으로 두 개의 프로그램을 연결하는 파이프 파일
b: block device 으로  블럭 단위로 하드웨어와 반응하는 파일
c: character device 으로 스트림 단위로 하드웨어와 반응하는 파일

권한은
read write execute 를 의미함.
권한이 있으면 알파벳 /  없으면 - 으로 표시됨

그럼 예제를 다시 보자
drwxr-xr-x
디렉토리 형식에 
파일 소유자는 읽고 / 쓰기 / 실행 
파일이 포함된 그룹은 읽고 / 실행
나머지 사용자는 읽고 / 실행




접근 권한 변경
usage: chmod [-fhv] [-R [-H | -L | -P]] [-a | +a | =a  [i][# [ n]]] mode|entry file ...
chmod [-fhv] [-R [-H | -L | -P]] [-E | -C | -N | -i | -I] file ...

chmod [권한] [파일]


예제로 보자
chmod g+w WPP   (WPP파일의 그룹에 쓰기 권한을 추가)
chmod o-r WPP     (WPP파일의 익명에 읽기 권한을 제거)


숫자로 쉽게 줄 수 있음
chmod 777 WPP (WPP파일의 권한을 rwx rwx rwx 로 설정) 
chmod 541 WPP (WPP파일의 권한을 r-x r-- --x 로 설정) 


8진수 생각!
7 rwx  
6 rw-
5 r-x
....



소유권 or 그룹 변경
usage: chown [-fhv] [-R [-H | -L | -P]] owner[:group] file ...
       chown [-fhv] [-R [-H | -L | -P]] :group file ...


chown [사용자:그룹] [파일]


예제로 보자
chown cot WPP            (WPP파일의 소유자를 cot을 변경)
chown cot:men WPP    (WPP파일의 소유자를 cot으로, 그룹을 men으로 변경)


참고


2018년 11월 4일 일요일

맥북프로 13인치 2018년형 터치바 구매, 개봉기

드디어!!! 기대하고 기대하던  맥북이 왔다.

맥북에 대해 상당히 많은 시간을 고민을 하였지만,
'20대의 행복은 돌아오지 않는다. 행복해져라' 라는 문구를 보고  할부로 질러버렸다..
(내 5개월...하)

내가 산 것은 맥북프로 2018년형 13인치 터치바모델 '기본형'


- 구매하기 까지..
모델선택에도 많은 고민이 있었다.
맥북프로 모델 터치바 유무에 따라 나누어지기 때문에 고려해야할 것이 너무 많았다.

무조건 이번 노트북은 13인치를 사려고 마음먹었기에 화면크기(13인치)는 고정이었고,
터치바는 조금 꺼려서 논터치모델을 사려고했었다. (물론 가격이 큰 이유 중 하나)

하지만, 애플이 치사한 놈들은 논터치모델과 터치바모델의 차이를 만들어서 터치바모델을 사도록 유도하는 것 같다. (**같은 C타입포트 개수, 성능 등)

논터치모델과, 터치바모델을 중고나라와 애플공식 리퍼비쉬 페이지, 커뮤니티 등을 오가며 보던 중
쿠팡에 2018년 터치바모델이 나름 저렴하게 올라온 것 같아 바로 구매했다...

맥북을 공홈보다 저렴하게 사는 경로는 여러가지있다.

1. 애플 교육할인 스토어
- 별다른 인증없이 할인 받을 수 있는 것 같다.
(물론 할인폭은 그렇게 높지 않다. 맥북프로 13인치 터치바 기본형 모델기준 13정도, 논터치 기본형기준 7)

2. AOC
- Apple On Campus 로 애플과 대학교가 제휴를 맺고 학생 및 교직원에게 적용되는 할인같다.
(할인폭이 애플 교육할인 스토어보다 높다. 학생이 아니라면 지인찬스 고고, 거의 리퍼비쉬 가격이었음)

3. 각종 쇼핑몰
- 새 제품 중 가장 저렴한 것 같다. 각 쇼핑몰의 할인쿠폰도 적용가능하고, 가끔씩 엄청 싸게 올라오는 경우도 있는 듯 하다.
(공홈처럼 묻지마 환불은 어려우며, 제품에 문제가 있을 경우 매우 귀찮아지는 것 같다.)

4. 중고나라
- 싸게 살 수 있다. 파는 사람도 많아 원하는 제품을 금방 찾을 수 있고, 운이 좋으면 좋은 물건을 상당히 저렴하게 구입할 수 있다.
(중고나라는 언제나 무서운 곳이다. 택배거래 조심하자......)


- 오늘 찍은 따끈따끈한 사진들
흐흐 인터넷에만 보던 박스다

깔끔쓰



열마자마자 보이는 이뿐 스페이스그레이...


구성품: 충전기. 끝. (+필요없는 스티커)


 저 광활한 터치패드를 보아라.....


기존에 있던 HP15인치 노트북과 크기 차이




ESC조차 터치바에 있기 때문에 뭔가 누르는 맛이 없긴한데, 신기하긴하다.
여러가지 터치바에 표시해주는 듯하나 과연 이 터치를 잘 활용할 수 있을까 의문.










2018년 10월 20일 토요일

CI/CD 란?

CI(Continuos Integration)란 ? 

개발자들이 개발한 소스를 모아서 특정 시점에 빌드하는 것과 반대로 주기적으로 수행함으로써 통합에서 발생하는 오류를 사전에 해결하고 이러한 과정들에 소요되는 시간을 줄이기 위한 기법으로 대표적인 툴로는 Jenkins 등 이 있다. 
(빌드,테스트를 실시하는 프로세스를 상시로 실시)


CI서버는 형상관리 서버에 커밋된 소스를 주기적으로 받아와 컴파일, 단위테스트 등의 과정을 수행하여 신규 또는 수정된 소스코드가 결함이 있는지 여부를 지속적으로 검증
또한 검증 결과를 이메일 등으로 전달하여 조기에 결함을 발견하여 해결할 수 있다고 함..


개발자 -> 형상관리 서버(ex. git,svn 등) -> CI 서버(jenkins, hudson 등) -> (최종 운영 서버에 배포 or ..?)
(이런식일까,, ??) 

>> 젠킨스의 설정에 따라 엄청 여러가지를 할 수 있는 듯 하다. 젠킨스의 셋팅을 직접해보면서 기능을 더 알아보는 것이 좋을 것 같다.(AWS하면 좋을  것같은데..언제하지..ㅠㅠ)

Jenkins가 제공하는 기능
- 웹 인터페이스를 통한 간편한 설정
- 강력하고 편리한 Reporting 기능
- 지속적인 자동화 빌드
- 지속적인 자동화 테스트
- 커버리지 감시
- 코드 품질 감시
- 다양한 인증기반과 결합한 인증 및 권한 관리 기능
- Groovy script를 이용한 고수준의 Job Scheculing 기능
- 커맨드라인 인터페이스 제공
- 자동화된 배포관리
- 분산빌드 기능
- 윈도우 커맨드 스케쥴링 실행 기능
(이 외에도 플러그인을 통해서 기능을 추가/확장 가능하다고함..)



CD(Continuous Delivery or Continuous Deploy)란? 

지속적 배포로 소프트웨어를 더 빠르게, 더 주기적으로 빌드하고 테스트하고 출시하는 것을 목표로한다. 

CI와의 차이점은 어디까지 자동화가 되어있느냐

소스를 푸쉬하고 빌드 시작 - CI
빌드 후 테스트 후 배포 - CD
(여기서도 배포 방식에 따라 수동화 - Delivery / 자동화 Depolyment) 

>>결국 CI/CD 를 통해 배포까지 자동화하는 것???  같음..

 기업들 기술블로그들에 좋은 자료가 많은 것 같다..ㅋㅋㅋ
참고해보쟝



- 컴투스 기술블로그 CI/CD
- 우아한형제들 기술블로그 CI/CD





2018년 10월 10일 수요일

만다라트 계획법

만다라트 계획법을 추천받아서 간단히 작성해보려고한다.

만다라트????

만다라트(MANDALA-ART)는 일본 디자이너가 '만다라'모양에서 영감을 얻어 고안했다고 한다. 

일본 유명 야구선수 '오타니 쇼헤이'가 고등학교 1학년 때 8구단 드래프트 1순위를 목표로 만다라트를 구성하고, 2년 만에 꿈을 이뤘다고 한다.. 
난 1학년 때 워3 카오스에 빠져서 게임하는 꿈을 꿨는데...ㅋㅋㅋㅋ


[사진]


엥 어디서 봤는데 했더니 예전에 인터넷에서 돌던 메뉴 결정장애를 위한 표랑 똑같다ㅋㅋㅋㅋㅋㅋㅋㅋ



아무튼 마인드 맵을 생각하게 되는데 
[가운데 핵심 목표] - [주변에 중간 목표] - [세부 목표] 
을 작성해가며 자신의 목표를 달성하기 위해 세부적이고 구체적인 계획을 세워서 달성하면 결국 핵심 목표까지 도달할 수 있게 도와주는 계획표 같은 느낌이다. 

'메뉴 결정장애를 위한 표'처럼 꼭 계획이 아니더라도 여러 분야에서 활용할 수 있고, 
장기적인 계획이 아니라 단기적인 계획표로도 쓸 수 있을 것 같다. 

단기적인 계획을 세워서 빙고처럼 하나씩 지우면서 중간목표 달성 시 
나를 위한 선물을 줘도 괜찮을 듯....???
남은 2018년 다 채워서 3개월 짜리 계획을 짜볼까....









2018년 10월 9일 화요일

JDBC , DBCP, JNDI (수정필요)

JDBC(Java Database Connectivity)
: 데이터베이스에 접근하여 SQL문을 실행하기 위한 자바 라이브러리

>>  자바프로그래밍의 일반적인 데이터 엑세스 제공 
>> 데이터베이스 풀 방식을 사용하지 않고 DB에서 정보를 가져올 때마다 매번 디비 연결을 열고 닫음
>> 효율이 떨어짐 
>> 그렇기 때문에 보통 pool 방식을 사용함. (ex DBCP)

==========================================================

DBCP(Database Connection Pool) 
: 데이터베이스와 연결된 커넥션을 미리 만들어서 저장해두고 있다가 필요할 때 저장된 공간(Pool)에서 가져다 쓰고 반환하는 기법

>> DB커넥션을 어플리케이션 소스 내에서 제어하면서 DB 풀을 가짐
>> 사용자가 요청할 경우 드라이버를 로드하고, 커넥션 객체를 생성해 연결하고 종료하는 비효율적인 작업을 하지 않아도 됨
>> 데이터베이스의 부하를 줄이고 자원을 효율적으로 관리

==========================================================

JNDI(Java Naming and Directory Interface)
: 디렉터리 서비스에서 제공하는 데이터 및 객체를 발견하고 참고하기 위한 자바API
(외부에 있는 객체를 가져오기 위한 기술)

>> DB커넥션을 WAS단(외부)에서 제어하면서 서버에서 하나의 커넥션 풀을 가짐
>> DBCP처럼 어플리케이션 소스단에 설정하느 방식이 아닌 WAS단에 데이터베이스 커넥션 객체를 미리 네이밍함
>> 소스단에 정보를 설정해놓으면 소스 개발자 외에는 정보를 찾기가 힘들다. 하지만 JNDI를 사용하면  WAS단에 저장하기 때문에 파악하기 쉬움..????
>> 서버단에서 어플리케이션 컨테이너는 하나이더라도 내부 어플리케이션 소스는 홈페이지 하나 이상이 될 수있는데(디렉토리 서비스, 서브도메인을 사용하여 서비스하는 경우) 이 경우, DBCP를 사용하면 각 어플리케이션마다 DB Pool이 각자 생성되어 풀이 많아져 효율이 떨어질 수 있음. 
JNDI는 WAS단에서 DB Pool를 하나로 관리하기 때문에 효율이 좋아진다고 함..
(WAS에 스태틱 객체를 생성 후에 쉽게 가져다 쓸 수 있기 때문??)


참고

http://eongeuni.tistory.com/43
http://all-record.tistory.com/104

todo

http://nastyle.tistory.com/15
https://d2.naver.com/helloworld/5102792

2018년 10월 2일 화요일

자바 로그(log) 남기기 - log4j, log4j2, logback, slf4j (간단한 logback 실습)

로그란? (log)

애플리케이션의 상태를 관찰할 수 있도록 애플리케이션이 제공하는 정보 

log4j, logback, log4j2  셋 다 java 로깅 유틸리티이다.

스프링프레임워크에서는  예전에는 commons.logging을 기본으로 사용하였지만, 지금은 slf4j, log4j 를 기본으로 사용?
시간 순서로 보면 Log4j -> Logback -> Log4j2 인듯?
----------------------------------------------------------------------------------------------

Log4j ? (log for java) 

Apache에서 만든 오픈소스 라이브러리로 프로그램을 작성하는 도중에 로그를 남기기 위해 사용되는 자바 기반 로깅 유틸리티

- 구조
Logger - 로깅이 일어나는 부분을 그룹화해, 필요한 그룹의 로그만을 출력하거나, 카테고리에 우선순위를 부여함으로써, 여러가지 출력 방법을 지원함. 실제 로그 긴으을 수행하는 역할을 담당.

Appender - 로그의 출력 위치를 지정. 콘솔, 파일, outputstream, java.io.Writer, Email(STMP), Network 등이 있음.
 - ConsoleAppender : 콘솔에 로그 메세지를 출력한다.
 - FileAppender: 파일에 로그메시지리를 출력한다.
 - RollingFileAppender: 로그의 크기가 지정한 용량 이상이 되면 다른 이름의 파일을 출력한다.
 - DailyRollingFileAppender: 하루를 단위로 로그 메세지를 파일에 출력한다.
 - SMTPAppender: 로그 메세지를 이메일로 보낸다.
 - NTEventLogAppender: 윈도우의 이벤트 로그 시스템에 기록한다.

Layout - 로그의 출력 포맷을 지정.
 - %d : 로그의 기록시간
 - %p : 로깅의 레벨
 - %F : 로깅이 발생한 프로그램의 파일명
 - %M : 로깅이 발생한 메소드의 이름
 - %I : 호출지의 정보
 - %L : 로깅이 발생한 호출지의 라인 수
 - %t : 로깅이 발생한 Thread 명
 - %c : 로깅이 발생한 카테고리
 - %C : 로깅이 발생한 클래스명
 - %m : 로그 메세지
 - %% : % 출력
 - %r : 시작 이후로부터 로깅이 발생한 시점까지의 시간

----------------------------------------------------------------------------------------------

Log4j2 ? 

이 후에 나온 버전으로 성능과 메시지 처리량 및 대기 시간이 향상되었다고 한다.
log4j 는 xml과 properties를 이용해서 설정하지만, log4j2 는 properties는 지원하지 않는다고함.

-특징
 - 자동적인 로깅 구성설정(?) 리로딩
 - 속성 서포트: Log4j2는 시스템의 속성을 불러오고
 - 자바8: 람다식에서 로그 메시지를 래핑하는 API 제공
 - Log4j2에는 쓰레기 값이 거의 없다.
 - LMAX Disruptor를 사용하는 비동기 logger

----------------------------------------------------------------------------------------------

logback ?

log4j 를 토대로 새롭게 만들어진 로깅 라이브러리로 스프링 부트의 기본 로그 객체.
ERROR < WARN < INFO < DEBUG < TRACE
스프링이나 일반적인 자바프로그램의 경우 resources 디렉토리 안에 logback.xml 참조
(logback.groovy -> logback-test.xml -> logback.xml 순서로 찾는다고함..)
스프링 부트는 logback-spring.xml 파일을 참조

-구조
Log4j와 유사한구조

Logger - 실제 로깅을 수행하는 구성요소로 Level 속성을 통해서 출력할 로그의 레벨을 조절할 수있음.

Appender - 로그 메시지가 출력될 대상을 결정하는 요소
 - ConsoleAppender : 콘솔에 로그를 찍는 방법
 - FileAppender : 파일이 로그를 찍는 방법
 - RollingFileAppender: 여러개의 파일을 순회하면서 로그를 찍는 방법
(상당히 다양하게 쓸 수있는 듯.....)
 - SMTPAppender : 로그를 메일에 찍어 보내는 방법
 - DBAppender:  데이터베이스에 로그를 찍는 방법
Socket, SSLSocket 등이 있음

패턴에 사용되는 요소
 - %Logger{length} : Logger name을 축약할 수 있음 {length}는 최대 자리 수
 - %thread : 현재 Thread 이름
 - %-5level : 로그 레벨, -5는 출력의 고정폭 값
 - %msg : 로그 메시지 ( =%message)
 - %n : new line
 - %highlight: 로그레벨에 따른 색을 줄 수 있는 듯 함

 - 나머지 log4j 와 비슷한 듯..


Encoder - Appender에 포함되어 사용자가 지정한 형식으로 표현 될 로그 메시지를 변환

*layout과 encoder의 차이점: 레이아웃은 들어오는 이벤트를 String으로 변환하고 에빈트가 기록될 때 제어할 수 없으며 이벤트를 일관처리로 집계한다. 반면에 encoder는 바이트를 소유하고 있는 appender가 관리하는 outputStream에 쓸 시간과 내용을 완전히 제어할 수 있음. 
FileAppender와 하위 클래스는 encoder를 필요로 하고 더 이상 layout은 사용하지 않는다.



-특징
1. log4j보다 약 10배 정도 빠름. 메모리 효율성 향상
2. 설정 파일을 변경하였을 경우, 서버 재기동 없이 변경 내용이 자동으로 갱신됨.
3. RollingFileAppender로 자동으로 오래된 로그를 지워줌.

----------------------------------------------------------------------------------------------

SLF4J ? (Simple Logging Facade for Java)

SLF4J 는 자바 로깅 유틸리티의 추상체 역할을 함. 인터페이스와 비슷한 역할을 하며, 사용하던 로깅 유틸리티가 변경되더라도 java소스의 변경을 방지해줌.

개발자는 어떤 상황에든 대처하고 확장될 수 있는 느슨하고 유연한 코드를 만들어야 합니다. 따라서 하나의 라이브러리에 너무 종속적이 되버리는 코드는 가급적 작성하지 않는쪽이 좋습니다. 그렇기에 어떤 라이브러리를 쓰든 동일하게 동작하는 코드를 만들어야하고 그것이 slf4j를 써야하는 이유입니다.


만약 log4j 에서 logback  으로 변경할 때 log4j를 import 하던 파일들을
다 logback 으로 바꿔줘야함.

1
2
import org.apache.log4j.Logger;
import org.apache.log4j.spi.LoggerFactory;
cs
소스들 마다 박혀있는 log4j를 바꿔줘야함...


하지만 slf4j를 쓴다면 사용하지 않는 dependency만 제거하면 됨.
1
2
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
cs


======================================================

간단 실습

pom.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
...
    <properties>
...
        <jcloverslf4j.version>1.7.6</jcloverslf4j.version>
        <logback.version>1.1.7</logback.version>
...
    </properties>
...
        <!-- Logback --> 
         <dependency>                                    
                  <groupId>org.slf4j</groupId>                
                  <artifactId>jcl-over-slf4j</artifactId>     
                  <version>${jcloverslf4j.version}</version>  
         </dependency>
         <dependency>
                  <groupId>ch.qos.logback</groupId>
                  <artifactId>logback-classic</artifactId>
                  <version>${logback.version}</version>
         </dependency>
...
cs


src/main/resources 
logback.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
<?xml version="1.0" encoding="UTF-8"?>
<configuration scan="true" scanPeriod="30 seconds">
    <!-- 로그파일 경로  -->
    <property name="LogFileDir" value="/logs/data.log" />
    <!-- CONSOLE appender -->
    <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
        <encoder>
            <pattern> %d{yyyy-MM-dd HH:mm:ss} [%-5p] [%F]%M\(%L\) : %m%n </pattern>
        </encoder>
    </appender>
    <!--  FILE appender -->
    <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <file>${LogFileDir}</file>
        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
            <fileNamePattern>${LogFileDir}.%d{yyyy-MM-dd}</fileNamePattern>
            <maxHistory>30</maxHistory<!-- 보관의 기간 -->
        </rollingPolicy>
        <encoder>
            <pattern>%d{yyyy-MM-dd HH:mm:ss} [%-5p] [%F]%M\(%L\) : %m%n</pattern>
        </encoder>
    </appender>
    <logger name="org.springframework" level="info"/>
    <logger name="org.hibernate" level="debug"/>
    <root level="debug">
        <appender-ref ref="CONSOLE"/<!-- Console에 로그를 출력하고자 할 때 사용 -->
        <appender-ref ref="FILE"/<!-- File로 로그를 남기고자 할 때 사용 -->
    </root>
</configuration>
cs

컨트롤러
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
@Controller
@RequestMapping("/")
public class HomeController {
...
    private static final Logger LOG = LoggerFactory.getLogger(HomeController.class);
...
    @RequestMapping("/")
    public ModelAndView Home(HttpSession session) throws Exception{
        LOG.debug("-------------------WebBoardList_Start--------------------");
  ...
LOG.debug("-------------------WebBoardList_End--------------------");
...
    }
cs


콘솔창



log파일
파일 내부



출처 및 참고 :