Unboxable in Tech: 30년 동안 틀린 형태
Source: Dev.to
This is a submission for the 2026 WeCoded Challenge: Echoes of Experience
매번 리크루터나 인재 파견 업체가 연락을 할 때마다 대화는 똑같은 방식으로 끝납니다.
“당신의 프로필은 정말 흥미로운데… 솔직히 말해서, 어느 박스에 넣어야 할지 모르겠어요.”
처음엔 이것을 예의 바른 어색함이라고 생각했고, 그다음엔 뒤끝이 있는 칭찬이라고 여겼습니다. 오늘은 이것을 지금까지 누군가가 나에게 해준 가장 솔직한 진단으로 받아들입니다.
30년 동안 코딩하고, 모델링하고, 새벽 3시에 디버깅해 왔습니다. 비즈니스 문제가 상류에서 제대로 이해되지 않았기 때문이죠. 30년 동안 작동하는 시스템을 구축해 왔지만, 업계는 여전히 나를 설명서 없는 이케아 가구처럼 바라봅니다.
문제가 나가 아니라면 어떨까?
Act 1 — TO7과 우연한 계시
첫 접촉: 1980년대 중반, 중학교 교실에 있던 Thomson TO7. 약간은 미친 수학 선생님이 카세트 테이프에 저장된 BASIC으로 문자들을 춤추게 하는 방법을 보여주셨다. 열세 살에게는 GOTOs가 있는 나니아와도 같았다.
3년 뒤 나는 순수 인문학 트랙—라틴어, 그리스어, 독일어, 철학, 끝없는 에세이—에 몸담고 있었다. 키보드는 보이지 않았다. 하지만 결국 컴퓨터 과학 학교에 입학했을 때, 그 바이러스는 여전히 잠복해 있었다.
그 학교는 완전히 다른 세계였다: COBOL, CICS, JCL; 메인프레임, 대규모 조직, 형식적 방법론. 데이터 모델링을 위한 MERISE, 프로그램 구조를 위한 Warnier. 엄격함, 계층 구조, 문서화.
첫 인턴십: Intel 8088을 기반으로 한 기계, 두 개의 5¼″ 플로피 디스크 드라이브, 그리고 GW‑BASIC으로 중학교 도서관을 디지털화했다. 겸손한 설정—우리가 배우던 시스템과는 전혀 달랐다.
아주 빨리 명확해졌다:
프로그램 자체가 진짜 문제는 아니다.
진짜 문제는 구조가 잘못된 데이터다. 대출, 반납, 저자, 사본—관계가 처음부터 올바르게 정의되지 않으면 아무것도 유지되지 않는다. 그래서 나는 코드를 한 줄도 쓰기 전에 먼저 모델링했다.
이 방법은 기계에 의존하지 않는다.
스무 살에, 정확히는 알지 못했지만, 나는 내 입장을 선택했다: 코더보다 시스템 사고가 먼저.
Act 2 — The Patchwork Years
What followed was a joyful, improbable patchwork.
- Architecture firm – quantity surveying in dBASE III+, an HP printer with no manual. Two weeks deciphering the jumpers on the back like a Chinese puzzle, because you had to understand the machine before you could ask anything of it.
- Regional postal authority (when Chronopost was still in pilot mode) – small applications to track shipments and complaints.
- Industrial cleaning company – OS/2 and Lotus Symphony, automating invoices and schedules.
Each time the same ritual: dive into the actual business, model the flows, structure the data, then code. Understand first. Build after.
No permanent position. No defined job title. No linear career. A way of working that held up—but had no name in the industry’s classification grids.
Act 3 — 파리, 인력 파견 업체, 그리고 문화 충돌
2006년에 나는 “보통” 루트를 시도해 보았다: 파리, 오픈 플랜 사무실, 인력 파견 업체, Pierre & Vacances, Photoways, 현장 계약. 내부에서 어떻게 돌아가는지 직접 보고 싶었다. 나는 보았다.
전체 Agile 도입: Redmine 티켓, 데일리 스탠드‑업, 회고, 벨로시티 포인트. 일주일에 3~4시간의 의식이 결국 시스템에 대해 실제로 생각하는 10분에 불과했다.
나는 결과물을 전달했다. 하지만 내부에서는 외치고 있었다:
“클라이언트가 리드의 15 %를 잃는 이유를 파악하는 것보다 번다운 차트를 채우는 데 더 많은 시간을 쏟고 있다.”
전체 스프린트가 사용자 스토리를 밀리미터 단위로 쪼개는 데 사용되었고—한 번도 물어보지 않았다: 이 데이터 모델이 5년 후에도 버틸 수 있을까? 우리는 벨로시티를 외치고, 나중에 고치겠다고 했다.
문제는 Agile 자체가 아니라, 그것이 변질된 형태였다: 실제 작업에 할당하던 에너지와 집중력을 모두 소모하는 집단적인 안심 의식.
한 가지 예외
Logic‑immo (2008‑2009) – 인력 파견 업체를 통해 채용됨. 나는 Zend Framework 역할 면접에 들어갔다가 20분 만에 나와 전혀 다른 일에 채용되었다: Oracle‑to‑MySQL 마이그레이션, CLI 모드 PHP, 절대 양보할 수 없는 요구사항—데이터 무결성이 먼저, 실행 속도가 그 다음. 트렌디한 프레임워크도, 유행어 빙고도 없었다. 단지 로드맵만 있었다.
누군가가 내가 실제로 하는 일을 보았고, 서류에 적힌 것만 보지는 않았다. 현장 반, 원격 반, 데이터가 중심이 되는, 완벽히 짜여진 스크립트. 내가 최고의 역량을 발휘할 수 있는 그런 일.
그것은 드물었다. 의미 있게 드물었다.
나는 2011년까지 버텼고, 그 뒤 짐을 싸서 떠났다. 2012년에 딸이 태어났다. 그것은 후퇴가 아니라 결론이었다.
Source: …
Act 4 — Building on My Own Terms
Leaving didn’t mean stopping.
- Regional classifieds site – Zend Framework, Smarty, 동적 생성 및 100개가 넘는 비즈니스 사이트를 맞춤 라우팅으로 관리. 10개월, 혼자 작업.
- B2B matching platform – 시간대 제한과 인간/자동 중재; 알고리즘 최적화, 부드러운 인터페이스, 이전 시스템을 부끄럽게 만들 정도의 성능.
- Other projects – 누군가 특정 기술을 쓰라고 요구하지 않은 프로젝트—그저 구체적인 결과를 얻기 위해 선택함.
그 뒤엔 dev.to, 영어로 글쓰기, 그리고 의뢰받지 않은 프로젝트들.
- RFC 2324 – 1998년 엔지니어들의 농담인 커피포트용 HTTP 프로토콜. 나는 이를 Python의 순수
asyncio서버로 진지하게 구현했는데, 이는 프로토콜이 실제 기술 문화에 대해 무엇을 말하는지 이야기할 좋은 변명이었음. - My own satirical RFC – HTBMCP/1.0, “맥주잔 제어 프로토콜”, 포트 1414, 번호 1516은 Reinheitsgebot(맥주 순수법)에 대한 경의를 표함.
- AJC Bridge – WordPress 플러그인으로, 콘텐츠를 GitHub을 통해 정적 사이트 생성기로 동기화함. 내가 필요로 하는 형태가 존재하지 않았고, 바로 해결해야 할 문제였음.
- CV as a graph – 내 이력서를 시간 순서가 아닌 관계 그래프로 분석함. 선형 이력서는 내와 같은 경로를 표현할 수 없기 때문.
이 프로젝트들은 모두 직무 설명이 없으며, 전통적인 의미의 “풀타임”도 아니다. 하지만 각각은 결국 내가 스스로 설계한 상자에 나를 맞추게 해 주는 퍼즐 조각이다.
ack React Node AWS. 그리고 이 모든 것은 같은 출발점에서 시작한다: 이력서를 채우는 것이 아니라 실제 문제에서.
마지막 예시 하나. 나는 AJC Bridge를 공식 WordPress.org 플러그인 저장소에 제출했다. 몇 주 기다린 뒤, 검토자는 플러그인 이름을 무시하고 일반적인 슬러그를 지정했으며—설명도, 내 이의 제기에 대한 관심도 없었고, 아무도 소유하지 않은 단어에 대한 가상의 상표 문제를 들어냈다. 나는 제출을 철회했다. 이제 플러그인은 GitHub Releases를 통해 직접 배포된다.
같은 메커니즘. 다른 무대.
Act 5 — The Same Job, Thirty Years Later
나는 이제 풀타임으로 코딩하지 않는다. 교실 보조원으로 일한다.
내가 꿈꾸는 직업이라고 가장하지 않을 것이다. 교실 보조원이라는 일은 선택에 의한 저임금 고용, 혹은 오히려 거부에 의한 것이다. 나를 어떻게 다뤄야 할지 모를 시스템과 계속 싸우는 것을 거부하는 것. 나의 지역, 딸, 나만의 일하는 방식을 희생해서라도 나를 위해 만들어지지 않은 틀에 맞추는 것을 거부하는 것.
그것은 타협이다. 명료하고, 의도적이며, 때로는 지치게 만든다.
하지만 그것은 나의 것이다.
이 아이들과 하는 일은 내가 시스템과 했던 일과 이상하게 닮았다: 가정 없이 관찰하고, 문서가 주장하는 방식이 아니라 실제 작동 방식을 이해하고, 적응하고, 누군가가 넣으려는 상자에 맞추는 것이 아니라 이 특정한 사람에게 맞는 해결책을 억지로 맞춰 만든다.
내 방법도 여기서는 똑같이 파괴적이다.
WeCoded 챌린지는 기술 분야에서 소외된 목소리를 기념한다. 나는 성소수자는 아니다. 하지만 나는 충분히 많은 동료들과 함께 일해 왔기에 그 메커니즘을 알게 되었다: 네가 상자에 맞지 않는 것이 아니라, 그 상자가 너를 배제하도록 만들어졌다는 것이다. 명시된 이유가 성별이든, 배경이든, 자격이든, 혹은 사람들을 불편하게 만드는 사고방식이든—결과는 동일하다.
소외는 항상 눈에 보이는 것은 아니다. 때로는 단지 — 분류 불가능 — 할 뿐이다.
만약 누군가가 “멋진 프로필이지만 우리 상자에는 안 맞아요” 라는 말을 건넸다면—주의 깊게 들어라: 네가 고장 난 것이 아니다. 그들의 분류 그리드가 너무 좁을 뿐이다.
업계는 초특화된 부품을 사랑한다. 전체 시스템을 보고 “이렇게 계속 가면 2년 안에 무너질 겁니다” 라고 말하는 사람을 거의 용납하지 않는다.
너는 분류 불가능한 것이 아니다. 단지 매칭 알고리즘에 읽히지 않을 뿐이다.
그리고 아니, 그들이 읽는 법을 배울 때까지 기다릴 필요는 없다.
모든 것이 기술 부채와 깨진 약속의 무게에 눌려 무너질 때—분류 불가능한 사람들만이 그들이 찾는 대상이 된다. 그들을 감사하기 위해서가 아니라, 문제를 고치기 위해서다. 그리고 나서 다음 위기가 올 때까지 그들은 그들을 잊어버린다.
그러니 지금 바로 네 공간을 만들라. 허가를 기다리면서가 아니라.
그들은 네 상자를 요구하지 않을 것이다. 그냥 물을 뿐이다: “이거 고칠 수 있나요?”
예. 나는 할 수 있다.
그리고 아마도 너도 할 수 있을 것이다.