UX와 디자인을 좋아하는 개발자의 기록들.
세션 + 네트워킹을 중심이었던 2025 TeoConf 를 다녀왔습니다.
24년에는 일정으로 못 가게 되어서 너무 아쉬웠는데,
즐거운 경험이 있는 컨퍼런스가 될 수 있도록 참여형 컨퍼런스를 목표로
기획하셨다는 Teo님의 말처럼 실제로 직접 참여할 수 있는 구성이 많아서
26년도에도 갈 수 있다면 또 가고 싶었던 컨퍼런스였습니다. 🙂
귀염뽀짝하던 TEOconF 굿즈들
컨퍼런스 구성과 내용 정리,
그리고 느꼈던 점 위주로 작성해보려 합니다.
컨퍼런스 초반에는 각자의 관심사에 맞는 팀구성을 통해 팀활동 온보딩을 진행했습니다.
서로 관심사를 자유롭게 이야기할 수 있도록
닉네임 위주로 부르고 편하게 말 걸 수 있는 분위기라 다른 컨퍼런스보다
훨씬 프리한 느낌이라 주니어 개발자들의 컨퍼런스에 대한 장벽을 낮춰주셨던 점이 좋았어요!
네트워킹 이후 A트랙 세 가지 세션과 Teo의 고민상담소까지 진행되었습니다.
회고했어야 하는 이유
좌절을 성장으로 바꾸는 법 / ZEN
세션 첫 순서는 “당신이 1년 전에 회고했어야 하는 이유”라는 주제였습니다.
“문제가 있을 때 그냥 넘어가는 게 아니라, 기록하고, 분석하고, 해결하는 과정 자체가 개발자스러운 태도다.” 라는 생각이 들던 세션이었는데요. 🙂
단순히 지난 흔적을 돌아보는 것이 아닌
개발자와 너무 잘 어울리는 개념이라는 생각이 들었어요.
케이스별로 소개해주셨는데 각 고민에 맞게 회고를 진행해보아도 좋을 것 같습니다.
스피커분이 진행하셨던 스터디 방식이 인상적이었습니다.
기존에 스터디를 하면서 책을 읽고 기록은 하지만
정말 내 지식이 된 게 맞을까 고민하던 순간들이 많아서 더 인상 깊었던 것 같아요.
세션에서 소개해주셨던 스터디 규칙은
배운 지식을 다시 재구성 하는 경험이 중요하다. 다시 보고, 피드백 받고, 스스로의 학습 과정을 분석하고 개선하기 위해 블로그를 시작하셨다는 실행력이 멋지더라구요.
이 부분이 크게 와 닿았는데, 책을 읽던 스터디 방식이나 그동안 공부하고 일을 하면서
개발에 대한 지식을 이야기할 때 “어느 정도”, “대략”과 같은 말로
스스로 자신없는 말로 얼버무릴 때가 있지 않았나 반성이되더라구요.
👉 단순 기록이 아니라, ‘나만의 방식으로 재구성해서 남에게 설명할 수 있는 글’을 써보는 방식처럼 내 지식 + 경험으로 만들 방법이 필요하다 회고하게 되더라구요.
개발자로 일하다 보면
“지금 잘하고 있는 걸까?” “다른 사람들보다 너무 느린 건 아닐까?”
이때 그냥 불안감에만 머무르지 않고,
기록을 통해 문제를 진단하는 도구로서 회고를 활용하자는 제안이 좋았습니다.
글로 적다 보면, 불안이 아니라 “분석 가능한 문제”로 바뀌고,
그에 맞는 해결책을 찾아 개선을 시도할 수 있는 것이 회고구나 싶었습니다.
함께 하는 회고, 그리고 KPT
소개해주신 회고 방법은 아래와 같습니다.
정확한 맥락에서, 구체적인 피드백을 받다 보니
방어적으로 느껴지지 않고, 오히려 더 잘 받아들여질 수 있었다고 이해했습니다.
스피커님의 포맷을 팀 내에서나 개인 네트워킹 자리에서 써보고 싶다는 생각이 들었습니다.
이력서를 쓰려고 앉으면 막막할 때가 많았는데요.
스피커분은 회고로 쌓인 데이터를 기반으로,
AI를 활용해서 이력서나 자기소개서를 작성하는 시대가 되었다는 이야기도 해주셨습니다.
내가 쌓아둔 기록이 소재가 되고, AI는 그걸 다듬어주는 도구라는 것. 결국 회고는 “나라는 사람의 데이터베이스”를 잘 쌓는 과정이라는 생각이 들었던 세션이었습니다.
스피커님의 현재 회사 서비스에서는 제품의 성숙도가 높은 편이라
새로운 UI를 개발하는 일보다는 기존 기능을 고도화하는 업무가 많다고 하셨습니다.
저도 지금 회사에서 FSD 구조를 프로젝트에 사용하고 있고,
처음 제가 현재 회사에 입사하고 FSD를 처음 접했을 때의 막막함이 다시 떠올라서
더 공감이 갔던 것 같아요. 🥲🥲🥲
실제 FSD 온보딩하면서 어려웠던 점과 느낀 점을 발표해주셨던 세션이었습니다.
1. 러닝 커브가 높다.
기술적 역할 중심 → 비지니스 도메인 중심의 코드 배치로 바뀌다 보니 기존 관성으로 생각하기 어렵다는 점
2. 공유 상태(context)에 의존적이다.
도메인 단위로 쪼개다 보니, 상태를 어디에서 어떻게 공유할지에 대한 설계가 더 중요해진다는 점
3. 도메인 자체의 어려움
4. 사고의 전환이 발생한다.
DDD, Layered Architecture FSD의 조상 : 도메인 위주로 나누는 사고의 전환이 발생
fsd-import, layer-imports 와 같은 린트 규칙을 적용하고, 개발을 진행하시면서
“역할과 위계를 제대로 정의했는지”를 계속 고민하게 되고 어려웠다는 이야기를 해주셨습니다.
코드 퀄리티
의존성 방향이 바뀌면서,
기존 코드의 재사용성 빈도가 높아졌다.
구조적 결함 → 도메인 응집
예전에는 구조 자체가 깨져 있다고 느껴졌다면,
이제는 도메인끼리 모여 있는 구조로 바뀌었다.
제어의 역전(IoC)을 통해 “정해진 아키텍처를 따르면 되는 상태”가 되니 오히려 편해졌다.
아키텍처 구조를 따른다는 것 = 위계를 재정의하는 것
물론, 0 → 1 기능을 만들 때는 “이게 과연 잘 맞을까?” 하는 의문은 여전히 남아 있다 하셨는데, FSD 구조를 프로젝트에 도입하기 전이나 막 도입한 후에 충분히 논의해봐도 좋을 주제 같았어요.
Q. 슬라이스를 나누기가 애매할 때는?
→ 애매할 때는 일단 widgets에 넣어둔 뒤, 리팩토링한다고 하셨어요.
Feet Stop 기간이나 리팩토링 시간이 날 때 도메인 경계를 다듬어 가는 방식.
Q. 도메인을 나누는 기준은?
→ 실제로 우리가 구현하고자 하는 “기능의 이름”을 기준으로,
모두가 같은 의미로 이해할 수 있는 용어로 정의하는 것.
Q. 도메인이 비대해졌을 때는?
→ 슬라이스를 여러 개로 나누는 방식도 고민 중이지만,
현재는 아직 과도하게 쪼개기보다는 하나의 큰 도메인을 가지고 진행
FSD는 단순히 폴더 구조의 문제가 아니라, “도메인을 어떻게 바라보고 나눌 것인가”에 대한 비지니스를 이해하는 관점에서 다시 회사 서비스에 대해 고민하고 이해해보는 세션이었습니다.
새로운 기능에 대한 피로나 학습을 해야한다는 압박감보다는 “React 19는 어떤 기존의 불편함을 해결하려고 등장했을까?” 라는 관점에서 설명해주셔서, 개발자인 동시에 사용자로서 React를 다시 보게 되는 시간이었습니다.
완전히 새로운 패러다임을 들고 나온다기보다,
이미 오래전부터 존재하던 불편함과 복잡도 등 경험을 개선하는 데
포커스를 맞춘다는 게 인상적이었습니다.
기존에는 useEffect 하나에
까지 몰아넣게 되기 쉬웠고,
상태 관리용 useState도 여러 개 생기다 보니 코드가 금방 복잡해졌습니다.
다수의 상태 관리 보일러 플레이트 +
모든 비동기 처리를 담당하는 useEffect, 높은 복잡도(비지니스, UI로직 한번에)
UI를 숨길 때마다 내부 상태가 초기화되는 문제 때문에,
스타일만으로 보이느냐/안 보이느냐를 제어하는 패턴을 썼던 적이 많았습니다.
( 렌더링 상태를 유지하고 스타일링으로 처리하다보면 컴포넌트가 살아있어 비용 리소스가 발생)
보이지 않는 렌더링 상태를 관리하고 불필요한 비용 리소스를 방지하는 기능으로 소개해주셨습니다.
의도하지 않은 Effect가 발생할 수 있다는 문제
호출될 때마다 최신 상태를 반영하여 호출하여 최신 상태를 안전하게 사용하게 해줄 수 있도록 개선되었더라구요.
memo를 이용해 최적화 시 자식 컴포넌트 리렌더링을 방지해오고 있었습니다. (순수 컴포넌트로 제작)
useMemo, useCallback 과 같은 훅들을 사용해서 불필요한 리렌더링, 계산을 막아오고 있었으나 고민의 요소가 많았고, 개발자가 매번 해당 훅들로 적용을 해야할 지 고민하는 시간 비용이 많이 든다는 문제가 있었습니다.
자동으로 메모이제이션을 내부에서 적용해서 자동으로 최적화를 진행해줍니다.
이 세션을 듣고 나서, React 19를 단순히 “새 기능이 많아졌다”가 아니라
“사용자로서 내가 겪었던 불편함을 React 팀이 어떻게 바라보고 개선해왔는지” 를 따라가 보는 버전처럼 느꼈어요.
새 버전이나 새 기능을 볼 때 “어떤 문제를 해결하고 싶어서 이렇게 만들었을까?” 를 먼저 질문해보는 연습을 해보면 좋을 것 같았어요.
마지막은 Teo의 고민상담소였습니다.
여기서 제가 제일 크게 가져온 키워드는
“말하기”와 “메타 능력”, 그리고 “기록”이었습니다.
AI 없이도 내가 직접 논리적으로 설명할 수 있는 사람이 되기 위해서는
보고, PR, 메신저, 문서 등에서 나를 드러내는 연습이 필요하다는 말이 크게 와 닿았습니다.
를 이해하고 넘어가야 진짜 내 경험이 된다는 이야기로 이해했습니다.
개발 진로에 대해 회의감이 드는 시기를 한 번씩은 겪게 되는 것 같습니다.
그럴 때,
“일을 잘하는 사람은 면접에서 티가 난다.” “취미로 즐기는 오타쿠력도 결국은 하나의 강점이 된다.”
라는 말도, 지금의 저에게 꽤 위로가 되는 문장이었습니다.
부정적인 생각은 긍정적인 생각의 5배 힘을 가진다.
모르는 것을 알게 되어서 감사해보고 개발세계가 신기하고 흥미로웠으면 좋겠다하셨습니다.
어떻게 생각했지? 어떻게 이렇게 했지?를 생각해볼 수 있도록 긍정적으로
내가 모르는 것들에 대해 긍정적으로 생각하며 학습하자싶었어요.
이번 TeoConf를 한 단어로 정리하자면,
저에게는 “기록(회고)”였습니다.
그래서 12월은, 26년이 오기 전에
올해 프로젝트들을 회고하고 글로 남기고 나만의 루틴을 조금씩 만들어보는
개인적인 “회고의 달”로 보내보려 합니다.
좋은 컨퍼런스 덕분에 2025년을 조금 더 개발자답게,
그리고 저 스스로에게 물어가며 회고하며 마무리할 수 있을 것 같아요.
읽어주셔서 감사합니다. 🙏