2025년 회고
벌써 2025년이 지나고 2026년이라니! 참 얼떨떨하다. 다양한 이벤트가 있어서 더 빠르게 느껴졌구나 싶다.
개발자
2025년에는 꽤 다양한 일을 했고 나의 강점을 최대한 살려 업무를 진행했다고 느끼는 중이다. PoC 프로젝트도 많았고, 다른 조직과의 협업도 많았고, 어쩌다보니 TF 발령이 되어 글로벌 서비스를 만드는 작업도 했었다. 무엇보다 기술공유를 꾸준히 했는데 이게 꽤 재밌었고 만족스러웠다.
(1) nBilly
원래 메인 업무가 nBilly 였는데, 올해는 nBilly에 기여한 부분이 많지 않았고 그게 무척 아쉽다. 연초에 세웠던 목표는 다음과 같다.
수행하는 역할
- 체계적인 기술 관리: 기술부채 관리, 트러블슈팅 정리, 팀원 역량 파악을 통합적으로 관리
- 효과적인 기술 전파: 내부 지식 공유와 외부 기술 마케팅을 통한 팀의 기술력 브랜딩
- 개인과 팀의 동반 성장: 팀원 지원과 개인의 아키텍트 역량 개발을 균형 있게 추구
미션
- 팀의 기술적 자산을 체계적으로 관리하고 지속적인 개선을 주도하는 기술회고 문화를 정착시킨다.
- 팀의 기술력을 대내외에 효과적으로 전파하고 기술 브랜딩을 강화한다
- 팀의 기술 멘토이자 아키텍트로서 성장하여 기술적 의사결정 역량을 강화한다.
이러한 활동을 하기 위해서는 nBilly 라는 구심점이 필요했을 것 같은데, 다양한 이해관계로 인하여 nBilly와 팀이 점점 멀어지다보니 우리 팀의 정체성을 만들고 전파하는 과정이 무척 어려웠다. 그런데 반대로 생각해보면, 구심점이 있어도 그 역할과 목표를 제대로 수행했을까? 솔직히 자신이 없다. 어쨌든 어떤 일들을 했는지 갈무리해보자.
1) 데이터 연동 자동화 PoC
nBilly에는 아직 API를 연동하는 기능이 없었다 (사실 지금도 없다). 더 정확히는 API는 호출할 수 있으나, 이 결과를 UI에 매핑하는 기능이 없었고 이를 "잘" 만들기 위한 시도를 많이 했었다.
Figma의 AutoLayout으로 구성된 UI를 nBilly로 가져온다 (Figma To nBilly)
이를 위해 2024년에 FlexLayout 이라는 개체를 하나 만드는 작업을 했다. 기능이 많이 복잡해서 힘들었고 버그도 많았다.
사용할 API에 대한 정보를 하나 등록한다. Postman 같은게 내장되어있는 모습이다.
UI와 API 호출 결과를 매핑하기 위한 UX/UI를 구성하여 제공한다.
- 현재 클릭한 요소가 어떤 개체인지 알아야 한다.
- 현재 개체에 매핑할 데이터를 연계한다.
사실 단순하게 생각하면 굉장히 쉬운데, 문제는 "반복"이 들어가는 순간이다. 반복구조를 추상화하고 매핑하는 과정이 제일 어려웠다.
가령, API 응답을 $input 이라고 정의했을 때, $input.data 가 배열일 경우, $input.data.$.title 처럼 사용하면 순차적으로 배열에 매핑이 되는 함수를 하나 만들어야 했다.
그런데 문제는 $input말고 UI에 있는데, UI의 반복구조를 어떻게 알 수 있을지가 관건이다. 이 패턴을 찾아서 정의하고 일관성 있는 형식으로 관리를 해야 되는데 그게 쉽지 않았다. (거의 1년 전이라 기억도 가물가물…)
그리고 1depth 까지는 그러려니 하는데, 2depth가 된다면? UI의 중첩구조와 데이터의 중첩구조를 함께 알아야하고 이를 매핑해야 하는데 그게 정말 쉽지 않았다. 이를 AI가 매핑해주는 기능도 추가했는데, 정확도가 높지 않았었다. AI가 데이터 구조 + nBilly의 모델 구조 + 현재 만들어진 개체의 구조 등을 알아야 하는데, 사용해야 하는 토큰도 많았고 속도도 느렸고 AI가 제공하는 내용이 정확도에 따라 승인하거나 반려하는 UI를 제공하는 등 신경써야 할 게 몇 배는 많아졌다. 뜬금없지만 AI 연동을 하다보면 자연스럽게 높은 수준의 엔지니어링이 필요함을 인지하게 된다.
이 PoC를 하는데 거의 2개월을 투자했는데 결국 기능은 도입하지 않는 것으로 합의 되었다. 어거지로 만들어서 넣기보단 높은 완성도를 추구하는 네이버의 색채 때문이랄까..? (지극히 주관적인 생각이다)
무엇보다 QA를 통과할 자신이 없었다. 만드는 게 2개월이었는데 QA도 2개월 혹은 그 이상 걸릴 것 같았다.
이 때 무척 고민이 많이 되었다. 높은 완성도는 결국 사용자를 위함인데, 완성도가 낮더라도 어쨌든 필요한 기능을 제공하는게 좋지 않을까에 대한…?
"일단 빠르게 사용자에게 제공하고 빠르게 피드백을 받는게 더 좋지 않을까?" 라는 고민을 무척 많이 하게 되었고 지금도 하는 중이다.
2) 통합프로모션 SDK 개발
앞에서 언급한 데이터 연동 PoC 가 마무리 된 후 "네이버 쇼핑의 프로모션 페이지를 제작하는 CMS에 nBilly를 SDK 방식으로 꽂아 넣으면 어떨까?" 라는 의견이 있었고, 양쪽 조직의 합의를 통하여 일이 진행되었다.
nBilly 자체를 하나의 "개체"로 만들어서 관리하는 방식으로 제공했다.
가령, nBilly에도 Block, Container, Layout 등의 개체들이 존재한다. Block은 ButtonBlock, ImageBlock 등 특정 UI의 형태를 제공하는 최소 단위의 개체인데, nBilly의 모델 구조를 하나의 개체로 만들어서 제공하는 것이다.
빌더 내부에 빌더가 있는 모습이랄까? (비슷한 방법으로, nBilly 내부에 nBilly를 꽂아넣을 수도 있다)
이 미션을 진행할 때 두 가지 측면의 어려움이 있었다.
기술적인 어려움
- nBilly를 SDK 형태로 사용하도록 제공한적이 없다보니, 번들링에 최적화에 대한 고민이 무척 많았다. nBilly의 기능이 굉장히 많은데 필요한 부분만 가져와서 조립하는 방식으로 만들어야 했다.
- 한 페이지에 하나의 빌더와 렌더러가 있다고 가정하고 만들었는데, 한 페이지에 여러 개의 빌더와 렌더러가 존재할 수 있기 때문에 기본적인 구조를 뜯어고쳐야했다.
- 팀 내에서 "리액트 19버전이 나왔고, 19버전의 기능을 사용해보자" 라는 요구가 있어서 nBilly에 적용한 다음에 패키지로 만든 다음 프로모션 페이지에 붙였더니 리액트 버전 호환이 안 되서 롤백했다. 즉, 팀의 기술부채가 외부에 의존이 되는 상태가 될 수 있다.
- SSR을 할 때 nBilly 패키지를 사용하는 측의 node 버전과 nextjs 버전에 따라 동작이 달라지는 부분이 있었고, 이를 테스트하고 검증하는 플레이그라운드를 다양하게 만들어야 했다.
- 이미지 업로드, 동영상 업로드 등의 기능은 nBilly 패키지를 사용하는 측에서 연동해줘야 하는 구간이 있고 마찬가지로 이를 테스트하는 과정이 꽤 까다로웠다.
- 기존에 트리쉐이킹을 하기 힘든 구조로 만들어진 상태라서 불필요한 패키지가 계속 말려들어가는 현상이 있었는데 이는 완전히 해소하기가 어려웠다.
커뮤니케이션에 대한 어려움
- 네이버에서 "쇼핑" 조직은 항상 높은 부하를 받는다. 그 와중에 다른 팀에서 만든 무언가를 가져다가 사용하는건 그 조직의 입장에서 무척 어려운 일이다. 즉, 우리 팀 입장에서 생각하는 이상적인 커뮤니케이션을 하는 것은 불가능에 가깝다.
- 그래서 어떻게 할까 고민하다가 쇼핑 조직에서 운영하는 저장소를 fork한 다음 어떻게든 내 컴퓨터에 제품의 개발 환경을 띄워놓고 nBilly의 패키지를 말아서 계속 붙여서 테스트한 후 완성된 상태를 PR로 만들어서 제공했다. 쇼핑 조직 입장에서 최대한 "부담이 되지 않는" 형태의 커뮤니케이션을 이끌어가려고 신경썼다.
- 제품이 온전히 연결된 상태에 도달하기 위해선 프론트엔드 영역 뿐만 아니라 백엔드의 영역까지 함께 신경써야 했다. 그래서 AI와 내가 가진 얕은 백엔드 지식을 이용하여 코드를 직접 만들어서 제공했고 연동가이드도 AI를 이용하여 매끄럽게 만들 수 있도록 신경썼다.
아무리 기술적인 문제를 잘 해결한다고 해도, 이해관계를 고려하여 커뮤니케이션을 진행하지 않았다면 기간내에 퀄리티있게 마무리할 수 없었던 일이라고 생각한다. 결과적으로 생각보다 훨씬 빠르게 일을 진행할 수 있었고 적극적인 의사소통에 대한 깨달음을 얻었다.
3) nBilly + AI
팀원들과 "기술회고" 라는걸 정기적으로 했는데, "날잡고 AI를 적극적으로 활용하는 시간을 만들어보자" 라는 의견이 있어서 금요일 오후 4시간 정도를 투자하여 AI 연동 부분 빼고 호로록 구현했다.
그 다음에 심심할 때 마다 조금씩 조금씩 기능을 추가했는데, 스스로 생각했을 때(?) 아이디어가 나쁘지 않았었다. 다만, 이 때 팀에서 nBilly의 중요도가 크지 않았던 시점이라 진지하게 "이 기능을 도입하자" 라는 이야기는 나오지 않았다. 참 아쉽다
어쨌든 채팅을 통해 AI에게 output을 만들도록 하기 위해선 다음과 같은 것들을 이해시켜야 한다.
<데이터 구성의 형태>
Model Schema: nBilly가 관리하는 데이터의 전체 구조
ModelSchema를 통해 만들어진 각 Plugins의 구체적인 Schema
- 가령, Block이 가질 수 있는 값이 id, boxStyle, type 일 때, ImageBlock은 src 등을 추가로 가질 수 있다.
- AI에게 추가 및 수정하고 싶은 플러그인의 정보를 정확하게 넘겨줘야 한다.
<Entity를 추가/삭제할 때 사용하는 함수의 인터페이스>
이런 정보를 어떻게 해야 정확하게 전달할 수 있을까 고민하다가 JSON Schema 를 활용하는 방법이 떠올랐다. 기존에 작성된 코드의 type을 전부다 불러온다.
// @nbilly/site-builder/src/Schema.ts
import { TSite, TInsertableEntities, TUpdatableEntities } from '@nbilly/domain';
import { TPluginsSchema } from '@nbilly/plugins';
type Schema = {
SiteModelSchema: TSite,
CommandsSchema: {
insert: TInsertableEntities,
update: TUpdatableEntities,
}
PluginsSchema: TPluginsSchema
};
export default Schema;
이렇게 작성된 typescript 파일을 ts-json-schema-generator 를 토대로 JSON Schema로 변환할 수 있다.
$ npx ts-json-schema-generator --path 'package/site-builder/src/Schema.ts' -o 'package/site-builder/src/Schema.json'
이렇게 만들어진 Schema를 프롬프트에서 활용한다.
import NBillySchema from './Schema.json' with { type: "json" }
import EntityExample from './EntityExample.json' with { type: "json" }
const systemPrompt = `
<Instruction>
당신은 nBilly 사이트 빌더의 AI Assistant입니다. 사용자의 요청을 분석하여 적절한 JSON 명령으로 응답해주세요.
### 주요 역할:
1. 사용자의 자연어 요청을 이해하고 분석
2. 위의 스키마 정보를 바탕으로 적절한 insert/update 명령 생성
3. 선택된 블록/컨테이너/레이아웃 컨텍스트를 고려한 명령 생성
### 응답 형식:
EntityExample와 NBillySchema를 참고하여 아래 형식에 맞춰 JSON 명령을 생성해주세요.
#### GENERATE 응답 (아예 처음부터 Site를 만들어야 할 때):
{
"action": "GENERATE",
"data": TSite | TPage | TSection | TBlock | TContainer | TLayout
}
#### INSERT 응답 (새로운 요소 추가시):
{
"action": "INSERT",
"data": TInsertableEntities
}
#### UPDATE 응답 (기존 요소 수정시):
{
"action": "UPDATE",
"data": TUpdatableEntities
}
### NBilly 자체에 대한 질문 응답
예시: "NBilly가 뭐야?" 같은, NBilly에 대한 질문이 있으면 이에 대한 너의 생각을 이야기해줘.
### 컨텍스트 처리:
- 사용자가 특정 요소를 선택한 상태라면 해당 요소의 id를 기준으로 작업
- 선택된 요소가 없다면 현재 페이지의 적절한 위치에 추가
- 모호한 요청시에는 가장 합리적인 위치/방법 선택
</Instruction>
<EntityExample>
${JSON.stringify(EntityExample)}
</EntityExample>
</NBillySchema>
${JSON.stringify(NBillySchema)}
</NBillySchema>
`;
나름 스스로 "획기적인데!?" 라고 생각했으나.. 거기까지였다. 그치만 만들면서 재밌었기 때문에 만족스럽다.
번외로, 이걸 서비스에서만 활용하는게 아니라 ChatGPT나 Claude에게 넘겨줘서 응답을 받을 수도 있다. API를 활용하여 테스트를 하면 비용이 발생하기 때문에 직접 AI 서비스 내에서 프롬프트를 입력하여 테스트 했었다.
(2) AI Driven 글쓰기
하반기에 우리 팀은 플랫폼 조직에서 서비스 조직으로 옮겨지며 nBilly 그만 만들고 서비스 지원해야 하는 상황이 되었다. 그래서 nBilly 개발은 잠정 중단하고 서비스 지원에 필요한 작업을 진행했는데 그 중에 하나가 AI 글쓰기였다.
네이버 블로그에서 글을 작성할 때 사용자의 메타데이터를 이용하여 자연스럽게 AI가 글을 작성해주는 기능을 PoC 프로젝트로 진행했었다.
<Case 1>
- 사용자가 글을 작성하다가 특정 키(
Tab,/등)를 트리거 했을 때 AI가 현재 작성중인 문장을 수집한다. - 수집한 문장에 대해 연관있는 데이터를 가져온다.
- 네이버 회원이면 사용자의 최근 본 콘텐츠, 방문장소, 쇼핑내역, 리뷰내역 등을 조회할 수 있다.
- 이를 기반으로 현재 문장과 관련있는 메타데이터를 뽑아서 추가 제안을 한다.
- 메타데이터 외에도 글감 API, 검색 API 등을 활용하여 추천 콘텐츠를 제공한다.
- 사용자가 클릭하면 해당 콘텐츠들이 삽입된다.
<Case 2>
- 사용자가 글을 작성하는 시점에 AI를 이용하여 초안을 작성하도록 처음부터 제안한다.
- 작성하고 싶은 글의 종류를 선택하면 이와 연관된 메타데이터와 검색결과를 뽑아와서 초안을 작성해준다.
아이러니하게도 이 작업을 할 때 제일 큰 병목은 AI보다 에디터였다. 물론 AI를 통해 데이터를 가져오는 것도 중요하지만, 이보다 가져온 데이터를 에디터 내에서 정확한 위치에 삽입하고 수정하는게 생각보다 까다로웠다.
그리고 가져온 데이터를 에디터에 삽입할 수 있는 형태로 정제하는 것도 어려웠다.
nBilly + AI를 할 때도 느꼈지만 AI를 잘 사용하기 위해선, 결국 플랫폼의 확장성이 굉장히 중요하다. 그래서 AI 시대에는 프론트엔드 개발자의 설계 역량이 점점 중요하지 않을까? AI와 플랫폼을 연결할 때 매끄러움이 느껴져야 한다. 그러기 위해선 고퀄리티의 엔지니어링이 동반된다고 생각했다.
어쨌든 이 PoC 프로젝트는 중단되었다. 무엇보다 글쓰기에 AI를 도입하면 그 비용을 감당할 수 없다는 것이 이유였다. 특히 사용자가 만족할만한 콘텐츠를 제안하는게 생각보다 까다롭다고 느꼈다.
(3) Thingsbook TF
8월까지 앞에서 언급했던 AI Driven 글쓰기를 진행했고, 그 이후 Thingsbook TF에 합류했다. 이미 80% 정도는 개발이 완료 되었으나 출시 일정이 촉박하여 인력이 부족한 상황이고, 그 시점에 우리팀은 플랫폼 제작 성격의 업무를 하다보니 자연스럽게 서비스 참여에 대한 상위 리더십의 요구사항이 있어서 나를 포함한 3명의 팀원이 착출되었다.
네이버에서 일하며 이렇게 다른 조직의 업무를 직접적으로 지원하는 경험은 처음이었는데, 이게 나에게 무척 긍정적인 경험이었다.
다른 팀의 조직문화에 대해 배울 수 있었다.
- 내가 느끼기에 네이버는 조직마다 문화가 너무 다르고, 다른 조직과의 연결이 약한 편이다. 함께 일한다는 느낌보단 따로 각자 일한다는 느낌을 많이 받았다. 특히 FE 개발의 경우 구심점이 없는 느낌이라, 팀 외부의 FE 개발자와의 소통을 하려면 직접 찾아가서 물어보는 방법 밖에 없었다.
- 그런데 의도치않게 다른 조직과 밀착하여 업무의 라이프사이클을 보면서 각 조직의 강점과 특징에 대해 알아갈 수 있었고 이게 재밌고 유익했다.
네이버에서 일하며 서비스 개발을 처음하다보니 새로 접하는 기술이 많았다.
- 나는 tanstack-query를 제대로 사용해본 경험이 없었는데, TF에 합류했더니 잘 구축된 tanstack-query 기반의 아키텍처를 자연스럽게 접할 수 있었다.
- 이 외에도 ts-pattern, opossum, lottie 등 꽤 많은 라이브러리의 사용방법을 자연스럽게 익혔다. 무언가를 공부할 땐 이미 완성되어 잘 쓰는 유즈케이스를 보는게 좋은 방법이라고 다시 한 번 느꼈다.
새로 합류한 입장에서 무언가를 도입하거나 제안할 때 효과적인 방법에 대해 알 수 있었다.
- n8n 기반의 코드리뷰, 단위 테스트, 통합 테스트, 커스텀훅 기반의 비즈니스 로직 분리, 커서룰 추가 등 기존 프로젝트에 기술적으로 기여한 부분이 꽤 있었다고 생각한다.
- 중요한건 "이런거 도입해볼까요?"를 이야기하기보단 은근슬쩍 만들어서 "결과물"의 형태로 보여주는 것이다. 내가 "이거 좋아요!" 라는 판단을 하는 게 아니라 결과물을 토대로 이를 보는 사람들이 판단하도록 만들다보면 자연스럽게 논의를 하게 되고, 그 과정에서 함께 일하는 사람들이 어떤 생각과 가치관을 가지고 있는지 알게 된다.
그리고 나와 함께 팀에서 착출된 분들이 마크업 개발에서 FE 개발로로 직무전환을 한 상태여서, 매일 멘토링을 하며 FE 업무의 성격에 대한 메타인지를 나 스스로 높일 수 있었다.
- 서버에서 가져온 데이터를 통해 SSR을 하기 까지의 과정, 클라이언트에서 API를 호출하여 이를 React의 상태로 만들고, 다시 React의 상태를 HTML로 변환하는 과정, 데이터를 제어하면 자연스럽게 UI에 변환되는 과정, 데이터를 기반으로 서비스의 흐름을 그려서 이해하는 과정 등을 설명하면서 "아! FE 개발의 핵심은 Data to UI 구나!?" 를 알았다.
- 더 나아가서 데이터를 생성하는 UI/UX (가령 우리 팀이 만들던 nBilly나 피그마 같은..) 도 FE의 영역이 될 수 있고, 개인적으로 이게 난이도가 훨씬 높다고 생각한다.
굉장히 디테일한 코드리뷰를 받을 수 있었다. 업무의 절반이 코드리뷰라고 봐도 무방하지 않을까?
- 특히 커밋 단위로 리뷰가 진행되는게 인상적이었다. 커밋 메시지는 적합한지, 불필요한 커밋은 없는지, 커밋의 순서가 어색하진 않은지, 커밋에 적절한 맥락이 담겨있는지 등에 대한 리뷰도 있었고 처음에는 이게 무척 부담이 되었으나 시간이 지날수록 그 이유를 잘 알 수 있었고 덕분에 좋은 습관이 체화되었다.
코드리뷰 때문에 다른 업무가 병목이 되지 않도록 화면공유를 하며 실시간 피드백을 주고받으며 리뷰를 최대한 빠르게 마무리하는 방식으로 진행되었다.
조금, 아니 많이 힘들었던건 서비스 스펙을 파악하는 부분이었다. 기획 담당자가 여러 번 바뀌고, 스펙 문서가 스택처럼 쌓여가면서 내가 개발하고 있는 기능의 전체 스펙을 파악하는 게 너무 힘들었다. 이 과정에서 SSOT(Single Source Of Truth, 단일진실원천)에 대한 중요성을 인식했다. 서비스 개발을 할 때에도, 이런 스펙 문서를 관리할 때에도 SSOT가 지켜지지 않으면 맥락을 파악하는 것도 몇 배는 어렵고, 유지보수의 난이도 또한 점점 높아진다.
마지막으로 약간의 TMI인데, TF를 하면서 글또를 통해 알게된 종윤님(재그지그의 개발블로그 주인장)님과 함께 일할 수 있었다. 종윤님의 경우 다른 사람들이 스쳐갈 수 있는 문제에 대해 잘 짚어주시고, 무척 꼼꼼하게 문제를 찾아주셨다. "어떻게 이런걸 발견했지?" 라고 느끼는 부분이 많았다. 나의 가장 치명적인 단점이 꼼꼼함인데, 이런 강점을 가지고 계셔서 무척 존경스러웠다. 내가 싸놓은 똥을 꼼꼼하게 잘 찾아주셨다.
종윤님 외에도 같이 일했던 모든 분들이 일당백 수준의 능력을 보여주셔서 깜짝깜짝 놀랄 때가 많았었다. 내가 모르는게 있어서 질문을 할 때 빛의 속도로 관련 자료를 찾아서 답변을 해주시거나, FE, BE, Infra 등 거의 모든 기술 영역에 대해 디테일하게 알고 있다거나, 복잡한 로직을 뚝딱뚝딱 만들어주시는 등 감탄할만한 일들이 굉장히 많았다. 세상에는 능력자가 많고 나는 그냥 말하는 감자라는 것을 매번 알게 되고 겸손해진다.
(4) 각종 기술공유
25년에는 기술공유를 다양한 범위에서 다방면으로 많이했다고 생각한다.
1) No-code Dev 팀의 AI 활용기
우리 팀은 AI 활용 성숙도 매트릭스를 만들어서 운영했다.
팀 구성원 대부분은 "업무를 할 때 AI를 능숙하게 활용하여 생산성을 높이는 상태" 였고, 이 다음단계가 "AI 활용 방법을 적극적으로 전파하고 공유하는 상태" 였다. 그래서 다음 단계로 나아가기 위해 우리 팀의 AI 활용 경험을 수집한 다음 이를 정리하여 사내에서 진행되는 AI 활용 세션에 참가했다.
이 때 공유했던 내용은 다음과 같다.
- AI를 이용하여 기술 문서를 최신화하여 신규 인원의 온보딩을 지원하는 방법
- 기술 문서를 AI가 읽어들여 nBilly 플러그인을 뚝딱뚝닥 만드는 방법
- Cursor Rules 활용하여 Test Coverage를 100%로 채우는 방법 (발표할 당시에 사내 공용 Cursor Rules 저장소를 만들어서 공유하기도 했다)
- Cursor와 Vercel의 v0.dev API를 연결하여 매끄러운 UI를 만들어가는 방법
- n8n과 AI를 활용하여 운영업무를 자동화하는 방법
이 때가 6월이었고, 이를 계기로 기술공유 개미지옥(?)에 자연스럽게 빠져들었다.
2) n8n 활용기
사내에서 내가 했던 발표의 대부분은 n8n과 관련된 내용이었다.
- n8n을 사내 플랫폼에 구축하는 방법
- n8n의 AI Node를 사내에서 제공하는 Commercial API와 연결하는 방법
- n8n을 이용하여 RAG를 만드는 방법
- n8n을 이용하여 MCP를 만드는 방법
위의 주제들로 다양한 기술공유를 진행했다.
- 3차 조직의 올핸즈 세션에서 발표(대략 300명 정도참여하는)
- 실습 기반의 핸즈온 세션 진행
- 사내강의 촬영
- 사내 엔지니어링 데이 참여 (어쩌다보니 조회수 1등..)
- FE와 관련된 주제로 발표할 때는 관심도가 낮았는데, AI를 주제로 하니까 조회수가 폭발해버렸다
- 역시 대중성이 중요해!
사실 나뿐만 아니라 모든 팀원이 기술공유에 적극적이었다. 연말 기술공유 시상식에 우리 팀이 뭐라도 하나 받겠지 생각했는데 아무것도 안 줘서 참 아쉬웠다 😩
(5) 온보딩 멘토
연초에는 팀의 가치를 인정받아서 팀의 규모가 커졌다(그치만 연말에 공중분해.. 윽..). 다른 팀에서 우리 팀으로 합류한 분들이 많았고, 온보딩 멘토를 자처했다. 매일 정해진 시간에 함께 모여서 필요한 지식을 순차적으로 전달하고, 이 과정을 녹화해서 공유했다. 이게 꽤 효과적이었다고 생각한다.
그런데 마크업(퍼블리싱)에서 FE로 직무전환을 하신 분들이 계셨고, 이 분들에게 적절한 난이도의 과제나 태스크를 제공해드리지 못했었다. 연초에는 내가 담당하고 있는 일의 범위도 많고 개인사(결혼 등)도 겹쳐서 너무 정신이 없다보니… 좋은 퀄리티의 멘토링을 진행하지 못했었다.
그런데 8월에 다시 TF로 분리가 되면서 이 때가 기회다! 라고 생각하여 내가 전달할 수 있는 부분은 최대한 전달하려고 했었다.
- React는 익숙하지만 javascript는 익숙하지 않은 상태여서 Vanilla Javascript 기반의 SPA를 만드는 과제를 만든 다음에 이에 대한 구현 가이드를 제공한 다음 구현한 내용에 대해 코드리뷰를 진행했다. 이걸 꾸준히 지속했다면 좋았을텐데, 시간적 여유가 없다보니 흐름이 끊겨서 아쉬웠다.
- Thingsbook 프로젝트의 구조를 Figjam으로 그리는 방식으로 함께 분석했다. 이 때 "데이터 중심"으로 분석할 수 있도록 했고, 데이터를 따라가면서 어떤 함수를 실행했을 때 어떤 아웃풋이 나와서 렌더링이 되는지를 중점으로 봤다.
- 분석한 내용을 기반으로 QnA를 진행하고, 퀴즈쇼 비스무리한것도 했다. (이건 왜 이렇게 될까요!? 같은..)
- 매일 데일리스크럼을 하면서 현재 진행하고 있는 태스크의 해결방법에 대한 힌트를 많이 제공했다. 특히 문제를 두 번 풀이하는 방식을 선호했는데, 일단 직접 구현하도록 유도한 다음 내가 리팩토링을 하면서 어떤 관점에서 코드를 다뤄야 하는지에 대한 이야기를 많이 했다.
멘토링을 하면서 가장 신경썼던 부분
지식을 전달하는 과정에서 내가 답답함을 느끼는 모습을 보여주면 교육이나 멘토링 자체에 집중하는 것이 아니라 감정에 집중하게 된다고 생각한다. 그래서 최대한 감정을 배제하고, "이 사람이 어떤 부분에서 어려움을 느끼고 있는지" 에 집중하려고 노력했다.
그럼에도 불구하고 큰 도움이 되었을까? 라고 생각해보자면.. 그냥 스스로에게 아쉬운 부분이 많았다. 사실 네이버에서 일을 하며 나 스스로가 부지런하다고 생각해본적이 많이 없었다. 더 정확히는 부지런하게 일을 한 적이 많이 없었던 것 같다. 조금더 몰입하고 신경썼더라면 더 좋은 결과가 있지 않았을까? 라는 아쉬움이 항상 있다.
개발을 잘 하는 것과, 코칭/멘토링을 잘 하는 것은 결이 많이 다름을 많이 느꼈다. 물론 난 둘 다 못하는 사람.. 🤣
(6) 조직, 그리고 끝
25년에는 조직개편이 많았고 덕분에 팀의 목표와 방향성이 거의 실시간으로 업데이트 되면서 "조직을 신뢰하는 마음"이 무너졌다. 다양한 이벤트가 있었고 이 현상을 바라보다가 나는 "내가 더 몰입할 수 있는, 성장할 수 있는 환경"에 대한 고민을 하기 시작했다.
- 연초에는 팀의 가치를 인정받아서 팀 규모가 확장되었다(8명 → 15명)
- 규모가 확장된다는 것은 우리 팀이 더 어려운 난이도의 미션을 수행해야 한 다는 이야기였고 특히 AI에 대한 중요도가 높아지면서 이와 접목할 수 있는 무언가를 계속 찾아내야 했다. 이 과정에서 AI와 관련된 PoC를 많이 진행했다.
- 그런데 갑자기 상위 조직이 플랫폼 사업 부문에서 서비스 사업 부문으로 이동되며 팀의 목표와 미션이 통째로 수정되었다. 서비스 지원이 중요해졌다.
- 기존에 만들던 것들을 중단하고, 우리 팀의 대다수가 다른 팀의 서비스 업무를 지원하는 방식으로 진행되었다.
- 그리고 팀의 목표가 실시간으로 변경되는 과정에서 나를 포함한 팀원의 대다수가 혼란을 느꼈다.
- 결국 연말에는 교통정리가 되어 우리 팀이 만들던 제품과 몇몇 팀원이 다른 조직으로 떨어져나갔다. 나도 그 중에 한 명이었다.
1~6 사이에 이상한 부분이 하나 더 있는데, 1의 과정에서 합류했던 분들은 원래 디자인시스템을 만들던 분들이었다. 그런데 6으로 도달했을 때 기존에 디자인시스템을 만들던 분들은 다른일을 하고, 기존의 팀원들이 디자인시스템일 이어받아 개발하는 형태로 되었다. 개인적으로 이러한 의사결정을 조금… 이해하기가 힘들었다.
무엇보다 거의 3년동안 쌓아온 우리 팀의 가치와 라포가 순식간에 무너지는 모습을 볼 수 있었다. 팀 내에서는 "우리가 이 일을 왜 해야 하는지 명확하게 이해하고 진행해야 합니다" 를 팀장님께서 항상 강조했다. 그런데 조직개편이 되면서 Top-Down으로 내려 꽂히는 의사결정을 겪었다. 때문에 이 상황에서 제일 힘든 사람은 팀장님이었으리라 생각한다. 팀원들의 불안감이 커지고, 업무에 몰입하기 힘든 상황이 계속해서 발생한다. 이 와중에 교통정리를 하고, 우리 팀의 생존을 위해 다양한 방식으로 고군분투 했으나 결과적으로 안 좋은 상황이 되었으며 "조직 구성원이 조직을 신뢰하지 못하는 상태" 가 되었다고 생각한다. 적어도 나는 조직을 신뢰하지 못하는 상태가 되었다.
이 외에도 빠르게 치고나가야 할 때 다양한 이유로 엎어지는 일을 많이 보고, 반대로 상위 리더의 강력한 의지가 있을 때에는 수십 명의 인원이 달려들어 프로젝트를 진행하다가 결국 망하는 모습을 많이 보면서 현타가 많이왔다.
내가 보는 동료들은 너무 뛰어나고 배울점이 많은데, 이 인원들의 역량을 100% 끌어내지 못하고 일의 몰입을 방해하는 요소가 계속해서 생겨난다.
마지막으로 내가 발견한 나의 강점을 회사에서 적극적으로 활용하여 좋은 성과를 만들어가는 것이 어렵다는 생각이 들었다. 나는 빠르게 무언가를 만들어서 진행한 다음 이를 토대로 피드백을 받고 완성도를 높이는 방식을 선호한다. 그리고 그걸 잘 하는 편이라고 생각한다. 그런데 네이버에서의 경험은 "한 번 만들 때 잘 만들어야 돼" 라는 느낌을 많이 받았다. 아마 사용자가 네이버를 바라보는 시선 때문일 수도 있고, 직원들의 성향 때문일 수도 있다. 이유야 어쨌든 결국 내가 가진 역량을 이 회사에서 온전히 끌어내기는 어렵겠다는 생각이 들었다. 특히 nBilly를 공개된 공간에서 조금 더 적극적으로 소개하고 공유했다면 어땠을까 라는 아쉬움이 있다. 좋은 제품의 목적은 사용자인데, 이것저것 기능은 많이 만들지만 다양한 이유 때문에 사용자를 많이 확보하지 못했다.
나는 네이버의 직원이지만, 나는 네이버가 아니다. 네이버라는 울타리가 없어지면 나는 바람 앞의 등불이 된다. 내가 가진 능력으로 나만의 견고한 울타리를 만들기 위해선 지금과 같은 환경은 좋지 않다고 생각했다.
이와 관련해서 최근 흑백요리사2의 손종원 셰프님께서 하신 이야기가 인상깊었다.
"저도 3스타 레스토랑 세 군데에서 일해봤지만, 제가 일했던 3스타가 저를 3스타로 만들지는 않더라고요. 저의 스타는 제가 만들어가야 되는 거거든요."
내가 네이버라는 좋은 회사의 소속이기 때문에 뛰어난 능력을 가졌다고 이야기 하기는 어렵다. 나는 더 성장하고 싶고, 견고해지고 싶다. 그래서 내가 더 견고하게 성장할 수 있는 환경을 찾아나섰고 결국 떠나게 되었다.
네이버에서의 여정은 26년 1월 9일 시점으로 마무리했다. 1월 12일부터는 토스 플레이스에서 새로운 여정을 시작한다. 추후에 이에 대한 생각을 정리해서 글로 작성할 예정이다.
교육자
내가 가진 또 하나의 정체성은 "교육자" 라고 생각한다. 그리고 나는 교육을 할 때 더 몰입하는 편이다. 웬만하면 개발자의 커리어와 교육자의 커리어를 병행하고 싶은데, 아마 26년에는 그게 힘들 것 같다. 어쨌든 25년의 교육자로서의 경험을 정리해보자.
(1) 항해플러스
1년동안 4기 ~ 7기, 총 4기수를 진행했다. 그리고 7기를 마지막으로 항해플러스는 완전히 끝났다 (아마도?)
1) 과제를 업데이트하기
각 기수를 관성으로 진행하기보단, 계속해서 과제의 난이도를 조정하고 업데이트하고자 했다.
<Vanilla Javascript SPA 만들기>
4기 ~ 5기는 해당 과제가 SNS를 구현하는 형태였다.
- 그런데 이게 비즈니스 로직을 많이 다루고 있지 않기 때문에 학습 효과가 생각보다 높지 않았다고 느꼈다.
- 특히 과제의 난이도가 높지 않기 때문에 스스로 문제를 해결하는 경우가 많았고 좋은 신호가 아니라고 생각했다.
6기 ~ 7기의 SPA 만들기 과제
- 6기부터는 "쇼핑몰"로 주제를 변경했다. 무엇보다 구현해야 하는 분량과 구현 난이도를 높이면서 스스로 문제를 해결하기보단 팀원들과
과제를 만든 코치를 욕하면서문제를 함께 풀이하면 좋겠다고 생각했다(는 사실 결과론이고, 의도치 않게 사람들이 뭉쳐서 과제를 풀이하는 모습을 봤다.흐뭇했다)
금요일 오전 6시까지 다함께 과제를 풀이하는훈훈한(?)모습이다. - 6기에는 단위테스트를 토대로 과제를 검증했는데, 그러다보니 문제가 너무 많이 발생해서 7기에서는 아예 E2E TEST만 사용하여 과제를 검증하는 방식으로 개선했다.
- 어쩌다보니 테스트 코드 챕터를 제외하고는 다 쇼핑몰을 다루고 있어서 또핑몰로 불리게 되었다
- 6기부터는 "쇼핑몰"로 주제를 변경했다. 무엇보다 구현해야 하는 분량과 구현 난이도를 높이면서 스스로 문제를 해결하기보단 팀원들과
<SSR 구현으로 변경된 인프라 기반 성능 최적화 과제>
5기까지는 9주차 과제의 난이도가 굉장히 쉬웠다. 사실 1~2시간 정도면 완료할 수 있는 수준의 내용이었다. 그래서 이걸 어떻게 변경할까 고민하다가 "꼭 인프라 기반 성능최적화라고 해서 인프라에 집중할 필요는 없잖아? 공부만 많이 하면 되잖아!" 라는 생각이 들었다.
6기부터는 기존의 과제를 실습과제로 변경하고, SSR, SSG 를 직접 구현하는 과제를 만들었다. 의도치않게 난이도가 제일 높은 과제가 되었다.
그렇게 어렵나..?
사실 서버에 대한 정확한 이해가 없으면 힘들 수 밖에 없다고 생각한다. 그런데 많은 FE 개발자가 NextJS 같은 프레임워크를 사용하고 있고 자연스럽게 서버를 접하고 있는데 이에 대한 정확한 이해가 없는 상태에서 기술을 사용할 때 마주할 수 있는 문제가 많다고 생각했고 이를 해소하고자 했다.
특히 7기의 준태님께서 이론에 대한 공부도 꼼꼼하게 남겨주셔서 참고차 남겨놓는다.
2) 항해플러스 블로그 만들기
사람들이 항해플러스를 수료한 다음에 이력서에 "항해플러스 수료" 라고만 남겨놓는게 너무 안타까웠다. 충분히 깊이 있는 경험을 했다고 생각하는데, 이걸 단순히 한 줄로 퉁친다고?
어떻게 이 문제를 해소할 수 있을까 고민하다가 과제의 내용을 기반으로 블로그를 만들면 어떨까? 라는 아이디어를 얻었다.
생각보다(?) 많은 분들(영서님, 진석님, 찬규님, 가은님, 창준님)께서 기여를 해주셨다. 다만 내가 귀찮아서 기능을 추가하지 않은게 많아서 완성도가 조금 아쉽다.
저장소
결과물
이렇게 수강생이 수행한 과제의 내용을 아티클 형식으로 볼 수 있다.
최종적으로 과제에서 수행한 내용을 기반으로 AI가 수강생의 강점과 역량을 추출한 다음 프로필에서 볼 수 있도록 하고 싶었는데 거기까지 진행하진 못했다.
3) n8n 기반의 코드리뷰 시스템
또 어떤 방식으로 수강생들에게 인사이트를 줄 수 있을까 고민하다가 "AI 기반의 코드리뷰 시스템을 직접 만들면 어떨까?" 라는 생각을 했다.
워크플로우 예시
결과물
4) 감사의 메시지
4기는 기억이 조금 가물가물하다. 그래도 더듬어보자면!?
- 마지막 최종 발표를 함께했던 7팀 + 10팀. 긍정적인 에너지와 팀워크가 너무 돋보였다. 뭐랄까.. 참 따듯한 느낌을 많이 받았던 그런 팀이었다.
- 8팀 준만님. 워낙 눈에 띄게 잘하시는 분이었다. 마플에서 잘 지내고 계시죠..!?
- 11팀 재도, 원정님, 근백님, 수빈님. 특히 재도는 정말 리스펙하는 후배고, 원정님은 내가 데려온 분이라 유독 기억에 남는다.
- 9팀 지수님. 사실상 9팀의 유일한 생존자… ㅋㅋ… OT때 맥주잔에 소주를 부어먹는 모습이 아직도 기억에 새록새록하다.
- OT와 중간네트워킹때 함께했던 6팀분들
- 학메 + 운영진까지 하게된 15팀 현빈님, 채은님. 너무 고생하셨어요!!
5기는 분위기도 좋고 열심히 하시는 분들도 많았고 인원도 많았던걸로 기억한다.
- 영호님과 운서님이 계셨던 2팀. 영호님께서 과제를 너무 잘 하셔서 놀란적이 많았었다.
- 팀 분위기도, 실력도 최상이었던 3팀. 마지막 멘토링 가짜인생/진짜인생이 유독 기억에 남는다.
- 채영님과 지찬님이 계셨던 6팀. 지찬님께서 항상 날카로운 질문을 해주셔서 당황스럽고(?) 재밌었다. 채영님은 6기, 7기 학메까지 해주셨다.
- 진솔님이 계셨던 7팀. 근데 제 멘토링을 들은적이 없는... ㅋㅋ
- 민지님이 계셨던 10팀. 그 당시에 고민이 많으셔서 걱정이었는데 지금은 너무 잘 풀리셔서 다행이다.
- 시작과 끝을 함께했던 12팀. 다들 잘 지내고 계시죠!? 마지막 과제 다 불합격드려서 죄송합니다…
어쩔 수 없었어요 ㅠㅠ - 민구님이 계셨던 따듯한 느낌의 13팀. 민구님이 너무 잘 풀려서 참 다행이다. 민구님의 경우 피드백을 스폰지처럼 흡수하고 체화하셨다. 별거 없는 저의 이야기를 잘 들어주시고 또 열심해주셔서 감사드립니다!
6기는 제일 애정이 많은 기수였다. 수강생들은 교육과정 자체에 애정을 가지고 동료들과 깊이 있는 라포를 쌓고, 이를 토대로 다시 교육에 몰입했다. 이들의 열정과 에너지, 긍정적인 영향력 등이 너무 보기 좋았다. 코치가 아닌 수강생으로 함께했다면 어땠을까? 라는 생각을 참 많이 했다. 그래서 기억에 깊이 각인 되었다. (롤링페이퍼 기억하고 있죠 여러분!? 모두 감사합니다 ㅎㅎ)
항해에서 비피 말고 베프 찾기나랑 찰떡궁합인 항해인은 누구? 지금 바로 시작해보세요!hanghae-bf.netlify.app
한분한분 언급하고 싶지만… 그러다가 장문의 편지가 될 것 같아요 ㅋㅋ ㅠㅠ 6기에서도 제일 감사한 준형님, 영서님, 진석님, 가은님, 창준님, 정석님, 지호님, 지현님, 도은님 + 학메분들! 여러분들 덕분에 행복한 10주였습니다. 감사해요~!
무엇보다 학습 자체를 다들 열심히 해주셔서 인상깊었답니다.
7기는 개인적인 이슈 때문에 중간 네트워킹과 수료식에 참여하지 못했고.. 덕분에 수강생들과 라포를 쌓기가 어려웠다.
- 처음을 함께했던 1팀, 2팀분들.
- 준모님의 재치가 돋보였던 3팀.
- 강렬한 정원님을 소유한 4팀.
- 파워인싸 성민님을 소유한 5팀. (이집트 진짜 실화인가요..?)
- 멘토링은 많이 했는데.. 우리 친해지질 못했네요.. 6팀 (ㅠㅠ)
- 마지막을 함께한, 그리고 베스트팀으로 선정된 7팀.
마지막으로 무한한 인사이트를 주시는 코치님들, 고군분투 해주신 현빈 매니저님과 혜민 매니저님. 너무 감사드립니다!
마지막으로 짤막한 마지막 인사를 하자면 (특히 마지막 인사를 제대로 못드린 7기분들께..)
학습은 이런 교육과정에 참여하는게 아니여도 혼자서 충분히 할 수 있다고 생각해요. 그치만 사회생활을 하면서 마음이 잘 맞는 좋은 동료를 찾는건 참 어려운 일이라고 생각합니다. 항해플러스가 여러분의 끈끈한 울타리가 되어주면 좋겠다고 생각했어요. 그리고 끈끈함을 만들기 위해선 결국 적절한 난이도의 미션도 필요하다고 생각했답니다.
많은 분들께서 불안감과 열등감에 대한 이야기를 많이 해주셨는데, 저도 항상 불안감과 열등감을 느끼고 있어요. 사람은 완벽할 수 없으니까요! 그래서 그게 잘못된 감정이라고 생각하지 않아요. 그냥 다른사람들도 나와 비슷하구나, 크게 다르지 않구나, 그렇게 느꼈으면 좋겠습니다.
그리고 내가 잘할 수 있는 일, 나의 강점을 꼭 찾아보세요. 결국 시간이 지날수록 뾰족한 무언가를 가지고 있어야 생존도 할 수 있고, 안정감도 느낄 수 있고, 그랬을 때 성장도 할 수 있다고 생각해요. 특히 지금처럼 빠르게 변하는 시대에서는 나만의 무기가 꼭 필요하다고 느끼는 중입니다. 공부도 물론 좋지만 나 자신에 대해 알아가는 시간을 많이 가져보셨으면 합니다.
어떤 방식으로든 도움이 필요하면 언제든 편하게 찾아주세요. 저도 항해플러스라는 울타리에 속해있는 한 사람이니까요!
5) 마무리하며
항해플러스를 진행하면서 좋은 사람들을 참 많이 만날 수 있었다. 사람들과 여러가지 이야기를 나누면서 나 자신에 대한 해상도가 올라갔고 내가 가진 강점도 많이 발견할 수 있었다고 생각한다. 스쳐간 모든 인연이 한 분 한 분이 나에게는 스승과 같다. 그래서 힘들고 피곤함에도 불구하고 그렇게 꾸역꾸역 했나보다. 나의 놀이터이자 쉼터가 아니였을까?
이런 시스템이 허물어지는게 참 아쉽다. 마음이 맞는 사람들이 모이기 위해선 공동의 목표가 필요하고, 모임을 유지하기 위해선 크고 작은 미션들이 필요하다고 느꼈다. 그리고 이 시스템에 기여할 수 있는 장치가 필요하고 기여했을 때 높은 수준의 보상이 필요하다.
언젠간 그런 시스템을 만들어보고 싶다. 고통스러운 교육 시스템이 아닌 놀이터 같은 교육 시스템을 만들어보고 싶다. 아마 나 혼자서는 분명 불가능할 것 같은데, 이 교육과정을 하면서 알게된 다양한 사람들의 도움이 있다면 분명 가능하리라 생각한다. 그게 언제가 될진 모르겠으나 꼭 정말 꼭 만들어보고 싶다.
(2) 리뷰어 경험
올해는 우아한 테크코스 7기, 넥스트스텝, 카카오 테크캠퍼스, 부스트캠프 서울대 특강 등의 과정에 코드리뷰어로 참여했다.
특히 우테코 리뷰어를 할 때 유독 힘들었는데, 코드에 대해 깊이있게 생각하는 분들이 많고 티키타카를 하다 보면 시간을 많이 쓸 수 밖에 없었다. 그 과정에서 내가 반복적으로 하는 이야기가 두 가지였다.
자동차 경주 미션을 통해 산출된 코드 리뷰우아한 테크코스 리뷰어로 참여하면서 남긴 피드백을 정리한 내용입니다.개발자 황준일
- 요구사항을 기반으로 클린코드에 대해 생각하기: 결국 좋은 코드의 목적은 "유지보수"이고, 요구사항을 추가/수정/삭제 하는 상황을 가정해보며 내 코드의 변화에 대한 예측을 해볼 수 있다. 이를 통해 코드의 흐름, 확장성, 응집도 및 기타 등등 다양한 상황에 대한 고민을 해볼 수 있다. 요구사항은 기능 요구사항과 기술 요구사항 두 가지에 대해 상상해보면 좋다.
요구사항의 변화로 알아가는 프론트엔드 클린코드클린코드를 요구사항을 떼어놓고 이야기할 수 있을까?개발자 황준일 - 선언형으로 추상화하기: 코드를 확장성있게 리팩토링 하다보면 최종 형태는 "선언형"으로 도달하게 된다. 그렇다면 "선언형 방식으로 작성된 코드"에 익숙해지면 어떨까?
이를 반복적으로 이야기하다보니 피로도가 참 많이 쌓였다. 그래서 26년도 목표 중 하나는 내가 생각하는 좋은 코드에 대한 시리즈물을 연재하는 것! (가능할까?)
(3) 부스트캠프 연계 대학교 특강
올해는 부스트캠프 마스터로 참여하진 않았고, 부스트캠프와 연계하여 2주동안 대학교에서 특강을 진행했다. n8n을 활용하는 방법과 ai를 이용하여 테스트를 작성하는 방법에 대해 다뤘는데, 이렇게 일방적으로 지식을 전달하는게 생각보다 쉽지 않은 것 같다. 나는 강의나 설명을 잘 하는 사람이 아님을 참 많이 느꼈었다.
지식을 잘 전달하기 위해선 지식을 추상화 해야 되는데, 나에게는 지식을 추상화하는 능력이 많이 부족하다. 어휘력도 부족하고…?
그러다보니 설명이 계속 장황해지고, 장황한 설명을 듣는 사람은 "저게 대체 뭔소리야?" 가 되어버린다. 이를 개선할 수 있을까? 적어도 5년 아니 10년은 꾸준히 숙련해야 가능할 것 같다.
(4) 각종 해커톤 연사
후배들의 요청으로 해커톤에서 개발자 취업 및 커리어를 주제로 주절주절 할 기회가 많았다. 그런데 대학생들이 발표하는 내용과 구현된 결과물을 보면 너무 잘해서 감탄할 때가 많았다. 이런 실력을 가지고 있음에도 불구하고 실무에서 일을 할 수 없다는 현실이 너무 안타까웠다.
20250628_개발자취업_이모저모개발자 취업 이모저모 20250628_황준일 1Google Docs
해커톤에서 연사로 참여할 때 사용한 자료다.
반복적으로 하는 이야기는, 취준생 입장에서 임팩트 있는 결과물을 만들어내는 것은 어렵기 때문에 그렇다면 임팩트 있는 결과물을 만들어낼 수 있는 "가능성"을 보여줘야 하고 그게 "러닝 포인트"라고 생각한다. 내가 문제에 대해 어떻게 접근하고 해결한 다음에 전파(공유)하는지가 중요하지 않을까?
(5) 기능경기대회
올해도 어김없이 기능경기대회에 참여하는 학생들을 코칭했다. 이제는 내가 직접적으로 지식을 전달하기보단, 문제를 해결하는 방법과 대회에서 입상을 할 수 있게 만들어주는 마음가짐 그리고 문제풀이 전략 등에 대해서만 이야기 하는 편이다.
결혼, 그리고 함께 살아가는 것.
25년 4월 20일, 결혼을 했다. 생각보다 많은 분들이 와주셔서 참 감사했고 뭉클했다.
나를 알고 있는 이렇게 많은 사람들이, 오직 이 날을 위해 한 자리에 모였다는 사실이 참 얼떨떨하고 믿기지 않았다. 참 감사했다. 예식 막바지에 갑자기 감정을 주체하지 못해 대성통곡을 해버렸다 🤣 영상으로 보면 얼마나 웃긴지..
여튼 꿈같은 결혼식이 지났고, 그렇게 아내와 함께 시간을 보내면서 느낀 점이 참 많다.
나는 스스로 꽤 성숙한 생각을 하는 사람이라고 생각했는데 성숙은 커녕 미숙하고 모자란 부분이 많아도 너무 많았다. 생각없는 행동도 많이 하고, 실수도 많이 하고, 아내를 실망시킨 순간들이 참 많았었다.
꽤 오랫동안 "상대방을 바꾸려고 하지 말자. 온전히 받아들이자." 라고 생각했다. 그런데 상대방에게 이 생각을 이야기 하면서 "나는 이렇게 생각해. 그러니까 나를 너무 바꾸려고 하지 않았으면 좋겠어." 라고 이야기 하는 모습을 발견했다. 모순이었다.
많은 사람들이 상대방과 가까워질수록, 상대방에 대한 마음이 커질수록, 상대방과 나를 동일시 하게 되는 문제가 있다고 한다. 나는 아닌 줄 알았는데 똑같았다. 나처럼 생각했으면 좋겠고, 나처럼 행동했으면 좋겠고, 나와 반대되는 생각과 행동을 할 때 ‘대체 왜 저렇게 말하는걸까? 왜 저렇게 행동하는걸까? 나라면 안 그럴 텐데..’ 라고 생각했다.
말로는 "우리가 서로를 이해하는게 중요해" 라고 이야기 하지만, 속으로는 상대방을 이해하지 못해 답답해했다. 내 기준으로만 생각하고 내 기준에 벗어나는 현상을 목격했을 때 힘들어한 것이다.
그리고 나 뿐만 아니라 상대방도 똑같은 생각과 똑같은 감정을 느끼고 있었다. 그렇게 우리는 많이는 아니여도 한 걸음 가까워졌다.
그런데 이게 꼭 부부 사이에만 발생하는 일일까? 그렇지 않다고 생각한다.
가까운 친구 사이에서도, 가족관계에서도, 팀 내에서도 일어날 수 있는 일이다. 상대방을 온전히 존중하고 이해하는 일은 무척 어렵고 힘들고 많은 노력이 필요하다.
26년에는 조금 더 성숙한 생각을 할 수 있는 사람이 되어보고 싶다.
여행
사회생활을 시작하면서 해외여행을 한 번도 안 해봤는데, 올해에는 두 번이나 했다!
(1) 신혼여행
신행은 모리셔스라는 곳으로 갔다.
모리셔스는 아프리카 옆, 인도양에 있는 제주도 정도의 크기의 국가다. 천국을 본따 만든 섬이라고 불린다. 좋긴 좋은데 그 정도까진 아닌 것 같다.
날씨는 대체로 무척 좋았고, 굉장히 여유로웠다. 액티비티도 많고(사자와 산책을 한다거나!?), 요트도 타고, 수상레저도 하고, 수영도 하고, 바닷가에 누워서 책도 보고, 정말 푹~~~~~~쉬다 왔다.
다만 모리셔스에서 제일 유명한 헬리콥터 투어를 못한게 너무 아쉽다.
신청은 했으나, 인원 미달로 취소가 되어버렸다… ㅠㅠ
휴양과 액티비티를 적절하게 즐기고 싶었는데, 어쩌다보니 휴양 위주로 하게 되었다. 그래도 나는 너무 만족스러웠던 여행이었다.
(2) 첫 유럽, 포르투갈
연말에 퇴사와 맞물려 장기 휴가를 사용했다. 뉴질랜드/호주 or 일본 or 유럽 중 고민하다가 유럽을 행선지로 한 다음에 유럽에서도 어디를 갈까 하다가 유튜브에 찾아보니 "마지막으로 딱 한 곳을 여행하고 싶다면 포르투갈!" 이라는 내용을 많이 봐서 포르투갈로 행선지를 정했다.
12월 17일 00:30에 출국했고, 1월 2일 09:00에 귀국했다. 어쩌다보니 크리스마스와 새해를 포르투갈에서 보냈다.
1) 포르투
포르투는 도시가 작아서 마음먹으면 하루만에 다 둘러볼 수 있다.
돔루이스 다리는 200년전에 만들어졌는데, 어떻게 그 당시에 이런 건축물을 만들 수 있었는지.. 상상이 잘 안 된다. 경이로웠다.
하루는 도루밸리 와이너리 투어를 다녀왔다. 도루밸리에는 이렇게 산 중턱에 안개가 있는데 풍경이 너무 멋있었다. 사진에 다 담기지 않는게 참 아쉽다.
포르투에서 5km 정도만 가면 대서양을 볼 수 있다. 포르트 둘째날에는 버스를 타고 대서양에 갔었는데, 그 때는 파도가 너무 높아서 깜짝 놀랐다. 그리고 또 하루는 날씨가 자전거를 타고 대서양까지 다녀왔는데 왕복 20km 여서 너무 힘들었다. 전기 자전거를 탔어야해!
7일을 포르투에 머물렀는데, 비가 자주 와서 노을을 보는게 참 어려웠다. 다행히 포르투를 떠나기 전날에 날씨가 좋아서 모루정원에 죽치고 앉아 노을을 구경했다. 그 때의 여유로움이 참 좋았다.
2) 리스본
확실히 포르투보다 리스본이 더 도시적인 느낌이 있었다. 웅장한 건축물도 많았고 전망대가 여기저기 있어서 등산하는 즐거움(?)이 있었다.
3) 신트라, 호카곶 투어
12월 30일에는 신트라 호카곶 투어를 했다.
신트라에 있는 페나성에 갔는데, 해발 500m 정도 되는 위치에 성을 지어놨다. 어떻게 이런곳에 이런 규모의 성을 지었을까? 다시 생각해도 경이롭다. 절벽마을도 잠깐 찍먹했다.
어쩌다보니 계속 일정이 지연되면서 노을이 막 졌을 때 호카곶에 도착했다. 호카곶은 유라시아 대륙의 최서단에 위치해있다. 내가 서쪽 끝에 도달했다니!?
연말에 보는 풍경이라 기분이 오묘했다. 잘 끝내는 느낌. 그리고 새로 무언가를 시작할 수 있을 것 같은 그런 기분.
4) 비행기에서 보는 1월 1일의 일출
26년의 첫 해는 비행기 안에서 볼 수 있었다. 창가자리에 앉을 수 있었다면 좋았겠지만!? 어쩔 수 없지~
2026년 목표
- 26년은 새로운 회사에서 새로운 도전을 할 예정이다. 26년에는 여태까지 하던 모든 활동을 다 접고, 오롯이 회사에 집중할 생각이다. 먼저 신뢰자본을 쌓아놓고 생각하고 싶다.
- 무엇보다 중요한건 건강! 거의 2년사이에 15kg 가까이 쪘다. 어디까지 튀어나올지 모르는 뱃살을 원상복구 해놓을 예정이다. 평소에도 러닝을 꾸준히 하고 있는데, 큰 무리가 없다면 매일 러닝을 할 생각이다. 웨이트도 주 2~3회는 하자.
- 해외여행을 하면서 느낀게 내가 너무 영어에 취약하다. 죽이되든 밥이되든 꾸준히 영어 공부를 할 생각이다. GPT와 친해지면 어찌저찌 되지 않을까?
목표를 너무 많이 세우기보단, 이렇게 큼직하게 세 가지만 집중할 생각이다. 어차피 지내다보면 까먹기 때문
대신 1~3을 달성할 수 있는 작은 단위의 목표를 촘촘하게 만들어서 관리하면 어떨까?
마무리
25년 한 해동안 많은 사람들을 알게 되었고, 회사 내에서도 회사 밖에서도 꽤 많은 일을 했고, 결혼이라는 인생의 큰 이벤트도 있었습니다. 이 순간 느끼는 제일 큰 감정은 겸손함과 감사함입니다.
부족하고 모자란, 황준일이라는 사람과 함께해주신 모든 분들께 감사했어요. 내년에도 잘 부탁드립니다! 새해 복 많이 받으세요~!