Peep

우린 Git-flow를 사용하고 있어요

배민에서 github으로 소스를 이전하면서 github-flow를 사용하기 시작했다.

하지만 곧 다시 git-flow로 브랜치 전략을 변경하였다.

작업 정책

JIRA 티켓 생성

하나의 티켓은 되도록 하나의 커밋

커밋 그래프는 단순하게

공유 브랜치의 커밋 그래프를 함부로 변경하지말 것

리뷰어에게 리뷰

본인의 pull request는 스스로 merge

git-flow

master 제품으로 출시될 수 있는 브랜치

develop 다음 출시 버전을 개발하는 브랜치

feature 기능 개발 브랜치

release 이번 출시 버전 준비 브랜치

hotfix 출시 버전에서 발생한 버그 수정 브랜치

브랜치가 많아졌기에 작업 시 해당 브랜치에서 작업하도록 주의한다.

정책에서 그래프를 단순하게 가져간다고하고 하나의 티켓에 하나의 커밋을 하기로 했기 때문에 squash와 rebase를 해서 그래프를 단순하게 한다.

squash, rebase 작업 전 후 비교 그래프

작업 브랜치의 수명을 짧게 가져가는 것이 좋다.

항상 git-flow로 흘러간 것은 아니지만 시행착오를 겪으며 브랜츠 전략을 더더욱 견고히했다고 한다.

예전에 읽게된 글을 다시 읽게되었다.
회사에서 flow를 재 정의하게 되었는데, 글을 읽으며 재 정의된 회사 정책과 비교할 수 있는 기회였던 것 같다.
안쓰는 기능들도 있어서 반성을 하기도 하고..
뱅크샐러드의 포스팅 '하루 1000번 배포하는 조직되기' 글과는 플로우 추구 방식이 반대이기도 하는 글이기도 해서 뱅샐의 글이 생각나면서 재미있었다. 브랜치 관리가 관건..
혹시나 2017년 글이기때문에 배민에서 플로우를 변경하지는 않았을까해서 찾아봤는데, 이후의 포스팅 콘텐츠가 없는 것으로봐서 git-flow 정착 후의 변화는 없는것 같다. 좋은 결과가 이어지고있기 때문이겠지?

원본

https://woowabros.github.io/experience/2017/10/30/baemin-mobile-git-branch-strategy.html

프론트에서 안전하게 로그인 처리하기

보안에 위협이 되는 문제

1. XSS (Cross Site Scriptiong)

공격자가 <input>태그나 url등에 Javascript를 삽입해 실행되도록 공격한다.

악성데이터를 실행하거나 사이트의 전역 변수를 이용해 API 요청을 하여 사이트의 로직인 척 행동하여 악의적인 행동을 한다.

2. CSRF (Cross Site Request Forgery)

서버에서 클라이언트 도메인을 통제하고 있지 않으면 공격자가 다른 사이트에서 API 요청을 할 수 있다.

이때 공격자가 사용자만이 가능한 행위(수정, 삭제, 등록 등)들을 할 수 있다.

(이러한 행위로인해 최악의 상황 -> 비밀번호, 송금 등에 접근)

원본 글 요약

• JWT(JSON Web Token)로 유저 인증
• Refresh Token은 httpOnly
• Access Token은 JSON payload
• Access Token은 지역변수로 저장
• 새로고침이나 브라우저 종료 후 재접속(mount) 처리, 각각의 API 이용 
  • 최초 접근 API
  • 재 접근 API
• 재 접근 시 Refresh Token과 Access Token을 새로 발급 받을 수 있도록 한다.
• CSRF, XSS 공격에서 다소 안전하나 XSS는 어떤식으로든 취약점이 생길 수 있어 서버에서도 같이 처리 필요

Access Token, Refresh Token이란?

• OAuth(Open Auth)에서 나온 개념이며 두개를 묶어 사용자 토큰이라고 부른다.
• Access Token은 보안상 짧은 유효기간, Refresh Token은 긴 유효기간을 가지고 있다.
• Access Token이 만료되면 Refresh Token을 통해 Access Token을 갱신한다.
• 왜 두개가 필요한지에 대해서는 Stack overflow 글 참고 하면 되고 참고 링크에서도 확인가능하다.
• 보안상 두가지를 사용하는 것으로 이해하면된다.

-참고 https://dreamaz.tistory.com/22

보안관련 작업을 해본적도 관심도 없었던 나에게 보안에 얕게나마 관심을 가지게해주는 좋은 글이었다.

원본 글

https://velog.io/@yaytomato/%ED%94%84%EB%A1%A0%ED%8A%B8%EC%97%90%EC%84%9C-%EC%95%88%EC%A0%84%ED%95%98%EA%B2%8C-%EB%A1%9C%EA%B7%B8%EC%9D%B8-%EC%B2%98%EB%A6%AC%ED%95%98%EA%B8%B0

클린봇 2.0: 문맥을 이해하는 악성 댓글(단문) 탐지 AI

AI관련해서 전혀 관심도 없는데, naver 블로그에서 확인하게 된 재미있고 유익한 글이 있어서 읽어봤다.
2020년 6월 18일 클린봇 2.0 모델이 나왔다고 하며 클린봇은 악플에 대한 탐지 AI이다.
클린봇 모델의 산출 과정에 대해 작성되어있다.

클린봇 2.0 악플 유형 기준

1. 욕설: 일반적인 욕설, 네이버 내부적으로 가지고 있는 욕설 데이터에 포함된 표현

2. 저속한 표현: 타인에게 불쾌감을 주는 속되고, 격이 낮은 표현

3. 선정적인 표현: 성적으로 자극적인 표현

4. 폭력적인 표현: 신체적 위협에 대한 표현

5. 차별적인 표현: 지역/인종/국가/종교 등에 기반한 차별 표현

6. 비하적인 표현: 상대방에게 모멸감과 수치심을 주는 비하 표현

토큰화가 필요했다고 하는데, 사용자 댓글은 오타나 비표준적인 표현, 한글 자모음, 특수문자 등을 다양하게 활용해서 작성되기때문에 단어나 형태소 단위는 적절하지 않았다고 한다. 따라서 음절 단위로 토큰화했다고...

<s> 시작
<e> 끝
<pad> 패딩
<unk> 출현 횟수가 일정 수를 넘지 않는 희소한 음절

* 입력 문장: “안녕하세요.”
* 토큰화 결과: [‘<s>’, ‘안’, ‘녕’, ‘하’, ‘세’, ‘요’, ‘<e>’, ‘<pad>’, ‘<pad>’, … ‘<pad>’,]

손실함수 정의, 모델 구조는 이해하지 못했다. 어렵다.
가볍게 읽는 글이기에 넘어가야겠다.
(이해를 위해 오랜시간을 쏟아야할 것같기도하고..ㅠ)

학습과정은 재미있었다.
데이터의 불균형이 생기면 학습 시 편향될 수 있기에 구축된 데이터를 토대로 복제해 균형을 맞춰주더라.

성능 향상을 위해 데이터 정제, 전이 학습등을 거쳤다.
전이 학습에서 재밌고 대단한 점이 유사도를 산출하는 것이었는데, 어휘의 중복, 의미적 유사를 계산하여 학습한다.
정성적인 측면(의미 유사)에서 가설을 하나 세웠다고하는데, 생각해보면 나도 가설과 같이 행동할 때가 많다.

‘평균적으로, 같은 사용자가 비슷한 시기에 같은 섹션에서 작성한 두 댓글은 다른 사용자가 작성한 두 댓글보다 의미적으로(즉, 정성적으로) 유사하다.’

- 원본 글 출처

탐지 사례와 결과에서 어휘가 비슷해도 의미가 다른 댓글에 대한 클린봇 2.0에 대한 반응이 있다.

같은 텍스트가 포함되어있어도 의미가 악플인지 아닌지에 대한 결과인데, 신기하고 재밌는 결과이다.

클린봇 같은 AI들이 많이 생기고 더욱 진화해서 악플이 안보이는 날이 오면 좋겠다.

원본, 이미지 출처

https://d2.naver.com/helloworld/7753273

은닉을 향한 자바스크립트의 여정

클래스 필드 스펙 Stage3까지 올랐다고한다. 곧 Stage4가 표준 스펙이 될거라는데??

타입스크립트 3.8부터 private를 지원, 공부 중에 잠깐 확인한 적이 있었다.

• 표준 스펙이 될 것이다.

  • 스펙이 업데이트될 수 있다.

• private와 같은 키워드를 사용하지 않고 #을 사용한다.

  • 키워드가 아닌 프리픽스

• public과 다르게 클래스의 필드 선언을 통해서만 만들 수 있다.

  • 동적으로 객체에 추가할 수 없다.

• 메서드에는 제한적이며 메서드 선언으로 사용 불가

  • 함수 표현식으로 정의

• 객체 초기화 구문은 계산된 속성명(computed property name)을 사용할 수 없다.

• 모든 private 필드는 소속된 클래스에 고유한 스코프를 갖는다.

  • getter 함수를 만들어서 public하게 노출해서 값에 접근 할 수 있다.

  • private를 정의한 클래스를 제외하고 어디에서든 접근이 불가능하다.

자바스크립트는 private 속성을 지원하지 않아서 코드를 짤 때 private하게 하기 위해 꼼수를 사용해왔다.

보통 클로저를 통해 캡슐화, 은닉화를 통해 private하게 만들었고,

그렇지 않고서는 언더스코어(_) 프리픽스를 통해 컨벤션으로 이것은 private야라고 해서 쓰기도 했다.

하지만 이게 컨벤션일뿐 모르는 사람이 그냥 외부에서 접근했을때에는 그냥 public이다.

그 후에는 JSDoc을 통해 @private를 표현했다고 한다. 

언더스코어보다 훨씬 명시적이로 문서도 자동화가 되니 자연스럽게 언더스코어의 사용은 줄었고,

글쓴이도 컨벤션에서 제하는것에 찬성했다고 한다. 

나도 글을 보니 사용을 지양하는 것이 좋겠다고 생각했다.

원본 글에서 가져온 코드다.
es6를 사용하지 못하는 프로젝트에서 캡슐화 시켜서 private하게 코딩할 때 모듈 패턴을 사용하는데,

이것도 생성자의 인스턴스 컨텍스트별로 private하게 하지 못하기 때문에 도움이 되지 않는다.

function SomeModule() {
  const privateProp = 'dont touch this';
  const publicProp = 'you can touch this';

  _doSomethingWithPrivateProp = () => { ... }

  const publicMethod = () => {
    _doSomethingWithPrivateProp();
    // ...
  }

  return {
    publicProp,
    publicMethod
  }   
}

- 코드 출처 원본 글

아래는 symbol에 대해 공부 의지를 불태워 줄 좋은 자료의 코드이다.

es6에서는 더 멋진 꼼수로 private하게 만들 수 있다는 예시라고 하는데, 

(하지만 이제 private를 정식으로 지원한다고 하니까.)

다음에 공부하게 참고해야지.!!

const privateMethodName = Symbol();
const privatePropName = Symbol();

class SomeClass {
  [privatePropName] = 'dont touch this';;
  publicProp = 'you can touch this';

  [privateMethodName]() {
    console.log('private method');
  }

  publicMethod() {
    this[privateMethodName](this[privatePropName]);
  }
}

- 코드 출처 원본 글

원본, 코드 출처

https://meetup.toast.com/posts/228