해당 글은 7월 26일 GDG Incheon & GDG Songdo 에서 주최한 Google I/O Extended Incheon의 General 세션 바이브코딩시대에 살아남는 개발자가 되는 방법을 다룬 글입니다.

서론

저는 2022년 ChatGPT가 나왔을 땐 단순히 "아~ 이제 검색하는데 시간 좀 덜걸리겠다." 정도로만 생각하고 별 위협을 느끼지 못했어요. 근데 반년도 채 지나지 않아 GPT의 새로운 모델이 나오고 몇분도 안돼서 몇천줄의 코드가 나오는 걸 보고 저는 벽을 느꼈었습니다. 코드를 빠르게 짜거나 많이 짜서 벽을 느낀게 아니라 말도 안되는 이 모델의 성장 속도를 보고 벽을 느꼈어요.

그런데 지금은 어떤가요? 이 때 GPT보다 성능이 뛰어나고 뾰족한 AI들이 정말 많이 생겼어요. 그래서 저는 계속 이런 고민을 해왔던 것 같아요. "내가 지금 잘 하고 있는걸까?", "AI가 나를 대체하지는 않을까?"하는 고민을 쭉 해왔었고, 그래서 오늘 바이브코딩시대에 살아남는 개발자가 되기 위해 제가 해왔던 고민과 통찰을 여러분들과 한번 나눠보려 합니다.

본론

역사와 흐름을 알자

저는 우선 살아남기 위해선 개발자의 역사와 흐름을 알아야한다고 생각했어요. 그래서 제 나름대로 개발 패러다임의 변화를 AI 등장 이전 시기, ChatGPT 등장 시기, 그리고 지금 우리가 살고있는 Agentic AI의 시기로 나눠봤어요.

AI 등장 이전 시기

AI 등장 이전에 우리는 어떤 방식으로 일을 했었나요? 에러가 발생하면 우리는 매일 밤을 새며 깃허브 이슈와 스택 오버플로우 등을 뒤지며 일을 했었어요. 이 때 우리에게 중요한 역량은 무엇이었을까요? 저는 이 때 우리에게 중요했던 역량을 3가지 꼽아보라면 CS지식과 검색 능력, 그리고 브레이크포인트를 찍으며 어디서 에러가 발생했는지 찾고, 왜 이런 에러가 났는지 분석하는 에러 분석 능력이 중요했다고 생각해요.

ChatGPT 시기

ChatGPT가 나오고 우리의 일하는 방식은 어떻게 변했나요? 우리는 이제 더이상 직접 검색하지 않게 되었습니다. 단순히 코드를 작성할 때에도 지피티에게 “해줘” 라고 한 뒤 그 결과물을 단순히 복사 붙혀넣기 했고, 만약 에러가 났으면 다시 에러 코드를 복사하고 붙여넣은 뒤에 “해줘” 만 반복했었죠.

그럼 이 때 우리에겐 어떤 역량이 중요했었을까요? 저는 AI 도구 활용 능력과 프롬프트 작성 능력, 그리고 AI가 작성해준 코드를 판단하는 코드 검증능력이 중요했다고 생각해요. AI를 효율적으로 토큰을 덜 쓰면서 원하는 결과물을 만들어내는 사람들의 가치가 올라가기 시작했었고, 잘 정돈된 프롬프트는 그 자체만으로도 가치있는 자산이 되었어요.

현재, Agentic AI 시기

그러면 지금 우리는 어떻게 일하고 있나요? 이제 우리는 복사 붙혀넣기 조차 하지 않습니다. 단순히 해줘 라고 말하면 AI가 코드 생성부터 수정, 삭제까지 모두 직접해줍니다. 내가 아예 모르는 분야라고 하더라도 그냥 자연어로 해달라고 말하면 결과물이 나오는 시대가 되었죠.

그러면 이 때 우리에게 중요한 역량은 무엇일까요? 똑같이 세가지로 꼽아보았는데 뒤에서 한번 천천히 알아가봅시다.

첫번째 열쇠 : 효율성

여러분들은 베이직 코딩이 중요하다고 생각하시나요 아니면 바이브코딩이 중요하다고 생각하시나요? 여기서 제가 말하는 바이브코딩이란 직관과 느낌에 의존하여 기존의 엄밀한 논리나 설계 없이 AI의 도움을 받아 빠르게 코드를 구현하는 새로운 개발방식을 말한거에요.

이렇게 말하면 너무 안좋아 보이니까 한번 각각의 장단을 비교해보도록 합시다.

특성 비교표

구분	베이직 코딩	바이브 코딩
장점	• 체계적이고 논리적인 학습 가능 • 견고한 기초 실력 구축 • 코드 품질과 유지보수성 향상	• 빠른 아이디어 구현 가능 • 반복 작업 최소화 • 초기 진입 장벽이 낮음
단점	• 높은 러닝커브 • 느린 작업 속도 • 자유도 부족	• 유지보수성 부족 • 스파게티 코드 구조로 관리 어려움 • 코드 확장성 부족

혹시 이 표를 보고 뭔가 느껴지지 않으시나요? 서로 각각 반대되는 장단점을 가지고 있는 것 같아요. 그래서 저는

• 베이직 코딩의 약점 (느린 속도, 자유도 부족) → 바이브 코딩의 강점으로 보완
• 바이브 코딩의 약점 (코드 품질, 확장성 부족) → 베이직 코딩의 강점으로 보완

할 수 있을 것 같았어요. 어떻게보면 뻔할수도있지만 베이직코딩과 바이브코딩 두가지 무기를 다 가지고 있으면 더 좋은거죠.

그러면 그냥 관심있는 분야 하나 정해서 베이직하게 공부 좀 하다가 바이브코딩 역량을 단순히 기르기만하면 살아남을 수 있을까요? 저는 조금 더 깊게 한번 고민해봤어요. 그래서 저는 순차적으로

• AI를 사용하지 못하는 사람
• AI를 활용하지 못하는 사람
• AI로 자동화하지 못하는 사람

이 대체될거라고 생각해요. 지금부터 그 이유를 한번 알아봅시다.

AI를 사용하지 못하는 사람

저는 가장 먼저 대체 될 그룹은 AI 사용을 거부하거나, AI를 사용하지 못하는 사람이 대체될거라고 생각해요. 지금 이제 주변을 돌아보면 비전공자이시거나 주니어 개발자이신분들도 AI를 활용해서 빠르게 코드를 뽑고, 새로운 분야에 빠르게 적응하고 있어요. 하지만 AI를 사용하지 않으면 같은 작업을 하더라도 생산성 측명에서 극명한 차이가 나기에 저는 가장 먼저 AI를 사용하지 못하는 사람들이 대체될거라고 생각해요.

AI를 활용하지 못하는 사람

그러면 AI를 사용하지 못하는 사람이 다 대체되면 어떤 사람이 대체될까요? 저는 AI를 단순히 사용하기만 하고 활용하지 못하는 사람이 대체될거라고 생각해요. 예를들어 내가 프론트엔드 개발을 해야하는데 lovable이나 v0등 프론트엔드 UI작업에 특화된 AI를 사용하지 않는다거나 AI와 AI를 유기적으로 연결하는 기술인 mcp를 사용하지 못하고 하나의 AI만 활용해서 여러 작업을 수행하는 사람이 대체될거라고 생각해요. 왜냐하면 각자 특화된 영역이 있는 AI를 사용하지 않으면 같은 작업을 지시해도 나오는 퀄리티가 다르다고 생각하고 mcp를 사용하지 않으면 전체적인 맥락 공유가 안되기때문에 최적화에서 수준차이가 날거라고 생각해요. 물론 mcp를 사용해야 작업이 더 빠르기도 하구요. 프론트엔드 코드를 맥락으로 넘겨주면 간단하게 DB설계를 할 수도 있고, 피그마를 연동해서 이미 나온 디자인을 빠르게 만들수도 있잖아요? 이런 다양한 매체를 유기적으로 연결하는 능력이 점점 중요해질거에요.

AI로 자동화하지 못하는 사람

마지막으로 AI를 모두가 활용하는 시대에서 저는 모든 과정을 자신이 직접 AI에 지시하여 수행하고 반복적인 작업을 자동화 하지 못하는 사람이 대체될거라고 생각해요. n8n make zapier agentica 등 다양한 툴을 사용하여 반복적인 작업을 자동화하면 장기적으로 봤을 때 정말 많은 시간이 단축돼요. 회의록을 자동화하고 슬랙에 공유하는 하나의 흐름을 자동화 한다거나 코드리뷰나 PR을 자동화 할 수도 있고, 배포를 자동화 할 수 있겠죠. 이런 반복적으로 수행하는 작업들을 자동화 하는것이 저는 점점 중요해질거라고 생각해요.

결국엔 효율성

이게 어떻게 보면 사실 다 같은 이야기에요. 시간이 지나면 지날수록 사람들의 AI 활용 능력은 점점 올라갈거에요. 그런 어떤 시점에서 평균 이하의 효율성을 보이는 사람들은 자연스럽게 경쟁력을 잃게 되겠죠. 그래서 저는 바이브 코딩 시대에서 살아남기 위해 갖춰야할 첫번째 역량을 효율이라고 생각했어요.

두번째 열쇠 : 설계력

그러면 어떻게 해야할까요? 계속 효율성만 높혀서 코드 짜는 능력만 기르면 되는걸까요? 저는 보다 근본적인 접근이 필요하다고 생각했어요. 다들 개발자의 본질이 무엇이라고 생각하시나요? 저는 개발자의 본질은 코드 짜는 능력이 아니라 문제 해결 능력이라고 생각해요. 단순 코드만 짜는것이 아니라 어떤 문제를 정의하고 그 문제를 해결하는 그 과정을 설계하는게 정말 중요하잖아요. 그래서 저는 우리가 단순한 코더가 아닌 개발자가 되어야한다고 저는 생각했어요. 그러면 개발자를 어떻게 정의내리면 좋을까요?

저는 개발자를 비즈니스 기획에 공감하고 진짜 문제를 정의하며 최적의 솔루션을 설계하는 사람이라고 정의를 해봤어요. 물론 이렇게 말하면 정말 어렵고 멀어보이지만 개발자가 되기로 마음먹으신 지금부터 그렇게 어렵지만은 아닌 길이 될거에요. 그러면 제가 정의내린 개발자가 되려면 어떻게 해야할까요? 지금부터 같이 알아봅시다.

항상 왜를 생각하자

아까 개발자의 정의에서 비즈니스에 공감해야한다라고 했었잖아요? 저는 비즈니스에 공감하려면 가장 먼저 “왜”를 생각해야한다고 생각했어요. 단순히 시키는 일만 하는것이 아니라 이게 왜 필요한지, 왜 이 스택을 선택하고, 왜 이 페이지가 필요한지, 어떠한 하나의 작업을 수행할때에도 사람들은 결과에만 초점을 두는 성향이 있어요. 이런걸 만들어야겠다. 아니면 이렇게 만들어야겠다라고 그 끝에 초점을 두는데 저는 끝보다 처음에 있는 그 의도와 원인에 집중해야한다고 생각해요. 어떠한 개발 방식을 적용할 때에도 왜 이런 방식을 적용하는지를 생각하고 에러가 나도 서비스 이탈율이 높아져도 항상 끝에있는 그 결과보단 시작에 있는 그 의도와 원인에 집중해서 왜를 생각하고 의도에 공감해서 솔루션을 설계했으면 좋겠어요.

빠른 정보습득력을 갖추자

그런데 이제 항상 새로운 정보가 빠르게 나오는 시대가 되었다보니 제가 생각하는 최적의 솔루션이 가장 좋은게 아닐때가 종종 있더라구요. 그래서 저는 빠른 정보 습득력이 중요한 것 같아요. 뉴스레터를 읽는다거나, 벨로그 티스토리 링크드인등등 SNS도 좋고 오픈 채팅방도 좋은 것 같아요. 방식에 상관없이 빠르게 정보를 습득 할 수 있으면 되는데 저는 단순히 아 이런게 있구나 알고 끝나는게 아니라 한번씩 찍먹이라도 해보셨으면 좋겠어요. 물론 직접 심도있게 공부를 할 수 있으면 좋겠지만 다들 바쁘시잖아요? 그래서 AI를 활용해서 한번 구현 정도만 해보셨으면 좋겠는데 이 때 중요한게 저는

명확한 지시능력을 가지자

명확한 지시 능력이라고 생각해요. AI랑 일을해도, 사람이랑 일을 해도 정말 중요한 역량이라고 생각하는데 이런 명확한 지시 능력이라는게 또 바로 생기는게 아니잖아요? 저는 이러한 명확한 지시 능력은 컴퓨팅적 사고 능력과 목표에 대한 이해도에서 찾아온다고 생각해요. 이게 어떤 얘기냐면 우리는 어떠한 큰 목표를 받았을 때 바로 이해하지 못해요. 우리만 그런게 아니라 모두가 그렇죠.

구체적인 예시를 하나 들어보자면 누가 갑자기 찾아와서 여러분한테 레고로 부가티를 만들어와라! 라고 하면 여러분들은 어떠실 것 같나요? 아마 대부분의 사람들은 당황하실거에요. 당황하고 또 막막하겠죠.. 아마 시도를 해도 내가 만든 부가티와 지시했던 사람이 생각하는 부가티가 다를수도 있을 것 같아요.

하지만 그 때 이 부가티를 만들기 위한 과정을 잘게잘게 나눠서 설명서처럼 지시를 하면 어떨까요? 지시 받을 땐 인지를 하지 못하겠지만 결국엔 부가티가 나오는 결과는 똑같을거에요. 근데 처음부터 부가티를 지시하는 것과 두 블럭을 결합해라 라는 지시를 받은 두 사람의 완성도는 차이가 나겠죠? 이런게 바로 명확한 지시이고, 이 능력이 정말 중요해지고 있다고 생각해요.

설계력이 정말 중요하다

여기까지가 이제 코더를 벗어나 개발자가 되는 이야기였는데 그래서 저는 바이브코딩 시대에 살아남는 두번째 역량을 설계력이라고 생각해요.

근데 이건 다 할 수 있는거 아닌가요?

그러면 설계력과 효율성만 있으면 되는걸까요? 저는 결국에 나만의 색이 있어야된다고 생각했어요. 사실 설계력과 효율성은 누구나 가질 수 있는거잖아요? 요새 PM들은 직접 필요한 데이터를 꺼내서 보고, 마케터들도 수치에 기반하는 Data Driven 마케팅을 하더라구요. 점점 프론트엔드 개발자들은 UX에 중점을 두기 시작한 것 처럼요. 여러분들도 여러분만의 개성이나 특색을 한번 생각해보시면 좋을 것 같아요.

잘하는 개발자가 되자

이 생각을 하는 당시에 저는 그냥 막연하게 잘하는 개발자가되자였어요. 잘하는 개발자라는게 충분히 저의 색이 될 수 있을 것 같았거든요. 그러면 잘하는 개발자는 무엇일까요? 단순히 코드를 잘 짜는 사람? 항상 다음을 생각하는 사람? 타 직군의 이해도까지 갖춘 사람? 풀스택 개발자? 사람마다 생각은 다 다르겠지만 저는 개발을 시작하기 전에 한번 머리속으로 처음부터 끝까지 시뮬레이션을 돌려보는 사람이라고 생각해요. 이게 시뮬레이션이라고 단순히 이렇게 해야지~ 하는게 아니라 아까 말한 왜부터 시작해서 설명서를 만드는 과정까지를 한번 깊게 생각해보는거에요. 이런 능력은 저는 경험에서 기반한다고 생각해요. 여러분들도 한번 해본 일을 다시 할 땐 머리속에서 했던 기억들이 막 떠오르면서 보다 쉽게 하시잖아요? 근데 이렇게 하면 작업적인 측면에서는 효율이 오르겠지만 타 부서와의 협력에서나 다른 기타사유로 문제가 생길 수 있겠죠. 그래서 언제까지 이걸 하고, 언제 이 부서에 문의를 하고 이런걸 한번 생각해보는게 중요한 것 같아요. 어떻게하면 그럴 수 있을까요?

많은 경험을 내것으로 만들자

이런 시뮬레이션 능력은 경험에서 기반한다고 했잖아요? 그래서 저는 많은 경험을 내것으로 만드는게 중요하다고 생각했어요. 저는 그냥 경험을 해보는것과 내것으로 만드는것은 정말 큰 차이가 있다고 생각하는대요. 여러분들도 아마 분명 한번 했던일인데 다시 했을 때 검색을 안하면 잘 생각 안나셨던 때가 한번쯤 있을거에요. 비단 개발뿐만 아니라 여러 분야에서요. 이런게 저는 경험을 내것으로 만든것과 아닌것의 차이라고 생각해요. 그러면 어떻게 하면 경험을 내것으로 만들 수 있을까요?

저는 단순히 단순히 프로젝트를 하고 아~ 너무 수고 많았다 하고 넘기는게 아니라 프로젝트에서 트러블슈팅 로그를 정말 매번 쓰고 인상 깊었던 부분 아쉬웠던 부분 추후 개선할 부분을 정말 하나하나 생각해보면서 회고하는 이 다시 돌아보는 과정의 유무의 차이라고 저는 생각을 해요. 물론 저도 그렇고 많은 분들이 그렇겠지만 밥 다 먹고 바로 설거지하는게 정말 귀찮잖아요. 밥 먹었으면 배부르니까 좀 누워서 쉬고싶고.. 업무나 프로젝트도 다 똑같다고 생각해요. 하나 끝내면 쉬고싶을수도 있고 다른 업무가 또 있을수도 있고, 하나 끝나고 다시 돌아보기가 정말 쉽지 않아요. 하지만 이게 한번 두번 하다보면 습관이 될거고 이런게 습관이 되다보면 나중에 정말 큰 도움이 될거에요. 어떤 도움이 될 수 있을까요?

혁신적 사고와 깊은 통찰력을 가지자

저는 어느새부턴가 같은 작업을 하는데 혁신적 사고와 깊은 통찰력이 생길거라고 생각해요. 이게 되게 추상적인 단어지만 같은 작업을 하더라도 어떤 차별점이 생긴다는 거죠. 몇가지 예를 한번 들어볼게요.

ToDO 서비스 이야기

만약에 ToDo 서비스를 만든다고 생각해봅시다. 아마 많은분들이 투두 인덱스를 정수로 많이 관리하실거에요 01234 뭐 이런식으로요. 그러면 이제 투두를 만들 때 인덱스의 순서를 서로 바꿔봅시다. 3번을 2번 위로 옮긴다고 생각해볼게요. 그러면 3번이 2번이 되고 그 뒤로 숫자가 하나씩 다 밀리겠죠? 근데 이게 인덱스 수가 적으면 상관이 없는데 만약 인덱스가 10만개라면 어떻게 될까요? 이런 부분 하나하나가 저는 성능 저하를 일으킨다고 생각을 해요. 근데 여기서 이제 혁신적 사고를 가지신분들은 인덱스 관리를 실수로 하시더라구요. 단순히 정수로 가져가서 10만번의 변동을 일으키는게 아니라 단순히 인덱스를 1/2해서 삽입해서 한번의 변동만으로 관리가 가능하게 만드는거죠.

게시판 서비스 이야기

또 하나의 예시를 들어볼게요. 만약에 게시판 서비스를 만든다고 생각해봅시다. 우리가 만약에 게시판 서비스를 다 만들었는데 포스트중에서 무언가 악의적인 글이 있을수도 있겠죠? 그러면 사람들은 아마 신고를 할거에요.

근데 만약 그 악의적인 글을 쓴 사람이 제제를 받기 전에 그 글을 지워버리면 어떻게 될까요? 그래서 보통 우리는 이 삭제라는 기능을 아예 DB에서 지우는게 아니라 단순 프론트에서 가리는 소프트삭제로 구현이 되어있어요.

근데 만약 이 악의적인 글을 쓴 유저가 개발자라 이 소프트 삭제를 고려하고 글을 쓴 뒤에 수정하고 지워버리면 어떻게 될까요? 아마 뭐 신고시점 이후에 수정 삭제를 막는다거나 하는 하드한 방법부터 AI로 검열을 자동화하고, 아니면 로그를 남기고 하는 다양한 방법이 있을텐대 여기서 아마 깊은 통찰을 가지신분들은 이미 자신의 서비스에 가장 핏한 방법을 선택해서 적용을 해두셨을 거에요. 근데 이런 다양한 경험을 우리가 언제 다 해보겠어요. 우리 지금 계속 하고있는 일만 해도 바쁜데 말이에요.

다양한 사람을 만나자

그래서 저는 중요한게 또 다양한 사람을 만나는게 중요하다고 생각해요. 이게 비단 개발자만 만나는게 아니라 다양한 직군에 있는 사람을 다 만나보면 정말 생각지도 못했던 인사이트를 얻을 때가 정말 많은 것 같아요. 그리고 또 좋은건 우리는 개발자잖아요? 그래서 우리의 활발한 커피챗 문화를 잘 활용해서 여러분들이 가고 싶은 회사나 포지션에 계신분들의 댜양한 경험을 듣고 그 경험을 여러분의 것으로 만드셨으면 좋겠습니다.

개발 외적인 색을 갖추자

쉽게 말하고 잘 듣자

그리고 또 저는 저만의 또 다른 색을 비 개발적인 분야로 가져갔어요. 좀 여러가지 색을 가지려고 노력을 했는데 그 중 하나는 쉽게 말하고, 잘 듣는 능력이에요. 우리는 일을 결국엔 사람과 하잖아요? 그래서 저는 함께 일하고 싶은 사람이 되기 위해 정말 많은 노력을 했어요. 이건 그중에 하나인데 우리가 보통 회의를 하면 다양한 직군이 모일 때가 있잖아요? 개발자만 모인 회의라고 하더라도 포지션이 다를 수 도 있구요. 이럴 때 정말 쉽게 말하는 능력이 중요하다고 생각해요.

아마 다들 이런말 한번쯤 들어보셨을거에요. 혹시 이 기능 추가 가능할까요? 그 때 우리는 정말 안될수도 있어요. 근데 하지만 우리가 단순히 No 라고 했을 때 그 사람은 이게 정말 기능적으로 안되는건지, 일정 때문에 안되는건지, 이 사람이 하기싫어서 안된다고 하는건지 알 수 없어요. 그래서 쉽게 설명하고 단지 No, Yes가 아니라 No but, Yes but을 말할 수 있었으면 좋겠다고 생각했어요.

그리고 저는 또 잘 듣는 능력이 중요하다고 생각했어요. 우리는 보통 사람과 대화할 때 그냥 잘 이해가 안됐는데도 불구하고 고개를 끄덕이며 잘 들은 척 할 때가 있어요. 근데 저는 함께 일하는 상황이라면 서로 바라보는 방향이 같아야 안 무너진다고 생각을 해요. 근데 서로 바라보는 방향이 같으려면 저사람의 방향이 무엇인지 알아야겠죠? 이 때 중요한게 바로 잘 듣기에요. 그 사람이 하는 말을 잘 듣고 그 사람이 원하는게 무엇인지를 잘 캐치해서 이후에 풀어나가면 일하기가 훨씬 수월해질거라고 저는 생각해요.

뱉은 말은 지킬 수 있는 사람이 되자

그리고 저는 또 하나 중요한 색으로 뱉은 말은 지킬 수 있는 사람이 되자라는걸 선택했어요. 아마 여러분들도 많이 들어보셨을텐대 이거 2주안에 가능할까요? 혹은 이거 만드시는데 얼마나 걸릴 거 같으신가요?라는 말을 다들 많이 들어보셨을거에요. 근데 이 때 대부분의 사람들은 깊게 생각하지 않고 그냥 넓게 생각해보고 대략적으로 대답을 하잖아요? 근데 그렇게 하다보면 언젠가는 하나 큰 에러가 나와서 해결하려고 전전긍긍했지만 그 말을 못 지킬수도 있구요. 저는 그래서 그러지 않기 위해 메타인지를 높히려고 최대한 노력을 했어요. 내가 하루에 얼마나 일을 할 수 있고, 내가 이 분야에 얼마나 이해도가 있고, 얼마나 걸릴지를 알기위해 많은 시도도 해보고 경험도 쌓았죠. 그래서 저는 여태까지 먼저 얼마나 걸릴 것 같다고 말을하고 단 한번도 일에서 마감을 못 지킨 적이 없어요.

영역을 구축하자

그래서 저는 이러한 저의 색과 앞서 말했던 두가지 요소들로 대체되지 않는 저만의 영역을 구축했어요. 앞으로는 어떻게 될 지 또 생각해봐야겠지만 저는 현재로썬 제가 대체되지 않을거라고 확신해요. 여러분들도 꼭 여러분들만의 색을 찾으셔서 대체되지 않는 이 영역을 구축하셨으면 좋겠습니다.

취업 이야기

근데 아마 제 세션이 이런 이야기라고 생각하지 못하신 분들도 있을 것 같아서 취업을 위한 몇가지 소소한 저만의 팁을 또 조금 준비했어요.

포트폴리오는 그때그때 정리하자

여러분들이 아마 취업을 위해서 무언가 많은 활동을 하실 거 같아요. 아마 많은 걸 하고 계실텐대 저는 포트폴리오를 그때그때 정리를 해야한다고 생각해요. 물론 프로젝트가 끝나고 회고를 작성하며 이게 좋았고 이게 아쉬웠고 이걸 개선하면 되겠다라고 기록을 하는것도 좋고 매번 트러블슈팅로그를 작성하는 방법도 정말 좋지만. 저는 나중가서 가장 기억이 안나는건 일의 흐름이였어요. 내가 왜 이걸 하려고 했고 왜 이 스택을 선택했고, 왜 이 패키지를 선택했고, 그래서 초반엔 어땠는데 어떤 변화를 만들었다라는 이 하나의 의식의 흐름을 그때그때 정리해두시면 나중에 이력서나 자소서를 작성하실 때 정말 도움이 될거에요.

단점을 장점으로 승화시키자

그리고 이건 정말 어렵겠지만 단점을 한번 장점으로 승화시켜보는것도 좋을 것 같아요. 저는 사실 개발자로 보면 단점이 좀 명확하게 보이는 사람이였어요. 저는 하나를 깊게 공부하기보단 해보고싶은걸 하는 사람인데, 그래서 보통의 분들처럼 하나의 분야에 전문성이 있지않고 전반적인 플랫폼 분야에 대한 경험이 있었어요. 저는 8개 플랫폼에서 개발을 해왔어요. 안드로이드, iOS, WearOS, Web, 임베디드, AI, Windows, macOS까지 총 8개 플랫폼을 찍먹해본 사람인데 일반적인 IT 기업을 지원하기엔 뭔가 내세울게 없는 사람이였어요. 그러던 중 어쩌다가 연구원 채용 공고를 보게 됐는데 연구원은 과제를 따오는 구조로 굴러가요. 보통 과제를 따오는 형식이 많고, 과제는 그 과제를 잘 수행할 수 있는 사람이 있는 곳에 과제를 주죠. 저는 그래서 다양한 분야에서의 제 경험을 연구원이라는 한 기업 문화의 잘 포장을 해서 지원을 했고, 운좋게 붙어서 열심히 다니고 있어요.

내가 개발자를 생각하는 방식

물론 저는 제 이야기가 정말 특수한 케이스고 다양한 사람에게 핏한 얘기는 아니라는걸 알아요. 개발자로 살아남는다기엔 정말 다양한 사람이 있고, 다양한 상황과 목표가 있죠. 그래서 저는 마지막으로 제가 생각하고 성장했던 방식을 공유드리려고 해요.

대부분의 사람들이 말하길 개발자는 평생 공부하는 사람이라고 하잖아요? 서로가 서로의 밥그릇을 뺏기도 하고, 계속 새로운 기술이 나오면서 그에 적응하려면 정말 멈추지 않고 공부를 해야하죠. 그래서 저는 이왕 내가 평생 공부를 할거면 좀 목표도 크게 가져보고 효율적으로 공부를 하자라고 생각했어요.

큰 목표를 작게 쪼개자

앞서 말했듯 큰 목표를 그대로 두면 사람은 정말 쉽게 지치더라구요. 저는 그래서 이 목표들을 정말 잘게 쪼갰어요. 전 예전에 30살 전에 GDE나 Microsoft MVP를 한번 해보자라는 목표가 있었어요. 그래서 막 찾아봤더니 커뮤니티 기여, 기술에 대한 이해도, 소통 능력, 추천 등 다양한게 정말 많이 필요했는데 저는 정말 잘게잘게 이 목표를 이루기 위한 과정을 쪼개 왔어요. 커뮤니티 기여는 오픈소스 기여나 컨퍼런스 연사로, 기술에 대한 이해도는 패키지 개발이나 블로그 발행으로, 소통 능력과 추천은 링크드인과 같은 SNS에 열심히 퍼스널 브랜딩 하는것으로 크게 쪼갰고 거기서도 하루에 이만큼 공부하고 그거에 맞는 오픈소스 찾고 연사 주제를 아카이빙하고 책 이만큼 읽고 뭐 이런식으로 정말 소소하게 쪼갰어요.

이게 제 이번 5, 6월 캘린더인데 저는 매번 거의 한달에 5~60개 이상의 task를 수행하고 있어요. 정말 하나하나 보면 별거 아니지만 그렇기에 더 쉽게 수행 할 수 있고, 여태까지 해온게 아쉬워서라도 멈추지 않게 되더라구요. 물론 지금은 다른 목표를 가지고 있지만 이 때부터 계속 해오던게 습관이 되어 개발자로도 계속 잘 성장하고 있기도 하구요.

성장속도를 단축시키자

그리고 저는 또 요새가 예전보다 성장하기가 정말 쉽다고 생각해요. 예전엔 대용량 트래픽 처리 라는 용어를 알게되는것도 어려웠고 알게 되더라도 이걸 공부하고 적용하기 힘들었어요. 하지만 요새는 AI에게 백엔드 개발자 되려면 어떻게 해야돼? 우대 사항은 뭐야? 라고 하면 대용량 트래픽 처리라는 용어가 바로 나오고 또 뭐냐고 물어보면 잘 알려주고 시키면 적용을 해주더라구요. 물론 나의 것으로 만드는 시간은 들어가겠지만 정말 배우는게 쉬워졌어요. 여러분들도 꼭 AI를 잘 활용하셔서 나만의 시니어 멘토를 하나 곁에 두고 잘 활용하셨으면 좋겠습니다.

마치며

그래서 이제 얘기를 마쳐볼게요. 오늘 얘기를 정리하자면 이렇습니다. 능동적인 사람이 됩시다. 우리는 이제 수동적이여선 살아남을 수 없어요. 내가 어떻게 살아남아야할지를 스스로 고민하고 실천해야합니다. 그리고 그러려면 다양한 경험을 내것으로 만들어야하고, 다양한 사람을 만나야 합니다. 이 글을 읽고계신 여러분들도 다양한 행사, 네트워킹 파티에 참석하셔서 다양한 사람들과 얘기 나눠보시면 좋을 것 같아요.

후기 및 소개

저는 바이브코딩 시대에 살아남는 개발자가 되는 방법이라는 세션을 발표한 장영하라고합니다. 커뮤니티에서는 마이라는 닉네임으로 열심히 활동하고있어요.

지금은 한국전자기술연구원이라는 연구원에서 근무중에 있고, 대학생들도 이런 인사이트를 쉽게 얻을 수 있게 하기 위해 GDGoC Gachon이라는 대학생 개발자 커뮤니티 가천대 지부의 운영진으로 활동하고 있습니다. 이 글이 유익했다면 깃허브 팔로우 한번씩 부탁드리고, 제가 궁금하시거나 궁금하신점이 있으셨다면 링크드인으로 편하게 질문해주시면 최선을 다해 답변 드리도록 하겠습니다.

발표를 준비할 땐 정말 힘들었었고 행사 때 정말 많은분들이 뒤에 서가시면서까지 들어주셔서 많은 긴장이 됐지만, 발표가 끝난 뒤에 다들 잘 들었다고 해주시고 또 질문도 많이 해주셔서 정말 좋은 추억으로 남는 것 같습니다. 다음에 또 좋은 주제로 다시 찾아뵐 수 있었으면 좋겠습니다. 좋은 행사 준비해주신 GDG Incheon & GDG Songdo 감사합니다.