← 목록으로

틀에 갇히지 않는 IT 실무자의 기록: 진짜 문제 해결을 위한 증거들

2026. 7. 10.

틀에 갇히지 않는 IT 실무자의 기록: 진짜 문제 해결을 위한 증거들

지난번에 11가지의 증거물을 꺼내 보였습니다. 강사, 레스토랑 주인, 우체국 직원, 개발자, 학교 보조원, 다시 개발자로 이어지는, 도무지 한 가지 틀에 맞춰지지 않던 커리어였죠. 그리고 마지막에는 "이게 내 문제일까, 아니면 그 틀의 문제일까" 하는 답 없는 질문을 남겼습니다.

여전히 명확한 답은 없습니다. 하지만 답을 기다리며 멈춰 있지도 않았습니다. 이 카테고리에 맞추려 하지 않는 저의 성향은 이력서가 아닌 코드에도 똑같이 적용되었고, 그 결과 8가지 증거물이 더 쌓였습니다. 자, 이제 그 결과물을 공개합니다.

증거물 12 — 관계형 그래프 이력서

11번째 증거물은 제가 일주일에 나흘은 교실에 서서, 제 아이도 아닌 아이가 제 일도 아닌 공부에 집중하도록 돕는 모습으로 끝납니다. 은유가 아닙니다. 그게 제 실제 스케줄이었죠.

나머지 사흘 동안, 저는 무언가를 만듭니다.

어느 순간, 저는 이 상황을 일반적인 이력서 — 즉, 직무별 한 줄, 연대순, 깔끔한 형태로 정리된 — 로 채용 담당자에게 설명하려 했습니다. 결과는 마치 한 직장에 오래 머물지 못하는 사람처럼 보였죠. 강사, 레스토랑 주인, 우체국 직원, 학교 보조원, 개발자, 다시 개발자… 밑바탕에는 항상 개발자라는 본질이 깔려 있었지만, 연대기식 타임라인은 그 "밑바탕"을 보여주지 않습니다. 그저 순서만을 늘어놓을 뿐이죠.

그래서 저는 타임라인 대신 그래프를 그렸습니다. 스킬은 노드로, 역할은 노드로, 그리고 이들을 실제로 연결하는 요소들은 엣지로 표현했죠. CMS나 ORM의 한계에 의문을 품었던 바로 그 직관이 제 커리어에도 적용된 겁니다. 결국, 일관성 없어 보이던 이력서는 내용의 문제가 아니라 렌더링 방식의 문제였습니다. 데이터 자체는 괜찮았는데, 시각화가 거짓말을 하고 있었던 거죠.

이 그래프가 열한 개의 글머리 기호보다 채용 담당자에게 더 설득력 있게 읽힐지는 아직 모르겠습니다. 하지만 저 자신에게는 훨씬 진실하게 느껴집니다.

교실 보조원 일은 한 달 중 일부를 채워줍니다. 하지만 이 그래프가 바로 '진짜 나'입니다. 이 두 가지 사실이 서로 모순되지 않도록 만드는 방법을 아직도 고민 중입니다.

(노드, 엣지, 그리고 그래프가 타임라인보다 나은 이유에 대한 자세한 내용은 선형 이력서를 넘어서에서 확인할 수 있습니다.)

이제 같은 직관이 커리어가 아닌 코드에 적용된 사례를 살펴보시죠.

증거물 13 — AJC 브릿지

저는 계속해서 워드프레스로 글을 쓰고 싶었습니다. 좋아서라기보다는, 이미 익숙한 인터페이스이고 마찰이 전혀 없는 도구였기 때문이죠. 하지만 그 결과물이 워드프레스 호스팅에만 묶여 있거나, 워드프레스의 무거움에 시달리는 것을 원치 않았습니다. 페이지를 어떤 CMS가 만들었는지 신경 쓰지 않는 독자들에게는 더더욱요.

단순한 마이그레이션이 아니었습니다. 다리(Bridge)를 만들고 싶었죠.

그래서 하나를 만들었습니다. 워드프레스의 발행 액션에 연결되어 콘텐츠를 Hugo, Astro, 또는 Jekyll — 대상 사이트가 어떤 정적 사이트 생성기를 사용하든 — 로 푸시하는 플러그인이죠. 제가 이미 아는 도구에서 한 번 쓰고, 독자들이 실제로 읽는 곳이라면 어디든 배포하는 방식입니다.

흥미로웠던 건 코드가 아니었습니다. 워드프레스에서 정적 사이트 생성기로 발행하는 문제는 이미 수십 가지의 반쪽짜리 방법으로 해결되어 있었으니까요. 진짜 흥미로웠던 건, '워드프레스를 완전히 버리는 것이 진보'라는 식의 뻔한 움직임에 저항했던 점입니다.

워드프레스 자체가 문제는 아니었습니다. 제가 능숙하게 다루는 인프라였고, 제가 중요하게 생각하는 콘텐츠를 담고 있었지만, 제 실제 필요와 맞지 않는 호스팅 모델 때문에 속도가 느려지고 있었을 뿐이죠. 사람들이 흔히 "워드프레스는 무겁다", "그냥 정적 사이트를 써라"며 지목하는 '적'은 결코 진정한 제약이 아니었습니다. 제약은 '능숙함은 중요하지 않고, "현대적인" 도구가 항상 기본적으로 승리한다'는 생각 자체였습니다.

저는 이 프로젝트를 GitHub Copilot CLI 챌린지에 출품했고, 상위 7%에 들며 400여 참가자 중 25위 안에 랭크되었습니다. 아이디어가 독창적이어서가 아닙니다. 대부분의 참가작이 기술적인 문제 해결에 집중했지만, 제 것은 개인적인 워크플로우를 버리지 않고 오히려 유지했기 때문이죠.

제가 실무에서 레거시 시스템을 다룰 때 항상 느끼는 점은 무조건적인 교체만이 답은 아니라는 겁니다. 익숙함이 주는 생산성은 생각보다 강력하죠. 내 커리어가 아닌 제 개인적인 발행 습관에 적용된 그래프와 같은 직관입니다. 무엇이 유행해서 바꿔야 하는지를 묻기보다, 무엇이 '진짜로' 고장 났는지 물어야 합니다.

(전체 글: 진짜 정적 사이트: 워드프레스가 더 이상 적이 아닐 때.)

증거물 14 — dev.to가 주지 않는 기억

dev.to의 내장 통계는 각 포스트의 조회수, 반응, 댓글을 실시간으로 보여줍니다. 하지만 3개월 전에는 무슨 일이 있었는지 직접 스크린샷을 찍어두지 않으면 알 수 없습니다. 1년이 지난 후에도 어떤 글이 꾸준히 독자를 얻고 있는지, 어떤 댓글 스레드가 후속 조치할 가치가 있는지 알려주지 않죠. 이 플랫폼에는 '기억'이 없습니다. 오직 '현재'만 있을 뿐입니다.

저는 저 자신의 역사를 알고 싶었습니다. 그래서 작은 것부터 시작했습니다. 로컬 스크립트를 만들고, SQLite를 사용해 정해진 스케줄에 맞춰 제 통계를 가져와서… 그냥 보관하는 것이었죠. '이 데이터를 잃지 않겠다'는 것 외에는 어떤 계획도 없었습니다.

작은 규모로도 잘 작동했지만, 어느 순간 한계를 맞았습니다. 추세, 비교, 어떤 게시물이 시간이 지나도 가치를 유지하는지 등 실제 기록을 쿼리하고 싶어지자, 노트북의 SQLite로는 더 이상 충분치 않았습니다. 그래서 FastAPI, pgvector가 포함된 PostgreSQL을 사용해 전체를 컨테이너화하고 제 VPS에서 실행되는 실제 스택으로 재구축했습니다. 처음에는 대시보드를 위해 Superset을 시도했습니다. 하지만 학습 곡선이 실제 필요한 출력물보다 더 많은 비용을 초래해서 포기했죠. Streamlit은 같은 작업을 더 빠르고 적은 비용으로 해냈습니다. GitHub Copilot CLI와 함께 작업하면서 대부분을 구축했는데, Copilot을 자동 완성 도구라기보다는, 제가 이미 스펙을 알지만 두 번 입력하고 싶지 않은 부분에서 '두 번째 손'처럼 활용했습니다.

이 모든 작업은 누가 시켜서 한 것이 아닙니다. 아무도 dev.to 분석 플랫폼을 요청하지 않았죠. 저는 이 플랫폼이 고의적으로 자신의 역사를 잊어버리는 곳이기 때문에, 스스로 기억해야만 하는 플랫폼을 만든 것입니다.

제가 개인적으로 운영하는 블로그나 작은 프로젝트에서도 이런 데이터를 쌓는 것의 중요성을 느끼고 있습니다. 단기적인 지표도 중요하지만, 장기적인 추이를 파악해야 진짜 인사이트를 얻을 수 있거든요. 다시 같은 직관입니다. 도구의 건망증을 삶의 사실로 받아들이지 마세요. 그 밑에 레이어를 구축하세요. 그리고 이미 투자했다는 이유만으로 도구를 계속 사용하지 마세요. Superset이 제게 가르쳐준 교훈이기도 합니다.

(시작부터 끝까지의 구축 과정: 로컬 SQLite 스크립트에서 GitHub Copilot CLI를 사용한 클라우드 플랫폼으로.)

증거물 15 — 폴란드 봇넷

dev.to 분석 플랫폼은 Cloud Run에서 실행됩니다. 어느 달, 요금이 갑자기 급증했습니다. 조금이 아니라 즉시 알아챌 정도로, 제가 행복해할 만한 트래픽 증가라고 가정하기 전에 로그를 실제로 읽어보게 만들 정도로 말이죠.

트래픽이 아니었습니다. 봇넷이었습니다. 대부분 폴란드에서 추적되었고, 그렇게 자주 호출될 이유가 없는 엔드포인트를 마구 두드리고 있었죠. 특별한 일은 없었습니다. 침해나 데이터 손실도 없었죠. 그저 로드처럼 위장한 노이즈가 조용히 저에게 스캔 비용을 청구하고 있었을 뿐입니다.

해결책은 더 큰 인스턴스를 사용하거나, 그 위에 속도 제한기를 덧붙이는 것이 아니었습니다. 실제로 노출되고 있는 것이 무엇인지 돌아보고, 공개될 필요 없는 것을 닫고, 나머지는 공격자에게 더 많은 비용을 들게 만들면서 제가 무시해도 될 정도로 만드는 것이었습니다. 요금은 96% 줄었습니다.

재미없는 교훈: 사람들이 스케일업으로 해결하려는 대부분의 비용 문제는 사실 아직 들여다보지 않은 보안 문제입니다. 사람들이 재작성으로 해결하려는 대부분의 "구식" 시스템도 마찬가지입니다. 절반은 모두가 먼저 생각하는 재작성보다 더 작고 가까운 곳에 해결책이 있습니다.

이제 이 패턴은 자동적으로 나타납니다. 당신이 예상했던 것과 실제로 일어나는 일 사이의 간극을 인지하고, 다른 어떤 것에도 손대기 전에 그 간극을 먼저 메우는 것이죠. 클라우드 비용 최적화 프로젝트에서 자주 마주하는 상황인데, 단순히 인스턴스 스펙을 올리기 전에 트래픽의 본질을 파악하는 게 핵심이죠. 저도 이런 식으로 숨겨진 비용을 찾아내어 꽤 큰 폭의 절감을 이룬 경험이 여러 번 있습니다.

(전체 로그 및 수치: 폴란드 봇넷을 막아 Cloud Run 요금을 96% 절감한 방법.)

증거물 16 — 워드프레스에서 Hugo로, 그리고 그 너머로

저는 워드프레스에서 Hugo로의 마이그레이션을 번개처럼 빠른 재구축으로 기록했습니다. CMS를 벗겨내고, 콘텐츠는 유지하며, 몇 초가 아닌 몇 밀리초 만에 로드되는 것을 배포하는 내용이었죠. 그 글은 괜찮은 반응을 얻었습니다. 하지만 그 글에 담지 못한 것은, 제가 발행 후에도 작업을 계속했다는 점입니다.

일회성 마이그레이션 스크립트는 한 사이트에는 괜찮습니다. 두 번째 블로그에 적용하기 전까지는 그것이 스크립트가 아니라 파이프라인의 시작이라는 것을 이해하지 못했습니다. 세 번째 블로그에 이르자, 그 패턴은 부정할 수 없게 되었습니다. 다른 콘텐츠 구조, 다른 플러그인 특성, 단순히 복사하는 것이 아니라 매핑해야 할 다른 요소들이 있었죠. 그래서 스크립트는 실제 파이프라인이 되었습니다. 콘텐츠 추출, 이미지 처리, 리다이렉션 매핑 등 "이제 얼마나 빨리 로드되는지 보세요" 스크린샷에는 나타나지 않지만, 실제 작업의 핵심인 부분들입니다.

프로젝트의 진정한 흥미로운 버전은 결코 당신이 공개하는 버전이 아닙니다. 박수갈채가 멈춘 후에도 계속 사용되면서, 누군가가 요청할 때마다 같은 문제를 처음부터 해결하는 대신 조용히 인프라로 변모해가는 버전이죠. 첫 번째 해결책은 데모일 뿐입니다. 진짜 해결책은 6개월 후에도 여전히 작동하는 것입니다.

(두 가지 마이그레이션은 각각 워드프레스에서 Hugo로와, 파이프라인이 성장한 후의 워드프레스에서 Astro로: 통제권을 되찾는 데 3일이라는 글에 있습니다. 이 글들은 두 번째와 세 번째 클라이언트 이후의 일은 다루지 않았는데, 지금 이 부분이 바로 그 내용입니다.)

증거물 17 — GCF Pro

프랑스의 교육 기관들은 Qualiopi 인증을 받아야 합니다. 이는 자금 관리, 행정 기록, 감사 추적 방식 등을 규정하는 준수 프레임워크입니다. 대부분은 이를 전혀 다른 목적으로 만들어진 도구들로 운영합니다. 예를 들어, 옆으로 엉망진창 구부려진 일반 CRM, 습관에 의해 유지되는 스프레드시트, 또는 실제 규정 준수 로직은 전혀 내장되지 않은 채 대기업용으로 가격이 책정된 소프트웨어 같은 것들이죠.

저는 GCF Pro를 교육 기관들이 늘 바라던 도구로 만들었습니다. 자체 호스팅 방식에 PHP 기반이며, ORM도 없고, 문제보다 무거운 프레임워크도 사용하지 않았습니다. 구독 방식이 아닌 라이선스 방식으로 판매했죠. 왜냐하면 이 기관들은 자신들의 준수 데이터를 다른 SaaS 업체의 가격 결정에 맡기고 싶어 하지 않기 때문입니다. 온프레미스는 제가 받아들인 제약이 아니었습니다. "감사 추적"이 인증에 따라 달라지는 누군가에게 어떤 의미인지 이해한 후에는, 그것이 실제 요구 사항이었습니다.

프랑스에는 약 28,000개의 Qualiopi 인증 기관이 있습니다. 이건 가설이 아니라 필터링된 목록입니다. 아직 제가 가지고 있지 않은 것은 '목록이 곧 시장'이라는 증거입니다. 이런 도메인 특화 솔루션은 일반적인 SaaS형 서비스가 놓치기 쉬운 '진짜 필요'를 충족시킨다는 점에서 의미가 크다고 봅니다.

(제품은 gcfpro.fr에서 확인할 수 있으며, 문서는 doc.gcfpro.fr에 있습니다.)

증거물 18 — Prospection CRM, 그리고 함께 지켜보는 확장 프로그램

대규모 콜드 아웃리치에는 데이터베이스가 필요합니다. 제 데이터베이스도 그렇게 시작되었습니다. 공개된 Qualiopi 기록에서 스크랩하고, 정보를 보강하고, 캠페인을 추적하며, CNIL 규정을 준수하도록 처음부터 설계했습니다. 나중에 덧붙이는 것보다 처음부터 제약을 내장하는 것이 낫기 때문이죠.

데이터베이스 자체는 흥미로운 부분이 아니었습니다. 흥미로운 부분은 제가 의도적으로 잠재 고객을 찾지 않고 그냥 웹 서핑을 할 때 일어나는 일입니다. 저는 크롬 확장 프로그램을 만들었습니다. 잠재 고객으로 보이는 사이트에 방문하면, 한 번의 클릭으로 현재 페이지와 법적 고지사항(회사 이름, SIRET, 전화번호, 담당자 이름 등)을 읽어와 필수 정보, 보안 헤더, PHP 버전, 성능 등 제가 대규모로 실행하는 것과 동일한 진단 스캔을 대기열에 추가합니다. 그저 제가 페이지를 보고 있는 것만으로 트리거되는 것이죠.

이것은 무언가를 발견하고 행동에 옮기는 사이의 간극을 줄여줍니다. 복사-붙여넣기도, 폼으로 탭을 전환할 필요도, "나중에 추가해야지" 하며 결국 하지 않게 되는 일도 없습니다. 이 도구는 제가 "지금 일해야겠다"고 결정할 때까지 기다리지 않습니다. 제가 언제나 조금씩이라도 일하고 있다고 가정하고, 제 길을 막지 않는 것이죠. 저도 평소에 업무 효율을 위해 작은 확장 프로그램을 만들거나 기존 툴을 연동하는 시도를 자주 하는데, 이런 '틈새 자동화'가 쌓이면 엄청난 생산성 향상으로 이어지더라고요.

증거물 19 — S&R CRM

한 고객은 난방 및 배관 기술자를 위한 유지보수 계약 추적 시스템이 필요했습니다. 어떤 건물에 어떤 장비가 있고, 어떤 계약이 적용되며, 다음 서비스는 언제인지 파악하는 것이었죠. 대부분의 도구가 가진 직관은 '계약을 고객에게 연결하는 것'입니다. 하지만 이 업계에서는 그게 틀렸습니다. 고객은 이사하지만, 건물은 그렇지 않죠. 보일러는 올해 누가 그 집을 소유했는지 신경 쓰지 않습니다.

그래서 계약은 거주자가 아닌 건물에 따릅니다. 작아 보이는 모델링 결정이지만, 누군가 집을 팔 때마다 조용히 고장 나는 시스템과 그렇지 않은 시스템의 차이를 만듭니다.

한 고객을 위한 해결책으로 시작된 것이 독립적인 제품으로 변모하고 있습니다. 캘린더 측면은 ScheduleX, 인터페이스는 Mazer, 그리고 여기 있는 다른 모든 것과 동일한 PHP 네이티브 백엔드를 사용하고 있죠. 아직 변환 중입니다. 건물 중심 모델이 이 한 산업 외의 다른 누구에게도 명확할지, 아니면 그것 자체가 전체적인 판매 전략이 될지는 아직 모르겠습니다. 데이터 모델링에서 이런 작은 관점의 차이가 시스템의 견고성과 확장성을 완전히 뒤바꿀 수 있다는 걸 저도 여러 프로젝트에서 경험했습니다. 본질을 꿰뚫는 모델링은 정말 중요합니다.

최종 판결

여덟 가지 증거물 — 브릿지, 기억 레이어, 그래프, 절감된 요금, 마이그레이션 파이프라인, 준수 도구, 나와 함께 생각하는 브라우저 확장 프로그램, 그리고 편리함이 아닌 정확하게 세상을 모델링하는 CRM. 문제들은 다르지만, 매번 같은 반응을 보였습니다. '무엇이 그것을 대체해야 한다는 이야기'를 믿기 전에 '무엇이 진짜로 고장 났는지'를 살펴보는 것이죠.

이들을 처음 11가지와 나란히 놓고 보니, 제가 살아가는 동안에는 명확하지 않았던 무언가가 분명해집니다. 이력서에 흩어져 보이던 커리어 — 강사, 레스토랑, 우체국, 개발자, 학교 보조원 — 와 포트폴리오에 흩어져 보이는 프로젝트들 — ERP, 브라우저 확장 프로그램, 이력서 시각화, 클라우드 요금 관리 — 은 같은 형태를 띠고 있습니다. 둘 다 제가 우연히 한 무관한 일들의 목록이 아닙니다. 둘 다 어떤 사람이 '여기서 진짜로 고장 난 것은 무엇인가?'라는 질문을 '여기서 표준적인 답은 무엇인가?' 대신, 자신이 마주하는 모든 영역에서, 누구도 고용하지 않은 스케줄에 맞춰 계속 물었을 때 일어나는 일입니다.

저는 그렇게 하는 방법을 압니다. 하지만 '그것'이 무엇인지 세 단어로, 명함에, 30초 안에 설명하고, 더 듣기 전에 카테고리가 필요한 사람에게 말하는 방법은 아직 터득하지 못했습니다.

그래서 진짜 질문입니다. 비유적인 표현이 아닙니다. 이 목록을 읽으면서, 이 중에 당신이 실제로 비용을 지불할 만한 것이 있나요? 만약 그렇다면, 그것을 뭐라고 부르시겠어요? 저는 검증을 바라며 묻는 것이 아닙니다. 제 자신의 작업을 외부에서 보는 능력을 잃었기 때문이고, 처음 11가지 증거물도, 이 8가지도 그 방법을 가르쳐주지 못했습니다. 하지만 첫 번째 질문 밑에는 두 번째 질문이 있습니다. 그리고 그것이 제가 실제로 답을 필요로 하는 질문입니다. 단순히 '이 중에 가격이 있는 것은 무엇인가?'가 아니라, 이 모든 것을 하는 사람은 당신의 시선에서 어떻게 보이나요? 그런 사람에게 붙일 이름이 있을까요? 여기서 보면, 그저 눈앞의 문제를 해결하는 똑같은 사람처럼 보일 뿐인데, 그것이 포트폴리오인지, 아니면 그저 성격의 일부인지 더 이상 구별할 수 없습니다.

원문: https://dev.to/pascal_cescato_692b7a8a20/unboxable-in-tech-the-evidence-locker-20n4 수집일: 2026-07-10 01:27:17