틀을 깨는 개발자의 문제 해결 기록: 10년차 IT 실무자의 '언박싱' 프로젝트 일지
2026. 7. 11.
틀을 깨는 개발자의 문제 해결 기록: 10년차 IT 실무자의 '언박싱' 프로젝트 일지
지난번에 이야기했던 열한 가지 이야기를 기억하시나요? 강사, 식당 주인, 우체국 직원, 개발자, 학교 보조원, 그리고 다시 개발자로 돌아오기까지, 제 경력은 단 하나의 '박스' 안에 갇히기를 거부했습니다. 그때 마지막으로 던졌던 질문은 답을 찾지 못했었죠. "이게 내 문제인가, 아니면 박스의 문제인가?"
여전히 명확한 답은 없습니다. 하지만 답을 기다리며 멈춰 있지도 않았습니다. 이력서가 아닌 코드에 그 '범주를 거부하는' 태도를 적용해봤더니, 여덟 가지의 새로운 증거물들이 탄생했습니다. 그 결과물을 지금부터 공개합니다.
증거물 12 — 관계형 이력서, '더 그래프'
증거물 11의 마지막은 여전히 교실에서 한 주에 나흘씩, 내 아이도 아닌 아이가 집중하도록 돕는 일을 하는 제 모습이었습니다. 비유가 아닙니다. 그게 제 실제 스케줄이었죠. 나머지 사흘 동안은 코드를 만들었습니다.
어느 시점에 헤드헌터에게 제 경력을 설명하려니 막막했습니다. 흔히 쓰는 일반적인 이력서, 즉 직업당 한 줄씩 연대순으로 깔끔하게 정리된 선형 이력서는 제가 직장을 오래 다니지 못하는 사람처럼 보이게 만들었습니다. 강사, 식당 주인, 우체국 직원, 학교 보조원, 개발자, 다시 개발자로 돌아왔지만, 그 밑바탕에는 항상 개발자로서의 본질이 있었습니다. 하지만 연대순 타임라인은 그 '밑바탕'을 보여주지 않습니다. 그저 순서만을 나열할 뿐이죠.
그래서 저는 타임라인 작성을 멈추고 대신 '그래프'를 만들었습니다. 스킬 노드, 역할 노드, 그리고 이들을 실제로 연결하는 엣지들. CMS나 ORM에 의문을 가졌던 바로 그 본능을 제 커리어에 적용한 겁니다. 알고 보니, 난잡해 보이던 이력서는 콘텐츠 문제가 아니라 '렌더링' 문제였습니다. 데이터는 괜찮았어요. 시각화 방식이 진실을 왜곡하고 있었던 거죠.
제가 실무에서 이력서로 여러 시도를 해봤을 때, 단순히 시간순 나열로는 제 강점을 전혀 보여줄 수 없다는 걸 뼈저리게 느꼈죠. 관계형 그래프 형태의 이력서가 수십 개의 불릿 포인트보다 채용 담당자에게 더 잘 읽힐지는 아직 모르겠습니다. 하지만 저 자신에게는 훨씬 더 진실하게 다가옵니다. 교실 보조원 일은 한 달 중 일부를 차지합니다. 하지만 '더 그래프'는 제가 실제로 어떤 사람인지를 보여주죠. 이 두 가지 사실이 서로 모순되지 않도록 만드는 방법을 아직도 고민하고 있습니다.
(노드, 엣지, 그리고 왜 그래프가 타임라인보다 나은지에 대한 전체 분석은 선형 이력서를 넘어에서 확인할 수 있습니다.)
이제, 이 동일한 본능을 경력이 아닌 코드에 적용한 사례들을 살펴보겠습니다.
증거물 13 — AJC 브릿지
저는 여전히 워드프레스에서 글을 쓰고 싶었습니다. 워드프레스가 '좋아서'가 아니었습니다. 이미 제가 익숙한 인터페이스이고, 작업 흐름에 마찰이 전혀 없었기 때문입니다. 하지만 방문하는 독자층이 어떤 CMS로 페이지가 만들어졌는지 신경 쓰지 않는데, 굳이 워드프레스의 무거운 호스팅 환경에만 결과물이 묶여있고 싶지는 않았습니다.
단순한 마이그레이션이 아니었습니다. 이건 '다리(Bridge)'였습니다.
그래서 직접 만들었습니다. 워드프레스의 게시(publish) 액션에 연결되어 콘텐츠를 Hugo, Astro, Jekyll 등 목적지 사이트가 사용하는 정적 사이트 생성기로 푸시하는 플러그인입니다. 한 번 작성해서 제가 잘 아는 도구에서 작업하고, 독자가 실제로 글을 읽는 모든 곳에 배포하는 방식이죠.
흥미로운 부분은 코드가 아니었습니다. 워드프레스에서 정적 사이트 생성기로 게시하는 것은 이미 수십 가지의 반쯤 작동하는 방식으로 '해결된' 문제였습니다. 진짜 흥미로웠던 점은 명백해 보이는 움직임, 즉 워드프레스를 완전히 버리고 그것을 진보라고 부르는 것에 저항했다는 겁니다. 문제가 아니었습니다. 워드프레스는 제가 능숙하게 다루는 인프라였고, 제가 아끼는 콘텐츠를 담고 있었으며, 단지 제가 실제로 필요한 것과 맞지 않는 호스팅 모델 때문에 느려지고 있었을 뿐입니다. 사람들이 흔히 적이라고 부르는 것, 예를 들어 "워드프레스는 너무 무겁다", "그냥 정적 사이트를 써라" 같은 말들은 결코 진짜 제약이 아니었습니다. 진짜 제약은 '능숙함'은 중요하지 않고, '최신' 도구가 무조건 이긴다는 생각이었습니다.
제가 실무에서 레거시 시스템을 최신 기술로 바꾸는 작업을 여러 번 해봤지만, 무조건적인 재작성만이 능사는 아니라는 걸 몸소 체험했습니다. 기존 시스템의 강점을 유지하면서 필요한 부분만 개선하는 것이 훨씬 효율적일 때가 많죠.
저는 이 프로젝트를 GitHub Copilot CLI 챌린지에 제출했습니다. 400개 이상의 출품작 중 상위 7%, 러너업(Runner-up)을 차지하며 25위 안에 들었죠. 아이디어가 독창적이어서가 아니었습니다. 대부분의 출품작이 기술적인 문제를 해결하는 데 집중했지만, 이 프로젝트는 개인의 작업 흐름을 버리지 않고 오히려 유지했기 때문입니다.
이력서가 아닌 저의 글쓰기 습관에 초점을 맞춘, '더 그래프'와 동일한 본능이었습니다. 무엇이 유행이니 교체할지를 묻지 마세요. '실제로 무엇이 문제인가'를 물어야 합니다.
(전체 글: 진정한 정적 웹사이트: 워드프레스가 더 이상 적이 아닐 때.)
증거물 14 — dev.to가 주지 않는 기억력
dev.to의 기본 통계는 게시물별 조회수, 반응, 댓글을 '현재 시점'으로 보여줍니다. 하지만 3개월 전에는 무슨 일이 있었는지 직접 스크린샷을 찍어두지 않으면 알 수 없습니다. 1년이 지나도 조용히 독자를 계속 확보하는 글은 무엇인지, 어떤 댓글 스레드가 후속 조치할 가치가 있는 논의로 발전했는지 알려주지 않습니다. 이 플랫폼은 '기억력'이 없습니다. 오직 '현재'만 있을 뿐입니다.
저는 제 글의 역사를 알고 싶었습니다. 그래서 작은 것부터 시작했습니다. 로컬 스크립트, SQLite를 사용해서 정기적으로 통계를 가져와 그냥... 저장해두는 방식이었죠. "이 데이터를 잃지 말자" 외에는 별다른 계획이 없었습니다.
작은 규모는 작동했지만, 결국 한계에 부딪혔습니다. 추세, 비교, 어떤 게시물이 시간이 지나도 가치를 유지하는지 등 실제로 히스토리를 쿼리하고 싶어지자, 제 노트북의 SQLite만으로는 더 이상 충분하지 않았습니다. 그래서 FastAPI, pgvector가 포함된 PostgreSQL을 사용하고 전체를 컨테이너화하여 제 VPS에서 실행되는 제대로 된 스택으로 재구축했습니다.
대시보드를 위해 처음에는 Superset을 시도했습니다. 하지만 이내 포기했죠. 제가 실제로 보고 싶었던 결과물에 비해 학습 곡선 비용이 너무 컸습니다. Streamlit은 더 적은 노력으로 같은 작업을 더 빠르게 해냈습니다. 대부분의 개발은 GitHub Copilot CLI와 함께 진행했는데, Copilot을 자동 완성 도구라기보다는 제가 이미 사양을 알고 있지만 두 번 타이핑하기 싫은 부분에서 '두 번째 손'처럼 활용했습니다.
제가 실제로 대시보드를 구축하면서 Superset을 써봤을 때, 초기에 들인 학습 곡선 비용이 예상보다 훨씬 커서 결국 Streamlit으로 선회했던 경험이 있습니다. 도구의 선택은 단순히 기능 목록을 비교하는 것을 넘어, 실제 개발 과정에서의 효율성과 비용까지 고려해야 한다는 것을 다시금 깨달았죠.
이 모든 작업은 그 누구의 의뢰도 받지 않았습니다. 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 인증을 받아야 운영할 수 있습니다. 이는 자금 관리, 행정 기록, 감사 추적(audit trail) 방식을 규정하는 규제 프레임워크입니다. 대부분의 기관은 이 작업을 전혀 다른 목적으로 만들어진 도구들로 처리합니다. 옆으로 비틀어 사용되는 일반 CRM, 습관에 의해 유지되는 스프레드시트, 또는 실제 규제 논리가 전혀 내장되지 않은 채 기업용으로 비싸게 판매되는 소프트웨어 같은 것들이죠.
저는 교육 기관들이 늘 갈망하던 도구를 직접 만들어봤습니다. 바로 GCF Pro입니다. 자체 호스팅 방식, PHP 기반, ORM 없음, 문제보다 무거운 프레임워크는 사용하지 않았습니다. 구독 방식이 아닌 라이선스 방식으로 판매합니다. 이들 기관은 자신들의 규제 관련 데이터를 다른 SaaS 업체의 가격 결정에 따라 좌우되는 것을 원치 않기 때문이죠. 온프레미스(On-premise)는 제가 받아들인 제약이 아니었습니다. 인증이 달린 사람에게 '감사 추적'이 무엇을 의미하는지 이해했을 때, 그것은 곧 실제적인 '요구사항'이었습니다.
제가 실무에서 고객들의 '요구사항'을 수집하면서 깨달은 점은, 고객이 말하는 솔루션이 아니라 그들이 '진정으로 해결하고 싶은 문제'가 무엇인지 파악하는 것이 중요하다는 겁니다. 이 프로젝트 역시 그 본질을 꿰뚫어본 결과물이죠.
프랑스에는 약 28,000개의 Qualiopi 인증 기관이 존재합니다. 이건 가설이 아니라, 필터링된 실제 목록입니다. 아직 제가 증명하지 못한 것은, 이 목록이 곧 '시장'이라는 증거입니다.
(제품은 gcfpro.fr에 있습니다. 문서는 doc.gcfpro.fr에서 확인할 수 있습니다.)
증거물 18 — 잠재 고객 CRM, 그리고 나와 함께 지켜보는 확장 프로그램
대규모 콜드 아웃리치(Cold outreach)에는 데이터베이스가 필요합니다. 제 데이터베이스는 공공 Qualiopi 기록을 스크랩하고, 정보를 보강하며, 캠페인을 추적하고, 나중에 덧붙이기보다 처음부터 CNIL 규제를 준수하도록 설계된 방식으로 시작되었습니다. 이 데이터베이스 자체는 흥미로운 부분이 아니었습니다.
진정 흥미로운 부분은 제가 의도적으로 잠재 고객을 찾지 않고 그저 웹 서핑을 할 때 일어나는 일입니다. 저는 크롬 확장 프로그램을 만들었습니다. 잠재 고객으로 보이는 사이트에 방문하면, 단 한 번의 클릭으로 현재 페이지와 법적 고지사항(회사명, SIRET 번호, 전화번호, 담당자 이름 등)을 읽어옵니다. 그리고 핵심 정보(보안 헤더, PHP 버전, 성능 등)에 대한 스캔을 대기열에 추가합니다. 제가 대규모로 실행하는 것과 동일한 진단 과정이지만, 단지 제가 페이지를 보고 있다는 사실만으로 트리거되는 것이죠.
이것은 어떤 것을 '인지하는 순간'과 '행동으로 옮기는 순간' 사이의 간극을 완전히 없앱니다. 복사-붙여넣기도 없고, 탭을 바꿔 양식에 입력할 필요도 없으며, "나중에 추가해야지"라는 말이 결국 이루어지지 않는 일도 없습니다. 이 도구는 제가 '지금 일해야겠다'고 결정하기를 기다리지 않습니다. 제가 언제나 조금씩이라도 일하고 있다고 가정하고, 그저 방해가 되지 않는 곳에서 기능을 수행합니다.
증거물 19 — S&R CRM
한 고객은 난방 및 배관 기술자들을 위한 유지보수 계약 추적 시스템이 필요했습니다. 어떤 건물에 어떤 장비가 있고, 어떤 계약이 적용되며, 다음 서비스는 언제인지 추적하는 것이었죠. 대부분의 도구가 본능적으로 '계약을 고객에게 연결'하려 합니다. 하지만 이 업계에서는 그것이 잘못된 접근입니다. 고객은 이사하지만, 건물은 그렇지 않습니다. 보일러는 올해 누가 집을 소유하는지에 신경 쓰지 않죠.
그래서 계약은 '거주자'가 아니라 '건물'을 따라갑니다. 사소한 모델링 결정처럼 들릴 수도 있습니다. 하지만 집이 팔릴 때마다 조용히 시스템이 고장 나는 것과, 그렇지 않는 시스템 사이의 큰 차이입니다.
한 고객을 위한 해결책으로 시작했던 것이 독립형 제품으로 발전하고 있습니다. 캘린더 부분은 ScheduleX, 인터페이스는 Mazer, 그리고 여기 있는 다른 모든 것과 동일하게 PHP 네이티브 백엔드를 사용합니다. 아직 전환 중인 단계입니다. '거주자'가 아닌 '건물' 중심의 모델이 이 특정 산업 외부의 누구에게나 명확하게 다가올지, 아니면 이 모델 자체가 제품의 핵심적인 셀링 포인트가 될지는 아직 알 수 없습니다.
결론: 최종 판결
여덟 가지 증거물들. 브릿지, 기억 레이어, 그래프 시각화, 절감된 요금, 마이그레이션 파이프라인, 규제 준수 도구, 나와 함께 생각하는 브라우저 확장 프로그램, 그리고 편리함 대신 정확하게 세상을 모델링하는 CRM까지. 모두 다른 문제들이지만, 매번 같은 반사적인 접근 방식이었습니다. 즉, 무엇이 대체되어야 한다는 이야기에 귀 기울이기 전에, '실제로 무엇이 망가져 있는지'를 살펴보는 것이죠.
이 여덟 가지를 지난번 열한 가지 증거물과 함께 늘어놓으니, 제가 직접 경험할 때는 분명하지 않았던 사실 하나가 명백해집니다. 이력서 상에서는 흩어져 보였던 경력 — 강사, 식당, 우체국, 개발자, 학교 보조원 — 과 포트폴리오 상에서 분산되어 보였던 프로젝트들 — ERP, 브라우저 확장 프로그램, 이력서 시각화, 클라우드 비용 절감 — 은 결국 같은 형태를 하고 있다는 겁니다.
둘 다 제가 우연히 했던 관련 없는 일들의 목록이 아닙니다. 둘 다 어떤 사람이 자신의 길을 가로막는 모든 영역에서 '여기에 실제로 무엇이 문제인가?'를 묻고, '여기에 대한 표준적인 답은 무엇인가?'를 묻지 않는 자세로, 아무도 시키지 않은 시간에 계속해서 문제를 해결할 때 일어나는 일입니다.
저는 그 일을 하는 방법은 알고 있습니다. 하지만 '그것'이 무엇인지, 명함에 세 단어로 요약해서 30초밖에 없는 사람에게, 그 사람이 더 들으려고 하기 전에 어떤 카테고리로 묶어 말해야 할지는 아직 알아내지 못했습니다.
그래서 진짜 질문은 이겁니다. 수사적인 표현이 아닙니다. 이 목록을 쭉 읽으면서, 여기 있는 것 중에 정말로 돈을 내고 싶을 만한 것이 있었나요? 있었다면, 그것을 뭐라고 부르시겠습니까? 저는 단순히 인정을 구하는 것이 아닙니다. 제 작업을 외부인의 시선으로 바라볼 능력을 잃어버렸고, 이전 열한 가지 증거물도, 지금의 여덟 가지도 그 방법을 가르쳐주지 않았기 때문에 묻는 겁니다.
하지만 첫 번째 질문 아래에는 두 번째 질문이 있습니다. 그리고 이 질문이야말로 제가 정말로 답을 얻고 싶은 겁니다. 단순히 "이것들 중 어떤 것이 가치가 있는가"가 아니라, 이 모든 것을 하는 사람이 당신의 입장에서 볼 때 어떤 모습일까요? 그것을 부를 이름이 있을까요? 왜냐하면 제 안에서는, 그저 눈앞에 있는 무엇이든 해결하는 같은 사람으로 보일 뿐이고, 이것이 포트폴리오인지 아니면 그저 저의 성격일 뿐인지 더 이상 구별할 수 없기 때문입니다.
원문: https://dev.to/pascal_cescato_692b7a8a20/unboxable-in-tech-the-evidence-locker-20n4 수집일: 2026-07-11 01:21:14