인프콘 2024 참가 후기

드디어! 나도! 인프콘!

매년 너무너무 인프콘에 참가하고 싶어서 간절한 마음으로 신청했지만 광탈했고, 올해도 마찬가지로 광탈하였으나…!
개인적 사유로 참가가 불가하신 용근님의 양도를 받아 인프콘에 다녀왔다 🥳🎉

듣고 싶은 세션이 많아서 고민 * ∞ 끝에 고른 세션은 바로 얘네들이다!

(장표 넣어서 정리하고 싶었는데… 장표 언제 공유되나요 인프콘..?)

세션1. 지속 성장 가능한 설계를 만들어가는 방법 - 김재민님

용근님이 추천해주신 세션이라 가장 기대하면서 본 세션이다.

설계하는 방법을 설명해 주실 줄 알았는데, 설계를 잘하는 방법 = 설계를 하지 않는 것이라는 장표로 시작을 하셨다. 😱 이어서 설계 대신 구현을 개념과 격벽이라는 두 가지로 나누어 설명해 주셨다.

개념은 말 그대로 프로덕트에서 사용되는 개념들이다.(e.g. 웹툰, 작품, 작가, 결제, …) 하지만 개념들을 묶을 수 있는 그룹이 여러개가 되면서 복잡도가 높아지는데, 이는 개념의 흐름이 통제되지 않아 발생하는 문제이다.

여기서 격벽이 등장한다. 방화벽이 허용한 요청만 흘려보내며 접근을 제어하고 흐름을 통제하듯이, 개념을 가로막은 격벽은 개념간의 접근을 제어하고 흐름을 통제한다. 코드를 통해 격벽의 예시를 보여주셨는데, 격벽이 잘 되어있다면 하나의 개념에 해당하는 클래스명을 수정해도 관련 클래스와 테스트 클래스에만 변경이 생기는 것을 확인할 수 있었다.

이어서 대출을 예시로 들어 설명해주셨는데, 대출이라는 개념이 신청, 실행, 상환이라는 행위로 이루어져 있다고 바라볼 수 있다. 이 경우 대출에 코드 변경이 일어날 경우 대출에 의존되어 있는 신청, 실행, 상환 코드도 모두 변경되는 문제가 발생한다. 이를 해결하기 위해 신청, 실행, 상환을 각각 대출과 분리된 개념으로 간주하게 되면, 대출이라는 개념에 변경이 발생해도 신청, 실행, 상환에는 영향을 주지 않게 된다.

그런데 상환에 실패하는 경우 재시도가 발생하거나 추가 이자가 발생하는 등 상환의 상태에 대한 요구사항이 커지며 상환이라는 개념 자체가 계속해서 커지는 문제도 발생한다. 이를 해결하기 위해서는 상환 실패라는 것을 상환의 상태로 간주하는 것이 아닌, 연체라는 새로운 개념으로 분리하여 관리할 수 있다.

대출 사례의 내용을 정리하자면 다음과 같다.

• 하나의 개념이 많이 쓰이면 분리를 검토하자
• 상태에 의해 개념이 생기면 격벽을 세워보자
• 상태나 행위를 개념으로 착각할 수 있다.

커머스를 예시로도 설명해주셨는데, 상품과 외부 연동사를 동등한 개념으로 바라보게 되면 외부 연동사의 변경이 상품에 영향을 주게되는 문제가 발생한다. 개념이란 우리가 만든 서비스를 지탱하는 것으로 외부 연동사와 DB의 영역이 수집 및 정제 영역이라면, 상품은 개념 영역에 해당한다. 이런 경우에는 모듈을 분리함으로써 외부 연동사의 변경이 상품에 영향을 주지 않도록 강제 할 수 있다. 더 나아가 개념에도 계층이 존재할 수 있으며, 모니터링이나 테스팅과 같이 개념이 없는 곳도 존재할 수 있다.

커머스 사례의 내용을 정리하자면 다음과 같다.

• 개념에도 계층이 있다
• 모든 것이 개념이 되지는 않는다
• 개념 영역을 분리할 수 있다

마지막으로 하드웨어/건설과 소프트웨어를 비교하며 소프트웨어의 설계는 유연해야 함을 강조하시면서, 인정하고, 하지말고, 상기해야 할 것들을 3개씩 나열해주셨다.

인정하자

• 요구사항은 계속 변한다
• 완벽한 설계란 없다
• Software는 Soft 해야한다

하지말자

• 요구사항이 완벽해야 설계 가능해요
• 우리 설계에서 그건 개발 못해요
• 설계해 봐야 개발 일정이 나옵니다

상기하자

• 성급한 설계는 모든 것을 망가트린다
• 과도한 설계는 모든 것을 망가트린다
• 설계는 필요한 만큼만 하자

세션 주제가 설계인 만큼 재민님이 생각하시는 설계에 대해서도 말씀해주셨는데, 개념을 잡고 격벽을 세워 구현하고 테스트 코드를 통해 증명하고 피드백하는 과정을 반복하다보면 설계가 자연스럽게 나오게 된다고 하셨다.

❗느낀점

가장 기대가 높았음에도 기대 이상으로 너무 좋았던 세션이었다.
설계라고 해서 어려운 기술과 용어를 이용해 요구사항을 충족할 수 있는 완벽한 설계를 도출해내는 것이 우선이 아니고,
결국 우리가 코드로써 해결하고자 하는 문제를 명확희 정의하고, 그 문제를 해결하기 위한 개념을 잡고, 각 개념의 관심사를 분리하여 상호작용을 통해 문제를 해결하는 것이 중요하다는 점을 다시 한번 느꼈다!
해결하고자 하는 문제의 본질을 잊지 말자!!

세션2. 디버깅 마인드셋: 디버깅의 고통을 절반으로 줄여주는 고수들의 행동패턴 따라하기 - 배휘동님

평소에도 디버깅을 잘하고 싶다는 생각을 가지고 있어서 해당 세션을 듣게되었다.

먼저 디버깅 역량을 키우기 어려운 이유는 보통 문제를 마주했을때 직관적으로 예측하여 찍다보니 마법처럼 맞추게되고, 이 과정이 반복되며 경험에 의한 직관만 남게 되기 때문이다. 휘동님은 디버깅을 잘하기 위해 디버깅을 잘하기로 소문난 몇몇 개발자들과, 한의사 등 문제 해결에 있어 전문가인 사람들을 인터뷰한 결과 디버깅은 마법이 아닌 마술과 같다는 사실, 즉 디버깅은 신비하고 어렵다기보다는 누구나 기술을 익히면 쉽게 할 수 있는 것을 알게 되었다.

다음은 문제 해결 전문가들이 문제 해결을 위해 하는 단계를 정형화 시킨 것으로, 각 단계를 순서대로 진행하기 보다는 필요한 단계로 이동하며 문제를 해결하게 된다.

문제 정의

• 말 그대로 현재 해결하고자 하는 문제를 정의하는 단계이다.
• 이 단계를 건너뛰게 되면 중요하지 않은 문제에 시간을 많이 쏟게된다.

정상동작 정의

• 가장 중요한 단계이다. 정상적인 환경에서는 어떤 조건에서 어떤 순서로 어떤 일들이 벌어지는지 정의하는 단계이다.
• 만약 이 단계가 안된다면 문제를 해결할 준비가 되지 않은 것으로, 정보를 더 찾아보거나 도움을 요청하는 것이 필요하다.
• 정상동작을 given, when, then의 구조로 정리해보는 것도 좋은 방법이다.

최소 재현 환경 구축, 관찰

• 사용자의 환경과 동작을 그대로 재실행해 보는 단계이다.
• 이때, 정상 환경에서 조건을 하나씩 소거해나가며 문제 상황을 만들어 보고, 패턴을 관찰해볼 수 있다.
• 관찰 결과를 2번에 갱신해나갈 수도 있다.

차이를 발생시키는 다양한 원인 탐색

• 추상적이든 구체적이든 다양한 가설을 적어보는 단계이다.

가설 설정 및 검증

• 4번에서 탐색한 가설을 검증 가능한 형태로 문장화하는 것이다.
• 만약 가설이 틀렸다면 다시 4번으로 돌아가서 다른 가설을 세워보아야 한다.
• 어렵다면 마찬가지로 정보를 더 찾아보거나 도움을 요청하는 것이 필요하다.

추가로, 각 단계 혹은 해당 문제의 디버깅에 얼마나 시간을 쏟을 것인가를 사전에 결정하는 것도 중요하다. 풀리지 않는 문제를 계속해서 잡고 있는 것은 또 하나의 비효율로, 잠시 산책을 통해 머리를 식히거나, 도움을 요청하는 것도 좋은 방법이다.

❗느낀점

어쩌면 당연한 부분이면서도, 빠르게 문제를 해결하고 싶은 마음에 놓치고 있는 부분들을 콕 찝어 정리해주는 세션이었다.
해결하고자 하는 문제를 차분히 정의하고 가설을 통해 검증하며 문제 해결의 전문가로 거듭나자!!

세션3. 사이드 프로젝트로 커리어 레벨업! - 조현우님

취업 전부터 사이드 프로젝트에 대한 로망이 있었던 나로써는 굉장히 관심이 가는 세션이었다.

사이드 프로젝트를 잘 하는 방법에 대해 이야기 해주셨다.

먼저 사이드 프로젝트의 크기는 max로 2-3일 내에 완성이 가능한 크기로 하는 것이 좋다.

사이드 프로젝트는 몰입이 중요한데, 몰입을 유지할 수 있는 기간이 보통 2-3일 정도일 것이기 때문이다.(물론 개인 차이가 있을 수 있다.)
만약 만들고 싶은 결과물이 크다면, 기능을 작게 나누어 애자일하게 조금씩 만들어 키워나갈 수 있다.
많이 사용해보지 않은 기술이더라도 작게 나누어 사용해 나가는 것이 좋다.

주제 선정의 경우 자신이 관심이 있는 분야를 선택하는 것이 좋다.

몰입과 비슷한 맥락으로 관심이 지속될 수 있도록 흥미를 유지하는 것이 중요하다.
평소에 관심 있었던 아이디어나, 내가 소비자가 될 수 있는 것, 또는 요즘 트렌드인 것을 주제로 선정해 볼 수 있다.

프로젝트마다 안써본 기술을 하나씩 추가해보는 것도 좋다.

크기가 작고 짧게 사용해보는 것이라고 하더라도, 프로젝트마다 누적해서 사용하다보념 복리효과를 누릴 수 있다.
큰게 아니더라도 새로운 저장소를 사용해볼 수도 있고, 배포 방식을 변경하거나 처음 사용해보는 라이브러리를 사용하는 등 다양한 방법으로 새로운 기술을 도입해볼 수 있다.
이미 회사에서 사용 중인 기술이라고 하더라도 회사에서는 주로 유지보수를 하게 되지만, 사이드 프로젝트에서는 처음부터 셋팅해서 사용하는 경험을 얻을 수 있다.

AWS, 도메인, 앱 스토어 개발자 등 돈 쓰는 것을 아까워하지 말자.

실제로 돈을 내고 사용해봐야 아는 것들이 있기 때문에, 돈 쓰는 것이 아닌 강의를 구매하는 것 처럼 성장에 투자한다고 생각하자.

마지막으로 두려움을 없애야 한다.(이거 너무 내 얘기…)

팀과 개인 프로젝트를 두고 본다면 내가 온전히 집중할 수 있는 개인 프로젝트를 강력 추천한다.
팀 프로젝트는 커뮤니케이션 등 프로젝트를 진행하는 것 외에 드는 비용이 많다.
무엇보다 할 수 있을지에 대한 막연한 두려움이 있을 수 있지만, 부딪혀 보는 것이 빠른 성장으로 갈 수 있는 길이다.

❗느낀점

열정과 에너지가 넘치시는 대단한 분이라고 생각되기도 하고, 따라해보고 싶어졌다.
세션을 들으면서 사이드 주제에 대해 고민했다.. ㅋㅋㅋ 당 장 레 포 파 ! ! !

세션5. 클린 스프링: 스프링 개발자를 위한 클린코드 전략 - 이일민님

굳이 설명이 필요 없는 백엔드 필수 세션… 😎

개발바닥에서 다루었던 주제인 클린코딩 하는데 구현을 못하는 개발자 이야기를 하며, 클린코드에 대한 오해라는 내용으로 시작되었다. 클린코드라는 말이 가장 먼저 다뤄진 것은 Clean code that works라는 로버트 C. 마틴의 문장에서 부터였고, 클린코드는 작동하는 코드라는 것을 잊지 말아야 한다. 클린코드가 최근 들어 코드 결벽증이나 원칙 기반 코드로 비춰지기도 하는데, 사실 클린코드의 본질은 유지보수하기 좋은 코드에 있다.

그렇다면 유지보수하기 좋은 클린코드는 개발 생산성이 떨어지는 것일까? 유지보수와 생산성은 서로 영향을 주고 받을 수는 있지만, 반비례하는 관계가 아니다.

클린코드의 선순환은, 현재 이해를 반영하는 코드를 빠르게 출시하고 리팩터링하는 단계를 거듭하며 코드를 개선해 나가는 것이다. 이때, 코드를 빠르게 출시한다고 해서 대충 작성하는 것이 아니라, 리팩터링 가능한 구조로 개발하는 것이 중요하다. 이렇게 유지보수와 생산성의 균형을 이루기 위해서는 테스트 작성이 필수적이며, 테스트를 빠르고 효과적으로 작성하며 개발하는 능력이 필요하다. 무엇보다 테스트가 도입 시점에서는 시간이 더 오래 걸린다고 보여질 수 있지만, 장기적으로는 테스트를 통해 생산성을 높일 수 있다.

유지보수와 생산성 외에도 우리가 고려해야 할 점이 있는데, 바로 팀워크이다. 클린코드의 설명 중 ‘읽기 좋은 코드’, ‘리팩터링 하기 좋은 코드’에는 대상이 있는데, 그 대상은 바로 ‘나’가 아닌 ‘팀원’이다. 읽기 좋고, 리팩터링 하기 좋다는 개념은 상대적이며, 상황마다 다른 기준이 있을 수 있기 때문에 나만을 위한 클린코드는 존재하지 않는다.

토비님은 여기서 함께 탐험하는 것을 즐거워하는 팀을 강조하며 함께 결정하고, 탐험하고, 학습하고, 성장하는 것이 중요하다고 말씀하셨다. 또 더 나아가 자신의 말을 하더라도 다른 사람의 기분을 나쁘게 하지 않는 친절한 코드를 짜는 것이 중요하다고 강조하셨다.

❗느낀점

Clean code that works라는 문장이 너무 인상적이었다.
깨끗하게 코드를 짤 방법이 떠오르지 않아 한참을 고민하고 개발 속도가 느려진 적이 종종 있었는데, 이번 세션을 통해 클린코드의 본질을 다시 한번 생각해보게 되었다. 팀원들이 이해하고 리팩터링하기 쉬운 친절한 코드를…! 테스트로 검증된 동작하는 코드를…! 🫠
(한편으로 나는 함께 탐험하는 것을 즐거워하는 팀에 있는 것 같아 감사하다고 생각했다. ㅎㅎ)

세션6. 객체지향은 여전히 유용한가? - 조영호님

굳이 설명이 필요 없는 백엔드 필수 세션… 222 😎

요즘 취준생, 주니어 개발자들이 ‘객체지향이 여전히 유용한지’에 대한 질문을 종종 하는 것을 보며, 성장하기 위해서는 질문을 조금 바꿀 필요가 있다고 이야기하시며 세션을 시작하셨다.

동일한 내용을 절차적인 설계와 객체지향 설계를 통해 각각 구현해두고, 요구사항에 따라 각 코드가 어떻게 변화해 나가는지에 대해 비교, 분석해주셨다.

• 절차적인 설계 : process에서 data 각각의 조건을 계산
• 객체지향 설계 : 하나의 Object 내에서 조건을 판단

A. data 구조가 변경된 경우

• 절차적인 설계 : data 구조가 변경되고, process의 로직에도 변경이 발생하는 것을 통해 결합도가 높다는 것을 확인
• 객체지향 설계 : Object 구조가 변경되었지만, 캡슐화 되어 클래스 내에서만 값을 사용중이라 해당 클래스에만 변경이 발생

B. 판단 조건의 타입이 추가된 경우

• 절차적인 설계 : data의 추가된 type에 따라 process에 분기문이 추가되며 마찬가지로 변경 사항이 process로 전파
• 객체지향 설계 : 다형성을 통해 타입 추가를 제어햐여 다른 코드를 변경하지 않고 타입을 확장하며 일관성 유지

여기까지만 보면 객체지향이 더 좋다고 판단할 수 있지만, B에 새로운 기능을 추가하며 살펴보았다.

B + 새로운 기능 추가

• 절차적인 설계 : 신규 메서드가 하나만 추가되면 되지만, 새로운 타입이 추가되면 모든 기능 메서드에 분기문이 추가되어야 한다.
• 객체지향 설계 : 인터페이스 메서드가 추가될 때 마다 타입마다 불필요한 override가 발생한다.

지금까지 살펴본 예시를 통해, 신규 타입 추가가 잦은 경우 객체지향이 유용하지만, 신규 기능 추가가 잦은 경우 절차적인 설계가 유용하다는 것을 볼 수 있다.

데이터 변환 관점에서도 살펴보았다.

• 절차적인 설계 : 내부 type이 노골적으로 들어나있어 그대로 변환이 가능해 비교적 편리
• 객체지향 설계 : 객체가 어떤 type인지 instanceOf로 판단이 필요하며, 각 타입에 따른 변환 구현이 필요

따라서 레이어 아키텍쳐를 기준으로 살펴보았을때, 데이터 변환이 주를 이루는 프레젠터, 서비스, 퍼시스턴트 레이어에서는 절차적인 설계가 유용하며, 규칙 기반의 상태 변경이 일어나는 도메인 레이어에서는 객체지향이 유용하다는 점을 알 수 있다.

절차적인 설계를 선택하든, 객체지향 설계를 선택하든 각각에는 트레이드 오프가 있다. 세션의 시작으로 돌아가 질문의 방향을 올바르게 바꿔보자면, ‘객체지향이 여전히 유용한가요?’보다는 ‘객체지향은 언제 유용한가요?’라는 질문이 더 적절하다. 만약 누군가 ‘~~를 꼭 배워야할까요?’라는 질문을 하면 ‘일단 배우세요.’라고 대답할 것이라고 말씀하셨다. 어떤 기술, 패러다임, 설계든 어떠한 문제를 해결하기 위해 만들어 진 것으로 각각의 용도가 있고, 각각이 유용한 케이스가 있다. 모든 경우를 커버하는 기술은 없기에, 현재 나의 상황에 적합한지, 유용한지를 판단하기 위해서는 일단 배우고 경험해보는 것이 중요하다고 말씀하셨다.

❗느낀점

가능한 한 지름길로 가고 싶어하는 취준생, 주니어들을 향한 우문현답 세션이었다고 생각한다.
객체지향에 대해 오랫동안 깊게 고민해봤기에 절차지향이 유용한 시점과 객체지향이 유용한 시점을 예시로 이해하기 쉽게 설명해주실 수 있다고 생각했다.
공부 의지를 불타오르게 해준 세션이었다! 🔥

마무리

너무 멋있고 열정 넘치는 사람들이 많아 좋은 자극을 받을 수 있는 시간이었다..!! 작년 우아콘 이후로 처음으로 참가한 컨퍼런스였는데, 우아콘은 사내 시스템에 대한 이야기라 흥미로웠던 반면, 인프콘은 주니어에 초점이 맞춰져 있어 더욱 유익하고 재미있었던 것 같다. 😆 세션이 끝나면 다음 세션 시작 전까지 Q&A를 진행할 수 있는 공간 + 시간도 마련되어 있어서 좋았다! 재민님 세션 듣고 Q&A하러 갔다가 사진도 찍었다. ㅎㅎ

그 외에도 부스나 참여형 이벤트들이 많아서 즐길거리가 많아서 좋았다. (포키랑 연로그랑 인프콘 세컷도 찍었다!! ㅎㅎ)

마지막 세션 시간에는 너무 당이 떨어지고 힘들어서 네트워킹 부스에 구경갔는데, 우테코 수료때 이후로 처음으로 링크드인을 써봤다. ㅋㅋㅋ (다들 명함도 들고오셔서 나눠줬는데 나는 모르고 안들고가서 못나눠줬다… 명함은 이럴때 쓰라고 있는거구나 싶었다 ㅎㅎ) 그리고 같이 이야기하던 분이 라라랑 같은 회사셔서 아는지 여쭤봤는데 같은 클랜이고 최근에 같은 운동 동아리에 들어갔다고 하셔서 신기했다!! 😳

다음에도 꼭 가고싶다!! 내년에는 추첨시켜달라 인프콘!! 🤩