안녕하세요, 프론트엔드 개발자 정소현입니다.
오늘은 12/6에 열린 TEOConf 2025 Track C 세션 3개를 듣고, 실무에 바로 가져갈 수 있는 인사이트를 중심으로 정리해봤습니다.

• 세션 요약이 궁금하신 분들은 바로 아래(세션 정리)를,
• 개인 후기가 궁금하신 분들은 👇 아래로 스크롤(느낀 점 & 후기) 해주세요!

---

📝 세션정리

오늘 들은 세션

• (기술) 혼자서도 잘해요? — TanStack Query 디버깅 여정 (재빙)
• (사람/운영) 아직 2년차인데 팀장이 되어버렸다 (오원)
• (제품/시스템) 3주간의 디자인 시스템 배포 삽질기 (한상욱)

---

오늘의 키워드 3개

• 🧠 stale-while-revalidate: “일단 보여주고(캐시), 뒤에서 갱신” 철학을 이해하고 쓰기
• 🤝 팀으로 디버깅하기: 혼자 끙끙보다 “빠르게 해결”이 더 중요할 때가 있다
• 🚀 배포는 기술 + 운영: 빌드/타입/CSS/권한/자동화까지… 결국 제품처럼 다뤄야 한다

---

🌟 1. 혼자서도 잘해요? — TanStack Query 디버깅 여정 (재빙)

1) 버그와의 조우: ‘0.5초’가 UX를 깨는 순간

• 🐞 유저 정보 수정 직후 약 0.5초 동안 수정 전 데이터가 노출
• 😵 로딩 UI가 없어 “어? 수정 안 된 건가?” 싶은 순간 발생
• 🧩 스택: tRPC + TanStack Query, useSuspenseQuery

처음 가설은 단순했다.

“오래된 캐시 때문 아닐까?”

---

2) 첫 번째 시행착오: gcTime의 미스터리

• gcTime: 비활성 쿼리 데이터가 캐시에 남아있는 시간 (기본 5분)
• gcTime = 0으로 바꿔서 “즉시 삭제 → 항상 최신”을 기대
• ✅ 대부분 해결
• ❗ 하지만 간헐적으로 동일 증상이 남음

---

3) 전환점: useSuspenseQuery 최소 gcTime 이슈

• useSuspenseQuery는 최소 gcTime 1000ms 이상이 보장되는 동작이 있음
• gcTime이 너무 짧고 + queryFn이 동기적으로 동작하면 무한 루프 위험도 존재
• 결과적으로 suspense 쿼리에서 invalidate 타이밍이 어긋나는 느낌이 남을 수 있음

---

4) 두 번째 가설: resetQueries면 되지 않을까?

• resetQueries로 캐시를 초기화하면 동작은 깔끔 ✅
• 다만 로딩 스피너가 무조건 보임 ❗

여기서 고민:

“매번 기존 데이터를 버리고 스피너를 보여주는 게 정답인가?”

---

5) 핵심 정리: TanStack Query는 stale-while-revalidate가 기본

• TanStack Query는 본질적으로
  기존 데이터(stale)를 먼저 보여주고 → 비동기로 새 데이터를 받아 갱신(revalidate) 하는 흐름
• 즉, “잠깐 이전 데이터가 보이는 것”은 버그라기보다 기본 철학에 더 가까움

그래서 진짜 질문은 이거였다.

• “왜 하필 수정 직후에 더 도드라지게 보였나?”
• “내 흐름에서 업데이트가 끊기는 지점이 어디였나?”

---

6) 팀 도움 요청이 해결로 이어진 이유: ‘갱신 흐름’이 끊겼다

• tRPC 설정에 abortOnUnmount 옵션이 있었고
• invalidateQueries()는 Promise를 반환하며 비동기로 refetch가 진행됨

실제 흐름:

1. submit
2. invalidateQueries() 호출 (비동기)
3. refetch 완료 전에 router.push() 실행
4. 이동하면서 컴포넌트 언마운트
5. abortOnUnmount로 요청 취소
6. 결과적으로 갱신이 끊겨 “잠깐 이전 데이터” / “업데이트 누락”처럼 보임

✅ 해결

• onSuccess에서 await invalidateQueries()로 순서 보장
• refetch 완료 후 이동 → ✅ 해결

---

1번 세션 takeaway

• 디버깅은 “설정값 맞추기”가 아니라 흐름(비동기/언마운트/취소)을 보장하는 일
• 그리고 이 흐름은 혼자보다 팀과 공유할 때 더 빨리 보인다

기술 문제를 푸는 속도는 팀의 문화/규칙(운영 흐름)에 의해 결정된다.

---

🌟 2. 아직 2년차인데 팀장이 되어버렸다 (오원)

1) 현업: 이상과 현실

• ⏳ 일정이 기술보다 먼저 오는 순간이 많다
• 🧾 개발 외 업무(회의/보고/조율)가 생각보다 크게 시간을 잡아먹는다
• 📚 온보딩/인수인계가 없으면 팀 생산성이 계속 깎인다

---

2) 인상 깊었던 메시지

“좋은 팀에 가는 것보다, 좋은 팀을 만드는 게 낭만적이지 않을까?”

---

3) 팀을 바꾸는 건 ‘문제를 다시 정의하는 것’

겉으로 보이는 문제:

• 반복 이슈 → 효율 저하
• 도메인지식 부족 → 일정 지연
• 스타일 제각각 → 도입 부담
• PR 밀림, 문서화는 일부만 함

실제 원인:

• “지킬 시간이 없고”
• “갑자기 도입해서 익숙하지 않다”

---

4) 문화는 추상 말고 ‘규칙’으로 만든다

• 🗓️ 목요일은 도메인 파악
• 🧹 불필요한 보고서 제거
• ✅ 코드리뷰 없으면 머지 불가
• 🔁 로테이션 업무 분배 + 티켓팅
• 🚚 트럭 팩터 2: 누가 빠져도 최소 한 명은 이어받을 수 있게

---

2번 세션 takeaway

• 팀을 바꾸는 일은 “분위기”가 아니라 지킬 수 있는 규칙과 시간, 운영을 설계하는 일
• 이런 구조가 있어야 1번 같은 디버깅도 적절한 타이밍에 공유되고, 빠르게 해결된다

그리고 운영의 끝판왕이 3번 세션:
배포 역시 기술이 아니라 운영이며, 제품처럼 굴러가야 한다.

---

✅ 체크리스트: 팀 문화/운영을 바꾸고 싶을 때

• “문제”를 행동/규칙으로 번역했나? (예: “리뷰 필요” → “리뷰 없으면 머지 불가”)
• 규칙을 지킬 수 있게 시간/리소스를 확보했나?
• 로테이션/티켓팅으로 지식이 특정인에 잠기지 않게 했나?
• “도입”이 아니라 “정착”을 위해 반복 주기(요일/리추얼)를 만들었나?

---

🌟 3. 3주간의 디자인 시스템 배포 삽질기 (한상욱)

1번이 “데이터 갱신 흐름”, 2번이 “팀 운영 흐름”이었다면,
3번은 “배포/운영 흐름”을 제품처럼 만드는 이야기였다.

1) 목표와 결정

• 디자인 시스템이 없어 생산성이 흔들리는 상황
• 다른 팀도 쓰게 하려면? → npm 배포 선택

---

2) 겪은 핵심 이슈들(요약)

• 🧱 빌드 도구 선택: 앱(Vite) vs 라이브러리(tsup)
• 🗺️ 경로/alias 문제: styled-system, @styles 등
• 🧩 SVG 처리: SVGR
• 🧾 이중 빌드: tsup(번들) + tsc(타입)로 복잡성 증가

---

3) 설치 테스트는 pnpm pack으로: “소비자 환경”에서 검증

• npm publish를 반복하지 않고
  로컬에서 패키징 → 실제 설치 흐름으로 검증
• 장점: 배포 사이클(버전업/퍼블리시)을 매번 돌리지 않아도 됨
• 목적: “진짜로 소비자가 설치했을 때”와 같은 환경에서 확인

---

4) 설치 후 CSS가 안 먹는 문제

• 컴포넌트는 렌더링되는데
• 버튼/카드가 Mantine 기본 스타일처럼 보이고
• 전역 CSS class가 없는 느낌 → 스타일이 적용되지 않음

원인

• Panda CSS 스타일 시트 생성/전달 문제

---

5) 타협과 해결 시도

• 현재 모든 것을 다 깔끔하게 해결할 수 없으니 실무에서 사용 가능한 선에서 타협하며 해결

---

6) 배포 자동화의 장벽

• GitHub Actions로 버전 올라가면 자동 배포 설정
• 403 에러(권한), Actions 재귀 문제 등 운영 이슈까지 등장

---

3번 세션 takeaway

• 정적 자원(CSS/SVG)은 꼭 따로 관리하는 전략이 필요하다
• 의사결정에서 중요한 건 정답이 아니라 “왜 그렇게 결정했는가”다
  → 배포는 개발이 아니라 제품 운영이다

---

세션 3개를 관통한 결론 — “흐름을 보장하는 설계”

• 디버깅은 결국 흐름(비동기/언마운트/취소)을 이해하는 일이고,
• 팀 리드는 문화와 운영을 설계하는 일이고,
• 배포는 개발이 아니라 제품처럼 다뤄야 하는 일이었다.

---

☘️ 오늘의 후기 & 느낀 점

☝️ 세션 후기

1) 1번 세션을 들으며: “나는 이 상황에서 어떻게 했을까?”

TanStack Query 디버깅 여정을 들으면서 공감이 컸는데, 동시에 이런 고민도 들었다.

• 발표에서는 onSuccess에서 await invalidateQueries()로 순서를 보장했지만,
• TanStack Query 최신 버전에서는 getQuery 쪽에서 onSuccess 패턴을 더 이상 지원하지 않는 흐름도 있다고 알고있고
  “이 패턴은 디버깅 난이도를 올리진 않을까?”라는 생각이 들었다.

그래서 세션 내내 이런 질문들이 머릿속에 남았다.

• 나라면 어떤 구조로 순서를 더 안전하게 보장했을까?
• 라우팅/언마운트/요청취소가 섞인 흐름에서 내가 디버깅하기 쉬운 형태는 뭘까?

이 세션은 내게 ‘질문의 골든타임의 중요성’을 다시 떠올리게 해줬다.

---

2) 2번 세션을 들으며: “좋은 팀을 만드는 사람이 되고 싶다”

가장 깊게 남은 문장은 이거였다.

“좋은 팀에 가는 것보다, 내가 있는 팀을 좋은 팀으로 만드는 게 낭만적이지 않을까요?”

나는 이 말에 크게 공감했다.
그리고 나도 팀 문화에 긍정적인 영향을 주는 사람이 되고 싶다고 생각하게 됐다.

나는 현재 회사에서

• CodeRabbit 활용,
• 리뷰 문화,
• 의견 공유,
• 새로운 기술 도입을 팀원들과 함께 논의하고 결정하는 분위기

같은 좋은 환경을 경험하고 있다고 느낀다.
저연차로서 사수분들께 인사이트를 얻으며 성장하고 있다는 점이 감사했다.

그래서 내 고민도 더 구체적으로 변했다.

• 이 문화를 지키고 신뢰를 쌓기 위해 나는 어떻게 행동해야 할까?
• 사수분들에게도 “함께 일하기 좋았다”는 경험을 드리려면
  나는 어떤 방식으로 기여할 수 있을까?

---

3) 3번 세션을 들으며: “타협의 기준은 어디에 둘까?”

디자인 시스템 배포 이야기를 들으며 가장 현실적으로 느낀 건 이거였다.

• 예상 공수보다 작업 기간이 길어졌을 때,
• 나는 어디서 타협하고, 어디서 끝까지 파야 할까?

빌드/타입/CSS/권한/자동화가 엮이는 순간
기술 문제가 아니라 “운영/제품화”로 넘어가는데,
그때는 정답보다 결정의 근거가 더 중요해 보였다.

---

✌️ 테오콘 후기

세션이 끝난 뒤 팀별로 세션의 내용과 연관된 주제로 네트워킹 시간을 가졌는데,
다른 컨퍼런스와는 다르게 새로운 분들과 나와 다른 환경에서 일하는 분들과 이야기를 나눌 수 있었다.

• 같은 세션을 들어도 조직/상황에 따라 해석이 달랐고
• 그 차이를 듣는 과정이 굉장히 의미 있었다

---

🎁 소소한 여담: 선물 증정식 & 받은 책

짧게 선물 증정식이 있었고,
나는 「마법의 고민해결책」을 받았다.

앞으로 회사에서 힘들 때마다 펼쳐볼 것 같다 ㅋㅋ

---

🔥 테오님의 Q&A에서 특히 남은 이야기 (AI 시대의 개발자)

질문 중 “AI가 발전하는 시대에 개발자의 지속가능성”이 정말 많았는데,
테오님 답변에서 기억에 남는 포인트는 이거였다.

• AI보다 내가 잘할 수 있는 영역을 찾고, 나머지는 소비하는 관점으로 경험해보기
• 사이드 프로젝트도 좋지만, 그에 앞서 현업에서 내가 잘할 수 있는 걸 찾기
• “기술을 잘하는 것”과 “업무를 잘하는 것”을 구분하고
  결국 업무를 잘하는 사람이 되도록 노력하자

---

💌 내가 생각하는 프론트엔드와 앞으로의 방향

나는 잘하는 프론트엔드를 이렇게 생각한다.

• 서로 다른 직군(기획/디자인/백엔드)을 연결하고
• 사용자와 서비스를 연결해 숨을 불어주는 역할

그래서 이번 컨퍼런스를 통해
기술뿐 아니라 소프트 스킬적인 부분도 더 고민하게 됐다.

• 내가 도움을 요청할 때도,
• 누군가 내게 요청할 때도,
  그 요청이 “부담”이 아니라
  팀이 더 나은 방향으로 가는 디딤돌처럼 여겨지면 좋겠다.

---

👍 마무리

오늘 테오콘은 나도 자주 하던 고민들(질문의 골든타임, 시행착오 공유 문화, AI 개발자 대체?)이
나보다 연차가 높은 분들도 함께 고민하는 주제라는 걸 확인하게 해줬다.

빠르게 변하는 프론트엔드 생태계에서
내가 앞으로 어떻게 성장해야 할지 조금 더 선명한 방향성를 얻은 컨퍼런스였다.