오디세이 스포일러가 아주 많이 포함되어 있습니다.

위례 스타필드 시티에 가서 영화 <오디세이>를 보고 왔습니다. 저번에 스파이더맨을 봤던 극장의 IMAX 2열(E열)에서 관람했는데요, 예전에 A열에서 봤을 때보다 훨씬 쾌적했습니다. 생각보다 E열은 스크린이 한눈에 들어와서 아주 좋더라고요. 비록 '용아맥(용산 CGV IMAX)' 수준은 아니지만, 개인적으로는 나쁘지 않았고 영화 자체를 즐기기에는 크게 문제없는 자리였습니다.

영화 내용이야 다들 아실 테니 굳이 길게 얘기할 필요는 없을 것 같습니다. 사실 이 영화를 보러 가기 전에, 영화 유투브에서 랄프 파인즈이 출연했던 예전 <더 리턴> 버전을 본 적이 있습니다. 그런데 그때 보면서도 '왕'이라고 나오는 인물들이나 왕궁에 있는 사람들이 너무 초라하고 거지나 부랑자 같은 느낌이 강해서, 제 취향과는 좀 안 맞는다고 생각했습니다. 저는 좀 더 웅장한 중세 기사 스타일의 연출을 기대했거든요.

아쉽게도 이번 크리스토퍼 놀란 감독의 <오디세이> 역시 그런 면에서 개인적인 취향과는 조금 맞지 않는 부분이 있었습니다. 관람 전에 '스토리 캠프'를 통해 원작 소설의 줄거리를 미리 듣고 갔는데, 원작에 비해 영화에서 조금 생략된 부분들이 있는 것 같기도 합니다.

그럼에도 개인적으로 재밌었고 좋았던 부분을 꼽자면, 결국 바다를 통해 귀향하는 스토리다 보니 바다를 묘사한 연출이 아주 훌륭했습니다. 끝없는 대양을 보여주거나 칠흑 같은 바다 위에서 인물들이 고군분투하는 장면들, 그리고 그 과정에서 전해지는 웅장한 사운드와 시각적 경험은 정말 좋았습니다.

또 좋았던 부분은 망자와 만나는 씬이었어요. 오디세우스가 망자인 시논과 아가멤논을 만나는 장면은 굉장히 좋았습니다. 사실 그 장면을 어떻게 구현할지 고민이 많았을 텐데, 연출의 밀도가 아주 높았어요. 어두운 곳에서 유령들이 좀비처럼 일어설 때 느껴지는 공포감이 훌륭하게 다가왔습니다.

반면 아쉬운 부분도 있었습니다.

• 마지막 연회장 전투 씬은 좀 더 극적이었으면 좋았을 것 같아요. 예전에 봤던 랄프 파인즈 주연의 영화 버전과 비교해 보면, 이번 버전은 확실히 등장인물이 너무 많은 느낌이었습니다. 약간 늘어지는 느낌이 있었다?
• 원작 특유의 재치 있는 에피소드들이 생략된 점도 아쉽습니다. '노바디(아무도 아니다)'라고 답하며 위기를 모면하는 오디세이의 재치나, 마지막에 침대를 이동시켜 달라는 대화를 통해 서로를 확인하는 그리스 로마 신화 특유의 묘미들이 많이 없는 부분이라 아쉬움이 남습니다.
• 헬레네에 대한 부분은 뭐 다들 아실거니까. ㅎㅎ

솔직히 말씀드리면,
이번 영화를 보며 크리스토퍼 놀란 감독의 폼이 좀 떨어졌다는 생각을 지울 수 없었습니다.

개인적으로 놀란 감독의 정점은 웅장함과 예술성, 대중적 재미를 모두 잡았던 <다크 나이트>와 <인셉션>이라고 생각합니다. 하지만 <오펜하이머>부터는 도대체 무엇을 말하려는 영화인지 알 수 없을 정도로 개인적으로는 최악이었어요.

이번 <오디세이> 역시 원작이라는 탄탄한 기본 스토리가 있으니 상상 속 화면을 어떻게 구현할지 기대했는데, 그저 예상한 수준으로만 나온 것 같습니다. 물론 몇몇 장면은 잘 만들었지만 기대치에는 미치지 못했습니다.

요즘 시대에 관객이 느끼는 재미의 관점에서도 아쉬움이 큽니다. 컴퓨터 그래픽과 AI가 고도로 발달한 시대에, 감독이 '실제 외눈박이 모형을 만들었다', '진짜 바다 위에서 촬영했다'라는 사실만으로 작품을 지나치게 고평가하는 것은 아닌가 싶습니다. 결과물로서 영화를 소비하는 관객 입장에서는 그것이 본질적인 재미를 주지 못하니까요. 마치 이렇게 고생했다고!! 를 외치고 강요하는 듯한 느낌.

스토리 면에서도 주인공 오디세우스의 캐릭터가 몰입을 방해했습니다. 맷 데이먼이 고생하는 모습을 보면서 영화 그리스 신화판 <레버넌트> 같다는 생각이 들었는데요. <레버넌트>의 주인공은 동료의 배신으로 고난을 겪지만, 오디세우스는 본인 스스로 화를 자초하는 빌런 짓을 반복합니다. 왜 굳이 외눈박이 거인에게 화살을 쏘는지 이해가 안되고, 실제로 동료가 물어보는데 대답을 못하죠. 곱게 집으로 돌아가면 될 것을, 자기 영민함과 총명함을 뽐내려다 화를 부르는 모습을 보며 "제발 그만 좀 해라"라는 생각이 절로 들었습니다. 세이렌 부분에서는 진짜 제발 그만좀해라하는 마음이었어요.

포스터에 나왔던 황금 투구 장식의 아가멤논 캐릭터도 비중에 비해 너무 허무하게 소비되어 아쉬웠습니다. 포스터만 보면 엄청나게 웅장한 전투 씬이 있을 것 같지만, 실제로는 그런 장면이 전혀 없다는 것이 이 영화의 가장 큰 스포일러입니다.

최근에 개봉한 세 작품을 개인적인 재미 기준으로 비교하자면 다음과 같습니다.

1. 스파이더맨 (가장 만족스러움)
2. 오디세이
3. 호프

물론 세 영화의 성격은 아주 다릅니다. <호프>는 완전한 상상력의 영역이고, <오디세이>는 검증된 고전 원작이 있으며, <스파이더맨>은 마블이라는 탄탄한 세계관을 기반으로 하니까요. 주관적인 재미로는 <스파이더맨>을 추천하지만, <오디세이> 역시 워낙 화제작이라 한 번쯤 볼 만은 합니다. 2시간 55분이라는 거의 3시간에 달하는 러닝타임 동안 지루하지 않게 볼 수 있는 작품이긴 합니다.

일단 호프는 외계인의 침공 같은 느낌으로 보긴 했고, 스파이더맨은 별 기대 없이 봤는데 각각의 얘기를 좀 해보면 재밌을 것 같아서 그냥 지금 마이크를 켜고 얘기를 하고 있다.

⚠️ 충분히 스포일러를 담고 있으니 참고

<호프>

전반부 약 50분 동안 황정민 배우가 나오는 파트에서는 외계인이 거의 등장하지 않는다. 이 부분을 좋게 보시는 분들도 있겠지만, 제 개인적으로는 초반이 약간 지루하게 느껴졌다.

하지만 그 이후 정원 장면부터 액션 씬이 휘몰아치고, 다시 산에서 한 번 더 몰아치는 연출은 정말 재미있었다. 확실히 긴장감 넘치는 장면들에서는 연출이나 카메라 워크가 아주 훌륭했다. 최근 넷플릭스 같은 OTT에서 보던 작품들은 예전만큼 대작 느낌이 덜해서 가볍게 소비하듯 보곤 했는데, 이 영화는 극장에서 볼 만한 가치가 있다는 생각이 들었다.

다만 개인적으로 아쉬운 부분들도 몇 가지 있었다.

가장 아쉬운 점은 설정이 다소 과도하고 불협화음이 느껴진다는 것이다. 외계인이 등장하는 설정을 감안하더라도 도대체 어느 시대인지 가늠하기 어렵다. 스마트폰이 없는 걸 보면 확실히 요즘 시대는 아닌 것 같고, DMZ 근처라는 배경까지는 이해하겠는데 인물들의 비주얼이 너무 따로논다.

1. 황정민의 패션: 독일 장교처럼 입고 나오는 패션이 어딘가 어색하고 이상했다.

2. 조인성 패거리의 비주얼: 트럭커 패션 같은 스타일도 이상할뿐더러, 왜 그렇게 씻지 않은 것처럼 더럽게 묘사했는지 의문이 든다.

3. 어촌계 인물들의 패션: 반면 뒤이어 어촌계에서 나오는 세 분은 금팔찌를 차고 파란색 옷을 입는 등 굉장히 패셔너블하게 등장한다.

이 세 그룹의 비주얼 톤앤매너가 너무 맞지 않아서 몰입을 방해했다. 의도된 설정인지는 모르겠지만, 전체적으로 조화롭지 못하고 겉도는 느낌이 강해 아쉬웠다.

영화 후반부의 말 타는 액션 같은 장면들은 개인적으로 아주 좋았다. 다만 구성상 아쉬운 점들을 몇 가지 정리해 보자면

1. 개그 장면의 늘어지는 템포: 일부러 웃기려고 연출한 장면들의 호흡이 너무 길다. 할아버지 다리 밑 장면이나, 말과 차를 오가며 왔다 갔다 하는 씬이 대표적이다. 개그/유머에 대한 부분을 3분의 2 정도로만 줄였어도 훨씬 좋았을 텐데, 전체적으로 분량이 길어져서 아쉽다. 감독의 의도가 있었겠지만 조금 과한 느낌이 든다.

2. 결말과 떡밥 회수: 관객들 사이에서 쿠키 영상과 마지막 부분을 바꿨어야 한다는 의견이 많고, 나 역시 그 생각에 공감한다. 제작진도 이 부분을 고민했을 텐데, 차기작을 염두에 둔 의도적인 선택이었는지는 지켜봐야 할 것 같다. 예전에도 이런 3부작짜리 SF 영화가 있었던 것 같은데, 뿌려둔 떡밥들이 앞으로 잘 회수될지가 아니면 한국 SF 영화의 고질적인 아쉬움으로 남지 않을까 우려된다.

3. 외국 배우 캐스팅의 의문: 외계인 역할에 굳이 외국 배우를, 그것도 마이클 패스벤더 같은 배우를 쓸 필요가 있었는지 의문이다. 솔직히 연기라고 할 만한 부분이 거의 없어서 AI로 대체해도 무방했을 수준이다. 마지막에 대사 자막이 나오는 장면 외에는 굳이 그 배우의 연기력이 필요한 대목이 있었나 싶다.

그럼에도 이번 영화 <호프>가 개봉하면서 긍정적인 영향도 분명히 있다. 워낙 대작이자 기대작이다 보니 트위터나 유튜브 등에서 많은 이들이 세계관을 분석하고 상상의 나래를 펼치는 '상상 글'들이 쏟아지고 있는데, 이런 현상을 지켜보는 재미가 쏠쏠하다.

관객들이 영화를 여러 번 곱씹어 보고, 다회차 관람을 하거나 GV(관객과의 대화)를 찾아보는 문화가 활성화되는 계기가 된 것은 확실해 보인다. 이런 활기가 영화 산업 전반에 좋은 자극이 되기를 바란다. 개인적으로는 <호프 2>와 <호프 3>도 계속해서 나와주었으면 좋겠다.

<스파이더맨 브랜드 뉴 데이>

사실 스파이더맨 시리즈를 그리 좋아하지는 않았다. 예전 토비 맥과이어 버전을 굉장히 좋아하긴 했지만, 스파이더맨이라는 캐릭터 자체가 항상 너무 불행하게 나오는 게 보기 힘들었거든요. 돈도 없고, 여자친구도 맨날 뺏기고, 가족도 죽고, 왜 이렇게 맨날 불행해야만 하는지 그 불행을 보는 게 짜증이 나서 그동안 잘 안 보게 되었다.

이번 톰 홀랜드 버전도 원래 볼 생각이 없었다. 전편을 안 봐서 주인공이 왜 친구들의 기억에서 잊혀졌는지도 모르는 상태였는데, 동생 집에 갔다가 우연히 같이 극장에 가서 보게 되었다.

그런데 생각보다 정말 재밌게 봤다.

• 영웅의 고뇌나 피해를 입지 않으려고 애쓰는 모습 등 스토리는 뻔하지만, 연출이 훌륭해서 2시간 30분이라는 러닝타임이 전혀 아깝지 않고 만족스러웠다.
• 이전에 봤던 블랙 위도우 같은 아쉬웠던 마블 영화들에 비하면 훨씬 훌륭했고, 대중적으로 아주 잘 만든 영화라는 생각이 든다. 마블의 세계관이나 디테일한 설정은 잘 모르지만 전체적인 스토리가 나쁘지 않았다.

두 영화를 보고 느낀 점

<호프>는 나홍진 감독의 전작 '곡성'을 완벽히 이해하지 못한 상태였어서, 유튜브로 곡성 해석 영상을 찾아보며 나름대로 공부를 하고 갔다. 그런데 오히려 그게 독이 되었던 것 같다. 영화를 보는 내내 모든 장면과 인물이 의심스러웠다.

• '조인성이 죽지를 않는데, 혹시 외계인인가?'
• '아니면 황정민이 외계인인가?'
• '무슨 바이러스가 있는 건가?'

계속 이런 생각이 꼬리를 물고 감독의 숨은 의도를 찾으려고 애쓰다 보니 영화를 보는 것 자체가 너무 피로하고 힘들었다. 어떻게 보면 그 혼란 자체를 감독의 의도였을지도 모르겠다.

하지만, 단순히 즐기기에는 아무 생각 없이 편하게 볼 수 있었던 스파이더맨이 개인적으로 훨씬 좋았다. 스파이더맨은 '결국 이렇게 흘러가서 적응하고 해결하겠지' 하는 뻔한 흐름을 알고 보니까 머리 쓸 필요 없이 푹 빠져서 즐길 수 있었다. 개인적으로 둘다 보기를 추천하지만, 아주 다른 취향을 가지고 있는 몇명이서 볼거라면 나는 스파이더맨을 더 추천할 것 같다.

일단 이 글은 순수하게 100% 음성으로, DJI 마이크와 Typeless를 통해 초안 작성되었음을 밝힌다.

클로드를 이용해 코딩하는 일은 이제 너무나 보편화됐다. 다만 내 성향상 여러 가지 AI를 동시에 써보며 다양한 시도를 하는 편은 아닌 듯하다. 예를 들어 Qwen 같은 로컬 AI나 다른 도구들에는 개인적으로 크게 관심은 없고(이건 나중에 다른 글에서 애기하고 싶음), 최근에는 AI Nativce Company를 만드는 일에 더 많은 관심을 두고 있다.

당근마켓에서 오픈클로(openclaw)를 처음 접한 이후 여러 국내 사례들을 보게 됐다. 그때부터 클로드 코드를 이용해 봇을 만들고 테스트하는 작업을 계속해 왔다.

처음에는 ‘cclaw’라는 이름으로, 텔레그램에 클로드 API를 연결하고 앞단에 웹서버를 두어 대답해 주는 방식을 만들었다. 그러다 텔레그램 형태가 데스크탑 환경에서는 조금 번거롭다는 생각이 들었고, 웹 대시보드/채팅을 직접 구축했다. 대시보드 안에서 봇들에게 특정 페르소나(Personality)나 아이덴티티, 목표 등을 부여하고, 봇을 조금 더 쉽게 만들 수 있는 환경을 구축해 현재까지 사용하고 있다.

그 이후에는 크론탭(Cron)이나 하트비트(Heartbeat)을 만들었고 정기적으로 실행해야 하는 작업들을 만들었다. 오픈클로 개발자분이 만든 gog 등을 활용해 구글 워크스페이스 기반의 이메일 자동화를 구축했고, 다양한 크롤링이나 자료 수집처럼 루틴화된 작업들을 자동화하는 형태로 유용하게 사용하고 있다. 예를 들면, 주말나들이 계획을 목요일 오전에 조사하게 만든다거나, 클리앙의 중고기기 매물들을 매일 요약해서 보여주거나 하는 식등.

처음에는 이 프로젝트를 오픈소스 형태로 만들고자 했다. 하지만 개발을 진행하면서 점차 오픈소스 방식을 포기하게 됐다. 가장 큰 이유는 개인적인 성향과 필요에 맞춘 기능들에 집중하게 되었기 때문이다. 오픈소스는 좀 더 범용적인 기능을 개발해야 하지만, 나는 나만의 개인적인 워크스페이스를 활용하는 방향으로 자연스럽게 방향을 잡게 됐다.

특히 ‘스킬’ 기능에 대한 고민이 컸다. 나는 빌트인(built-in) 스킬을 제공하고, 추가 스킬을 CLI를 통해 봇에 붙이는 방식으로 개발했다. 하지만 나에게는 필수적인 네이버 지역 정보나 지도 API 같은 기능이 한국 사람에게는 당연할지 몰라도, 글로벌한 오픈소스 관점에서는 보편적인 빌트인 스킬이 아닐 수 있다는 점을 깨달았다.

시스템의 구조도 처음에는 단순히 비서나 집사, 자료 조사용 봇 두 개 정도를 두는 수준이었다. 나라는 사람에게 AI에이전트가 필요한가? 하는 생각이 많이 들었고, 여러 다양한 자동화를 하시는분들을 보면 부러웠다. 하지만 지금은 마치 하나의 회사 같은 형태로 봇들을 만들었고 사용하고 있다.

• 개발자
• 마케터
• 디자이너
• 리서처
• 데이터 분석가
• 총괄 PM

이렇게 자연스럽게 확장하다 보니 단순한 채팅을 넘어선 그룹 형태로 발전하게 됐다. 이에 따라 오케스트레이션(Orchestration) 방식에 대해서도 많이 고민하게 됐다.

처음에는 PM 역할을 하는 하나의 오케스트레이터가 내부에서 대화를 갈무리하고, 결정된 사항만 나에게 전달하는 방식을 구현해 보았다. 하지만 이 방식은 실제 대화 과정을 내가 직접 볼 수 없다는 문제가 있었다. 그래서 현재는 멤버들이 각자 그룹 대화에서 직접 이야기하는 방식을 주로 사용하고 있다. 또한 리니어(Linear)를 연동해 태스크를 생성하고 수행하도록 구성했다.

기술적인 구현 측면에서는 ‘Claude Code’의 영향이 컸다. 일반적인 클로드 세션을 사용하는 것이 아니라, 별도의 마크다운 파일을 활용해 대화를 관리한다. 또한 대화에서 지식을 추출해 벡터 데이터베이스(Vector DB) 기반의 지식 베이스를 구축하고 활용하고 있다.

아래는 현재 진행 중인 작업과 앞으로의 구상, 그리고 이번 주 개발 진행 상황을 정리한 내용이다.

현재 남은 작업과 자동화 현황

에이전트들에게 앱이나 웹 개발을 많이 시키고 있다. 웹은 배포가 그리 어렵지 않지만, 앱 개발의 경우 테스트와 배포 자동화 부분이 아직 미진하다. 이 부분을 스킬로 만들어 붙이는 작업을 계속 진행 중이다.

최근에는 다음과 같은 작업들을 각 봇에 연결해 자동화를 완료했다.

• 인스타그램 연동 작업
• 파이어베이스 애널리틱스(Firebase Analytics) 연결을 통한 분석 작업
• 명령을 내리거나 보고를 받아 데이터를 추출하면 자연스럽게 요약해 주는 작업

AI Native Company 회사의 방향성 구상

앞으로 이 시스템을 실제 회사 형태로 발전시키기 위한 구상을 하고 있다. 내가 사장이고 에이전트, 즉 봇들이 회사원이라고 가정 했을 때, 현재는 코딩 후 PR을 올리는 등의 과정에서 최종 결과물 확인과 앱 배포를 여전히 내가 직접 하고 있다. 이 확인 절차를 어떻게 하면 더 신뢰성 있게 자동화할 수 있을지가 남은 과제다.

또한 스타트업들이 슬랙(Slack)과 노션(Notion)에 의사결정의 역사와 데이터를 남기듯, AI Native Company에서도 데이터를 남길 방법이 필요하다.

1. 소통 채널은 내가 자체 제작한 메신저를 슬랙처럼 활용한다.
2. 데이터 축적 및 동기화는 내가 만들지 않은 외부 서비스인 노션에 의존하기보다는, 깃허브(GitHub) 레포지토리에 주기적으로 싱크하는 방식을 구상하고 있다.
3. 데이터 활용은 싱크된 데이터를 다시 로드하는 시점에 로컬 벡터 DB를 이용해 보여주는 방식을 생각하고 있다.

모바일 앱 개발 프로세스 및 Swift 전환

이번 주에는 모바일 버전 개발에 큰 변화가 있었다.

첫 번째 버전은 PWA 기반의 모바일 버전이었다. 초기에는 대시보드 기반의 채팅 형태로 만들었으나, 로딩이 원활하지 않고 푸시 기능 적용도 애매했다.

두 번째는 플러터(Flutter) 버전이었다. 크로스 플랫폼 프레임워크로 재구현했으나, 아이폰 기준으로는 확실히 네이티브 특유의 부드러운 느낌이 떨어진다는 아쉬움이 있었다.

세 번째는 스위프트(Swift) 버전이다. 네이티브 느낌을 살리기 위해 이번 주 화요일에 Swift로 완전히 갈아엎었다. 순수 개발 시간은 1시간도 채 걸리지 않았지만, 결과물은 상당히 만족스럽다. 현재는 API 토큰이 부족해 잠시 개발을 멈춘 상태다.

지금은 나 혼자만 사용하는 시스템인 만큼, 앞으로도 웹과 함께 네이티브 앱의 형태를 계속 유지하며 가져갈 생각이다.

그 외에도 자잘하게 만든 것들이 많다. 결국 이 시스템 자체가 집에 있는 로컬 맥 프로에서 돌아가고, Tailscale을 통해 통신하는 방식으로 구현되어 있다 보니 에이전트들이 작업한 결과물을 외부에서 보고 싶을 때 잘 되지 않는 느낌이 있었다.

예를 들어 디자이너 에이전트에게 일을 시켜 이미지가 나오면, 외부에서도 모바일 앱으로 그 결과물을 보고 컨펌하고 싶다. 그런데 봇에게 메신저로 이미지를 올려달라고 하는 방식에는 한계가 있었다. 그래서 ‘워크스페이스’라는 개념을 만들었다. 워크스페이스에 파일을 올리면 외부에서도 보고, 삭제하거나 다운로드할 수 있는 기능을 만들어 사용하고 있다. 생각보다 편해서 잘 쓰고 있다.

그 외에 특이한 것은 아직 없다. VPS에 올리는 작업은 아직 나에게 그렇게 필요하지 않은 것 같다. 오히려 맥 미니가 더 필요하다는 생각이 점점든다. 주 기종인 맥북프로를 집에서 가지고 나가는 경우가 생기는데 이럴때는 작업을 할 수가 없다.

마치며

지금은 토큰이 없는 상태라 블로그 글을 음성으로 쓰고 있는데, 세상이 많이 변했다는 생각이 든다. 오늘 버스를 타고 오면서 든 생각인데, 예전에는 개발하는 일이 굉장히 신나고 재미있었다. 그런데 요즘 회사에서 개발하는 일에는 어느 정도 제약이 많다. 협업을 위한 관습과 방식, 안전장치들이 있기 때문이다. 반면 AI 툴은 굉장히 많은 것들을 가능하게 해주고, 제약도 적다. 회사에서는 내가 만들고 싶은 것이 아니라 만들어야 하는 것을 만들어야 하니, 조금 재미가 없는 것도 사실이다.

그러다 보니 많은 사람들이 회사 밖에서 사이드 프로젝트로 다양한 것들을 만드는 것 같다. 나 역시 지금 이런 사이드 프로젝트를 포함해 개인적으로 다양한 툴을 만들고 있다. 아이폰 개발자 계정을 유지하기 위해 1년에 15만 원 정도를 내고 있는데, 솔직히 돈이 아깝다는 생각은 전혀 들지 않는다. 이미 직접 만든 앱만 6~7개 정도 되고, 아이폰 홈 화면 하나를 내가 만든 앱으로 다 채울 정도다. 오히려 개인적인 개발의 재미와 아이디어가 많이 샘솟는 느낌이다.

물론 비즈니스적으로나 경제적으로 성과가 있으면 더 재미있을 것이다. 하지만 아직 그 정도는 아니다. 이 부분은 다른 1인 개발자들이 이야기하는 것처럼 마케팅이나 인스타그램 활동 등을 더 잘해야 할 것 같다. 그리고 이런 과정도 어떻게 하면 더 자동화할 수 있을지 고민하고 있다.

“공부를 하고 있나”라고 생각해보면, 사실 예전 스타일의 공부를 하고 있는 것 같지는 않다. 하지만 AI 시대에 들어온 본질적인 의미에서의 ‘메이커’로서는 성장하고 있다고 본다. 무언가를 잘 만들어 문제를 해결하고, 또 잘 서빙하는 것을 목표로 하고 있으니 그런 관점에서는 잘하고 있지 않나 싶다.

AI 활용 자체도 이제는 우리 부모님 세대인 70대분들까지 ChatGPT에서 검색해 나에게 결과를 보내주실 정도로 많이 발전했다. 어떻게 하면 AI를 더 잘 쓸 수 있을지 계속 고민하게 된다. 나는 로컬 AI만을 지향하는 쪽은 아니다. 가격 정책 등의 변수는 있겠지만, 아직은 로컬만 고집하기 어렵다고 생각한다.

내가 만든 AI 네이티브 컴퍼니를 공개할 날이 올지는 모르겠다.
다만 현재는 이런 것들을 만들며 생활하고 있다는 정도로 봐주면 좋겠다.

26.07.11
글을 쓰는 기간동안 기존의 애매한 개인-회사 사이의 시스템을 버리고 AI Native Company에 필요한 것들만 새로 추렸다. 쓰지않는 스킬과 봇을 버리고 진짜 서비스를 잘 개발하기 위해서 필요한 스킬과 에이전트들을 배치하고 있다.

앞으로 무엇을 해야 할까? 하는 생각들로 정말 하루에도 수없이 고민을 많이 하게 되는 것 같고, 특히 지금 내가 하는 게 이걸 지금 하는 게 맞는가? 라는 실존적 고민을 하게 된다. 돌이켜보면 20대에는 기술자가 되기 위해서 공부와 경험을 하는 시기였고, 30대에는 다양한 프로젝트와 커리어를 위해서 이직도 하고 직책도 바꿔가면서 지내왔는데, 40대 초반에 들어서니 그 다음은? 부분에서 많이 고민이 된다. 누군가는 이 고민이 사치스럽다고 할 수도 있고, 누구나 가는 일반적인 길이 있는데 왜 고민을 하냐고 생각할 수도 있다. 지금 해왔던 것처럼, 다른 일반적인 사람들처럼 지금까지 해왔던 커리어를 가지고 새로운 기회를 찾고, 더 큰 문제를 해결하고 조직을 관리하는 역할로 가는 게 가장 일반적인 형태일 것 같다. 그러나 그 선택을 주저하게 되는 건, 그 삶의 모습이 현재와 크게 다르지 않을 것 같아서다. 아침에 일어나서 출근을 하고 동료들과 회의를 하고 다양한 일을 하고 다시 퇴근을 하고 이런 삶. 내 문제가 아닌 다른 문제의 방법들을 구현하는 일. 평일에 일을 하고 주말에는 쉬거나 밀린 일을 하고. 삶이 뭐 그리 다를 게 있겠냐 싶지만, 그럼에도 불구하고 이 삶의 모습이 내가 원하는 궁극적인 모습인가? 앞으로 30년 이상을 더 할 수 있어? 에는 스스로 물음표를 던지게 된다. 이 근원적인 물음에 대한 답을 내리는 데 시간이 조금 걸렸다. 아니 어쩌면 답은 이미 알고 있었는데 그걸 스스로 마주하기까지 시간이 좀 걸렸던 것 같다.

내가 내린 결론은 내가 원하는 모습이 되기 위해서 진짜 처절하게 그리고 냉정하게 살아야 한다는 것이다. 열심히 살다 보면, 좋은 회사를 다니고, 좋은 커리어가 되어서 좋은 집에서 잘 살겠지 하는 생각은 우연에 우연을 거듭해야 가능한 것이다. 과거의 여러 선택들의 합이 현재의 나의 모습이라고 한다. 그렇게 보면 지금의 나의 모습은 정말 여러 우연과 우연들, 그리고 수많은 운이 좋은 결과라고 볼 수밖엔 없다. 어떤 사람들은 그래도 내 모습에 대해서 좋게 봐주시고, 감사해야 하는 것 아니냐는 얘기들을 해주시는 분들이 있는데, 감사한 것은 감사하지만 나는 다른 모습으로 사는 나를 원하고 있다. 그렇기 위해서 지금의 나는 다른 선택을 해야 한다. 현재의 내 삶의 흐름에 휩쓸려 내려가기 시작하면 답이 없다. 그 방향이 맞다면 상관없겠지만 그게 아니라면 나는 보트에서 내려서 산으로 올라가야 한다.

자기증명

이런저런 고민들과 나의 현재의 모습, 앞으로 원하는 모습들을 고민하다가, "자기증명"이라는 단어가 떠올랐다. 내가 아무리 "나는 이런 삶을 살고 싶어요."라고 외쳐도 소용이 없다. 세상은 나한테 관심이 없고, 내가 나를 표현하는 방법은 현재의 나의 모습뿐이다. 그래서 나는 나 스스로를 내가 원하는 모습으로 만들어야 한다. 그게 나를 증명하는 유일한 방법이다. 그리고 이 불만족과 수많은 번뇌를 끝낼 수 있는 유일한 길이다.

chatgpt로 시작해서 cursor를 썼었고 지금은 claude code를 쓰고 있다.
어떻게 보면 물어보는 단계에서 부분적으로 첨삭을 받는 단계
그리고 이제는 맡기는/위임(delegation)을 하는 단계에 온 것 같다.

개발자들이랑 얘기해보면 이제 뭐 먹고 사냐,
미용/미장을 배워야 한다는 얘기도 자조 섞인 얘기들도 많이 하는 것 같다.

그럼에도 AI와 뭔가를 하는 것은 즐겁다.
직업적인 의미에서의 개발자의 종말보다는
개발자라는 사람들이 가지고 있는 본능이 더 깨어나는 느낌이다.

뭔가 만들고 싶고, 개조하고 싶은 그런.

뭔가 claude code 이전에 AI 코딩툴을 쓰거나 할 때에는 아이를 키우는 느낌과 비슷했다.
해야 하는 일과 역할을 정해주고
기억해야 하는 것과 하지 말아야 하는 것을 가이드하는 것은
집안에서 애한테 맨날 하는 잔소리에 비슷했다.

내가 더 많이 알고 있으니까
너는 이렇게 해야 하는 식이 강했다.

근데 지금은 상호교류를 하는 방식으로 나도 바뀌고 있는 것 같다.
이게 뭐야? 이거 어떻게 구현해줘 이렇게 물어보는 경우도 있지만

최근에는 너라면 어떻게 구현할래? 너는 어떻게 생각해? 이런 경우에는 문제가 되지 않아?
이 부분 같이 좀 봐줘 이런 말투를 쓰게 되고
AI를 대하는 나의 자세가 같이 옆에 앉아서 물어보거나 하는 식으로 된 것 같다.

거기서 내가 발견하지 못한 것들을 발견하는 재미가 있다.

이세돌이 말하는 알파고 이후, 바둑기사들이 오히려 AI를 통해서 영향을 받는 게 개발자들에게도 오고 있다고 생각한다.

--

또 다른 재미는 단연 만듦의 재미다.

개발자는 예전부터 뭘 만들려면 우선 공부를 해야 했다.
언어나 구조를 공부하는 시간이 있었는데 사실상 그게 엄청 단축이 되었다.
그러다 보니 바로 그 다음 단계인 만드는 단계로 바로 넘어가는 것이다.

게다가 빨리 어느 정도 워킹하는 수준까지 만들어주니 이건 진짜 도파민이 터질 수밖에 없다.
트위터에서 보면 어떤 분은 디즈니나 다른 OTT 구독을 끊는다고 할 정도다.

요즘 나의 하루는 AI와 함께 시작해서 AI로 끝난다.
출근하면서 텔레그램으로 몇 개의 프로젝트 구현 지시하고 보고 받고
회사에 오면 회사일을 클로드 코드로 진행한다.
코드뿐만이 아니다.

개인적으로 cowork는 잘 쓰지 않고,
로컬에 디렉토리 만들고 파일 다운받거나 자료 넣어서 클로드 코드로 작업을 진행한다.
뭔가를 읽고 고치고, 보고서를 쓰는 건 결국 다 텍스트 제너레이션이고 그건 클로드 코드가 제일 잘한다.

퇴근을 하면 밥을 먹고 바로 컴퓨터에 앉아서 사이드 프로젝트를 진행한다.
한 3-4시간 정도 사이드 프로젝트나 AI 관련 테스트를 해보다가 자는 게 일상이다.
아이들이랑 아내에게 미안해질 정도.

빠르게 실행하지만 결국 사용자가 쓰게 만들고 lovable한 제품을 만드는 게 중요한 시대인것 같다.
또 다른 건 나에게 체화를 하는 게 더 중요하게 생각해야한다.
너무 많은 기술과 아티클이 쏟아지는데,
내가 중심을 잡고 나한테 필요한 것을 셋업해 나가야 한다.

마치 고수의 무공을 나에게 주입해주는데 내가 다 받다가는 주화입마가 올 것 같은 느낌이다.

--

openclaw를 써보고 가장 놀란 건 openclaw 자체가 아니었다.
나라는 사람에 대한 이해.
다른 사람들이 쓰는 것을 보면
주식을 분석하거나 뭔가를 리포팅을 받거나 하는 등의 자동화를 하는데 나는 그럴 게 없었다.

거의 유일하게 해본 게 아내에게 imessage로 문자가 오면 openclaw가 답해주게 하는 정도?

왜 나는 그런 케이스가 발견이 안 될까?를 곰곰이 생각해보니
너무 삶이 단순하기 때문이라는 결론에 이르렀다.

취향이 무기가 되는 시대라는 말이 정말 맞다.
크게 취향이 없고 뭘 궁금해하지 않다 보니 자동화할 것도 없었다.

그렇게 나에 대해서 깨달은 다음에, 그래도 뭔가 더 해보려고 하고 있다.

• 매일 아침 6시 날씨 요약
• 매일 아침 9시 전날 메일 요약 및 답장해야 하는 것 확인
• 매일 오후 8시 클리앙 데일리 요약

openclaw를 쓰지는 않고 있고,
openclaw와 비슷한 별도의 툴을 만들어서
텔레그램을 연결해서 원격에서도 봇으로 작업을 지시하는 형태로 쓰고 있다.

--

은퇴한 개발자들이 클로드 코드에 멱살 잡혀서 다시 현업으로 나온다는 얘기가 있다.
근데 진짜 그럴 것 같다. 만드는 것에 대한 제약이 없어진 느낌. 마치 능력개방 같은 느낌.
그러다 보니 여러 가지에 관심이 간다.

이제는 물어보고 찾고 하는 게 너무 쉬우니까
스마트 팜 관련 IoT 제품을 구매를 해서 구축해보려고 생각 중이다.
예전에는 이런 것을 하려면 다 카페나 사이트 들어가서 조사해서 진행해야 했는데
이제는 조사는 AI가 해주고
거기에서 나한테 필요한 것을 선별하면 되니 너무 편하다.

그리고 그것들을 내가 지금은 알지 못하더라도
연결할 수 있는 방법을 쉽게 찾고 구현을 할 수 있다.

--

세상이 어떻게 변할지, 한 달 후, 6개월 후를 모르겠다.
그럼에도 불구하고 지금 이 재미를 놓치고 싶진 않다.

일단 모바일을 해야한ㄴ다고 생각한 이유가, 앉아서 맥북을 켤 수 없기 때문인데 그래서 생각한 방법이 아이콘 터미널 앱 -> Tailscale -> 맥북 클로드 코드 실행 이런 순서이다.

사실 Tailscale 은 이미 이전 글 : 인텔 맥북 개발서버로 세팅하기에서 집에서 사용하지 않는 맥북프로 터치바로 SSH 접근을 할 수 있게 셋업을 해두어서 그것을 쓰면 된다. 문제는 어떤 터미널 앱을 쓸 것인가인데, AI는 Blink Shell을 추천했지만 유료여서 제외를 했고, MOSH를 지원한다는데, 사실 나는 5G만 쓰기 때문에 전환이 없을거라서 제일 익숙한 Terminus앱을 사용을 했다.

pem 파일을 아이폰 파일로 넣어서 ssh로 접속을 하게 했고, 미리 맥북프로에 클로드 코드를 셋업을 해두었다. 물론 이렇게 쉽게 되면 글을 쓸 필요가 없는데, Claude Code가 아이폰 Terminus에서 접속을 하면 인증을 요구하는 문제가 생겨서 그 부분은 /login을 쳐서 나오는 URL을 복사를 해서 맥에서 웹 브라이저로 인증을 받아서 토큰을 다시 복사해서 아이폰에 넣는 식으로 진행을 했다. 여기서 꽤 삽질을 오래한 부분은 terminus에서 복사한 URL이 개행이 되는 시점에 빈칸(whitespace)가 들어가는 문제가 있어서 이 부분은 한번 꼭 텍스트 편집기에 붙여서 확인해보길 추천한다.

셋업을 한 뒤로는 아이폰에서 tailscale VPN을 활성화하고, Terminus에 들어가서 ssh에 접속해서 claude code를 사용하면 된다.

• 2개의 물리적 환경

  • 회사와 집
  • 2개의 맥(mac)에서 사용

• 2개의 논리적 환경

  • 회사 프로젝트
  • 개인 프로젝트

결국 내가 원하는건 2개의 물리적으로 독립된 맥에서 2개의 환경이 잘 쓰이길 원했다. 처음에는 회사 컴퓨터에서만 주로 작업을 하다보니 회사에 관련된 환경만 셋업을 했었는데 집에서도 작업을 할 경우가 있다보니 그것들을 가져올 필요가 있었다. 그리고 2개의 논리적 환경이 공통화된 영역도 있고 다른 영역도 있다. 예르들면, 문서화하는 부분 README.md, CLAUDE.md를 작업후에 정리하는건 똑같은 루틴이지만, git 브랜치 전략이나 세부적인 작업 영역은 다르다. 개인 프로젝트에서는 main 브랜치 위주로 작업하고 커밋하지만 회사에서는 feature-pr 방식으로 일을 한다.

그래서 지금 마련한 방식은 github에 claude라는 repository를 만들고 거기에 각 workspace/작업영역에 해당하는 관련 설정이나 commands를 넣어두고 그것을
내려받아서 make sync(delete - copy)를 시키는 방식이다.

전체적인 구조를 보면 다음과 같다.

├── Makefile
├── README.md
├── global
│   ├── CLADUE.md
│   ├── scripts
│   │   └── context-bar.sh
│   └── settings.json
├── personal
│   ├── CLAUDE.md
│   ├── commands
│   │   ├── git-sync.md
│   │   ├── lint-format.md
│   │   └── update-docs.md
│   └── rules
│       └── flutter-project-checklist.md
└── company 
    ├── CLAUDE.md
    └── commands
        └── lint-format.md

보통 나는 ~/workspace/personal, ~/workspace/company 이렇게 두고 그 하위에 각 영역에 맞는 프로젝트들을 배치를 한다. 그래서 .claude도
~/workspace/personal/.claude, ~/workspace/company/.claude 이렇게 위치가 된다.

make sync를 하면 global에 있는 부분은 ~/.claude 안으로 복사가 되고 나머지는 각 프로젝트로 복사가 되어진다.

global에 있는 settings.json에는 명령어 allow 항목들이 있어서 그것들은 전역적으로 영향을 미친다.
각 영역에 있는 CLAUDE.md 파일에는 개인과 회사 작업에 있어서 기본적인 지침들이 들어있다. 물론 각 프로젝트의 CLAUDE.md도 만들게 된다.

commands의 경우, 상위 디렉토리에 있는것을 찾지 못하는 문제가 있어서 아쉽지만 그래서 프로젝트를 만들고 .claude를 구성하면 ln -s로 commnands 를 수동으로 세팅을하면 하위 프로젝트에서도 custom commands를 모두 사용할 수 있다.

지금 이 세팅이 완벽하진 않지만, 현재의 내 환경에는 맞는것 같고 좀 더 작업을 해보면서 업데이트를 할 예정이다.

-s (scope) 옵션

claude mcp add 명령어에서 -s 옵션은 MCP 서버의 설정 범위를 지정한다.

대부분의 경우 -s user를 사용하면 된다.

개발 관련

JIRA

claude mcp add jira -s user \
  --env JIRA_HOST=https://my.atlassian.net \
  --env JIRA_USERNAME=ash84@xxx.com \
  --env JIRA_API_TOKEN={{ JIRA API TOKEN}} \
  -- npx -y @modelcontextprotocol/server-atlassian

Slack

claude mcp add slack -s user \
  -e SLACK_BOT_TOKEN={{ SLACK_BOT_TOKEN }} \
  -e SLACK_TEAM_ID={{ SLACK_TEAM_ID }} \
  -- npx -y @modelcontextprotocol/server-slack

Data 관련

Redash

claude mcp add redash -s user \
  -e REDASH_URL={{ REDASH_URL }} \
  -e REDASH_API_KEY={{ REDASH_API_KEY }} \
  -- npx -y @suthio/redash-mcp

MongoDB

claude mcp add mongodb -s user \
  -e MDB_MCP_CONNECTION_STRING="{{ MONGODB_CONNECTION_STRING }}" \
  -e MDB_MCP_READ_ONLY=true \
  -- npx -y mongodb-mcp-server

MySQL

claude mcp add mysql -s user \
  -e MYSQL_HOST='{{ MYSQL_HOST }}' \
  -e MYSQL_PORT='3306' \
  -e MYSQL_USER='{{ MYSQL_USER }}' \
  -e MYSQL_PASS='{{ MYSQL_PASS }}' \
  -e MYSQL_DB='{{ MYSQL_DB }}' \
  -e ALLOW_INSERT_OPERATION='false' \
  -e ALLOW_UPDATE_OPERATION='false' \
  -e ALLOW_DELETE_OPERATION='false' \
  -- /opt/homebrew/bin/node ~/workspace/mcp-server-mysql/dist/index.js 

• https://github.com/benborla/mcp-server-mysql
• 마지막줄에 -- npx -y @benborber/mcp-server-mysql 를 넣으면 되는게 잘 안되서 릴리즈를 로컬에 다운로드 받고 그걸 빌드해서 나온 dist/index.js를 사용하는 방식으로 쓰고 있음.

사실 경력사다리상에서 어떤 스탯을 찍는다는 느낌이 강했다. 레벨적인 부분, 직책적인 부분, 그것을 지나서는 내가 원하는 기술 스택적인 부분 그 안에서 할 수 있는것도 할 수 없는것들이 공존하고 타협할 수 밖에 없는 것들이 공존한다.

요즘 눈에 들어오는 분들은 한 회사에서 5년이상 기술리드직을 하시는 분들이다. 리드냐 아니냐가 문제는 아니지만 이 자리가 쉽지 않고, 늘 장애와 그리고 돈과 싸워야 하는 자리인데 어떤 마음으로 계속 그런 역할을 회사에서 그리고 개인의 삶에서 이루어나가는지가 궁금하다. 특히 리드들은 더이상 개발을 하지 않는게 일반적이고, 요즘들어서는 중간 실무리더조차도 AI툴을 쓰다보니 더 코드를 직접 쓸 일들이 없어지는데 어떻게 계속 해나가야할까?

떠나는게 답은 항상 아니라는 생각이 이제는 든다. 이제는 다른 답을 찾아야겠다.

Postman을 사용하다 보면 특정 변수를 매번 변경해서 요청을 보내거나, 이전 응답값을 다음 요청에 넘겨서 테스트해야 하는 경우가 있다. 이럴 때 pre-request와 post-response 스크립트를 활용하면 편리하다.

📚 공식 문서: Use scripts to add logic and tests to Postman requests

Pre-request Script

// 32자리 숫자 문자열 생성 (맨 앞자리 0 방지)
let pid = String(Math.floor(Math.random() * 9) + 1);
for (let i = 1; i < 32; i++) {
  pid += Math.floor(Math.random() * 10);
}
pm.environment.set("pid", pid);
console.log("pid:", pid);

서버에서 중복되지 않는 값을 전달해야 API 테스트가 가능한 경우가 있다. 이때 pre-request 스크립트에서 랜덤 값을 생성해 변수에 저장할 수 있다. 위 예제에서는 pid라는 32자리 숫자 문자열을 생성해 환경 변수에 저장하고 있다.

이렇게 저장한 값은 Postman request body에서 {{pid}} 형태로 참조하면 된다. 요청을 보내기 전에 pre-request 스크립트가 먼저 실행되어 변수에 값이 담기고, 그 후 요청이 전송된다.

📚 공식 문서: Write pre-request scripts

Post-response Script

const body = pm.response.json();
pm.environment.set("refund_document_number", body.data.refund_document_number);

이전 응답값을 다음 요청에서 사용해야 하는 경우도 있다. 예를 들어 결제 요청 시 승인번호를 받고, 이 승인번호로 결제 취소를 해야 한다면? 매번 응답값을 복사해서 붙여넣는 건 번거롭다.

post-response 스크립트를 활용하면 응답 JSON에서 필요한 값을 추출해 변수에 저장할 수 있다. 이후 요청에서는 {{refund_document_number}}처럼 변수로 바로 참조하면 된다.

📚 공식 문서: Write scripts to test API response data

환경 변수 활용

pm.environment.set()과 pm.environment.get()을 사용하면 요청 간에 데이터를 쉽게 전달할 수 있다. 환경 변수는 Collection Runner에서 여러 요청을 순차 실행할 때 특히 유용하다.

📚 공식 문서:
- Edit and set environment variables
- Reference variables in scripts

Collection Runner로 순차 실행

이 기능들을 조합하면 여러 request를 하나의 폴더에 넣고 Run을 통해 순차적으로 실행할 수 있다.

1번 request의 pre-request 실행 → 변수 저장
↓
1번 request 실행
↓
1번 request의 post-response 실행 → 응답값을 변수에 저장
↓
2번 request에서 저장된 변수 활용
↓
...반복

📚 공식 문서:
- Test your API using the Collection Runner
- Customize request order in a collection run

물론 curl이나 Python으로도 가능하지만, 스크립트 코드는 유지보수가 상대적으로 번거롭다. 개발자와 QA가 함께 Postman을 사용하는 조직이라면 이 방식을 적극 추천한다.

이런 고민을 꽤 한적이 있었다. 술이 좋거나 먹을게 좋아서 자는게 좋아서
그런 다이어트 관련 지엽적인것 외에도 왜 목표를 달성하지 못할까? 하는 생각.

그리고 그것들을 해도 뭔가 나아지지 않을까하는 생각들을 했었다.

그러다 언제였는지는 모르겠지만
올리브영에서 음료수를 고르다 그런 생각이 들었다.

뭔가를 선택할때 마다
또는 뭔가를 하기 전에

이게 내가 가려는 커다란 목표,
이루었을때의 나의 모습에 부합하는 행동인가/결정인가?

이런 생각을 매순간 결정하면서 어떨까?

일상을 돌이켜보면 나의 시간을 사용하는데
아무렇게나 쓰는 경우들이 많다.

시간이 있으니까 친구를 만나고, 게임을 하고, 술을 먹고 등등
근데 그게 어떤 목표에 부합하진 않는다.

이런 생각을 뭔가를 할 때마다 생각하고 한번 if문으로 거른다면
그래도 목표에 더 다가갈수 있지 않을까?

—

이게 내가 생각하는 가장 완벽한 생각 프레임워크인데
이걸 내 삶에 적용해보고 있다.

그 적용 과정에서 몇가지 느낀 문제점은

1. if문을 태우는데는 꽤 많은 에너지가 많이 든다는 점, 그래서 많은 사람들이 말한 습관을 만들어야 한다는게 왜 만들어야 하는지 알게 되었다.

2. 뇌에 오기전에 해버리는 것들이 있다. 자연스럽게 커피를 먹거나 지하철을 타거나 하는 등의 어떤것들은 내가 인지하지 못하는 사이에 그것들이 이루어진다. 어떻게 보면 기존의 습관의 영역에 있는것들이라고 볼 수 있을것 같다.

3. 뇌에서는 알겠는데 그걸 뛰어넘어 버리는 케이스. 이건 어떤 본능이나 편안함의 영역 같은데, 목표 자체는 일을 더 해야하지만 그것도 내가 알고 있지만 누워버리거나 생각없이 음식물을 짚어들거나(드는 순간 알지만..) 하는 등. 사실 목표만을 향해서 가는건 맞지만 그 순간과 과정이 항상 행복할 수는 없기에 작은 행복들을 찾는것 같다.

그래도 이 프레임워크로 내 생활과 의사결정, 생각을 다시 한번 성찰하게 된다.
휩쓸려서 온건 아닌지

지금이라도 내가 원하는 모습과 목표를 이루이 위해서
원하는 상태가 되기 위해서

매 순간 진짜 매순간마다 생각해야한다는것
그리고 올바르게 가려고 애써야 한다는 것

한해동안 많이 고민한 것들은 결국 나는 어디로 가야하는가? 에 대한 근본적인 물음이었다. 내가 하고싶은것은 무엇인가? 에 대한 매우 근본적인 물음, 그게 나라는 한 사람만 생각하기엔 나는 가정도 있고, 나이도 있기 때문에 완전하게 나 자신만을 오롯이 위한 결정을 한다는것은 매우 위험하고 이기적이다. 결혼전 30 초반에 퇴사를 하고 다음날 바로 돈 한푼없이 이탈리아를 간 적이 있었다. 이제는 그런 선택을 할 수는 없다.

매우매우매우. 근본적으로 돌아가서.
나는 컴퓨터 관련 일, 컴퓨터 프로그래밍 관련 일을 지금도 하고 싶은가?
나는 왜 이일을 시작했을까? 라는 물음까지 다다르게 되었다.

15살의 나로 돌아가봤을때
순수하게 컴퓨터라는 것에 호기심이 있었고
뭔가 멋져 보였고, 그리고 다른 사람들이 못하는것을 내가 하는 것이 재밌었다.
그 이후에는 어려웠지만 만드는게 재밌었고, 그것으로 돈이 벌리고
많은 사람들을 만나면서 제품과 서비스들, 그리고 그걸 쓰는 모습들이 좋았다.

지금의 세속적인 나에게 다시 돌아오면
나는 여전히 뭔가 만드는게 재밌긴하다.
그렇지만 좀 더 잘 만들어야 하고, 그 안에는 비지니스가 있어야 하고 돈이 벌려야 한다.

지금의 나에게
'개발 조직을 구성하고 서포트 하는 것'은 조금은 흥미가 떨어졌다.
이유는 몇년간 해오면서
생각보다 외부의 영향을 많이 받는 부분이 크고
AI 툴들의 발전으로 굉장한 변곡점의 한가운데 있다는 생각이 들었다.
그렇지만 여전히 좋은 개발자분들이 회사에서 일을 잘 할 수 있고
블로커를 치우는 일 자체를 하고 있다. 다만 예전만큼의 흥미를 느끼진 않는다는 점

개인적으로 올 한해는 아쉬웠던 것은 시스템 장애 예방을 잘 못했다는 점이 매우 아쉽다. 그렇지만 동료와 함께 좀 더 우리의 본질에 대해서 이해하게 된 것 같다. 업의 본질, 고객의 본질, 사업의 본질, 회사의 본질, 조직과 구성원의 본질에 대해서 더 깊이. 책이나 구글 밑 타회사의 베스트 프랙티스들이 모든 도메인과 모든 곳에서 진리가 아니고 우리는 그 안에서 적절한 절충선을 찾아야 한다. 그게 타협일수도 있고, 아닐수도 있지만.

백엔드 개발자의 역할에서 좀 더 데이터 파트들을 들여다 보는 시간이었다. 백엔드의 역할도 안한건 아니지만 대부분의 업무가 DBA, DE 역할들을 했다. 서비스 뒤쪽에 흐르는 데이터들을 보면서 그것들을 어떻게 저렴한 비용으로 정합성이 깨지지 않는 선에서 조직 전체에서 잘 사용할 수 있게 만들것인가에 대해서 고민하고 움직였던 부분이 2025년 한해 가장 성장한 부분이라고 생각한다.

기술적인 부분 외에는, 어떤 압박이나 챌린지가 있더라도 결국 해야하는 것은 밀어 붙여서 만들어야 한다는 것이다. 종종 조직이나 리소스 탓을 하기 쉬운데 그것이 맞는 길이고 지금 해야하는 것이고 내가 그것을 믿는다면 결과로 보여줘야 한다는 것이다. 다른 누가 관심을 같든지, 임팩트가 없다고 평가를 하던지(이건 귀에 걸면 귀걸이) 그런것에 상관없이 하면 된다. 결과를 보여주면 보이기 때문에 믿고 다르게 평가하게 되어 있다.

코파운더로 회사를 다닌지 올해가 입사 5년차가 되면서 회사도 당연히 많은 변화를 겪고 있다. 그 과정에서 나 스스로도 심경의 변화가 있었지만 어느순간부터 크게 동요하진 않고 있다. 이유는 여러번의 이직도 해봤고 그 과정에서 다양한 라이프사이클의 사람들과 회사들을 보면서 지금 어느 정도의 순간에 있구나 정도를 가늠할수 있게 되었다. 그리고 그 중심에 내가 원하는 것이 무엇인가? 를 고민하면서 나에 대해서 더 깊게 고민했던것 같다.

최근에는 삶의 지루함과 재미에 대해서 생각이 많다. 매일매일 지하철을 타고 회사를 가고 집에와서 저녁을 먹고 이런 삶에서 과연 재미라는게 있나? 왜 이렇게 삶이 재미가 없지? 지루하다라는 생각 다른 사람들은 어떻게 살지하는 생각이 들었다. 재미지게 살기 위해서 노오력을 해야하는가 싶다. 어제 봤던 드래곤라자 스토리 캠프 영상을 보면서 너무 빠른 모바일이나 컴퓨터가 있어서 책에서 오는 상상이 주는 재미를 못 느끼게 된 세상이 아닌가도 싶다. 다양한 취향을 가진 사람이 되고 싶다. 그게 깊든 아니든 상관없이.

올해 개인적으로 몇가지 소소한 것들을 공유하자면

• 가족중에 한명이 아팠고 죽음에 대해서 한번 더 상기시키는 시간이 있었다.
• 둘째 생일에 꿈도미라는 곤충샵에서 사슴벌레 4마리를 구매해서 키우고 있다.
• 박스까남 이벤트에 당첨이 되어서 차 스피커를 하만카돈에서 포칼 스피커로 변경했다.
• mongodb local seoul 컨퍼런스에 참석 했는데 datadog 이벤트를 뭔가를 했는데 애플 에어팟맥스를 받았다.
• m2 맥북을 당근마켓에서 광고 36,000원을 태워서 100만원에 겨우 팔았고, m5 맥북프로를 구매했다.
• 기존에 사용하던 여러가지 todo 앱들을 다 해지하고 애플 미리알림(reminder)로 선회했다.
• 라미 만년필을 베스트펜에 가서 시필을 하고 구매를 했고, 매일 잘 쓰고 있다.
• 꽤 자주 새벽에 드라이브를 나갔고 개인적으로 용비교-한남동-월드컵경기장 코스를 많이 다녔다.
• 가장 좋았던 드라이브코스는 가평, 한계령, 미시령
• 포도나무를 키우는 작업들은 잘 관리를 하지를 못했고 결정적으로는 2024년에 너무 가지를 짧게 잘라서 수확량이 적어졌다.
• 여름에 주말에는 여러 계곡들은 난생 처음 갔다. 파주 풍차이동갈비, 포천 동막골 등 아이들과 난생처음 여러가지 추억을 남겼다. 정말 재미있었고 많은 돈이 들지 않더라도 이렇게 재밌게 놀 수 있어서 좋았다.
• 속초로 여름 휴가를 갔었고, 바다좌대낚시 그리고 장사항에서 스노쿨링을 했다. 스노쿨링도 처음 해봤는데 바다 물고기를 보는게 좋았고, 본의 아니게 유실물들을 건지게 되었다.
• 11월에 참석했던 AWS CTO Night And Day에 참석을 했고 2박 3일동안 많은 CTO 분들을 만나뵙고 여러 위로도 받고 조언도 받을수 있는 시간이 있었다. 그들 역시 장애에서 자유로울수 없고, 일과 가족 사이에서 많이 고민을 하고 있었고, 나와 크게 다르지 않다는 인상을 받았다.
• 10kg 정도 감량을 했고 한동안 점심시간에 샐러드를 먹으면서 자연스럽게 감량이 되었다. 지금은 유지중이지만 26년도에는 10kg 정도 더 감량을 할 생각이다.
• 캠핑은 거의 2번정도 갔다 왔던것 같은데 너무 자주 못가서 아쉽다.
• chatgpt, cursor를 1년정도 썼는데 12월에 해지를 했고 claude max 100을 월 결제해서 사용하고 있다. 생각보다 chatgpt는 크게 도움이 잘 안되는 느낌이었고, cursor는 1년 결제를 잘못했었다.
• 여전히 iCloud를 잘 쓰고 있고, 사진 기능에 매우 만족하고 살고 있고, 애플 뮤직은 약간 불편하지만 잘 쓰고 있다.
• 블로그 자체는 AWS Lightsail에서 사용을 하다가 지속가능성에 대해서 의문이 있었고, 별도의 jinja2 기반의 zvc라는 툴을 만들어서 모든 글들을 마크다운으로 이관했고 지금은 GitHub Page에서 서빙을 하고 있다.
• 12월에 제주에 평일 휴가를 내고 다녀왔다. 알고보니 5년만이더라. 5년전 회사에 합류하기 전에 아이들과 제주도 길게 왔었는데 5년이라는 시간이 지나서 이제 자유롭게 뛰어다니는 애들을 보면서 뭔가 아쉬움과 여러가지 복합적인 감정들이 들었다.
• 자주보는 유투브는 째즈마인드, 이종범의 스토리캠프, 박스까남, 정우성의 더파크, 빈플렉스, 포프TV, 브루스리TV
• 가장 재밌게 본 영화는 F1더무비, 체인소맨 레제편, 귀멸의 칼날 무한성편
• 가장 재밌게 본 드라마는 애플티비의 미틱퀘스트, 테드래소

• 인텔 맥북프로 하드웨어 스펙

(system_profiler SPHardwareDataType | grep -E "Model Identifier|Processor Name|Memory"; \
 echo "Storage:"; \
 system_profiler SPStorageDataType | awk -F': ' '/Capacity:/{ if (!seen[$2]++) print "  " $2 }')

Model Identifier: MacBookPro13,2
Processor Name: Dual-Core Intel Core i7
Memory: 16 GB

Storage:
  250.69 GB (250,685,575,168 bytes)

1. 우분투를 깔아서 사용하기
- 고민을 했던 부분인데 개인적으로 과연 내가 우분투를 쓰게 될까? 이제까지 안썼는데? 라는 생각이 들어서 실효성이 낮다는 생각이 들었다. 완전히 맥북이 없는 상태에서 우분투를 쓴다면 모를까, 메인 기기가 되긴 어렵다고 판단했다.

2. 분해해서 지금 맥북에어에 적용하기
- 램은 메인보드에 납땜되어 있어서 분리가 어렵고, SSD는 외장 SSD로 NVMe 어댑터를 이용하면 가능할 것 같았다. 그렇지만 이건 차선책으로 생각했다. 좀 더 활용성이 높게 쓸 수 있는건 없을지 좀 더 고민

3. 모니터를 떼고 하판만 사용하기
- 유투브에서 예전에 중국에서 하판만 판다는 애기가 있었고, 실제로 그걸 해본 영상이 있어서 약간 혹했다.
- 일단 뭔가 분해를 해야하고 그것을 위해서 드라이버를 구매하는 등의 추가 비용이 들어서 이건 스킵.

4. 팔아치우기
- 생각보다 돈이 안될것 같았다. 애초부터 이건 좀 어렵다고 생각을 했다. 이미 M시리즈가 나온지 꽤 되었다.

5. SSH 접속가능하게해서 홈개발서버로 사용하기
- 이런저런 고민을 chatgpt에 털어놓다가 나온 아이디어인데, 램과 하드웨어를 모두 사용할 수 있다는 점에서 마음에 들었다.
- 기존에 쓰고 있던 AWS Lightsail을 처분한 상태였는데, 데이터 수집이나 그런것들을 하려면 개발서버가 하나 있었으면 했다.

결국 선택한건 2번. 대신 인텔 맥북을 크롬쉘모드로 둔 상태로 전원만 연결해두고 맥북에어에서 SSH로 접속해서 사용할 수 있어야 쓸 것 같았다. 매번 쓸때마다 인텔 맥북 열고, IP 확인해서 접속하는건 너무 귀찮았다. 결국 귀찮으면 내가 안쓰게 된다.

PEM 파일 만들고 등록하기

• 이건 사실상 서버에서 접속하기 위한 일반적인 절차라서 짧게 코드만 공유하고 스킵

# 인텔 맥북에서 수행 

## 키 발급 
openssl genpkey -algorithm RSA -out key.pem -pkeyopt rsa_keygen_bits:4096
chmod 400 key.pem
ssh-keygen -y -f key.pem > key.pub

## 키 등록 
mkdir -p ~/.ssh
chmod 700 ~/.ssh
touch ~/.ssh/authorized_keys

## 공개키(한 줄)를 붙여넣고 저장
chmod 600 ~/.ssh/authorized_keys

• 이후에 key.pem 파일을 접속을 하는 대상(여기서는 맥북에어)에 복사해두고 사용

tailscale

이걸 사용하는 이유는 결국 IP를 인텔맥북에 들어가서 확인해서 ssh로 접속하고 싶지 않기 때문이다. brew로 설치하는 방법도 있지만 공식 홈페이지에서 다운로드 받아서 사용하기를 권장한다.

https://tailscale.com

brew로 설치한 경우 이상하게 UI가 깨지는 문제가 있어서 삭제하고 tailscale 홈페이지에서 다시 받아서 설치 했다. 설치하고 가입하고 로그인을 양쪽 2개의 컴퓨터에하면 아래와 같은 화면을 볼 수 있다.

여기에서 저 IP를 쓰거나 혹은 다른 이름으로 접속할 수 있다.

## 맥북에어 - 접속 클라이언트
ssh -i key.pem ash84@100.x.x.x
ssh -i key.pem ash84@ash84-macbookpro

맥북 원격로그인 권한 켜기

진행하다보면 막히는 부분이 원격로그인 권한에 대한 부분인데, 맥에서 공유(sharing)에서 원격로그인 권한을 켤 수 있다.
이 작업을 해야 SSH로 접근할때 문제 없이 접근이 되고, 에러가 나면 connection refused 에러가 발생한다.

sudo systemsetup -getremotelogin # 확인 명령어
sudo systemsetup -setremotelogin on

systemsetup으로 설정할 수도 있다고하는데, UI에서 하는것을 추천한다.
UI에서 들어가는 방법은 맥에서 설정 > 공유(sharing)으로 들어가면 원격로그인을 찾을수 있다.
그 부분을 허용하면 된다.

맥북 슬립 방지 시키기

제일 중요한건 크롬쉘모드, 즉 인텔맥북을 닫아두고 전원을 연결해둔 상태에서 인터넷이 연결이 되고 tailscale이 동작해야 내가 접속을 할 수 있다. 이게 안되면 사용하기 전에 다시 열고, 켜주고하는 작업을 해야하는데 엄청 귀찮게 된다.

아래의 명령어를 쓰면 슬립모드로 안들어간다고 한다.
될지 안될지 몰라서 수행해봤는데 약 12시간 정도 지났는데 문제 없이 동작을 한다.

## 절대 슬립 방지 (sudo 권한 필요)
sudo pmset -a disablesleep 1
## 변경사항 확인
pmset -g

인텔맥북 활용도를 높이고 싶어서 진행한 부분인데, 생각보다 만족스럽긴하다. 아직 pyenv 설치하는 정도밖엔 셋업을 하지 않았다. 여러 인터넷에 있는 다양한 자료들을 찾아보면서, 느낀점은 생각보다 맥북이 오래 쓰지 못하는것 같다는 생각이 들었다. 그리고 체감상으로는 인텔맥북이 느렸지만 그렇다고 아예 못쓸 정도는 아니여서 집에 만약 나 말고 다른 개발을 안하지만 맥을 쓰는 사람이 있다면 그냥 쓰게 했을것 같다는 생각이 들었다.

애들이 마인크래프트를 좋아하는데 iOS 기기로 둘이서 하려다보니 둘다 마이크로소프트 계정이 있으면 한쪽에서 한쪽을 초대해서 하거나 아니면 Realm 이라는것을 통해서 같이 할 수 있는것 같다. 근데 이건 유료인것 같고. 근데 내가 알기론 마인크래프트는 서버를 운영할 수 있다고 들었고 좀 더 찾아보니 java edition과 bedrock edition이 있는데 iOS/Andriod 사용자라면 bedrock edition으로 서버를 띄우면 둘이 접속해서 쓸수 있게 할 수 있을것 같았다.

막연하게 생각만 하다가 아래의 김실장 유투브를 보게 되면서 나도 모르게 서버를 띄워서 둘이 같이 하게해주자라는 생각에 불이 붙었다.

그렇지만 AWS나 그런곳에 쓰는건 귀찮았고, 내 맥북에어에 띄우고 와이파이로 애들이 접속하는 형태로 진행했다. docker로 된 것들이 있어서 아래와 같이 docker 명령어를 수행하면 마인크래프트 서버가 뜨고 ip:port를 마인크래프트 앱에서 넣으면 접속시킬수가 있다.

docker rm -f mcbedrock
docker run -d --name mcbedrock \
  --platform=linux/amd64 \
  -e EULA=TRUE \
  -e TZ=Asia/Seoul \
  -e GAMEMODE=survival \
  -e ALLOW_CHEATS=false \
  -e DIFFICULTY=easy \
  -e LEVEL_NAME=ActionsAndStuff \
  -p 19132:19132/udp \
  -v ~/workspace/bedrock-data:/data \
  itzg/minecraft-bedrock-server

일단 애들이 굉장히 좋아했고, 둘이 할수 있으니 ㅎㅎ 와이파이가 되는 공간에서만 둘이 할 수 있다보니 집이 아닌 어디를갈때 자꾸 챙기라고 한다.

추가사항

⚠️ 약간의 틀린 내용이 있을수 있습니다. 저도 마인크래프트 전문가가 아님을 먼저 말씀드립니다.

일단 기본적으로 만들면 마인크래프트 아무것도 없는 곳이 나오는데, 아이들이 유튜브에서 마인크래프트를 접하게 되면 어느정도 구축된 세계를 플레이하는 유튜버의 플레이를 기준으로 삼게 된다. 한마디로 아빠가 만들어준 세계가 너무 시시하다. 그래서 처음에는 월드를 설치해줬다. 월드라는게 무엇이냐 하면, 스타크래프트로 치면 유즈맵세팅 같은 느낌이라고 보면된다.(맞나?) 원래 마인크래프트세계는 아무것도 없는데 여러가지 조건이나 제약이나 미리 어느정도의 세계를 구축해 놓은것이다.

https://mcpedl.com/tag/mcworld/

이런 사이트에 가면 좀비, 오징어게임 심지어 젤다까지 다양한 월드(mcworld)가 있고 이것을 다운로드 받아서 .zip으로 바꾸고 압축을 풀고 특정 디렉토리에 두면 된다. 그리고나서 volume이 연결된 위치, 그러니까 내 로컬로 치면 ~/workspace/bedrock-data 하위에 worlds 하위로 다운로드 받은 디렉토리를 위치 시키면 된다. 그리고 그 디렉토리의 이름을 LEVEL_NAME에 연결시키면 된다. 지금 보면 ActionAndStuff 라는 디렉토리가 ~/workspace/bedrock-data/worlds/ActionAndStuff 위치에 있고 LevelName이 ActionAndStuff로 되어 있다. 이렇게 되면 서버로 접속하면 그 월드로 연결되어서 나오게 된다.

처음에 나는 인식을 서버라는건 말 그대로 서버라고 생각을 했고, 월드는 서버안에 여러개의 월드가 있어서 선택해서 들어갈 수 있는 형태라고 생각을 했다. 그래서 여러 월드를 깔아놓고 애들이 맘껏 놀게 해야지라고 생각했는데 그게 아니였다.

잘 놀다가 갑자기 이게 아니라고 하면서 모드(mods)를 설치해달라고 한다. ㅠ 고객님들은 만족할줄을 모른다. 이건 또 뭔가 싶다.
어려운점이 뭐냐하면 대부분의 마인크래프트 유튜버들은 Java Edition 즉, PC에서 이걸하는데 약간 bedrock edition과 다른점도 있고 꽤 오래된 영상이들을 보게 되면 지금 시점에 어떻게 적용해야할지 막막하다.

찾아보니 모드(mods)는 단순하게 생각하면 부분적인 커스터마이징이라고 보면 된다. 예를 들어, 월드는 그대로인데, 특정 아이템만 더 추가를 하고 싶다. 총을 추가하고 싶다라던가 괴물을 더 추가하고 싶다라고 할때 이 모드를 다운로드 받아서 설치하면 된다.

https://www.minecraftmods.com/

모드는 2가지 종류가 있느것 같은데 하나는 resource 다른 하나는 behavior. 그래서 둘다 있는 경우도 있고 하나만 있는 경우도 있는데
다운로드 받으면 나의 docker volume이 연결된 기본 디렉토리 ~/workspace/bedrock-data 하위에 2개의 디렉토리를 만든다.

• behavior_packs
• resource_packs

이 2개의 디렉토리 중 하나에 압축을 푼다. 그리고 나서 압축을 푼 디렉토리 안에 들어가면 manifeset.json 이라는 파일이 있는게 그것을 열면 이런 형식으로 나와있다.

{
    "format_version": 2,
    "header": {
        "description":"It gives your world a more dynamic and lively feel by adding several new animations, particles, and other stuff! (Work in progress).",
        "name": "Actions & Stuff §8(1.0.2)",
        "uuid": "22b87fae-158c-4663-aa29-a3d70acbf0b3",
        "version": [1, 0, 2],
        "min_engine_version": [ 1, 20, 80 ]
    },
    "modules": [
        {
            "description": "ACT",
            "type": "resources",
            "uuid": "19c0aaaf-dfcb-4de9-9184-eb1ba17cd774",
            "version": [1, 0, 2]
        }
    ]
}

중요한건 header.uuid, header.version 인데, 이 정보를 지금 만든 월드 안에 넣어야 한다. 어떻게 넣냐하면
본인이 만든 월드 디렉토리, 여기서는 ~/workspace/bedrock-data/worlds/ActionAndStuff 이 디렉토리 하위로 가면 2개의 파일이 있다.(없으면 만든다)

• world_resource_packs.json
• world_behavior_packs.json

이 파일에 아까 저 header.uuid, header.version을 넣는다. 형식을 보면 json array 형식이다. 즉 하나의 월드안에 여러가지 모드(mods)를 원하는 만큼 추가 및 삭제가 가능하다는 것이다.

[
  {
    "pack_id": "22b87fae-158c-4663-aa29-a3d70acbf0b3",
    "version": [1, 0, 2]
  }
]

이렇게 연동을 하면 서버 접속을 할때 월드와 그에 딸린 모드들을 같이 로드가 된 세계를 플레이할 수 있다.

생각보다 재밌었던 경험이었고, 무엇보다도 개발자, 컴퓨터 잘하는 아빠로써 체면을 살렸던 순간이었던것 같다. 그리고 월드/모드 시스템을 간접적으로 경험하면서 이런식으로 구성했구나를 이해하는 재미가 있었다. 결국 하나의 월드 안에 여러가지 모드들을 넣으면서 자신들만의 세계를 구축할 수 있는 시스템이 마인크래프트라는것을 서버 셋업을 하면서 알게 되었다. 가장 어려운건 bedrock edition에 대한 자료가 많지 않아서 찾는게 일이었고, 항상 모든 검색어 끝에 bedrock을 붙이면 그나마 금방 찾을수 있을듯.

1-2일 정도만에 웹사이트를 통해서 알게된 내용들이라 틀린 내용들도 있을거라서, 만약 틀린 내용이 있다면 me@ash84.io로 보내주세요.

어쨋든 Akiflow 재결제를 고민하다가 나는 결국 아이폰 미리알림을 선택했다. 이유는 간단하다. 돈을 내고 쓸만큼 좋지만 뭔가 계속 내 삶에 소프트웨어 덕지덕지 붙는 느낌이었다. 곰곰히 기억을 더듬어서 처음에 어떻게 일을 했나로 돌아가봤다. 주간회의때 다이어리 들고 들어가서 팀장님 말씀 받아적고, 그 다음은 어느새부터 노트북을 들고 들어갔던것 같다. 구글캘린더, 노션 등등 이런것들이 하는 개발일은 동일한데 계속 덧붙여졌다. 새로운 소프트웨어를 경험하는것은 물론 매우 좋지만, 개인적으로 드는 생각은 결과적으로 하는 일은 같은데 왜 이렇게 전처리 단계가 많아졌지? 하는 생각이 들었다.

왜 나는 소프트웨어 추가가 부담스럽게 느껴졌을까?

나이가 들어서일수도 있지만 2가지의 생각이 들었다. 하나는 소프트웨어의 추가, 실질적으로 이건 아이폰 앱이나 맥앱의 추가로 이어지는데, 기존에는 필요한것을 쓴다라는 관점이었는데 요즘에는 효율적이면 새로운것을 쓴다는 관점이 더 많이 작용하는것 같다. 그러다보니 소프트웨어의 추가가 내가 느끼기엔 방안의 새로운 소파나 티비를 추가하는 것 같다. 샀는데 안쓰면 죄책감을 느끼고, 그렇다고 안쓴다고 큰일이 벌어지지도 않는다.

다른 하나는 효율성에 대한 강박관념인것 같다. 나를 효율적으로 해줄수 있으면 소프트웨어를 구매하고 설치해서 쓴다는 생각이 예전보다 많이 생기는것 같은데(이건 예전보다 선택할 수 있는 소프트웨어가 많아졌다는 방증) 당연히 하나로 100% 효율적일수는 없으니 여러개를 계속 도입하게 된다. 아이폰 메모에서 노션으로, 구글캘린더에서 Akiflow로 등등 특히 AI툴이 최근에 생기면서 더 그러는 경향이 커진것 같다. 확실히 소프트웨어는 하드웨어보다 싸고, 부피가 적고, 설치가 쉬운것도 한몫을 하는것 같다.

많은 소프트웨어를 사용하는것이 절대 나쁜것은 아니지만, 내 관점에서는 그런것들은 별로 중요한건 아닌것 같다. 사람이 살아가는것은 크게 달라지지 않은것 같다. 잘 먹고 마시고 잘 자고, 생각을 하고 원하는 것을 만들고, 다양한 경험을하고. 이런 과정에서 나를 도와줄 수 있는 소프트웨어는 좋지만, 그걸로 인해서 본래의 목적이 방해 받는다면 한번쯤은 생각해봐야 할 것 같다.

나는 유료로 쓰는 소프트웨어들에 대해서 다시 한번 점검을 해보고 있다. 그게 진짜 지금 필요한지, 과거네 나는 어떻게 그 필요성들을 대응하면서 살아왔는지, 이제는 소프트웨어의 미니멀리즘이 고민해봐야 하지 않을까?

지속가능성에 대한 고민

또 다른 생각은 지속 가능한가? 라는 관점에서의 고민이 있었다. 개발자를 그만두더라도, 다른 일을 하더라도 블로그는 계속할 것 같은데, 물론 블로그를 운영하는 게 개발적으로 어려운 일은 아니지만 AWS 나 다른 플랫폼에 의존하는것도 귀찮고 언젠가 내가 돈을 못 내면 서버가 내려가고 내 글이 인터넷상에서 사라지지 않을까? 상대적으로 GitHub 그리고 markdown 파일이 더 오래 살아남지 않을까 하는 생각이 들었다. 만약 GitHub가 대체되더라도 markdown 파일만은 나에게 남을 테니. 그런 고민들을 하다가 결국 markdown 기반으로 돌아서기로 했다.

도구의 선택

Astro를 회사 개발 블로그를 만들어서 이번에도 Astro를 먼저 선택했다. 하지만 아쉬운 부분이 theme 시스템이었다. 대부분의 블로그 툴들은 theme를 쉽게 갈아낄 수 있다. 다운로드 받아서 선택하면 된다. 그런데 Astro는 사이트를 만드는 개념이다 보니 theme를 다운로드받아서 사용하는 방식이 아니었다.(모르는 방법이 있을지도) 예전에 회사 개발 블로그는 https://github.com/danielcgilibert/blog-template 이걸로 만들었었다. 나는 theme를 직접 만들어 쓰는 편이라 theme를 쉽게 갈아끼는 시스템은 필요했다.

직접 만들기

결국 직접 만들기로 결심했다. 정확히 시작은 금요일 밤이었고, 토요일까지 이어졌다. 풀타임은 아니었고 어차피 운영하던 것이 있으니까 못 만들어도 상관없다고 생각했다.

구조

제일 첫번째 고민한 것은 구조였다. 어디에 글을 보관하고, 어디로 정적 블로그 결과물이 나와야 할까 등등 몇가지 고민을 한 끝에 대략 구조를 잡았다. 구조를 설명하면 다음과 같다.

• contents가 블로그 글이 실제로 저장되는 디렉토리다. contents 디렉터리 하위에 url path에 해당되는 디렉터리가 있다. 개별 디렉터리가 하나의 포스트(post)의 공간이다. 예를 들어 이 글은 contents/move-to-markdown-based-blog에 위치해 있다. 글마다 디렉터리를 만든 이유는 이미지나 다른 여타의 해당 글에 들어가는 파일들이 다른 디렉터리로 흩어지는 것을 막고 싶었다.
• 해당 디렉터리 하위에는 해당 디렉터리와 같은 이름의 .md 파일이 있다. 여기에 본문을 쓴다.
• .md 파일의 최상단에는 아래와 같은 meta 정보를 담는다. 이건 다른 여타의 static generator가 사용하는 방식이고, Astro에서 경험한 부분을 넣었다.

---
title: '지속가능한 블로그를 만들기 위한 노력'
author: 'ash84'
pub_date: '2025-07-08'
description: '마크다운 기반의 블로그 만들기'
featured_image: ''
tags: ['blog', 'markdown', 'static generator']
---

대략 이 정도의 구조를 가지고 있다. 정리해 보니 처음 어떻게 만들지에 대해서 막막하게 생각했던 것보다 나아졌다.

무엇으로 만들것인가에 대한 고민

static generator를 만들어야 하는데 제일 편한 python으로 작업을 했다. 이번에 회사에서는 잘 안쓰는 uv, typer 등을 사용해서 contents 디렉터리 내 .md 파일을 읽고 html로 변환하는 작업을 진행했다. 여기서 고민했던 것은 어떤 url path를 지정할 것인가? 였다. 예를 들어 실제 접속하는 url path가 /move-to-markdown-based-blog가 될 수도 있지만 /2025/07/08/move-to-markdown-based-blog가 되게 할 수도 있다. 이 부분에서 많이 고민을 했는데 글을 쓴사람이 직접 지정한 대로 갈 것인가? 아니면 규칙을 만들 것인가?에 대한 고민이 있었고, 날짜를 넣는 방식을 선택했다. 이유는 날짜별로 나중에 다른 부분에서 보여줄 때 더 나을 것 같았다.

theme

결국 theme 때문에 이 모든 게 시작이 되었다. 사실 python을 선택한 건 2가지 이유가 있었는데 첫 번째는 내가 제일 편하고 빠르게 코딩할 수 있어서, 두 번째는 기존 내 블로그가 jinja2 template를 기반으로 되어 있기 때문이었다. 그래서 markdown 기반 정적 블로그를 만들되 기존의 내가 쓰고 있던 jinja2 template 기반의 theme를 가져와서 쓰면 좋겠다는 생각이 들었다. 결국 내가 원하는 건 theme를 만들어서 배치시키고 여러 테마 중에 하나를 선택하기를 원하는 것이다. 그러기 위해서 themes 디렉터리 하위에 사용하려는 테마 디렉터리를 배치하는 방식을 선택했다. themes 디렉터리 하위에 여러 테마가 있다고 하면 결국 블로그 주인은 어떤 것을 현재 테마로 사용할지를 선택해야 하는데 그것을 위해서 config.yaml을 만들었다.

theme: 
  name: goodnote
blog: 
  title: Ash84
  description: Ash84 Blog 
publication:
  path: ./docs

위의 config.yaml을 기준으로 설명하면 해당 파일을 읽어서 themes 하위에 goodnote라는 테마를 가져와서 읽어와서 사용한다.

변환

config.yaml publication.path에 지정된 디렉터리에 변환된 html 파일들이 들어간다. 최상단에 index.html이 들어간다. 이 부분이 블로그에 들어가면 보는 첫 화면에 해당한다. 그 다음에는 yyyy/mm/dd/xxx/index.html 이렇게 생성을 한다. 그렇게 되면 앞서서 말한 것과 같이 년/월/일/title url path로 접속할 수 있게 된다.

마이그레이션

기존의 AWS Lightsail MySQL에 있던 약 1000건의 데이터를 가져와서 contents 디렉터리 하위에 markdown 파일로 넣으면서 동시에 파일 내 상단의 meta 정보를 넣어서 생성하는 작업을 진행했다. 이 부분은 기존 DB에 개별 컬럼으로 title, slug, tag 등이 구분되어 있었고, DDL을 cursor에 주고 바로 작업을 시켜서 쉽게 진행할 수 있었다.

이사가기

주말이 지나고 퇴근 후, 드디어 월요일 밤에 기다리던 이사를 시작했다. 기존 AWS Lightsail에 있었던 DNS Zone을 지우고 Route53에서 A Record 그리고 네임서버들을 설치했다. 기존에 운영되고 있어서 DNS 적용에 계속 시간이 흘렀고, GitHub Page에서 Domain 활성화가 잘 안 되었다. 그동안 사이트가 접속이 되진 않았다. ChatGPT의 도움을 받아서 아래의 명령어를 통해서 잘 전파되고 있는지를 확인했다. 이 부분은 시간이 어느 정도 지나니까 전파가 완료되어서 해소가 되었다. 아직 Lightsail에 있는 instance랑 DB를 내리진 않았다.

> dig NS ash84.io
> dig +trace ash84.io
> dig ash84.io +noall +answer -t A

소회

뭔가 후련하면서도 시원섭섭하다. 영원히 운영할 줄 알았다. 이 세상에 영원한 건 없다는 것을 한 번 더 느꼈다. 그래도 이렇게 몇일만에 전환 할 줄은 몰랐다. 그렇지만 다른 static generator를 사용하지 않고 직접 만들어서 써본 경험은 간만에 느끼는 소소한 재미였다. 코딩하는 재미가 이런 부분에 있었다는 것을 다시 한 번 느꼈다. 별거 아니지만 내 손으로 만드는 것만큼 재밌는 건 없다. 직접 만드는것의 좋은 점은 계속 사용하면서 발전시킬 수 있다는 점이다. 지금은 매우 간단하지만 점점 나한테 필요한 것을 더 추가해 나갈 예정이다.

관련글

• 내 블로그에 emoji 를 구해줘😱
• 블로그 툴 이사

그리고 더 나아질수 있다는 믿음이 지금 이 순간의 나에게 없다.

몇년간의 도돌이표가 너무 지치게 만들고 모든시간과 노력과 의사결정과 그런 것들이 너무 헛되이 느껴진다. 또 새로운 사람들이 들어오고 이것들이 반복이 되고, 나는 또 단상에 오르고 또 고개를 숙이고 n회차다.

우린 과연 더 나아지고 있을까? 진짜? 그렇게 생각해?

너무 화가나서 모든 짐을 챙겨서 나왔다. 2일의 휴가를 내고 집에서 일을 하겠지만 동일한 마음으로 돌아갈 수 있을까?

편리함 하지만 불안함

블로그를 예로 들어보자. 나는 처음에는 테터툴즈에서 시작해서, 네이버 블로그, 티스토리, 워드프레스, 고스트 같은 서비스를 썼었다. 그런데 서비스가 종료되거나, 유지보수가 어렵게 되면 그때부터 써왔던 글, 데이터들이 문제가 된다. 여러가지 이유로 우리가 작성한 수많은 글과 데이터는 사라질 위기에 놓인다. SaaS 기반의 플랫폼은 본질적으로 그 생명이 서비스 제공자의 운영 여부에 달려 있기 때문이다.

설령 백업이 되더라도 그 형태는 그 서비스에서 만든 형태이고, 그런것들이 다른 플랫폼으로의 이전이 쉽지는 않다. 결국 누군가를 importer를 만들어주기 전까지는 그저 텍스트 파일일뿐이다. (알아볼수 있는 형태면 다행일지도 모른다.)

SaaS의 또 다른 문제는 통제권의 부족이다. 플랫폼에서 제공하는 기능 외에 추가적인 기능을 원한다면 제한이 많다. 커스터마이징이 불가능하거나, API를 제공하지 않으면 데이터 이동조차 쉽지 않다. 사용자의 데이터가 특정 업체의 정책과 서버에 종속되는 "락인(Lock-in)" 문제가 발생하는 것이다.

과거에 블로그를 여러 서비스에서 전전하면서 이런 생각이 들었고, 최근 몇 년 사이에는 노션을 쓰면서 이 자료들은 노션이 서비스를 종료하면 어떻게 하지? 라는 물음이 들었다. 그러다보니 자연스럽게 서비스가 아니라 데이터 자체, 파일에 대해서 관심을 가지게 되었고 그래서 현재는 옵시디언을 잘 쓰고 있다.

그래서 몇가지 고민해본 것들은

1. 데이터를 직접 소유하고 백업하기

클라우드 기반의 SaaS를 이용하더라도 데이터는 주기적으로 백업하는 것을 하면 좋다. 가능하면 오픈 포맷으로 데이터를 저장하고, 다른 서비스로 이전할 수 있도록 준비해야 한다. 블로그라면 마크다운(md) 형식으로 저장하거나, JSON이나 CSV로 내보내기를 지원하는 플랫폼을 선택하는 것이 좋다.

2. 직접 서비스 구축하기

SaaS의 편리함을 포기하고 자가 호스팅(self-hosting) 방식을 선택하는 것도 하나의 방법이다. 나 역시 여러 블로그 서비스를 전전하다가 결국 Flask를 이용해 직접 블로그를 구축했다. 내 서버에서 돌아가니 데이터가 사라질 걱정도 없고, 원하는 기능을 자유롭게 추가할 수도 있다. 운영의 부담이 약간 있지만, 장기적으로 보면 가장 자유로운 방식이다. 데이터를 내가 원하는 방법으로, 익숙한 방법으로 소유하고 있기 때문에 언제든지 백엔드나 프론트엔드를 수정할 수 있다.

하지만, 결국 다 없어지는게 아닌가?

자체 구축을 하더라도 결국 나라는 사람이 죽게 되면 서버는 내려가게 되고 글들은 안보이고 데이터를 지워질것인데 이런 노력이 필요할까? 하는 염세주의적 생각을 하게 되기도 한다. 돌이켜보면 세상의 모든것들이 그런것 같지만서도, 우리가 보는 책이나 글이나 그런것들이 꽤 오래 된것도 있고, 오래된 비석이나 돌에 새겨놓은것들은 몇천년이 지난 우리가 보고 있는것도 현실이다. 반대로 생각하면 그만큼 없어진것이 더 많은것도 사실이고.

그렇지만 어딘가에 이런 글들, 자료가 유지되면 좋겠다는 생각이 든다. 사진, 책, 비석 같은것들이 어떻게 보면 영속성 장치였던것이고, 인터넷 시대에는 그런 시도들이 어떻게 이어질지 궁금하다. 아니면 이건 그냥 인간의 욕심일수도 있고.

왜 도입했나?

일단 왜 도입했냐를 애기하기 전에 배경 상황을 먼저 설명을 해야하는데 내가 회사에서 쓰는 툴들은 다음과 같다.

• 구글 캘린더 : 일정/미팅/회의
• jira : 할일 관리
• 노션 : 문서
• 슬랙 : 실시간 소통
• 이메일 : 외부 소통 창구

사실 이건 회사에서만 쓰는 툴들이다. 나라는 개인을 보면 기본적으로 2가지 역할(role)을 가지고 있다. 하나는 직장인/리더/개발자 다른 하나는 가족 구성원/개인으로써의 나이다. 하지만 나에게 주어진 시간은 24시간 밖에 안되고 나는 회사 일을 하면서 나를 챙기고 가장으로써 가족을 챙겨야 한다.

예전보다 힘든건 이제는 쓰는 모든 툴들에서 요청들이 온다는 것이다. 예를 들면 구글 캘린더로 미팅 요청을 받고, jira로 할일/개발거리를 요청 받고, 슬랙으로 업무처리를 요청받고, 이메일로 외부 업체에서 요청을 한다. **결국 핵심은 요청관리(requirement management)를 어떻게 할 수 있느냐다. **

여러가지 시도들

다 기억나진 않지만 짧게는 한달 길게는 몇달이상 시도해봤던 것들을 정리해봤다. 지극히 주관적인거라서 도움이 될지는 모르겠지만.

회사와 개인 캘린더 분리

• 이 시도는 아마 캘린더를 깔끔하게 쓰고 싶어서였던것 같다. 개인은 개인 캘린더에서 회사는 회사 캘린더에 이메일도 마찬가지. 개발자스럽게 뭔가 컨테이너에 가두고 싶었던것 같은데. 결과적으로는 실패했다.

• 실패한 이유는 이메일은 받는 창구여서 상관 없는데, 캘린더는 내가 미팅을 잡을때 이 전환이 쉽지가 않았다. 특히 구글 캘린더를 분리하려면 구글 계정을 분리해야하는데, 크롬에서 구글 계정을 인식해서 들어가다보니까 여간 전환이 귀찮은게 아니였다.

Todoist 도입

• 사실 회사일들은 도구들이 있었는데 개인 Task 관리 도구가 없었다. 그래서 예전에도 잘 사용했던 Todoist를 사용했다. 개인적인 일만 사용하다 보니, 결과적으로 툴이 하나 더 늘어났고 컨택스트 전환이 더 많이 일어났다. 그리고 개인 Task만 적는게 Todoist까지 필요한가 싶었다.

Jira Private Project 사용

• 리더로 일을 하면서 느낀점 중 하나가 일반적인 작업이나 개발관련된 부분은 Jira에 남기기 편한데 비공개적인 업무를 남기기가 불편했다. 예를 들면, 보안 관련 사항이나 그런 부분은 public한 jira에 남기기가 애매했다. 그래서 나만 쓰는 비공개 Jira project를 만들어서 사용했다.

• 이 방식은 꽤 괜찮았다. Jira 자체에 너무 익숙해져있기도 했고, 일단 다른 개발 요청들도 대부분 Jira 받다보니 나쁘지 않았다. 하지만 이것도 몇개월가진 못했다.

• 지금은 이 방식을 사용하지 않는데, 이유는 회사 툴에 개인적인 일을 쓰는게 너무 마음에 걸렸다. 장보기, 미용실 예약 이런것을 굳이 jira에 쓸 이유가 있을까? 나중에 누가 볼수도 있지 않을까하는 생각도 들어서 그만두었다.

sunsama 도입
- 이 툴도 꽤 오래 썼었는데, jira, todoist, notion, gmail 등 대부분의 툴들을 연결해서 쓸 수 있었다. 개인적으로 꽤 만족했었는데 잘 안쓰게 된 이유는 어떻게 보면 Akiflow로 넘어온 이유라고도 볼 수 있는데, 시간 확보를 위해서 타임박싱(time-boxing) 내 스케쥴에 도입하게 되면서 Akiflow 캘린더 중심적으로 좀 더 편하다는 생각이 들었다.

Akiflow 도입

• integrations가 잘 되는 부분이 가장 좋았지만 사실 내가 오늘 Task을 Inbox에서 가져오고 그것을 캘린더에 넣음으로써 시간을 할당하고, 그게 다른사람으로부터의 일정/미팅 요청으로부터 보호가 되고 활용할 수 있는 시간이 늘어나는 느낌이었다.

어떤 점이 도움이 되었나?

• Inbox : 하루에도 수많은 요청을 여기 저기서 받는다. 예를 들면, 회사 카페테리아에서 요청을 받는다. 그러면 나는 그것을 기억해야하는데 jira는 너무 느리다. akiflow는 쉽게 바로 inbox에 넣을수 있다. 그리고 슬랙에서 요청이 오면 내가 지금 다른 작업을 하고 있을때는 처리 못하지만, Later를 걸어놓으면 자동으로 Akiflow Inbox에 들어간다.

• Projects : 프로젝트를 만들수 있는 기능이 있다. 앞에서 말한 내가 겪고 있었던 회사와 개인 일에 대한 분리를 나는 Projects를 통해서 하고 있다. 그래서 slack에서 들어온 요청을 회사 프로젝트로, 개인적으로 해야하는일은 별도의 프로젝트로 넣고 있다. 개인 Task들도 프로젝트로 분류를 해서 넣고 있다. 예를 들면 사이드 프로젝트, Finance 와 같이 약간의 중요도가 다른것들을 프로젝트 별로 분류해서 넣고 있다.

• Calendar : Task가 만들어지면 그것들을 언제 실행할지를 정해야한다. 보통 나는 이 작업을 1~2일전에 배치작업을 진행한다. 캘린더 상에서 내가 할일을 해당 시간에 옮겨 놓음으로써 해당 일을 하는 시간을 확보할 수 있다. 이렇게 하니 좋은점 2가지를 발견했다.

**첫번째, 시간이 잡혀 있기 때문에 다른 사람의 일정/미팅 요청을 거절 할 수 있다.** 구글 캘린더 기반의 회사를 다녀보면 알겠지만 논의를 하기 위해서 내가 비워둔 일정에 계속 미팅/회의를 요청한다. 그렇게 되면 나는 일을 할 시간이 없다. 그러나 일정을 채우고 내가 그 일정에 내 할일을 하면 방해받지 않는다.

두번째, 해당 Task를 비공개 또는 공개로 할 수 있기 때문에 비공개 관련 일도 잘 관리할 수 있다. 개발 관련된 일만 하지는 않고, 사람관리, 리소스 관리를 할 때가 있는데 그런것들이 공개되는 건 개인적으로 불편하다. 그런데 Akiflow에서는 해당 Task를 캘린더에서 공개로 할지 비공개로 할지 정할수가 있다. 나는 비공개를 기본값으로하고 공개할 만한것들만 따로 공개하는 편이다.

가장 잘 쓰는 기능?

사실 가장 잘 쓰는 기능은 Task 내 메모 기능이다. 일들이 막 들어오고 내가 쓴 한줄짜리 일들을 시간이 될때 모바일 또는 맥에서 볼때 생각나는 파편들을 해당 Task 안에 적곤 한다. 그런것들이 꽤 도움이 된다. 예를 들어, 블로그 글을 쓸 소재를 Task로 적어두었다고 하면 다른 책을 보거나 뭔가를 봤을때 블로그 글에 쓰면 좋겠다고 생각이 들면 해당 Task에 메모를 해둔다.

Priority 기능은 몇번 써보려고 했지만 사실 잘 손에 익지는 않는다. 이건 내 개인적인 방식인데, 나는 아침시간에 집중이 잘 되어서 MakeTime에서 애기하는 하이라이트 Task, 오늘 꼭 처리해야하는 제일 중요한 일은 아침시간에 배치한다. 따라서 내 하루 일정에서 뒤로 가면 갈수록 덜 중요한 Task라고 보면 된다.

아쉬운점

AI Project 분류기능이 있긴 한데 개인적으로 조금 아쉽다. 꽤 오랫동안 사용했는데 잘 분류하지는 못하는것 같다. 한국어라서 그런지는 몰라도. 현재 꺼놓은 상태긴하고 좀 더 고도화되면 좋을것 같다. 그 외에 크게 불만족하는 부분은 없다.

command bar 기능도 있는데 확실히 손에 익으면 더 빨리 처리할 수 있을것 같다. 좀 더 커져서 Raycast에도 기능이 들어오면 개인적으로 더 편할것 같기도 하다. 그리고 사실 캘린더 자체를 회사 캘린더를 쓰다보니 개인 Task도 일부 회사 갤린더에 등록해서 사용하고 있다. 분리 되진 않지만 시간화보라는 측면에서 트레이드오프를 한 것이라고 볼 수 있을것 같다.

이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.

• 달리기를 좀 했었다. 자주라기 보다는 정신적으로 힘들어서 달라기를 했었는데 길게는 못하고 1시간 뛰다 걷다 하면 그래도 나아지더라.
• 체력적으로 나아졌는지는 솔직히 모르겠지만 정신적으로 많이 도움이 되었다.
• 여전히 혈압약, 통풍약을 먹고 있다. 올해 추석쯤 통풍 발작이 왔었는데 다행히 미리 받아놓은 응급약으로 대응을 할 수 있었다.
• 작년보다 나아진 점은 예전보다 많이 자고 있다. 예전에는 5시간 남짓 잤던것 같은데 5시 배포가 많아서 아예 9-5로 자는 시간 변경을 해서 8시간 정도 수면시간을 확보했다. 요즘에는 아이들이랑 자다 보니 9시 정도면 자고 있고, 6-7시 정도 기상을 목표로 하고 있다.
• 하반기에 캠핑으로 인해서 허리 디스크가 문제가 생겼고 고생을 약 2달 정도 했다. 지금은 많이 좋아졌지만 운동도 조심하고 있다.
• 주말에 아이들이 커서 가끔 목욕탕/사우나에 가고 있다. 스트레스 완화에 그래도 도움이 되긴 하는것 같다.
• 건강관리에 개인적으로 40점. 잘 못한 게 더 많은 것 같고 40대에 접어들면서 확실히 회복이 더디다는 생각이 든다. 평생 쓸 몸을 만들어야겠다는 생각을 하고 있다.

가정

• 성장하는 두 아들들에 슬슬 치이기 시작하는 느낌, 아내가 2아들이라는 존재에 버거워하는 것 같다.
• 아무리 퇴근을 일찍 해도 사실 한계가 있다. 어떻게 하면 주말에 아내 없이 두아들을 데리고 뭔가를 할 수 있을까를 고민해야 한다. 최근에는 스케이트를 탔었는데 재밌었고 아빠랑 함꼐 할때 새로운 것들을 많이 시켜주려고 한다. 새로운 곳, 새로운 음식 등 아이들에게 새로운 세계를 열어주고 싶다.
• 공부/교육에 대해서 아직은 크게 신경쓰고 있지는 않지만 첫째가 조금 진지하게 숙제에 임해주면 좋겠다는 생각을 요즘 하고 있다. 너무 장난꾸러기라.
• 조금 더 집이 커졌으면 하는 바램이 있다. 개인적으로 평생 살 집을 빨리 마련했으면 하는데 아직 애들때문에 안될것 같다.
• 캠핑
  • 2번 정도 캠핑을 갔었다. 그리고 허리디스크가 터져서 그 이후론 못갔다. 빨리 매트를 마련해야한다.
  • IGT(IronGrillTable)를 시작했다. 이유는 캠핑을 갔는데 내가 거의 전담 요리사 수준으로 일을 하고 있고, 유투브에서 보는 것처럼 다 같이 앉아서 먹고 싶은데 아직은 그 그림이 안나온다.

회사

• 4년이 넘었다. CTO로 3년 그리고 Head of technology로 첫 1년 시작.
• 점점 더 매니저 일/임원 일에 적응해 가고 있다. 직업인으로서가 아니라 직장인, 회사에 속한 직장인이라는 느낌이 더 난다. 그렇다고 부정적인건 아니다. 한 명의 엔지니어로의 역할들을 해왔다면 지금은 회사 임원으로의 의사결정, 기술적으로 나은 결정도 중요하지만, 현재 회사의 상태와 내부 인원, 비지니스를 고려해서 의사결정을 하게 되는 것 같다. 물론 좀 더 보수적으로 변했을수도 있고, 신중을 기하게 된 것 같다. 해야 하는 것보다는 하지 말아야하는것을 애기를 많이 하게 되었다.
• 링크드인 활동을 시작했다. 글쓰기를 해야 한다는 것을 느꼈고, 더 자주 노출해야한다. 강남역 11번 출구에 나오자마자 네이버 광고를 봤다. 네이버도 이렇게 열심히 홍보하는데 나는 무엇을 하고 있나라는 생각이 들었다.
• 1번 정도 장애가 났고 그 이후에 조직과 담당자를 변경했다. 장애훈련도 진행을 했다. 장애라는 트라우마를 벗어날 수 있을까?
• 장애를 기점으로 Python/Django으로 만든 서버의 API들을 kotlin/spring으로 옮겨가고 있다. 플랫폼 파트는 여전히 Golang을 유지하고 있다.
• 나의 역할이 개발자, 개발 리드의 역할 그리고 소방수 역할을 지나서 매니저 역할, 계획과 비전과 미래를 걱정하는 역할로 가고 있다. 잘 할수 있을지는 모르겠다. 한 회사에서 창업부터 시작해서 큰 회사까지 오래 다닌 엔지니어/개발자들을 만나보려고 한다. 어떻게 그렇게 오래 다닐 수 있는지? 그 원동력은 무엇인지가 궁금하다.
• 회사에서 테크리드를 신설했다. 다른 회사보다 스타트업, 그리고 도메인의 특수성을 반영했고 역할에 대한 다양한 파트의 사람들이 의구심을 가졌지만 결국 만들었고, 앞으로 그걸 잘 작동시키면 될 것 같다. 아직 2-3번 정도의 격주회의로 의사소통들을 이어오고 있는데, 2025년부터는 좀 더 체계를 잡아가려고 한다.
• 11번의 테크세미나를 진행했다. 처음부터 용기를 내주었던 분들에게 감사하다. 때로는 회유로, 때로는 감언이설로 때로는 내가 하고싶은 말을 하거나 다른 리더들을 세워서 기술과 관련된 이야기를 했던 것 같다. 1번은 AWS LaunchDay로 진행하기도 했고, 12월은 쉬느라고 안하고 있다. 내년에 계속할지는 약간 고민 중이긴 하다.
• 1on1은 용두사미가 되었다. 자주하는게 좋지만 약간 할말이 없어지는것도 현실인것 같고. 안하진 않을것 같은데 빈도를 조금 생각하긴 해야할 것 같다. 하지만 반대로 기대를 하는 사람들도 있다. 에너지를 주는 사람이 되고 싶었지만 2024년은 내겐 진짜 에너지가 없었다.
• 같이 함께했던 분들이 하나둘씩 떠나가는 시리즈의 단계에 회사가 온 것 같다. 익히 이전 회사에서 겪었던 부분이라 익숙하긴 하지만 아쉬운 건 어쩔 수 없다. 한편으로는 수 많은 회사들이 이런 시기들을 계속 겪고 있는데 어떻게 시스템이 동작하게 만드는지도 신기한 것 같다. 그게 회사를 만든다는 거겠지.
• 돈과 숫자, 지표들을 들여다 봐야 하는 게 그게 회사에서나 가정에서 잘 안되었던 것 같고, 그게 나의 단점인데 너무 치명적이라 2025년에는 고치려고 한다. 무조건 고쳐야 한다.

커리어

• 여러 가지 언어/기술을 얕게 하는 게 지금 나의 현 상황인데, 깊게 해야 할까를 몇 번 고민을 한 적이 있었다. 물론 그것이 다른 개발자에게 조언 한다는 측면에서는 좋다고 생각했지만 나 스스로 원하는 부분인지에 대한 고민에서는 아니다 라는 결론에 다다랐다. 이유는 결국 나는 무엇을 만들고 싶고, 그 만들고 싶은게 있으면 거기에 필요한 것을 배우고 익히면 된다는 결론이다. 개인적으로 쉽게 쓸 때는 파이썬을 여전히 많이 쓰고 있고, API를 개발할때는 Golang으로 개발 하고 있다. 솔직히 개발 속도는 AI가 있어서 이제 거기서 거기인데, AI가 실제 서버까지 운영은 안 해주니 빠른 언어를 선택하는 게 답이라고 생각한다.
• 앞으로의 커리어에 대한 고민이 있었다. 아니 좀 더 딥하게는 지금 하고 있는 일이 내 인생에서 나 자신이 계속 하고 싶은 일인가?라는 근본적인 고민이 있었다. 개발과 관련된 일을 한지 좀 있으면 20년인데, 길면 길고 짧으면 짧겠지만, 한 번쯤 고민을 해봐야 할 시점이라고 생각했다. 결론은 개발은 재밌지만, 앞으로는 개발과 기술에 얽매이기 보다는 많은것들을 만들어보고 시도하고, 호기심을 가지고, 다양한 일들을 해보고 싶다는 것이다.
• 예전에 두려움이 이끄는 대로 성장해라 라는 주제로 어디에선가 발표를 한적이 있었다. 지금 나의 두려움을 뭘까? 하는 생각에서 고민을 꽤 했다. 프론트엔드 관련된 부분, 데이터베이스, DevOps 이런것들이 내가 잘 모르는 영역인 것 같은데 그 모든 것을 다 할 수는 없고, 회사에서의 업무 그리고 앞으로 개인 커리어, 그리고 나의 삶에서 일의 목적들을 고민해 보고 어떤것을 익힐지를 고민했다. 프론트엔드쪽으로 2025년에는 많이 시도를 해보려고 한다. Next.js로 사이드 프로젝트를 시작했다.

올해 가장 좋았던 책

• 꿈과 돈 : 이렇게 쉽고 빠르게 읽었던 책이 있었나 싶다. 꿈을 이뤄야 돈을 번다라고 생각했는데 그 생각을 깨준 책
• The Software Engineer's Guide Book : 아직 다 읽지는 못했지만 회사에서 많은 분들에게 추천하기도 했고 테크리드, 챕터리드분들에게는 꼭 읽어보라고 권했던 책, 공감이 가는 내용들이 많았고, 어렴풋이 알고 있는 내용들이 책으로 나와서 좋은것 같다. 좀더 이 직업에 대한 다양한 시각들이 생겨나고 성숙해져가는 느낌이 들었다.
• 군주론 : 개인적으로 군주론을 꼭 처음부터 끝까지 읽어보고 싶었다. 예전에 대학생때 읽다가 역사책인가 해서 잘 안 읽혔는데, 요즘에 읽을때에는 회사와 나의 상황에 대해서 빗대어서 혹은 하나의 국가를 회사로, 여러 가지 비지니스 케이스들을 투영해서 생각해 보면 재밌더라.
• 린치핀 : 최근에 읽기 시작한 책인데, 재미있다. 예술에 대해서 다시 한번 생각하게 되고 직장인, 개발자로서 어떻게 예술적인 일을 할 수 있는지에 대해서 고민하게 만든다.

올해의 컨퍼런스

• 현재카드 테크톡
  • 개인적으로 큰 기대를 하지 않고 갔었는데 현대카드의 데이터 관리, 체계 및 AI에 대해서 굉장히 자세하게 볼 수 있었던 시간이었다.
  • 각 부문장분들이 나와서 그냥 슬라이드를 읽는 방식이 아니였고 거기에 온 사람들에게 잘 설명해 주는 느낌이었다. 다른 코엑스에서 하는 컨퍼런스에 비해서 이태원에서 하는 것도 신선했고, 좁지만 그래도 재밌었다.

올해의 가장 특이했던 경험

• 베이블레이드 X 대회

  • 12월에 베이블레이드 x 대회 인천 계양점에 처음 가봤고, 팽이 하나로 남녀노소 5세부터 40대 이상까지 하나가 되는 모습을 지켜봤다. 통성명 없이 베이와 경기장으로 하나되는 진정한 평등한 세계는 여기에 있었다.
  • 사람이 살아가는 데 있어서, 인간과 인간이 만나서 커뮤니티라는 게 이루어지고 그게 왜 필요한지를 알게 되었던것 같다. 물론 완전 100% 공감하진 못했지만 이런 세상도 있구나 하는 생각이 들었다.

• 유치원 졸업 여행

  • 둘째의 유치원 졸업여행을 같이 갔는데, 무서워서 같이 잠도 못 자는데 하루 종일 꼭 붙어서 같이 수납함도 만들고, 튜브도 타고, 레크레이션도 같이 해서 좋은 추억으로 남았다. 비가 엄청 오는 날이라 걱정했는데 나쁘지 않은 경험이었고 무엇보다도 집에서가 아니라 친구들과 같이 있을 때 녀석의 모습을 볼 수 있어서 좋았다.

• 할로윈 캠핑

  • 친척분들 가족과 2박 3일 할로윈 캠핑을 갔다. 재밌기도 했고 할로윈이라는게 아직 어색하지만 그래도 아이들에게는 좋은 추억이 된 것 같아서 좋았다. 아이들을 통해서 새로운 경험을 하는게 큰 행복으로 다가와서 좋다.

• 전반적으로 현재 나에게 새로운 경험이란, 대체로 아이들을 통해서 오는 인사이트 같은 것들이 많은 것 같다. 아이들은 틀이 없기 때문에 거기에서 오는 인사이트들이 나로 하여금 기존의 보이지 않았던 틀을 깨고 나아가게 만들어주는 것 같다.

올해의 툴

• AKIFLOW : 개인적으로 구글 캘린더와 할일관리, 지라, slack, notion에서의 태그 같은 것들이 한번에 관리되는 툴들을 오랫동안 찾았었는데 Akiflow에 정착해서 사용하고 있다. 습관이 들어서 이제는 모든 할일관리를 Akiflow로 하고 있고 출근하자마자, 혹은 일어나마자 하는일이 Akiflow에서 일정을 정리하는 일이되었다. offlight라는 국내에서 비슷한 툴을 만들고 있는것으로 알고 있는데, 아직 Akiflow는 1년을 끊어놓은 상태라 옮겨가진 못하고 있다. 기회가 된다면 ㅎㅎ
• chatgpt : 더 이상 무슨말이 필요할까? 거의 매일 GPT 관련된 내용을 보고 내 삶에 적용해보고 있다. 최근에는 나만의 GPTs를 만들어서 사용하고 있는데 재밌다. 업무와 관련된 부분에도 적용해보고싶고, n8n, make.com 같은것들을 연동해서 생산성을 높여보고 싶다.
• obsidian : 사실 세컨드브레인은 나에게는 잘 안맞긴하다. 약간의 정리 강박이 있는데, 노력이 따라와주지 못하는 느낌. 근데 노션은 너무 느리고 답답하고 커스텀할 수 있는 부분이 없고, 사실 제일 문제는 노션은 망하거나 에버노트 같은 느낌이 될 수 있을것 같다. 그래서 오픈소스 기반의 obsidian을 사용하고 있다. 활용도를 높이기 위해서 적극적으로 쓰고 있고, 아래의 동영상이 많이 도움이 되었다. 특히 캔버스는 도움이 많이 되고 있다.

올해의 유투브

• go ghost : 올해 유난히 지치고 소모되어버린 나를 어떻게 할지 고민이 많았는데 이 유투브를 보게 되었고, 그 다음부터는 스스로를 돌보고 조용히 나의 길을 가야겠다는 생각을 많이 했다.

• life of riza : 얼마전부터 보기 시작한 영상인데, 구성이 좋고 여러가지 활동들을 하는 모습들이 좋아서 자주 보게되는것 같다.

이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다

1세대

꽤 오래전 좋은 키보드가 필요하다고 느껴서 리서치를 했었다. 정확히는 겉멋이었고, 난 MS키보드에서 막 벗어나고 있는 시점이었고, 리얼포스와 HHKB를 접했다. HHKB는 이전이나 지금이나 방향키가 없기 때문에 계속 논외로 취급해왔다. 처음 구매했던 것은 리얼포스87u 였다. 용산역에 거의 붙어있는 키보드 타건을 해볼 수 있는곳(리더스키였다.)에서 리얼포스를 타건을 해보고 구매를 했다. 검은색으로 기억하는데 정말 잘 사용했다. 그 키감은 여전히 그립다. 하지만 리얼포스를 쓰면서 아래와 같은 불편함이 있었다.

1. 맥을 쓰게되면서 키맵핑 프로그램을 썼었는데 너무 귀찮았다.
2. 무거워서 가지고 다니는 게 거의 불가능했다. 사실 휴대성은 지금에서 생각해보면 나에게 거의 필요가 없는 요구사항이긴하다.

결과적으로 내 기준에서의 2세대 키보드로 갈아타면서 리얼포스는 동생이 창업할 때 사무실에서 쓰라고 줬다.

2세대

2세대는 맥만 쓰게 되면서 키맵핑 없이 쓸수 있는 기계식 키보드가 없을까를 찾다가 키크론 k2를 찾았고 구매를 했다. 무려 한국이 아닌 미국사이트에서 ㅎ
키크론 관련 글은 아래의 글을 참고하시길. 그때의 감정이 묻어져있다.

6개월 기다린 키보드 후기

3세대

키크론을 쓰면서 생긴 나의 패턴이 사무실과 집에 회사에서 준 맥북과 개인용 맥북이 각각있고, 같은 키보드를 각각 사서 손에 익게 만드는것이었다. 사무실과 집에서 약간씩 키보드가 다름으로 인해서 버벅이는게 싫었다. 그리고 이때쯤부터 윈도우를 아예 사용하지 않게 되었다. 그래서 집에서는 키크론 K2 청축, 회사에서는갈축을 썼다. 거기까진 좋았는데 키크론은 기본적으로 기계식이어서 다시 무접점을 쓰고 싶다는 생각이 들었다. 그리고 키크론을 쓰면서 느낀점은 나는 블루투스와 맞지 않는다는 것이다. 크롬쉘 방식으로 주로 맥북-모니터1 구조로 쓰다보니 sleep 상태에서 돌아올때 블루투스 키보드가 연결이 약간 끊어져 있는 느낌 그리고 유선보다 덜 빠릿한 느낌이 싫었다. 그리고 2세대를 거치면서 나는 75% 키배열 에서 굉장히 익숙해졌고, 좀 더 작은 65% 배열을 원하게 되었다.

참고 : 키보드배열

정리하면 이제까지의 조건은
- 무접점
- 65% 배열
- 맥에서 키맵핑없이 쓸 수 있을 것
- 윈도우-맥 키 전환이 될 것
- 사실 이건 약간 폐쇄망 환경에서 윈도우-맥을 번갈아가면서 쓰기 위한 조건을 만족하기 위함이었다.

그렇게 찾은게 한성키보드 gk868b였고 지금까지 쓰고 있다. 키크론 k2보다 위에 한줄이 적은데, F11, F12 라인은 Fn 키 조합으로 커버할 수 있다.(키 맵핑 프로그램은 아니다.) 사실 흰색을 2년전에 사고 잘 쓰고 있었고 회사에서는 키보드를 쓰지 않고 맥북 키보드를 썼었다. 회사가 커지면서 코딩보다 회의나 문서 작성이 많아졌고, 한 자리에 앉아있을 시간이 별로 없었다. 그러던 중, 최근에 허리디스크 문제가 발생하면서 노트북 키보드 보다 키보드를 두고 쓰는게 좀 더 자세에 낫다는 생각이 들어서 다시 키크론 갈축을 가져와서 썼다. 근데 그 소리가 너무 크게 들렸다. 다시 하나의 gk868b가 필요해졌다. gk868b pro가 나왔지만 색깔이 너무 화려해서 싫었고, 당근마켓에서 중고거래를 통해서 검은색 gk868b를 65,000원 마련하게 되었다.

지금은 회사와 집에서 gk868b를 쓰고 있다. 집에서는 화이트, 회사에서는 블랙, 장점은 들고다니기도 좋고(사실 거의 유스케이스가 없음) 정전용량식은 아니지만 기계식보다는 나은것 같다. 최근에는 독거미나 레이니75 같은것들도 써보고 싶은데 배열이나 여러 조건에 맞지 않아서 일단 여기에 정착한 상태다. gk868b도 완벽하진 않다. 개인적으로 블루투스 연결 장치가 있는데 아예 빼버렸으면 좋겠다. 유선 USB-C만 있는 gk868b developer edition 같은게 있으면 좋겠다. 만약 만든다고 하면 아래의 조건처럼 만들고 싶다.

• 무접점
• 65% 키배열
• 유선 전용
• 맥 전용

현재에서 나에게 다음 세대의 키보드가 있을까 싶다. HHKB도 사실 중간중간에 많이 고민했다. 대부분의 개발자가 HHKB를 사용하고 있고 키감은 솔직히 좋다. 그렇지만 방향키는 솔직히 적응이 어려울 것 같다. 근데 진짜 리얼포스에서 65% 배열, 유선, 맥 전용이 나오면 무조건 살 것 같다. 최근 2주동안 키보드 세계를 다시 탐닉하고 회사 분들은 어떤 키보드를 많이 쓰는지 봤는데, HHKB도 많지만 다양한 기계식 키보드들이 많고 굉장히 화려한 것 같아서 재미있었다.

최근에 찾아보니 GK868B Pro가 나오긴 했는데 지금 내가 쓰는것과 완전 동일하다고 볼 수는 없고 약간 키캡이 동글동글한 버전이 있는데 관심있는분들은 한번 사보셔도 좋을것 같다. 아마 키감은 동일하고 키캡은 어차피 갈아쓰면 되니까. 그리고 좀 더 펌웨어가 개선되지 않았을까를 기대하고 있다.

이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.

2일 연속 다 참여를 했고, 첫날은 솔직히 늦었다. 수원은 내가 생각한것보다 멀다기보다는 토요일 오전 자동차 트래픽을 감안하지 못했던 것 같다. 첫날은 점심 이후 세션부터 참여했고, 그 전에 여러가지 부스들을 돌아봤다. 매년 나오는 8percent, 래블업, 토스 같은 회사를 보면 대단하다는 생각이 들었다. 단순히 참가하는 입장이 아니라 스폰서로 참가해보면 매년 참가한다는 것이 얼마나 대단한지 알게 된다. 특히 스타트업은 더 그렇다. 내부 설득 과정이 어렵고 특히 요즘처럼 비용적으로 고민이 많은 시기는 더 그럴것이다.

포스터 세션은 매년 있었던 것 같지는 않은데 이번에 조금 넓은 공간에 있어서 좋았던 것 같고, 다양한 파이썬을 이용한 시도들이 있어서 좋았다. 따로 오픈공간에서 이야기하지는 못했지만, 그래도 예전에 함께했던 친구를 만나서 파이썬 개발자 수급 및 여러가지에 대해서 이야기 할 기회가 있었다. 지역이 가까우면 만나겠는데, 멀게 되면 이런 자리를 빌어서 만나게 되는것 같다.

첫날 들었던 세션 중에서는 “저는 파이썬을 가르치는 초등학교 교사입니다.“ 라는 세션이 제일 기억에 남는다. 아이를 키우면서 그리고 이제 아이가 컴퓨터를 배우면서 코딩 교육에 대한 생각이 조금씩 생긴다. 예전의 나처럼 게임 -> 컴퓨터 -> 코딩으로 관심이 이동하면 좋겠지만 요즘은 코딩 수업이 따로 있을만큼 아이들에게 가까이 와있다는 생각이 들었다. 교사의 입장에서 교육의 난이도에 대한 고민도 많으셨던것 같았다. 특히 놀랐던것은 나라면 빨리 코딩을 해서 결과물을 보여주는 부분에 초점을 맞추고 거기서 재미를 느끼게해서 더 그 다음으로 진입하게 할 것 같았는데, 교육적인 부분에서는 코딩을 통해서 다른 논리나 수학적인 부분을 키워줘야 한다는 것이었다. 스스로 조금 기능적인 부분에 너무 초점을 맞추고 있었다는 생각이 들었다.

둘째날은 키노트 세션/오전세션이 제일 좋았던 것 같다. 신정규님의 "Python과 PyCon 공룡시대의 닭들의 행성" 세션을 들으면서 새삼 나도 비슷한 여러가지 기술/툴들을 써본것 같아서 나이가 들었나? 하는 생각이 들었다.

어디에나 파이썬이 있는 시대가 되었다는 것에, 그리고 그 과정에서 여러 회사에서 파이썬을 실무 운영레벨에서 치열하게 고민하고 PHP, Java를 사용하던 동료, 선임들을 설득했던 날들이 생각이 났다. 이제 그럴 필요는 없어졌고, 사람들은 시들해졌다고 생각할 수 있으나 여전히 많이 쓰고 있고 그건 통계로 이미 증명이 되었다고 생각한다.

"파이썬, 기술에서 커뮤니티와 인간으로"라는 주제로 배권한님이 발표를 해주셨는데, 예전에 한번 파이썬을 사용하는 회사와 시니어 개발자에 대해서 인터뷰를 한 적도 있었지만, 그런 부분에서 많은 고민이 엿보였다. 회사 생활과 별개로 이런 오픈소스 활동을 한다는 것은 진짜 어렵다. 특히, 한국에서는 더 그렇다. 나이가 들면 회사-오픈소스 외에도 회사-가정-오픈소스 이렇게 전환이 되는게 그 안에서 계속 오픈소스와 그와 관련된 커뮤니티활동, 고민을 이어나간다는 것은 정말 대단한 일이다.

--

개인적으로 수원컨벤션 센터를 멀지만 그래도 광교호수공원과 갤러리아 백화점이 있어서 점심시간이나 잠깐 쉬기에도 좋았던 것 같다. 원래 라이트닝 토크로 4년간 django로 회사를 운영한 경험이나 최근에 회사의 주 언어를 django에서 kotlin/spring으로 변경하면서 느꼈던 점을 발표할까 했지만 너무 급하게 발표하긴 싫다는 생각이 들었다. 내년에도 마음이 있다면 되게 애매하지만 이 주제로 발표를 할 것 같다.

⏳이 글에는 다수의 스포일러가 포함되어 있을 수 있습니다.

이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.

팀원 모으기

주인공 오바나 나츠키는 파리에서 몇 년전 큰 사고를 치고, 다른 레스토랑에서 써주질 않기에 전전한다. 그 과정에서 미슐랭 별을 받고 싶은 하야미 린코를 만나게 되고 둘은 그랑 메종 도쿄라는 프렌치(프랑스요리) 레스토랑을 창업하게 된다. 당연히 둘 만으로는 되지가 않는다. 다양한 파트의 동료들을 모으기 시작한다. 지배인, 보조셰프, 디저트 담당, 식재료 담당 등. 대부분의 동료들은 몇 년전 오바나가 친 사고로 악감정을 가지고 있는 상황. 당연히 동료가 바로 될 수가 없다. 이 과정에서 요리 자체로 설득을 하거나, 그 사람이 현재 일하고 있는 곳에서 도와주거나, 과거에 함께 일했을 때 좋은 기억을 되살려주거나, 더 성장할 수 있게 푸시하는 식으로 설득을 해나가고 결국 그랑 메종 도쿄에서 미슐랭 3스타를 위해서 함께 일을 하게 된다.

스타트업 초창기도 마찬가지다. 초반에는 아무것도 없다. 자본도 없고, 제품도 없다. 그나마 mvp가 나왔으면 다행이다. 내가 이제까지 다른 직장에서 일해온 시간에서 제일 좋았던 기억들을 떠올리고 그때 함께했던 그 사람들을 찾아서 새로운 스타트업의 합류의 의사를 묻는다. 당연히 거절이다. 가정이 있거나더 큰 회사에서 경험을 쌓고 싶어하는 분들도 있다.(그랑메종도쿄에서도 마찬가지) 그래도 나를 믿고 스타트업에 합류해주시는 분들이 있다. 그 분들에게는 신의를 지켜야 한다. 초기에 스타트업에서 주니어 혹은 신입으로 합류하시는 분들이 있다. 빠르게 성장하기 위함이라고 생각을 하는데 지금의 회사에서도 있었고, 빠르게 성장하는 모습들을 보여주었다. 초반 스타트업에서 팀원을 모으는데 은총알은 없다. 각자의 스타트업 초기 멤버가 가지고 있는 인적자원 혹은 무기로 그 단계를 돌파해 나가야한다.

디저트 담당인 마츠이는 자신이 만드는 디저트에 대한 자부심이 있었지만 오바나의 혹평을 듣고 더 그랑 메종 도쿄에 합류해서 더 성장하고 싶어한다. 이런 모습은 이상적인것 같다. 돌이켜보면 초기 단계에서 우리를 찾아오는 개발자들이 시니어일수는 없기 때문에 성장하고 싶어서 눈이 반짝이는 분들을 선택했던 것 같고, 다 성공적이진 않았지만 대체로 그런 분들은 내적동기가 강한편이라서 계속 스스로 성장하는 모습을 보이고 그런 분들이 많아지면 전체적으로 회사의 분위기가 달라진다. 초기에 시니어가 있으면 좋은가? 라고 묻는다면 단서를 달고 싶다. 무조건적으로 시니어가 있어야 한다라기 보다는 니일내일 가리지 않고, 일을 하고 단계를 넘어가는데 주저하지 않는 시니어라면 좋을것 같다.

투자

오바나의 사고 때문에 피해를 입은 사람들이 새로 여는 레스토랑에 대해서 탐탁치 않아 한다. 그래서 은행에서 대출을 받으려고 해도 쉽지가 않다. 요리로 담당자를 설득을 해도 무리다. 그 과정에서 과거 동료의 도움을 받아서 대출을 받고 레스토랑을 열게 된다. 스타트업의 투자를 보면, 한번 이상 창업을하고 투자 유치를 했던분들이 더 수월하게 받는것 처럼 보인다.(아닐수도 있다.) 그 만큼 과거의 경험과 평판은 중요한것 같다. 만약 이전에 스타트업에서 사고를 치고, 문제를 일으켰던 대표에게 누가 투자를 하겠는가?

돈에 대한 투자 뿐만아니다. 오바나의 제자 쇼헤이는 모종의 이유로 경쟁업체 카쿠 레스토랑에 탄고 셰프와 일하게 된다. 일하게 되는 과정을 보면 이전에 같은 직장에서 일을 했었고 탄고셰프는 쇼헤이의 실력을 알고 있어서 채용을 하게 된다. 평판이라는게 얼마나 중요한지를 보여주는 대목이다. 물론 쇼헤이는 이 평판때문에 고초를 겪는다. 그럼에도 쇼헤이의 동료들은 쇼헤이와 일을 하고 싶어한다. 왜냐하면 같이 일을 했을때의 경험이 좋았기 때문이다.

가끔 스타트업에서 보면 무례하거나 혹은 문제를 일으키고 도망가는 식으로 퇴사를 하는 분들이 있다. 다신 업계에서 안볼 것 같지만 언제 어디선가 그런것들은 본인 스스로가 정산을 해야 할 시점이 온다. 그래서 나는 누군가에게 함부로 하지 않으려고 한다. 퇴사를 하더라도 인수인계 문서를 잘 작성하고, 나 다음에 있을, 그리고 남아있을 동료들을 위해서 최선을 항상 다했다. 그건 스스로에 대한 프로페셔널함과 동시에 동료들을 위한 당연한 배려, 그리고 미래의 나를 위한 투자라고 생각한다.

버티기

이 드라마의 중반부는 계속 동료모으기 그리고 오바나의 실수에 대한 보복을 하려는 음해공작으로 이어진다. 사고친 셰프가 도쿄의 레스토랑을 열었다고 하는데 누가 오겠는가? 다들 오바나를 탓하고 있을 때 오바나는 움직인다. 갑자기 지역 음식 축제에 나가면서 원래 만드는 프랑스 요리와 상관없는 카레 등의 요리를 가지고 나가고 결국 오바나의 레스토랑에서 나온 걸 알고 쫓겨나지만 음식은 맛있어서 SNS를 통해서 인기를 되찾는다. 그리고 그랑메종도쿄는 다시 정상영업을 할 수 있게 된다.

스타트업을 하다보면 원래 하려고 했던 일 외에 이상한 일을 해야하는 시점들이 온다.(물론 이건 회사마다 다르다.) 정부과제나 더 나아가서는 SI를 해야하는 경우도 있다. 자원자체가 풍부하면 좋겠지만 대부분이 그렇지 못하고 원래 가려고하는 길을 직선으로 생각했지만 우리는 구불구불한 길을 가야할지도 평지가 아닌 오르막과 내리막의 연속을 가야할 경우도 있다. 당연히 예상보다 자원은 더 필요로 하고 그것들을 마련하는데 부차적인 상관없는 일을 할 수 밖에 없는 경우가 있다. 물론 그런것들로 연명하는 스타트업은 빨리 탈출하는게 맞지만, 거기서 나오는 수익에 매몰되어 있는지, 원래 가려고 하는 길의 연장선상에 있는지 보는 게 중요할 것 같다.

이런 작업을 하면 동기부여가 구성원들이 떨어지기 마련이다. 왜 이걸 해야하나? 라고 바로 의문이 들수 밖에 없다. 창업자나 파운더들이 해야하는 일은 이때 왜 이걸 우리가 지금 해야하는지 잘 소통하는 것이다. 이해할 수도 있고, 이해하지 못할수도 있다. 이해하지 못해서 떠난다면 어쩔수 없다. 하지만 소통은 해야한다.

성장

그랑메종도쿄에서 자주 나오는 대목이 어떤 요리나 디저트를 만들었을 때 미슐랭 3스타 레스토랑에 걸맞는 것인지를 서로에게 계속 물어본다. 디저트 담당인 마츠이는 이 부담감에서 헤어나오질 못한다. 주인공인 오바나 역시 메인 요리에서 미슐랭 3스타급의 요리를 만들려고 노력을 한다. 중요한 점은 각 파트에서, 에피타이저, 디저트, 와인, 메인요리를 만든 사람들이 주방의 인원들에게 요리를 선보이고 그 사람들은 미슐랭 3스타를 이 요리로 딸 수 있는지를 냉정하게 평가한다. 그리고 미흡한게 있으면 바로 그 자리에서 지적한다.

스타트업 세계에서는 성장을 자꾸 이야기한다. 성장이 도데체 뭘까? 스타트업에 와야만 성장할 수 있는 걸까? 사실 잡부인데 성장이라고 포장하는 게 아닐까? 이런 물음들을 스스로 많이 해왔다.

철저히 개인적인 생각인데 스타트업 안에서 개개인이 성장하려면 해당 조직이 원하는 기준이 높아야 하고, 그걸 맞추기 위해서 서로가 챌린지 해야한다. 서로가 그 기준을 맞추기 위해서 푸시하거나 끌어올리거나 노력을 해야한다. 스타트업에서 일이 많다고 해서, 그 일을 다 해냈다고해서 성장했다? 라고 말할 수 있을까? 기준은 결국 리더가 잡아야 하고 항상 높은 수준의 기준을 가지고 지키기 위해서 노력해야한다. 그래야 구성원이 성장한다.

그랑메종도쿄에서 오바나가 파리에서 에스코피유라는 레스토랑을 운영했었고, 동료들은 거기서 함께 했었다. 그래서 드라마에서 보면 많은 사람들이 에스코피유의 요리에 대해서 극찬하는 부분이 나온다. 높은 기준이 있는 조직에서 성장한 구성원들은 퇴사를 하더라도 예전을 그리워하고 다음 회사를 다고 좀 더 높은 기준에서 본인이 성장할 수 있는 곳을 찾게 된다.

스스로를 믿기

그랑메종도쿄에서는 이런 순간들이 많이 있다. 결정적으로 하야미는 오바나와 함께해서 성장했고, 미슐랭 3스타에 걸맞는 요리를 만들어내지만 스스로 믿지를 못한다. 하지만 결정적인 순간에 스스로를 믿고 자신의 요리로 밀어 붙인다. 그리고 결과를 만든다.

보면서 굉장히 중요한 부분이라고 생각했다. 유난히 이 스타트업계에는 말이 많다. 이렇게 해야한다. 저렇게 해야한다. 블라블라블라. 이미 한번 성공하거나 성공한 스타트업에 다니는 사람들, 그리고 그 사람들이 쓴 책과 팟캐스트, 블로그 등에서 참견들을 한다.(어쩌면 이 글이 그런걸지도 모른다.) 그런것들이 어느 순간까지는 도움이 된다. 내가 몰랐던것, 그리고 회사를 만들어나감에 따라 공통적인 영역에 대해서는 도움이 된다. 다만, 중요한건 어느 순간/시점이 지나면 하나의 스타트업은 고유해지고(unique) 그에 필요한 방식과 도구들이 있어야 한다. 고유해지는건 도메인의 특성일수도 아니면 대표의 스타일일수도, 회사의 문화일 수도 있다.

고유해진 시점부터는 스스로를 믿는 게 중요하다. 외부에 있는 소위 전문가들이 우리 회사를 알까? 얼마나? 참고하되 맹목적이진 말아야한다. 스스로 맞는 방향이라고 믿는다면 밀고 나가야 한다. 여기서는 이렇게 했네, 저기서는 저렇게 했네라는건 의미가 없다. 결국은 어떻게든 결과를 만들어내면 된다. 어떤 방향이었고, 거기에 도착했다면 맞는 방향이었던 것이다.

생각해보면 그런 참견의 말들도 결국 결과를 만들어낸 어떤 방향에서 시작했고, 그게 결과를 내니까 소위 맞는 방향, 참견의 말이 된것일 뿐이다.
제발 스스로를 믿자.

떠나기

거의 마지막 화가 되었을 무렵 오바나는 그랑메종도쿄를 떠난다. 스스로 떠나야 할 때를 알게 되었고 그래서 떠나게 된다. 스타트업이 어느정도의 투자를 받고 성장을 하게되면 초반의 멤버들이 떠나는 시기들이 온다. 혹자는 회사의 성장을 개인이 따라잡지 못해서라고 하지만 개인적으로 동의하진 않는다. 다만, 창업자가 아닌 이상에는 모든 임직원들은 스스로 떠나야 할 때를 직감적으로 안다.(이건 스타트업만 그런게 아니다.) 내적 동기부여가 안되는 경우도 있고, 여러가지를 이 회사에서 다 해봐서 그럴수도 있고, 성장할 만큼 성장해서, 다른 사람/회사와 일해보고 싶어서, 다른 도메인을 해보고 싶어서일수도 있다,]. 넷플릭스의 스포티파이 관련 시리즈인 플레이리스트를 보면 전체 6화 중 절반정도가 초반 멤버가 떠나가는 이야기다. 그만큼 흔한걸수도 있다.

잘 떠나는 것도 중요하다. 초반 멤버들에게 하고 싶은 말은 개인과 가족의 생활을 희생하고 여기까지 달려와서 떠나는 것이 허탈 할 수도 있다. 하지만 그분들에게 말씀드리고 싶은건 개인의 인생에서 한 파트로 남겨두면 좋을 것 같고, 사회라는 곳에서 제품/서비스를 만드는 회사를 만들었다는것, 그리고 남겨진 멤버들이 있다는 것을 자부심을 가졌으면 한다. 사회에서 몇명이나 회사를 만들어봤을까?

추억을 가져야 한다.

아이들과 아내와 삶을 살아간다는 것.

그건 시간을 함께 보내고, 경험을 나누는 것

결국 그걸 지향해야하지 않을까.

아이들이 모래놀이는 하는 동안 족욕을 할 수 있는 곳이 있어서 족욕을 했다. 뛰어노는 아이들과 잔디 그리고 녹색으로 뒤덮힌 산을 보면서 강원도에 왔구나라는게 실감됐다. 어떻게 보면 참 별거 없는데 왜 이제까지 내 자신을 위한 이런 노력도 안하고 있었나 싶다. 매년 아이들과 같이와도 애들이 커가면서 색다른 추억들이 쌓일것 같다.

애매한 7시반 정도의 시간이라 내부에서 마땅히 먹을곳이 없었다. 밖에 나가서 밥을 먹기로 했다. 평창한우마을 면온점, 최근에 전현무가 다녀갔다는 것으로 걸러야겠다라는 생각이 들었는데 마땅히 대안도 없어서 갔다. 아내가 이번에는 차를 가져가지 않고, 셔틀버스가 오는것을 선택했다. 그렇게 내키지는 않았다. 셔틀버스 안에서 다른 사람들과 같이 앉아서 불을 끄고 가는데 한 10분정도의 거리동안 휴대폰을 보지 않고 휴가의 시작에 대해서 생각해보게 되었다. 셔틀버스의 선택부터가 이번 휴가가 조금씩 내가 이제까지 여행해왔던 방식이랑 다른것 같았다. 아이들도 처음 경험해보는거라 신기해했다. 음식점에서 한우모듬세트를 시켜서 먹었는데 분명히 배가 안고프다는 아이들이 약 15분만에 한우를 거의 다 먹어 치웠다. 식욕이 떨어졌다. 아내는 막국수를 시켰다. 개인적으로 좋아하는 한우를 아이들에게 구워주면서 이렇게 아버지가 되는구나라는 생각이 들었다.

음식점의 선택은 괜찮았던것 같다. 유명 연예인이 오는 곳을 잘 거르게 되는데, 몇가지 좋았던 점을 설명하자면, 1) 현지의 싼 가격은 아니지만 맛은 있었다. 2) 아이들을 위한 여러가지 이벤트가 있었다. 예를 들면, 사탕을 주거나 아이스크림을 먹을수 있거나 비눗방울을 주거나 3) 생각보다 체계적인 곳이었다. 숯 관련 구역이 따로 있었고, 계산대와 셀프바 근처에는 평창, 봉평 로컬푸드를 파는 진열대가 있었다. 화장실 문에는 음식점에서 하는 다양한 리뷰 이벤트들이 있었다. 그리고 밖에는 무대가 있어서 뮤직비디오가 틀어져있었다. 다시 리조트로 가는 셔틀버스를 기다리는 시간 동안 아이들은 뮤직비디오를 보면서 춤을 췄고, 우리는 웃기 바빴다.

다시 셔틀버스를 타고 오면서 이런 경험도 재밌다고 느꼈다. 리조트로 돌아온 아이들은 생전 처음보는 투니버스 채널에 빠져서 보다 늦게 잠들었다.

--

2일차 아침이 밝았다. 창문을 여니 안개가 자욱했다. 같은 시각이라도 강원도에 있으니 뭔가 상괘한 공기가 느껴졌다. 밍기적 거리다가 첫째가 일어나서 또 투니버스 시청을 시작했다. 텔레비전 소리에 둘쨰가 합류했다. 둘째는 언제 워터파크를 가냐고 나에게 물었고, 나는 밥을 먹어야 갈 수 있다고 했다. 당장 자고 있는 엄마에게 "엄마, 아침이야, 일어나" 라고 둘째가 말했다.

조식도 포함이 되어 있는 패키지 였는데, 확실히 성수기라서 약 20분정도 기다렸던것 같다. 구성은 나쁘지 않았다. 집에서 먹는 종류와 비슷하게 계란, 빵, 야채, 과일로 먹었다. 요즘 건강관련 인스타를 많이 봐서 그런지 밀가루 종류보다는 빵과 과일을 먼저 먹었다. 쌀국수도 있었지만 참았다. 에소프레소에 얼음을 넣어서 따뜻한 아이스 아메리카노(잔이 따뜻했다.)를 먹고 다시 방으로 돌아왔다.

이제 워터파크를 가야한다. 가기전에 오늘 무엇을 할 것인지 계획을 세웠다. 그 전에 원래 할려고 한 전체 리스트들은 다음과 같았다.

• 워터파크
• 루지
• 곤돌라
• 상상놀이터
• 태기산 CC 투어

이 중에 태기산 CC 투어는 골프카트를 타고 18시에 골프장을 한 바퀴도는걸로 내가 하고 싶었는데 포기했다. 애들이 그리 좋아할것 같지도 않고, 시간이 애매해서 포기. 일단 오늘은 워터파크, 루지만 하기로했다. 루지가 16시에는 가야해서 워터파크는 늦어도 15:30분에는 나와야했다.

5년전에 간 워터파크는 시장통이었다. 그때보다는 사람이 적었다. 아쉬운건 야외 일부 슬라이드들이 운영을 하진 않았지만 놀기엔 충분했다. 둘째가 악어 튜브를 빨리 바람을 넣어달라고 했다. 악어튜브는 바람이 샌다. 그래서 되게 자주 넣어야 하는데, 그래도 큰 튜브를 이용할 수 있는 곳이 그리 많지 않아서 바람을 넣어 주었다. 첫째는 2단발사 물총을 가져왔다. 다른 사람들이 물총이 없는것을 보고 아내가 못하게 했지만 계속 들고 다녔다. 유수풀, 파도풀 등 다양한 곳들에게 즐겼고 나는 간간히 썬배드에 누워서 잠을 청했다. 몇년전부터 약간 젖은채로 썬배드에 앉아서 비치타올로 몸을 덮고 그늘 아래에서 있는게 좋았다. 사람들이 여유가 있는 모습, 파란하늘, 수영장, 그리고 아이들을 보고 있는것만으로도 좋았던것 같다.

첫째는 이제 혼자 놀기를 원하는것 같았다. 수영을 다녀서 곧잘 하지만 혼자서 슬라이드 타고 내려오고 이제 같이 뭘 하기 보다는 옆에 있어주기만해도 될 것 같다는 생각이 들었다. 워터플레이라는 약간 작은 미끄럼틀과 종아리까지 오는 풀이 있었는데 거기에서 첫쨰, 둘째랑 악어튜브 쟁탈전을 했다. 서로 물멕이고, 물을 쏘고, 잡고 땡기고 장난치고 아무 생각없이 그럴수 있어서 좋았던 것 같다.

마지막 2시간은 유수풀에서 꽤 놀았는데, 심심해서 악당 역할을 맡았다. 물총을 가지고 유수풀에 애들과 아내가 돌아다닐때 계속 물총을 쏴댔다. 첫째와 둘째가 재밌어했다. 물을 채우고 물을 쏘고, 계속 뛰어다니는데 순간 예비군같다는 생각이 들었다. 오후 3시가 되어서 나가자고 하니 싫다고 했다. 그럴줄 알았다. 루지를 지금 나가지 않으면 못탄다고 했다. 바로 가자고 한다. 워터파크랑 리조트랑 가까워서 와서 바로 샤워하고 머리를 말리고 루지를 타러 갔다.

루지 헬맷을 먼저 쓰고 리프트를 타고 올라가서 루지를 타고 내려오는 코스인데, 헬맷부터 첫째가 화를 내기 시작했다. 파란 헬맷을 쓰고 싶었던 모양이다. 아쉽게도 여기에는 파란색, 빨간색, 핑크색 등으로 사이즈를 구분하고 있어서 파란색은 엑스라지, 핑크색은 스몰이다. 나는 파란색을 아이들은 핑크색 헬맷을 썼다. 리프트를 타고 올라가면서 아이들도 리프트가 처음이기 때문에 매우 신기해했다. 나도 겨울이 아닐때 리프트를 타니 눈이 아닌 도토리 나무나 여러가지 시설물들이 보이면서 조금 무서웠다. 리프트에 내려서 루지 교육을 받았다. 루지는 이번이 2번째인데, 아직 아이들은 어려서 부모님과 같이 타야했다. 나랑 첫째 그리고 아내와 둘째가 같이 탔다. 스키장에서 내려오는 루지는 긴코스여서 재미는 있었지만 곳곳에 여러가지 속도를 줄일수 있는 장애물들을 배치해놔서 속도를 내기는 어려웠던것 같다. 곧 아이들도 스스로 타게되서 넷이서 타면 더 재밌겠지.

바로 곤돌라를 탔다. 원래 스케쥴에는 없었지만 저녁식사보다 약 1시간 정도 남아서 곤돌라를 타고 정상으로 올라갔다. 약 15분정도 걸렸지만 올라가길 잘했다. 긴 초원처럼 펼쳐져 있었고, 아래에서는 다른 바람이 불어올라왔다. 뛰어노는 아이들을 보면서 잘 올라왔다는 생각이 들었다. 원래 스키장 정상이라 늘 올라오면 내려갈때 그 두려움이 있었는데, 눈이 없을때는 그 두려움보다도 멀리 보게 되니 강원도 산자락들이 보였다. 겨울에는 다 눈으로 뒤덮히고 스키와 스노우보드 타는 사람들이 많겠지, 이번 겨울에는 아이들과 함께 다시 오고 싶다는 마음이 생겼다. 다른 한편으로는 나도 다시 스키를 탈 수 있는 몸을 만들어야 겠다는 생각이 들었다.

내려오는 곤돌라에서 둘째는 벌써 자기 시작했다. 워터파크, 루지, 곤돌라 등 계속 뛰어놀았고 햇살이 따가운탓에 얼굴일 빨개지고 코가 딸기코가 되었다. 그래도 밥은 먹어야 했다. 이것도 패키지에 포함되어 있기 때문에. 아이들은 무료인데 뷔페에서 다양한 음식과 샴페인을 먹었다. 회도 맛있었고, 고기도 맛있었다. 더할 나위없었다. 아내가 너무 많이 먹어서 어떻게 해야할지 모르겠다고해서, 이제 가서 자면 된다고했다. ㅎㅎ 아이들은 리조트에서 또 투니버스를 봤고 나는 누워서 넷플릭스를 봤다.

자기전에 애들이랑 같이 티비를 봤는데 투니버스에서 명탐정 코난을 해주고 있었다. 코난의 클리셰, 수면침을 쏘고 사건을 해결하는, 설명을 해주기 아이들이 신기해했다. 아빠가 어렸을때도 있었던 애니메이션이라고 했다. 원래 코난은 어린애가 아니라 어른이라는 것과 검은모자 악당들이 있다는 것, 그리고 아직도 결말이 안났다는 것(맞나?)을 알려주니 신기해했다. 근데 나는 코난에 감사했다. 애들이랑 이렇게 애기할 수 있는 거리가 있다는게, 세대를 초월해서 말이다.

소파에서 잠을 자는데 첫째가 무섭다고 같이 자자고 했다. 에어콘이 거실에만 있는 구조라서 약간 더웠고, 많이 먹어서 그런지 좀 힘들었다. 이제 과식은 안되겠구나라는 걸 몸소 깨달았다. 뒤척임이 계속 되었고, 너무 피곤한 둘째날의 밤이 지나가고 있었다.

너무 많이 먹은탓, 잠자리가 잘 나랑 안 맞는 탓에 셋째날 오전 컨디션이 별로였다. 아침에 일어나서 조식을 먹으러 갔고, 어제와 같은 음식이기에 더부룩하지 않은 음식으로 하루를 시작했다. 어제 약속했던 상상놀이터에 아이들과 아내를 보내고, 첫날갔던 야외 족욕하는 곳에서 찬물로 족욕을 하면서 이 휴가를 돌이켜봤다. 더할 나위 없었다. 아이들이 짜증도 있었고, 더위도 있었고 그래도 다 작은 추억들인것 같다.

다시 일상이 시작된다. 무섭기도하고 좀 더 긴 휴가였으면 좋겠다는 생각도 들지만 그래도 재밌었다.
여름이 지나가고 있었다.

몇 주정도 사용해 보다가, 최근에는 일선에서 코딩을 잘안하는데 golang으로 웹훅을 만들어줄 일이 있었다. 원래 얘기했던 일정 하루 앞두고 시작했는데 chatgpt의 도움을 많이 받았다. 활용한 부분은 파라미터에 대한 반복 작업 그리고 막히는 문법적인 부분에 대한 검색이었다. 6시간 정도 chatgpt와 함께 작업을 하고 신기한 감정들이 들었다.

개발자의 시대 : the era of developers

약 14년 이상 일을 해오면서 IT 주류업계에 있진 않았지만 그래도 변해온것들을 몸소 느껴왔다고 생각하는데 지극히 주관적으로 몇가지 시대를 나열하면 이렇다.

• 도제 시대
• 인터넷 검색 시대
• AI 협업 시대

사실 이 시대의 구분은 개발자가 얼마나 정보에 쉽게 접근할 수 있는지를 기준으로 잡았다. 나는 1~2년 차 정도에는 도제식의 회사에 다녔다. 어떤 개발 관련 정보를 사수를 통해서만 알 수가 있었다.(그래서 약간의 라인도 있었던 것 같다.) 물론 개발문화도 달랐다. 그렇지만 인터넷에서 개발 관련 정보를 국내에서 찾긴 어려웠고, 책과 사수의 지침을 통해서 배우는 게 일반적이었다. 장점은 글쎄.. 뭔가 그때 나름대로의 끈끈함? 그런게 있었던 것 같고, 단점은 정보를 접할 수 있는 한계가 있다 보니 개인의 성장이 회사나 사수를 넘기가 어려웠다고 생각한다.(물론 그때도 커뮤니티 활동을 통해서 더 많은 정보를 접하시는 분들이 계셨다고 생각한다.)

그 다음은 인터넷 검색의 시대인데, stackoverflow.com가 나오기 전에 c#으로 일을 했을때는 훈스닷넷이나 KLDP 같은곳에서 정보를 얻었다. 그리고 개인 블로그들이 활성화되고, stackoverflow.com, github가 나오면서 인터넷에서 검색하는 것들이 일반화 되었고, 더 검색이 쉬워진것 같다. 이 시대(지금도 이 시대의 끝자락에 있지 않나 싶다) 장점은 이전 시대의 단점을 보완한다. 다양한 회사와 단체, 오픈소스, 소스코드를 접하면서 개인이 성장할 수 있다. 단점은 인터넷에 있는 정보는 대체로 평이해서 어느 수준이상의 정보들을 찾기란 어렵다.(사실 이건 책도 마찬가지.) 또 굳이 단점이라면 회사가 신입에게 요구하는 것들은 점점 더 높아졌다. (물론 코로나 시대의 개발자 수요 증가도 한몫했다고 생각한다.)

다음은 AI를 활용하는 시대인데, 지금이 그 초입에 오고 있는것 같다. 이제는 구글 검색이 아닌 AI로 검색을 하며 사람들은 더 이상 서로에게 어떤 기술적인 것들을 예전만큼 묻지 않는다. 예전에 선배에게 물어보기 전에 구글 검색을 하고 가라는 애기가 있었고 구글 검색을 잘 하는 방법들을 소개도 되었었다. 그런데 지금은 chatgpt가 이상하게 물어봐도 어느정도 수준까지 제대로 답변을 해준다. 그러다보니 서로 물어볼 필요가 없이 chatgpt에게 개인들이 물어보고 있고 그것들을 활용하고 있는 시대이다. 나는 이 시대를 AI를 통한 셀프서비스의 시대라고 생각한다. 장점은 아무래도 기존 개발자 2~3명이 했던 일들은 1명이 처리할 수 있게 될 것이고, 단점은 ai가 헛소리를 할때가 있다고 하지만 그건 점점 개선이 될 것이고 단점이라 볼 수 없고, 굳이 단점이 있는가 싶다. 한편으로는 협업적인 측면에서 예전보다 서로의 교류가 더 적어질 것 같다. 생각해 보면 개발자 입장에서 기술적인 습득 부분이 AI를 통해서 대체할 수 있다고 하면 사실 대부분의 회사에서 가지고 있는 협업을 위한 가이드라인, 그라운드룰을 익히는데는 수습기간 3개월이면 충분하다.

앞으로의 공고에서 chatgpt, 코파일럿을 회사에서 지원해주는지가 복지 아니 필수가 될지도 모른다. 아니, 내가 지금 개발자를 채용해하는 대표라면 chatgpt, 코파일럿 제공을 JD에 쓸 것 같다.

개발자 관점

기술은 계속 변한다. 그리고 그것들을 익히기 위한 어떤 것들이 있었다. 강의, 책, 스터디 등등 그러나 이런 것들은 이제 AI에 의해서 사라질 것이다. 아니면 좀 더 다른형태로 변경될 수 있을것 같다. 이제 개발자들은 굳이 뭔가를 만들기 위해서 이전보다 많은 수고를 들일 필요가 없다. 백엔드 개발자인 내가 프론트엔드를 해야 할까 생각하지만 프론트엔드 코딩을 chatgpt에게 시키면 된다. 지금도 chtgpt로 코딩에서 노동적인 일들은 다 대체가 되고 있다. 그럼 남는건 뭘까? 우린 사라져야 하는 걸까?

고민을 해보다 결국 남는 건 협업이다. AI가 협업을 대신해주진 않는다.(솔직히 모르겠다. 해주게될지도) swagger를 만들고 문서를 만드는걸 도와준다고? 그건 협업이 아니다. 협업을 더 잘하기 위한 재료와 도구일뿐. 도제식의 개발자 시대에서 인터넷 검색 개발자 시대 그리고 이제는 AI를 활용하는 개발자의 시대다. 구현을 잘하는 개발자에서 협업을 잘 하는 개발자의 시대로 넘어가고 있다고 생각한다. 구현은 이제 너무 당연한 것이 되어가고 있다. 그런 애기를 들었다. 이제 사람들은 스파게티가 맛있는 집을 찾아다니는게 아니라고, 왜냐하면 그건 이미 너무 당연하게 되어서.

창업자 관점

AI가 좋은 점은 사람들이 가지고 있는 일정 수준 이하의 지식의 벽을 허물었다고 생각한다. 이전에 꽤 많은 것들을 어떤 전문가에게 의존했다고 생각한다. 마케터, 개발자, 디자이너 하지만 이제는 그럴 필요가 없어졌다. 다양한 AI 기반의 마케팅, 디자인 툴들이 나오고 있고, 개발자 역시 필요는 하겠지만 예전만큼 필요할까 싶다.

내가 만약 지금 창업한다고 하면 최대한 AI툴을 유료로 구매해서 쓸 것같다. 대부분의 AI툴들은 인건비보다 싸다. 물론 실제 뭔가를 만드는 것과 조언을 받는것은 일이 된다는 차원에서 다르다. 하지만 지금 창업을 하는 사람들이라면 AI 도구 비용과 인건비에 대해서 진지하게 고민해봐야 한다. 개발자 5명으로 팀을 꾸릴 것인가? 아니면 AI를 잘 활용하는 개발자 2명으로 팀을 꾸릴 것인가?

--

나는 왜 이런 글을 작성하게 되었을까를 작성하고, 퇴고하는 동안 생각을 하게 되었다. chatgpt가 나온 지도 꽤 되었고, 주변의 개발자가 사용한 지도 꽤 되었는데도 말이다. 글을 쓴 계기는 결국 AI활용에 따라서 사람들의 행동/커뮤니케이션이 달라지고 그것들이 내가 인지할 수 있는 수준으로 내 주변에서 관찰/감지되었기 때문인 것 같다.

지금 이 글을 AI에 의해서 도움을 받지 않았습니다.

세상에 휴먼에러는 없다. 있는것은 시스템에러 뿐

사람을 실패하게 만드는 시스템에 문제가 있다.
따라서 개인을 단두대에 올린다해도 사고의 원인을 없앨수 없다.
사고의 원인을 없애지 않으면 똑같은 일이 발생한다 .

돈은 돈을 잘 써주는 사람에게 모인다.

고가의 상품을 없애버리면
돈이 넉넉하지 않은 사람에게
돈을 받아야하는 세계가 기다려.

프리미엄은 경합이 있는것중에 최상위 체험이고
럭셔리는 경합이 없는 체험이다.
bmw는 도움이 되고 의미가 있지만, 람보르기니는 의미가없다.

고객이 가격을 결정하는 상품은 가격을 올리는 이유가 필요해
하지만 럭셔리 상품의 가격을 결정하는 건 럭셔리 상품을 취급하는 사람이야.
즉, 가격 인상의 이유나 명분은 필요없어.

의미를 판매할 기회를 놓치고, 기능을 판매하면 고객이 계산을 하게된다.
기능은 돈이 되지 않아.

오버스펙이 장인의 긍지이자 자기만족이며, 사회적으로 헛수고가 될 가능성이 있다.
돈이 되지 않는다.

팬은 싸게사고 싶은 사람이 아니야
팬은 응원하고 싶은 사람이야.

우리가 손님이라고 부르는 사람들중에는 ‘고객’ 과 ‘팬’이 있다.
고객은 상품을 사는 사람, 팬은 상품제공자를 응원하는 사람 ‘

꿈의 대금 = 목적지(꿈) - 현재위치

꿈이 없으면 팬은 생기지 않아.
사람들은 네가 꾸고 있는 그 꿈에 자신의 돈을 투자한다는 것을 잊지마
따라서 지금부커 우리가 할 일은 현재 서있는 위치와 당도할 목적지(꿈)의 위치를 계속 주위에 알리는 거야

함부로 불편을 없애지마, 기능만 팔게 될테니까

필요한 불편은 2가지로 나눌수 있다.
혼자서 즐기는 불편을 통해서 얻을수 있는 기쁨 : 성취감과 성취감 확인
여럿이서 즐기는 불편을 통해서 얻을수 있는 기쁨 : 성취감 공유와 소통

모르는 것에 스스로 접근해서
가설과 검증과 실험을 반복해
너만의 꿈과 소중한 사람들을 위해 필요한 돈을 모을 수단을 찾아

돈이 필요해. 돈을 만드는 수간이 필요해

runner's high?

사내에 런닝을 많이 하시는 분이 있었고, 체력이 떨어지는것을 많이 느끼고 있었다. 어떻게 하면 체력을 기를수 있을까를 생각하다가 런닝을 하는것을 4월즘 시작했고, 대체적으로 새벽에 6-8시 사이에 성북천을 따라서 1시간정도 뛰었던것 같다. 헬스장의 런닝머신에서는 느낄 수 없는 알수 없는 더 빡셈 그리고 뛰는 사람들을 보면서 좋았다. 좋았다라는 표현이 너무 제너럴한데, 일단 스스로 자주 숨이차게 만들었던것 같고, 그러면서 여러가지 잡생각, 부정적인 생각들이 그 순간에는 없어지는것 같아서 좋았다. 그리고 운동을 한 후, 출근을 하는데 알 수 없는 자신감과 상쾌함이 생겼다. 물론 부작용도 있었다. 오후 4시만 되면 진짜 책상에서 앉아서 졸았다. 너무 졸렸다. 그리고 1달 정도 런닝을 한 주 3-4회정도 하니까 몸이 좋아지는데 종아리가 너무 아팠다. 병원에가서 엑스레이를 찍으니 종아리에 염증이 한 가득했다. 마라톤 하냐고 의사가 물었는데 창피해서 대답을 할 수 없었다. 종아리에 주사 7방을 맞고 나았다. 요즘은 주 2-3회로 줄이긴 했지만 좋은 습관이라는 생각이 든다.

블로그 갈이

블로그를 한번 개편했다. 뭔가 좀더 내가 쓴 내용이 잘 보였으면 하는 바램이었고, 사실 나는 라이프로그적 관점이 큰데, 요즘 드는 생각은 예전에 어린 내가 했던 약간 중2병 같은 생각들을 왜 다른 사람들이 봐야하지? 하는 생각이 들어서 최근글만 보여주도록 수정을 했다. 완전 맘에 드는건 아니지만 그래도 어느정도는 나쁘지 않은것 같다. 회사 블로그를 astro를 이용해서 개편을 했는데, astro로 바꿀까도 생각했지만 결국 astro도 유지보수 안되는 시점이 온다는 생각을 하면 내가 직접 만든게 더 장기적인 방향성에서 낫지 않나 싶다. 몇가지 개편 생각들은 아래와 같다.

• admin페이지를 vue.js 기반에서 react 기반으로 변경
• db를 쓰지 않는 static page 형태로 변경?
  • 이 부분이 저렴한것 같은데 고민중

AWS Summit

AWS Summit을 되게 오랜만에 갔었고, 몇가지 세션을 많이 듣지는 못했지만 느꼈던 점들은 아래와 같다.
- 생각보다 큰 행사, 세션 뿐만 아니라 전시관들도 보니 AWS라는 생태계가 얼마나 큰지를 실감할 수 있었다.
- 언젠가는 re:invent 행사를 가봐야 겠다는 생각이 들었다.
- 결국 앞으로의 미래는 AI/로봇, 우아한 형제들에서의 키노트도 그렇고 현재의 투자 시장도 그것들을 반증하는것 같다.
- 옛 직장분들, 옛 상사를 만나서 이런저런 애기를 나누면서 클라우드를 쓰지 않는 회사도 이젠 다 넘어오는구나 하는 생각이 듦
- 회사분들에게 좀 더 이런 해앗에 대한 참여를 독려해야겠다는 생각이 들었다.
- 물론 동영상으로 보는게 당연히 더 편하지만 현장 분위기 등을 보면 올만한 것 같다. 더군다나 AWS Summit이니

최근 고민/생각하고 있는 것들

몇가지 고민들이 있어서 두서없이 적어보자면,
- 기술부채를 어떻게 잘 청산해야할까?
- 누가 이것을 할것인가? 누가 이것을 할 수 있나?
- 지속가능한 팀을 만들기 위해서는 무엇이 필요한가?
- 회사에 없어도 지속가능한 구조를 어떻게 만들것인가?
- 사람에 의존하지 않는 구조를 만들어야 한다.
- 현재 빅쿼리를 사용하고 있는데, 빅쿼리를 사용하지 않고 데이터 관련 아키텍처를 정비를 어떻게 할까?
- 많이 들어오는 기술적 이슈들에 대해서 어떻게 줄일수 있을까? 그것에 대한 인지부하를 조직적으로 어떻게 감쇄할 수 있을까?
- 사람들을 늘리지 않는 선에서 서비스의 고도화, 기술부채, 그리고 신규기능을 어떻게 만들어나갈수 있을까?
- 더 나아지려면 어떻게 해야할까?
- 왜 나는 성장해야 하는가? 회사? 동료?
- 철저히 개인적인 입장에서 굳이 성장이 필요한가?
- 더 성장하려면 성장해있는 사람들을 만나야한다. 기존에 만나왔던 사람들로는 현재 상태에서 머무를뿐
- 질문을 가져야한다. 본질적인 질문들
- 아이들에게 어떤 기억들을 남겨줘야 할까?
- 남은 인생을 기존 체제에 순응하면서 살 것인가?
- 90%가 사는 틀에 박히 인생을 살것인가, 10%의 틀에 박히지 않은 인생을 살 것인가?

최근 칸예웨스트의 노래들을 많이 듣고있는데 그의 기행들보다도 가졌던 생각들이 마음에 든다.

코드를 정리하는 일이 반드시 보고해야 하고 추적하고 계획, 일정을 잡아야하는 일이 되어서는 안 됩니다. 특정 코드를 변경해야하는데 코드가 지저분해서 변경하기 어려울 때, 먼저 코드를 정리하는 것입니다. 일상적인 업무이자, 생각하면서 개선하는 절차입니다.

동료가 했던 말이 생각났다. "리팩토링은 항시 해야 한다." 리소스를 들여서, 받아야만 하는게 아니라. 그러나 리팩토링에 대한 부정적인 인식, 매우 큰 구조를 변경하는 일이고, 문제가 생길 수 있고, 임팩트가 제로다라는 인식은 여전히 존재한다. 대부분 개발자가 리팩토링을 해야한다고 소리칠 때는 들어주지 않다가 제품에 문제가 생기면 그때서야 하자고 한다. 그 사이에 고객은 떠나가기도하고. 물론 조금만 어려우면 리팩토링 카드처럼 꺼내는 개발자도 있긴하다.(어딜 어떻게 할지는 애기하지 않는다.) 그래서 그런지 그 동료가 애기했던 리팩토링를 항시 해야한다는 의견에 나 자신도 많이 동의하고 있었다.

그렇지만 그 역시 회사일이라서, 누군가에게 의무처럼 지우긴 어렵웠다. 그래서 오히려 책에 있는 코드정리라는 단어가 덜 부담스럽게 다가왔다.

코드 정리는 작은 리팩터링으로 누구도 싫어할 수 없을 정도로 사랑스럽고 포근합니다.

느끼는 감정이 달랐다. 거대한 산을 움직이는게 아닌 놀이터에서 작은 모래성을 뿌수고 다시 만드는 느낌. 매일 자주 할 수 있을것 같은 느낌이 이 문장을 보고 들었다. 코드 정리를 한게 언제였나 싶었다. 구현을 하기에, 밀려드는 버그와 일을 쳐내기에 급급하진 않았나. 스스로 스스로에게 미안해졌다. 나라는 프로그래머를 사랑하지 않고 있었다는 생각이 들었다.

코드를 정리할 때 한번에 처리하는 규모를 작게 할 것을 권했습니다.
...
한 번의 코드 정리에 한 시간 이상이 걸린다면, 이는 원하는 동작변경을 위해 필요한 최소한의 구조변경 시기를 놓쳤다는 의미일 수 있습니다.

코드 정리를 하다보면 책에서도 나와 있듯이 연쇄적으로 하게된다. 약간 빠져든다는 표현이 좀 더 맞는것 같다. 마치 todo 리스트에 1번을 하고 2번을 해야하는데 1-1, 1-2, 1-3을 계속 해나가는 느낌들을 받았다. 책에서는 그 기준을 한시간 이내정도로 가이드 해주고 있다. 물론 상황에 따라서 다르겠지만 시간을 체크해보는 것도 좋을것 같다.

동작변경과 구조변경을 분리하라는 이야기도 나온다. 코드정리가 결국 내부 구조를 변경하거나 하면서 동작을 변경하게 되고 또 구조를 변경하게 되는것 같은데 그리고 그것들이 현실세계에서 하나의 PR로 다른 개발자들에게 강요하는게 아닌가하는 과거의 나의 모습이 생각이 났다. 내가 이만큼 수고 했으니 어서 approve를 해달라. 이런식

그리고 코드 정리가 좋지만, 코드를 정리해야할 시점, 정리하지 미루어야할 시점에 대해서도 언급을 하고 있다. 코드 정리를 하는게 좋지만 미루어야 할 시점들이 있는데 그런 부분이 이제까지는 조금 경험적으로 알고 있었고, 사내에 다른 개발자들에게 가이드 하기 어려운 부분이었는데 책으로써 잘 정리해준것 같다.

오늘 우리가 하는 설계는 내일의 동작변경을 구매하는 옵션에 대해 지불하는 프리미엄입니다.

설계를 왜 해야하는가? 에 대한 좋은 답변이라는 생각이 들었다. 특히 스타트업에서 설계라는 단계에 대해서 투입되는 시간의 양에 대해서만 기회비용으로 측정을 한다. 예를 들어, 설계할 시간에 개발을 더 빨리해서 출시를 더 빨리 하는게 좋다는 식, 물론 비지니스라는 단어 앞에 장사가 없지만 설계라는 것을 비지니스적으로 해석해 준 부분에서 매우 인상적이었다.

코드 정리의 차원에서 코드와 자신과의 관계에 대해 이야기하고 있기 때문에 코드 정리를 먼저하면 이후의 행동변화가 더 즐거워 진다는 이유로 코드 정리를 먼저할 수 있습니다. 이런한 자기관리로서의 코드 정리는 어느정도 정당화 될 수 있습니다. 다만, 경제적인 인센티브에 반하는 행동을 하고 있을수도 있다는 사실을 항상 인식하세요.

코드정리를 하기 위해서, 혹은 리팩토링을 하기 위해서 일정 미뤄달라 혹은 리소스를 달라는 개발자도 있었다. 설계와 구조가 중요하지만 때로 아직 사용자가 없고 출시도 안한 상태에서 코드정리, 리팩토링만 하려고 하는 개발자를 보면 조금 답답하긴 하다.

비싼 프로그램에는 모두 한가지 공통점이 있다는 것을 발견했습니다. 한 요소를 변경하려면 다른 요소도 변경해야한다는 것이죠. 반면 저렴한 프로그램은 좁은 범위의 코드변경만 필요한 경향이 있었습니다. 그들은 이 변경감염 특성을 결합도라고 불렀습니다.

결합도는 소프트웨어 비용을 결정합니다.

비싼 프로그램을 언젠가 적정가격으로 내려앉히는 작업(리팩토링)을 해야하는데 그건 언제 해야하는 걸까? 아니면 지속적인 코드정리를 통해서 가능한걸까?

제 믿음 중에서, 증명하거나 적절하게 설명할 수 없는 것이 하나 있습니다. 한 종류의 코드 변경에 대한 결합돌를 줄일수록 다른 종류의 코드 변경에 대한 결합도가 커진다는 것입니다. . 이것이 의미하는 실질적인 의미는 모든 결합을 다 색출하듯 없애려고 애쓰지 말아야 한다는 것입니다. 그렇게 해서 만들어진 결합도는 그만한 가치가 없습니다.

하지만 가장 중요한 것은 바로 여러분입니다. 코드를 정리하면 평화, 만족, 기쁨을 느끼면서 프로그래밍을 할 수 있을까요? 그럴수도 있습니다. 이것이 중요한 이유는 여러분이 최상의 상태에서 주체적으로 일할 때, 더 나은 프로그래머가 될 수 있기 때문입니다. 항상 시간에 쫓기며 고치기 힘든 코드를 변경하느라 고통속에 있다면 최상의 상태가 될 수 없습니다.

코드 정리에 너무 집착하지 마세요. 코드 정리를 하면서 자신의 삶과 업무가 더 나아질 수 있다는 사실을 깨닫고 나면, 때때로 들뜬 기분에 휩싸여 코드 정리가 제일 우선이라고 생각할 수 있습니다. 일반적으로 코드를 다룰 때 기능 변경에 대해서라면 자신이 옳다고 생각하는 일을 해도 사람들이 불만을 가질 수 있는 위험과 불확실성을 지닙니다. 반면에 코드 정리에 영향을 받을 사람은 바로 나 자신이기 때문에 만족할 가능성이 매우 높습니다.

코드 정리라는 주제로 tidy first를 일주일만에 읽었다. 사실 작은 책이라 쉽게 읽히긴 했지만 리팩토링이 아닌 코드정리라는 작고 소중한 무엇인가를 선물받은 느낌이다.
켄트 백의 다음 책들이 기대된다.

이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.

팀원이 퇴사하는 과정에서 잡지 못했다. 아니 잡지 않았다는 말이 좀 더 솔직할것 같다. 회식에서 오고간 이야기들 속에서 여러가지 생각들이 들었다. 나의 역할 회사의 임원으로써 좋은 사람이 되기 위했던 것일까, 아니 잡는다고 좋은 사람일까. 난 여전히 엔지니어로써 아니 좀 더 정확히는 한명의 동시대를 조금 먼저 살아가는 엔지니어로써 그런 선택을 공감을 했던것 같다.

집에오는 택시 안에서 이제까지의 대여섯번의 퇴사의 경험들을 곱씹었봤다. 어떻게 너가 이럴수 있냐는 분들, 다른 곳이 가면 다를것 같냐는 분, 어이없는 레퍼첵을 통해서 합격을 하지 않았는데도 업무 배제를 했던 경험, 정말 사랑했던 회사에서 나왔던 경험들. 그런 여러가지 경험들이 영화 필름처럼 스쳐 지나갔다. 지금 생각해보면 원하는 액수를 적으라는 분도 계셨지만 코파운더의 역할을 선택했고 아이러니하게 개인적으로 별로인 감정을 가지고 있는 분이 나의 선택을 존중해주었다. 지금와서는 한편으로 감사하다. 그 분도 지금의 나의 심정과 같은 느낌이었을까

택시에서 내려서, 예전 회사에서 퇴사했을 때 슬랙에 올렸던 퇴사표(退社表) 글을 예전 개인 노션에서 찾아서 다시 읽어봤다. 나는 왜 그 시점에 그런결심을 했을까. 왜 그렇게 사랑했으면 그만 둘 생각을 했던걸까. 다시 읽으면서 그때의 감정과 상황들이 머릿속에 떠올랐다.

그냥 그런때가 사람들에게 오는것 같다. 그만두어야 할때. 그만둘 수 밖에 없을때. 그게 역량일수도 있고, 의지일수도 있고, 동기부여일수도있고. 근데 그런걸 다 따져서 무엇할까. 개인의 선택이고 시간의 흐름속에 낡기도 하고 새로워지기도하고, 자연의 법칙이기도 한 것 같다.

동료의 퇴사를 맞이하면서 진짜 힘든건
누군가의 퇴사가 감정적으로, 같이 일을 했던 동료로 아쉬운것들을 넘어서
이것 또한 지나가고, 대비해야하는 것을 내가 인식해야한다는 사실이다.

오늘은 쉽사리 잠을 잘 수 없을것 같다.