[후기] 03. 유스콘(YOUTHCON) 2022

우아한 테크 코스 5기 슬랙방에서 우연히 우아한 형제들과 넥스트스탭에서 주관하는 유스콘 콘퍼런스를 알게 되었다.

누군가의 생각과 경험을 듣는 걸 좋아하기도 하고, 콘퍼런스마다 나 자신을 되돌아볼 수 있게 돼서 이번에도 참여하게 되었다.

https://frost-witch-afb.notion.site/YOUTHCON-22-a18e4511463a416e8befd99993355215

YOUTHCON'22

아쉽게도 올해 마지막 날이라 가족끼리 시간을 보내야 할 것 같아서 오프라인 신청도 못해봤지만 서울경기권에 거주하게 된다면 어떤 콘퍼런스든 웬만하면 오프라인 신청을 하려고 한다.

내가 참여한 세션은 다음과 같다.

OOP START!

전체적으로 GRASP 패턴의 몇 가지 원칙에 따라 핸즈온 방식으로 진행되었는데 객체 지향은 이렇게 하는구나 라는 걸 알게 해준 세션이었다.

흔히 객체 지향을 말할 때 역할과 책임에 대한 얘기가 종종 나오게 된다.
그리고, 객체 지향의 특성으로 캡슐화, 상속, 추상화, 다형성을 말한다.

무엇보다 이번 세션에서 캡슐화에 대한 배움이 컸다.

세션의 일부 중에서 "캡슐화는 데이터 은닉만을 말하는 것이 아니다."라고 설명한 부분이 있다.
부끄럽게도 내가 아는 캡슐화에 대한 정의는 저것만 알고 있었다..

캡슐화에도 종류가 여러 개 있었다.

- 데이터 캡슐화
- 메서드 캡슐화
- 객체 캡슐화
- 서브 타입 캡슐화

일반적으로 흔히 하는 캡슐화는 4가지 종류 중 데이터 캡슐화에 해당되고, 데이터 캡슐화는 필드에 대한 접근을 좁히고, 메서드를 통해 접근하는 것이다.

그 외 나머지에 대한 건 실제로 적용해보질 않아서 설명하기엔 부족하다는 생각이 들어서 만약 해당 세션이 올라온다면 충분히 시간을 들여서 볼만하다고 생각한다.

결론적으로 캡슐화는 단순히 데이터를 외부에서 접근만을 얘기하는 것이 아니었다.
세션 발표자님은 캡슐화를 이렇게 정의하였다.

캡슐화는 변경될 수 있는 어떤 것이라도 감추는 것
내부 구현의 변경으로 외부 객체가 영향받는다면 캡슐화를 위반한 것
변화와 불안정성이 다른 요소에 나쁜 영향을 미치지 않도록 방지하는 것

캡슐화 말고도 상속에 대한 정의도 다시금 배웠다.
상속은 코드를 재사용하는 목적이면 안 된다. 상속의 목적은 타입 계층을 구현하기 위함이다.

Unit Test Puzzler: 퀴즈로 알아보는 단위 테스트

앞선 세션에 이어 나 자신에게 회초리(?)를 든 세션이었다.

일단 7가지의 퀴즈 퍼즐을 나만의 방식으로 정리를 한 걸 적어봤다.

1. 두 가지 동작을 한 번에 검증을 하면 무엇을 테스트하는지 모른다.
2. 매개변수화 테스트로 중복을 제거할 수 있다. (@ParameterizedTest)
3. 테스트에서 if문을 사용하지 않아야 한다.
4. 단일 작업을 하는데 두 개의 메서드 호출이 필요하다면 설계가 잘못된 API이다.
5. private 메서드를 테스트하는 것은 private를 사용하는 의도와 맞지 않기에 테스트를 지양한다.
6. 테스트는 언제, 어떻게 실행하든 성공해야 한다.
7. 좋은 단위 테스트는 테스트 하나만 봐도 어떤 테스트인지 알아야 한다. 즉, 테스트케이스 간 결합이 존재하면 안 된다.

프로젝트에서 내가 작성한 테스트 코드와 이번 세션에서 정의한 좋은 단위 테스트 코드와 비교해본다면 난 2,4,6,7번을 어겼다고 볼 수 있다.

어기게 된 건 역시나 테스트 코드나 TDD를 어깨너머로 배웠기 때문에 얕은 지식을 가져서라고 생각한다.
그래도 지금이라도 내가 이런 오류를 범하고 있다는 걸 이 세션을 계기로 되돌아볼 수 있어서 다행이라고 생각한다.

무엇보다 가장 기억에 남는 건 BeforeEach를 언제 사용하는가였다.
중복을 줄이기 위해 BeforeEach에 값 설정을 해온 경험이 있는데 이럴 경우 테스트 간 결합도가 생기게 되어 알아보기 힘들어진다는 것이었다. 그래서 BeforeEach는 값 설정보다 환경 설정을 하는 것이 더 적합한 상황(?)이라고 한다.

중복이 생겨도 테스트간 결합도는 없고 알아보기 좋게 하는 것이 좋은 단위 테스트이고, 중복을 줄이려면 Helper 메서드로 값 설정을 하는 것이 좋다고 한다.

토비의 스프링 같이 읽기

같은 시간대의 세션을 더 듣고 싶었지만,,,, 사실 1주일 전에 토비의 스프링을 구매해서 시간이 없으니 1권만 꾸준히 봐야지라는 생각이 있어서 듣게 되었다.

토비 님과 함께 스터디하면서 인상 깊었던 내용과 토비의 스프링을 읽으면서 겪은 시행착오와 후기가 담긴 세션이었다.

내가 느낀 바로 주요 내용은 두 가지였다.

• 토비의 스프링을 읽고 무엇을 배웠는가
• 토비 님과 스터디를 하면서 인상 깊었던 내용

1. 토비의 스프링을 읽고 무엇을 배웠는가
발표자님은 토비의 스프링을 보고 나서 코드를 보는 눈이 좋아지고, 다양한 디자인 패턴과 객체 지향 기법을 익혔다고 한다.

스프링을 더 잘 이해하고자 어제부터 먼지 쌓인 헤드퍼스트 디자인패턴을 다시 꺼내보기 시작했다.
1장밖에 보진 못했지만 끝까지 본다면 자바/스프링을 더 잘 이해하고 쓸 수 있을 것 같다는 생각하던 찰나에 이 얘기를 들으니 좋은 코드를 쓰는 건 생각보다 더 어려운 거구나 는 걸 느꼈다.

2. 토비 님과 스터디를 하면서 인상 깊었던 내용
전달할 만한 걸 추려서 DI, TDD, 예외 처리, 코프링 순으로 4가지의 이야기를 들려주셨다.

DI는 의존성 주입할 객체는 가능한 한 인터페이스를 사용하라는 것이고,
TDD는 시간이 들어도 테스트는 만들어야 하고, TDD는 내 코드에 대한 피드백을 받는 사이클을 컨트롤하는 기법이라는 것이고,
예외 처리는 생각하는 것보다 더 중요하니 throws를 남발하거나 대충 하지 말라는 것이었고,
코프링은 자프링과 비교했을 때 여러 장단점을 얘기해 주셨다.

SI 개발자의 서비스 회사 적응기

SI에서 5년을 근무하고 서비스 회사로 이직하면서 느낀 각 회사마다 느낀 환경과 경험을 공유해준 세션이었다.

기억에 남는 한 문장이 있다. 동료가 최고의 복지다.
생각해보면 나도 올해 빠르게 성장할 수 있었던 건 동료 덕분이고, 만족할 만한 프로젝트를 내게 된 것도 전부 동료 덕분이었다.
그리고 최근 배우는 기술들을 얘기를 해주시던 중에 2-3년 차까지 활동을 많이 하긴 했으나 흐르듯이 지냈던 게 아쉽다는 말을 해주셨다.

이 말을 듣고 어제 헤드퍼스트 서문에 적힌 문장을 적어둔 것이 떠올랐다.

천천히 하세요.
더 많이 이해할수록 외울 내용은 줄어들게 마련입니다.

그냥 무작정 읽지 맙시다.
잠깐씩 쉬면서 생각을 해봅시다.
책에 있는 질문을 보고 바로 정답으로 넘어가면 안 됩니다.
누군가 다른 사람이 정말로 질문을 하고 있다고 생각하세요.
더 깊이, 신중하게 생각할수록 더 잘 배우고 기억할 수 있습니다.

최근에 책도 많이 사고, 할 건 많다는 생각에 약간의 조바심을 가지는 나날들을 보내고 있었다.
그런 와중에 연사님의 말과 어제 본 문장을 보면서 느리더라도 멀리 가자는 생각으로 내 패턴에 맞춰서 행동하려고 한다.

---

풀타임 콘퍼런스 참여는 지난 인프콘에 이어 두 번째였는데 이번에도 반성해야 하고, 알아가는 것이 너무나도 많았다.
무엇보다 내가 먼저 선행되어야 하겠지만, 좋은 동료, 좋은 환경인 곳에서 성장하고 싶다는 생각이 들었다.

나도 누군가에게 좋은 동료가 된다면 여러 사람 앞에서 내 생각도 얘기해 보고, 지식의 깊이도 깊다면 정보도 공유할 수 있는 사람이 되고 싶다.