Krong Dev.
2025 회고

2025년 회고: 시작을 위한 기반을 다지는 해

멘토멘티, UMC, 프로젝트, AI, 여행 — 2025년 한 해를 돌아보며 회고 기록을 남깁니다.

2025년 회고: 시작을 위한 기반을 다지는 해

완벽보다 완료: 나의 첫 회고록의 목표는 “다 적기”가 아니라 “핵심이 남는 기록”이 목표


0. 한 문장 총평

  • 2025년을 한 문장으로:
    • “시작을 위한 기반을 다지는 해”

1. 올해의 키워드 5개

  • #멘토멘티 / #UMC / #프로젝트 / #AI / #여행
  • 키워드별 한 줄 설명:
    • 멘토멘티: 네이버웹툰 개발자 “이현석”님의 1일 멘토멘티 온라인 클래스.
    • UMC: 내 꿈을 개발자로 이끌어 주었던 연합 동아리 활동.
    • 프로젝트: 주니어 개발자로서 경험했던 프로젝트.
    • AI: 바이브 코딩 수업과 MCP로 만든 프로젝트.
    • 여행: 국내, 해외 여행 경험.

2. 기억나는 사건들

네이버 웹툰 멘토멘티 수업

  • 2025년 1월 네이버 멘토멘티 수업을 듣게 된 배경에 대해 떠올렸다.
    • 답을 찾고 싶어서 주변에도 물어보고, 유튜브도 찾아봤지만 막연했다. 그러다 교내 비교과 프로그램인 SW 직무 클래스를 발견했고, 일단 3개의 주제를 신청했다.
      • 네이버 웹툰 SI 개발자 이현석님
      • 롯데카드 정보보호 개발자 최경호님
      • 현대카드 데이터 사이언티스트 임소현님
    • 솔직히 “일일 클래스”라 가볍게 훑는 느낌도 있었고, 무엇보다 내가 기초가 부족해서 한 번에 이해되진 않았다.
    • 그런데 이현석님의 클래스에서 프론트엔드라는 분야를 처음 제대로 마주했고, 거기서부터 호기심이 커졌다. 평소 아무렇지 않게 쓰던 웹/앱 뒤에 복잡한 구조와 기술이 숨어 있다는 걸 체감했다. 지금 돌아보면, 화면 하나에도 API/상태/캐시/빌드/배포까지 연결되는 과정이 있었고, 그때 “도대체 어떤 기술을, 어떻게?”라는 질문이 생겼다.
스크린샷 2026-01-17 오후 12.48.28.png
  • 그 호기심이 이어져 2025년 1월 중순, HTML, CSS, JavaScript를 처음 접하게 되었다.
    • 유튜브 무료 강의를 찾아 독학을 시작했지만, 생각했던 것만큼 흥미가 지속되진 않았다. 실제 서비스처럼 높은 품질의 결과물을 만들고 싶었는데, 강의 흐름만 따라가서는 그 목표에 바로 닿기 어렵다고 느꼈고, 그래서 꾸준히 만들면서 배우는 방향을 찾게 됐다.
스크린샷 2026-01-17 오후 12.49.37.png
  • 그때 멘토멘티 수업에서 들었던 말이 떠올랐다. “대학교에서 동아리를 꼭 해보세요. 팀 프로젝트를 해보면 실력이 많이 늘 거예요.” 그래서 ‘에브리타임’에서 여러 동아리 공고를 찾아보다가, 가장 먼저 눈에 들어온 곳이 ‘UMC’였다.
  • 지금 돌아보면, 그 선택이 내가 ‘팀 기반으로 개발하는 방식(협업/기획/구현/리뷰)‘을 처음 제대로 배우게 된 전환점이었다. github을 사용해 팀 프로젝트에 기여할 수 있는 능력, 사람들과의 소통의 중요성 등을 깨달을 수 있었다.

UMC 활동(1)

  • 서류와 면접 과정을 거쳐 ‘UMC 8기 Web 챌린저’로 활동을 시작하였다.
스크린샷 2026-01-17 오후 1.15.58.png
  • UMC는 약 10주 동안 웹 기술 스택과 협업 도구(Notion, GitHub)를 기반으로 워크북을 수행하고, 그룹 스터디로 함께 학습을 밀어주는 구조였다. 워크북을 통해 TypeScript, TailwindCSS, (상태/서버 관리 라이브러리 등) 개념을 실습했고, 최종적으로 하나의 웹 사이트를 완성하는 것이 목표였다.

  • 다만 당시의 나는 정말 버거웠다. 모르는 개념이 많아 공식문서/블로그/AI 도구를 붙잡고 따라갔지만, 학교 수업과 교내 근로가 겹치면서 체력이 급격히 떨어졌고, 워크북은 점점 뒤로 밀렸다.

  • 워크북과 함께 유튜브 강의도 제공됐는데, 초반에 워크북/강의를 제작하신 매튜(김용민)님이 이런 말을 했다. “처음 하는 분들은 힘들 수 있어요. 지금 당장 이해가 안 되더라도, 나중에 다시 보겠다는 마음으로 여러 번 보다 보면 결국 이해될 거예요.” 그 말이 당시 내 상태를 정확히 짚어주는 것 같아서, 조급함이 줄었고 학습 동기를 다시 잡을 수 있었다.

  • 지금 돌아보면 문제는 “실력”보다 “개발 습관이 아직 없었다는 점이었다. 꾸준히 만들고 공유하는 재미, 기록에서 오는 성취감을 아직 경험하지 못했고, 만들고 싶은 것은 있어도 요구사항, 설계, 우선순위가 한꺼번에 몰리니 “어디서부터 시작하지?”가 늘 스트레스였다.

  • 그럼에도 한 가지는 분명히 알게 됐다. 나는 지식을 정리하고, 스터디 사람들과 공유하며 토론하는 걸 정말 좋아한다는 것. 개발 얘기를 나누는 시간이 가장 즐거웠고, 나에게 가장 큰 동기부여의 과정으로 자리 잡기 시작했다.

  • UMC 데모데이

    • 2025년 1학기 여름방학 데모데이 프로젝트로, PM/Design/FE/BE 협업팀에서 향수 추천 웹 서비스 ‘CHICCHIC’을 개발했다. 사용자의 취향을 ‘총 7문항 설문 → 답변한 내용에 AI가 분석하여 맞춤형 향수 추천 → 향수 상세 정보 확인’의 흐름이다.
    • 새로운 도전을 하고 싶었던 욕심에 프로젝트의 Frontend(Web) 파트 리더를 맡아 프로젝트 폴더 구조/라우팅 설계 기준을 정의해 초기 아키텍처를 잡았고, 매주 회의를 운영하며 의사결정과 회의록을 기록하였다.
스크린샷 2026-01-17 오후 5.37.11.png
스크린샷 2026-01-17 오후 5.32.25.png
스크린샷 2026-01-17 오후 5.32.40.png
  • 욕심이 과했던 탓일까? 첫 프로젝트를 마치면서, 특히 소통 방식에 대해 많이 생각하게 됐다.
  • 순탄할 줄 알았던 첫 프로젝트에서 몇 가지 병목이 생겼다.
    • 공용 컴포넌트/훅을 초기에 정하지 않아 중복 구현이 늘어났다.
    • 문제가 생기면 의사결정이 나에게 몰리면서 ‘병목(나를 거쳐야만 진행)‘이 발생했다.
    • 비대면 회의로 인해 집중이 흐트러져 결정이 늦어지고, 회의록의 중요도가 커졌다.
  • 기술보다 협업 규칙(공용 컴포넌트 기준/의사결정 라인/회의 운영)이 생산성을 좌우했다. 앞으로는 프로젝트 초반에 공용 컴포넌트/훅 정책 + 결정 권한 분산 + 회의 운영 룰을 먼저 합의하고 시작해야겠다고 다짐했다.

UMC 활동(2)

  • 2025년 2학기 ‘UMC 9기 Web 파트 리더’를 맡았다.
    • 2025년 2학기 UMC 9기 Web 파트 리더를 맡으면서, ‘가르치는 일’이 곧 ‘내가 확실히 아는 일’이라는 걸 처음 제대로 체감했다. 누군가에게 설명하려면, 대충 아는 수준이 아니라 왜 그렇게 동작하는지까지 명확해야 한다. 그 기준을 잡아준 사건이 김용민(매튜)님의 유튜브 라이브였다. “라이브러리를 많이 쓰는 게 좋을까요?”라는 질문에 대해 “왜 쓰려는지? 허점은 확인했는지?”라는 답을 들었을 때, 나는 바로 답하지 못했다. 그래서 적용하려던 ky를 실제로 파고들었고, 모듈 시스템(CJS/ESM) 같은 개념이 선택의 근거가 된다는 것도 연결해서 이해하게 됐다.
    • 이후엔 내가 정리한 내용을 수업/스터디 시간에 다시 설명하면서 확실히 내 것으로 만들었다. 돌아보면 ‘가르치기/설명하기’가 내가 가장 빠르게 배우는 방식이었다.
    • 학습 방법에 따른 평균 기억율을 나타내는 ‘국제 학습 연구소’의 자료에 따르면 ‘집단 토의, 연습(실습), 가르치기’와 같은 참여적 학습 방법이 큰 효과가 있다는 결과가 있다.
image.png
출처: 지식 디자이너 칼럼
  • 결과에 대한 불명확하다는 비판도 있지만, ‘수동적 학습방법’보다는 참여적 학습방법이 더 깊게 남는다는 방향성은 내 경험과 정확히 맞닿아 있었다. 파트 리더로서 내가 배운 내용을 다시 정리해 스터디에서 설명했을 때, 가장 이해가 잘 되었고, 이 활동이 내 학습 동기를 자극시켰다.

대외 네트워킹 활동(컨퍼런스/졸업 전시회 등)

  • 개발 실력을 쌓는 것만큼이나, 다른 개발자들과 네트워킹도 중요하다고 느꼈다. 네트워킹의 목적은 결국 서로의 인사이트를 주고받는 것이라고 생각한다. 나는 아직 실무 경험이 없어서, 실무를 겪어본 사람들의 실전 감각과 작은 팁들을 듣고 내 학습에 적용해보고 싶었다.
  • UMC 연합 컨퍼런스
    • 2025년 7월 UMC 연합 컨퍼런스에서 특히 민세림님과 허민님의 세션이 오래 기억에 남았다.
    • 민세림님은 이력서를 단순히 스펙을 나열하는 게 아니라, 지금까지 했던 일을 먼저 줄글로 풀어 쓰고, 그 위에 이력서의 컨셉을 잡은 뒤 서비스 소개/기획 이유/기술 스택/어필 포인트를 근거와 함께 정리하라는 흐름으로 설명했다. gitHub 링크나 MVP 배포 링크를 공개하고 Readme를 정리하며, 프로젝트는 여러 개를 얕게 하기보다 하나를 깊게 파라는 조언도 현실적으로 와닿았다.
    • 그래서 나는 앞으로 이력서를 ‘잘 쓰는 글’이 아니라, 내가 만든 것을 ‘증거(링크/README/배포)‘로 설득하는 문서로 만들고 싶다는 기준이 생겼다.
    • 허민님은 개발 실력의 핵심이 ‘문제 정의’에 있다고 말했고, 코드를 짜기 전에 구조를 파악하는 습관이 가장 중요하다는 점을 강조했다. 막연한 질문이 아니라 구체적인 질문을 통해 사고력을 키우고, 다양한 경험을 통해 복잡한 시스템을 이해해야 한다는 관점이 특히 인상 깊었다.
    • 돌아보면 프로젝트에서 막히는 순간은 실력이 부족해서라기보다, 문제 정의가 흐린 상태에서 구현부터 들어갔을 때 더 자주 생겼다. 다음에는 구현을 시작하기 전에 목표/제약/질문을 한 장으로 정리하고, 결과물은 MVP 배포와 Readme 정리까지 묶어서 마무리하는 습관을 더 확실히 만들고 싶다.
IMG_0659.JPG
UMC 연합 컨퍼런스 : 연사자 - 허민님
  • UMC 파트 컨퍼런스
    • 2025년 8월에 진행했던 UMC 파트 컨퍼런스에서 ‘역구조화(서비스를 관찰하고 구조를 추론하는 과정)‘가 중요하다고 들었는데, 막상 나는 그게 감이 잘 오지 않아서 김용민(매튜)님께 질문을 했다.
    • 그런데 내가 정말 하고 싶었던 질문은 “역구조화는 어떻게 하죠?”라기보다, “프론트엔드는 뭘 공부해야 하고, 어떤 방향으로 가야 하고, 방법은 뭐가 있나요?”였다. 하라는 역구조화는 안 하고 공부 방향 상담을 계속 해버렸지만, 이런 질문 덕분에 오히려 내 상황과 맞는 힌트를 많이 얻었다.
    • 컨퍼런스, 레포와 같은 자료를 참고하되, 결국은 버튼 컴포넌트 하나에 많은 기능을 담을 수 있는 작은 레벨부터 직접 구현해보고, 하나의 프로젝트를 깊게 완성하면서 쿠키/캐시/스토리지/이미지 정책 같은 ‘실제로 서비스가 굴러가는 지점’까지 끝까지 파보라는 조언이 특히 와닿았다.
    • 그래서 이번 컨퍼런스는 단순히 내용을 듣고 끝난 게 아니라, 내가 앞으로 프론트엔드를 공부하는 방식을 “관찰(문제정의)→구현→검증(배포)“으로 확장해야겠다는 기준을 세우게 해준 자리였다.
  • 교내 헤커톤(SKThon) 참여
    • 2025년 9월 첫 해커톤에 참여했다. 무박 2일로 경험했던 만큼 피곤했지만, 짜릿한 인상을 주었다. 아이디어를 구체화하는 요구사항 정의/문제 구조화 단계에서 전공 교수님에게 현실적인 피드백을 받을 수 있었던 경험이다.
    • 우리는 ‘장애인과 장애인 돌봄치료사 매칭 서비스’를 주제로 장애인이 장애 돌봄치료사를 선택하는 흐름으로 초기 기획을 잡았지만, 교수님은 어린이 돌봄 서비스 사례를 들어 “현실은 사용자가 원하는 보호사를 고르는 구조라기보다, 공급이 부족해 사용자가 신청하고 오래 대기하는 구조에 가깝다”는 점을 짚어주셨다. 특히 장애 돌봄 영역은 더 하려는 사람이 많지 않아 수요-공급의 비대칭이 심해질 수 있으니, 서비스의 매칭 구조(권한과 선택의 방향, 현실적 갑을 관계)를 다시 설계해보라는 조언이었고, 그 말이 기획을 ‘멋진 아이디어’에서 ‘현실적인 문제’로 재정렬하는 계기가 됐다.
    • 다만 무박 2일 일정으로 개발 시간이 절대적으로 부족한 상황에서 우리 팀은 사소한 디테일까지 챙기느라 MVP 기준으로 우선순위를 명확히 세우지 못했고, 그게 결과물 완성도에 직접 영향을 준다는 걸 뼈저리게 느꼈다. 그럼에도 극도로 피곤한 상태에서 핫식스를 다섯 캔, 녹차 2잔을 마셔가며 짧은 시간 동안 개발에만 몰입해 끝까지 밀어붙였던 경험은 잊을 수 없는 추억을 남겼다.
    • 나에게 다시 이런 기회가 온다면 초반에 문제 정의와 사용자 플로우를 더 탄탄히 다져 MVP를 먼저 확정하고 우선순위를 고정한 뒤 개발에 들어가겠다는 깨달음을 주었다.
IMG_0658 2.JPG
교내 해커톤 SKTHON - 프로젝트 : 두리
  • 졸업 전시회
    • 2025년 11월, 12월 각각 컴퓨터공학과, 소프트웨어학과의 졸업 전시회를 다녀왔다. 다른 사람의 프로젝트 결과물을 보는 것은 매우 흥미로웠고 소규모 네트워킹도 하면서 재미를 느낄 수 있었다.
    • 해당 내용은 링크드인 게시글에 자세하게 작성하였습니다. LinkedIn
image.png
  • TEOConf
    • TEOConf(테오콘)에 참여했을 때, 현직자 분들을 실제로 마주하는 순간부터 몸이 먼저 굳었다. 레크리에이션도 하고 네트워킹 시간도 있었지만, 긴장한 탓에 생각만큼 자연스럽게 말이 나오진 않았던 기억이 난다.
    • 그런데 그 “얼어있던 경험” 덕분에 오히려 확실하게 깨달은 게 생겼다. 내가 성장하려면 실력만 쌓는 게 아니라 시야를 넓히는 자리에 계속 나가야 한다는 것, 그리고 그 시야는 결국 사람을 통해 넓어진다는 것이다. ‘한입 커뮤니티’를 통해 참여하게 된 것 자체가 ‘경계를 넘는 첫 행동’이었고, 현장에서 만난 선배 개발자들과의 대화는 내가 얼마나 좁은 범위에서만 고민해왔는지 자각하게 만들었다.
    • 그래서 올해의 결론은 단순하다. 더 다양한 사람을 만나고 네트워킹을 이어가자. 다만 ‘연결’ 자체가 목표가 아니라, 내가 배우기만 하는 곳도 아니고 내가 주기만 하는 곳도 아닌, 서로의 인사이트를 주고받는 환경을 목표로 삼자. 이제는 ‘주기만 하는 자리’에서 벗어나, 나도 배움을 받고 동시에 내 경험과 고민을 의미 있게 나눌 수 있는 곳으로 방향을 잡아야 할 때라고 느꼈다.
    • 자세히 경험한 내용은 링크드인 게시글에 작성하였습니다.
image.png

여행

  • 여행에 다녀온 이야기는 소소하고 가볍게 작성해보려고 한다. 올해 다녀온 지역은 후쿠오카, 바르셀로나, 마드리드, 맨체스터였다.
  • 일본(후쿠오카)
    • 2025년 2월 일본 ‘후쿠오카’로 여행을 다녀왔다. 일본 여행은 총 3번째이지만, 2024년부터 지속적으로 네트워킹을 쌓아왔던 교내 공연 동아리 ‘SDR’의 부원들과의 우정여행으로는 처음이었다.
    • 하카타역 근처에 있는 캐널시티 하카타의 5층에는 ‘일본 라멘 잡지’에 등록되기 위해 치열한 경쟁 속에서 살아남은 라멘집들만 모아놓은 곳이 있다. 일본 라멘을 굉장히 좋아해서 아직까지도 기억에 남는 장소였다.
IMG_8352.HEIC
후쿠오카 - 하카타 라멘 스타디움
  • 너무 배가고파서 먹느라 사진 찍는 것을 깜빡하였다..
IMG_8362.HEIC
  • 2023년 10월에 오사카에 갔을 때는 아무 정보도 조사하지 않아서 지하철, 버스를 타고 다닐 때 항상 아날로그 기계로 티켓을 뽑는 방식으로 대중교통을 이용했었는데, 이번 여행에서는 같이 온 지인이 ‘PASMO’라는 앱을 사용해서 교통카드로 사용할 수 있는 방법을 알려주었다. 이로써 화폐 사용량을 매우 줄일 수 있어서 편리한 대중교통 생활을 즐겼다.

  • 그런데 같이온 6명 중에서 1명이 갤럭시를 사용중이었는데, PASMO 앱은 현지에서 생산된 갤럭시 제품이 아니면 호환이 안된다는 작은 이슈가 있었다.. 안타깝게도 그 친구는 이동하는 내내 동전소리가 요란하게 들렸다.

  • 일본의 조용조용한 거리, 애니메틱한 디자인과 분위기가 내 취향에 잘 맞았고, 가장 중요한 음식이 무엇보다 내 입맛에 맞았다. 또한 취미로 일본 애니메이션도 소소하게 즐기고 있어 좋은 경험이 되었다. 26년에도 일본 여행을 계획해 볼 예정이다.

  • 스페인(바르셀로나)

    • 2025년 12월 바르셀로나행 비행기에 탑승했다. 총 16시간의 비행시간이라 엉덩이가 아팠지만, 첫 유럽여행에 설레는 마음덕에 아프지 않았다(?).
    • 바르셀로나에서 가장 유명한 랜드마크인 안토니오 가우디의 ‘사그라다 파밀리아 성당’에 방문했다. 안에 들어가면 스테인드글라스로 들어오는 빛이 공간을 색으로 채워서 분위기가 확 달라진다. 전체적으로 가우디 특유의 곡선미랑 자연(숲/나무) 느낌의 양식이 느껴져서 건물이라기보다 하나의 ‘작품’ 같았다.
20251221_144558.JPEG
스페인 - 사그라다파밀리아
IMG_1975.HEIC
IMG_1972.HEIC
  • 스페인에서는 빠에야, 올리브오일로 만든 음식 등이 유명하다. 내가 가장 먼저 찾았던 것은 ‘하몽 이베리코’였다. 평소에 하몽을 즐겨 먹진 않고 편의점에서 사먹어본 경험이 있는 정도였지만, 당연하게도 너무 차이가 날 정도로 맛있었고 와인과의 페어링도 잘 어울렸다.
  • 바르셀로나의 근교에 있는 1시간 정도 거리에 ‘시체스’라는 소도시에도 방문했다. 바르셀로나 도시에서는 사람이 워낙 많아서 주변 광경을 제대로 보지 못했는데, 시체스에서는 사람이 적어서 분위기를 충분히 느낄 수 있었다.
IMG_2080
스페인 - 시체스의 거리
  • 스페인(마드리드)
    • 계절이 겨울이긴 하지만, 스페인은 전반적으로 따듯할 거라는 예상과는 달리, 바르셀로나는 그다지 따듯하지 않았다. 오히려 너무 추웠다. ‘바르셀로나는 해안 지역이라 해풍 때문에 쌀쌀한 거겠지?‘라는 생각도 잠시, 내륙 지역인 마드리드 공항에 도착하자마자 캐리어에서 점퍼를 꺼내입었다.
    • 마드리드에서는 유럽 3대 미술관인 ‘프라도 미술관’과 ‘피카소의 게르니카’, ‘살바도르 달리’의 작품들이 전시되어 있는 ‘레이나 소피아 미술관’으로 향했다. ‘ISIC’ 학생 카드를 등록해놓은 덕에 무료 입장이 가능했다.
    • 프라도 미술관에서는 중세시대 귀족들의 그림과 ‘프란시스코 고야’의 그리스로마 신화를 주제로한 그림들이 정말 많았다. 사실 어떤 그림인지 설명을 듣기 전까지 전혀 알지 못했다. 정말 어릴 때 만화책으로 그리스로마 신화를 접했었는데, 그때 좀 더 관심 갖고 읽어볼걸.. 회고 작성할걸..이라는 생각도 든다.
IMG_2613.HEIC
프라도 미술관
IMG_2623.HEIC
피카소 - 게르니카(Guernica)
  • 미술책에서 봤던 피카소는 색감이 더 화려한 작품이 많았는데, 레이나 소피아 미술관에서는 훨씬 어둡고 무거운 피카소를 본 느낌이었다. 특히 ‘게르니카’처럼 흑백 톤으로 전쟁의 공포를 다룬 작품이 인상 깊었다. 개인사도 영향을 줬을 것 같다는 생각이 들었는데, 정확히는 잘 모르겠다.
  • 달리의 단편 영화를 시청했는데, ‘이게 도대체 무슨 소리지?’ 싶은 영화였다. 갑자기 남자 손에 개미떼가 올라가더니 정신 차려보니 어떤 여자가 나오고 그 여자를 궁지로 몰아넣을때 피아노, 사람, 다른 물건들을 끌고 오고는.. 뭐 이런식이었다. 나중에 찾아봤을 때 달리가 일부로 엉터리 전개를 만들어 혼란을 주는 것이 단편 영화의 목적이라 하였다는 사실을 듣고, ‘천재와 엉터리는 한끗차이 일까?‘라는 생각에 잠기곤 했다.
IMG_2619.HEIC
살바도르 달리 - 루이스 부뉴엘의 초상(Retrato de Luis Buñuel)
  • 영국(맨체스터)
    • 유럽여행의 마지막 도시는 ‘맨체스터’였다. 여기 온 이유는 단 하나밖에 없다. ‘꿈의 극장’, ‘맨체스터 유나이티드의 Old Trafford 경기장’을 오기 위해서이다.
    • 이곳은 나의 버킷리스트 중 하나이다. ‘데이비드 배컴’을 좋아해서 팬심을 갖고 ‘맨체스터 유나이티드’를 응원하기 시작했는데, 정말 꿈만 같았다. 12월 30일 맨체스터 유나이티드 vs 울버햄튼 경기를 직관하는 특별한 경험을 하게됐다. 아쉽게 비겼지만, ‘성공을 위한 도약 준비’라 생각하기로 했다.
    • 경기 다음날에는 예약한 경기장 투어를 다녀왔는데, 경기장의 잔디, 선수들 라커룸을 코앞에서 볼 수 있어서 2025년 중 가장 행복하고 설렜던 경험이었다. ‘ManUtd Museum’을 갔을 때는 과거의 영광에 대해 직접 보진 못했지만 기록물로 남았던 그 장면을 다시 한 번 떠올릴 수 있었다.
IMG_2971.HEIC
(1998~1999) 맨체스터 유나이티드 EPL 역사상 최초 트레블
  • 내가 가장 좋아하는 ‘데이비드 베컴’ 선수를 박물관에서 접할 수 있었다.
IMG_2938.HEIC
IMG_2931.HEIC
IMG_2861.HEIC
꿈의 극장(Theatre of Dreams) - 올드 트래포드(Old Trafford)
IMG_2813.HEIC
최근 사진 보기.png
  • 놀라웠던 점은 영국 음식에 대한 혹평이 많아서 걱정을 하고 ‘피쉬앤칩스’를 먹었는데, 생각보다 너무 맛있어서 순식간에 다 먹어버린 적이 있다. 또 2층 버스가 처음 내 앞을 지나갔을 때 ‘관광버스가 되게 많네’라고 생각했던 것도 잠시 일반 버스임을 체감하고는 신기해서 사진부터 찍었던 생각이 난다.
  • 여행을 마치면서 유럽이 치안이 좋지 않고, 인종차별을 경험할 수도 있다는 우려가 있었는데, 다행히도 그런 사건들에 연루되지 않았다. 오히려 그 지역을 좋아하는 표정이 티가 났는지 현지 사람들이 친절하고 살갑게 대해주었다.
  • 가장 놀라웠던 것은 ‘사그라다 파밀리아’, ‘바르셀로나 대성당’, ‘톨레도 대성당’ 등과 같은 성당이 단순한 건축물이 아니라 예술작품으로 인식하게 만들었을 정도로 놀라운 건축물들이었다. 그저 성당을 볼때마다 계속 감탄만 나왔을 정도로 놀라웠다. 외국인들이 우리나라의 경복궁을 봤을 때 이런 느낌일까?
  • 이번 여행은 ‘유럽’이 아니라, 내가 세상을 보는 방식이 바뀐 여행이었다. 직접 보고 느끼니까, 선입견보다 경험이 훨씬 정확했다.

3. 실행 중심 회고 요약

  • Keep(유지): 꾸준한 개발 습관을 바탕으로 한 학습 회고를 작성한다.
  • Problem(개선): 기술(라이브러리/도구)을 “써보는 것”에 치우쳐, 왜/리스크/대안까지 정리하지 못해 질문에 막히는 순간이 있었다.
  • Try(시도): 적용하려던 기술을 단순 사용이 아니라 도입 이유/리스크(모듈/SSR 등) 관점으로 조사하고 정리했다.
  • Insight(깨달음): 지금 회고를 작성하면서 돌이켜보면, 나는 내가 직접 구현한 서비스를 배우고 학습하면서 개발 욕구를 채우는 것을 좋아한다. 하지만 무엇보다 프로젝트가 끝날때마다 주변 사람들에게 내가 만든 프로젝트를 직접 사용해보라면서 권했던 기억이 많이 나서 다른 사람이 내 서비스를 재밌게 사용하는 것을 보고 만족감과 뿌듯함을 느끼는 것 같다.
  • Emotion(월별/분기 감정 흐름 한 줄):
    • 1분기(1월~3월): 시작의 속도를 조절하는 침착함과 과감함
    • 2분기(4월~6월): 익숙하지 않은 환경의 낯섦과 극복하기 위한 열정
    • 3분기(7월~9월): 배움의 재미를 느끼고 과감한 시도를 시작하는 자신감
    • 4분기(10월~12월): 새로운 도전을 위한 설렘과 연말의 차분함

4. 요즘 생각들 : “스스로에게 던지는 질문들”

4-1) AI에 대한 생각

  • AI는 개발자들 사이뿐만 아니라 일상에서도 빠르고 밀접하게 자리 잡고 있다. 최근에 가장 큰 관심을 끌었던 ‘지브리 풍으로 프로필 이미지 만들어줘’라는 명령 하나만으로 지브리 분위기의 개인 프로필을 만들어주기도 하였다. 어릴 때부터 지브리 애니메이션을 좋아하던 사람의 입장으로써 몇 분, 몇 초만에 90%의 유사도를 보여줬던 AI에 크게 감탄하였다.
  • 내가 AI를 처음 써본 건 가볍게 재미로 했던 ‘사주’였다. 생년월일 몇 가지 정보만으로 순식간에 분석 결과가 나온다는 점이 신기했고, AI에 대한 첫인상도 꽤 긍정적이었다.
스크린샷 2026-01-19 오후 3.04.43.png
  • 이후에는 ‘알고리즘/딥러닝’ 같은 전공 과목을 공부할 때, 정리나 개념 확인을 위해 검색 및 보조 도구처럼 사용하기 시작했다.
  • 그러다 교내 비교과 프로그램에서 ‘바이브 코딩 교육’을 접하게 되었고, AI 활용 방법에 대한 인식이 크게 바뀌었다. 이 교육에서는 AI 에이전트와 대화하며 코드를 생성, 수정하는 흐름을 직접 체험했고, Streamlit/Replit로 간단한 ‘이색취미찾기’를 주제로 웹 사이트를 만들어 발표하였다. ‘AI가 개발 과정에 들어오는 방식’을 감으로 잡았다. 동시에 할루시네이션, RAG, MCP 같은 개념을 통해 ‘AI가 잘하는 것/약한 것’과 툴 연동, 지식 보강이 왜 중요한지도 배웠다.
KakaoTalk_Photo_2025-07-14-16-53-45 003.JPEG
교내 바이브코딩 교육 현장 - 코드트리
  • 교육에서 MCP와 바이브 코딩을 Streamlit/Replit로 직접 해보면서, 솔직히 “프론트엔드 개발자는 앞으로 정말 필요할까?”라는 회의감이 들기도 했다. 잘 짜여진 프롬프트만 던져도 화면과 코드가 빠르게 만들어지는 경험이 꽤 강렬했기 때문이다.
  • 그래서 교육을 진행하신 ‘코드트리(CodeTree)‘의 이승용 대표님께 현장에서 직접 이런 고민을 여쭤봤다. 대표님의 답은 의외로 단순했고 설득력이 있었다. ‘만드는 속도’는 빨라질 수 있어도, ‘서비스를 운영하면서 생기는 유지보수(버그, 요구사항 변경, 성능/보안, 사용자 피드백 반영)는 결국 개발자가 책임지고 다뤄야 한다’는 것. 그 말을 듣고 나서 내 고민은 ‘개발자의 역할이 무엇으로 재정의될까?‘로 조금 바뀌었다.
  • 그 이후로 유튜브에서 AI 관련 콘텐츠를 찾아보기 시작했다. 키워드는 단순했다. ‘대 AI 시대에 개발자가 살아남을 수 있을까?’ 현업 개발자분들이나 AI 전문가분들의 이야기를 들어보면 결론은 크게 다르지 않았다. ‘아무도 정확히 예측할 수는 없지만, 채용 방식이나 역할은 바뀔 수 있어도 개발자라는 직업이 완전히 사라지진 않을 것’이라는 공통적인 답변을 들을 수 있었다.
  • 또 최근 AWS CEO ‘맷 가먼(Matt Garman)‘이

‘장기적으로 성장하는 회사를 만들려면 AI로 개발자를 대체하는 일을 시작조차 해선 안 된다’ - 연합뉴스

라는 취지의 말을 했다는 이야기도 접했다. 이런 메시지들을 보면서, ‘대체’라는 프레임보다 역할의 변화와 AI 생태계 다양성에 더 초점을 맞춰야겠다는 생각이 들었다.

  • 그래서 나는 AI를 ‘해적 같은 동료’라고 생각하게 됐다. 내가 좋아하는 해적 장르(원피스, 캐리비안의 해적)에서는 서로 적이었다가도 어느 순간 같은 목표를 위해 손을 잡고, 더 큰 적을 물리치곤 한다.
  • AI도 비슷하다고 느꼈다. 처음엔 내 직업을 위협하는 ‘적’처럼 보이기도 했지만, 관점을 바꾸면 AI는 같은 문제를 더 빠르고 더 정확하게 풀기 위해 손잡을 수 있는 해적 동료다. 결국 중요한 건 ‘AI를 두려워하지 않는 것’이 아니라, AI를 통제 가능한 도구로 만들기 위한 사용법과 기준을 갖추는 것이라고 생각한다. 그 기준이 잡히면 시너지는 폭발할 것이다.
  • 개발자들이 AI를 만들었고, 지금은 누구나 AI를 쓸 수 있는 시대가 됐다. 나는 이걸 위협으로만 보진 않는다. 오히려 ‘누구나 쓸 수 있는 도구’가 된 만큼, 그 도구를 가장 잘 다루는 사람이 경쟁력을 갖는다고 생각한다. 결국 AI는 ‘일을 대신해주는 마법’이 아니라, 내가 더 좋은 선택을 하고 더 빨리 실험하도록 돕는 일잘하는 도구다. 그래서 나는 위험해 보이는 도구를 멀리하기보다, 기준을 세우고 근거를 문서화하면서 누구보다 능숙하게 다루는 쪽을 선택해보고자 한다.

4-2) 스스로에게 던지는 질문들

(인생/생활)

Q. 올해 감정 점수의 ‘고점/저점’은 언제였고, 이유는?
  • 정말 다행히도 2025년 전반적으로ㄹ 꾸준한 성장을 해왔다.
  • 저점(1월): ‘앞으로 뭘 해야 할지’가 선명하지 않아 불안이 컸다 → Bad/Afraid
  • 고점(12월): 다음 해 계획이 구체화되면 들었던 설렘/기대가 있었고, 여행으로 한 해를 잘 마무리해서 행복/안정감을 느꼈다. → Nervous/Comfort
Q. 올해 가장 고마웠던/도움을 많이 줬던 사람은?
  • 가장 고마웠던 사람은 ‘여자친구’다. 감정적으로 의지했던 순간이 정말 많았는데, 힘들 때 위로가 가장 큰 원동력이 되었다.
  • 가장 도움을 많이 줬던 사람은 김용민(매튜)님이다. UMC에 들어오고 나서 동기가 확 올라갔다고 느꼈는데, 그 중심에는 중앙교육국장으로서 맡은 일을 정말 끝까지 책임지고 해내는 김용민님의 태도가 있었다. 솔직히 “어떻게 저렇게까지 열심히 하지?” 싶을 정도로 무서웠지만, 그만큼 나도 배우고 싶고 따라가고 싶다는 마음이 생겼다.
  • 실제로 라이브에 참여했을 때 내가 던졌던 ‘라이브러리 선택’ 관련 질문에 성심성의껏 답변해주셨고, 단순히 ‘이게 좋다/나쁘다’가 아니라 “왜 쓰려는지?, 리스크는 확인했는지?”처럼 질문의 본질을 다시 생각해보게 해주셨다. 그 이후로는 기술을 고를 때도 그냥 써보는 걸 넘어서, 도입 근거를 스스로 정리하고 설명할 수 있어야 한다는 기준이 생겼다. 지금 생각해도 내 마음속 멘토로 자리 잡게 해준 사람이었다.

(커리어/학업)

Q. 올해 실력이 늘었다고 느낀 ‘근거 사건’은?
  • UMC 8기 데모데이 ‘CHICCHIC’ 프로젝트였다. 프론트엔드 파트장을 맡아 처음으로 아키텍처(폴더/라우팅 기준) 정리, 공통 구조 설계, 회의 운영/기록까지 프로젝트를 ‘개발 + 운영’ 관점에서 책임져 봤다.
  • 첫 프로젝트다 보니 욕심이 커서, 원래 분담할 수 있는 일도 혼자 끌어안는 구간이 있었다. 그때는 ‘배운다’는 명목으로 버텼지만, 결과적으로 병목이 생기고 지속 가능하지 않다는 걸 몸으로 배웠다.
  • 그래서 이 경험을 통해 ‘리더의 역할은 더 많이 하는 것이 아니라, 업무를 분해하고 기준을 공유해 팀이 함께 움직이게 만드는 것’이라는 방향성을 깨달았다. 이 사건은 단순히 구현 실력뿐 아니라, 프로젝트를 운영하는 실력이 늘었다고 느낀 가장 큰 계기였다.
Q. 내가 반복해서 막힌 병목은 무엇이었나?
  • 내가 반복해서 막힌 병목은 기술 자체보다, ‘내가 지금 하고 있는 선택과 방향이 맞나?‘에 대한 의심이었다. 모순적이게도 확신이 없어서 의심이 생겼지만, 그 의심은 학습을 촉발하는 트리거가 됐다. 의심이 들 때마다 근거를 찾고(문서/레퍼런스/비교), 작은 단위로 적용해보고(프로젝트에 실험), 결과를 통해 검증하는 과정을 반복하면서, 결국 그 과정이 지식 → 기준 → 확신으로 이어졌다.
  • 즉 병목은 ‘의심’이었지만, 그 병목을 통과하는 방식이 쌓이면서 나만의 판단 기준이 만들어졌다. 그래서 올해의 반복 패턴은 ‘의심 → 학습 → 적용 → 확신’이었고, 내 성장의 엔진은 ‘의심을 없애는 것’이 아니라 의심을 생산적으로 처리하는 방식을 갖추는 것이었다.
Q. 내년 1년을 레벨업시키려면 환경을 어떻게 바꿔야 하나?
  • 내년은 ‘꾸준함 습관’의 해로 만들고 싶다. 한 번의 몰입이나 단기 성과보다, 지속적인 학습/회고/경험이 끊기지 않도록 환경을 설계하는 게 목표다.
  • 꾸준함을 만드는 환경 변화
    • ‘매일/매주’ 반복되는 최소 루틴을 고정한다.
      • 학습(작게), 회고(짧게), 적용(작업 1개)처럼 끊기지 않는 최소 단위로 설계한다.
    • 의심이 생겼을 때 감정적으로 머무르지 않고, 바로 다음 행동으로 넘어가게 만든다.
      • 의심 → 근거 찾기 → 작은 실험 → 기록을 루틴으로 고정한다.
    • 경험을 지식으로 바꾸는 장치를 둔다.
      • 회고를 ‘느낌’이 아니라 다음 행동/기준/체크리스트로 남겨서 누적되게 한다.

5. 올해의 “나만의 기준/원칙”

습관이 실력을 만든다: GitHub 하루 1커밋

  • 원칙: 무엇이 됐든 매일 1커밋으로 개발 습관을 유지한다.
  • 왜(근거 사건 1개): 워크북/강의가 밀리기 시작하면 흐름이 끊기고 동기가 떨어졌던 경험이 있었다. 반대로 작은 작업이라도 “오늘 한 게 남는 날”은 다시 탄력이 붙었다.
  • 앞으로의 적용 규칙(내 행동):
    1. 커밋은 크기보다 연속성이 우선(문서/리팩터/테스트/버그픽스도 인정).
    2. 커밋 메시지는 “무엇을 남겼는지”가 보이게 최소 규칙 유지(예: docs:, refactor:, fix:).
    3. 바쁜 날은 15분만이라도 “내일의 나”를 돕는 커밋 1개로 마감.

팀 프로젝트는 친해지는 게 생산성이다

  • 원칙: 프로젝트 초반에 팀원들과 의도적으로 친해진다(관계 형성이 곧 소통 비용을 줄인다).
  • 왜?(근거 사건 1개): 첫 팀 프로젝트에서 비대면 회의 집중 문제, 연락/공유의 어색함, 결정 지연 같은 소통 문제가 생산성에 직접 영향을 줬다.
  • 앞으로의 적용 규칙(내 행동):
    1. 비대면 회의보다는 대면회의를 우선적으로 진행한다.
    2. 각자 역할/진행 상황을 편하게 공유할 수 있도록 짧은 데일리/주간 공유 규칙을 만든다.
    3. 문제가 생기면 “지적”이 아니라 상황 공유 → 도움 요청 → 다음 액션 순서로 말한다.

‘완주’보다 ‘배포 먼저’ → 일단 해보고 개선

  • 원칙: 배움의 기준은 ‘완료’가 아니라 배포/데모 가능한 결과물이다.
  • 왜(근거 사건 1개): 강의 흐름만 따라갈 때는 “내가 원하는 실서비스 수준”과 간극이 커서 흥미가 떨어졌다. 반대로 프로젝트에서 직접 만들고 보여줄 때 동기가 유지됐다.
  • 앞으로의 적용 규칙(내 행동):
    1. 사이드 프로젝트는 1~2주 안에 MVP 배포를 목표로 잡는다(작아도 공개).
    2. 기능 추가보다 먼저 ‘사용자 흐름 완성(접속→사용→결과)‘을 만든다.
    3. 배포 후 피드백을 기준으로 리팩터/확장 순서를 정한다.

도입은 ‘감/유행’이 아니라 근거: 언어/프레임워크/라이브러리 선택 문서화

  • 원칙: 새로운 언어/프레임워크/라이브러리/도구는 “유명해서”가 아니라 도입 근거를 분석하고 문서화한 뒤 결정한다.
  • 왜(근거 사건 1개): 매튜님 라이브에서 “왜 쓰려는지/허점은 확인했는지” 질문을 받았을 때 답을 못했고, 그 뒤에 ky를 파고들며 ‘선택의 근거’가 얼마나 중요한지 체감했다.
  • 앞으로의 적용 규칙(내 행동):
    1. 도입 전 1페이지 문서 작성: Why(목표)/Trade-off(리스크)/Alternatives(대안).
    2. 프로젝트 맥락(렌더방식/번들/팀 숙련도/유지보수)까지 포함해 판단한다.
    3. 결정 후에도 “왜 이걸 썼는지”를 팀이 공유하도록 문서를 남긴다.

6. 2026 액션 플랜

‘다짐’이 아니라 실행 가능한 형태로만 남기기

6-1) 2026 목표 3개

  • 목표1: 나만의 사이트 만들기 -> 개인 블로그
  • 목표2: 부트캠프/현업자 동아리 들어가기 -> kt cloud TECHUP frontend 2nd
  • 목표3: 실무 인턴 활동

6-2) 2026에 “시도할 것”

  • 실험1: 그때그때 적는 회고와 매달 작성하는 ‘Monthly 회고’를 작성하는 습관을 들인다. 또한 회고 스터디를 만들어 서로 작성한 회고를 피드백하고 검토하여 발전된 회고 문화를 만들고 싶다.
  • 실험2: 나만의 사이트에서 Three.js를 활용한 애니메틱 배경을 만들어 보고 싶다. Zustand 메인 페이지 화면에서 너무 큰 감동을 받았다.. Three.js와 3D렌더링(블렌더)에 대해 공부하고 싶다.

6-3) 2026에 “안 할 것”

  • 안 할 것1: 처음이라는 두려움에 시도 조차 하지 않는 마음. 그게 잘 되던, 잘 되지 않던 우선 부딪히고 시도해보자.
  • 안 할 것2: 이유, 목적 없는 학습을 하지 말자. 유행에 끌려가기만 하는 것 보다, 유행이더라도 이유를 찾고 목적을 이룰 수 있는 학습을 실천하자.

7. 마무리

  • 올해의 나에게 한 문장: 시작이 어려운거야. 시작했으니 됐다.
  • 내년의 나에게 한 문장: 앞으로도 정진하여 이루고자 하는 것들을 꼭 이루자.