제목 : 플랫폼 개발 엔지니어로서 출근하기 전, 자아성찰과 나아갈 길에 대한 고찰
부제목 : 인생에서 하나의 챕터를 끝내고, 다음 챕터로 나아가기 위한 글
이 글을 작성하는 이유
개발자, 즉, 엔지니어를 꿈꾸는 이들은 굉장히 많다.
이들은 각기 다른 이유로 개발직을 꿈꾼다.
누구는 "좋은 회사" 에 가기 위해,
누구는 "좋은 연봉" 을 바라기에,
누구는 컴퓨터 그 자체를 좋아하기에, (이건 나에 해당한다.)
누구는 부트캠프에 다녀왔기에, 개발자를 그저 꿈꿀 수도 있다.
나는 다양한 목표를 가지고 개발직군을 꿈꾸는 이들에게, 내 이야기를 들려주고자 이 글을 작성한다.
기초와 경험은 이제 그만, 실무를 해야 한다.
나는 2 주간 약 120 개 정도의 이력서를 넣었으며,
그 중 12 번의 면접 제의를 받았다. (이 글을 작성하는 현재까지.)
현재 차갑다 못해 남극으로 변해버린 채용 시장에서 그래도 꽤 괜찮은 타율을 낸 것 같다고 생각한다.
그러면 이건 오롯이 나의 경험과 능력으로 인해 수많은 면접 제의를 받을 수 있었는가?
절반은 맞고, 절반은 틀리다.
내가 만든 고정관념과 회피성향을 마주했다.
나는 현재까지 총 230 편 이상의 블로그 IT 글을 작성하고, 나만의 IoC 프레임워크를 만들기도 했으며,
팀 프로젝트에서 Backend & Infra & CI/CD 역할을 맡았다.
위의 두 문장은 개발/엔지니어 직군에서 나를 표현 할 때, 단순하게 표현 할 수 있는 문장이다.
물론 프로젝트를 단순하게 1-2 개 한 것은 아니고, 다양한 도메인의 프로젝트를 진행했다.
쿠팡 API 를 분석하여 "보안취약점" 을 보고하고, 3000 달러 (세후 308 정도 나옴) 받은 적도 있다.
이 글을 읽는 분들은 어쩌다 들어오셨을 확률이 매우 높은데,
저는 이러한 글을 작성했었습니다.
- Spring IoC 컨테이너를 내 방식으로 직접 만들기 (Java 의 메타데이터를 극한으로 다루는 법)
- --> 나만의 프레임워크 엔진 만들기
- --> 스스로 Convention 을 만들어 보며, 사용자의 편의성을 체득하기
- index.html 에서 시작하는 점진적인 리액트 프로젝트 적용 방법에 대해서
- --> Legacy 웹 구조를 현대 구조로 변환하려는 현업 종사자들을 위해 작성한 글
- React 런타임 코드 해부 노트 : Fiber 와 Scheduler 를 따라간 21일
- --> 너무 방대하고 복잡한 오픈소스 분석하는 법을 공유하는 글
- React 를 다시 공부하기 전, 스스로에 대한 고찰 및 비판
- --> 나 스스로, 그리고 개발자들을 위해 작성한 고찰
- node.js 로 멀티 스레드 구현하기 (Worker)
- -->
Node.js서버가 단일 스레드 기반 이벤트 루프 구조를 가지기에 가지는 단점을 극복하고자 작성한 글 - --> 비동기 처리는 요청을 빠르게 받아들이지만, 단일 스레드가 모든 Context 를 가지기에,
복잡한 계산이 서버에서 실행 될 경우, 요청 I/O 가 느려질 수 있음을 알고 작성 한 글
- -->
- C 그리고 fgets 라인 입력만으로 tokenizer 메서드 제작하기 (하드코어)
- --> 나 자신의 알고리즘 포텐셜을 높이고, 메모리 구조와 로직을 Low 에서 다루고자 노력했던 글
사람들은 자신만의 세상을 만들 수 있으며, 고정관념을 가지고, 스스로의 길을 개척 할 수 있는 권리가 있다.
특히나 나는 수많은 글을 제작 할 때, 단순 "정보 전달" 에 그치지 않고, 나의 생각을 나누었다.
따라서 구글 검색 엔진이 나의 글 점수를 높게 쳐 주어, 7,000 이상의 조회를 달성했다고 생각한다.
그리고 약 2 년 동안 정말 꾸준하게 블로그 글을 작성했기 때문이었다.
그러나 나는 오랜 독학으로 인해 실제 세상을 깨닫지 못하고, 스스로의 세상에 갇혀 있었다.
나는 내가 만든 새장에서 나올 생각을 못했지만, 이미 엔지니어로서 일하고 있던 친구의 도움으로
실제 세상을 마주하고, 내가 땅바닥에 버렸던 모든 기회비용을 마주했다.
이를 스스로 마주한다는 건, 매우 어려운 일 중 하나에 속했다.
면접 제의를 받았을 때, 이를 오롯이 나의 경험과 능력으로 볼 수 있는가?
라는 질문을 던진다면, 나는 절대 아니다 라고 말할 수 있다.
완전한 준비 상태는 존재하지 않는다. 그러나 미리 준비된 사람이 압도적으로 유리하다
고심해서 생각난 문장인데, 나는 3 년 동안의 공부와 프로젝트를 진행하면서 이 생각을 하지 못했다.
다행인 것은, 꾸준히 작성한 나의 블로그는 "나는 준비되었다" 라는 것을 "정량적으로" 보여주는 증거였다.
우리가 생각해야 하는 것은, "어느 정도가 준비 상태인가?" 를 정의하는 것이다.
신입 개발자이자, 엔지니어로 변모하기 위해, 우리는 얼마나 준비해야 하는지 모른다.
그 전에, "도대체 무엇을 준비해야 하는 지 조차도 알기 힘든 것" 이 바로 "Develop" 이라고 생각한다.
AI 가 많이 발전 한 것은 사실이다. 나는 Cursor Pro 를 사용하여 복잡한 형태의 아키텍쳐를 구성해 보기도 했다.
"처음엔 경악과 감탄이었고, 15 분 이후부터는 의문으로 변했다."
- AI 는 인간의 컨벤션을 가져와 자신만의 Convention 으로 인간이 코드로 개입 할 여지를 주지 않는다.
- 쓸데없는 행동(명령어 직접 입력) 으로, 정해진 Token 수를 과도하게 낭비한다.
- Architecture 가 복잡 해 질 수록, AI 사용은 비례하지 않고, 기하학적으로 상승한다.
위의 3 가지는 내가 최신 버전의 Cursor Agent 를 사용하면서 알게 된 것이다.
나는 모든 과정을 보고, 최종 오케스트레이션은 엔지니어가 관리해야 한다는 것을 알게 되었지만,
이 글을 읽는 여러분들은 어떤 생각을 하실 지 모르겠다.
개발의 분야는 단순히 취업 시장에서 나뉘는 것 보다, 보지 못하는 영역이 훨씬 더 많기 때문에,
각자 이 특징을 보고 자신은 어떻게 성장해야 할 지 정해야 한다고 생각한다.
스스로 정의한 "준비" 가 되었다고 생각하면, 자신이 내세울 수 있는 "강점"이 무엇인지 생각해야만 한다.
이는 비단 신입 뿐만 아니라, 실무를 하고 있는 사람에게도 해당 될 수 밖에 없다.
AI 시대에서 가장 중요 해 진 것은, 아이러니하게 "인간의 본질" 이었다.
인간의 본질을 정의 해 보자.
철학, 영혼, 생명, 죽음, 혹은 우주적인 엔트로피 상승 요인... 이런 추상적인 영역을 제외하고,
개발, 그리고 엔지니어로서 갖추어야 할 "인간의 본질" 에 대해서 이야기하고자 한다.
내가 AI 보다 개발을 잘 할까?
솔직히 말해보자. 단순 코드 구현, 알고리즘, API 엔드포인트, JWT 보안 구성, 세션, 등등..
이들은 모두 AI 에게 점령되었다. 이는 Web 과 App 분야에서도 마찬가지이다.
심지어 특정 아키텍쳐를 배워야 하는 "결제 시스템" 조차, AI 가 가장 구현을 잘하는 영역이다.
AI 보다 코드를 빠르게 만드는 사람은 그냥 없다고 봐도 무방하다.
생산성 자체로 보았을 때, AI 를 이길 수 없다. 이용하는 시각을 가져야 한다.
2022 년 부터 시작된 AI Boom 부터 현재 2026년 까지의 행보를 다시 보자.
처음에는 똑똑한 단순 Chat 이었다. 코드를 작성할 수 있지만, 할루시네이션이 심했다.
Version 이 업그레이드 되어가며 복잡한 "규칙" 과 "법" 그리고 "구현" 을 매우 잘하게 되었다.
이 시기 미국에서는 살벌한 전문직 해고와, 절반 이상의 개발직군 해고가 동시에 이루어지기 시작했다.
버전이 업그레이드 될 때 마다 똑똑해 지는 것이 보일 정도이다.
조금 시각을 바꿔서 보자. 그 당시 완벽하지 않던 AI 때문에 과연 대량 해고가 일어났을까?
내가 만약에 대형 기업을 이끄는 수장이었다면, 그 수많은 사람들의 노고를 세심하게 알 수 없다.
즉, 정량적 업무와 기여 수치를 만들고, 지정한 수치에 이르지 못한 자를 모두 잘랐다고 볼 수 있다.
한국과 다르게 미국은 자르는게 훨씬 쉽다.
즉, "회사" 는, 기존의 구현 업무를 진행하던 사람들을 "해고하고",
AI 의 발전과 사용으로 얼마나 인력을 대체할 수 있는지 Testing 한 것이다.
그게 비록 특정 업무의 마비가 일어나더라도, 가장 비싼 투자인 "인력" 자체를 삭감할 수 있었기 때문이다.
문제는, 회사 자체가 이러한 과정 속에 AI 의 활용에 익숙해져 굳이 사람들을 뽑을 이유가 많이 없어진 것이다.
지금 사회는 단순하게 AI 하나만 이용하지 않는다.
AI Codex, MCP, Agent 와 같은 개념이 등장하며, 목적을 위한 "판단" 까지도 동시에 수행하려 한다.
머리를 잘 사용하고, 돈을 많이 주어야 했던 White-Color 직군들이,
회사 입장에서는 AI 로 교체하고 싶으며, 심지어는 AI 가 더 잘하기도 한다.
회사 입장에서는 인건비가 가장 큰 "지출" 일 테니, 군침을 흘릴 수 밖에 없다.
다시 돌아와서,
결국 우리가 개발/엔지니어 를 하고자 함은, 원하는 일을 하고자 함이다.
그리고 AI 가 가장 잘 하는 것이 바로 "개발" 이다.
우리는 어떻게 사회에서 살아남아야 하는가?
이는 단순히 "개인"에게 할당된 문제가 아니라, "회사" 그 자체에도 해당되는 문제다.
공기업, 공공기관으로부터 단순 구현 수주를 받는 회사는 서서히 저물 수 밖에 없다.
정말 수많은 IT 기업들이 무너졌다. 이를 보고 IT 기업들은 살아남기 위해 변했다.
이 급격한 AI 시대 변화에 살아남기 위해 가장 노력한 주체가 바로 기업이다.
기업의 변화를 보면, 우리가 어떻게 AI 사회에서 생산성 있는 사람으로서 변모할 수 있는지 보여준다.
그건 정말 간단하게도, "AI" 를 어떻게든 사용하고 이용하는 것이다.
즉, 인간의 적응 능력으로, "뛰어난 AI" 를 사용하여 더 높은 생산성을 끌어올리는 것이다.
AI 를 어떻게 이용해야 하나?
내가 질문한 이 문장의 본질은, 단순히 "AI 를 사용하세요" 가 절대로 아니다.
정말로, AI 를 어떻게 바라봐야 하냐는 의미이다.
우리 모두는 AI 가 너무 급격하게 성장하고 변화하기에, 단순히 원하는 정보 추출과 사용 그 자체에만 몰두해 있다.
나는 최근에 Spring IoC/DI 컨테이너를 직접 만들어 가벼운 프레임워크를 만들었는데,
그 과정에서 생각난 발상이 존재했다.
AI 를 사용하는 것이 아니라, AI 에게 "도구 혹은 정보" 를 제공해라.
대부분의 IT 기업들은, 개발 인력을 통한 서비스 구현과 제공에 초점을 두었다.
그러나, 이러한 생산성을 AI 에게 빼앗긴 기업들은 선택을 해야 했다.
대부분의 기업은 감히 엄두도 못 할 정도의 기술력을 가진 것은 아니기 때문이었다.
그래서 현재 일반적인 IT 기업들은,
- 다른 기업에게 AI 도입 컨설팅
- AI 를 이용한 빠른 구현 & 인건비 감소 (개발자를 자르며) --> 절대 지속적이지 않음.
- AI 자체 제작 --> 극소수
- AI Agent 제공 --> 국제기업 AI 와 오픈소스 AI 를 결합한 맞춤형 "로컬 AI" 제작 회사
- 접근하기 어려운 정보를 부여받아 서비스를 제공하는 회사 (당연히 AI 사용)
- 단순 서비스 중개 뿐만 아니라, 하드웨어로 진출하는 회사 (당연히 AI 사용)
일단 크게 생각나는 대로 적어보았다.
공고를 300 개 정도 보았는데, 기업의 성장 방향성이 위와 같이 변하고 있다고 판단했기 때문이다.
AI 를 음식에 비유 해 보자. - 고추가루와 고추장의 탄생
고추가루와 고추장은 우리나라 음식에 빠지지 않으며, 엄청난 감칠맛과 매운맛을 더해주는 재료다.
여기서 나는 고추가루와 고추장을 AI, 그리고 AI Agent 에 비유 할 것이다.
상황을 가정 해 보자.
- 2021 년 까지, 고추가루는 기존의 재료를 대체 할 만큼 훌륭하지는 않았다고 가정하자.
- 사람들은 음식을 먹을 때, 대부분 고추가루가 존재하지 않는 음식을 먹었다고 가정하자.
- 사람들은 매운 것을 원하기에, 만들기 힘든 캡사이신을 조금씩 넣어 먹었다고 가정해 보자.
그런데, 2022년에
매운맛, 감칠맛을 너무나 쉽게 더해주고, "어떠한 음식" 에도 궁합이 잘 맞는 재료,
"고추가루"(AI) 가 등장했다.
사람들은 기존에 음식(서비스)에 고추가루가 들어갔을 때, 대부분의 상황에서 맛이 더 좋아 진 것이다.
음식 제조에 일가견이 있는 사람들은, 모두 고추가루를 융합하여 고객에게 판매하기 시작했다.
그렇게 고추가루로 인해 모든 음식이 상향 평준화 되었을 때, 고추가루를 이용한 융합 재료,
2023-2024 년 즈음, "고추장"(AI Codex, AI Agent) 이 등장했다.
이미 음식(서비스)이 상향 평준화 된 상황에서, 음식을 제조하는 모든 회사들은 이 기회를 놓칠 수 없었다.
따라서, 자신들의 모든 기존 음식 제품에, "고추장" 을 섞어서 만들어 판매하게 된 것이다.
그리고 현재로 돌아와서, 우리는 모두 저렴한 가격에 "고추장" 을 구매해서, 밥에 비벼먹고 있다.
우리가 음식을 제공하는 사람이라고 생각 해 보자.
우리는 살아남기 위해서 "어떤 음식"(프로그램) 을 만들어야 하는가?
여기서 확실히 해야 할 것은, "고추가루" 와 "고추장" 만 있으면 맵기만 하다는 것이다.
그래서 우리는 계란, 콩나물, 참기름, 혹은 참치캔을 따서 재료들을 밥과 같이 비빈다.
여기서 "계란", "콩나물", "참기름", "참치캔" 은 비유인데,
각 개인이나, 회사가 가진 인력과 능력, 정보에 해당 할 수 있다.
각자에게 맞는 재료들이 무언인지를 깊게 생각 해 보아야 한다.
변하는 세상에 흔들리지 말고, 자신만의 어려운 길을 걸어야 한다.
자신만의 세상에 갇히라는 것이 아니다.
바로 위에서 설명한 "계란", "참기름", ... 과 같이,
AI 와는 궤를 달리하는 능력이 필요하다.
이 글을 읽는 여러분이, AI 에게 대체된 능력을 가지고 있더라도 상관없다.
단순한 게시판 서비스를 만들더라도, 그 과정에서 겪은 나만의 트러블슈팅(해결과정) 은,
AI 가 함부로 대체 할 수 있는 능력이 아니다.
이러한 생각으로, 나는 누구도 관심을 기울이지 않았던
Spring IoC/DI Container 프레임워크를, 나만의 시각, 그리고 방식으로 만든 것이다.
그 과정을 겪으며, 개발자와 엔지니어들도 보지도 듣지도 못한 기능을 직접 제작 및 사용하며,
나만의 계란과 참기름을 만들어가는 것이다.
그리고 나만의 재료는 AI 와 결합하여 특별한 서비스를 만들어 낼 수도 있는 것이다.
우리는 여태까지 특정 능력을 고도화시켰는데, AI 가 대체해버렸다.
이 소단원을 따로 넣은 이유는, AI 에 부정적인 시각을 가짐을 말하는 것이 아니다.
누구라도 자신이 여태껏 키웠던 능력을 5 년도 안되는 시간 안에 빼았겼다면, 매우 불쾌할 수 밖에 없다.
예술의 영역이었던 그림, 음악, 편집은 AI 가 가져간 것이 사실이다.
나는 누군가 어렵게 제작한 프로그램이 있다면, 시간만 주면 나는 만들 수 있다고 자부할 수 있다. 끈질기기 때문이다.
그러나 유튜브에서 "심통봇" 이라는 유튜브 채널을 보았다.
이 채널은 뮤직비디오를 AI Agent 와 같이 협업하여 만드는 채널인데, 영상의 결과물이 비록 AI 같더라도,
AI 양산형 콘텐츠를 생산하는 채널과는 격을 달리하는 콘텐츠를 생산했다.
나는 어떤 프로그램이던 시간만 준다면 반드시 해낼 수 있다고 생각하는 사람인데,
거의 유일하게 이 사람은 어떤 방식과 시각으로 이러한 컨텐츠를 생산하는 건지 감이 잡히지 않았다.
즉, 사람인 우리는 개인이 가진 고유의 특성이 있다.
이것은 성격이 될 수도, 인맥이 될 수도, 정보가 될 수도, 아이디어가 될 수도 있다.
우리가 가져야 할 시각은, "너가 나를 대체했어." 가 아니다.
"너를 통해 내가 이득을 보겠다." 라는 시각을 가져야 한다.
기존의 프로그래머들은 특정 라이브러리, 프레임워크, 코드 작성에 익숙하다.
그렇다면, 우리는 일종의 "감독" 으로서 AI 가 코드를 단순히 출력한 것인지,
책임 분리와 유지보수성을 유지했는지, 인간의 개입을 위해 우리가 어떤 라이브러리를 사용하여 테스팅하라고 명령할지
생각해야 한다.
그리고 이러한 능력을 가지기 위해서는, 어떤 언어와 도메인, 혹은 지식이던, 굉장히 깊게 팔 필요가 있다.
즉, 우리는 밑바닥의 기초 지식을 알기에 비즈니스 로직과 데이터베이스를 연결 할 수 있었다.
그리고 에러를 처리 할 수 있었다.
그러나 AI 를 생각 해 보자. 당연히 어떤 기초 지식이던 물어보면 정확하게 알려주겠지만,
비즈니스 로직과 복잡한 플랫폼 관리를 만들기 위해, AI 는 딱히 밑바닥 지식을 고려하지는 않는다.
그저 자가 테스트를 통해 에러가 일어나면, 그 때 가서 오랜 분석을 거친다.
Cursor 를 통해 간단한 React + Spring + Redis + Docker 프로그램을 제작했을 때,
우리가 흔히 말하는 Maven Central 의존성 라이브러리 중 E2E 테스팅 라이브러리를 가져오지 않고,
비효율적으로 curl 명령어와 body 내용문을 직접 집어넣어 테스팅하는 작업을 연속으로 틀리고,
수십 번의 행동으로 토큰을 낭비하는 과정을 보면서, 나는 엔지니어가 가져야 할 시각을 비로소 보게 되었다.
너가 취업 되었으니까, 맘 편하게 이런 글을 작성하는 거 아니야?
세상은 더욱 비정해졌으며, 개인주의적으로 변했다.
직관적으로 Money(돈), Wealth(부) 는 사회가 발전하며 점점 더 양극화 되어가고 있다.
그리고 우리가 가질 수 있던 스스로의 인력,
즉 사회에서의 생산성 조차도 기존의 실력자들이 가로채 갈 수 있는 것이 사실이다.
소셜 미디어로 사람들의 자존감조차도 깎였는데,
심지어는 사회에 미칠 수 있는 나의 영향조차도 없어졌다고 생각할 수 있기 때문이다.
솔직히 말해서, 나 또한 그랬다.
나는 C 언어로, 제한된 라이브러리를 사용하여 C 자체의 내장 라이브러리를 다루지 않고 직접 제작 해 봤으며,
이를 통해 저 수준의 메모리 조작과 나만의 타입 생성을 경험했다.
나는 Java 를 통해 IoC/DI 프레임워크를 제작 해 보았으며,
이 과정에서 Spring 의 오픈소스 코드는 쳐다도 보지 않고, 기능만 보고 다른 시각으로 제작했다.
나는 쿠팡에게 공개 API 취약점을 보고하여 3,000 달러의 포상금을 얻기도 했다.
나는 React 라는 거대한 라이브러리 오픈소스의 코드를 뜯어 일부 순환 사이클을 분석했다.
등등.. 말하고 싶은 것이 너무 많다.
사람들은 자신들이 내세울 능력이 있으며, 그것을 사회에 알릴 수 있다. 그건 권리이다.
그러나, 지금의 상황을 정확히 요약 해 보자면,
AI 로 인력을 대부분 교체 할 수 있는거 아니야?
였다가,
AI 와 인력을 합쳐야 생산성이 극대화되는구나
로 바뀌었다고 생각한다.
지금은 혼돈의 시기이다. 어떤 능력이 대체될지, 무엇을 요구할지, 그것은 알 수 없다.
따라서, 기업들도 사람을 뽑아야 하는데, 그 기준이 명확하지 않고 추상적으로 변했다는 것이다.
나는 웹 페이지의 구조와 비즈니스 로직에 대한 이해, 의존성의 원리, 그리고 아키텍쳐의 존재 이유를 알고 있다.
10년차 시니어 수준의 지식은 아니더라도, 아키텍쳐가 미치는 영향이 무엇인지는 알고 있는 것이다.
이제는 회사에 작성된 특정 프로그램의 이해도를 따지는 것이 아니라,
어짜피 해당 프로그램은 AI 를 이용하여 빠르게 유지보수 및 기능 추가를 도입 할 수 있으므로,
전체적인 이해도를 가진 신입을 뽑는 것을 추구한다는 걸 알 수 있었다.
왜냐면, 면접제의 온 회사들의 업무가 전부 달랐고, 언어, 프레임워크, 웹, 프론트, 아키텍트, .. 다양했다.
심지어는 PHP, OracleDB 를 사용하는 회사에서도 면접제의가 왔기 때문이다.
이 회사들이 나를 잘못 부른 것이 아니다. 미래에 어떤 프로그램과 플랫폼을 구축할 지 모르는데,
빠르게 변화하는 세상에 적응 할 줄 아는 신입을 원하는 것이다.
이것은 단순히 AI 를 이용하여 프로그램을 뽑아내는 사람 뿐만 아니라,
CS 기초 지식에 매우 튼튼한 사람에게도 유리한 조건이다.
각자 자신만의 능력에 대한 상대적인 기준점이 있을 것이고, 다르다는 것을 알 수 있다.
그러나, 이제는 확실하게 정해야 한다.
현재까지 자신이 세워 온 업적이, AI 세상에서, 어떤 강점을 가질 수 있는지 정하고, 키워야 한다.
그리고 공통적으로, AI 사용은 필수이다. (어떤 업무던.)
나에게 해당되는 것.
이 글은 단순히 취준생들(특히 개발자) 혹은 회사(IT) 들을 위해 작성하는 글이 아니다.
나 스스로가 뼈저리게 이 세상을 마주해야 하기 때문이다.
내가 플랫폼 구축을 완성하고 큰 기여를 준다 한들,
AI 발전이 훨씬 빨라져서 내가 미리 정리했던 .md 파일들을 읽고, 순식간에 대체 할 수도 있다.
그러나, 절대로 없어질 수 없고, 대체할 수 없는 것이 있다.
바로 플랫폼을 구축하기 위해 경험하게 될 나의 AI 협업 과정이다.
현재는 이러한 AI 협업 과정을 정확하게 정의할 수 없어 "바이브코딩" 이라고 부르기도 하지만,
이제 몇 년 지나지 않아 AI 와 협업하는 전문 엔지니어를 따로 부르는 언어가 생길 것이다.
아직 나는 치열한 아키텍쳐 구현에 해당하는 실무를 겪지 않았다. 나는 내 미래를 알 수 없다.
그러나 하나는 알고 있다. 이 모든 게 헛되지 않는다는 것을.
비록 원하는 길이 나오지 않더라도, 항상 인생은 다른 길을 제시했던 것을 이전부터 많이 체험했기 때문이다.
마지막으로 하고 싶은 말.
최근에 유튜브에 영화 "혜옥이" 라는 요약 영상이 떴다.
굉장히 흥미있게 봤는데,
고려대를 나온 여주인공이 부모님의 등살과 스스로의 선택으로 행정고시 5급을 준비하며,
매년 동일한 실패를 겪으며 마주하는 "매몰비용" 에 대한 영화이다.
붙지 않으면 그 동안의 청춘과 미래가 모두 "매몰비용" 으로서, 회수될 수 없다는 의미가 아니다.
사람은, 쉽게 변하지 않는다. 그러나, 극단적인 상황에서 변한다.
이 극단적인 상황은, 주변인과 주변 상황에 따라 벌어질 수도 있지만,
누구에게나 벌어질 수 있는 상황에서, 스스로를 갉아먹는 상태로 전환시킬 수 있다.
나는 대부분의 취준생이 이 상황에 놓여있다고 생각한다.
내가 말하고 싶은 것은 극단적인 상황이라는 것은 스스로 결정하는 것이라고 생각한다.
별 볼일 없는 일이 나 자신에게는 극단적일 수 있고,
너무나 심각한 상황이 나에게는 별 볼일 없는 일이 될 수 있다.
여러분에게 드리고 싶은 말씀은, 스스로의 가치를 놓치지 말고, 스스로를 인정하시고 받아들였으면 좋겠습니다.
그렇다고 자만감을 가지진 마십시오. 자만감과 자신감은 한 끝 차이일 수 있겠으나,
이 차이는 스스로가 자만감인지, 자신감인지 생각 하는 과정에서 나뉜다고 생각합니다.
스스로 만든 세상을 부수고, 현실을 알게 된다는 게 얼마나 힘든지 알고 있습니다.
제 글을 통해 여러분들이 응원을 받고, 스스로를 다시 돌아보셨으면 좋겠습니다.
-그저 수많은 사람 중 하나 일 뿐일 사람. 코딩크리처 블로그 운영자 올림.-
