2년 전 취업을 준비할 때 작성했던 자기소개서를 오랜만에 다시 펼쳐봤습니다.
그때는 문장을 500자씩 잘라 맞춤법 검사기에 넣어가며 고쳤던 기억이 아직도 생생한데, 이제는 LLM 덕분에 긴 글도 한 번에 점검할 수 있어서 그만큼 글을 손보는 데 드는 노력이 크게 줄었습니다.
예전에는 자기소개서 한 편을 쓰고 제출하는 데도 하루를 썼다면, 지금은 ‘1일 1지원서’도 충분히 가능할 것 같습니다. 기술이 어떤 방식으로 개발자를 도와주는지, 이런 사소한 순간에서도 확실히 느끼게 되네요.
자기소개서를 다시 쓰는 작업은 단순히 문장을 다듬는 것 이상의 의미가 있었습니다.
지난 2년간 제가 무엇을 배웠고, 어떻게 성장했는지 돌아보는 시간이었습니다.
그리고 앞으로 어떤 개발자가 되고 싶은지 다시 한번 정리할 수 있었습니다.
제가 경험한 내용을 바탕으로 솔직하게 적었습니다.
실무 경험이 없다보니 면접관이 보기엔 부족하게 느껴질 수도 있겠지만, 저는 제가 해내지 못한 일을 적고 싶지 않았습니다.
대신 제가 어떻게 문제를 해결했고, 그 과정에서 무엇을 배웠는지에 집중했습니다.
이 글이 저처럼 자기소개서를 고민하는 누군가에게 도움이 되길 바랍니다.
개발자가 된 계기
개발자로 일하는 친구가 어느 날 별찍기 문제를 내밀었습니다. 단순해 보이는 문제였지만, 규칙을 찾아내고 반복문으로 구현하는 과정이 퍼즐을 맞추는 것처럼 재미있었습니다. 문제를 풀고 나니 더 어려운 문제를 풀고 싶어졌고, 그렇게 자바를 배우기 시작했습니다. 자바를 배우며 점점 욕심이 생겼습니다. 이제는 직접 프로젝트를 만들어보고 싶었고, 그때 부트캠프라는 것을 알게 되어 코드 스테이츠에 등록했습니다.
비대면 수업이었지만 6개월 동안 130명이 넘는 학생들 중에서 가장 성실하게 임했다고 자부할 만큼 흠뻑 몰입했습니다. 그곳에서 처음으로 동료 개발자들을 만났고, 주말에는 종로 카페에 모여 함께 코딩할 정도로 성장에 목말라 있었습니다. 사실상 독학에 가까웠지만, 개발자 친구의 조언이 큰 도움이 되었습니다. "에러가 생기면 에러 코드를 읽어봐라", "뭐든 공식 문서로 배우려고 해라"는 말을 듣고, 문제를 마주할 때마다 공식 문서를 찾아보고 에러 메시지를 꼼꼼히 읽으며 원인을 분석하는 습관을 들였습니다.
배운 내용은 블로그에 정리하기 시작했는데, 이게 저와 너무 잘 맞았습니다. 복잡한 개념을 글로 풀어내는 과정에서 제가 진짜로 이해했는지 확인할 수 있었고, 나중에 비슷한 문제를 만났을 때 제 블로그를 다시 찾아보곤 했습니다. 지금은 블로그 글이 230개가 넘었습니다. 글을 쓰며 배운 것을 정리하고, 다른 개발자들과 지식을 나누는 일이 제 학습 방식의 핵심이 되었습니다.
프로젝트를 진행하며 아쉬웠던 점은 팀원들이 개인 사정으로 이탈하여 백엔드를 혼자 담당하게 된 것입니다. 순환 참조 문제를 해결하고 스프링 시큐리티를 구현할 때, 배운 지 몇 달 안 된 제가 혼자서 해냈다는 것이 뿌듯한 기억으로 남아 있습니다. 물론 그때 작성한 코드를 지금 보면 아쉬운 부분이 많습니다. 하지만 짧은 기간에 그만큼 빠르게 성장했다는 것 자체가 의미 있다고 생각합니다.
개발자가 알아야 하는 영역인 네트워크, Git, 배포, 데이터베이스 설계 등 전반적인 부분을 직접 경험했다는 것이 제 강점입니다. 다만 비전공자였기에 2023년 부트캠프를 수료했을 때는 바로 취업 지원을 하지 않았습니다. 당시 제 역량이 제가 원하는 수준에 미치지 못한다고 판단했기 때문입니다. 지금 돌이켜보면 그때 바로 도전하지 않은 것이 후회되기도 하지만, 그 시간 동안 리팩토링과 테스트 코드 작성을 학습하며 코드 품질에 대한 이해를 깊게 만들 수 있었습니다.
좋은 개발자란
저는 좋은 개발자란 단순히 기능을 구현하는 사람이 아니라, 함께 일하는 사람들을 편안하게 만드는 사람이라고 생각합니다. 요구사항을 정해진 일정 내에 충족하는 것은 기본입니다. 하지만 개발이 완료된 후에도 코드의 품질을 고려해야 합니다. 6개월 후, 1년 후에 이 코드를 다시 보는 사람이 쉽게 이해할 수 있도록 작성하는 것, 버그가 발생했을 때 빠르게 원인을 찾을 수 있도록 테스트 코드를 꼼꼼히 작성하는 것이 유지보수를 염두에 둔 개발이라고 생각합니다.
부트캠프에서 Git Flow 전략과 커밋 컨벤션을 지키며 협업하는 방법을 배웠습니다. 처음에는 단순한 규칙으로만 여겼지만, 프로젝트를 진행하며 이것이 함께 일하는 사람들을 배려하는 방법임을 깨달았습니다. 명확한 커밋 메시지는 다른 팀원이 변경 사항을 이해하는 시간을 줄여주고, 일관된 코드 스타일은 코드 리뷰를 수월하게 만듭니다. 개발자는 혼자 일하지 않습니다. 프론트엔드, 디자이너, 기획자 등 다양한 역할을 가진 사람들과 협업하며 하나의 결과물을 만들어냅니다. 그렇기에 배려심을 가지고 적극적으로 소통하는 것이 좋은 결과를 만드는 첫걸음이라고 생각합니다.
저는 맡은 일을 책임감 있게 완수하는 것뿐만 아니라, 팀 전체의 성과를 함께 만들어내는 과정에서 기쁨과 자긍심을 느낍니다. 부트캠프에서 줌 수업 지각이 점점 늘어나는 것을 보며 동기들에게 공지문을 작성했던 경험이 있습니다. 스티븐 잡스는 매킨토시의 부팅 시간을 10초 줄여야 한다고 주장하며 이렇게 말했습니다. 500만 명이 매일 컴퓨터를 켠다면 10초는 연간 3억 시간이 되고, 이는 100명이 평생을 사는 시간과 같다고요. 저는 이 이야기를 공유하며 우리가 프로그램을 설계할 때 1초를 고민하는 이유가 바로 사용자의 시간이 소중하기 때문이라고 설명했습니다. 130명이 함께하는 줌 수업에서 1분 지각은 130분, 즉 2시간 이상의 시간이 낭비되는 것입니다. 이후 모두가 약속 시간을 지키려 노력하게 되었고, 작은 행동이었지만 공동의 목표를 위해 함께 노력하는 문화를 만들 수 있었습니다.
가장 어려웠던 경험
저는 개발 과정에서 오류를 만나거나 모르는 것을 배워나가며 문제를 해결하는 과정이 무척 즐겁습니다. 하지만 즐거움만 있었던 건 아닙니다. 프로젝트를 진행하다가 팀원들이 취업이나 개인 사정으로 이탈하여 백엔드를 혼자 담당하게 된 적이 있었습니다. 주어진 일은 어떻게든 끝내야 한다는 마음으로 며칠 밤을 새워가며 작업했지만, 스프링 시큐리티를 설정하지 못해 3일간 진전이 없었습니다. 프론트엔드 팀원들에게 피해를 주고 싶지 않은 마음에 비해 실력이 따라주지 않아 분하고 속상한 마음에 눈물이 나곤 했습니다.
하지만 포기하지 않았습니다. 인프런에서 시큐리티 강의를 찾아 들었고, 동작 흐름을 파악하고, ChatGPT에게 수시간 동안 질문하며 문제의 원인을 좁혀나갔습니다. 공식 문서를 반복해서 읽고, 필터 체인을 한 줄씩 분석하며 물고 늘어졌습니다. 그렇게 끝내 문제를 해결했고, 프로젝트를 성공적으로 마칠 수 있었습니다. 힘들어하던 순간에 카카오에 근무하셨던 멘토님께서 "프로젝트가 완성되지 못하더라도 세상이 무너지는 게 아니다. 지금 멋진 속상함을 느끼고 있는 것 같다"고 위로해 주셨던 말씀이 기억에 남습니다. 하지만 저는 그 순간, 어떤 일이 있어도 무조건 해결하는 사람이라는 것을 깨달았습니다.
이 경험은 제게 두 가지를 알려주었습니다. 첫째, 저는 어떤 상황에서도 주어진 업무를 완료하려는 책임감과 끈기를 가지고 있습니다. 특히 팀이 어려움에 직면했을 때 더욱 힘을 내서 문제를 해결하려 노력합니다. 둘째, 이러한 책임감 때문에 가끔 과도한 스트레스와 압박감을 느낄 때가 있습니다. 지금은 산책을 하거나 팀원들과 소통하고, 주변에 도움을 요청하는 등의 방법으로 스트레스를 관리하는 법을 배웠습니다. 혼자 모든 것을 감당하려 하기보다는, 적절한 타이밍에 도움을 요청하는 것도 책임감 있는 태도라는 것을 알게 되었습니다.
저는 문제 해결 과정 자체를 즐기는 개발자입니다. 이런 열정을 가지고 꾸준히 성장하다 보면, 언젠가는 더 큰 가치를 세상에 기여하는 개발자가 될 수 있을 것입니다.
객체지향 프로그래밍에 대한 이해
저는 Java 언어와 Spring 프레임워크로 애플리케이션을 개발하는 방법을 배웠을 때 가장 즐거웠습니다. 그중에서도 객체지향 프로그래밍의 핵심 개념을 이해하고 실제로 코드로 구현하는 과정이 가장 기억에 남습니다.
처음에는 객체, 캡슐화, 다형성 같은 용어들이 추상적으로만 느껴졌습니다. 하지만 직접 클래스를 만들어보며 현실 세계의 문제를 프로그래밍적으로 해결하는 방법을 배우면서 이해하기 시작했습니다. 자동차 클래스를 만들 때 색깔이나 차종을 필드로 지정하고 동작을 메소드로 만들어보았습니다. 시장에서 바구니에 물건을 담는 것처럼 바구니 클래스가 음식 클래스를 담도록 구현해보기도 했습니다.
객체지향의 진짜 의미를 깨달은 순간은 프로젝트를 하면서였습니다. 사용자, 게시글, 댓글처럼 각각의 개체가 독립적으로 존재하면서도 서로 관계를 맺고 상호작용하는 구조를 설계할 때, 현실 세계의 관계를 코드로 표현할 수 있다는 것이 신기했습니다. 특히 상속과 다형성을 이해하고 나서는 중복되는 코드를 줄이고 유연한 구조를 만들 수 있다는 점이 매력적으로 느껴졌습니다. 같은 인터페이스를 구현하더라도 각 클래스가 다르게 동작할 수 있다는 것, 새로운 기능을 추가할 때 기존 코드를 최소한으로 수정할 수 있다는 것이 객체지향의 강력함이었습니다.
이후 알고리즘 문제를 풀면서 큰 문제를 작은 문제로 쪼개서 해결하는 분할 정복 방식을 배웠습니다. 복잡한 요구사항을 작은 단위로 나누고, 각각을 논리적으로 해결한 뒤 조합하는 과정이 객체지향 설계와 닮아 있다는 것을 깨달았습니다. 개발자에게 문제 해결 능력과 논리적 사고력이 중요하다는 것을 알게 되었고, 꾸준히 알고리즘 문제를 풀며 구현력을 키우고 있습니다.
프로젝트 경험
프론트엔드 2명, 백엔드 1명(본인)으로 구성된 팀에서 가계부 애플리케이션을 개발했습니다. 일반적인 수입과 지출 관리 기능 외에도 위시리스트 기능을 통해 목표 금액을 설정하고 계획적으로 소비할 수 있도록 돕는 시스템을 구현했습니다. 매달 지출 내역 기반으로 자산 관리 피드백을 이메일로 제공하는 서비스도 구상했습니다.
프로젝트 초기에 요구사항 명세서와 ERD를 작성하는 과정에서 많은 고민을 했습니다. RESTful한 API 설계를 위해 리소스를 어떻게 정의하고 URI를 어떻게 구성할지 고민했습니다. 예를 들어 사용자의 지출 내역을 조회할 때 /users/{userId}/expenses처럼 계층 구조를 명확히 표현하려 노력했고, HTTP 메소드를 용도에 맞게 사용하려 했습니다.
ERD를 설계할 때는 엔티티 간의 관계를 정의하는 것이 가장 어려웠습니다. 사용자와 카테고리의 관계를 설정할 때 N:N 관계로 설정해야 할지, 아니면 중간 테이블을 명시적으로 만들어야 할지 고민했습니다. 결국 유연성을 위해 사용자가 커스텀 카테고리를 만들 수 있도록 중간 테이블을 두는 방식을 선택했습니다.
또한 연관관계를 표현할 때 식별 관계와 비식별 관계를 구분하는 것이 중요했습니다. 실선은 식별 관계로, 부모 테이블의 기본키가 자식 테이블의 기본키이자 외래키가 되는 경우입니다. 점선은 비식별 관계로, 부모 테이블의 기본키가 자식 테이블의 일반 외래키로만 사용되는 경우입니다. 예를 들어 지출 내역은 사용자에게 강하게 종속되어 있지만 독립적인 ID를 가지도록 비식별 관계로 설계했습니다. 이는 나중에 지출 내역을 다른 용도로 활용하거나 관계를 변경할 때 유연성을 확보하기 위함이었습니다. 반면 필수 관계인지 선택 관계인지는 카디널리티 표기로 나타냈습니다. 지출 내역은 반드시 사용자에게 속해야 하므로 1:N 관계로 표현했고, 위시리스트는 카테고리가 없을 수도 있어 0..1 관계로 설정했습니다.
데이터베이스를 선택할 때도 각 선택지의 장단점을 조사했습니다. NoSQL과 관계형 데이터베이스를 비교했고, 가계부라는 특성상 데이터 구조가 명확하고 트랜잭션 일관성이 중요하다는 점, 그리고 수입과 지출 간의 관계를 명확히 설정해야 한다는 근거를 바탕으로 MySQL을 선택했습니다. 모든 결정 사항과 그 근거는 문서로 기록하여 팀원들이 언제든 확인할 수 있도록 했습니다.
설계를 마친 후 요구사항에 맞춰 CRUD를 구현하고 엔티티 간 관계를 코드로 옮겼습니다. JWT 기반의 인증 시스템을 구현하고, 로그아웃 시 JWT 무효화를 위해 Redis에 블랙리스트 기능을 추가하여 보안을 강화했습니다.
프로젝트를 진행하며 CORS 에러, 순환 참조 에러, AWS 배포 중 발생한 문제, Git merge 충돌 등 수많은 문제를 마주했습니다. 하지만 그동안 스스로 문제를 해결하는 능력을 키워왔기에 일정에 맞춰 배포를 마칠 수 있었습니다. 배포 이후에는 사용자 입장에서 직접 사용해보고 다른 사람들에게 피드백을 받았습니다. 개발할 때 놓쳤던 버그와 요구사항을 발견하고 수정했으며, Postman으로 테스트하던 부분을 JUnit5와 Mockito로 기능 테스트 코드를 작성했습니다.
프로젝트 완료 후에도 개선 작업을 이어갔습니다. 마틴 파울러의 리팩토링 책을 구입하여 읽으며 코드 품질을 개선하는 방법을 학습했고, 실제로 코드를 더 나은 구조로 업데이트했습니다. 비록 백엔드 개발자 간의 협업을 경험하지 못한 것이 아쉬웠지만, 혼자서도 협업의 규칙을 철저히 지키려 노력했습니다. 덕분에 백엔드 개발의 전반적인 과정, 기획부터 배포, 그리고 유지보수까지 모든 단계를 경험할 수 있었고 이것이 제 역량을 키우는 귀중한 경험이 되었습니다.
AI와 함께 성장하기
2023년 처음 ChatGPT를 접했을 때 저는 단순한 코드 참고용으로만 사용했습니다. 막히는 함수 이름을 떠올릴 때나 예시 코드가 필요할 때 가볍게 도움을 받는 정도였습니다. 당시에는 "AI를 쓰면 실력이 떨어진다"라는 우려도 많아서, 저 역시 조심스러운 마음으로 사용했습니다.
하지만 개발을 계속하다 보니 AI를 바라보는 시각이 자연스럽게 달라졌습니다. 스프링 시큐리티 설정 문제로 며칠을 고민하며 ChatGPT에게 수시간 동안 질문했던 경험은 단순히 답을 얻는 것을 넘어, 어떻게 질문해야 원하는 답을 얻을 수 있는지를 배우는 과정이었습니다. AI가 잘못된 답을 줄 때 어떤 기준으로 바로잡아야 하는지 스스로 판단할 수 있게 되면서, 제가 AI에 의존한 것이 아니라 AI를 활용해 더 빠르게 성장하고 있다는 걸 깨달았습니다.
반복적인 작업을 AI에게 맡기기 시작하면서 저는 더 본질적인 문제에 집중할 수 있게 되었습니다. 보일러플레이트 코드 작성에 쓰던 시간을 아키텍처 설계나 사용자 경험을 고민하는 데 투자할 수 있었고, 이러한 변화는 프로젝트의 완성도로 자연스럽게 이어졌습니다.
특히 최근에는 Spring AI를 학습하며 제 역할이 확실히 바뀌었습니다. 이전에는 AI를 사용하는 소비자였다면, 지금은 AI 기반 서비스를 만드는 공급자가 되었습니다. 이 전환은 단순히 기술을 배운 것 이상의 의미가 있었습니다. RAG 시스템을 구축하며 PDF 문서를 벡터로 변환해 저장하고 검색하는 흐름을 구현하면서, 사용자가 방대한 문서 속에서 필요한 정보를 빠르게 찾을 수 있도록 돕는 서비스의 가치를 이해하게 되었습니다. Tool Calling을 활용해 LLM이 필요할 때 외부 기능을 직접 호출하는 구조를 설계하면서는, AI가 단순한 대화를 넘어 실제 작업을 수행하는 에이전트로 진화할 수 있다는 가능성을 직접 경험했습니다.
MCP(Model Context Protocol)를 공부하면서는 더 큰 그림을 볼 수 있게 되었습니다. LLM이 외부 도구와 데이터에 접근하는 표준화된 방식을 이해하면서, AI 서비스가 단일 애플리케이션이 아니라 다양한 시스템이 협력하는 생태계로 확장될 수 있다는 점을 깨달았습니다. 팀 프로젝트에서 Spring AI 기반 MCP 서버를 직접 구현하며 Git 저장소 도구 개발을 담당했을 때, 프로토콜 수준에서 AI 서비스를 설계하는 경험은 단순히 기능을 만드는 것을 넘어 시스템 간 상호작용을 설계하는 방법을 배우는 기회였습니다.
10년 뒤에는 지금 제가 작성한 코드보다 훨씬 효율적인 코드를 AI가 만들어낼지도 모릅니다. 하지만 그렇기 때문에 저는 코드를 잘 작성하는 개발자보다, 문제를 정의하고 구조를 설계하며 도메인을 깊이 이해하는 개발자가 되고 싶습니다. AI가 코드를 생성하더라도, 어떤 문제를 해결해야 하는지, 사용자에게 어떤 가치를 전달해야 하는지를 결정하는 것은 결국 개발자의 몫이기 때문입니다.
앞으로의 다짐
실제 업무에서는 기존에 해오던 프로젝트에 비해 트랜잭션, 보안, 데이터베이스 관리와 같은 측면에서 엄격한 규제와 요구사항이 있어 더 많은 주의와 전문 지식을 요구합니다. 그래서 어렵게 느껴질 수도 있지만 지금까지 해결해 온 것처럼 강의나 책을 찾아보고, 개발자 커뮤니티에 질문하면서 문제를 해결하고, 틈틈이 자격증을 취득한다면 기술이 변화하더라도 변화에 유연하게 대응할 수 있는 개발 능력을 보유하게 될 것이라고 확신합니다. 그리고 혼자서 모든 것을 감당하는 것이 아니라 주변에 훌륭한 동료들이 저를 잘 이끌어 주리라는 믿음이 있기에 두렵지 않습니다.
저는 변화하는 환경 속에서도 흔들리지 않고, 본질적인 개발 역량을 꾸준히 쌓아가는 개발자가 되고 싶습니다. AI를 두려워하기보다는 자연스럽게 활용하고, 그 위에서 제 가능성을 더 넓혀가며, 결국 사용자에게 진짜 가치를 전달할 수 있는 서비스를 만드는 개발자로 성장하고 싶습니다.
