아둥바둥 개발일기

[Spring] @Transactional(readOnly=true) 설정시 성능 향상

JoyyKim — Thu, 13 Jan 2022 11:06:50 +0900

1. JPA, 하이버네이트

엔티티가 영속성 컨텍스트에 관리되면 1차 캐시부터 변경 감지까지 얻을 수 있는 혜택이 많다.
하지만 영속성 컨텍스트는 변경 감지를 위해서 스냅샷 인스턴스를 보관하므로 더 많은 메모리를 사용하는 단점이 존재한다.

flush 호출하지 않음
dirty checking(변경 감지)하지 않음

readOnly=true 옵션을 주면 스프링 프레임워크가 하이버네이트 세션 플러시 모드를 MANUAL로 설정한다.
이렇게 하면 강제로 플러시를 호출하지 않는 한 플러시가 일어나지 않는다.
따라서 트랜잭션을 커밋하더라도 영속성 컨텍스트가 플러시 되지 않아서 엔티티의 등록, 수정, 삭제가 동작하지 않는다.

flush 할 때 일어나는 스냅샷 비교와 같은 무거운 로직을 수행하지 않으므로 성능이 향상된다.

참고

https://cheese10yun.github.io/jpa-flush/

1-1. 스프링 5.1 이후 사용시 - 읽기 전용 쿼리 힌트 자동적용

@Transaction(readOnly=true)로 설정 시, 하이버네이트 전용 힌트인 org.hibernate.readOnly(읽기 전용 쿼리 힌트)가 자동으로 true로 동작한다.
org.hibernate.readOnly를 사용하면 영속성 컨텍스트가 스냅샷을 저장하지 않아서 메모리 사용량을 최적화 할 수 있다.
스냅샷만 저장하지 않는 것이지, 1차 캐시에는 그대로 저장한다. 똑같은 식별자로 2번 조회했을 경우 반환되는 엔티티의 주소가 같다.

참고

2. MySQL - InnoDB Read-Only Transactions

readOnly 트랜잭션은 transaction ID(TRX_ID field)를 세팅하는 오버헤드를 줄일 수 있다.
transaction ID는 쓰기 작업이나 SELECT ... FOR UPDATE 같은 lock을 거는 읽기 작업에서 필요한데, readOnly 트랜잭션에선 필요하지 않다.

InnoDB can avoid the overhead associated with setting up the transaction ID (TRX_ID field) for transactions that are known to be read-only. A transaction ID is only needed for a transaction that might perform write operations or locking reads such as SELECT ... FOR UPDATE. Eliminating unnecessary transaction IDs reduces the size of internal data structures that are consulted each time a query or data change statement constructs a read view.

참고

https://dev.mysql.com/doc/refman/5.7/en/innodb-performance-ro-txn.html

[Spring] 선언적 트랜잭션(@Transactional)의 AOP 프록시 매커니즘

JoyyKim — Thu, 13 Jan 2022 10:21:18 +0900

스프링에서 @Transactional은 AOP로 구현한다.
스프링의 프록시 매커니즘에는 두 가지 - JDK Dynamic Proxy, CGLIB Proxy 가 있다.
스프링부트에서는 CGLIB Proxy가 default로 사용된다.

JDK Dynamic Proxy

인터페이스에 대한 Proxy만을 지원, 클래스에 대한 Proxy를 지원할 수 없다.
Target 클래스에 Proxy를 적용할 때 PointCut을 통해 Advice되는 메서드를 지정한다. JDK Proxy를 사용하면 Target 클래스에 대한 모든 메서드 호출(PointCut으로 지정하지 않은 메서드도)이 일단 JVM에 Intercept된다(이 때 reflection이 사용된다). 그 후에 메서드의 Advice 적용 여부를 판단하게 된다.
- 이는 JDK Dynamic Proxy의 실행속도를 저하시키는 원인이 된다.

CGLIB Proxy

CGLIB Proxy는 클래스에 대한 Proxy가 가능하다.
CGLIB Proxy도 JDK Proxy처럼 Runtime시에 Target 메서드가 호출될 때 해당 메서드의 Advice 적용 여부를 결정하게 된다. 그러나 CGLIB는 메서드가 처음 호출 되었을때 동적으로 bytecode를 생성하고 이후 호출에서는 재사용하여 두번째 호출 이후부터는 실행속도가 향상된다.

Spring Boot에서 기본으로 CGLIB를 선택한 이유

예전에는 CGLIB에 3가지의 한계점이 있었고, 때문에 권장되지 않았다.

net.sf.cglib.proxy.Enhancer 의존성 추가
타깃 클래스에 파라미터가 없는 디폴트 생성자 필요
생성된 Proxy의 메소드를 호출하게 되면 타깃의 생성자가 두 번 호출됨.

하지만 Spring boot 1.4(Spring 4.3) 부터는 @Transactional은 기본적으로 CGLIB Proxy로 동작한다. Spring boot 1.4 release note

Spring Core 패키지에 포함됨 - net.sf.cglib.proxy.Enhancer -> org.springframework.cglib.proxy
objenesis 라이브러리를 사용
1. 디폴트 생성자가 필요없어짐
2. 생성자가 두 번 호출되던 문제 해결

기존에 CGLIB가 가지고 있던 한계점들이 개선되었기 때문에 JDK Dynamic Proxy보다 성능이 좋은 CGLIB Proxy를 @Transactional의 기본 프록시 매커니즘으로 선택하게 된 것이다.

참고

내가 꿈꾸는 프로그래머로서의 삶

JoyyKim — Wed, 27 Oct 2021 11:23:14 +0900

우아한테크코스의 마지막 글쓰기 미션으로 "내가 꿈꾸는 프로그래머로서의 삶"을 주제로 쓴 글입니다.

열린 마음을 가진

우아한테크코스는 피드백을 매우 강조합니다. 레벨1, 2에서는 미션을 통해 리뷰어에게 피드백을 받고 점진적으로, 반복적으로 미션을 개선해 나갔어요. 레벨4에서는 크루끼리 서로 리뷰어의 역할을 하면서 피드백을 주고 받았죠. 미션뿐 아니라 다양한 곳에서 우리는 피드백을 주고 받았어요. 피드백이 자연스러운 이런 환경에서 공부를 하다보니 제 커뮤니케이션 태도가 많이 바뀐걸 알게 되었어요. 이 곳에 오기 전에는 누군가와 토론을 할 때, 아니면 대화를 할 때 항상 방어적이었어요. 상대를 이기려하고, 내 의견이 옳다는걸 증명하려고 했죠. 그것만이 유일한 토론의 방법인줄 알았죠.

하지만 이 곳에서 코치, 리뷰어, 크루들에게 받은 피드백은 저를 변하게 했어요. 그들의 피드백에는 나에게 진심으로 도움이 되고 싶어하는 진실한 마음과 배려가 느껴졌어요. 덕분에 저도 마음을 열고 제가 모르는 것, 부족한 것들을 솔직하게 내보이게 되었죠. 마음을 열고 서로를 이해하면 대립하거나 공격적이지 않아도 훨씬 더 깊은 토론과 성장이 가능하다는 것도 알게 되었죠. 우테코에서 함께 자라기의 가치도 깨닫게 되었는데요, 동료와 함께 동반성장을 하는 것도 마음을 열지 않고는 불가능하답니다.

삭막한 컴퓨터와 숫자, 코드만 가득할 줄 알았던 프로그래밍의 세계에 이런 인간적인 모습이 가장 중요하다는게 모순이면서 정말 멋지다고 생각해요. 전 이 곳에서 열린 마음으로 진실하고 배려심 있는 커뮤니케이션을 통해 가치를 만드는 프로그래머가 되고 싶은 꿈이 있습니다.

행복한 개발자

제가 좋아하는 "AI가 세상을 지배한다면" 이라는 웹툰에는 유명한 피아니스트와 연주 AI가 대결을 하는 에피소드가 나와요. 자신의 연주를 완벽하게 카피해서 연주하는 AI에게 피아니스트는 절망하죠. 또한 아무도 AI가 카피한 연주와 자신의 연주를 구분하지 못하였고 피아니스트는 비참함에 음악을 포기하려합니다. 하지만 유일하게 자신의 연주를 알아봐준 형 덕분에 피아니스트는 다시 연주를 할 힘을 얻게 돼요.

저는 저 에피소드를 가장 좋아하는데, 아마 저 피아니스트가 저와 닮았다고 느꼈기 때문일거에요. 저는 우아한테크코스에서 슬럼프를 경험한 적이 있어요. 개발이 손에 안잡히고 공부도 의미없게 느껴졌죠. 제게 할 일이 주어지는게 무서웠어요. 이걸 제대로 해낼 수 있을 것 같지가 않았거든요. 제가 왜 그런 상태가 되었는지 생각을 해봤고 이유를 찾았죠. 스스로를 다른 사람들과 비교하고 급을 나눴기 때문이었어요. 저희 팀원들, 다른 팀, 다른 크루들과 끊임없이 비교하면서 스스로를 깎아내렸습니다. 개발공부를 시작했을 때부터 지금까지 제 원동력의 많은 부분은 열등감과 불안함이었어요. 우테코에 온 후로 많이 덜해지긴 했지만 아직 저는 제가 못미덥고 한심하게 느껴질 때가 많답니다.

이유를 파악하니 슬럼프는 쉽게 벗어날 수 있었어요. 남들과 비교하는 제 모습이 불행해보였거든요. 그 순간 10년 후에도 계속 비교하다가 불행해져 개발을 그만두게 된 제 모습이 강한 이미지가 되어 머리속에 남았어요. 그 후 저는 더 이상 남들고 비교하지 않고 있어요. 비교를 하려다가도 그 이미지가 다시 떠올라 그만두게 되더라고요 (충격요법?).

불행한 개발자는 됐으니 이제는 제가 생각하는 행복한 개발자의 이미지를 머릿속에 박아넣어야겠네요. 일단 불행한 개발자의 모습과 반대되는걸 생각해볼까요?

나의 삶을 사랑하고 지금 이 순간에 충실하고 집중한다.
내 부족함을 인정하되 미워하지 않는다.

이제는 나의 부족함을 미워하고, 채찍질하는건 그만하고 싶어요. 나에게 집중하고 부족함을 받아들이고 마음속의 이야기에 귀기울이려고 해요.

앞서 말했던 에피소드의 마지막 장면엔 고통에서 벗어난 피아니스트가 AI에게 이런 대사를 합니다.

네가 쇼팽이든, 음악의 신이든 이젠 관심없어.

나는 내 삶을 연주할 뿐.

멋있지 않나요? 저도 언젠간 고통에서 벗어나 편안함에 이르러 제 삶을 온전히 사랑하는 행복한 개발자가 되고싶습니다.

Jackson 라이브러리 ObjectMapper 재사용해도 될까?

JoyyKim — Fri, 24 Sep 2021 19:40:38 +0900

Jackson은 java의 json 프로세싱 라이브러리로 유명하다.
Jackson에는 ObjectMapper 클래스가 있는데 POJO(Plain Old Java Object)를 JSON으로 변환하거나, 반대로 JSON을 POJO로 변환한다.

우아한테크코스에서 간단한 MVC프레임워크를 구현하는 미션을 진행하던중 ObjectMapper를 사용하게 되었다.
나는 ObjectMapper를 싱글턴 객체로 만들어 재사용해도 될지 고민이 생겼다. 내가 만드는 프레임워크는 멀티 쓰레드로 동작하기 때문에 Thread-safe한지가 중요했다.

ObjectMapper는 Thread-safe 한가?

일단 ObjectMapper 인스턴스는 불변 객체가 아니다. 공식문서에 따르면 ObjectMapper는 ObjectReader, ObjectWriter 를 생성하는 팩토리처럼 동작한다고 한다. Mapper 필드에는 read, write 기능을 위한 여러가지 Configuration 객체들을 필드로 가지고 있는데, 대부분이 final이 아니며 setConfig(), setDateFormat() 등의 메서드들을 통해 설정을 바꿀 수 있다.

ObjectMapper also acts as a factory for more advanced ObjectReader and ObjectWriter classes.

Jackson 공식문서에서는 Mapper 객체는 configuring 메서드(setConfig, setDateFormat 등)가 실행중이 아닐 때만 read, write 요청이 Thread-safe 하다고 한다.

Mapper instances are fully thread-safe provided that ALL configuration of the instance occurs before ANY read or write calls.

ObjectMapper itself is only thread-safe when configuring methods (such as this one) are NOT called.

ObjectReader, ObjectWriter

ObjectMapper는 ObjectReader, ObjectWriter 객체를 생성할 수 있는데, 이 두 클래스의 인스턴스는 외부에서 동기화작업을 해주지 않아도 되는 Thread-safe한 불변 객체다.
ObjectMapper의 Configuration에 따라 writer(), reader() 메서드로 두 객체를 만들 수 있다.
ObjectMapper에서 Reader,Writer를 생성하는 작업은 값싼 연산이기 때문에 만약 Reader,Writer 객체를 재사용하고 싶지도 않고 메모리를 차지하는게 싫다면, Mapper만 가지고 있고 필요할 때만 Mapper에서 생성해도 괜찮다고 한다.

기능적으로도 Mapper와 Reader,Writer는 차이가 있다.
ObjectReader.readValues(InputStream), ObjectWriter.writeValues(OutputStream) 는 훨씬 긴 시퀀스의 입출력을 처리할 수 있는데, Mapper에는 이 메서드가 없다.

Note that although most read and write methods are exposed through this class, some of the functionality is only exposed via ObjectReader and ObjectWriter: specifically, reading/writing of longer sequences of values is only available through ObjectReader.readValues(InputStream) and ObjectWriter.writeValues(OutputStream).

ObjectMapper는 Multi-Thread 성능 이슈

검색 중 ObjectMapper를 멀티 쓰레드에서 사용하지 마라는 근거 중 lock으로 인한 성능저하가 있다는 글을 보았다. 그런데 누군가는 전혀 lock이 없다고 의견이 갈려서 찾아보니 예전 버전에는 lock 이슈가 있었다는걸 발견했다. 아래는 ObjectMapper 내부의 synchronized 블록으로 인한 멀티쓰레드 성능이슈를 발견하고 해결한 분이 그 과정을 작성한 글이다.
https://medium.com/feedzaitech/when-jackson-becomes-a-parallelism-bottleneck-f1440a50b429

Jackson 프로젝트 해당 이슈에선 2.8.7 버전부터 개선되었다고 한다. 확인해보니 정말 해당 버전부터 synchronized 블록이 사라졌다.

2.8.6

2.8.7

[프로그래머스 Level2] 전화번호 목록 - Python

JoyyKim — Tue, 19 Jan 2021 11:38:34 +0900

def solution(phone_book):
    phone_book_set = set(phone_book)

    for phone_number in phone_book:
        for i in range(1, len(phone_number)+1):
            prefix = phone_number[:i]

            if prefix in phone_book_set and prefix != phone_number:
                return False

    return True

[프로그래머스 2020 KAKAO BLIND RECRUITMENT] 문자열 압축 - Python

JoyyKim — Sun, 17 Jan 2021 17:50:38 +0900

def solution(s):
    answer = len(s)

    for unit in range(1, len(s)):
        result = ''
        count = 1

        for i in range(0, len(s), unit):
            pivot = s[i: i + unit]
            next_pivot = s[i + unit:i + unit + unit]

            if pivot == next_pivot:
                count += 1
                continue

            if 1 < count:
                result += str(count)

            result += pivot
            count = 1

        if len(result) < answer:
            answer = len(result)

    return answer

2021년 1월 근황

JoyyKim — Tue, 12 Jan 2021 22:44:54 +0900

우아한테크코스에 합격하고 과정이 시작하기까지 한달이란 시간이 남았다. 2월 2일에 시작하니 1월 한달은 온전히 자유시간이다.

우테코를 준비하며 한달 동안 달성할 TODO 리스트를 적어보았다. 항상 시작만 하고 마무리를 못 짓는 이 놈의 TODO... 2021년 첫 계획이기도 하니 이번엔 잘 지키고 싶다.

TO DO

CS 공부 - 자료구조/운영체제/데이터베이스/웹
스프링 책 실습 (스프링 부트와 AWS로 혼자 구현하는 웹 서비스)
독서 3권 - 가볍게 끝까지 1회 독 (클린 코드, 객체지향의 사실과 오해, 이펙티브 자바3)
타자 연습
시간표 정해놓고 루틴 만들어서 규칙적인 생활하기
일주일 중 하루는 꼭 쉬기 - 노트북 X, 책은 허용

CS 공부

아무래도 비전공자이고 그 동안 CS를 제대로 배우진 못해서 항상 이 부분이 나의 약점이라고 생각했다. 패스트캠퍼스에서 CS수업이 있었지만 짧게 2주만에 끝났기 때문에 충분히 많은 내용이 커리큘럼에 담겨 있지 않아 아쉬웠다. CS 지식 중 자료구조/운영체제/데이터베이스/웹 이렇게 4가지를 골랐다. 컴퓨터를 더 이해하는데 도움이 될 자료구조/운영체제와 웹 백엔드 공부, 실무에 더 잘 적용시킬 수 있는 데이터베이스/웹을 공부하는 것이 도움이 될거라 생각했다.

기초가 튼튼해야 높은 탑을 쌓을 수 있으니까!!

스프링 책 실습

내 롤모델 이동욱님의 저서 <스프링 부트와 AWS로 혼자 구현하는 웹 서비스>를 가지고 실습하는 것이 목표다. 스프링의 개념이란~~ 하면서 나오는 IoC, DI, AOP 얘기는 그만 듣고 얼른 만들어 보고 싶었다. 이미 Django를 써보기도 했고 직접 사용해 본 후에 자세한 개념을 배우면 더 잘 이해할 수 있을거라 생각했다. 많은 책 중 이 책을 고른 건 몇 가지 이유가 있다.

단순히 프레임 워크 사용법 뿐 아니라 현업 Best Practice에 대한 가이드도 제시해줘서
테스트, AWS를 통한 배포, 특히 배포 자동화, 무중단 배포까지 경험할 수 있어서
개념 얘기는 거의 안하고 바로 실습으로 들어가서!
저자가 이동욱 님이라서 - 신뢰도 100%. 마이 롤모델.

우테코에서도 스프링 부트로 교육을 하기 때문에 도구를 익히는데 아까운 시간 낭비하기 싫어서 미리 어느정도 배워놓고 가려고 한다!

개발 관련 독서 3권

클린 코드, 객체지향의 사실과 오해, 이펙티브 자바3

독서 3권...조금 빡센 목표 같아서 일단 가볍게라도 끝까지 읽자! 라는 마음으로 시작했다. 근데 잘 안 읽힌다. 너무 어려운 책들을 고른 걸까... 클린 코드와 이펙티브 자바3는 쪽 수도 500이나 된다. 현재 진행도를 보니 이펙티브 자바3는 빼야할 듯 하다. 나중에 틈틈히 보지 뭐.

나머지~

타자연습

나는 몇 달 전 까지만 해도 독수리 타법이었다. 화면보고 타자보고 낑낑대며 코딩하는 모습을 답답하게 본 친구가 한컴 타자 연습을 해보라길래 해봤는데 한 150타...? 그 정도가 나왔다. 그래서 그 이후로 연습을 좀 해서 나아졌고 이번에 쉬는 동안 다시 빡세게 해보려고 한다. 근데 아직 한번도 안했다ㅎㅎ 날 잡아서 해야지...

규칙적인 생활하기

학원을 안가서 규칙적인 생활이 깨졌다. 워낙 잠이 많아서 그런지 늦게 일어나는 날이 많아졌다. 보통 9시~10시에 일어나는 것 같다. 우테코 시작하면 일찍일찍 다녀야 하고 집도 머니 다시 생활리듬을 바꾸려고 한다. 목표는 12시 취침, 7시30분 기상.

일주일 중 하루 쉬기

내 평소 생활 패턴을 아는 친구의 조언을 반영했다. 일주일 내내 개발 생각만 하지 말고 쉴 땐 쉬라고. 그게 맞다고 머리론 아는데 실천이 잘 안된다. 그래서 쉬는 날엔 개발 관련 책은 허용하는 조건으로 휴가를 정했다ㅎㅎ

[우아한테크코스] 웹 백엔드 3기 최종 합격

JoyyKim — Wed, 6 Jan 2021 02:20:46 +0900

우아한테크코스에 최종 합격했다.

원래 이 글은 최종 코테 후 합격 여부 메일을 기다리며 프리코스를 회고하려고 했는데 크리스마스도 있었고 CS 공부도 하면서 이것저것 핑계를 대며 미뤘는데 합격 메일을 받아 버렸다... 그래서 그냥 프리코스 회고부터 합격까지 한번에 포스팅 해버려야겠다.

우아한 테크 코스란?

우아한 테크 코스는 배달의 민족을 서비스하는 우아한 형제들에서 진행하는 프로그래머 양성 교육이다. 10개월 과정이며 교육비는 없고 2020년 3기 부터는 웹 백엔드, 프론트엔드 두 가지 과정이 진행되고 있다.

우테코 소개 영상

계기

사실 이 과정에 대해서 처음 알게 된건 작년 초였다. 검색을 하다 우연히 우아한테크코스 교육생들의 발표 동영상을 보게 되었는데 열정 넘치는 발표자와 화목한 발표 분위기가 인상 깊었다. 분명 힘든 과정일텐데 발표자와 나머지 교육생들 모두 이 과정을 즐기고 몰입하고 있다는 느낌을 받아 부럽기도 하고 언젠간 저런 사람들과 함께 일하고 싶다고 생각했다. 우테코 지원은 11월에 시작하고 다니던 학원이 10월 쯤에 끝나니 시기도 잘맞아서 바로 이어서 갈 수 있으면 참 좋겠다고 생각도 했었다.

후에 학원 과정을 수료할 쯤에 앞으로의 계획을 세워보았다. 당시 나는 학원 두 군데를 각각 6개월 씩 다녀서 1년 째 개발 공부를 하고 있는 상황이었다. 그 동안 생각이 바뀌어 이 과정에 지원하기 얼마 전만 해도 빨리 취업해서 일을 하면서 배우고 돈도 모으는게 최선이라고 생각했다. 회사에서 직접 부딪히면서 내 부족함을 깨닫고 공부의 필요성을 느끼면 모은 돈으로 생활비를 해서 다시 공부를 해야겠다고 나름 플랜B도 세워놨다.

그러다 우아한테크코스 지원일이 다가오고 문득 생각을 바꿨다. 공부를 계속하면서 실력부족을 깨닫고 자존감이 낮아진 상태라 우아한테크코스에 지원해도 붙을 리 없다 생각했지만, 반대로 불합격해도 잃을 것도 없고 이런 실패도 좋은 경험이고 동기부여가 될 것 같았다.

지원

우테코에 지원하는 과정은 꽤 길다.

지원서 제출 - 1차 코딩 테스트(4시간 7문제) - 3주 프리코스(일주일에 미션 하나씩 해결) - 2차 코딩 테스트(5시간 미션 하나)

지원서는 4가지 항목에 대해 답변하면 된다. 내가 느낀 바로는 지원자의 현재 능력보다는 가능성을 중점에 둔 질문이었다.

1. 프로그래밍 학습 과정과 현재 자신이 생각하는 역량은?
2. 프로그래머가 되려는 이유는 무엇인가요?

3. 마음이 끌리는 무엇인가에 긴시간 동안 몰입해 본 경험이 있나요?

4. 우아한테크코스에 참여하려는 이유는 무엇인가요?

지원서에서는 개발에 대한 열정과 나의 내가 목표하는 바를 충분히 얘기해서 만족스러웠다. 우테코가 지향하는 바를 공감하고 이 과정에 어울리는 사람이라는 걸 어필하려고 노력했다. 제출 기간 도중에 지원서를 쓰기 시작해서 제출 전 날까지 밤을 새며 썼던 기억이 난다. 나중에는 하고 싶은 말은 많은데 1000자 제한 때문에 글을 줄이는데도 고생을 했다.

지원 당시 개발 공부를 시작한지 딱 1년 정도가 되는 시점이었는데 1년을 되돌아 보며 회고하고 앞으로의 방향에 대해 고민하는 좋은 기회였다.

1차 코딩 테스트

지원서를 제출한 사람들은 모두 참여할 수 있다. 우아한테크코스를 리딩하는 박재성님의 말에 따르면 문제는 일정 개수 이상만 맞으면 지원서를 통해 결정한다고 한다. 전 기수 지원자들의 후기를 보니 난이도는 꽤 쉽다고 해서 걱정은 안했지만 당일엔 긴장을 많이 했다.

3시간만에 6문제는 모두 풀었지만 마지막 문제에서 해매다 시간이 끝났다.

가슴 졸이며 1주 뒤 발표날만 기다리고 있었는데 합격 발표일이 3일 미뤄져서 고통의 시간이 길어졌다...

결과는 합격!!!!!

기쁜마음이 가장 컸지만 프리코스는 자바로 진행해야하고 스프링도 배우고 온 여러 지원자들에 비해 상대적으로 미숙한 실력이라는게 불안했다. 어렵게 얻은 기회를 어이없게 놓칠 순 없어 합격날부터 바로 자바 공부를 시작했다. 자바를 안쓴지 반년이 넘었지만 걱정과 달리 금방 익숙해졌다. 아마 파이썬과 장고를 배우면서 프로그래밍의 본질적인 지식도 많이 익혔기 때문인 것 같다. "역시 언어는 도구일 뿐이구나"라는 생각도 들었다. 1, 2주 만에 맨 처음 자바를 학습할 때보다 더 많이 알게 된 것 같았다.

프리코스

프리코스는 3주 간 진행되며 주 마다 미션이 하나씩 주어진다. 미션은 주어진 요구사항들을 최대한 만족하도록 구현하고 기간 안에 제출하면 된다. 특정 프레임워크를 익힌 분들이 조금 수월할 순 있겠지만 그렇지 않은 분들도 미션 완수에 어려움은 전혀 없다고 생각한다.

사실 취업을 준비하는 입장에서 3주가 길게 느껴질 수 있을 것 같다. 하지만 그만큼 프리코스 과정에서 많은 걸 얻어갈거라 기대했고 그 기대보다 더 성장했다고 생각한다.

아래는 우테코 백엔드 과정을 리드하는 박재성님이 보내주신 메일 내용의 일부다.

...
프리코스의 목적
지원할 때 참고했던 글을 통해 확인할 수 있듯이 우아한테크코스 교육과정은 강의식으로 진행하는 주입식 교육이 아닙니다.
여러분이 해결해야 할 미션을 부여하고, 미션을 구현한 후 피드백을 받는 방식으로 진행합니다.
이 교육 방식이 기존의 교육방식과 완전히 다르기 때문에 프리코스는 본 과정을 미리 경험해 보는 단계입니다.
...
이 과정을 통해 지원자는 우아한테크코스 과정을 미리 경험해 보면서 교육의 참여 여부를 결정할 수 있고, 저희는 우아한테크코스 과정을 소화하는데 어려움이 없는지 판단할 수 있는 기간이 될 수 있을 것 같아요.
서로가 같이할 수 있는지를 탐색할 수 있는 시간이라고 생각하면 됩니다.
...
우아한테크코스가 목표가 아니라 좋은 개발자로 성장하는 것을 목표로 하면서 성장해 나가는 과정으로 생각하고 도전했으면 합니다.
...

미션은 매 주 메일로 전달하고 깃허브에서 레포지토리를 포크, 요구사항을 지켜 구현하고나서 PR을 통해 제출하는 방식이다.

지금까지의 프로젝트와는 매우 달랐는데 주어진 기능 요구사항, 프로그래밍 요구사항, 과제 진행 요구사항 세 가지를 최대한 만족해야 하며 특히 기능을 구현하기 전에 기능 목록을 만들고, 기능 단위로 commit하는 방식으로 진행했다.

그 중 프로그래밍 요구사항을 지키면서 개발하면서 실력이 많이 늘었다고 생각한다. 아래는 요구사항 중 일부분이다.

자바 코드 컨벤션을 지키면서 프로그래밍한다.
indent(인덴트, 들여쓰기) depth를 3이 넘지 않도록 구현한다. 2까지만 허용한다.
함수(또는 메소드)의 길이가 15라인을 넘어가지 않도록 구현한다.
else 예약어를 쓰지 않는다.

최종 코딩 테스트

우테코 최종 합격 여부를 결정하는 코딩 테스트. 3주 간 해왔던 미션들과 같은 방식으로 진행되지만 5시간 밖에 주어지지 않아서 압박감이 컸다. 자바에 익숙하지 않다보니 코딩 속도가 큰 난관 중 하나라 예상했다. 그래서 3주차 미션 제출 후 전 기수의 코딩 테스트를 풀어보며 빠르게 구현하는 연습을 했다. 다른 지원자들의 코드를 분석하는 것도 준비하는데 큰 도움이 됐다.

원래는 오프라인으로 진행하는 최종 코딩 테스트이지만 코로나 상황때문에 어쩔 수 없이 온라인으로 Zoom을 통해 진행되었다. 우테코 과정이 진행되는 루터회관에 꼭 가보고 싶었는데 그러지 못해 아쉬웠다.

난이도는 3주 차 미션보다 비슷한? 조금 더 높아진 정도였지만 시간이 훨씬 부족해 그만큼 빡셌다...! 정신없이 5시간이 지나갔고 최종 제출을 했다. 테스트 코드는 커녕 기능을 구현하는 시간도 부족했다. 구현은 어찌저찌 한 것 같지만 README에 기능 정리도 제대로 못했고 기능 단위 커밋도 충실히 하지 못했다... 일단은 완성하고 제출까지 다 했다는 것에 의미를 두었다.

얼마 안되는 시간이지만 너무 긴장하고 집중해서 피곤한 나머지 제출하고나서 그 날은 아무것도 안하고 쉬었다.

프리코스를 마치며

이번 프리코스는 나에겐 큰 도전이었고 여기까지 온 것만으로 기대 이상으로 성취했다. 새로운 도전과제가 주어져서 그 동안 동기를 잃고 반복하던 일상에 다시 활기가 돌게 되었다. 정말 감사하게 생각한다. 부끄럽지만 난 내가 나름 잘하는 편이라고 생각을 했는데 다른 지원자들의 코드를 보며 스스로 우물 안 개구리였다는 것도 깨달았다. 역시 세상은 아는만큼 보인다. 이제라도 깨달은게 어딘가.

3주 차 미션 제출 시 함께 메일로 보냈던 프리코스 소감이다.

자바 문법에 익숙하지 않은 상태에서 프리코스를 시작하게 되어서 정말 하루하루가 진빠졌던 것 같습니다...

쉴 틈 없이 몰아친 3주 였습니다. 장고로 프로젝트도 몇 번 해봤고 지금까지 다닌 교육기관에서도 항상 우수한 편이어서 나름 자신있다고 생각했는데 터무니없는 자만심이었다는 걸 깨달았습니다. 첫 주 과제를 제외하고는 매일 8시간 이상은 붙들고 작업했습니다. 그 만큼 어려운 요구사항, 제약사항들 이었고 그 만큼 많은 성장을 한 것 같아 정말 뿌듯하게 생각합니다.

제출 후 다른 사람들의 결과물을 보며 비교되어서 불안할 때도 있었습니다. 3주차에서는 처음 접하는 레이어의 개념을 적용하려 버벅이고 있을 동안 다른 분들은 이미 제출을 한걸 보고 큰 실력 차를 느꼈습니다. "역시 스프링을 배우고 왔어야 했나"라는 생각도 들고 지원자들 중에서 제 작업물이 가장 완성도가 떨어지는 것처럼 느껴졌습니다. 하지만 가장 못한다는건 "그 만큼 배울게 많다는 것이기도 하다"라고 생각하니 더 간절하게 우아한테크코스에 가고싶어졌습니다.

프리코스에서의 극단적인 연습을 통해 제 부족함을 느끼고 더 성장하고 싶다는 욕심이 커졌습니다. 3주 동안 처음 코딩을 배울 때 처럼 열정적인 제 모습을 다시 보게 된 것 같아 즐거웠습니다. 프리코스 과정을 통해 배운 것들이 앞으로도 성장하고 커리어를 이어나가는데 큰 도움이 될거라고 생각하고 너무나 뜻 깊고 소중한 시간이었습니다.

하루하루 성장하고 있는 자신을 보면서 더 성장해갈 제 모습과 앞으로 배울 것들이 기대되는 3주 였습니다. 이런 좋은 기회를 주셔서 정말 감사합니다!!

분명 지난 3주 간 어떻게 학습했으며, 얼마나 성장했는지에 대해 구체적으로 작성해달라고 했는데 지금 보니 쓰라는 건 안쓰고 내가 하고 싶은 말만 구구절절 했네...창피하다...

최종 합격

꿈 아니지...?

아직도 이 날을 생각하면 온 몸에 소름이 돋는다. 벅차도록 기뻤고 옆에서 나보다 더 기뻐해준 사람들이 있어서 감사했다.

사실 이거 합격한게 뭐가 대단한거라고 이렇게 호들갑을 떨까 생각하는 사람도 있을 거다. 하지만 이건 나에겐 정말 큰 의미다. 나는 무슨 일을 해도 금방 포기하고, 변명만 하던 사람이었다. 그러던 내가 처음으로 간절히 원하던 걸 내 힘으로 이뤄낸 것이다.

내가 워낙 자만이 심한 사람이라 남들과 비교하며 우월감 느끼는 경우가 가끔 있는데 100명 정도 되는 프리코스 지원자들 중 "그래도 내가 이 사람보다는 잘했지"하는 생각이 든 지원자는 한 명도 없었다. 스스로 제출한 프로젝트를 보면 볼수록 부족한 점 밖에 보이지 않았다. 그래서 최종합격은 이미 체념하고 이제 무엇을 할까 고민하고 있었는데 너무나 큰 행운이 찾아와서 현실감이 없다. 믿기지 않아서 지금도 이틀에 한번은 최종합격 메일을 다시 본다. 부족한 부분이 참 많았을텐데 가능성을 보고 합격시켜준 우테코 분들에게 감사하다. 내가 뽑힘으로서 탈락한 누군가에겐 간절했을 기회라는걸 기억하고 매 순간 최선을 다해야겠다.

프리코스 과정 중 짧은 시간안에 새로운 걸 많이 배우고 바로 적용하면서 어려움과 답답함을 느꼈는데 그 동안 내가 아는 지식 내에서만 편하게 개발하고 안주하고 자만한 것 같아 반성하고 내 부족함을 인정하게 되었다. 아이러니하게도 내 부족함을 깨달은 지금 이 순간이 그 어느 때 보다 긍정적인 힘과 희망이 넘치는 것 같다. 그 동안 이 세상에서 내가 어디쯤에 있는지 몰라 길을 잃고 헤맸다면 지금은 저 멀리 내가 가고자하는 지점이 희미하게 보이는 느낌이다. 멀고 힘든 길이겠지만 후회는 없다.

2021년이 기대된다.

[우아한테크코스] 프리코스 3주차 - 지하철 노선도 미션

JoyyKim — Wed, 23 Dec 2020 20:15:02 +0900

3주차 과제 회고

새로 알게 된것

객체에 메시지를 보내는 법
비즈니스 로직과 UI 로직을 분리하라
동작하게 만들고, 제대로 만들고, 빠르게 만든다
enum의 다양한 활용법

아쉬웠던 점

중복 코드가 많은 것
살아있는 문서를 만들지 못한 것
객체지향적이지 못한 설계
테스트 코드를 제대로 작성하지 못한 것

객체에 메시지를 보내라

"메시지를 보낸다"라는 개념이 처음엔 생소했습니다. 그 의미를 곰곰히 생각해보았고 제가 그 동안 객체를 객체스럽게 사용하지 못하고 데이터 덩어리처럼 사용하는 경우가 많았다는 걸 깨달았습니다. 덕분에 정보만 담고 있는 데이터 덩어리가 아닌 역할과 책임을 가지고 있는 객체를 만들 수 있게 되었습니다.

비지니스 로직과 UI 로직을 분리하라

그 동안 하나의 도메인에 관련된 역할은 모두 모아놓고 구현해왔는데 비즈니스 로직과 UI를 분리하면서 좀 더 책임이 분명한 객체들을 만들 수 있었습니다. 레이어를 나누며 결합도가 낮아지는걸 경험하면서 더 많은 아키텍처들에 대해 알고 싶어졌습니다. 도메인, MVC, 서비스 레이어 등 여러 아키텍처를 조금씩 공부하면서 기능 구현 뿐 아니라 설계의 본질이라고 생각되는 "코드를 어떻게 배치할 것인가"를 고민하는 즐거운 시간이었습니다.

동작하게 만들고, 제대로 만들고, 빠르게 만든다

처음에는 완벽한 설계를 하고 구현을 시작해야한다는 이상한 강박에 사로잡혀 이틀 정도 거의 아무 코드도 작성하지 못하는 고난이 있었습니다. 좋은 설계를 가지고 시작하고 싶다는 마음 덕분에 공부를 하며 새로운 지식을 얻을 수 있었지만 과제의 기한과 제 능력을 제대로 파악하지 못하고 시간이 허비되었다는 생각도 듭니다.

그 때에 포비님의 세미나 중 "처음부터 완벽한 설계는 없다. 일단 동작하는 코드를 만들고, 그걸 개선해라"(정확한 대사는 기억이 안나지만 비슷한 의미였습니다..) 라는 말씀을 듣고 마음껏 똥(?)을 만들어내기 시작했습니다. 신기하게도 아무리 머릿속으로, 노트에 그려도 감이 안잡히던 설계가 보이기 시작했습니다.

enum

메뉴 선택지를 구현할 때 반복적인 조건문 없이 구현하고 싶어서 방법을 찾던 중 enum을 알게 되었습니다. enum을 활용하면 좀 더 가독성 좋고 안정적인 조건분기를 할 수 있을 것 같아서 적용해보았습니다. 다른 언어와는 달리 하나의 클래스처럼 동작하기 때문에 많은 일들을 할 수 있다는 걸 알게 되었는데 그 중 새로웠던 활용법은 필드로 Functional Interface를 가질 수 있어서 enum이 로직을 가지는 것이 가능하다 는 점 입니다.

반복하지 마라

메뉴 선택지를 enum으로 구현한 덕분에 조건문 지옥은 피했지만 이번엔 선택지(enum)의 적절한 위치가 어디일까라는 고민이 생겼습니다. 사용자가 메뉴를 선택하는 어플리케이션 로직은 컨트롤러의 역할이라고 생각해 컨트롤러의 Inner class로 배치했지만 Inner class는 상속이 불가하다는 점 때문에 컨트롤러마다 선택지를 직접 만들어 주었고 변경이 있을 때마다 선택지 클래스를 일일이 찾아서 수정해주었습니다. enum의 요구사항이 변경될 때 마다 다른 enum에서도 똑같은 작업을 하며 비효율적으로 일했습니다. 컨트롤러와 enum을 효과적으로 관리할 수 있는 방법을 찾지 못했고 선택지라는 클래스끼리 어떤 관계도 만들어주지 못한 것이 큰 실수였습니다.

만약 리팩토링을 한다면 컨트롤러와 메뉴(enum)의 분리하여 컨트롤러와 메뉴 모두 메뉴 인터페이스를 의존하게 만들 것 같습니다.

객체지향을 버린 설계...

자바에서 MVC 패턴을 접해보는건 처음이라 객체지향적 설계를 전혀 하지 못한것이 아쉽습니다. 로직을 레이어로 분리하면서 static 메소드를 자주 쓰게 되었는데 제 때에 개선하지 못하고 컨트롤러, 서비스 대부분의 로직을 static 메소드로 구현해버렸습니다. 나중에 제 코드를 보니 클래스를 사용할 뿐 전혀 객체를 쓰지 않고 있다는 사실을 알았고 오히려 절차지향에 가깝다고 생각했습니다.

[Git] Merge vs Rebase - Git Branch 합치기

JoyyKim — Mon, 7 Dec 2020 17:53:50 +0900

우리는 깃을 쓰면서 브랜치를 나누어 안전하게 작업하고 완성된 작업을 다시 원래의 브랜치로 합쳐서 작업을 업데이트 한다.

깃에는 브랜치를 합치는 방법이 두 가지, Merge와 Rebase가 있지만 깃을 처음 접하는 초심자들은 브랜치를 합칠 때 Merge만을 사용한다. 두 방법의 차이점을 알아보자.

합치는 명령어는 Merge와 Rebase이지만 실제 사용할 때에는 따로 사용하는게 아니다.

Merge만 사용하기
Rebase 후, Merge하기

예제를 통해 설명 하겠다.

현 상황은 master 브랜치에서 작업 중, 커밋 C2에서 experiment 브랜치를 생성해서 checkout 하고 C4를 커밋. master에서 C3를 커밋했다. 이제 작업이 완료된 experiment 브랜치를 master 브랜치로 합치려고 한다.

"C~"는 커밋이고 화살표는 자신의 부모 커밋을 바라보는 방향이다. ex) C1은 자신의 부모 커밋 C0을 바라본다.

master 브랜치에서 나뉜 experiment 브랜치

1. Merge

master 브랜치에서 experiment 브랜치를 Merge한다.

$ git checkout master
$ git merge experiment

충돌이 일어나지 않았다면 3-way Merge를 통해 별도의 Merge 커밋 C5를 만들고 master 브랜치는 C5로 최신화 된다.

3-way Merge를 통한 합치기. Merge 커밋 C5가 생성되었다.

Merge를 통한 브랜치 병합 과정에서 특징은 다음과 같다.

experiment 브랜치는 변경이 되지 않음 (Merge 전의 각자 브랜치의 커밋 로그가 그대로 남아있음)
Merge를 진행하는 주체는 master 브랜치이다. (master로 checkout한 후 experiment를 merge)

2. Rebase

Rebase도 브랜치의 병합이지만 조금 다르다. Merge가 Merge커밋을 통해 C3 와 C4 를 둘 다 가리키는 반면, Rebase는 C3 에서 변경된 사항을 Patch로 만들고 이를 다시 C4 에 적용시킨다.

요약: Rebase 명령은 한 브랜치에서 변경된 사항을 다른 브랜치에 적용한다.

이제 Rebase를 통해 두 브랜치를 합쳐보자

$ git checkout experiment
$ git rebase master

실행하면 아래와 같은 상태가 된다. master 브랜치는 그대로 있고 experiment의 작업(변경사항)이 master에게 옮겨왔다. 그리고 옮겨온 변경사항 커밋은 C4가 아니라 C4`이다. 이것은 experiment의 커밋로그가 내용만 복사되어 새로운 커밋이 됐다는 뜻이다. 자세한 내용은 나중에 설명하겠다.

Rebase를 통한 브랜치 합치기. experiment의 커밋이 복제되어 master에 적용되었다.

일단 명령어를 보면 Merge와는 조금 다른 점이 있다. 일단 Rebase를 하는 주체가 master가 아니라 experiment다.

정확한 설명인지 자신은 없지만 나는 "experiment가 자신의 base, C2에서 master의 최신 커밋 C3로 base를 옮김, 즉 Rebase 했다"고 생각하니 이해하는데 도움이 되었다.

공식문서의 자세한 설명은 이렇다.

실제로 일어나는 일을 설명하자면 일단 두 브랜치가 나뉘기 전인 공통 커밋으로 이동하고 나서 그 커밋부터 지금 Checkout 한 브랜치가 가리키는 커밋까지 diff를 차례로 만들어 어딘가에 임시로 저장해 놓는다. Rebase 할 브랜치(experiment)가 합칠 브랜치(master)가 가리키는 커밋을 가리키게 하고 아까 저장해 놓았던 변경사항을 차례대로 적용한다.

아직 끝난게 아니다. master를 C4`로 최신화해줘야 한다. 아래의 명령어로 master를 Fast-forward 시켜주자

$ git checkout master
$ git merge experiment

master를 Fast-forward 시켜 최신화 해준다

master입장에서 experiment는 자신보다 앞서있는 브랜치이기 때문에 merge 명령어를 실행하면 별다른 병합 없이 해당 브랜치까지 전진하는데 이걸 Fast-forward 라고 한다. 이렇게 하면 master에 experiment의 작업이 모두 적용되었다.

참고

Git 브랜치 - Rebase하기
Git 브랜치 - 브랜치와 Merge 의 기초