![[현직자 인사이트] 막막한 개발자 취업, 이력서보다 ‘이것’ 먼저 설계하세요! - 오태은 님](https://image.inblog.dev?url=https%3A%2F%2Fsource.inblog.dev%2Ffeatured_image%2F2025-05-13T05%3A24%3A57.896Z-97852924-e678-4cca-b972-c14d3b76e2cc&w=2048&q=75)
[현직자 인사이트] 막막한 개발자 취업, 이력서보다 ‘이것’ 먼저 설계하세요! - 오태은 님
안녕하세요, 코드잇 스프린트입니다. ⚡️
개발자 취업을 준비하는 분들과 이야기를 나누다 보면, 비슷한 고민을 자주 듣게 됩니다.
“이력서와 포트폴리오는 어떻게 구성해야 하나요?”, “블로그도 운영해야 한다던데, 어떻게 해야 할지 모르겠어요.”, “프로젝트에서 어떤 부분을 어필해야 할까요?”
누구나 한 번쯤 떠올릴 법한 고민들이죠.
개발자 취준생 여러분의 고민을 해결해 드리기 위해, 2025 스프린터의 봄 컨퍼런스에 오태은 연사님을 모셨습니다.
연사 프로필
- 이름: 오태은
- 현직: 프론트엔드 개발자 @ 채널코퍼레이션
- 이력: 우아한테크코스, NextStep 코드리뷰어 활동 경력
오태은 연사님은 이력서나 포트폴리오처럼 ‘어떻게 보여줄까’보다,
그 전에 ‘무엇을 갖추고 설계해야 할지’를 먼저 짚어주셨어요.
또 각자의 강점에 따라 어떤 방식으로 표현하면 좋을지도 함께 이야기해 주셨죠.
이 글을 통해, 현직 개발자 연사님의 인사이트를 직접 들어보세요!
들어가며
이력서 멘토링을 하다 보면 비슷한 질문들을 자주 듣습니다.
“이력서는 어떻게 써야 할까요?”, “프로젝트를 더 해야 할까요?”, “블로그나 포트폴리오는 필수인가요?”
취업을 준비하는 과정에서 누구나 한 번쯤 떠올리는 고민들입니다. 이 글은 그런 고민들 사이에서 제가 깨달은 작은 인사이트를 나누기 위해 쓰였습니다. 다만, 먼저 분명히 해두고 싶습니다. 제가 전하는 이야기는 정답이 아닙니다. 업계 전체를 대변하지도, 모든 상황을 아우르지도 못합니다. 그저 한 사람의 경험과 관점일 뿐이니, “이런 시각도 있구나” 정도로 가볍게 읽어 주세요. 필요한 부분만 골라 참고하시고, 나머지는 편하게 흘려보내셔도 좋습니다.
취업 준비를 개발처럼 생각해 보기
본격적으로 이야기를 시작하기 전에, 개발 얘기 하나를 먼저 해보려 합니다. 어플리케이션을 하나 만든다고 가정해 볼까요? 가장 단순한 형태로 아키텍처를 구성한다면 어떤 모습일까요? 물론 여러 방식이 있겠지만, 저는 보통 두 개의 덩어리를 떠올립니다. 하나는 핵심 로직을 담당하는 도메인(Domain), 다른 하나는 사용자와 상호작용하는 뷰(View) 입니다. 아주 단순하게 추상화하면, 프로그램은 입력을 받고 처리하여 결과를 출력하는 흐름을 가집니다. 입출력은 뷰가 담당하고, 그 사이에서 실제로 일을 하는 부분은 도메인이 맡습니다. 관심사를 분리해 관리하는 기본적인 구조이죠.
이 관점을 현실에도 적용할 수 있을 것 같습니다. 취업을 준비하든, 개발 공부를 하든, 또는 어떤 결과물을 만들든, 결국 모든 활동은 핵심 내용(도메인)과 그것을 전달하는 방식(뷰)으로 구분할 수 있습니다. 이 글에서도 같은 관점을 유지하려 합니다. 개발자로서 갖춰야 할 핵심 도메인은 무엇인지 먼저 살펴보고, 그 도메인을 어떻게 효과적으로 드러낼 수 있을지, 즉 도메인에 의존하는 뷰를 어떻게 설계할 것인지를 이어서 이야기해 보겠습니다.
.jpg%3Ftable%3Dblock%26id%3D1ee6fd22-8e8d-8002-8a20-f3dbea4d3e66%26cache%3Dv2&w=1920&q=75)
무엇을 보여줄지보다, 무엇을 갖추었는지가 먼저다
취업을 준비할 때 많은 사람들이 이력서, 포트폴리오, 깃허브, 블로그 같은 것부터 고민합니다. 어떻게 써야 할지, 무엇을 더 준비해야 할지, 어떤 형식이 좋은지 같은 문제들입니다. 이 모든 것은 결국 뷰(View)에 해당합니다. 내가 가진 것을 밖으로 보여주는 방식입니다.
하지만 보여주는 방식보다 먼저 고민해야 할 것은 따로 있습니다. '나는 어떤 개발자인가?'라는 질문에 대한 답, 즉 도메인(Domain)입니다. 기본적인 지식 체계, 구현 능력, 문제 해결 경험처럼 실질적인 역량이 뒷받침되지 않는다면 어떤 뷰를 선택하든 설득력을 갖기 어렵습니다.
물론 외형적인 준비가 전혀 필요 없다는 뜻은 아닙니다. 하지만 기본이 갖추어지지 않은 상태에서 겉을 꾸미는 데 집중하면, 결국 어느 순간 한계가 드러나게 됩니다. 좋은 뷰는 탄탄한 도메인 위에서만 제대로 기능할 수 있습니다. 그래서 취업 준비를 시작할 때 가장 먼저 해야 할 일은 자신의 도메인을 점검하고 다지는 것입니다.
다음 장에서는 이 도메인을 구성하는 가장 기본적인 토대, 즉 개발자로서 갖춰야 할 핵심 역량이 무엇인지 살펴보겠습니다.
기본기에 머무르지 않고 성장하려면
개발자로 일하기 위해 기본적인 역량을 갖추는 것은 필수입니다. 자료구조와 알고리즘 같은 컴퓨터 과학 지식, 구현 능력, 프레임워크와 라이브러리 사용법, Git과 인프라에 대한 이해 등은 일을 시작할 수 있는 기본 조건입니다. 하지만 기본기를 갖췄다고 해서 준비가 끝난 것은 아닙니다. 기본기는 출발선일 뿐, 그 위에서 무엇을 할 수 있는지가 진짜 실력을 결정합니다.
개발자로 성장하기 위해서는 기본기를 단순히 쌓는 데서 멈추지 않고, 그것을 문제를 해결하는 데 어떻게 활용할지를 고민해야 합니다. 좋은 개발자는 단순히 많은 도구를 아는 사람이 아니라, 적절한 도구를 골라 문제를 해결하고, 그 과정을 통해 더 나은 방법을 찾아가는 사람입니다.
문제를 잘 푼다는 것은 다음의 과정을 충실히 밟아가는 것을 의미합니다.
문제 정의
무엇이 문제인지, 그리고 왜 그것이 문제인지를 명확히 이해해야 합니다. 문제를 정확하게 짚지 못하면 어떤 해결 방법도 효과를 발휘하기 어렵습니다. 때로는 주어진 문제가 표면적인 현상에 불과하고, 진짜 문제는 그 이면에 숨어 있는 경우도 있습니다. 문제를 정의하는 단계에서는 관찰과 질문을 통해 문제의 본질을 파악하는 능력이 필요합니다.
해결 방법 제안
문제를 정확히 정의했다면, 그에 대한 해결 방법을 찾아야 합니다. 중요한 것은 한 가지 방법만 생각하는 것이 아니라 가능한 여러 옵션을 열어두는 것입니다. 각각의 방법이 가지는 장단점을 비교하고, 현재 상황에서 가장 합리적인 선택이 무엇인지 판단하는 과정이 필요합니다. 기술적인 고려뿐 아니라, 시간, 자원, 유지보수성 같은 현실적인 요소들도 함께 검토해야 합니다.
결과 도출
제안한 방법이 아무리 훌륭해 보여도, 실제로 문제를 해결해내지 못하면 의미가 없습니다. 실행에 옮기고, 예상한 결과를 얻을 수 있어야 합니다. 이 과정에서는 계획했던 방법을 충실히 따르는 것도 중요하지만, 상황에 따라 유연하게 대처하는 능력도 필요합니다.
회고 및 확장
문제를 해결한 뒤에는 과정을 돌아보아야 합니다. 선택한 방법이 충분히 효과적이었는지, 더 나은 방법은 없었는지 검토해야 합니다. 또한 지금 해결한 문제가 더 넓은 범위의 문제로 확장되었을 때도 여전히 유효한 접근법인지 고민해 볼 필요가 있습니다. 회고는 단순한 반성이 아니라, 다음 문제를 더 잘 풀기 위한 준비입니다.
몰입의 흔적에서 강점을 발견하다
강점이란 무엇일까요? 우리는 종종 강점을 ‘남들보다 잘하는 것’이라고 생각합니다. 하지만 진짜 강점은, 단순한 비교에서 드러나지 않습니다. 오히려 어떤 문제를 만났을 때 스스로 깊이 빠져들고, 노력이라는 생각조차 없이 몰입하게 되는 순간에 모습을 드러냅니다.
강점은 크기가 아니라 방향입니다. 남보다 빠르게 잘하는가보다, 어디를 향해 자연스럽게 에너지를 쏟게 되는가가 더 중요합니다. 시간이 가는 줄도 모른 채 고민하고, 더 나은 답을 찾기 위해 스스로를 밀어붙였던 경험들. 강점은 그런 몰입의 흔적 속에 있습니다. 단순히 습득한 기술이 아니라, 스스로 의미를 느끼고 끝까지 파고들 수 있었던 경험을 통해, 우리는 자신만의 방향을 발견할 수 있습니다.
이를 위해 가장 좋은 방법은 프로젝트를 회고하는 것입니다. 프로젝트를 돌아보며, 어떤 순간에 자연스럽게 몰입했는지를 떠올려야 합니다. 어떤 이슈를 다룰 때 더 깊이 파고들었는지, 어떤 종류의 문제를 만났을 때 시간이 가는 줄 모르고 몰두했는지, 그런 흔적을 찾아야 합니다.
예를 들어 어떤 사람은 시스템이 어떻게 작동하는지를 깊이 파고들 때 몰입합니다. 또 어떤 사람은 사용자 경험을 세심하게 다듬을 때 에너지를 얻습니다. 누군가는 팀 내 커뮤니케이션과 협업을 원활하게 만드는 일에 자연스럽게 관심을 갖기도 합니다.
이런 몰입의 흔적이 곧 나만의 강점을 형성합니다. 강점을 찾는다는 것은 자신이 가진 역량을 객관적으로 평가하는 것 이상입니다. 앞으로 어떤 문제를 풀어 나갈 때 더 큰 시너지를 낼 수 있을지를 아는 일입니다.
표현은 수단이다: 도메인에 의존하는 뷰 설계
기본기와 문제 해결력, 그리고 몰입을 통해 발견한 강점까지. 여기까지가 도메인이라면, 이제는 이 도메인을 어떻게 드러낼지를 고민해야 합니다.
취업 준비를 하다 보면 "블로그를 써야 한다", "포트폴리오를 준비해야 한다" 같은 조언을 많이 듣습니다. 이런 조언이 틀렸다고 생각하지는 않습니다. 하지만 모두에게 똑같이 적용되는 답은 아닐 수 있습니다. 무엇을 어떻게 보여줄지는 결국 내가 어떤 도메인을 가지고 있는지에 따라 달라져야 합니다. 표현 수단은 목적이 아니라, 내가 가진 것을 가장 설득력 있게 드러내기 위한 전략이어야 합니다.
.jpg%3Ftable%3Dblock%26id%3D1ee6fd22-8e8d-8076-ba7d-dce4adc5eb0d%26cache%3Dv2&w=1920&q=75)
예를 들어 봅시다.
✔️ 깊이 있는 기술 탐구가 나의 강점이라면, 이를 정리하고 풀어내는 블로그가 좋은 선택이 될 수 있습니다. 단순한 사용법이나 튜토리얼이 아니라, 특정 기술이 동작하는 원리를 파헤치거나, 라이브러리 내부 구조를 분석하는 글을 쓰는 식입니다. '어떤 기술을 쓸 줄 안다'를 넘어 '왜 그렇게 동작하는가'를 설명할 수 있다면, 블로그는 단순한 기록을 넘어 나의 사고 방식을 보여주는 강력한 창구가 됩니다.
✔️ 다양한 문제를 해결하고 프로젝트를 주도해본 경험이 강점이라면, 이를 구조화하여 보여주는 포트폴리오가 자연스럽습니다. 단순히 결과물을 나열하는 것이 아니라, 어떤 문제를 어떻게 정의했고, 어떤 대안을 고려했으며, 최종적으로 어떤 선택을 했는지를 프로젝트마다 스토리로 풀어낼 수 있어야 합니다. 결과물 자체보다, 그 결과물에 이르기까지의 사고 과정이 설득력을 만듭니다.
✔️ 협업과 커뮤니케이션에 강점을 가지고 있다면, 오픈소스 기여나 팀 프로젝트 경험을 적극적으로 드러낼 수 있습니다. 단순히 PR을 보냈다는 사실만이 아니라, 이슈를 정의하고 팀원들과 협업하여 해결까지 이끈 과정 전체를 기록하는 식입니다. 팀 내 소통이나 기여 과정을 구체적으로 보여주는 것은 혼자만 잘하는 개발자가 아니라 함께 문제를 푸는 개발자라는 인상을 남길 수 있습니다.
결국 무엇을 했느냐보다, 무엇을 드러내고자 했는지가 중요합니다. 단순히 블로그를 쓴다고 해서, 포트폴리오를 만든다고 해서 의미가 생기는 것은 아닙니다. 내가 가진 도메인을 가장 잘 드러낼 수 있는 방법을 고민하고, 그에 맞는 수단을 전략적으로 선택해야 합니다. 표현은 수단입니다. 도메인이 먼저이고, 표현은 그 도메인을 따라야 합니다.
마무리하며
취업을 준비하는 과정에서 우리는 자연스럽게 '무엇을 준비할까, 어떻게 보여줄까'를 고민하게 됩니다. 이 글은 그 고민을 다른 시선으로 바라보려는 작은 시도였습니다.
무엇을 보여줄지 고민하기 전에, 먼저 내가 어떤 개발자인지, 어떤 문제를 풀 수 있는 사람인지, 어디에 몰입할 수 있는지를 돌아봐야 합니다. 그리고 그것을 가장 잘 드러낼 수 있는 방법을 찾아 표현해야 합니다. 기본기는 출발선이고, 문제 해결력은 경쟁력이며, 강점은 방향입니다. 표현은 그 도메인을 드러내기 위한 수단입니다.
취업 준비라는 여정 속에서 중요한 것은, 남들이 요구하는 형식에 맞추는 것이 아니라, 나만의 도메인을 세우고 그것을 설득력 있게 드러내는 일입니다. 자신만의 본질을 다지고, 그 본질을 스스로의 언어로 표현해내는 과정이 결국 가장 흔들리지 않는 길이 될 것입니다.
코드잇 스프린트에서는 취준생 여러분의 고민을 해결할 현직자 네트워킹을 정기적으로 제공하고 있습니다. 네트워킹에 목말라 있다면? 스프린트에 지원해 보세요!
Share article
