일단 해보고, 아니면 뭐

늦은 2022년 회고 - 잘해왔고, 잘할 거야.

개발자 김은혜 — Fri, 27 Jan 2023 19:10:21 +0900

2023년이 된 지 거의 한 달이 다 되어가지만, 더 늦기 전에 2022년 회고를 하려고 블로그를 켰다.
올 한해는 정말 많은 일이 있었고 그 안에서 많은 것들을 배웠고 느꼈다! 나의 한 해를 돌아보자.

3년 차 파트리더?

올해는 첫 회사를 재직한 지 2년이 넘어서는 해였고 3년 차 개발자가 되는 해였으며 회사 방침(?)에 따라 대리로 진급하는 해였다.
대리로 진급을 하면서 신입사원 분들의 사수역할도 해보고 작은 프로젝트였지만 프로젝트 리딩 역할을 하게 되었다.
나는 아직 부족한게 많다고 생각하는 나로써는 내가 어떤 프로젝트를 리딩한다는 것이 두렵기도 하고 얼떨떨하기도 했다.
하지만 팀장님께서 나를 믿는다며 힘든 일이 생기면 언제든지 도와줄 테니 한번 맡아서 해보라며 재차 권유를 하셨고 나는 이전보다는 홀가분한 마음으로 자리를 맡게 되었다.

이전에는 내 업무만 잘하면 됐고 내 일만 생각했으면 됐지만 이제는 그게 아니었다.
프로젝트를 함께 하는 인원들의 역량을 파악해야했고 개발 일정을 산정하고 업무를 분담하고 코드 품질을 위한 노력도 했어야 했다.
다른 프로젝트와 협업이 필요하면 대표로 커뮤니케이션 창구가 됐어야 했고 도움이 필요한 분들에게 도움도 됐어야 했다.
이런 것들이 힘들지 않았다면 사실 거짓말 일것이다. 굉장히 부담스러웠고 힘들었고 어려웠다.

하지만 하루하루 이런 업무들을 하다보니 어느 순간 힘들고 부담스러운 마음보다 얻는 것이 더 많아졌다.
개발하는 시야가 넓어지고 책임감으로 인해 오히려 더 많은 공부를 하게되고 커뮤니케이션 능력도 한층 증가했다.
또한 평소에 해보고 싶었던 기술들을이나 꿈꿔왔던(?) 건강한 개발문화의 도입이 한층 쉬워졌다.
이러한 시간들을 경험하면서 글과 말로는 표현할 수 없는 많은 것들을 배우게 되었다.
이때부터 나는 개발만 잘하는 개발자보단 개발도 잘하는 개발자가 되고 싶다 라는 생각을 하게 된 것 같다.

경험을 해야지만 성장할 수 있는 부분들이 분명히 있다고 생각하고 그만큼 경험은 값진 것이다.
나는 이번 경험을 계기로 여태 성장하지 못했던 역량들을 느끼고 깨닫고 성장할 수 있었던 거 같다.
앞으로는 겁먹지말고 다양한 경험을 하면서 다양한 방면으로 역량을 쌓아보고 싶다!
2023년에도 겁먹지 말고 일단 해보자! 내 슬로건 처럼 실패했어도 배우면 실패가 아니다!

우수사원

열심히 일을하고 있는데 갑자기 메일이 왔다.

회사에서 분기마다 소위말하는 우수사원상을 주는데,
본부당 한두명만 받을 수 있고 본부의 리더가 뽑는 만큼 회사에서 역량을 잘 펼치는 사람들에게 주는 상이다. (는 나의 희망사항이다)
내가 이번에 그 우수사원상을 받게 된 것이다!

누군가 나에게 이 상을 받을 만큼 열심히 했냐고 물어본다면 나는 1초도 망설이지 않고 그렇다고 할 것이다.
어이없어 보일진 모르겠지만, 내가 잘했다는 게 아니라 회사를 위해서 정말 열심히 했다는 것이다.
야근도 많이 했고(야근이 열심히 했다는 결과 지표는 절대 아니다)
더 나은 성능을 위해 수 없이 공부하고 고민하고 개선해 나갔으며 수많은 이슈를 대응했다.
내가 한 일들이 모두 좋은 결과를 냈다고 자부할 순 없지만, 그럼에도 난 그저 최선을 다했다.

그래서 나는 이 상을 받았을 때 열심히 한 나에게 주는 작은 선물이라고 생각하며 기분 좋게 받았던 것 같다.
가끔 이런 보상이 있어야 더 열심히 달릴 연료가 되지 않을까? 어디서든 무엇을 하든 지금처럼 그저 묵묵히 최선을 다하자!

첫 번째 이직 그리고

올해는 내 인생 첫 이직을 준비하게 된 해이다.
취준생 시절에도 자소서 쓰는 거에는 자신이 있었던 터라 이번 이직준비에도 서류 합격은 어렵지 않았던 것 같다.

하지만 기술면접에서 나는 큰 벽을 마주치고 말았다.
신입 시절에는 사실 기술 질문은 거의 없거나 기본적인 CS 질문 수준이었다면,
경력직 이직은 내가 경험한 기술들을 기반으로 깊고 넓게 질문을 한다.
어떤 식으로 준비해야 할지도 어떤 질문이 나올지도 몰랐던 나는 그냥 그렇게 여러 면접을 보면서 좌절하고 우울하고 힘들어했다.

하지만 그럴 때마다 딱 하루만 좌절하자!라는 마음으로 있는 힘껏 힘들어한 후에 다시 일어나서 면접 준비를 했다.
면접을 보다 보니 매번 면접마다 공통적으로 궁금해하는 나의 경험들이 있었고,
내가 강점으로 내세워야 하는 경험이 무엇인지 알게 되었고 원하는 면접 질문을 이끌어 나가는 스킬이 필요하다는 것을 알게 되었다.

어느덧 처음 면접을 볼 때의 긴장감은 많이 해소되고 합불 결과보단 면접을 통해서 하나라도 얻어가고자 하는 마음이 커졌던 것 같다.
그러다 보니 부담감이 줄어들었고 편하게 면접을 볼 수 있었고 오히려 더 자신감이 있는 모습으로 변했다.
이렇게 나는 무사히 이직을 마치고 꿈에 그리던 서비스 회사에 합격하게 되었다!

우테캠 Pro 5기

우테캠 Pro 5기를 수료한 것이 올해 나에게 있어서 기술적으로 가장 큰 아웃풋이라고 생각한다.

회사를 다니면서 수업을 듣는다는 게 굉장히 힘든 일이었고, 매주 과제를 하는 게 꽤나 많은 시간을 투자해야 하는 일이었다.
과제도 그냥 한다고 되는 게 아니라 매번 리뷰어에게 리뷰를 받아야 했고 일정 요구사항을 만족시켜야 다음 단계로 넘어갈 수 있었다.

직접 경험하지 않은 사람은 저걸 왜 힘들어하지?라고 생각할 수도 있다. (나 또한 그랬으니)
과제라고 나오는 주제는 로또 생성기 만들기 같은 굉장히 간단한 과제들이다.
하지만 그 안에서 지켜야 하는 요구사항들과 TDD 작성, 객체지향 생활체조등의 조건을 만족시키며 개발하다 보면 시간이 꽤나 소요된다.
주차가 지날수록 이전 주차의 요구사항 + 이번 주차의 요구사항이 중첩되어 늘어나면서 점점 지켜야 하는 부분들은 늘어나고
또 배운 것들은 학습하고 적용하다 보면 과제의 난이도는 점점 올라간다.

그래서 오히려 쉬운 주제의 과제를 줬었다는 것이 더 많은 것을 느끼게 한다.
과연 정말 그 과제가 쉬웠던 건지, 내가 늘 해오던 방식 빠르지만 잘못된 방식으로 개발을 해서 쉽게 느껴졌던 것인지를 돌이켜 보게 됐다.
그만큼 우테캠 Pro 과정은 나에게 스킬적인 레벨업도 선물해 주었지만,
여태까지 그리고 앞으로의 개발자로서의 건강한 마인드를 선물해 준 것 같다.

두 번째 이직

처음 이직하게 된 모 서비스 회사가 회사의 사정으로 인해 잠정 휴업을 하게 되었다.

메신저로 대뜸 휴업 통보를 받았던 날은 어안이 벙벙했고 어이가 없었다.
회사의 내부사정과 이유도 모른 채 그저 회사가 휴업 절차를 밟고 있으니 따르라는 것이었다.
이 회사에 더 다닐 수 없다고 판단한 나는 떠돌이 신세가 되었고 다시 한번 이직 준비를 하게 되었다.

처음에 이직할 때는 그저 회사의 기술과 네임벨류 같은 것들만 보고 지원을 했는데 이런 일들을 겪고 나니까 다른 것들도 보게 되었다.
지원하려는 회사가 무슨 도메인이고 그 도메인에서 어떤 경쟁력을 갖추고 있는지 그리고 어떤 성과를 내고 있는지를 더 우선시 보게 되었다.
그리고 매번 면접을 볼 때 회사의 내부상황을 투명하게 공유하는지 타운홀 미팅이 주기적으로 열리는지는 질문하게 되었다.

회사에 애사심을 가지고 다니면서 개발을 하려면 적어도 내가 속한 회사의 상황이 어떻고 내가 무엇을 만들고 있으며 이로 인해 유저들에게 어떤 경험을 선사하는지 알고 있어야 한다는 것을 느끼게 되었다.
더 까다로워졌지만 오히려 그래서 더 어렵지 않게 회사를 고르고 이직을 할 수 있었던 것 같다.
의도치 않았지만 더 좋은 서비스 회사로 이직하게 되었고 이 글을 작성하고 있는 2023년 1월 기준 열심히 적응하고 업무를 해나가고 있다.

공부가 재밌었나

올해는 스터디 활동도 유독 열심히 했던 거 같다.
이직 준비를 시작해서 그런지 모르겠지만 학습에 욕구가 생겼고 혼자 공부하는 것보단 다른 사람들과 서로 열정을 가지고 학습하는 게 좀 더 좋은 효과가 있을 것 같다는 생각에 온라인 스터디를 시작했다.

우테캠 프로라는 수업을 시작으로 JPA 스터디와 이펙티브 자바 스터디도 시작을 했고, 작게나마 토이 프로젝트 기획을 시작하게 되었다.
확실히 혼자 공부하는 것보다 더 열심히 할 수 있었고 같은 내용이더라도 여러 시야로 바라보니 오히려 더 폭넓은 공부를 할 수 있게 되었다.
그리고 일정에 맞춰 진행하다 보니 약간의 강제성이 있어에 루즈해지지 않고 꾸준히 진행할 수 있었다.
현재까지도 꾸준히 진행 중이며 그 안에서 많은 것들을 배우고 있다.
한 주제에 스터디가 마무리되면 또 다른 스터디를 꾸려서 진행하는 2023년이 되고 싶다.
학습을 게을리하지 말자!

저 진짜 재밌어서 하는 거예요 (억울)

2022년은 어쩌다 보니 자의로 한번 타의로 한번 이직준비를 하게 되었다. 그래서 1년 동안 정말 많은 기업의 면접을 봤다.

아직 주니어 개발자라서(?) 그런지 면접을 볼 때마다 면접관분들이 공통적으로 하던 질문이 있었는데
‘은혜님에게 개발이란 무엇인가요’ 나 ‘왜 개발을 하게 되었나요’ 같은 뉘앙스의 질문들이었다.
신입 시절에 나였다면 예상 면접 질문을 준비하며 작성했던 멋진 나만의 멘트로 대답을 했겠지만,
(사용자에게 좋은 서비스를 제공하고 싶다거나 사용자 친화적인 서비스를 개발하고 싶다거나.. 물론 아직도 이 마음은 가지고 있다)
이번엔 따로 준비를 안 하기도 했고 솔직하고 싶어서 정말 나의 날 것 그대로 대답을 하였다.

내 대답은 어느 기업이든 상관없이 ‘그냥 개발이 재밌어서요’였다.
내 대답을 들으신 어느 면접관 분은 그저 말없이 웃기만 하시기도 하셨고 또 다른 면접관 분은 그런 거 말고 진짜 은혜님의 생각을 듣고 싶다고도 하기도 하였다.
그럴 때마다 나는 ‘진짜예요…’라고 다시 답변을 하곤 했다.

물론 나는 개발을 한지 오래되지 않았다.
나보다 몇 배 오래 일하신 개발자 분들이라면 '아직 한참 재밌을 때지 싶겠지만' 나는 취준 시절부터 단 한순간도 개발이 재미가 없었던 적이 없었다.
물론 ‘일’을 하다 보면 뜻대로 되지 않아서 힘들기도 하고 짜증 나기도 하고 한 때는 번아웃도 심하게 오기도 하지만 그럼에도 불구하고 나는 그저 개발이 재미있었기에 지금까지 할 수 있었다.
유저에게 제공할 기능을 만들고 그 기능을 개선하고 그 과정에서 여러 장애도 만나보고 그 장애를 밤새 해결해 보고 더 나은 성능을 위해 공부하고 토론하고 개발하고 사실 챗바퀴 같다면 챗바퀴 같은 이 과정을 난 너무 즐겼고 사랑한다.
나는 이 마음을 잃고 싶지 않고 2023년에도 이런 마음으로 개발을 하고자 한다.
내가 개발을 엄청 잘하는 사람이 되기는 힘들진 몰라도 개발을 엄청 재밌어하는 사람으로 손꼽히는 게 나의 큰 목표이다.

2022년 글에 다 적지 못할 만큼 몸 고생도 마음고생도 많이 했다.
하지만 나는 여태 그랬듯이 잘해왔고, 잘할 것이기 때문에 무너지지 않고 한 해를 버틸 수 있었다.
2023년에도 늘 초심 잃지 않고 꾸준히 노력하는 사람이 되어보자!

은혜야 잘해왔고, 잘할 거야!

우아한 테크캠프 Pro 회고록 - EnableJpaAuditing

개발자 김은혜 — Tue, 8 Nov 2022 18:18:53 +0900

벌써 우테캠의 2주 차 순서인 JPA도 얼마 남지 않았다.

시간이 정말 빠른거 같다! 특히 최근 2~3주 동안 너무너무 바빴어서 더 그런 거 같다.

암튼 오늘의 포스팅 주제는 @EnableJpaAuditing 어노테이션이다.

JPA 첫번째 과제를 하다가 배우고 느낀 것들을 정리해보고자 한다!

사건의 발단

created_at timestamp not null,
updated_at timestamp,

여러개의 엔티티를 DDL을 참고하여 JPA 매핑 작업을 하고 있었고,

대부분의 엔티티에는 위의 컬럼들이 공통적으로 구현되어 있었다.

나는 첫번째 회사에서도 사용해본 경험이 있었어서 바로 저 부분을 공통 클래스로 구현하여 상속을 받는 구조로 구현을 시도했다!

더불어 EnableJpaAuditing 기능을 사용하여 개발자가 직접 데이터를 설정하는 것이 아닌

엔티티의 INSERT, UPDATE 쿼리가 실행될 때 JPA가 자동으로 데이터를 설정해주는 방식으로 구현을 했다.

내가 원하는 기능으로 구현을 하려면 다음과 같이 구성을 해야 한다.

@EnableJpaAuditing

@MappedSuperclass
@EntityListeners(AuditingEntityListener.class)
public class BaseTime {

    @CreatedDate
    @Column(nullable = false)
    private LocalDateTime createdAt;

    @LastModifiedDate
    private LocalDateTime updatedAt;

    public LocalDateTime getCreatedAt() {
        return createdAt;
    }

    public LocalDateTime getUpdatedAt() {
        return updatedAt;
    }

}

이 부분 관련해서는 많은 포스팅이 있기 때문에 간략히 만 살펴보자.

먼저 애플리케이션 메인 메서드 상단에 @EnableJpaAuditing 어노테이션을 달아준다.
객체의 입장에서 공통 매핑 정보가 필요할 때 사용하는 @MappedSuperClass를 해당 엔티티에 달아준다.
Entity에서 이벤트가 발생할 때마다 특정 로직을 실행하는 @EntityListeners를 달아준다.
- 실행할 특정 로직인 AuditingEntityListener.class를 추가한다.

내가 하고자 했던 거

위의 코드로 엔티티를 구성하면 BaseTime을 상속받은 엔티티들이 INSERT 되거나 UPDATE 될 때 자동으로 데이터를 설정해준다.

그런데 문득 이런 생각이 들었다.

INSERT에는 updatedAt을 NULL로 반영하고, UPDATE 일 때만 updatedAt을 반영하고 싶다!

그래서 어떤 블로그를 참고해서 작업을 진행해보았다. (https://wakestand.tistory.com/936)

updateAt 컬럼에 insertable = false 라는 설정값을 추가하였다.
그러니 다음의 쿼리처럼 INSERT 할 때 값이 반영되지 않은걸 볼 수 있었다.

그런데,

이상하게도 실제 save() 함수가 실행된 후의 객체를 디버깅해보니

updatedAt에 데이터가 들어가져 있는 것이었다.

이것저것 해보고 디버깅을 계속해봐도 도저히 답이 나오지 않아서 우테캠 단체 슬랙에 문의를 드렸다.

댓글이 20개나 달렸다.

(근데 정말 본인들의 일처럼 열정적으로 도와주신다. 멋진 개발자 분들)

그래서 결론이 무엇이냐

거두절미하고 해결했던 해결방안이 무엇이었냐면

@EnableJpaAuditing(modifyOnCreate = false)

이었다!

위에서 작성했던 (insertable = false) 설정을 할 필요 없이 애플리케이션 메인 메서드 상단에 작성했던

@EnableJpaAuditing 어노테이션에 (modifyOnCreate=false) 값을 설정하는 거였다.

(이 자리를 빌려 큰 도움을 주신 백 XX님 그리고 또 다른 많은 분들 모두 모두 다시 한번 감사합니다!)

그렇다면 왜

저 설정을 주어야 하는 걸까?

이유를 알아보기 위해선 위에 BaseTime 엔티티에 설정해 주었던 AuditingEntityListener의 분석이 필요했다.

AuditingEntityListener에는 touchForCreate와 touchForUpdate가 있다.
두 개의 구성은 거의 비슷한데 마지막 줄이 markCreated() / markModified()로 다르다.

하지만 두 가지 경우 모두 메서드를 타고 들어가 보면

touch()라는 동일한 메서드가 실행된 결과를 리턴하게 된다!
touch() 메소드 내부에는 touchAuditor() 메서드를 또 실행하는데 이 부분이 포인트이다!

마지막 두 개의 조건을 확인해보면 isNew (created 시에는 true가, modified 시에는 false가 들어간다.)라는 값과

modifyOnCreation이라는 값을 가지고 무언가의 행위를 하는데,

즉, modified 시에 modifyOnCreation 값에 따라 값을 세팅할지 말지를 결정하게 되는 것이다!

그리고 이 값은 자체적으로 기본값이 true로 되어있었다!

그래서 나는 @EnableJpaAuditing(modifyOnCreate=false)를 통해서 저 값을 변경하여 사용해야 했던 것이었다.

많은 분들의 도움을 받아서 문제를 해결하게 되었고,

테스트 코드를 통과할 때의 짜릿함이란 말로 표현할 수 없었다.

다시 한번 더 테스트와 코드 분석 그리고 주위에 능력 있고 열정 넘치는 개발자(?) 들의 중요성을 느끼게 되었다.

그럼 안녕! (너무 급하게 포스팅이 마무리된 감이 있네)

우아한 테크캠프 Pro 프리코스 회고록 - 객체지향 생활체조

개발자 김은혜 — Wed, 2 Nov 2022 02:38:31 +0900

정말 오랜만에 포스팅을 하는 것 같다.

요 근래 정말정말 많은 일이 있었는데, 심기일전하고 다시 열심히 해봐야겠다!

아무튼 바쁜와중에 정말 운 좋게 우아한 테크 캠프 Pro 5기에 선발돼서 열심히 공부도 병행하는 중이다.

지금 이미 1주차에 들어섰지만 프리코스 때 배운 점들을 정리해보고자 뒤늦게나마 포스팅을 작성해본다.

과제를 낼때마다 요구사항을 함께 보내주는데, 굉장히 기본적이고 간단해 보이지만 생각보다 까다로웠다.

이번 과제에서 많은 걸 배우고 느꼈던 요구사항 몇 개를 알아보자!

else 예약어를 쓰지 않는다.

개발자라면 조건문의 중요성을 너무나 잘 알거라고 생각한다! 나 또한 조건문을 이용한 코딩을 많이 하는데

else 예약어를 자주 썼던 나로써는 굉장히 당황스러웠다.

그런데 밑에 작은 글씨로 이렇게 적혀있었다.

힌트: if 조건절에서 값을 return하는 방식으로 구현하면 else를 사용하지 않아도 된다.

힌트를 듣고 나는 아래와 같이 코딩을 해봤다! List를 적절한 조건에 맞춰서 생성하여 리턴하는 메소드이다.

private List<Car> resetWinCars(List<Car> winCars, Car car) {
    if (compareResult == MANY) {
        winCars = new ArrayList<>();
        winCars.add(car);
        return winCars;
    }
    if (compareResult == SAME) {
        winCars.add(car);
        return winCars;
    }
    return winCars;
}

if문으로 임의의 조건을 건다.
조건에 해당될 때 바로 리스트를 생성해서 리턴해준다.
즉, else문 없이 원하는 리스트를 받을 수 있다.

일급 콜렉션을 활용해 구현한다.

일급 콜렉션이란 무엇일까?

List, Map 같은 Collection을 Class로 포장하면서, 그 외 다른 멤버 변수가 없는 상태를 뜻한다.

일급 콜렉션에 대해서 잘 정리되어있는 내가 개인적으로 존경하는 개발자분의 포스팅 링크이다.
이번 포스팅은 개념적인 정리보다는 내가 사용하면서 느꼈던 점을 작성하는 회고이기 때문에 개념은 링크로 대체한다!
https://jojoldu.tistory.com/412

public class Lottos {

    private List<Lotto> lottos;
    
    public Lottos(List<Lotto> lottos) {
    	this.lottos = lottos;
    }

    public void generate(int generatorCount) {
        for (int i = 0; i < generatorCount; i++) {
            Lotto lotto = new Lotto();
            lotto.generateRandomNumber();
            lottos.add(lotto);
        }
    }

    public LottoResult calculatorLotto(Lotto lastWeekLotto, LottoNumber bonusNumber) {
        LottoResult lottoResult = new LottoResult();
        for (Lotto lotto : lottos) {
            int sameCount = lotto.sameNumberCount(lastWeekLotto);
            boolean containBonus = lotto.containBonusNumber(bonusNumber);
            lottoResult.addResult(sameCount, containBonus);
        }
        return lottoResult;
    }

    public void addedLotto(Lotto lotto) {
        this.lottos.add(lotto);
    }

    public void addedLottos(Lottos lottos) {
        this.lottos.addAll(lottos.lottos);
    }
}

포장된 클래스의 이름만 보더라도 해당 Collection이 어떤 의미를 가지고 있는지 알 수 있다.
Lottos 클래스가 항상 List<Lotto>의 상태를 유지하고 있기 때문에 행위의 구현에 대한 파라미터가 필요 없다.
- List<Lotto>에 대해서 무언가의 비즈니스 로직이 이뤄져야 할 때 메서드를 호출하며 파라미터로 넘기는 방식이 아닌 Lottos 객체 자체에 메소드를 구현하면 된다.
- Lottos가 List<Lotto>를 Wrapper 하여 가지고 있기 때문에 메서드에 불필요한 파라미터가 필요하지 않게 된다.
List가 제공하는 public 메서드들을 비즈니스 설계에 따라서 제한할 수 있다.
- List<Lotto>에 대한 비즈니스 로직이 Lottos 클래스에 메서드로 구현되어 있기 때문에
- 메서드의 접근제어자에 따라서 외부에서 호출 제한을 아주 정확하게 컨트롤할 수 있다.
- 그렇게 되면 설계상 List<Lotto>에 가해져서는 안될 행위를 미연에 방지할 수 있다.
List<Lotto>에 관련된 로직이 Lottos 클래스에 모두 모여있기 때문에 유지보수가 간편하다.

모든 원시 값과 문자열을 포장한다.

이 말은 int, long, String 같은 원시 타입, 문자열 변수를 객체로 포장해서 사용하라는 의미이다.

이렇게 사용하면서 어떤 이점이 있었는지 확인해보자.

public class LottoNumber implements Comparable<LottoNumber> {

    private int number;

    public LottoNumber(int number) {
        this.number = number;
    }

    public LottoNumber(String number) {
        try {
            this.number = Integer.parseInt(number);
        } catch (Exception e) {
            throw new IllegalArgumentException(ONLY_NUMBER_PAST_LOTTO_INPUT);
        }
        if (this.number < 1 || this.number > 45) {
            throw new IllegalArgumentException(ONLY_NUMBER_BETWEEN_1_TO_45);
        }
    }

    public int value() {
        return number;
    }

    @Override
    public int compareTo(LottoNumber number) {
        if (this.number > number.number) {
            return 1;
        }
        if (this.number < number.number) {
            return -1;
        }
        return 0;
    }

}

일급 콜렉션과 비슷한 의미로 Wrapping 된 원시 값과 문자열의 의도를 클래스 명으로 바로 확인할 수 있다.
- LottoNumber i 와 int i 를 보면 (사실 변수명을 이렇게 지으면 안 되지만) 보자마자 바로 체감할 수 있다.
Comparable 같은 인터페이스를 Override 하여 재정의 할 수 있다.
- 클래스의 도메인 설계에 따라서 필요한 인터페이스를 Overriding 하여 재정의 하면
- 필요할 때마다 비즈니스 로직을 구현할 필요 없이 바로 사용할 수 있으며
- LottoNumber 클래스 안에 종속되어 있기 때문에 유지보수가 간편하다.
생성자를 적극 활용해서 원시 값과 문자열을 정의할 수 있다.
- 생성하는 방식이 다를 때 필요한 곳에서 매번 개발을 하다 보면 중복 코드가 생기기 쉽고 소스가 여기저기 퍼지기 쉽다.
- 하지만 Class의 생성자를 활용하면 중복 코드도 없앨 수 있고 Class 내에 모든 로직을 개발할 수 있다.

여기까지 내가 우테캠 Pro 프리코스를 경험하며 느꼈던 많은 내용 중에 '크게 와닿았던' 부분이다!

이런 부분들을 공부하고 배우면서 실제 강의를 수강해보고 싶다는 생각을 하게 되었는데,

운 좋게도 프리코스에서 합격해서 실제 수강생이 돼서 1주 차를 수강하고 있다.

(이 메일을 받았을 때 얼마나 기뻤던지 모른다.)

자세하게는 설명할 수 없지만 현재 여러 가지 일이 겹쳐서 굉장히 바쁘고 정신없지만

좋은 기회로 우테캠 Pro의 수강생이 되어 수강을 하고 있으니 최선을 다해서 수료해보고자 한다!

이번 포스팅처럼 강의를 수강하고 과제를 해나가면서 느끼는 부분들을 자주 포스팅해봐야겠다.

파이팅!

Java Stream 모르고(?) 쓰면 일어나는 일들

개발자 김은혜 — Fri, 16 Sep 2022 13:54:49 +0900

오늘 포스팅은 다소 어이없을(?) 수도 있다.

오늘의 주제는 Java Stream의 일부인데, 모르고 쓴다기보단 막 쓰면 일어나는 일이라고 해야 할 수도 있겠다.

더 나아가자면 Stream의 문제가 아닌 그냥 개발자의 태도의 관한 포스팅이라고 생각하면 편할거 같다.

이전 회사에서는 Stream을 자주 사용하지 않았다.

대부분을 향상된 For문과 조건문을 활용해서 각종 필터링 작업을 진행하고, 그룹핑 해야하는 부분에서만 간혹 사용하곤 했다.

그런데 이번 회사는 신기할정도로 Stream을 자주 쓰고 거의 대부분이 Stream을 통해 구현되어 있다.

적응하면 가독성도 좋아지고 퍼포먼스도 잘 나온다고들 하는데, 나는 사용을 거의 안 해봐서 별로 체감하지 못하고 있었다.

그래도 지금 하는 프로젝트에선 주로 사용하니 조금씩 익숙해져 가고 있을 때 이러한 코드를 보게 되었다.

똑같은 코드는 아니고 객체명이나 변수명들은 대충 치환하였다.

List<User> Users = userDtos.stream()
    .peek(x -> x.setXxx(userDtoMap.get(String.valueOf(x.getXxx()))))
    .peek(x -> x.setYyy(userDtoMap.get(String.valueOf(x.getYyy))))
    .peek(x -> x.setZzz(UserType.getType(x.getType(), String.valueOf(x.getZzz()))))
    .filter(x -> x.getPage() == page).collect(Collectors.toList());

이걸 보면서 여러 가지 생각이 들었다.

" peek() 메소드는 무슨 역할을 하는 걸까? "

" 변수를 세팅해주기 위해 한 개의 변수당 한개의 peek() 메소드를 호출할 필요가 있을까? "

" filter() 처리를 하고 peek() 메소드를 호출하는 게 낫지 않을까? "

등등

그래서 확인해 보았다!

List<String> ids = Arrays.asList("첫번째(ok)", "두번째(ok)", "세번째(ok)", "네번째(no)");
List<String> newIds = ids.stream()
                        .peek(x -> System.out.println("first peek() : " + x))
                        .peek(x -> System.out.println("second peek() : " + x))
                        .peek(x -> System.out.println("third peek() : " + x))
                        .filter(x -> x.contains("no"))
                        .collect(Collectors.toList());
System.out.println("newIds size : " + newIds.size());

동일한 구조로 만들어 보았다.

peek() 메소드는 무언가의 작업을 한다.
peek() 메소드를 1번 이상 호출한다.
filter() 메소드를 통해 원하는 값만 추출한다.
리스트로 변환하여 리턴한다.

결과는 다음과 같았다.

first peek() : 첫번째(ok)
second peek() : 첫번째(ok)
third peek() : 첫번째(ok)
first peek() : 두번째(ok)
second peek() : 두번째(ok)
third peek() : 두번째(ok)
first peek() : 세번째(ok)
second peek() : 세번째(ok)
third peek() : 세번째(ok)
first peek() : 네번째(no)
second peek() : 네번째(no)
third peek() : 네번째(no)
newIds size : 1

Wow 놀라운 일이 일어나고 있었다.

결국 내가 사용하고자 하는 결과 리스트는 한 개의 객체만을 가지고 있다.

하지만 filter()를 선행하지 않아서 불필요한 행위들이 진행되었고, peek() 메서드를 매번 부르면서 리스트를 계속 순회하고 있었다.

테스트한 리스트의 사이즈가 작아서 별 문제가 안 되겠지만,

만약 백건 천 건, 더 나아가 만 건 이상의 데이터가 있는 리스트를 세 번 순회하며 무언가의 행위를 한다면

그 로직은 상당히 비효율적이고 느린 로직이 될 것이다.

나는 그래서 이렇게 변경하였다.

List<String> ids = Arrays.asList("첫번째(ok)", "두번째(ok)", "세번째(ok)", "네번째(no)");
List<String> newIds = ids.stream()
                        .filter(x -> x.contains("no"))
                        .peek(x -> System.out.println("first + second + third peek() : " + x))
                        .collect(Collectors.toList());
System.out.println("newIds size : " + newIds.size());

first + second + third peek() : 네번째(no)
newIds size : 1

필요한 데이터를 먼저 선 필터링하여 추출한 후, 내가 하고자 하는 연산을 한 번에 처리해 주는 것이다.

이러면 불필요하게 리스트를 순회하지 않아도 되고 선 필터링을 하기 때문에 순회하게 될 리스트 사이즈가 줄어든다!

이런 내용을 포스팅하자니 조금 자괴감(?)이 들기도 하는데,

항상 내가 짜고 있는 코드가 어떤 흐름인지 파악하고 더 효율적이고 좋은 성능의 코드는 없을지 고민하는 내가 되도록 하자!

파이팅!

Spring MVC 톺아보기 (1) - Controller

개발자 김은혜 — Wed, 14 Sep 2022 14:54:36 +0900

안녕하세요! 해피 추석입니다

이전에 다니던 회사에서는 모든 서버에 Swagger UI를 도입하여 사용하였다.

Swagger UI를 사용하면 컨트롤러에 설정한 모든 Endpoint나 Parameter들이 개발자가 세팅하지 않아도

화면으로 구성된 칸에 작성만 해주면 알아서 적절하게 API Request를 날려준다.

하지만 지금 다니는 회사에서 한 서버에 Swagger UI를 사용하지 않고 있다.

Swagger UI 물론 굉장히 쉽고 간편하지만, 너무 편하게 사용한 나머지 어떻게 사용되는지를 생각하지 않고 개발을 하게 되어서

Swagger UI를 사용하지 않는 서버에서 API 테스트를 하려고 하니 앞이 막막했다.

Postman을 사용하여 API를 테스트하는데, 자동으로 세팅해주던 Swagger UI와는 다르게

컨트롤러에 설정된 요청 방식에 따라서 개발자가 직접 세팅을 해야 하는데 기본기를 놓쳤다 보니 어려움이 있었다.

그래서 이번 추석 연휴를 맞이하여 Spring MVC Docs를 읽으면서 개념 공부를 할 예정이다!

굉장히 많은 부분이 있지만 컨트롤러를 위주로 공부해보자.

https://docs.spring.io/spring-framework/docs/current/reference/html/web.html#mvc-controller

@Controller vs @RestController

컨트롤러 행위를 하고자 하는 클래스에 Annotation을 달아서 컨트롤러임을 명시하는데

두 어노테이션의 차이는 간단하게 설명하자면 두 가지의 차이는 반환하는 데이터 형식의 차이이다.

@Controller는 전통적인 Spring MVC의 컨트롤러로 View를 반환하기 위해 사용한다.

하지만 View가 아닌 일반 Data를 반환해야 하는 경우도 있다.

이때 모두가 알다시피 @RequestBody 어노테이션을 함께 달아 사용한다.

이러한 두 어노테이션이 합쳐진게 @RestController이다.

각 어노테이션을 구조를 살펴보면,

@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Component
public @interface Controller {}

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Controller
@ResponseBody
public @interface RestController {}

@RestController의 어노테이션에 @Controller와 @ResponseBody 어노테이션이 모두 달려있음을 확인할 수 있다.

참고!

@RequestMapping 어노테이션만 달려있어도 Spring Controller로 인식한다.
일반 @Controller와 같은 매핑 역할을 해준다.

Mapping Reqeust

@RequestMapping 어노테이션을 사용하면 Request를 컨트롤러 메소드에 매핑할 수 있다.

URL, HTTP Method, Reqeust Parameter, Header 등 여러 값을 매핑할 수 있다.

public @interface RequestMapping {
    String name() default "";
    String[] value() default {};
    String[] path() default {};
    RequestMethod[] method() default {};
    String[] params() default {};
    String[] headers() default {};
    String[] consumes() default {};
    String[] produces() default {};
}

HTTP Method : method
- HTTP 요청 메소드를 명시하며 RequestMethod (Enum) 값을 적어준다.
- 그 외에 어노테이션 방식으로 작성할 수도 있다.
  - @GetMapping: GET
  - @PostMapping : POST
  - @PutMapping : PUT
  - @DeleteMapping : DELETE
  - @PatchMapping : PATCH

위 정보들은 @RequestMapping 어노테이션의 필드들과 매칭 되어 사용된다.

@AliasFor(annotation = RequestMapping.class)
String name() default "";

결국 같은 기능을 하지만 HTTP Method를 추가 매핑한다는 점이 추가된 것이다.

Endpoint : path / value

아무 필드 이름을 명시하지 않고 값만 작성하면 기본적으로 path / value 값으로 명시된다

@GetMapping("/{id}")
public Person getPerson(@PathVariable Long id) {
}

참고!

@RequestMapping 에는 path와 value 값이 존재하는데 두 개는 같은 의미를 뜻한다!
코드를 살펴보면 두 가지가 서로 @AliasFor 어노테이션을 통해서 서로의 이름을 향하고 있다.

@AliasFor("path") String [] value() default {};
@AliasFor("value") String [] path() default {};

URI 패턴
- PathPattern
- AntPathMatcher

공식 문서에 따르면 PathPattern은 웹 애플리케이션에 권장되며 Spring WebFlux에서 유일하게 선택했다고 명시되어 있으며

Spring 버전 5.3 이전에는 AntPathMatcher 뿐이었고 기본값이지만 그 후 PathPattern을 사용할 수 있다.

Stack Overflow 답변에 따르면 PathPattern의 처리량이 6-8배와 할당 비율에 30-40% 감소를 나타내고 있다고 한다.

패턴 비교
- URI 변수로 계산
- 단일 와일드카드로 계산
- 이중 와일드카드로 계산
- 동일한 점수 시, 긴 패턴이 선택
- 동일한 점수와 동일한 길이의 패턴 일시 와일드카드보다 URI 변수가 더 많은 패턴이 선택

접미사 일치
- Spring MVC 5.3 이상부터 .* 패턴을 지원하지 않는다고 한다.
- 브라우저가 일관되게 해석하기 어려운 Header를 보낼 때 위와 같은 방식을 사용했지만
- 현재로서는 더 이상 필요하지 않기 때문에 Accept Header를 사용하는 것이 선호된다.

@RequestMapping(value = "/user*", method = RequestMethod.GET)

( 와일드카드만 단독으로 사용할 때 )

@RequestMapping(value = "/user.*", method = RequestMethod.GET)

( 와일드카드앞에 .을 추가하여 사용할 때 )

Media Type : consumes / produces
- consumes : 요청이 들어올 때의 데이터 타입
- produces : 요청이 나갈 때의 데이터 타입
- 부정표현도 지원 ex) consumes = "!test/plain"

@PostMapping(path = "/pets", consumes = "application/json")
@GetMapping(path = "/pets/{petId}", produces = "application/json")

Parameter / Header : params / headers
- 정해진 값이 Parameter와 Header로 들어왔을 때 요청을 허용
- params : 정해진 파라미터만 허용
- headers : 정해진 헤더 값만 허용
- 마찬가지로 부정 표현도 지원

@GetMapping(path = "/user", params = "userId=ehkim")

Handler Method

요청과 응답에 대해서 여러 타입을 지원한다.

요청

@RequestParam
- 서블릿 요청 매개변수 (쿼리 매개변수)를 바인딩
  - @RequestParam("petId") int petId
  - localhost:8080?petId=value
- 기본적으로 아무 어노테이션이 없다면 @RequestParam 타입이다.
- 필수 매개변수임을 명시하지만 required 플래그를 false로 지정하거나 Optional 인수로 선언하여 선택사항으로 지정할 수 있다.
- Map<String, String> 또는 MultiValueMap<String, String> 이용하여 적절한 key 값으로 파라미터를 조회할 수 있다.
@RequestHeader
- 요청 헤더를 바인딩
  - Host, Accept, Accept-Language, Accept-Encoding, Accept-Charset, Keep-Alive
  - @RequestHeader("Accept-Encoding") String encoding
- Map<String, String> 또는 MultiValueMap<String, String> 이용하여 적절한 key 값으로 파라미터를 조회할 수 있다.
- 쉼표로 구분된 문자열은 Stirng[] 또는 List<String>으로 변환하여 사용할 수 있다.
@CookieValue
- HTTP 쿠키 값을 바인딩
- @CookieValue("JSESSIONID") String cookie
@ModelAttribute
- 모델의 속성에 액세스 하거나 존재하지 않는 경우 인스턴스화 한다.
- @ModelAttribute로 명시된 인스턴스는 아래의 방법 중 한 가지로 소싱된다.
  - @ModelAttribute 매개변수로 넘어왔을 모델을 통해 검색
  - @SessionAttributes가 클래스 수준에 명시되어 있을 경우 HTTP 세션에서 검색
  - 경로 변수나 요청 매개변수에서 이름이 일치하는 곳에서 검색
  - 기본 생성자를 통해 인스턴스화
  - 서블릿 요청 매개변수와 일치하는 인수가 있는 기본 생성자를 통해 인스턴스화
@SessionAttributes (Controller 내 속성)
- HTTP 요청 시 서블릿 세션에 모델 속성을 저장하는 데 사용된다.
- @SessiontAttributes("pet") : 서블릿 세션에 값 저장
- SessionSatus.setComplete() : 서블릿 세션에서 값 삭제
@SessionAttribute (Controller 외 속성)
- Controller 외 (인터셉터나 필터)에서 생성된 세션 데이터에 접근하는 데 사용된다.
@RequestAttribute
- 서블릿 필터나 스프링 인터셉터 이전에 생성된 요청 속성 값에 바인딩한다.
- @RequestAttribute Client client
리디렉션
- 어떤 요청의 결과로 페이지를 포워딩해야 하는 경우 새로고침 등의 행위를 방지하고자 결과를 redirect 처리하기 위한다.
- 이를 통해 데이터를 리디렉션 대상으로 전달할 수 있다.
- return "redirect:{url}"
- 하지만 위 방식이면 데이터의 정보를 숨길 수 없고 인코딩 등의 문제가 있다.
- 그때 사용하는 것이 RedirectAttributes 객체이다.
플래시
- 데이터를 리디렉션 대상을 전달할 수 있는 다른 방법이다.
- Post - Redirect - Get 패턴에 주로 쓰인다.
- 플래시 속성 값들은 리디렉션 후 요청에 사용할 수 있도록 세션에 임시로 저장되고 즉시 제거된다.
- @RequestMapping 어노테이션이 달린 컨트롤러에서는 직접 작업할 필요는 없다.
  - RedirectAttributes를 사용하면 자동으로 FlashMap에 전파된다.
멀티파트
- MultipartResolver가 활성화되면 multipart/form-data가 포함된 POST의 요청에 액세스 할 수 있다.
- List<Multipartfile> : 동일한 이름에 대한 여러 개의 파일
- @RequestParam으로도 액세스가 가능하지만 설정에 따라 Json으로 역직렬화 역할이 실행될 수 있다.
- 기본적으로는 @MultiPart와 함께 사용할 수 있다.
@RequestBody
- 요청 데이터를 직렬화 한다.
- @Validate 어노테이션과 함께 유효성 검사를 제공한다.
- @ResponseBody는 직렬화를 담당하는 거고 데이터 포맷팅 (json, xml) 행위는 별개로 HttpMessageConverter가 처리한다.
HttpEntity
- @RequestBody + Content + Header

String 기반의 요청 입력을 담당하는 어노테이션인 @RequestParam, @RequestHeader, @PathVariable, @MatrixVariable, @CookieValue는 다른 데이터 타입으로 선언되어있을 시, 구성한 변환기에 따라서 자동으로 형식 변환이 적용된다. (아래에 정리된 DataBinder의 역할)

응답

@ResponseBody
- 응답 데이터를 직렬화 한다.
- 클래스 레벨과 메서드 레벨을 모두 지원한다.
- @ResponseBody는 직렬화를 담당하는거고 데이터 포맷팅 (json, xml) 행위는 별개로 HttpMessageConverter가 처리한다.
ResponseEntity
- @ResponseBody + Status + Header
- 유형에 따라서 비동기 처리 등을 지원한다.

HttpMessageConverter
- @RequestBody, @ResponseBody로 요청이나 응답의 데이터 변환 처리 시 사용하는 컨버터 인터페이스
- 변환을 하고자 하는 데이터 타입에 맞춰 실제 구현체 클래스를 사용한다.
  1. StringHttpMessageConverter
    - text/*
    - Content-Type : text/plain
  2. FormHttpMessageConverter
    - application/x-www-form-urlencoded
    - MultiValueMap<String, Object>
    - multipart/form-data
  3. ByteArrayHttpMessageConverter
    - */*
    - Content-Type : application/octet-stream
  4. MarshallingHttpMessageConverter (org.springframework.oxm.Marshaller)
    - text/xml
    - applicatioin/xml
  5. MappingJackson2HttpMessageConverter
    - application/json
  6. SourceHttpMessageConverter (javax.xml.transform.Source)
    - text/xml
    - application/xml
  7. BufferedImageHttpMessageConverter
    - java.awt.image.BufferedImage
    - Java I/O API

DataBinder

@Controller 또는 @ControllerAdvice가 명시된 클래스는 @InitBinder를 통해 WebDataBinder를 초기화하고 다음과 같은 기능을 수행한다.

요청 파라미터를 모델 객체에 바인딩
문자열 기반의 요청 값(Parameter, Path, Header, Cookie 등)을 컨트롤러 대상 유형으로 변환
문자열 양식의 데이터를 HTML 양식으로 렌더링

즉, 클라이언트가 서버에게 요청을 할 때 클라이언트가 명시한 값들을 서버(Spring Web MVC)에서 사용되는 각종 객체들로 바인딩하는 역할을 하는 것이다.

Exception

@ExceptionHandler를 이용하여 예외를 처리할 수 있다.

@Controller, @RestController가 적용된 Bean 내에서 발생하는 예외를 처리한다.

그렇기 때문에 @Service나 @Repository가 적용된 @Bean에서는 사용할 수 없다.

@ExceptionHandler({FileSystemException.class, RemoteException.class})

예외처리를 하고자 하는 예외 클래스의 이름들을 명시하여 특정 예외 유형 목록을 사용할 수도 있다.

@ExceptionHandler(NullPointerException.class)
public String handle(NullPointerException ex) {
    return "NullPointerException";
}

@ExceptionHandler(RuntimeException.class)
public String handle(RuntimeException ex) {
    return "RuntimeException";
}

위 상황처럼 예외처리가 핸들링되는 경우에는 좀 더 하위 예외가 우선순위를 가진다.

즉, 위의 @ExceptionHandler가 명시된 컨트롤러에서 NullPointException이 발생하면 상위의 handler 메서드가 실행된다.

예외 유형 사이의 불일치 가능성을 줄이기 위해서 최대한 구체적으로 명시하는 것이 좋다.
즉, 전파되는 최상위 예외나 래퍼 예외 같은 예외를 명시하는 것보다 구체적으로 정의된 예외를 명시하는 것이 좋다.

@ExceptionHandler의 여러 인수들과 반환 값들은 굉장히 다양하니 공식 문서를 확인하자!

REST 서비스는 일반적으로 예외를 그대로 응답하는 것이 아닌, 응답 본문에 오류 세부 정보를 포함하는 것이다.
하지만 Spring Framework는 이를 자동으로 수행하지 않으니, 이러한 핸들러를 활용하여 예외를 적절하게 재정의 후 응답하는 것이다.

Controller Advice

@ExceptionHandler와 @InitBinder 어노테이션은 @Controller가 가 적용된 클래스에만 적용되지만

@ControllerAdvice와 @RestControllerAdvice는 모든 컨트롤러에 적용된다.

또한 @Component 어노테이션이 달려있어 스프링 빈으로 등록하여 사용할 수 있다.

@ControllerAdvice
@ResponseBody
public @interface RestControllerAdvice

@ResponseBody 어노테이션이 달려있기 때문에 HTML이 아닌

응답 객체 변환을 통해 렌더링 된 반환 값을 갖는다.

내부 속성 값들을 통해서 일부 컨트롤러에 매핑하여 사용할 수도 있다.

@ControllerAdvice(annotations = RestController.class)

작성된 값들은 런타임에 평가가 되고 광범위하게 사용하게 되면 성능의 부정적인 영향을 미칠 수 있으니 주의해야 한다!

매번 한국어로 잘 정리된 블로그 글만 보다가 영어로 된 공식 문서로 공부하다 보니 사실 이해되지 못한 부분도 꽤나 있었다.

하지만 공식 문서에는 정리되어 있지 않은 여러 정보들을 알고 '존재한다' 정도의 사실을 알게 되어서 좋았다.

이번을 기회로 Spring Web MVC 공식문서를 한번 훑어보며 공부를 해보고자 한다!

가보자고!

Concurrency Problem 올바른 대응방법 (1) - Lock

개발자 김은혜 — Fri, 9 Sep 2022 15:09:34 +0900

동시성 이슈 문제를 해결했던 업무 회고를 작성했던 지난 포스팅에 이어서

동시성 이슈 문제의 해결 방법 중 하나인 Lock이라는 거에 대해서 좀 더 자세히 알아보고자 한다.

지난 포스팅에서 나는 동시성 이슈를 JPA의 Lock Annotation을 이용하여 대응을 하였다.

동시성 이슈에 대해서 공부 하다보면 대응을 위해서 Redis 데이터베이스를 썼다는 이야기가 많이 나온다.

대략적인 이유를 보면 '단일 스레드 처리 방식과 데이터 잠금의 차이'라고 나와있다.

나는 그래서 Lock을 사용하고자 했던 거고 이번 기회에 Lock에 대해 더 공부를 하게 되었다.

Lock?

Lock이란 트랜잭션 처리의 순차성을 보장하기 위한 방법으로,

같은 데이터에 동시에 접근하는 경우 데이터의 일관성과 무결성의 유지를 위해 사용하는 기술이다.

DBMS마다 Lock을 구현하는 방식이 다르기 때문에 원하는 DB별 Lock에 대한 이해가 필요하다.

또한 Application 레벨에서도 설정할 수 있다.

이처럼 때와 상황에 맞춰서 어느 레벨에서 관리하는지도 중요한 관리 포인트가 될 것이라 생각한다.

개인적으로는 접근하고자 하는 데이터나 비지니스 상황에 따라 Lock의 설정을
다르게 하고자 할 수도 있기 때문에 Application 레벨이 좀 더 유연하게 대처할 수 있지 않을까 라는 생각을 한다.
또한 데이터베이스 레벨에서 Lock을 설정하여 구현하게 되면 성능 저하를 야기할 수도 있지 않을까? 싶기도 하다.

Database (Postgresql)

기본적으로 DB의 Lock는 공유(Shared) Lock과 베타(Exclusive) Lock이 있으며

공유 Lock은 Read Lock 이라고도 불리고 배타 Lock은 Write Lock 이라고도 불린다.

공유(Shared) Lock
- 데이터를 읽을때 사용되는 Lock
- 같은 공유 Lock 끼리는 동시에 접근이 가능
- 즉, 하나의 데이터를 읽는 것은 여러 사용자가 동시에 할 수 있다는 것
베타(Exclusive) Lock
- 데이터를 변경하고자 할때 사용되는 Lock
- 트랜잭션이 완료될 때까지 유지
- Lock이 해제될 때까지 다른 트랜잭션(Read 포함)은 데이터에 접근할 수 없음

DB별로 Lock에 대한 세부설정이 다르기 때문에 일단 내가 동시성 이슈를 대응했던 Postgresql 기준으로 알아보았다.

Lock의 종류가 위의 두가지를 기준으로 좀 더 세부적으로 존재하는 듯했다.

Read Lock - AccessSharedLock
- AccessSharedLock은 SEELCT 명령문으로 잡히는 Lock이다.
- 첫 번째 세션이 트랜잭션을 생성하여 계정 정보를 조회하고,
- 두 번째 세션이 다른 트랜잭션으로 동일한 계정 정보를 조회하더라고 이상 없이 동일한 정보를 조회한다.

session1> begin; 
session1> select user_id, company from user_info where email = 'admin';
email | company
-----------------
admin | [NULL]


session2> begin; 
session2> select email, company from user_info where email = 'admin';
email | company
-----------------
admin | [NULL]

select locktype, relation::regclass, mode, transactionid tid, pid, granted 
from pg_catalog.pg_locks where not pid=pg_backend_pid();

relation	user_info	AccessShareLock		6322	true

Write Lock - RowExclusiveLock
- RowExclusiveLock은 UPDATE, DELETE, INSERT 명령문으로 잡고 있는 Lock이다.
- 첫 번째 세션이 트랜잭션을 시작하고 데이터를 수정한 후, 수정된 데이터를 조회하면 수정된 데이터가 정상적으로 조회된다.
- 하지만 두 번째 세션이 트랜잭션을 새로 시작하고 첫 번째 세션이 트랜잭션을 종료하기 전에 동일 데이터를 조회하면
- 수정되기 전에 데이터로 조회되는것을 확인할 수 있다.
- 이는 데이터의 정합성과 무결성을 정하는 격리수준인 Isolation level이 대부분의 DB에서는 Read Committed로 되어있기 때문이다.
- 이것은 Commit을 한 정보만 다른 세션 또는 트랜잭션에서 확인할 수 있음을 의미한다.
- RowExclusiveLock은 ExclusiveLock 중에 하나로 데이터를 변경할 때 다른 사람이 동시에 바꿀수 없도록 쓰기 잠금을 걸고, 쓰기를 마치면 잠금을 해제한다.
- 물론 쓰기 잠금이 걸려있을 때는 다른 잠금을 걸 수 없다.

session1> begin; 
session1> select email, company from user_info where email = 'admin';
email | company
-----------------
admin | [NULL]
session1> update user_info set company = 'company' where email = 'admin';
session1> select email, company from user_info where email = 'admin';
email | company
-----------------
admin | company

session2> begin; 
session2> select email, company from user_info where email = 'admin';
email | company
-----------------
admin | [NULL]

select locktype, relation::regclass, mode, transactionid tid, pid, granted 
from pg_catalog.pg_locks where not pid=pg_backend_pid();

virtualxid	[NULL]	ExclusiveLock		6417	true

Race Condition - SharedLock
- 첫번째 세션이 트랜잭션을 생성하고 데이터를 수정한 후, 트랜잭션이 종료되지 않은 상황에서
- 두번째 세션이 트랜잭션을 생성하여 동일 데이터에 수정 작업을 진행하게 되면 쿼리가 정상적으로 작동하지 않고 대기를 한다.
- 그 후에 첫번째 세션의 트랜잭션이 정상적으로 종료된 후에야 두 번째 세션의 데이터 수정 작업이 완료된다.
- Lock 정보를 조회해보면 Shared Lock이 추가되었음을 확인할 수 있다.
- Shared Lock은 공유 잠금 또는 읽기 잠금이라는 뜻으로
- 동시에 데이터를 변경할 때 생기는 문제를 보호하기 위하여 먼저 Lock을 잡은 TransactionId에 공유를 요청하는 Lock으로
- 첫 번째 세션이 먼저 UPDATE 행위를 통해 ExclusiveLock을 잡고 있었기 때문에 SharedLock과 Conflict 되어 Lock이 Granted 되지 않았던 것이다.

session1> begin; 
session1> update user_info set company = 'company' where email = 'admin';
UPDATE 1

session2> begin; 
session2> update user_info set company = 'company2' where email = 'admin';

session1> commit;

select locktype, relation::regclass, mode, transactionid tid, pid, granted 
from pg_catalog.pg_locks where not pid=pg_backend_pid();

transactionid	[NULL]	ShareLock	1129	8902	false

등등 그 외에도 굉장히 다양한 종류의 Lock이 있다.

Application

내가 실제로 사용한 방식인 JPA를 이용한 방식으로 Lock mode를 설정하는 방식을 알아보자.

JPA에서는 Optimistic Lock (낙관적 락)과 Pessimistic Lock (비관적 락)을 제공한다.

Optimistic Lock
- 데이터 갱신 시 충돌이 발생하지 않을 것이라고 낙관적으로 보고 잠금을 거는 기법이다.
- 동시에 동일한 데이터에 대한 여러 업데이트가 서로 간섭하지 않도록 방지하는 version이라는 속성을 확인하여 Entity의 변경사항을 감지하는 메커니즘이다.
- JPA에서 낙관적 잠금을 사용하기 위해 Entity 내부에 @Version 어노테이션이 붙은 변수를 구현하여 줌으로써 간단하게 구현이 가능하다.
- @Version 명시에 주의사항
  1. 각 Entity 클래스에는 하나의 버전 속성만 있어야 한다.
  2. 여러 테이블에 매핑된 Entity의 경우 기본 테이블에 배치되어야 한다.
  3. 버전에 명시할 타입은 int, Integer, long, Long, short, Short, java.sql.Timestamp 중 하나여야 한다.
- JPA는 Select시에 트랜잭션 내부에 버전 속성의 값을 보유하고 트랜잭션이 업데이트를 하기 전에 버전 속성을 다시 확인한다.
- 그동안에 버전 정보가 변경이 되면 OptimisticLockException이 발생하고 변경되지 않으면 트랜잭션은 버전 속성을 증가하는 업데이트를 하게 된다.
- LockMode Type
  1. NONE : 별도의 옵션을 사용하지 않아도 Entity에 @Version이 적용된 필드만 있으면 낙관적 잠금이 적용된다.
  2. OPTIMISTIC (Read) : Entity 수정 시에만 발생하는 낙관적 잠금이 읽기 시에도 발생하도록 설정한다. 읽기 시에도 버전을 치크하고 트랜잭션이 종료될 때까지 다른 트랜잭션에서 변경하지 않음을 보장한다.
  3. OPTIMISTIC_FORCE_INCREMENT (Write) : 낙관적 잠금을 사용하면서 버전 정보를 강제로 증가시키는 옵션이다.
  4. READ, WRITE : READ는 OPTIMISTIC과 같은 역할, WRITE는 OPTIMISTIC_FORCE_INCREMENT와 같은 역할을 하며 JPA 1.0호 환성을 위한 옵션이다.
- OptimisticLockException
  - 권장되는 예외처리 방법에서는 Entity를 다시 로드하거나 새로고침하여 업데이트를 재 시도하는 방법이다.
  - Entity에서 낙관적 잠금 충돌을 감지하면 OptimisticLockException을 발생시키게 되고 트랜잭션은 롤백 처리를 한다.

@Entity
public class Student {
    @Id
    private Long id;
 
    private String name;
 
    private String lastName;
 
    @Version
    private Integer version;
}

Pessimistic Lock
- 트랜잭션의 충돌이 발생한다고 가정하고 우선 락을 걸고 보는 방법으로 트랜잭션 안에서 서비스 로직이 진행되어야 한다.
- LockMode Type
  1. PESSIMISTIC_READ : dirty read가 발생하지 않을 때마다 공유 잠금을 획득하고 데이터가 UPDATE, DELETE 되는 것을 방지할 수 있다.
  2. 데이터베이스에 따라 PESSIMISTIC_READ를 지원하지 않는 경우엔 PESSIMISTIC_WRITE로 대체된다.
  3. PESSIMISTIC_WRITE : 배타적 잠금을 획득하고 데이터를 다른 트랜잭션에서 READ, UPDATE, DELETE 하는 것을 방지할 수 있다.
  4. PESSIMISTIC_FORCE_INCREMENT : 이 잠금은 PESSIMISTIC_WRITE와 유사하게 작동하지만 @Version이 지정된 Entity와 협력하기 위해 도입되어 PESSIMISTIC_FORCE_INCREMEMT 잠금을 획득할 시 버전이 업데이트된다.
- Exception
  1. PessimisticLockException : 잠금은 ShareLock 또는 Exclusive Lock 둘 중에 하나만 얻을 수 있으며 그 락을 얻는데 실패하면 발생하는 예외
  2. LockTimeoutException : 락을 대기하다 설정해놓은 wait time이 초과되었을 때 발생하는 예외
  3. PersistenceException
- Lock Scope
  1. NORMAL : 기본값으로 해당 entity 만 잠금이 설정되고, @Inheritance(strategy = InheritanceThype.JOINED)와 같이 조인 상속을 사용하면 부모도 함께 잠금이 설정된다.
  2. EXTENDED : @ElememtCollection, @OneToOne, @OneToMany 등 연관된 entitye들도 잠금이 설정된다.

결국 내가 동시 결제견에 대한 처리를 이렇게 했다고 정의할 수 있을 것 같다.

@Lock(LockModeType.PESSIMISTIC_WRITE)

결제 건에 대해서는 항상 한 트랜잭션으로 관리를 한다.
즉, 결제 관련 데이터를 조회하고 결제를 요청하고 결제가 완료되면 데이터를 수정해서 다시 저장하는 일련의 과정을 하나의 트랜잭션으로 관리하는 것이다.
하나의 트랜잭션이 일정 결제 건을 조회한다면 Dirty Read를 방지하고자 PESSIMISTIC_WRITE의 LockMode로 데이터를 조회해온다.
LockScope는 결제정보 해당 Entity에만 걸고 연관된 Entity에는 걸지 않는다.

추가로 더 해줘야 하는 것?

데이터에 Lock을 설정하다 보면 (특히 Exclusive Lock) 일정 트랜잭션이 일정 데이터를 점유하고 있는 동안 다른 트랜잭션에 접근이 거부되기 때문에 무한정 대기를 하게 되거나 예외를 내게 되는데 이런 경우의 적절한 처리가 필요할 것이다!

민감한 사용자의 정보일수록 이런 설정들에 더더욱 신경을 써줘야 할 것이다.

특히 결제는 돈이 걸려있는 문제다 보니 더 신중하게 여러 경우의 수를 생각하며 개발하는 것이 좋을 것 같다!

(오늘도 성장하는 나)

CloudFront와 S3를 이용한 정적 데이터 조회 (2)

개발자 김은혜 — Fri, 2 Sep 2022 16:04:15 +0900

포스팅 1탄에 이어서 2탄을 들고 왔다.

1탄과 기능의 전반적인 개념을 정리했다면 2탄에서는 캐시 생명주기 관련한 방안과 실제 어떤 코드를 작성하였는지를 정리하고자 한다!

캐시 데이터를 관리하다 보면 원본 데이터가 저장된 데이터베이스와 캐시 데이터를 가지고 있는 캐시 서버의

데이터 동기화 문제를 많이들 경험하게 될 것이다.

이 기능도 마찬가지로 원본 데이터가 저장되어 있는 데이터베이스(S3)와 캐싱 처리를 하고 있는 캐시 서버(CloudFront) 사이의 데이터 동기화를 항상 신경 써 주어야 한다.

S3에서 원본 데이터가 변경되었음을 CloudFront에서는 알 수 있는 방법이 없기 때문에 동기화 처리는 직접 해주어야 한다.

물론 1탄에서 CloudFront를 구성할 때 설정한 TTL값 만큼의 시간이 흐르고 난 뒤에는 다시 S3에서 데이터를 조회해 오기 때문에 설정한 시간만큼의 여유를 감안할 데이터라면 굳이 임의의 처리를 하지 않고 그저 TTL값 만큼의 시간을 기다리면 된다.

하지만 데이터 별로 데이터가 변경됨을 바로 감지하고 캐싱 서버에 바로 반영해야 한다면 하염없이 그 시간을 기다릴 순 없을 것이다.

그럴 때 사용할 수 있는 방법을 소개한다!

파일 무효화

엣지 캐시에서 파일을 무효화한다. 그러면 다음에 파일을 요청하면 CloudFront는 최신 버전의 파일을 가져오도록 오리진에 반환한다.

파일을 무효화하려면 개별 파일에 대한 경로나 와일드카드로 끝나는 경로 중에 지정할 수 있다.

/images/image1.jpg
/images/image*
/images/*

CloudFront API 방식으로 파일 무효화를 할 수 있다.

파일 무효화: CreateInvalidation
무효화 목록 가져오기: ListInvalidations
특정 무효화 관련 정보 가져오기: GetInvalidation

배포당 한 번에 최대 3,000개의 파일에 대해 진행 중인 무효화 요청이 가능하다.

와일드카드를 사용하는 경우 한 번에 최대 15개의 무효화 경로에 대해 진행 중인 요청이 가능하다.

월별로 제출한 최초 1,000개의 무효화 경로에 대해서는 무료

CloudFront 배포를 사용하여 기존 콘텐츠 업데이트

CloudFront가 제공하는 콘텐츠 관리에 대한 제어를 강화하기 위해 파일 이름이나 폴더 이름에 버전 식별자를 사용하여 파일을 제거한다.

이 식별자는 날짜-타임스탬프, 일련번호 또는 동일 객체의 두 버전을 식별하는 기타 방법이 있다.

image.jpg 대신 image_1.jpg로 초기 저장
image_2.jpg로 변경 후 웹 앱 사이트의 접근 링크 변경

객체 만료까지 기다릴 필요가 없고 객체 무효화 비용의 지불도 없다.

파일의 버전을 관리하는 경우라도 만료 날짜는 설정하는 것이 좋다.

동일한 파일 이름을 사용하여 기존 콘텐츠를 업데이트할 수도 있지만 권장하지 않는다.

참고

파일을 자주 업데이트하려는 경우에는 기본적으로 파일 버전 관리를 사용하는 것이 좋다.

나는 위의 두 가지 방법 중 파일 무효화 방식을 택했다.

일단 파일이 자주 업데이트가 되는 구조는 아니지만 업데이트되는 즉시 캐시 리로드를 해야 했고,

해당 데이터를 조회하는 클라이언트는 업데이트가 되어 변경된 접근 링크 endpoint를 알 수 없는 구조였기 때문이다.

소스코드는 아래와 같다.

Java + Spring Boot 환경이며 기본적으로 제공하는 AWS SDK를 사용하였다.

public void cacheReload(String path) {
    AmazonCloudFront cfClient =
            AmazonCloudFrontClientBuilder.standard()
            .withRegion(region).build();

    String[] paths = {addSeparatorPrefix(path)};
    Paths invalidationPaths = new Paths().withItems(paths).withQuantity(paths.length);
    InvalidationBatch batch = new InvalidationBatch(invalidationPaths, Long.toString(System.currentTimeMillis()));

    cfClient.createInvalidation(new CreateInvalidationRequest(distributionId, batch));
}

캐시를 무효화시키는 부분이다.
CloudFront SDK를 이용하여 원하는 경로에 캐시 데이터를 무효화해준다.

public String uploadObject(String bucketId, File uploadFile, MultipartFile attachment, String keyName) {
    AmazonS3 s3Client = AmazonS3ClientBuilder.standard()
            .withRegion(region)
            .build();
    String bucketName = getBucketName(bucketId);

    try{
        ObjectMetadata metadata = new ObjectMetadata();
        metadata.setContentType(attachment.getContentType());
        metadata.setContentLength(attachment.getSize());

        PutObjectRequest request = new PutObjectRequest(bucketName, keyName, uploadFile);
        request.setMetadata(metadata);

        log.info("upload s3 object: bucket[{}], key[{}]", bucketName, keyName);
        s3Client.putObject(request);

        return s3Client.getUrl(bucketName,keyName).toString();
    } catch (Exception e) {
        log.error("uploadObject Error Message : {}", e.getMessage());
    }

    return "";
}

원본 데이터를 업로드하는 부분이다.
기존 데이터는 백업을 해놓고 동일한 경로와 이름으로 새 파일을 등록해야 했기에 기존 파일에 타임스탬프를 추가하여 복제해 놓은 후, 동일한 이름을 새 파일로 엎어 쓰게 구성되었다.

기본적인 SDK가 너무 잘 구성하여 제공되어 있기 때문에, 방식과 정책만 잘 정한다면 별 어려움 없이 개발할 수 있을 것이다.

이직한 회사에 첫 업무를 잘 마무리할 수 있어서 아주 만족스러웠다!

다음 업무 어서 오고!

Proxy Pattern 으로 구현해보는 다이나믹 서비스 적용기

개발자 김은혜 — Wed, 31 Aug 2022 11:00:25 +0900

회사를 이직한 지 벌써 한 달이 지났다. 딱히 한 게 없는 것 같은데 시간은 정말 빠르게 지나가는 듯하다.

이전 회사랑 업무 스타일이나 사람들 분위기가 달라서 적응하는데 애를 먹고 있지만,

B2C 서비스를 개발하다 보니 이전 회사에서는 경험해보기 어려운 업무들을 할 수 있어서 재미있는 것 같다.

아무튼 오늘 포스팅 주제는

"Proxy Pattern 적용기"이다.

저번에 인프런 김영한 님의 스프링강의를 들으면서 여러 가지 디자인 패턴을 학습하게 되었는데,

그중에 하나가 오늘 포스팅 주제인 Proxy Pattern이다.

나는 기존 사내 프로젝트의 앱 푸시 로직을 개편하게 되는 업무를 맡게 되었고, 업무는 다음과 같았다.

- 기존 : 앱 OS (Android / IOS)에 따른 Messaging 라이브러리로 직접 푸시 로직 구현
- 개선 : NHN Cloud Push 서비스를 연동하는 방식으로 구현

서비스 중인 앱을 개발하다 보니, 사용 중인 사용자들에게 강제 업그레이드를 요청하지 않는 이상

기존 서비스를 제공하는 앱을 사용중인 사용자도 있을 거고 개선된 서비스를 제공하는 앱을 사용하는 사용자도 있을 것이다.

결국 어느 시점 동안에는 (모든 사용자가 버전 업데이트를 하거나, 강제 업그레이드를 진행하기 전) 두 서비스를 모두 제공해야 할 것이다.

평생 두 서비스를 모두 제공한다면 오히려 편할 것이다.

그저 기존 서비스에 새로 개발된 서비스를 추가만 하면 되기 때문이다.

하지만 두 서비스를 모두 제공할 수도, 둘 중에 한 서비스만 제공할 수도, 더불어 새로운 서비스가 추가되어 기존 모든 서비스를 제공하지 않을 수도 있다.

이렇게 제공 서비스가 변경될 때마다 클라이언트 비지니스 로직을 변경한다는 것은

굉장히 번거로운 일이고 자칫 잘못하다 휴먼에러를 발생하여 서비스에 장애를 일으킬 수도 있을 것이다.

이때 내가 떠올린 것이 Proxy Pattern이다.

클라이언트와 서비스 부분의 소스 변경을 최소화하고, 대신 내가 원하는 서비스를 다이나믹하게 사용할 수 있는 프록시를 중간에 둔다면 편하지 않을까? 라는 생각을 하게 되었기 때문이다.

실제 업무에서는 처음 도입해보는 거라 잘 될까 걱정이 앞섰지만, 걱정과는 다르게 간편하게 구현이 되었다!

팩토리 패턴을 고려하지 않은것은 아니다.
두 패턴을 고민했었고, 각 패턴의 정의와 활용방안을 고려해 봤을 때 Proxy Pattern이 더 적절하다고 판단했다.
- Factory Pattern : 객체를 생성하는 클래스 (Factory) 를 따로 구성하는 방식
- Proxy Pattern : 가상의 객체 (Proxy) 를 사용해 로직의 흐름을 제어하는 방식

내가 해야하는 일은 서비스 구현체를 필요에 따라 다르게 생성 하는것이 아닌, 컨트롤러에서 서비스를 호출할 때 상황에 따른 서비스들만 호출될 수 있도록 제어하는 역할이 필요했기 때문에, 최종적으로 Proxy Pattern을 사용하게 되었다.

소스로 확인해보자.

public interface PushService {
    List send();
    ...
}

PushService
- 서비스 비지니스 로직들을 모아놓은 인터페이스이다.
- 실제로는 더 많은 기능 메서드들이 있지만, 일단 한 개만 추출해왔다.

public class LivePushServiceImpl implements PushService {}
public class NHNPushServiceImpl implements PushService {}

LivePushServiceImp / NHNPushServiceImpl
- 인터페이스를 상속받아 실제 로직을 구현할 서비스 클래스이다.
- 기획에 따라서 더 추가가 될 수도, 없어질 수도 있을 것이다.

이제 실제 Proxy Pattern을 사용하여 구성한 클래스 파일들이다.

@Configuration
@RequiredArgsConstructor
public class PushServiceProxyConfiguration {

    @Bean
    public PushService pushService() {
        PushService livePushService = new LivePushServiceImpl();
        PushService nhnPushService = new NHNPushServiceImpl();
        // 실행에 사용하고 하는 서비스 구현체를 리스트 형식으로 담아 프록시를 생성
        PushServiceInvocationHandler handler = new PushServiceInvocationHandler(new LivePushService[]{nhnPushService, livePushService});
        return (PushService) Proxy.newProxyInstance(LivePushService.class.getClassLoader(), new Class[]{LivePushService.class}, handler);
    }

}

PushServiceProxyConfiguration
- 기획이나 배포 상황에 맞춰서 비지니스 로직 실행에 사용할 푸시 서비스의 구현체들을 생성하여 실행 프록시에 담아준다.
- 이때 프록시의 형상은 서비스 인터페이스이고, 빈으로 생성한다.
- 구현체를 DI 하여 사용하는 컨트롤러나 서비스 클래스에서는 어떤 푸시 서비스를 실행할 건지에 대해서 소스를 수정할 필요가 없다.

@RequiredArgsConstructor
public class PushServiceInvocationHandler implements InvocationHandler {

    private final Object[] services;

    @Override
    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        Object result = null;

        ArrayList pushResults = new ArrayList();
        if (services != null) {
            for (Object service : services) {
                if (service != null) {
                    try {
                        result = method.invoke(service, args);
                        if (result != null) {
                            if (result instanceof List) {
                                pushResults.addAll((ArrayList) result);
                                result = pushResults;
                            }
                        }
                    } catch (Exception e) {
                        e.printStackTrace();
                        log.error(String.format("알람 푸시중 에러가 발생하였습니다. 타겟 서비스 [%s], 메세지 [%s]",
                                service.getClass().getName(), e.getMessage()));
                    }
                }
            }
        }

        return result;
    }
}

PushServiceInvocationHandler
- 푸시 서비스의 프록시 클래스이다.
- 생성자로 주입된 필드(실행할 서비스 클래스들)를 반복문으로 돌아가며 하나의 서비스씩 접근한다.
- 서비스 별로 method.invoke() 함수를 호출하여 실제 서비스의 메서드를 호출한다.

즉, 컨트롤러에서 서비스를 호출할 때 사용될 서비스 구현체를 프록시가 제어하여 대신 호출해주는 것이다.

프록시에서 설정한대로 제어하여 호출해주기 때문에 컨트롤러나 서비스레벨의 소스코드를 수정해주지 않아도 된다!

위와 같이 Proxy Pattern이 적용된 클래스들을 추가한 후 생성한 Bean을 주입받아 원하는 메서드를 실행하면,

PushServiceProxyConfiguration에서 리스트로 추가된 모든 서비스 구현체의 메서드가 실행된다!

이젠 기획과 상황에 따라 원하는 서비스 구현체를 넣을 수도 뺄 수도 있고

더 이상 비즈니스 로직 레벨을 그때그때 변경할 필요도 없게 되었다.

사실 어떤 기술이든 이론만 공부한 것과 실제 개발 상황에서 도입하여 사용해보는 것은 머리에 남는 지식 차이도 크고

해당 기술이 가진 이점들의 와닿는 정도가 꽤나 차이가 난다고 생각한다.

이번에 실제로 Proxy Pattern을 실무에 도입하여 사용하면서 이러한 부분을 몸소 체감할 수 있어서 좋았다.

김은혜 패턴을 만드는 그날까지... 열심히 하자! (엥?)

CloudFront와 S3를 이용한 정적 데이터 조회 (1)

개발자 김은혜 — Sat, 20 Aug 2022 21:28:15 +0900

개발을 하다 보면 캐시라는 단어를 여기저기서 많이 들어보게 되는데

캐시란 자주 사용하는 데이터나 값을 미리 복사해 놓는 임시 장소를 가리킨다.

이는 다양한 방식으로 구현하여 사용할 수 있다.

특히 웹 어플리케이션을 개발함에 있어서 자주 사용되는 데이터를 캐시하는 방식은

(내 지식 안에서) 크게 세 가지 정도라고 생각되는데 간단하게만 살펴보자면

데이터베이스 shared buffer 사이즈 확보
- 자주 사용되는 데이터가 rdbms에 있다면 매번 쿼리 하여 디스크에서 데이터를 조회하는 것은 성능에 좋지 않기 때문에
  shared buffer라는 공간을 사용하여 데이터를 캐시 할 수 있다.
- 데이터베이스에 액세스를 시도하면 먼저 디스크에서 필요한 데이터를 공유 버퍼로 먼저 읽어 드리고,
  공유 버퍼에서 데이터를 읽고 쓰기를 처리한다.
- 이후, 동일한 데이터 액세스에 대해서는 공유 버퍼에서 읽어 들여 느린 디스크 액세스를 줄여 성능을 확보할 수 있다.
어플리케이션 인메모리에 저장
- 말 그대로 자주 사용하는 데이터를 웹 어플리케이션 서버가 가지고 있는 메모리에 저장하는 것이다.
- 디스크가 아닌 메모리로 비지니스 로직을 처리하는 어플리케이션 내에 저장하기 때문에 굉장히 속도가 빠르지만 어플리케이션이 재기동되면 사라지는 휘발성 데이터이기 때문에 유실이 되면 안 되는 데이터에는 적합하지 않다.
캐시 관리용 데이터베이스(Redis)에 저장
- 빠른 응답속도를 보장하는 메모리 데이터베이스에 데이터를 저장하는 것이다.
- 많은 기업에서 캐시 용도로 메모리 데이터베이스를 많이 사용하고 있다.
- 나 또한 재직했던 모든 회사에서 그런 이유로 메모리 데이터베이스인 Redis를 많이 사용하였다.

아무튼 이러한 캐시 데이터를 관리하는 방식(?)을 이번에 개발하게 되었는데,

여태 내가 알고 있는 방식이 아닌 다른 방식을 사용하게 되어 공부 겸 정리 겸 공유 겸 이렇게 포스팅을 하게 되었다.

거두절미하고 내가 이번 캐시 데이터 관리 기능 구현에 사용한 방식은 다음과 같다.

" AWS CloudFront + S3 연동방식 "

사실 내가 캐시 성으로 관리하고자 했던 건 정규화되어있거나 규격이 있는 ‘데이터'의 형식보다

‘파일'의 형식이었고 현재 재직 중인 회사가 AWS를 사용하고 있기 때문에 위의 방식을 사용하게 되었다.

이번 포스팅에서는 위의 서비스들의 정의와 연동방법을 정리해보고

실제로 어떻게 사용했는지는 업무 완료 후 정리하여 포스팅해보도록 하겠다!

S3?

Simple Storage Service의 줄임말로 인터넷용 스토리지 서비스이다.

언제나 어디서나 원하는 양의 데이터를 저장하고 검색할 수 있다.

단독 스토리지로도 사용 가능하며 EC2, EBS와 같은 다른 AWS 서비스와도 함께 사용할 수 있다.

나 같은 경우는 CloudFront와 활용하여 캐싱 서비스를 할 예정이다.

기본개념

객체 (Object)
1. 데이터가 저장되는 기본 단위로써 파일과 메타데이터로 이루어져 있다.
2. 크기는 1Byte ~ 5TB까지 가능하다.
버킷 (Bucket)
- 최상위 디렉터리 개념으로 한 리전에서 유일해야 한다.
- 각 버킷에 저장할 수 있는 객체수와 용량은 무제한이다.
표준 스토리지
- 99.9999999%의 내구성을 보장하며 99.99%의 가용성을 제공한다.
RRS (Reduces Redundancy Storage)
- 표준 스토리지보다 저렴한 비용으로 데이터를 저장할 수 있다.

CloudFront?

정적 및 동적 웹 콘텐츠를 사용자에게 더 빨리 배포하도록 지원하는 웹 서비스이다.

Origin Server
- 실제 데이터를 보관하고 있는 서버로 Amazon S3 버킷 또는 HTTP 서버를 사용할 수 있다.
Edge Server (= Edge Location)
- CloudFront를 지칭하며 오리진 서버에 저장된 데이터를 캐싱한다.

클라이언트가 데이터를 요청하면 가장 가까운 (지연 시간이 가장 낮은) 엣지 로테이션으로 라우팅 된다.

우리는 오리진 서버로 Amazon S3 Bucket을 사용한다.

CloudFront는 오리진 서버로부터 파일을 가져와 모든 CloudFront 엣지 로케이션에 배포한다.

클라이언트가 CloudFront에게 파일을 요청한다.
캐싱 여부 확인한다.
1. 캐싱 : 캐싱 데이터 응답한다.
2. 미 캐싱 : 오리진 서버에 요청 포워딩 후 캐싱 데이터 생성하여 응답한다.

사용 사례 중 ‘정적 웹 사이트 콘텐츠 전송 속도 향상’을 근거로 사용한다.

정적 콘텐츠를 저장하고 전송하기 위한 간단한 방법은 Amazon S3 버킷을 사용하는 것이다.
S3와 CloudFront를 함께 사용하면 OAI(원본 액세스 ID)를 통해 S3 콘텐츠에 대한 액세스를 쉽게 제한할 수 있으며 이외에도 다양한 장점이 있다.

이제 이 두 가지 서비스를 연동하여 S3 스토리지의 파일을 CloudFront에 캐시 처리하는 방법을 알아보자!

S3 버킷 생성

AWS Console에서 S3 서비스에 접속한다.
버킷 만들기 버튼을 클릭하여 만들기 화면으로 전환한다.
- 일반 구성
  - 버킷 이름
    - 버킷 이름에 버킷의 DNS 호환 이름을 입력한다.
    - 버킷 이름은 다음과 같아야 한다.
      1. 모든 Amazon S3에서 고유해야 한다.
      2. 3~63자 이내여야 한다.
      3. 대문자가 없어야 한다.
      4. 소문자 또는 숫자로 시작해야 한다.
    - 버킷을 생성한 후에는 해당 이름을 변경할 수 없다.
  - AWS 리전 : 서비스 리전 선택한다.
  - 기존 버킷에서 설정 복사 : 기존 버킷에 설정을 동일하게 사용한다.
- 객체 소유권 : 외부에서 데이터에 접근할 수 있는지에 대한 여부를 설정한다.
- 이 버킷의 퍼블릭 액세스 차단 설정
  - 기본적으로 객체 소유권을 비활성화하면 모든 퍼블릭 액세스가 차단된다.
- 버킷 버전 관리
- 태그
- 기본 암호화

CloudFront 연동

AWS Console에서 CloudFront 서비스에 접속한다.
배포를 생성한다.
배포 방식을 선택한다.
- Web
  - HTTP(S)를 통해 동적, 정적 파일( .html, .css, .php 등)을 제공하는 방식이다.
- RTMP (Real Time Messaging Protocol)
  - Adobe Flash 멀티미디어는 HTTP 또는 HTTPS를 통해 제공할 수 없지만, CloudFront RTMP 배포를 사용하여 제공하는 방식이다.
  - 현재 VOD 같은 영상 제작물들은 이 방식으로 사용하는 중?
배포 설정을 한다.
- https://docs.aws.amazon.com/ko_kr/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html (설정 값이 굉장히 많기 때문에 문서를 꼭 참고하자!)
- Origin
  - Origin Domain Name
    - S3 사용하게 되면 input box에 사용 가능한 목록들이 뜨기 때문에 선택하면 된다.
  - Origin ID
    - 오리진 또는 오리진 그룹을 고유하게 구별하는 문자열이다.
    - Origin Domain Name을 목록으로 선택했다면 자동으로 생성된다.
  - Restrict Bucket Access (Origin이 S3 버킷일 때만 노출)
    
    Access S3 URL Access CloudFront URL
    
    YES (권장) X O
    
    NO O O
    - YES 일 때 추가 항목
      - Origin Access Identity
      - Comment
      - Grant Read Permissions On Bucket
        
        CloudFront에서 S3에 접근하기 위해 버킷의 read 권한을 부여하기 위해 설정한다.
        
        Yes, Update Bucket Policy : S3 버킷에 대한 읽기 권한 자동 부여
        
        No, I will Update Permissions : 버킷 권한을 업데이트하는 대신 권한을 수동으로 업데이트하려는 경우
      - Origin Custom Headers
- Cache
  - Path Pattern : CloudFront로 파일을 가져올 규칙으로 기본값은 *(모든 파일)이고, 배포 후 추가 가능하다.
  - Viewer Protocol Policy : Client가 CloudFront 콘텐츠를 액세스 할 때의 프로토콜을 설정한다.
  - Allowed HTTP Methods : Origin 처리를 하기 위해 허용할 HTTP 메서드를 지정한다.
  - Field-level Encryption Config : 중요한 보안 데이터를 강화하기 위해 필드 레벨로 암호화를 적용한다.
  - Cached HTTP Methods
    - OPTIONS 메서드 요청 시 Origin의 응답 데이터 캐싱 여부를 설정한다.
    - GET, HEAD 요청은 기본적으로 항상 캐싱한다.
  - Cache Based on Selected Request Headers : CloudFront에서 지정된 헤더의 값을 기반으로 객체를 캐싱할지 여부를 지정한다.
    - None (improves caching) 없음(캐싱 향상)
      - CloudFront가 헤더 값을 기반으로 객체를 캐시 하지 않는다.
    - Whitelist(화이트리스트)
      - CloudFront가 지정된 헤더의 값(Whitelist)만을 기반으로 객체를 캐시 한다.
      - 즉, Whitelist Headers(화이트리스트 헤더)를 사용하여 CloudFront에서 캐시의 기준으로 설정할 헤더를 선택한다.
    - 모두
      - CloudFront가 이 캐시 동작과 연결된 객체를 캐싱하지 않는다.
      - 그 대신 CloudFront가 모든 요청을 Origin에 전송한다. (Amazon S3 Origin에는 권장하지 않음)
  - Object Caching
    - Origin 서버에서 객체에 Cache-Control 헤더를 추가하여 파일의 캐시 유지 시간을 설정합니다.
    - 유지 시간이 지나면 CloudFront에서 파일이 삭제됩니다
    - Use Origin Cache Headers를 선택하면 Default TTL이 적용되며, 1일(86400초)이 기본값입니다.
    - Customize를 선택하면 Minimum TTL, Maximum TTL를 작성해줘야 합니다.
  - Forward Cookies
  - Query String Forwarding and Caching
  - Smooth Streaming
  - Restrict Viewer Access
  - Compress Object Automatically
  - Lambda Function Associations
- Distribution
  - Price Class
  - AWS WAF Web ACL
  - Alternate Domain Names
  - SSL Certificate
  - Supported HTTP Versions
  - Default Root Object
  - Logging
  - Enable IPv6
  - Comment
  - Distribution State

위와 같이 S3 버킷을 적절하게 생성하고, CloudFront에 생성한 S3 버킷을 연동한 후, S3 일정 디렉터리에

캐시 처리를 하고자 하는 파일을 업로드하면 CloudFront 도메인 + 저장된 디렉터리 경로로 접근하면 해당 파일을 볼 수 있다!

캐시의 특징처럼 최초 조회 시에는 CloudFront가 S3에서 데이터를 조회하여 보여주고

그 후 동일 조회 요청에서는 CloudFront의 캐시 처리가 된 데이터를 보여준다.

다만 캐시 특성상 위에서 등록해준 데이터 TTL이 지나지 않으면 원본 데이터가 변경되었다 하더라도
CloudFront에서는 데이터 변경의 여부를 알 방법이 없다!

다음 포스팅에서는 이러한 캐시 무효화의 방식들의 소개와 실제로 어떻게 반영하여 개발하였는지를 포스팅하겠다!

(언제 할 수 있을까...)

첫 회고 (취업 준비부터 첫 회사 퇴사까지)

개발자 김은혜 — Wed, 17 Aug 2022 15:56:59 +0900

첫 이직을 한지 한 달이 다 되어간다.

이직한 회사 적응도 하고 최근 운동에 흥미가 생겨서 운동도 하고 못 만났던 친구들도 만나다보니,
써야지 써야지 마음만 먹고 미루고 있었던 첫 회사 회고를 이제야 쓰게 되었다.

대학시절

입사 전 학창 시절부터 돌이켜 본다면 나는 유사 전공자이다. (정보통신공학과 재학)
고등학생 시절 공부에 흥미가 없어서 공부를 잘하지 않았고
수능점수 맞춰서 간 학과다 보니 대학시절도 딱히 공부를 열심히 하지 않았다.

친구들이랑 노는 게 좋았고 학교 가는 게 싫어서 한 학기는 학사경고도 받을 정도로 공부를 안 했다.

그래도 먹고 살길은 찾아봐야 하지 않겠나 싶어서 1학년을 마치고 대뜸 휴학을 했고
돈 벌어보겠다며 이런저런 알바를 했고 나름 공부도 해보겠다고 뜬금없이 세무,회계 책을 왕창 사다가
하루이틀 공부해 보다가 결국엔 이도 아닌 거 같아 수능 준비를 하게 되었다.

하지만 모든 것은 뜻대로 잘 되지 않았고 (끈기 있게 한 게 없으니 당연하다.)
다시 재학 중이던 대학교에 복학하게 되었다.
이 때문에 부모님도 이런 나를 보면서 정말 걱정이 많으셨다.
학창 시절에는 사춘기도 없이 자라던 내가 다 커서 놀러만 다니니 걱정이 많으실 법했다.

취업준비

3,4학년이 되니 동기들은 한명 두명씩 자격증을 따고, 본인이 원하는 학과로 전과를 하거나
인턴으로 취업을 하면서 본인들의 미래를 설계해 나가고 있었다.
분명 같이 놀았던거 같은데 나만 뒤쳐지고 친구들은 점점 앞서나가는거 같았다.

이대론 안 되겠다 싶어서 여기저기 수소문하였고 국비지원이라는 교육 프로그램을 알게 되었다.
교육비도 무료고 학기 중에도 취업계를 내고 다닐 수 있다 하여 옳다쿠나 하며 상담을 받았고
무엇을 하는 곳인지, 무엇을 배우는 곳인지도 모른채 무지성으로 다니기 시작하였다.
지금처럼 개발자 붐이 일어난 시기도 아니었고, 국비지원이 유명하지 않았기 때문이다.

Java 웹 개발자 양성 프로그램이었는데,
나는 여태 그랬왔던 것처럼 열정이나 포부, 간절함도 없이 그냥 학원을 다니기 시작했다.
하지만 정말 운 좋게도 열정 넘치는 강사님과 학원 여러 동기들을 만났고,
(이 시절 에피소드는 다 쓰자니 너무 길어질 것 같아서 생략하겠다. 다음에 한번 포스팅을 써봐야지)
매일같이 수업 듣고 공부하고 복습하고 스터디하고를 반복하였다.

나는 점점 개발에 흥미가 생겼고, 나도 몰랐던 약간의 재능(?)을 발견하면서 하루하루 빠르게 성장했다.
강사님과 많은 동기들의 칭찬과 기대를 받았고, 이런 관심을 처음 받아본 나는
그런 기대에 부흥하고자 더더욱 열심히 했던 거 같다.

7개월 과정중에 두달정도는 안양-강남을 통학하며 지냈지만, 그 시간조차 아까웠던
나는 학원 근처에 창문하나 없는 작은 고시텔을 구했고
남은 다섯달 동안 오전에 수업을 듣고, 오후에는 스터디와 복습을 하고 새벽까지 프로젝트를 했다.

나는 결국 모든 프로젝트에서 1등을 하게 되었고, 모범상도 타며 수료를 하게 되었다.

수료하고 나서도 계속 공부하며 친한 동기들과 취업전선에 달려들었고,
이렇게 나는 수료한 지 한 달 차쯤에 첫 번째 회사에 입사하게 되었다.

첫 직장

첫 회사는 나름 크고 이름 알려진 중소기업이었고 나는 새로운 프로젝트로 꾸려진 팀에 소속되었다.

이 회사를 다니면서 정말 희노애락의 감정을 다양하게 느꼈고,
성격도 많이 바뀐 거 같다. ~~(물론 안 좋게^^)~~
그리고 일적으로도 일 외적으로도 좋은 사람들과 좋은 경험도 정말 많이 했다.
첫 취업, 첫 직장, 첫 업무, 첫 회의, 첫 야근...
모든 게 처음이다 보니 모든 경험이 지금 생각해보면 소중하고 특별한 기억이 될 것 같다.

점심시간이 다 끝나지도 않았지만 커피를 4잔씩 마시기도 하고

야근에 철야에 귀에 이명이 들릴 정도로 무리하면서 일했던 기간도 있었다.
이 시즌에는 번아웃이 정말 제대로 와서 힘들었던 거 같다.

아침에 일 하기 위해서 눈뜨는게 힘들었고, 재택 근무 시절에는 울뻔 한적도 여럿 있었다.
지금 생각해보면 뭐가 그렇게 힘들었을까 싶을만큼 무뎌졌지만
그만큼 열정적으로 일했고 최선을 다했기 때문에 힘들었지 않았나 싶다.

하지만 그런 와중에도 ‘개발이 재밌다'라는 생각을 하지 않았던 적이 없다.
사람 때문에 힘들고 야근과 철야, 답이 없는 긴 회의에 아무리 지쳐도
개발을 하고 더 나은 성능을 위해 이야기를 나누는 순간은 항상 즐거웠다.

무뎌진건지 적응을 한건지는 모르겠지만 힘들다는 감정의 소비가 점차 줄게 되었고
그냥 그렇게 꾸준히 열심히 하다 보니 주위 사람들의 칭찬과 인정을 받게 되었고
또 그런 상황을 영양분으로 삼아 더더욱 성장하게 되었다.
이런 힘든 나날들을 보낸 전우애(?) 넘치는 팀원들이 있어서 더더욱 열심히 할 수 있었다.

회사 다니는 기간 동안 감사 할만큼에 관심과 생일 축하도 받고

특히 정말 열심히 했던 2021년을 보낸 후에,
2022년에는 핵심 인재로 인정받아 연봉도 많이 오르고 우수 사원상도 받았다!

이직

하지만 사람이란 게 편해지며 현 상황에 적응을 하다 보니 안일해지고 나태해지게 되었다.
그래서 나는 다시 초심을 찾고자 하는 마음으로 2022년 초부터 이직을 준비하게 되었고
수많은 면접을 보면서 신입과 경력직 면접은 정말 다르구나를 느끼며
내가 3년간 겪었던 경험들을 부정하게 되며 현타도 오고 멘탈도 많이 나갔었다.

하지만 ‘멘탈은 하루만 놓자'라는 생각을 가지고
멘탈을 놓을 때는 시원하게 정말 놔버리고 그다음 날엔 다시 정신줄 챙겨서 회사일도 하고 이직 준비도 열심히 했다.

결국 나는 이직에 성공하였고 많은 이들의 인사를 받으면서 첫 회사를 나올 수 있게 되었다.
이렇게 2년 9개월간의 첫 회사가 마무리 되었고, 다음 걸음을 걸어가고 있다!

첫 회사를 너무 즐겁게 다닌 나머지 이직을 한 지금 적응을 하기가 조금 힘들지만,
새로운 환경 새로운 사람 모든 새로운 것에 난 또 나아가고 있다!

	Access S3 URL	Access CloudFront URL
YES (권장)	X	O
NO	O	O