소프트웨어 개발 분야에서 '주니어'와 '시니어' 개발자는 흔히 사용되는 용어지만, 그 경계는 명확하지 않습니다. 단순히 경력 연수만으로 주니어와 시니어 개발자를 나눌 수 없으며, 기술적 숙련도, 문제 해결 능력, 협업과 리더십 같은 소프트 스킬이 주니어와 시니어 개발자를 나누는 중요한 기준이 될 수 있습니다. 프로그래머스에서는 시니어 개발자분들과 인터뷰를 통해 각 유형의 개발자들이 생각하는 개발자의 성장 단계를 나누는 기준을 살펴보았습니다. 이 글을 통해 주니어와 시니어 개발자의 역할이 어떻게 달라지는지 알아보고, 개발자들이 성장하는 과정에서 필요한 역량을 살펴보겠습니다.
 
# 개발자의 성장 단계는 어떤 기준으로, 어떻게 나눌 수 있을까요?
![1_b5EausLITYCF9jJgws1QNA.webp](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/94f88f29-b67d-40da-91ff-a5c6b6bf3ad7/1_b5EausLITYCF9jJgws1QNA.webp)
[이미지 출처](https://medium.com/@jamie.reid.nb/the-differences-between-junior-medior-and-senior-developers-using-javascript-46f689f62e05)
 
## 💬 박ㅇㅇ님 (프론트엔드 엔지니어) / 실리콘밸리
미국은 레벨링이 잘 되어 있어요. 막연하게 몇 년 차 이렇게 말하지 않아요. 그런 건 큰 의미가 없다고 생각합니다. 미국에서는 레벨 3부터 레벨 5까지가 핵심인데요. 레벨 3이 주니어, 4가 중간, 5가 시니어 입니다.

레벨 3은 정해진 스펙으로 구현할 수 있는 능력을 가진 레벨입니다. 레벨 4는 레벨 3에서 더 나아가 좀 더 넓은 시야로 사이드 이펙트 등을 파악하고 제시할 수 있는 수준입니다. 간단하게 말하자면 레벨 3은 할당된 내용대로만 업무를 수행하면 되고, 레벨 4는 예상되는 문제점을 찾아 역제안할 수 있는 단계의 개발자를 의미하는 것이죠.

레벨 5는 처음부터 끝까지 스스로 구현할 수 있는 레벨입니다. 레벨 6은 여기에 리더십이 포함되는데, 레벨 5들을 모아서 새로운 것을 만들때 융합할 수 있는 방법을 제시하고 리딩할 수 있는 능력이죠. 레벨 7은 레벨 6들을 모아서 회사에 필요한 것을 만들어낼 수 있는 사람입니다. 기술적으로는 레벨 5가 최대치라고 볼 수 있습니다. 이러한 레벨에 대해 인정받는 방법은 각 레벨 기준에 해당되는 역량을 보여주는 프로젝트나 포트폴리오를 가져가서 증명해 내는 것이죠.

물론 승진에는 정치적인 요인도 들어갈 수 있기에 넷플릭스와 같은 일부 회사들은 시니어만 채용한 후 평가없이 성과만 내도록 독려하기도 합니다. 하지만 성과를 내지 못하면 바로 나가야 하죠. 이러한 회사는 인터뷰 과정을 매우 철저히 진행하여 반드시 성과를 낼 수 있을 것 같은 인재들만 채용하기도 합니다.
 
> 📌 **Summary**
> · 미국은 연차대신 레벨링으로 표현
> · Lv.3는 정해진 스펙으로 구현할 수 있는 능력을 가진 사람 (주니어)
> · Lv.4는 문제점을 찾아 역제안할 수 있는 사람 (중간)
> · Lv. 5는 처음부터 끝까지 스스로 구현할 수 있는 사람 (시니어)

## 💬 우ㅇㅇ님 (백엔드 엔지니어)
흔히 신입, 주니어라고 부르는 개발자의 성장 첫 단계는 눈앞에 보이는 문제 상황 해결, 그리고 그것을 해결하기 위한 전문 기술(스프링이나 각 언어에 대한 학습)을 갖추는 단계인 것 같습니다.

이러한 부분을 어느정도 원활하게 수행할 수 있게 되면, 그 다음부터는 향상된 커뮤니케이션을 바탕으로 특정 파트의 대표를 맡는 사람이나 팀장이 됩니다. 팀장이 되기 전에도 특정 기술 분야나 개발 중인 도메인 또는 기능 분야가 있으면 그 부분을 대표하는 역할을 수행할 수 있습니다. 그 사람의 발언이 어느 정도 대표성을 띄는 순간, 시니어의 단계에 접어드는 것이라 생각합니다.

시니어 개발자 중에는 부족한 커뮤니케이션 역량을 개발 능력으로 채우는 경우도 있고, 오랜 기간 쌓아온 도메인 지식, 회사와 관련된 풍부한 정보 등을 통해 어느 정도 대표성을 띄면서 커뮤니케이션을 조율하는 경우도 있습니다.

가장 좋은 것은 일단 기술적으로 누구에게나 존중받을 수 있는 단계로 성장하는 것입니다. 서로 코드 리뷰를 하거나 기술 선택을 할 때 어느 단계의 개발자인지 자연스럽게 보이며, 이로 인해 발언권 차이가 나기도 합니다. 다른 개발자들을 설득할 수 있을만한 기술적 역량을 가지고 있고, 동시에 도메인 지식까지 갖춰 마케팅, 디자인, 기획 등의 타 부서와 원활하게 소통하는 사람이 있는데, 결국 이런 분들이 존중받는 시니어 개발자가 되는 것 같습니다.
 
> 📌 **Summary**
> · 신입과 주니어는 눈앞에 보이는 문제 상황을 해결하고, 이를 위한 전문 기술을 학습하는 단계
> · 시니어는 특정 파트의 대표성을 띄고, 다른 개발자를 설득할 수 있는 기술 역량과 커뮤니케이션 역량을 갖추는 단계

## 💬 정ㅇ님 (풀스택 엔지니어)
주니어와 시니어를 구분하는 간단한 기준을 말하자면, 시니어는 알아서 잘하는 사람, 주니어는 '이것이 문제다'라는 것을 인지하고, 시키는 것을 잘하는 사람입니다. 시니어가 되면 문제점을 찾고, 대안을 제시하고, 그 문제를 스스로 해결할 수 있어야 합니다.

때문에 주니어에게는 매우 디테일하게 업무를 할당해야 하는데, 시니어에게는 '이러한 문제가 있다'고만 말하면 되는 것이죠. 시니어 레벨의 개발자들은 그 문제를 해결하기 위해 필요한 것들을 계획할 수 있습니다. 이러한 부분이 주니어와 시니어 단계를 나누는 기준이 될 수 있겠죠.

어느 조직을 가나 부족한 점은 있습니다. 하지만 시니어 레벨로 가는 사람들은 이러한 조직 내 문제점을 인지하고, 이를 어떻게 해결할 수 있을지 고민합니다. 단순히 코딩만 하는 것이 아니라 타부서와 협업하고, 더 나은 협업 프로세스를 고민하게 됩니다. 주니어 단계에서는 앉아서 코딩만 열심히 하고, 이를 딜리버리하면 좋은 평가를 받을 수 있지만, 시니어 단계로 가면 기대치가 훨씬 높아집니다. 문제점을 인지하고, 이에 대한 대안점을 찾고, 이를 해결하는 것 까지를 요구합니다.
 
> 📌 **Summary**
> · 주니어는 문제를 인지하고, 시키는 것을 잘 하는 사람
> · 시니어는 문제점을 찾고, 대안을 제시하여 해결하는 사람

 
*위 글은 프로그래머스에서 시니어 개발자분들과 인터뷰한 내용의 일부를 재편집한 글입니다.
 
 
> **프로그래머스 웹과정 데브코스** 👩‍💻
> 1,700개 기업의 채용 공고를 완벽 분석하여 취업에 필요한 핵심 기술을 엄선한 프로그래머스 프론트엔드 / 백엔드 과정


[![be-coding-test2(729x90).jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/306190da-2ff2-4a68-a251-ccb1871ef0d4/be-coding-test2%28729x90%29.jpg)](https://school.programmers.co.kr/learn/courses/25244?utm_source=prgmblog&utm_medium=social&utm_campaign=school_25244_blog&utm_content=25244_banner)

[![fe-coding-test2(729x90).jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/231c7cb0-2cb9-4384-ac28-8b3e6cf35b0e/fe-coding-test2%28729x90%29.jpg)](https://school.programmers.co.kr/learn/courses/25243?utm_source=prgmblog&utm_medium=social&utm_campaign=school_25243_blog&utm_content=25243_banner)

주니어와 시니어 개발자를 나누는 기준

안녕하세요, 프로그래머스입니다.
길벗 출판사에서 신청자 전원 참여가 가능한 코딩 자율학습단 21기를 모집 중입니다.
코딩 자율학습단은 길벗출판사의 프로그래밍 도서 + AI 도서의 완독을 돕는 프로그램인데요!
4주간 프로그래밍과 AI 입문을 배워보고 싶으신 분들은 주목해주세요!
 
 
## 코딩 자율학습단 21기 모집 중!
![프로그래머스 공유용_블로그 (1).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/d2769960-97c4-40b1-add2-aa7c5a00ad94/%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%84%80%E1%85%B3%E1%84%85%E1%85%A2%E1%84%86%E1%85%A5%E1%84%89%E1%85%B3%20%E1%84%80%E1%85%A9%E1%86%BC%E1%84%8B%E1%85%B2%E1%84%8B%E1%85%AD%E1%86%BC_%E1%84%87%E1%85%B3%E1%86%AF%E1%84%85%E1%85%A9%E1%84%80%E1%85%B3%20%281%29.png)
 
✅ 참가비 없음
✅ 준비물은 오직 책 1권!
✅ 신청시 전원 100% 참여 가능
 
🎁 학습 기간 내에 커리큘럼, 가이드, 질의응답 등 다양한 학습 서비스가 제공되며, 완독하신 분들에게는 **도서 구매용 포인트 2만 점**과 **네이버 포인트** 등 다양한 선물이 증정됩니다! 
 
👉 **[코딩 자율학습단 자세히 알아보기](https://gilbut.co/c/26061837WD)**

 
 
#### 💡 코딩 자율학습단은?
* **누적 참여자 5,000명**이 증명하는 확실한 커뮤니티
* 완독까지 매일매일 **학습 알림**!
* 꼼꼼한 **학습 커리큘럼**과 **실시간 질의응답**
* **완독만 해도** 제공되는 다양한 선물과 우수사 시상까지!

 
 
## 코딩 자율학습단 도서 목록
![프로그래머스 공유용_블로그 (2).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/8feb0efb-866a-442b-8129-2b1a0c320f57/%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%84%80%E1%85%B3%E1%84%85%E1%85%A2%E1%84%86%E1%85%A5%E1%84%89%E1%85%B3%20%E1%84%80%E1%85%A9%E1%86%BC%E1%84%8B%E1%85%B2%E1%84%8B%E1%85%AD%E1%86%BC_%E1%84%87%E1%85%B3%E1%86%AF%E1%84%85%E1%85%A9%E1%84%80%E1%85%B3%20%282%29.png)
 
* 코딩 자율학습 나도코딩의 파이썬 입문
* 코딩 자율학습 HTML+CSS+자바스크립트
* 코딩 자율학습 나도코딩의 C 언어 입문
* 코딩 자율학습 나도코딩의 자바 입문
* AI 자율학습 커서ⅹAI로 완성하는 나만의 웹 서비스
* AI 자율학습 밑바닥부터 배우는 AI 에이전트
* AI 자율학습 AI 에이전트 개발 입문
* AI가 다 하고 내가 돈 버는 앱 만들기
* 바이브 엔지니어링

 
 
## 코딩 자율학습단 21기 안내
![프로그래머스 공유용_블로그 (3).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/37ac7e9e-6a24-41c3-9cfc-61a55fee0a2e/%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%84%80%E1%85%B3%E1%84%85%E1%85%A2%E1%84%86%E1%85%A5%E1%84%89%E1%85%B3%20%E1%84%80%E1%85%A9%E1%86%BC%E1%84%8B%E1%85%B2%E1%84%8B%E1%85%AD%E1%86%BC_%E1%84%87%E1%85%B3%E1%86%AF%E1%84%85%E1%85%A9%E1%84%80%E1%85%B3%20%283%29.png)
 
* 모집 기간: **~7월 10일(금)**
* 학습 기간: **7월 13일(월) ~ 8월 7일(금)**

 
*선정 안내는 신청 후 개별 연락을 드릴 예정입니다.*

 
👉 **[학습단 상세 안내](https://cafe.naver.com/gilbutitbook/22979)**

 
 
## 참여 혜택
![프로그래머스 공유용_블로그 (4).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/caf1ceca-a428-425b-8679-abea71d94f75/%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%84%80%E1%85%B3%E1%84%85%E1%85%A2%E1%84%86%E1%85%A5%E1%84%89%E1%85%B3%20%E1%84%80%E1%85%A9%E1%86%BC%E1%84%8B%E1%85%B2%E1%84%8B%E1%85%AD%E1%86%BC_%E1%84%87%E1%85%B3%E1%86%AF%E1%84%85%E1%85%A9%E1%84%80%E1%85%B3%20%284%29.png)
 
* 4주간 카톡 알림, 학습 커리큘럼 제공
* 멘토 가이드 및 학습 Q&A 지원
* 완독시 2만 포인트 지급
* 우수자 3만 네이버 포인트 지급
* 친구들과 함께 신청 시 전원 커피 기프티콘 증정

 

많은 참여 부탁드립니다 😊

 
 
#### 학습단 문의
📧 jjbook@gilbut.co.kr

[길벗출판사] 코딩 자율학습단 21기를 모집합니다!

AI 시대, 개발 역량을 활용할 수 있는 커리어는 점점 다양해지고 있습니다.
 
이번 영상에서는 OpenAI에서 AI Success Engineer로 일하고 있는 임지훈 님을 만나 AI를 고객의 업무와 서비스에 성공적으로 도입하도록 돕는 역할에 대한 이야기를 나눴습니다.
 
AI와 개발의 접점에서 일하는 다양한 커리어가 궁금하다면, 인터뷰를 끝까지 읽어보세요!
 
 

<div style="position: relative; max-width: 100%; padding-bottom: 56.25%; height: 0;"><iframe width="560" height="315" src="https://www.youtube.com/embed/uyQ9sqCVfZ0?si=kVZK-x-mLCFEeGRr" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen="" style="position: absolute; position: absolute; top: 0; left: 0; width: 100%; height: 100%;"></iframe></div>

 
 
 
## 간단한 자기소개와 현재 하고 계신 일을 소개해주세요.
안녕하세요. 저는 OpenAI에서 Member of Go To Market Staff - AI Success Engineer로 일하고 있는 임지훈, Eric입니다.
 
저는 흔히 생각하시는 전통적인 의미의 개발자, 즉 Software Engineer라기보다는 Solution Architect, Solution Engineer, Technical Success에 가까운 역할을 하고 있습니다.
 
AI 기술을 고객의 실제 환경에 적용하고, 문제를 해결할 수 있도록 설계하고 구현까지 함께하는 역할을 하고 있습니다. 단순히 기술을 설명하는 것이 아니라, 고객의 문제를 이해하고 그에 맞는 구조를 제안하고, 실제로 운영까지 연결하는 역할이라고 보시면 좋을 것 같습니다.
 
 
## 해당 커리어를 선택하게 된 계기가 궁금합니다.
제가 이 길을 선택하게 된 계기는 사실 꽤 우연했어요. 대학에서 컴퓨터공학을 전공했고 음악·음향 쪽을 부전공했는데, 당시만 해도 저는 개발 커리어라고 하면 무조건 Software Engineer밖에 없는 줄 알았어요. 그래서 졸업하면 당연히 개발자가 되어야 한다고 생각했고요.
 
그러다 대학교 3학년 때 인턴십을 준비하면서 여러 인터뷰를 보게 됐고, 운 좋게 아마존의 SWE 인턴 최종 라운드까지 가게 되었습니다. 그런데 그 자리에서 인터뷰어가 “넌 개발자처럼 말하지 않네?”라고 하시는거예요. 그 말을 듣고 순간, ‘아, 망했다…’ 싶었습니다. 제가 너무 덜 테크니컬하게 말했나, 엉뚱한 이야기를 했나 걱정을 많이 했죠.
 
그런데 그분이 이어서 “Solutions Architect 라는 직군이 있는데, 그 쪽이 더 잘 맞을 것 같다”고 제안해주셨어요. 마침 SWE 인턴 자리는 거의 다 차서 대기 상태만 가능한 상황이기도 했고요. 당시에는 인턴 자체가 너무 중요했기 때문에, 솔직히 어떤 직무인지 정확히 알지는 못했지만 “기회만 주신다면 뭐든 해보겠습니다”라는 마음으로 시작하게 됐습니다. 지금 돌아보면, 그 선택이 제 커리어에서 정말 중요한 전환점이었던 것 같습니다.
 
 
## 어떤 점에서 Solutions Architect라는 직군이 잘 맞다고 생각하셨나요?
인턴십을 통해 저는 혼자 코드를 깊게 파고드는 역할보다는 기술을 이해하고 그걸 사람과 문제에 연결하는 역할이 더 잘 맞다는 것을 알게 되었어요.
 
물론 엔지니어링 백그라운드가 있기 때문에 기술적인 부분을 이해하고 직접 구현하는 것 자체도 좋아합니다. 근데 저한테 더 재미있었던 건 “이 기술이 실제로 어떤 문제를 풀 수 있는가”, 그리고 “이걸 현실적인 시스템으로 어떻게 설계하고 운영할 수 있을까”를 함께 고민하는 일이었습니다.
 
 
## Solutions Architect라는 직군에 대해 조금 더 구체적으로 설명해주실 수 있으실까요?
### "고객과 기술을 연결하는 역할, Solutions Architect"
Solutions Architect나 Technical Success는 회사가 가진 기술을 고객이 실제로 성공적으로 쓸 수 있도록 돕는 역할이라고 생각합니다. 예를 들어 AWS라면 클라우드 서비스를 가지고 고객의 시스템을 어떻게 설계하고 운영할지 함께 고민하는 것이고, AI 회사라면 모델이나 제품을 고객의 실제 워크플로우에 어떻게 붙이고, 어떤 식으로 배포하고, 운영하고, 조직 안에 안착시킬지를 같이 설계하는 일입니다. 
 
단순히 제품을 설명하는 역할이 아니라, 고객의 문제를 이해하고, 적절한 구조를 제안하고, 때로는 직접 개발과 검증, 배포, 운영 안정화까지 함께 들어가는 역할이에요. 
 
 
### "제품팀과 고객 사이의 Gap, 그 간극을 메우는 역할"
소프트웨어 회사 안에는 크게 두 축이 있다고 생각합니다. 소프트웨어를 만들고 발전시키는 제품팀과 그 제품을 실제로 사용하는 고객과 사용자입니다. 그런데 이 두 영역 사이에는 생각보다 큰 gap이 생기기 쉽습니다.
 
제품을 만드는 팀은 기술적으로 무엇을 만들 수 있을지, 제품을 어떤 방향으로 발전시킬지에 집중합니다. 반면 사용자는 실제 업무와 환경 안에서 그 제품을 어떻게 써야 하는지, 무엇이 불편한지, 무엇이 더 필요한지, 어떤 부분에서 막히는지를 느낍니다.
 
문제는 이 둘이 서로를 완벽하게 이해하기 쉽지 않다는 점입니다. 사용자는 제품이 왜 이렇게 설계되어 있는지, 어떤 방식으로 활용해야 가장 큰 가치를 낼 수 있는지 알기 어려울 수 있습니다. 반대로 제품팀은 사용자가 실제 현장에서 어떻게 제품을 사용하고 있는지, 어디에서 어려움을 겪고 있는지, 무엇을 원하는지 충분히 보지 못할 때가 많습니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/4c268579-220d-4d65-bcf2-ff836e38ecc7/image.png)
 
Solutions Architect는 바로 그 사이를 연결하는 역할이라 생각합니다. 고객에게 “이 제품을 당신의 환경에서는 이런 식으로 사용해야 실제 가치가 생긴다”는 것을 구체적으로 보여주고, 제품팀에게는 “고객은 이 제품을 실제로 이렇게 사용하고 있고, 여기에서 막히고 있고, 이런 니즈가 있다”는 현장에서의 목소리를 전달하는 것이죠.
 
그래서 Solutions Architect는 단순한 기술 설명자도 아니고, 단순한 개발자도 아닙니다. 기술을 이해하면서 동시에 사람을 이해해야 하고, 제품을 알면서 현장도 알아야 합니다. 저는 바로 그 점이 굉장히 흥미로웠고, 제가 가진 강점과도 잘 맞는다고 느꼈습니다.
 
 
## AI 분야, 특히 OpenAI에 합류하게 된 이유는 무엇인가요?
저는 AI가 단순히 새로운 기술이 아니라, 사람들이 일하는 방식과 비즈니스의 구조를 바꾸는 기술이라고 느꼈습니다. 근데 AI가 좋다고 해서 저절로 잘 쓰이게 되는 건 아니라고 생각합니다. 오히려 AI야말로 제품팀이 만든 기술과 고객이 실제로 원하는 결과 사이의 간극이 더 크게 생기기 쉬운 분야라고 봤습니다. 
 
그래서 저는 많은 사람들이 AI를 실제로 잘 쓰게 만드는 일에 의미를 느꼈고, 그걸 가장 잘 할 수 있는 환경이 Frontier AI Lab이라고 생각해서 OpenAI에 합류하게 되었습니다.
 
 
## AI 관련 기업에서 일하는 것은, 일반 IT 기업과 어떤 부분에서 다른가요?
Frontier AI Lab은 지금 가장 앞선 AI 모델을 직접 만들고 연구하는 회사들입니다. 제가 느끼기에 일반 IT 기업과 가장 다른 점은, 이곳은 정말 ‘연구소에 가깝다’는 점입니다.
 
일반 IT 기업은 보통 이미 존재하는 기술을 더 잘 개선하거나, 검증된 기술을 활용해서 문제를 해결하는 경우가 많습니다. 비교적 익숙한 기술적 기반 위에서 제품을 만들고 최적화하는 일이 중심이 되죠.
 
반면 지금의 생성형 AI는 기존 기술을 조금 발전시키는 수준이 아니라, 아예 새로운 가능성을 계속 열어가는 영역에 더 가깝다고 생각합니다. 그리고 이 정도 스케일의 기술로 무엇을 할 수 있는지도 아직 완전히 정해져 있지 않은 상태입니다.
 
그러다 보니 Frontier AI Lab에서는 모든 것이 훨씬 더 실험적이고 탐색적입니다. 빠르게 만들어보고, 실제로 써보고, 실패하더라도 그 과정에서 배우는 것이 굉장히 중요합니다. 그런 점에서 일반적인 제품 회사라기보다는, 연구와 개발이 동시에 이루어지는 진짜 Research Lab이라고 보시면 될 것 같습니다.
 
 
## 실제 업무에서 가장 중요하게 사용하는 역량은 무엇인가요?
실제 업무에서 제가 가장 많이 사용하는 역량은 결국 고객의 목소리를 듣는 능력입니다.
 
제 일은 기술부터 시작하는 게 아니라, 고객이 지금 어떤 문제를 겪고 있는지, 서비스를 어떻게 쓰고 있는지, 어디에서 막히고 있는지를 이해하는 것에서 시작합니다.
 
그래서 고객이나 사용자의 트렌드를 보고 어떤 방식으로 제품을 활용하고 있는지, 어떤 부분을 불편해하는지, 그리고 그 문제를 지금은 어떻게 접근하고 있는지를 먼저 파악해야 합니다. 저는 그 과정에서 항상 고객의 입장에서 한 번 더 생각해보는 것이 중요하다고 느꼈습니다.
 
그리고 이런 맥락이 충분히 이해된 다음에야 비로소 기술적인 역량이 의미 있게 쓰인다고 생각합니다. 그때부터 아키텍처를 설계하고, 적절한 솔루션을 제안하고, 실제로 구현과 배포까지 이어지는 기술적인 판단이 가능해지기 때문입니다.
 

 <div style="border-radius: 4px;padding:22px 20px; background: #F5F5F5; border: 1px solid #D6D6D6;">AI를 고객의 성공으로 연결하는 AI Success Engineer 임지훈 님의 이야기, 흥미롭게 읽으셨나요? 곧 공개될 인터뷰 2편에서는 AI 시대에 변화하는 개발자의 역할, AI 산업과 기술 트렌드, 커리어 준비 방향에 대한 이야기를 더 깊이 나눌 예정입니다. 다음 편도 기대해주세요!</div>

 
 
### 📌 OpenAI 임지훈 님 인터뷰 2편 보러가기
* [AI가 코딩하는 시대, 진짜 경쟁력은 따로 있습니다](https://community.programmers.co.kr/post/13961)

개발자 취업만 준비했다면 놓칠 수 있는 직무 ㅣ OpenAI AI Success Engineer 임지훈 인터뷰 (1편)

"우리 회사에는 수십 년간 쌓인 데이터가 정말 많습니다."
AI 도입을 검토하는 수많은 기업에서 들려오는 이 당당한 자신감은, 안타깝게도 프로젝트 시작 직후 "그런데 정작 쓸 만한 데이터가 없다"는 당혹감으로 바뀌곤 합니다. 오랫동안 관리해 온 데이터가 왜 AI 앞에서는 무용지물이 되는 걸까요?
 
AI 시대에 접어들며 기업 데이터 관리의 기준은 단순한 '저장'에서 '활용 가능성'으로 급격히 이동하고 있습니다. 그 중요성을 보여주듯 [최근 삼성전자 역시 데이터 엔지니어링 전문가를 영입해 'AI Ready Data' 체계 구축](https://biz.chosun.com/it-science/ict/2026/08/14/6O2E5NU23NCPBGSAUT2WOIC4VY/)에 박차를 가하고 있습니다. 데이터 사이언티스트 정경문 님이 전하는 이번 글을 통해 기업의 AI 성패를 가를 'AI Ready Data'에 대해 자세히 알아보세요!
 
 
 
## 데이터는 많은데, 왜 AI를 만들 데이터는 없을까?
### "우리 회사에는 데이터가 정말 많습니다."
AI를 도입하려는 기업에서 흔히 들을 수 있는 말입니다. 틀린 말도 아닙니다. ERP와 MES에는 수년에서 수십 년간의 데이터가 쌓여 있고, 공장에서는 수많은 센서가 매초 데이터를 만들어냅니다. 서버를 열어보면 PDF, PPT, Excel, 작업표준, 설비 매뉴얼, 연구 보고서, 회의록이 끝없이 나옵니다. 최근에는 데이터 레이크나 데이터 플랫폼까지 구축한 기업도 많습니다.
 
그런데 막상 “이제 이 데이터로 AI를 만들어봅시다”라고 하면 이상한 일이 벌어집니다. 데이터는 많은데 정작 AI에 쓸 데이터가 없다는 이야기가 나오기 시작합니다. 왜 그럴까요?
 
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/940f33ef-1e6a-4df2-9b75-e5fe777a52a0/image.png)
왜 쓸만한 데이터가 없을까? (이미지 출처: ChatGPT)
 
 
설비 고장을 예측하는 AI를 만든다고 생각해 보겠습니다. 회사에는 10년 치 설비 데이터가 있습니다. 결측치도 거의 없고, 중복 데이터도 제거했고, 온도와 압력의 단위도 통일했습니다. 전통적인 데이터 품질 관점에서는 상당히 잘 관리된 데이터입니다.
 
그런데 AI 학습을 시작하려고 자세히 들여다보니 정상 운전 데이터가 99%이고 실제 고장 데이터는 1%밖에 없습니다. 더 큰 문제는 고장 시점은 기록되어 있지만 “왜 고장이 났는가”를 설명해 줄 진동이나 부하 변화 같은 중요한 변수가 빠져 있다는 것입니다. 게다가 데이터의 상당 부분은 이미 교체된 구형 설비에서 만들어졌습니다. 데이터는 깨끗합니다. 그런데 과연 이 데이터는 고장예측 AI에게도 좋은 데이터일까요?
 
여기서 질문을 바꿔볼 필요가 있습니다. **데이터가 깨끗하면 AI가 사용할 준비가 된 것일까요?** **데이터가 많으면 AI Ready한 것일까요?** 그리고 가장 중요한 질문, **도대체 ‘AI가 사용할 준비가 된 데이터’란 무엇일까요?** 
 
이 질문을 체계적으로 다룬 연구가 Data Readiness for AI: A 360-Degree Survey입니다. 이 연구에서는 AI를 위한 Data Readiness를 설명하면서 **데이터의 품질(Quality), 접근성(Accessibility), 적합성(Suitability)**, 즉 데이터의 품질뿐 아니라 접근 가능성과 AI 목적에 대한 적합성을 함께 강조합니다. 여기에서 특히 중요한 단어가 Suitability(적합성), 즉 “**이 데이터가 내가 풀려는 AI 문제에 실제로 적합한가?**”입니다.
 
 
### Tidy Data -> Clean Data -> AI Ready Data
이 관점에서 보면 우리가 오랫동안 이야기해 온 Tidy Data, Clean Data, 그리고 AI Ready Data의 차이가 분명하게 드러납니다. 각 개념이 던지는 핵심 질문을 살펴보면 다음과 같습니다.
 
* **Tidy Data**: 분석할 수 있도록 행과 열이 제대로 구성되어 있는가?
* **Clean / Quality Data**: 값이 정확하고, 빠진 값이나 중복이 없으며 일관적인가?
* **AI Ready Data**: **그래서 이 데이터를 이 AI가 실제로 사용할 수 있는가?**

 
다시 말해 데이터가 깔끔하게 정리되어 있다는 것과 AI가 잘 사용할 수 있다는 것은 같은 이야기가 아닙니다. 이 글을 관통하는 가장 핵심적인 한 문장을 꼽는다면 바로 이것입니다.

 
 
### Clean Data ≠ AI Ready Data
이러한 변화는 최근 AI 개발 방식의 변화와도 맞닿아 있습니다. 과거의 AI 개발은 대체로 Model-centric AI, 즉 “같은 데이터를 두고 어떻게 더 좋은 모델을 만들 것인가?”에 집중해 왔습니다. 새로운 모델 구조를 설계하고, 하이퍼파라미터를 조정하고, 학습 방식을 개선하면서 성능을 높이는 접근입니다.
 
그런데 모델이 점점 표준화되고 Pre-trained Model과 Foundation Model을 가져다 쓰는 시대가 되면서 다른 질문이 중요해지기 시작했습니다.
 
> **“모델을 더 바꾸는 대신 데이터를 더 좋게 만들면 어떨까?”**

 
반대로 Data-centric AI는 효과적이고 효율적인 AI 시스템을 만들기 위해 데이터를 "체계적이고 확장 가능한 방식(systematically and at scale)"으로 개선하는 패러다임으로 설명합니다. 중요한 점은 더 많은 데이터를 무조건 모으자는 것이 아니라, **AI가 해결하려는 문제에 "더 적합한 데이터(more appropriate data)"를 만드는 것**입니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/d019986a-1095-480a-b817-a6c8ef93ae78/image.png)
AI 기반 시스템 개발을 위한 새롭고 상호 보완적인 패러다임으로서의 데이터 중심 AI (출처: Data-Centric Artificial Intelligence)
 
 
위 그림은 두 접근의 차이를 아주 단순하게 보여줍니다.
* **Model-centric AI**: 데이터를 비교적 고정해 두고, "**AI 모델을 어떻게 더 잘 만들 것인가?**"를 반복해서 묻습니다.
* **Data-centric AI**: 모델을 비교적 고정한 상태에서 "**데이터를 어떻게 더 잘 만들 것인가?**"를 반복합니다.

 
하지만 두 접근은 경쟁 관계가 아니라 상호보완적입니다. 좋은 모델도 필요하고 좋은 데이터도 필요합니다.
 
다만 AI 모델을 API로 호출하고 공개된 파운데이션 모델을 활용할 수 있는 지금의 개발 환경에서는, 기업이 직접 차별화하기 어려운 모델보다 자신의 문제를 설명하는 데이터의 품질과 구조를 어떻게 개선할 것인가가 더 중요한 문제가 될 수 있습니다.
 
바로 이 지점에서 Data-centric AI와 AI Ready Data가 연결됩니다. Data-centric AI가 “데이터를 지속적으로 개선하자”​는 개발 패러다임이라면, **AI Ready Data**는 한 걸음 더 나아가 “**그렇다면 어떤 상태의 데이터가 AI가 사용할 준비가 된 데이터인가?**”​를 묻는 개념으로 볼 수 있습니다.

 
 
## 어떤 데이터가 AI Ready Data일까?
기존의 Data Quality가 주로 "데이터 자체의 품질이 좋은가?"를 물었다면, AI 시대에는 질문이 훨씬 많아집니다. 주로 아래와 같은 핵심적인 질문들을 던져야 합니다.
 
* 필요한 값이 빠지지는 않았는가?
* AI가 학습해야 할 사례가 충분한가?
* 정답 Label이 제대로 붙어 있는가?
* 특정 종류의 데이터에 지나치게 몰려 있지는 않은가?
* AI가 풀려는 문제와 실제로 관련 있는 변수가 존재하는가?

 
예를 들어 고장예측 모델을 만드는 데 있어서, 직원 사번과 구매 전표가 아무리 정확하게 1억 건 저장되어 있어도 고장예측에는 큰 도움이 되지 않을 수 있습니다. 반대로 진동, 온도, 압력, 부하, 정비 이력과 실제 고장 시점이 정확하게 연결된 10만 건의 데이터가 훨씬 가치 있을 수 있습니다.
 
그래서 AI Ready Data를 생각할 때는 두 질문을 구분해야 합니다.

1. **이 데이터 자체로 좋은 데이터인가?**
2. **이 데이터가 우리가 만들려는 바로 '이 AI'에게 적합한 데이터인가?**

 
 
### 좋은 데이터인가? vs. '이 AI'에게 좋은 데이터인가?
기업 입장에서는 결국 이런 질문을 하게 됩니다.
 
> **"그래서 우리는 어떤 관점으로 데이터를 관리해야 하는 것일까요?"**

 
다음 그림은 이 복잡한 문제를 훨씬 이해하기 쉽게 정리합니다. 이 그림은 AI Data Readiness를 지탱하는 여섯 개의 기둥으로 분류합니다.
 
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/bc0a03e3-655d-4b1b-9f06-c24c6d4f7b58/image.png)
AI를 위한 데이터 준비성 지표 6가지
(출처: Data Readiness for AI: A 360-Degree Survey. Fig.3)
 
 
첫 번째는 **Data Quality**입니다. "데이터 자체의 품질이 좋은가?"를 묻습니다.
정확한지, 빠진 것은 없는지, 중복되거나 잘못된 값은 없는지와 같은 가장 기본적인 영역입니다.
 
두 번째 **Understandability & Usability of Data**는 “이 데이터가 무엇인지 알고 실제로 사용할 수 있는가?”를 묻습니다. 
예를 들어 DB에 `TMP_AVG_01 = 742` 라는 값이 정확하게 저장되어 있어도, TMP_AVG_01이 무엇을 의미하는지 아무도 모른다면 활용하기 어렵습니다. 반대로 이것이 ‘평균 조업 온도’이고, 단위는 ℃이며, 어느 센서에서 측정되고 정상 범위는 얼마인지 Metadata와 설명이 붙어 있다면 742라는 숫자는 비로소 사람이든 AI든 이해할 수 있는 데이터가 됩니다.
 
세 번째 **Data Structure & Organization**은 “AI가 필요한 데이터를 쉽게 찾아서 가져다 쓸 수 있는가?”를 묻습니다. 
같은 설비의 정보가 DB, 개인 PC의 Excel, PDF, 이메일 첨부파일에 흩어져 있다면 데이터는 존재하지만 AI가 활용하기는 어렵습니다
 
네 번째 **Data Governance**는 “이 데이터를 AI가 안전하고 책임 있게 사용해도 되는가?”를 묻습니다. 
개인정보, 접근 권한, 보안, Ownership, 법적·윤리적 사용조건 등이 여기에 해당합니다.
 
그리고 다섯 번째 기둥부터 AI Ready Data의 특징이 더욱 분명해집니다.
**Impact of Data on AI**, 즉 “이 데이터가 실제로 AI를 더 잘하게 만드는가?”입니다. 
데이터가 아무리 정확하고 잘 정리되어 있어도 AI가 풀려는 문제와 아무 관계가 없다면 그 AI에게는 가치가 낮습니다. 고장예측 AI라면 고장과 관계있는 진동이나 온도, 부하, 정비 이력이 중요할 것이고, 계약서 검색 AI라면 계약 조항의 의미와 문서 구조가 중요할 것입니다. 
 
따라서 **Data Quality가 “좋은 데이터인가?”를 묻는다면 Impact on AI는 “이 AI에게 좋은 데이터인가?”를 묻습니다**. 이 작은 차이가 AI Ready Data를 이해하는 데 매우 중요합니다.
 
마지막은 **Fair & Unbiased Data**입니다. 
단순히 “편향이 없는가?”라고 번역하면 이 개념의 일부만 전달됩니다. 기업 AI 관점에서는 “**이 데이터가 AI가 실제로 만나게 될 현실을 충분히 대표하고 있는가?**”라는 질문까지 함께 던지는 편이 이해하기 쉽습니다. 
 
예를 들어, 건설 현장의 안전모 탐지 AI를 맑은 날 낮 시간의 한 현장에서 수집한 데이터로만 학습했다고 생각해 보겠습니다. 실제 현장에는 야간도 있고, 비가 오기도 하며 먼지가 날리고 작업자의 자세와 작업복도 달라집니다. 학습 데이터에서는 잘 작동하던 AI가 실제 현장에서 실패할 수 있습니다. 
 
결국 AI에게 필요한 것은 단순히 편향이 없는 데이터가 아니라 AI가 만나게 될 세계의 다양성을 충분히 담은 데이터입니다.
 
 
### 무엇을 위한 AI Ready Data인가?
앞의 네 기둥(Data Quality, Understandability & Usability, Data Structure & Organization, Data Governance)는 어떤 AI 방법을 사용하느냐와 관계없이 기업 전체가 공통으로 갖춰야 할 기본적인 데이터 기반입니다.
 
반면 뒤의 두 기둥 (Impact of Data on AI와 Fairness & Bias)은 어떤 문제를 어떤 AI로 해결하느냐에 따라 달라집니다. 즉, 개별 AI 과제를 시작할 때마다 다시 물어야 하는 질문이죠.
 
즉, **AI Ready는 데이터 자체에 영구적으로 붙일 수 있는 절대적인 Label이라기 보다 데이터와 AI Use Case 사이의 관계로 보는 것이 더 적절**합니다. 같은 설비 데이터라도 생산량 예측에는 충분히 Ready할 수 있지만 고장예측에는 고장 Label과 진동 데이터가 부족할 수 있고, 작업자 안전 예측에는 아예 필요한 데이터가 없을 수도 있습니다.
 
그렇다면 “이 데이터는 AI Ready한가?”라는 질문만으로는 부족합니다. 한 문장을 더 붙여야 합니다. 

 <div style="border-radius: 4px;padding:22px 20px; background: #F5F5F5; border: 1px solid #D6D6D6;">**“AI-ready for what?” “무엇을 위한 AI Ready Data인가?”**</div>





 
 
## 결국 기업은 어떤 데이터를 준비해야 할까?
이제 처음의 질문으로 돌아가 보겠습니다. "데이터가 깨끗하면 AI가 사용할 준비가 된 것일까요?" 답은 '그것만으로는 부족하다'입니다. 우리가 정리한 개념과 던져야 할 질문을 정리하면 다음과 같습니다. 이 질문들에 답할 수 있어야 비로소 AI Data Readiness를 이야기할 수 있습니다.
 

| 데이터 준비도 | 주요 개념 | 질문 |
| --- | --- | --- |
| Data Quality | 데이터 품질 | **데이터 자체가 제대로 되어 있는가?** |
| Understandability & Usability | 이해·활용 가능성 | **이 데이터가 무엇인지 알고 실제로 사용할 수 있는가?** |
| Data Structure & Organization | 데이터 구조와 조직화 | **AI가 필요한 데이터를 쉽게 찾아서 가져다 쓸 수 있는가?** |
| Data Governance | 데이터 거버넌스 | **이 데이터를 안전하고 책임 있게 사용해도 되는가?** |
| Impact of Data on AI | AI에 대한 데이터의 영향 | **이 데이터가 실제로 AI를 더 잘하게 만드는가?** |
| Fair & Unbiased Data | 공정성·대표성 | **이 데이터가 AI가 만나게 될 현실을 충분히 대표하는가?** |
 
그렇다면 기업의 데이터 전략도, 데이터를 다루는 백엔드 엔지니어도 달라져야 합니다. “AI 시대가 왔으니 우리 회사의 모든 데이터를 먼저 깨끗하게 만들자”는 접근은 현실적으로 비용도 많이 들고 끝도 없습니다. 오히려 순서를 뒤집을 필요가 있습니다.

 <div style="border-radius: 4px;padding:22px 20px; background: #F5F5F5; border: 1px solid #D6D6D6;">**Business Problem → AI Use Case → AI가 해야 할 판단 → 그 판단에 필요한 Data와 Knowledge → Data Readiness 평가 → 필요한 데이터 준비 → AI 적용**</div>

 
고장예측 AI라면 고장 사례와 관련 변수(Feature)의 확보가 중요할 것이고, 사내 생성형 AI나 RAG라면 문서의 의미와 구조, 메타데이터, 최신성과 접근 권한이 중요할 것입니다. Vision 기반 안전 AI라면 다양한 날씨와 시간, 작업환경을 포함한 현실 대표성이 중요합니다. 
 
 
### 무엇을 Ready하게 만들어야 하는지는 AI의 목적에 따라 달라집니다
Data Readiness는 AI 프로젝트를 시작하기 전에 한 번 데이터를 전처리하고 끝내는 작업이 아닙니다. AI를 실제로 사용해 보면 부족한 데이터가 보입니다. 예상하지 못한 현장에서 성능이 떨어지고, 새로운 유형의 질문이 들어오고, 오래된 문서 때문에 잘못된 답변이 만들어집니다.
 
그러면 부족한 데이터를 다시 확보하고, 구조와 메타데이터를 개선하고, 라벨을 수정하고, 다시 평가해야 합니다. **AI 사용 → 성능 평가 → 부족한 데이터 발견 → 데이터 개선 → 다시 AI**라는 순환이 만들어져야 합니다. AI Ready Data는 완성품이라기보다 지속적으로 만들어지는 데이터 상태에 가깝습니다.
 
오랫동안 데이터 분야에서는 **Garbage In, Garbage Out**이라는 말을 사용해 왔습니다. AI 시대에도 여전히 맞는 말입니다. 다만 이제 한 문장을 더 기억할 필요가 있습니다.

 <div style="border-radius: 4px;padding:22px 20px; background: #F5F5F5; border: 1px solid #D6D6D6;">**Clean Data ≠ AI Ready Data**</div>

 
앞으로 기업이 물어야 할 질문은 “우리 회사에는 데이터가 얼마나 많은가?”가 아닐지도 모릅니다. 더 중요한 질문은 이것입니다.
 
> “**우리가 해결하려는 문제를 AI가 이해하고 학습하고 판단할 수 있을 만큼, 필요한 데이터와 지식을 준비해 놓았는가?**”

 
이것이 기업의 AI 경쟁력을 결정하게 될 것입니다. 그리고 여러분이 그 업의 주인공이 될 것입니다.

 
 
 
### 📚 참고 문헌
* [Data Readiness for AI: A 360-Degree Survey — Pasindu A. Hiniduma, Suren Byna, Jean Luca Bez et al.](https://arxiv.org/pdf/2404.05779)
* [Data-Centric Artificial Intelligence — Johannes Jakubik, Michael Vössing, Niklas Kühl, Jannis Walk, Gerhard Satzger](https://arxiv.org/pdf/2212.11854)

 
 
### 📌 함께 읽으면 좋은 글
* [바이브 코딩을 넘어 AI Native Engineering으로: AI 시대 개발자 로드맵](https://community.programmers.co.kr/post/13962?utm_source=&utm_medium=&utm_campaign=&utm_content=data_13962)
* [바이브 코딩 앱이 현업 서비스가 되기 전에 반드시 넘어야 할 백엔드의 벽](https://community.programmers.co.kr/post/13861?utm_source=&utm_medium=&utm_campaign=&utm_content=data_13861)
* [LLM 성능의 '천장'을 깨는 시대: 백엔드 엔지니어를 찾아라](https://community.programmers.co.kr/post/13729?utm_source=&utm_medium=&utm_campaign=&utm_content=data_13729)

 
 

![정경문 작가님 프로필 카드.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/5e64c3af-26b1-4b64-9a3f-b5ec14236695/%E1%84%8C%E1%85%A5%E1%86%BC%E1%84%80%E1%85%A7%E1%86%BC%E1%84%86%E1%85%AE%E1%86%AB%20%E1%84%8C%E1%85%A1%E1%86%A8%E1%84%80%E1%85%A1%E1%84%82%E1%85%B5%E1%86%B7%20%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%84%91%E1%85%B5%E1%86%AF%20%E1%84%8F%E1%85%A1%E1%84%83%E1%85%B3.png)

AI 시대 데이터 관리의 새로운 기준: 저장에서 활용 가능성으로 (AI Ready Data)

온톨로지와 Agentic AI 진화

🤔 *“나는 전공생인데, 부트캠프로 백엔드 공부를 다시 하고 싶어요!”*
🥺 *"아예 개발 해보지도 않았는데 어떤 과정을 들어야 할까요?"*
 
프로그래머스 데브코스를 알아보는 분들이 가장 궁금해하시는 내용인데요.
나의 경험과 현재 상황에 따라 어떤 과정이 필요한지 살펴볼까요?
 
![제목을 입력해주세요. (7).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/99852d32-e708-40f4-9334-4305100da507/%E1%84%8C%E1%85%A6%E1%84%86%E1%85%A9%E1%86%A8%E1%84%8B%E1%85%B3%E1%86%AF%20%E1%84%8B%E1%85%B5%E1%86%B8%E1%84%85%E1%85%A7%E1%86%A8%E1%84%92%E1%85%A2%E1%84%8C%E1%85%AE%E1%84%89%E1%85%A6%E1%84%8B%E1%85%AD.%20%287%29.png)
 
프로그래머스는 **백엔드 개발을 하나의 방향이 아닌, 여러 성장 경로로 확장할 수 있는 핵심 직무**로 보고 있습니다. 그래서 백엔드 개발자를 목표로 하는 분들을 위해 아래와 같이 **총 3가지 백엔드 특화 과정**을 운영하고 있습니다.
 
3가지 백엔드 특화 과정은 백엔드 데브코스, 생성형 AI 활용 백엔드 데브코스, 그리고 백엔드 단기심화 데브코스 과정인데요, 과정별 주요 차이점을 이해하기 쉽도록 표로 정리해 보았습니다.
 
![제목을 입력해주세요. (2).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/18b6254f-6354-4155-9ddd-c183c3b33791/%E1%84%8C%E1%85%A6%E1%84%86%E1%85%A9%E1%86%A8%E1%84%8B%E1%85%B3%E1%86%AF%20%E1%84%8B%E1%85%B5%E1%86%B8%E1%84%85%E1%85%A7%E1%86%A8%E1%84%92%E1%85%A2%E1%84%8C%E1%85%AE%E1%84%89%E1%85%A6%E1%84%8B%E1%85%AD.%20%282%29.png)
 

| 구분 | **생성형 AI 활용 백엔드 데브코스** | **클라우드 기반 백엔드 데브코스** | **백엔드 단기심화 데브코스** |
| --- | --- | --- | --- |
| **수강 자격** | 내일배움카드 발급 가능자 누구나 | 내일배움카드 발급 가능자 누구나 | KDT를 이미 들었어도 수강 가능 |
| **추천 대상자** | 1인 개발을 지향하면서 LLM을 서비스에 연계하고 싶은 분 | 전통적인 백엔드 역량과 클라우드/DevOps에 집중하고 싶은 분 | 단기간에 실무 심화 역량을 끌어올리고 싶은 분 |
| **진행 방식** | 온라인 | 온라인 | 온·오프라인 병행 |
| **기간** | 6개월 | 5.5개월 | 2.5개월 |
| **난이도** | 중하 | 중 | 상 |
| **커리큘럼 핵심** | • Java / Spring 기반 백엔드 핵심 • LLM / 프롬프트 엔지니어링 | •Java / Spring 기반 백엔드 핵심 •Kotlin 마이그레이션 | • MSA 기반 서비스 아키텍처 설계 • Kubernetes 활용한 운영 환경 이해 • Spring AI 기반 서비스 구현 |
| **프로젝트 구성** | • 여행 계획 및 추천 플랫폼 개발 • 전문가 매칭 플랫폼 구현 • end-to-end LLM 프로젝트 | • 메뉴 관리 CRUD 프로젝트 • 자율 REST API 구현 프로젝트 • Kotlin 마이그레이션 실습 • 백엔드 최종 프로젝트 | • 주문·결제 플랫폼 구현 프로젝트(MSA / Kubernetes) • 개인 맞춤형 추천 플랫폼 프로젝트(Spring AI 적용) |
| **랜딩페이지** | [\[상세 내용 확인\]](https://school.programmers.co.kr/learn/courses/25630?utm_source=prgmblog&utm_medium=social&utm_campaign=school_25630_blog&utm_content=25630_banner) | [\[상세 내용 확인\]](https://school.programmers.co.kr/learn/courses/25579?utm_source=prgmblog&utm_medium=social&utm_campaign=school_25579_blog&utm_content=blog_banner) | [\[상세 내용 확인\]](https://school.programmers.co.kr/learn/courses/25629?utm_source=prgmblog&utm_medium=social&utm_campaign=school_25629_blog&utm_content=blog_banner_13335) |

 
표로 정리된 내용에서 조금 더 설명을 드리자면, 백엔드 데브코스와 생성형 AI 활용 백엔드 데브코스는 기본 커리큘럼이 유사합니다. 다만, 클라우드/DevOps에 집중하고, 기존 서비스 개선·전환을 위한 Kotlin 마이그레이션을 학습할지, 혹은 1인 개발자로 성장하기 유리한 LLM 활용 역량을 학습할지에 따라 과정을 선택해 주시면 됩니다. 
 
무엇보다 프로그래머스 데브코스는 현업 경험이 풍부한 강사진과 검증된 수강생 후기를 바탕으로, 과정별로 높은 강의 퀄리티를 꾸준히 유지하고 있기에 어떤 과정을 선택하더라도 **백엔드 개발자로서의 기본기와 실무 역량은 동일하게** 가져갈 수 있는 점 참고 부탁드립니다. 
 
위에서 나에게 적합한 과정을 확인하셨다면, 각 과정별로 어떤 특장점이 있는지 궁금하실텐데요, 해당 포스팅에서만 공개하는, 선발 담당자의 TIP 까지 모두 꼼꼼하게 확인해주세요!
 
 
## 1. `현재 모집 중` 생성형 AI 활용 백엔드 데브코스 
이제 기업은 단순히 백엔드를 구현하는 개발자가 아니라, AI와 API를 결합해 실제 서비스로 확장할 수 있는 개발자를 찾고 있습니다.
 
중요한 건 AI를 써봤다는 경험이 아닙니다. 왜 AI를 선택했는지, 어떤 문제를 해결하기 위해 도입했는지, 그리고 그것을 어떻게 설계에 반영했는지를 시장에서는 더 중요하게 평가합니다.
(단순히 API를 연결한 프로젝트와 AI 활용이 필수적인 구조를 설계한 프로젝트는 분명히 다르거든요🤔)
 
이 과정에는 주로 아래와 같은 분들이 지원하십니다.
 
✔ 컴퓨터공학 전공이지만, 학업에 쫓겨 제대로 된 프로젝트 경험이 부족한 분

✔ 개발에 대한 경험이 없어, Java 문법부터 학습이 필요하신 분

✔ 기존 프로젝트에 AI 활용 경험이 없어 포트폴리오 매력도가 부족한 분

✔ 현재 직무의 미래 가치에 고민이 있는 이직 희망자

✔ 개발 경력은 있지만, 트렌디한 AI 역량을 다시 갖추고 싶은 분
 
ChatGPT나 Gemini를 자주 사용해봤더라도, 작동 원리 이해, 프롬프트 엔지니어링, LLM을 활용한 서비스 구조 설계까지 체계적으로 경험해본 분은 아직 많지 않습니다. 
 
비전공자분들도 학습을 미리 고민하기보다는, 오히려 지금이 기회라고 생각합니다.
아직 많은 사람이 갖추지 못한 역량인 만큼, 시장에서 요구하는 성장 가능성 높은 LLM 역량을 지금 선점해보시길 추천드립니다.
 
### 💡 선발 담당자의 TIP ✨
해당 과정은 백엔드 기본기를 탄탄히 다지면서 LLM을 활용해 프론트 영역까지 확장 가능한 결과물을 설계하도록 구성되어 있어, 필요하다면 1인 개발에 유리한 풀스택 역량까지 어필할 수 있는 포트폴리오로 활용 가능합니다.
 
지원서를 작성하실 때도 “AI 역량이 필요한 이유”와 프로젝트 경험이 있으시다면 “AI를 어떻게 설계에 반영했는지”를 중심으로 정리하시면 좋은 평가를 받는 데 도움이 될 수 있습니다.
 
[![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/0b1692f0-87ab-4575-81ca-f0df0bc45cbf/image.png)](https://school.programmers.co.kr/learn/courses/25630?utm_source=prgmblog&utm_medium=social&utm_campaign=school_25630_blog&utm_content=25630_banner)
 
 
## 2. 클라우드 기반 백엔드 엔지니어링 데브코스
백엔드를 공부하다 보면 이런 순간이 옵니다.
 
✔ CS, OS, 네트워크, 자료구조까지 열심히 공부했지만, 막상 그 지식을 하나의 완성도 있는 결과물로 만들어본 경험은 부족하다고 느낄 때

✔ 프로젝트를 통해 기능 구현에는 성공했지만, 실제 배포 환경에서 트래픽이 몰리면 어떻게 될지 등 확장성과 안정성을 확보한 사례는 없을 때

✔ 개인 프로젝트나 단기 팀 프로젝트만으로는 내 설계 기준이 맞는지, 코드 품질이 실무 기준에서 괜찮은지 객관적으로 점검 받기 어려울 때
 
사실 학교의 전공 수업만으로는 현업에서 실제로 어떤 기술 스택을 쓰는지, 어떤 기준으로 설계를 하는지, 협업은 어떻게 이루어지는지 제대로 경험하기 어렵습니다.
 
클라우드 기반 백엔드 데브코스는 단순히 기능을 구현하는 개발자가 아니라, 트래픽을 고려해 구조를 설계하고, 클라우드 환경에서 확장성과 안정성을 고민하며, 팀 단위 협업 속에서 코드 품질을 검증받고, 실무에서 사용하는 트랜디한 기술 스택으로 프로젝트를 완성하는 과정입니다.
 
### 💡 선발 담당자의 TIP ✨
**클라우드/DevOps에 집중된 커리큘럼과 Kotlin 마이그레이션 프로젝트 경험이** 해당 과정의 큰 차별점입니다.
 
탄탄한 백엔드 개발 역량을 기반으로 기존 레거시 코드를 이해하고, 코드 구조를 분석하며, 이미 운영되고 있는 시스템을 점진적으로 개선해보는 경험은 신입 포트폴리오에서 쉽게 보기 어려운 사례입니다.
 
단순히 새로운 프로젝트를 만들어봤다는 경험이 아니라, **기존 시스템을 이해하고 개선해본 실무형 경험**이라는 점에서 채용 시장에서 충분히 차별화 포인트가 될 수 있습니다.
 
채용 지원서를 작성하실 때는 데브코스에서 “무엇을 구현했다”보다 “왜 그렇게 설계했는지”, “마이그레이션 과정에서 어떤 고민과 개선이 있었는지”를 중심으로 정리하여 차별화된 포트폴리오를 제작해보세요 😉
 
[![image2.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/b0679e8c-e41f-44af-9f1f-289f9e8e4bd8/image2.png)](https://school.programmers.co.kr/learn/courses/25579?utm_source=prgmblog&utm_medium=social&utm_campaign=school_25579_blog&utm_content=blog_banner)
 
 
## 3. `현재 모집 중` 백엔드 단기심화 데브코스
데브코스에는 개발을 처음 시작하는 분들도 많지만, 1~10년 차 개발자들도 꾸준히 지원하고 있다는 사실, 알고 계셨나요?
 
이미 백엔드 개발자로 일하고 있더라도 기술 트렌드는 빠르게 바뀌기에 지금 시장에서 요구하는 기술을 이해하고 설명할 수 있어야 합니다. 
 
그렇기에 재직 중인 개발자분들도 역량을 한 단계 끌어올리기 위해 퇴사 후 백엔드 단기심화 데브코스를 수강하고 단기간 내에 취업하고 계십니다. 
(물론, 아직 직무 경험이 없어도, 실력이 충분하다면 누구나 합류 가능합니다 😉)
 
특히나 해당 과정은 국내 기업에서 가장 주목하고 있는 MSA 아키텍쳐, Kubernetes 기반 운영 환경, Spring AI 활용 설계를 중심으로, 단순 이론 학습이 아니라 프로젝트에 직접 적용해 9주 안에 심화 포트폴리오를 완성하도록 설계되었습니다. 
 
현재까지는 해당 기술 스택은 들어 봤지만, 구조와 활용 방식을 명확히 이해하고 직접 프로젝트에 반영해 본 신입 개발자는 많지 않습니다. 그렇기에 해당 심화 기술을 빠르게 습득하여 채용 시장에서 우위를 점할 수 있도록, 그 차이가 곧 경쟁력이 되도록 학습을 시작하시길 추천드립니다.
 
 
### 💡 선발 담당자의 TIP ✨
백엔드 단기심화 데브코스는 기초를 배우는 과정이 아닙니다. 이미 학습 혹은 실무 경험이 있는 개발자가 **단기간에 심화 포트폴리오를 제작하는 과정**입니다. 
 
기본적으로 CRUD는 물론, API 설계, 구현, 배포까지 프로젝트 전 과정을 무리 없이 수행할 수 있는 분들을 우선적으로 선발하고 있습니다. 지원서를 작성하실 때는 수행한 프로젝트, 맡은 역할, 사용한 기술 스택, Java 및 백엔드 이해도 등 본인의 실력을 어필할 수 있는 내용을 구체적으로 작성해 주세요.
 
**MSA, Kubernetes, Spring AI가 어떤 기술이고, 왜 필요한지**에 대한 기본적인 이해가 있다면 전반적으로 좋은 평가를 받으실 수 있습니다
 
[![image3.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/1dd2bea7-6b9a-45aa-857e-873a1f3ab9a5/image3.png)](https://school.programmers.co.kr/learn/courses/25629?utm_source=prgmblog&utm_medium=social&utm_campaign=school_25629_blog&utm_content=blog_banner_13335)
 
백엔드 개발자를 목표로 한다면, 가장 중요한 건 어떤 과정을 선택하느냐보다 지금의 나에게 맞는 성장 환경을 선택해야 합니다. 
 
프로그래머스 데브코스는 백엔드 개발이라는 하나의 목표를 중심으로, 각자의 출발점과 다음 단계를 고려해 서로 다른 3가지 백엔드 성장 경로를 준비했습니다.
 
![백엔드 과정 선택(3).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/450e5ae7-d2bc-413b-afee-2fb571c2487d/%E1%84%87%E1%85%A2%E1%86%A8%E1%84%8B%E1%85%A6%E1%86%AB%E1%84%83%E1%85%B3%20%E1%84%80%E1%85%AA%E1%84%8C%E1%85%A5%E1%86%BC%20%E1%84%89%E1%85%A5%E1%86%AB%E1%84%90%E1%85%A2%E1%86%A8%283%29.png)
 
어떤 과정을 선택하든, 여기서 쌓게 될 경험은 단순한 수강 이력이 아니라 취업 시장에서 설명할 수 있는 실무 경험으로 남게 됩니다.
 
지금의 나에게 가장 잘 맞는 백엔드 데브코스를 선택하고, 다음 채용 공고 앞에서 자신 있게 지원서와 포트폴리오를 제출하는 지원자가 될 수 있도록 데브코스가 곁에서 함께 응원하겠습니다!

백엔드 vs 생성형 AI 활용 백엔드 vs 백엔드 단기심화, 단계별로 추천하는 데브코스 가이드

단순한 CRUD 구현을 넘어 실제 서비스 환경에서의 백엔드 설계와 문제 해결 경험을 쌓고자 백엔드 단기심화 2기에 참여한 이유종 님의 후기 인터뷰입니다.
MSA 구조, 대용량 정산 배치, LLM을 활용한 추천 기능까지, 짧지만 밀도 높은 과정 속에서 실무에 가까운 경험을 쌓았다고 하는데요. 유종 님이 경험한 기술적 도전과 성장 스토리를 지금 바로 확인해보세요!
 
 
## 안녕하세요. 간단한 자기소개 부탁드립니다.
안녕하세요! 컴퓨터 공학을 전공하고 오는 2월 졸업을 앞두고 있는, 백엔드 단기심화 2기 수료생 이유종입니다.
 
학부 수업과 동아리, 공모전을 통해 Spring Boot 기반 백엔드 개발을 경험했지만, 취업을 준비하며 단순한 기능 구현을 넘어 실제 서비스처럼 여러 도메인과 데이터가 얽힌 구조 속에서 발생하는 문제를 다뤄보고 싶어 단기심화 데브코스 2기에 참여하게 되었습니다.
 
 
![스크린샷 2026-02-09 오후 2.02.18.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/c15ef477-d2b5-432a-bd0b-c6aa42b87daf/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202026-02-09%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%202.02.18.png)
 
 
## 백엔드 단기심화 과정에 참여하게 된 계기는 무엇인가요?
취업을 준비하며 그동안 진행했던 프로젝트들을 정리해 보니, 대부분이 CRUD 구현 중심이라 깊이 있는 백엔드 개발 경험이 많이 부족하다는 것을 느꼈습니다.
 
백엔드 단기심화 데브코스는 비교적 짧은 기간 안에 혼자서는 공부하기 어려운 다양한 기술 스택을 배우고, 배운 내용을 바로 팀 프로젝트에 적용해 볼 수 있는 점이 매력적인 과정이라 느꼈습니다.
 
특히 **MSA, 대용량 처리, AI 활용처럼 최근 기업들이 실제로 관심을 가지고 있는 주제들을 학습하고 프로젝트에 활용**해 볼 수 있기에, 저의 포트폴리오를 보완하기에 딱 알맞은 과정이라고 생각해 선택하게 되었습니다.
 
 
## 타 기관도 많지만, 특별히 프로그래머스 데브코스를 선택한 이유는 무엇인가요?
여러 과정을 비교했을 때, 프로그래머스 데브코스는 **실제 실무에서 쓰이는 기술 스택을 중심으로 커리큘럼이 구성**되어 있다는 점이 마음에 들었습니다. 또한 비교적 교육 기간이 짧아 취업 준비의 흐름을 크게 끊지 않으면서도, 효과적으로 포트폴리오를 보완할 수 있다는 점도 데브코스를 선택하게 된 이유 중 하나였습니다.
 
 
## 백엔드 단기심화 과정의 실제 난이도는 어떠했나요?
저의 경우 깊이 있는 백엔드 경험이 많지 않은 상태에서 과정에 참여했고, 다루는 주제 역시 심화 내용이 많고 기간도 짧은 편이다 보니 따라가는 데 벅차게 느껴지는 순간도 있었습니다.
 
하지만 그만큼 밀도 있게 압축해서 배우는 과정이라 느꼈고, 단순히 강의를 듣고 끝나는 것이 아니라 **배운 내용을 직접 적용해 보며 한층 더 깊이 있게 이해**할 수 있었던 것 같습니다.
 
과정이 끝나고 돌아보니, 기술적으로 많은 부분을 배우고 얻어 간 시간이라고 느꼈습니다.
 
 
## '이건 진짜 심화 과정이다'라고 느꼈던 학습 포인트가 있다면 무엇인가요?
단순히 기능을 구현하는 것에서 그치지 않고, **왜 이런 구조로 설계했는지, 이 방식이 확장성이나 유지보수에 어떤 영향을 주는지까지 고민**하게 하는 과정이었습니다.
 
서비스 분리, 트랜잭션 처리, 데이터 정합성 부분을 직접 부딪혀 보며, 이전에는 이론으로만 알고 있었던 개념들을 실제 문제로 마주하고 해결해 나가는 과정 속에서 이 과정이 왜 '심화 과정'인지 실감할 수 있었습니다.
 
 
## 백엔드 단기심화 과정이 포트폴리오 작성에 어떤 도움이 되었나요?
이전에 진행했던 프로젝트는 CRUD 중심의 구현에서 크게 벗어나지 않아, 자소서나 포트폴리오를 작성할 때 기술적인 깊이 측면에서 아쉬운 부분이 많았습니다.
 
하지만 이번 과정을 통해 새로운 기술을 학습하고 직접 적용해 보면서, **왜 해당 기술을 선택했는지, 성능이나 데이터 정합성을 어떻게 고려했는지** 등 다양한 요소를 고민하며 구현해 볼 수 있었습니다.
 
더불어 어떤 고민을 거쳐 기술을 선택했고, 어떤 문제를 어떻게 해결했는지 명확하게 설명할 수 있게 된 점이 포트폴리오 측면에서 가장 의미 있는 변화였던 것 같습니다.
 
 
## 백엔드 단기심화에서 진행한 프로젝트는 어땠나요? 간단한 서비스 소개와 담당했던 역할도 설명해 주세요.
저희 팀이 개발한 서비스는 '**마이루틴**'**이라는 오픈마켓 플랫폼**입니다. 판매자가 자유롭게 상점을 개설해 상품을 판매할 수 있으며, 사용자는 반복적으로 구매하는 상품에 대해 원하는 주기를 설정해 정기 구독 형태로 자동 주문할 수 있다는 점이 차별화 요소입니다.
 
 
![스크린샷 2026-02-09 오후 1.13.24.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/2c8961c4-da9f-4e18-a12d-a1155480276d/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202026-02-09%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%201.13.24.png)
⬆️ 최종 프로젝트 - 오픈마켓 플랫폼 '마이루틴'
 
![스크린샷 2026-02-09 오후 1.13.40.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/3650b90e-6478-4e04-8324-304f7b991709/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202026-02-09%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%201.13.40.png)
⬆️ 프로젝트 아키텍처
 
 
저는 **주문과 정산 도메인을 주로 담당**했습니다. 주문의 경우, 장바구니나 정기 구독을 통해 요청이 들어오면 상품 서비스에 재고 선점 요청을 보내고, 그 결과에 따라 주문 생성과 결제가 이어지도록 흐름을 설계했습니다.
 
정산은 반복적으로 대량의 데이터를 안정적으로 처리해야 하는 작업인 만큼, Spring Batch를 활용해 매월 판매자별 매출 집계와 수수료 계산, 정산금 지급 과정이 자동으로 처리되도록 구현했습니다.
 
또한 상품 추천 기능의 경우, 장바구니와 최근 주문 데이터를 기반으로 LLM을 활용해 사용자 취향을 문장 형태로 추출하고, 이를 임베딩하여 유사도 기반 추천에 활용하는 흐름을 구현했습니다.
 
 
### 🔍 최종 프로젝트 보러가기
* [최종 프로젝트 배포 링크](https://myroutine.store)
* [GitHub](https://github.com/prgrms-be-adv-devcourse/beadv2_2_Node5_BE)
 
 
## 프로젝트 과정에서 어려운 과제에 도전했던 경험이나, 기술적으로 한 단계 성장했다고 느꼈던 순간이 있다면 공유해 주세요.
프로젝트 초반에는 정산 로직을 별도의 모듈로 분리해 둔 상태였지만, 서버 자원 제약과 배치 작업을 별도의 서비스로 분리해야 하는 상황이 겹치면서 구조를 다시 고민하게 되었습니다.
 
이 과정에서 단순히 로직을 나누는 문제가 아니라, 어떤 데이터와 책임을 어느 서비스가 가져가는 것이 적절한지까지 다시 정리해야 했습니다. 특히 배치 서비스는 여러 도메인의 데이터를 함께 다뤄야 했기 때문에, 데이터 접근 방식을 어떻게 해야 할지에 대한 고민이 컸습니다.
 
결국 배치 관련 정산 작업은 배치 서비스로, 나머지 정산 비즈니스 로직은 판매자 도메인이 포함된 멤버 서비스로 분리하고, 두 서비스에서 함께 사용하는 정산 도메인은 공통 모듈로 분리해 공유하도록 구조를 정리했습니다.
 
이 경험을 통해 서비스 분리는 단순한 코드 분리가 아니라, 데이터 흐름과 책임 범위를 함께 고려해야 하는 설계 문제라는 것을 배울 수 있었습니다.
 
 
## 멘토링 중 인상 깊었던 코드 리뷰나 피드백은 무엇이었나요?
멘토링 시간마다 각자 개발한 파트를 설명드리면, 멘토님께서 놓친 설계 포인트나 추가로 보완하면 좋을 부분을 **구체적인 액션 아이템으로 짚어주셨던 점**이 특히 인상 깊었습니다.
 
덕분에 막연하게 부족하다는 느낌에 그치는 것이 아니라, 실무 관점에서 어떤 부분을 더 공부하고 보완해야 할지 명확한 방향성을 잡을 수 있었습니다.
 
또한 현직자분들과 직접 만나 소통할 기회가 많지 않은데, 업계 분위기나 취업 준비에 대한 현실적인 이야기를 들을 수 있었던 점 역시 큰 도움이 되었습니다.
 
 
![스크린샷 2026-02-09 오후 1.51.08.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/41197e0d-733d-47ae-a79e-d4aa3a1a2c9b/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202026-02-09%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%201.51.08.png)
⬆️ 멘토링 내용 일부
 
![스크린샷 2026-02-09 오후 1.53.58.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/3657f7cf-8b98-4c2f-933a-c9aa29663d52/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202026-02-09%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%201.53.58.png)
⬆️ 코드 리뷰 피드백 정리 내용 일부
 
 
## 백엔드 단기심화 과정이 취업 준비 과정에서 어떤 부분에 가장 도움이 되었나요?
타 부트캠프 대비 **짧은 기간 안에 팀 프로젝트 경험을 통해 포트폴리오를 보완할 수 있었던 점이 가장 큰 도움**이 되었습니다. 기존에는 단순한 기능 구현 위주의 경험이 많았다면, 이번 과정에서는 설계와 구조까지 함께 고민하며 구현해 볼 수 있었습니다.
 
강사님께서도 기술적인 성장에 많은 도움을 주셨습니다. 고민되는 부분에 대해 다양한 해결 방향을 함께 고민해 주시고, 실무에서는 어떻게 접근하는지도 함께 설명해 주셔서 현업 관점을 들을 수 있었던 점이 큰 도움이 되었습니다.
 
이외에도 개인별 면담을 통해 저의 현재 상황에 맞는 조언을 들을 수 있었고, 현직자분들의 취업 특강을 통해 업계 분위기와 최근 흐름을 접할 수 있었던 점도 의미 있었습니다.
 
전체적으로 단순한 교육을 넘어 취업 준비 과정 전반에 있어서 실질적인 도움이 되었던 것 같습니다.
 
 
## 백엔드 단기심화 과정은 어떤 분들에게 잘 맞는 과정이라고 생각하시나요?
기본적인 백엔드 개발 지식과 경험은 있지만, **실무 감각이나 설계 경험이 부족하다고 느끼는 분들에게 특히 잘 맞는 과정**이라고 생각합니다.
 
단순 CRUD를 넘어 실제 서비스 환경을 고려한 구조 설계를 경험해 보고 싶은 분, 단기간에 몰입하여 협업 프로젝트 경험을 쌓고 싶은 분들에게도 잘 맞는 과정이라고 생각합니다.
 
 
## 백엔드 단기심화 과정을 마친 지금, 어떤 개발자로 성장하고 싶으신가요?
서비스의 요구사항과 현실적인 제약을 함께 고려해 **상황에 맞는 적절한 설계 방식을 판단하고 구현할 수 있는 백엔드 개발자**로 성장하고 싶습니다. 복잡한 요구를 효율적으로 처리하고 안정성과 확장성을 갖춘 서비스를 만드는 것이 목표입니다.
 
 
## 수강을 고민 중인 분들께 추천의 한마디 부탁드립니다!
혼자서는 경험하기 어려운 내용들을 짧은 기간 동안 몰입하여 경험해 볼 수 있다는 게 백엔드 단기심화 데브코스의 가장 큰 장점이라고 생각합니다.
 
백엔드 개발 기초는 어느 정도 갖췄지만, 깊이 있는 백엔드 개발 경험을 통해 한 단계 더 성장하고 싶은 분들에게 추천드립니다!
 
다만 과정이 짧은 만큼 밀도 있게 진행되기 때문에, 수동적으로 따라가기보다는 **스스로 고민하고 학습하려는 자세가 있어야 많이 얻어 갈 수 있는 과정**이라고 생각합니다. 
 
 
*강의 운영 사정에 따라 세부 프로그램 내용은 변경될 수 있습니다.*
 
 
[![DEV-BE-DEEP-coding-test-02(1456x180).jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/e3332bf8-d582-42d1-9a62-7f39fbcaf445/DEV-BE-DEEP-coding-test-02%281456x180%29.jpg)](https://school.programmers.co.kr/learn/courses/25629?utm_source=prgmblog&utm_medium=social&utm_campaign=school_25629_sales&utm_content=blog_banner_13335)

[데브코스 후기] 단순 기능 구현을 넘어 실제 서비스로! 단기간에 포트폴리오까지 보완했어요 - 백엔드 단기심화 2기 이유종 님

요즘 개발자들 사이에서 이런 고민을 종종 듣습니다. "AI 코딩 도구를 쓰기 시작한 뒤로 코드는 빨리 나오는데, 왜 실력이 늘지 않을까?" 저도 비슷한 경험을 했습니다. AI 도구를 처음 쓰던 날, 마치 슈퍼파워를 얻은 것 같은 기분이었습니다. 몇 시간씩 걸리던 기능 구현이 30분 만에 끝나고, 모르는 문법도 즉시 해결됐습니다. 생산성이 폭발적으로 올라간 것 같아서 매일 퇴근길이 뿌듯했습니다.
 
그런데 시간이 지날수록 이상한 느낌이 들기 시작했습니다. 코드는 쌓이는데, 성장하는 느낌이 들지 않았습니다. 새로운 문제를 마주했을 때 여전히 AI 없이는 막막했고, 내가 직접 작성한 코드의 원리를 설명하지 못하는 순간이 있었습니다. AI를 쓰기 전보다 코드는 많이 작성했는데, 실력은 그만큼 늘지 않은 것 같은 묘한 불안감이었습니다.
 
이것은 저만의 이야기가 아닙니다. AI 코딩 도구가 보편화되면서 많은 주니어 개발자들이 비슷한 경험을 하고 있습니다. 도구 자체가 문제는 아닙니다. 망치가 나쁜 도구가 아니듯, AI 코딩 도구도 잘 쓰면 아주 강력한 무기가 될 수 있습니다. 문제는 어떻게 쓰느냐에 있습니다. 같은 도구를 써도 빠르게 성장하는 개발자가 있는 반면, 도구에 기대다 정체되는 개발자가 있습니다. 그 차이는 어디서 오는 걸까요.
 
 
## AI에 끌려다니는 개발자의 3가지 패턴
![스크린샷 2026-03-09 오전 10.00.53.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/26e00411-7794-4950-a1be-13f45460595f/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202026-03-09%20%E1%84%8B%E1%85%A9%E1%84%8C%E1%85%A5%E1%86%AB%2010.00.53.png)
(이미지 출처: 픽사베이)
 
먼저, 잘못된 사용 패턴부터 짚어보겠습니다. 이 패턴들은 단독으로 나타나기보다 서로 얽혀 함께 나타나는 경우가 많습니다. 아래 내용을 보며 내 모습과 얼마나 겹치는지 솔직하게 점검해보세요.
 
### 이해 없는 복붙
신입 개발자 A씨는 페이지네이션 기능을 구현해야 했습니다. AI 코딩 도구에 "페이지네이션 기능 만들어줘"라고 입력하자 깔끔한 코드가 생성됐고, 테스트도 통과했습니다. A씨는 코드를 PR에 올렸습니다.
 
다음 날 코드 리뷰에서 팀장이 물었습니다. "이 offset 계산 로직, 왜 이렇게 짰어요?"
A씨는 말문이 막혔습니다. 어떻게 동작하는지는 어렴풋이 알겠지만, 왜 그렇게 구현했는지는 설명할 수 없었습니다. 내 손을 거친 코드이지만, 그 안에 내 생각은 없었던 겁니다.
 
이것이 바로 '이해 없는 복붙'의 핵심 문제입니다. 코드가 동작한다는 것과, 그 코드를 이해한다는 것은 전혀 다른 이야기입니다. AI가 생성한 코드를 그대로 붙여 넣는 것은 누군가가 쓴 답안지를 그대로 베끼는 것과 비슷합니다. 시험은 통과할 수 있어도, 그 과목을 이해했다고 보기는 어렵습니다.
 
더 큰 문제는 이것이 누적된다는 점입니다. 하나의 개념을 이해하지 못한 채 넘어가면, 그 다음 개념을 이해하기는 더 어려워집니다. 프로그래밍은 개념들이 서로 연결되어 있기 때문에, 중간에 구멍이 생기면 그 위에 쌓이는 것들도 흔들리기 쉽습니다. 당장은 코드가 잘 돌아갈지 몰라도, 조금 다른 상황이 생기면 대처하기 어려워집니다.
 
### 너무 이른 질문
저도 한때 이 함정에 깊이 빠졌던 적이 있습니다. 에러 메시지가 뜨면 읽어보기도 전에 바로 AI에게 붙여넣었습니다. 30초 만에 해결책이 나오니 빠르다는 생각이 들었습니다. 하루에 열 개의 문제를 처리하기도 했습니다. 꽤 생산적인 것처럼 느껴졌습니다.
 
그런데 한 달이 지나도 비슷한 에러가 나오면 여전히 AI에게 물어봐야 했습니다. 문제를 해결한 것이 아니라, AI가 해결하는 과정을 지켜본 것이었기 때문입니다.
 
스스로 문제를 붙잡고 씨름하는 시간에는 생각보다 많은 일이 일어납니다. 에러 메시지를 직접 읽고 해석하는 능력이 생깁니다. 어디서부터 추적해야 할지 감을 잡는 훈련이 됩니다. 가설을 세우고 검증하고, 틀리면 다시 세우는 사고 패턴도 자연스럽게 몸에 배게 됩니다. 그리고 결정적으로, 스스로 막힌 문제를 뚫었을 때 얻는 성취감이 다음 문제를 해결하는 동력이 됩니다.
 
이 과정을 AI에게 넘겨버리면 코드는 나오지만 개발자는 성장하지 않습니다. 빠르게 답을 얻는 대신, 느리게 배울 수 있는 기회를 잃게 되는 셈입니다. 물론 모든 문제를 혼자 해결하라는 뜻은 아닙니다. 적절한 타이밍이 있습니다. 충분히 고민하고 시도해본 다음에 AI에게 질문하는 것과, 고민 없이 바로 던지는 것은 결과가 다릅니다.
 
### 무비판적 수용
개발자 B씨는 사용자 인증 기능을 AI의 도움으로 빠르게 구현했습니다. 코드는 깔끔했고, 기본 동작도 문제없이 작동했습니다. 하지만 몇 주 뒤 보안 리뷰에서 토큰 만료 처리가 빠져있다는 것이 발견됐습니다. 만료된 토큰으로도 계속 접근이 가능한 심각한 취약점이었습니다. AI가 틀렸던 겁니다.
 
AI 코딩 도구는 종종 자신감 넘치게 틀립니다. 문법은 맞아 보이고 그럴듯하게 생겼지만, 보안 취약점을 놓치거나, 엣지 케이스를 고려하지 않거나, 프로젝트의 특수한 맥락을 무시한 코드를 내놓은 경우가 생각보다 자주 있습니다. AI는 전반적인 패턴은 잘 알지만, 지금 내 코드베이스의 특수한 상황, 우리 팀의 컨벤션, 서비스의 비즈니스 로직은 모릅니다.
 
AI의 출력을 검증해야 할 코드가 아니라 정답으로 받아들이는 순간, 문제는 시작됩니다. 특히 보안, 에러 처리, 동시성 관련 코드에서 이런 문제가 자주 발생합니다. 눈에 잘 보이지 않는 부분이라 그냥 넘어가기 쉽기 때문입니다. 결국 나중에 큰 대가를 치르게 됩니다.
 
 
## AI를 잘 쓰는 개발자의 3가지 습관
![스크린샷 2026-03-09 오전 11.19.10.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/04b944d6-6e07-43ff-a510-dee807e33687/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202026-03-09%20%E1%84%8B%E1%85%A9%E1%84%8C%E1%85%A5%E1%86%AB%2011.19.10.png)
(이미지 출처: ChatGPT 생성)
 
그렇다면 AI 코딩 도구를 제대로 활용하는 개발자들은 무엇이 다를까요? 그들이 AI를 덜 사용하는 것은 아닙니다. 오히려 더 많이 사용합니다. 차이는 어떻게 사용하느냐에 있습니다.
 
### AI를 답이 아닌 대화 상대로 사용한다
AI를 잘 쓰는 개발자들은 완성된 코드를 요청하지 않습니다. 대신 이렇게 접근합니다. 먼저 스스로 방향을 잡습니다. "이 기능을 구현하려면 어떤 접근 방법이 있을까?" 혼자 10분이라도 먼저 고민해봅니다. 
 
그 다음, AI에게 자신의 방향을 검토해달라고 합니다. "나는 이렇게 구현하려고 하는데, 이 접근법의 문제점이 뭔지 알려줘." 혹은 "이렇게 구현했는데, 더 나은 방법이 있으면 알려줘."
 
이렇게 접근하면 두 가지 장점이 있습니다.
첫째, AI의 답변이 훨씬 잘 이해됩니다. 이미 스스로 고민한 상태에서 답변을 받기 때문에, AI가 왜 그런 방법을 제안하는지 맥락이 잡힙니다.
둘째, 내 생각의 흔적이 남습니다. 문제를 어떻게 쪼갰는지, 어떤 장단점을 따져보았는지가 차곡차곡 쌓입니다. 이런 과정이 결국 진짜 실력으로 이어집니다.
 
저는 이 과정을 짝꿍과 함께 코딩하는 것에 비유합니다. 운전으로 치면, 핸들은 내가 잡고 AI는 옆에서 길을 알려주는 역할입니다. 어디로 갈지는 내가 정하고, AI는 "거기서 좌회전하면 막히니까 우해전 해봐"처럼 내가 미처 보지 못한 선택지를 알려주는 것입니다.
 
### 코드를 받은 후 반드시 설명해본다
AI에게 코드를 받은 뒤 바로 붙여넣지 않습니다. 대신 이렇게 해봅니다. 그 코드를 처음 보는 동료들에게 설명한다고 가정하고, 한 줄씩 읽으면서 스스로에게 설명해보는 것입니다.
 
"이 함수는 사용자 ID를 받아서... 여기서 await를 쓰는 이유는 비동기 처리 때문이고... 이 조건문은 토큰이 없을 때 예외 처리를 하는 건데..."
 
이렇게 설명하다 보면 반드시 막히는 부분이 나옵니다.
"이게 왜 여기 있는 거지? 이 변수가 왜 필요하지?"하고 막히는 지점이 바로 내가 아직 이해하지 못한 부분입니다. 그 부분만큼은 AI에게 다시 질문하거나, 직접 문서를 찾아봐야 합니다.
 
이 습관을 들인 뒤로 저는 AI가 짜준 코드를 아무 생각 없이 넘기는 일이 줄어들었습니다. 설명할 수 없으면 이해한 것이 아닙니다. 이해하지 못한 코드는 결국 내 코드가 아닙니다.
 
### AI가 틀릴 수 있다는 전제로 리뷰한다
AI가 짜준 코드를 볼 때는 "맞겠지"라는 생각보다 "혹시 빠진 부분은 없을까?"라는 관점으로 살펴봅니다. 간단한 체크리스트를 만들어두면 도움이 됩니다. 예를 들면 이런 것들입니다.
 
* **보안에 취약한 부분은 없는지**
* **에러가 발생했을 때 제대로 처리되는지**
* **예외적인 상황이 충분히 고려됐는지**
* **우리 팀의 코드 스타일과 맞는지**

 
이 네 가지만 확인해도 AI가 자주 놓치는 부분을 대부분 잡아낼 수 있습니다.
 
이건 AI를 믿지 못하겠다는 태도가 아닙니다. 믿되, 확인한다는 태도입니다. 시니어 개발자도 자기 코드를 다시 보고, 팀원 코드도 꼼꼼히 검토합니다. AI가 짠 코드라고 다를 게 없습니다. 누가 작성했든, 실제 서비스에 올라가는 코드는 내 눈을 거친 코드여야 합니다.
 
한 가지 팁을 더 드리자면, AI에게 코드를 받은 뒤 이렇게 질문해보는 것도 좋습니다. 
"이 코드에서 놓칠 수 있는 예외 상황이나 보안 문제가 있어?"
AI에게 자신이 짠 코드를 스스로 점검하게 시키는 것입니다. 물론 완벽하진 않지만, 빠진 부분을 찾아내는 데 꽤 도움이 됩니다.
 
 
## 도구가 발전할수록 격차도 벌어진다
![스크린샷 2026-03-09 오전 11.34.11.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/0f897db3-4e0d-403b-8dee-4c5985e3ab90/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202026-03-09%20%E1%84%8B%E1%85%A9%E1%84%8C%E1%85%A5%E1%86%AB%2011.34.11.png)
(이미지 출처: 픽사베이)
 
AI 코딩 도구는 앞으로 더 좋아질 것입니다. 지금도 놀라울 정도인데, 1년 뒤, 3년 뒤에는 얼마나 발전해있을지 예측하기 어렵습니다. 그렇다면 이런 생각이 들 수도 있습니다. "어차피 AI가 다 짜주는 세상이 온다면, 코드를 이해하는 것이 정말 중요할까?"
 
저는 오히려 반대로 생각합니다. 도구가 강력해질수록 그것을 제대로 방향을 잡고 활용하는 사람의 가치는 더 높아집니다. 좋은 AI 코딩 도구를 가지고 있어도, 어떤 문제를 풀어야 하는지, 어떤 접근 방법이 맞는지, 결과물이 올바른지 판단하는 것은 여전히 사람의 몫입니다. 그런 판단력은 코드를 이해하고, 직접 씨름하고, 실패해본 경험에서 나옵니다.
 
AI가 짜준 코드를 이해하지 못하는 개발자는 AI가 틀렸을 때 그것을 알아차리지 못합니다. AI가 최선의 방법이 아닌 코드를 내놓을 때, 더 나은 방향을 제시하지 못합니다. AI를 쓸수록 더 성장하는 개발자와, AI를 쓸수록 AI 없이는 아무것도 못하게 되는 개발자. 지금 어느 방향으로 가고 있는지 스스로 점검해볼 필요가 있습니다.
 
### AI 사용 습관을 들여다 보기
AI 코딩 도구를 쓰고 있다면, 이 질문들에 한번 답해보세요.
 
* **AI가 생성한 코드를 한 줄씩 설명할 수 있나요?**
* **에러가 발생했을 때 먼저 직접 읽어보나요, 아니면 반사적으로 AI에게 던지고 있나요?**
* **처음부터 끝까지 혼자 짠 기능이 언제였나요?**

 
솔직히 대답하기 좀 찔리는 질문들입니다. 저도 그랬으니까요.
하지만 여기서 막힌다면, AI가 나를 돕고 있는 것이 아니라 나 대신 일을 하고 있는 것일지도 모릅니다. 편한 것은 맞지만, 그 편함에 익숙해질수록 내 근육은 점점 약해집니다.
 
결국 AI는 도구입니다. 내가 무엇을 만들고 있는지 알고 있는 사람이 사용하면 진짜 강력합니다. 근데 모르는 채로 쓰면, 그저 더 빠르게 헤매고 있을 뿐입니다. AI가 나 대신 일하게 둘 것인지, 아니면 AI를 활용해 내가 더 성장할 것인지, 그건 지금 선택할 수 있습니다.
 
 
### 📌 함께 읽으면 좋은 글
* [개발자의 커리어 연말정산: 내 성장을 측정하는 법](https://community.programmers.co.kr/post/13268?utm_source=&utm_medium=&utm_campaign=&utm_content=gocoder_13268)
* [개발자가 알아야 할 질문의 기술](https://community.programmers.co.kr/post/13102?utm_source=&utm_medium=&utm_campaign=&utm_content=gocoder_13102)
* [사이드 프로젝트, 시작은 했는데 끝이 안 나는 이유](https://community.programmers.co.kr/post/12938?utm_source=&utm_medium=&utm_campaign=&utm_content=gocoder_12938)
 
 

![고코더 작가님 프로필 카드.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/c227824e-8b30-4bd8-b5a3-233a53dc4546/%E1%84%80%E1%85%A9%E1%84%8F%E1%85%A9%E1%84%83%E1%85%A5%20%E1%84%8C%E1%85%A1%E1%86%A8%E1%84%80%E1%85%A1%E1%84%82%E1%85%B5%E1%86%B7%20%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%84%91%E1%85%B5%E1%86%AF%20%E1%84%8F%E1%85%A1%E1%84%83%E1%85%B3.png)

AI 시대, 신입 개발자가 실력을 키우는 법

웹 애플리케이션 개발 과정에서 프론트엔드와 백엔드, 데이터베이스 관리 등 다양한 기술을 아우르며 전체적인 시스템을 구축할 수 있는 개발자, 바로 풀스택 개발자인데요. 사용자와 직접 상호작용하는 인터페이스부터, 서버와 데이터베이스 관리, API 개발 및 배포까지 다방면의 역할을 소화할 수 있어, 특히 리소스가 한정된 스타트업 환경에서 그 중요성이 높아지고 있는 추세입니다. 풀스택 개발자의 역할과 필요 역량, 학습 로드맵에 대해 하나씩 알아보겠습니다.

 
# 풀스택 개발자란?
풀스택 개발자는 웹 애플리케이션 개발에서 프론트엔드와 백엔드 모두를 다룰 수 있는 개발자를 말합니다. 즉, **사용자 인터페이스(UI)부터 서버 및 데이터베이스와 같은 백엔드까지 하나의 웹 또는 앱을 개발할 수 있는 능력을 갖춘 개발자**이죠. 구글에서 Full stack developer을 검색해볼까요?

![스크린샷 2024-09-19 오전 11.20.02.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/34f6efc6-a2be-470f-8928-0d27f333d054/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202024-09-19%20%E1%84%8B%E1%85%A9%E1%84%8C%E1%85%A5%E1%86%AB%2011.20.02.png)

> 풀스택 개발자는 프론트엔드와 백엔드 언어 모두에 높은 숙련도를 가지고 있습니다. 이들은 HTML, CSS, JavaScript, NodeJS, ExpressJS, Django, 그리고 PHP에 능숙합니다. 또한, 풀스택 개발자는 MySQL, PostgreSQL, MongoDB와 같은 다양한 데이터베이스 관리 시스템(DBMS)을 이해하고 있습니다. (출처: Amazon Web Services)

이처럼 풀스택 개발자는 프론트엔드와 백엔드의 영역을 넘나들며 앱을 구성하는 다양한 기술 계층을 다루게 됩니다. 단순히 프론트엔드, 백엔드에 대한 이해 수준을 넘어 이러한 부분을 실제로 운용할 수 있는 능력을 갖춰야 합니다. 이 모든 스택들을 100% 마스터한 수준이 아니더라도, 앱의 구성 요소들을 편안하게 다루고 앱을 스스로 구축하는 것만으로도 풀스택 개발자의 가치는 올라가게 됩니다. 프론트엔드, 백엔드 양 분야를 다루기 위한 지식과 역량을 쌓는 것이 힘들기 때문에 실제로 업계에서도 풀스택 개발자를 유니콘이라 부르기도 합니다. 그만큼 풀스택 개발자의 수가 적다는 의미겠죠. 하지만 혼자서 모든 개발 과정을 처리할 수 있는 풀스택 개발자로 성장한다면 업계에서는 최고의 대우를 받을 수도 있다는 점! 그리고 이를 위해 상당히 많은 학습과 노력의 시간이 필요하다는 점! 을 강조할 수 있을 것 같아요 😉

 
| 프론트엔드 개발자|백엔드 개발자 |
| --- | --- |
|사용자에게 보여지는 앞 부분을 담당합니다. 화면 내의 카테고리, 레이아웃, 인터페이스, 폰트 등의 요소가 있습니다. 백엔드 API에서 가져온 데이터를 출력 및 입력하여, 사용자 인터페이스(UI)를 개발하는 역할을 담당합니다. 웹 퍼블리셔의 핵심 스킬인 HTML, CSS, JavaScript 등의 기술을 주로 사용하게 됩니다. |백엔드는 사용자에게 보여지지 않는 뒷단의 영역을 담당합니다. 웹 및 앱의 서버 시스템, 데이터베이스 등의 요소가 있습니다. 서버에 대한 개발을 진행하기 때문에 서버 운영체제에 대한 지식과 네트워크 통신에 대한 지식을 갖추어야 합니다. 주로 사용하는 언어로는 Java, Python, C++ 등이 있습니다. |

![FEvsBEvsFS.webp](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/9bf70287-bc3f-4b72-9c3c-32879db05c25/FEvsBEvsFS.webp)
[이미지 출처](https://medium.com/front-end-weekly/frontend-vs-backend-vs-full-stack-development-whos-the-winner-2968751b0565)

# 풀스택 개발자의 주요 업무
풀스택 개발자는 웹 애플리케이션의 전반적인 개발 과정을 책임지며, 주요 업무는 다음과 같습니다.
* **프론트엔드 개발**: HTML, CSS, JavaScript 등을 사용하여 웹사이트의 사용자 인터페이스(UI)를 설계하고 구현합니다. React, Angular, Vue.js와 같은 프레임워크를 사용할 수 있습니다.
* **백엔드 개발**: 서버, 데이터베이스, 애플리케이션 로직 등을 관리합니다. Python, Java 등의 언어와 Node.js, Django, Flask, Ruby on Rails, Spring 등의 프레임워크를 사용하여 서버 측 로직을 구현합니다.
* **데이터베이스 관리**: MySQL, PostgreSQL, MongoDB와 같은 데이터베이스를 설계하고 관리하며, 데이터의 저장, 검색, 수정 등의 기능을 구현합니다.
* **API 개발 및 관리**: RESTful API나 GraphQL API를 설계하고 구현하여 프론트엔드와 백엔드 간의 데이터 통신을 관리합니다.
* **DevOps 작업**: CI/CD(Continuous Integration/Continuous Deployment) 파이프라인 설정, 클라우드 인프라 관리(AWS, GCP, Azure) 등 운영 및 배포 관련 작업도 포함될 수 있습니다.


# 풀스택 개발자가 되고 싶어요! 어떤 역량이 필요한가요?
풀스택 개발자는 프론트엔드와 백엔드 영역 모두를 다루기 때문에 여러 분야를 아우르는 다양한 기술과 역량이 필요합니다.
* **프론트엔드 기술**: HTML, CSS, JavaScript, 프레임워크(React, Angular, Vue.js 등)에 대한 이해
* **백엔드 기술**: 서버 언어(Node.js, Python, Ruby, Java 등), 프레임워크(Django, Express.js, Spring 등), 데이터베이스 설계 및 관리(MySQL, PostgreSQL, MongoDB 등)
* **DevOps**: 클라우드 서비스(AWS, GCP 등), 도커(Docker) 및 컨테이너 관리, CI/CD 파이프라인 구축
* **문제 해결 능력**: 전반적인 시스템에서 발생하는 문제를 분석하고 해결할 수 있는 능력
* **협업 및 커뮤니케이션 능력**: 디자이너, 다른 개발자, 프로젝트 매니저와 원활하게 협업할 수 있는 소통 능력

![풀스택 개발자 필요 역량.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/40e92d01-be2b-4f75-8dc5-029a77360d22/%E1%84%91%E1%85%AE%E1%86%AF%E1%84%89%E1%85%B3%E1%84%90%E1%85%A2%E1%86%A8%20%E1%84%80%E1%85%A2%E1%84%87%E1%85%A1%E1%86%AF%E1%84%8C%E1%85%A1%20%E1%84%91%E1%85%B5%E1%86%AF%E1%84%8B%E1%85%AD%20%E1%84%8B%E1%85%A7%E1%86%A8%E1%84%85%E1%85%A3%E1%86%BC.png)

# 스타트업에서 찾는 풀스택 개발자
풀스택 개발자는 다양한 조직에서 활약할 수 있지만, 특히 스타트업에서 그 역량이 높게 평가됩니다. 제한된 리소스를 효율적으로 활용해야 하는 조직 특성상, 특정 분야에만 집중하는 스페셜리스트보다 다양한 역할을 소화할 수 있는 제너럴리스트를 선호하기 때문이죠. 특히 스타트업은 협업 경험이 상대적으로 부족한 경우가 많아, 여러 방면에 걸친 지식과 능력을 겸비한 풀스택 개발자가 필수적입니다.

풀스택 개발자는 다양한 부서와의 원활한 커뮤니케이션을 통해 여러 프로젝트를 긴밀하게 수행할 수 있는 강점을 가지고 있습니다. 또한 스타트업의 초기 아이디어를 빠르게 구현하고, 이를 통해 비즈니스 도메인에 대한 인사이트를 도출하는 능력 덕분에 스타트업에서 높은 수요를 보이고 있습니다.

이외에도 다양한 웹사이트와 모바일 앱을 개발하는 회사, 온라인 쇼핑몰이나 거래 플랫폼과 같은 이커머스(E-commerce) 분야에서 전체적인 시스템을 이해하고 개발할 수 있는 풀스택 개발자를 선호하는 경우가 많다고 해요. 📱

# 풀스택 개발자 학습 로드맵
풀스택 개발자가 되기 위해서는 많은 기술과 역량을 단계적으로 학습하는 것이 중요한데요. 이번 포스팅에서는 풀스택 개발자 커리어를 준비하는 분들을 위한 기본적인 학습 로드맵을 안내해 드릴게요.

![풀스택 학습 로드맵 (2).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/d93bcd52-62ec-457b-8a2f-85868b04ec7a/%E1%84%91%E1%85%AE%E1%86%AF%E1%84%89%E1%85%B3%E1%84%90%E1%85%A2%E1%86%A8%20%E1%84%92%E1%85%A1%E1%86%A8%E1%84%89%E1%85%B3%E1%86%B8%20%E1%84%85%E1%85%A9%E1%84%83%E1%85%B3%E1%84%86%E1%85%A2%E1%86%B8%20%282%29.png)

추가적으로 국내 기업의 풀스택 개발자 채용 공고를 보며 학습해야 하는 기술에 대해 다시 한 번 들여다 볼게요. 이번에 가지고 온 채용 공고는 ‘아기상어'로 유명한 유아 콘텐츠 기업 더핑크퐁컴퍼니의 풀스택 개발자 채용 공고입니다.

> **더핑크퐁컴퍼니 개발자 채용 공고**
웹 개발 기술에 대한 이해가 있는 분 (RDB, REST API, GraphQL)
팀 단위 협업과 다른 직군과의 원활한 커뮤니케이션이 가능한 분
TypeScript / Express / NextJS를 이용한 Node.js
TypeScript, Next.js를 이용한 프론트엔드 개발 경험이 있는 분
개인 서비스 제작 및 운영, 오픈소스 기여 경험이 있는 분

더핑크퐁컴퍼니 채용 공고를 보니 웹 개발 기술부터 프론트엔드 개발, 백엔드 개발, 협업 등 풀스택 개발자가 갖춰야 할 다양한 역량들을 요구하고 있네요. 풀스택 개발자의 경우 다양한 영역을 넘나들며 개발과 협업을 이끌어내는 직무이기 때문에 학습 로드맵을 따라 차근차근히 학습해나가며 이러한 역량을 쌓아가는 것이 중요합니다. 💪

 
![스크린샷 2024-09-19 오전 11.45.58.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/05beceb7-acee-43ec-81e5-8739c5c434f5/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202024-09-19%20%E1%84%8B%E1%85%A9%E1%84%8C%E1%85%A5%E1%86%AB%2011.45.58.png)


# 풀스택 학습, 프로그래머스에서 시작하세요
개발자 역량 평가 독보적 리더, 프로그래머스의 노하우를 담은 <타입스크립트로 함께하는 웹 풀사이클 개발(React, Node.js) 데브코스>는 12,000개 기업 채용 공고를 집중 분석하여 취업에 필요한 핵심 기술만 반영한 풀스택 과정입니다. 웹 개발의 A부터 Z까지 학습한 후 **소프트웨어 설계-개발-테스트-배포-운영-유지 관리까지 전체 프로세스를 이해하고 협업할 수 있는 육각형 개발자로 성장**해보시길 바랍니다.

> **프로그래머스 타입스크립트로 함께하는 웹 풀 사이클 개발(React, Node.js) 데브코스** 👩‍💻
> 12,000개 기업 채용 공고를 집중 분석하여 취업에 필요한 스킬만 엄선하고 반영한 웹 풀스택 과정. (전)카카오톡 창립 멤버이자 CTO 출신 이확영 강사로부터 직접 배우는 풀스택 과정으로, 카카오톡의 아키텍처를 설계한 노하우와 28년 개발 경력의 실무 경험을 바탕으로 소프트웨어 개발 프로세스의 핵심 요소를 배울 수 있습니다.

[![full-coding-test3(320x50).jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/e9d5f8e5-4483-4cd3-80e8-99bda2c81069/full-coding-test3%28320x50%29.jpg)](https://school.programmers.co.kr/learn/courses/24941?utm_source=prgmblog&utm_medium=social&utm_campaign=school_FS_blog&utm_content=FS_banner)

풀스택 개발자의 모든 것! 풀스택 개발자의 역할부터 필요 역량, 학습 로드맵 까지

AI의 승부는 더 이상 모델의 크기가 아니라, 그 모델을 어떻게 다루느냐에서 갈립니다. 데이터 사이언티스트 정경문 님은 이 변화의 중심에서 '소프트웨어 2.0' 시대의 핵심을 이야기합니다. 이제 중요한 것은 지능을 만드는 일이 아니라, 그 지능을 통제하고 연결해 실제 가치로 바꾸는 '시스템 설계 능력'입니다. 
 
정경문 님의 아티클을 통해 왜 지금 백엔드 엔지니어가 AI 시대의 주인공이 될 수 밖에 없는지, 그 결정적인 이유를 확인해보세요!
 
 
## 소프트웨어 2.0 시대, 시스템을 설계하는 개발자를 찾습니다
최근 AI 연구의 핵심은 '더 큰 모델'을 만드는 것에서 '**모델의 능력을 어떻게 100% 끌어낼 것인가**'로 옮겨가고 있습니다. 예를 들어, 과거에는 우리가 라면 끓이는 법을 가르칠 때 "물 550ml를 넣고 4분을 끓여라"라고 한 땀 한 땀 명령어를 적었습니다. 이것을 우리는 ‘**소프트웨어 1.0시대**’라고 부릅니다. 하지만 테슬라 AI의 수장이자 OpenAI의 창립 멤버인 안드레 파시(Andrej Karpathy)는 이제 시대가 변했다고 말합니다.
 
사람이 일일이 규칙을 짜는 대신, AI에게 수백만 장의 라면 사진과 평점을 던져주고 "최고의 맛을 내는 로직은 네가 알아서 찾아내!"라고 시키는 '**소프트웨어 2.0**'의 시대가 온 것이죠. 하지만 역설적으로 모델이 똑똑해질수록 그 모델을 안전하게 가두고, 올바른 길로 안내하며, 비즈니스 가치로 전환하는 '시스템 설계자'의 가치는 더욱 치솟고 있습니다. 오늘 저는 여러분께 왜 지금이 백엔드 엔지니어가 AI의 중심으로 도약할 수 있는 최고의 적기인지, 그리고 그 핵심 열쇠인 '하네스 엔지니어링'이 무엇인지 이야기해 보려 합니다.
 
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/1b03abb8-6347-4851-9ca6-8cff1747ac51/image.png)
소프트웨어 2.0 시스템 설계 개발자 (출처: 챗GPT 생성)
 
 
### 1. AI에게 별도의 지식이 필요한가?
우리가 AI 서비스를 설계할 때 가장 먼저 마주하는 것은 거창한 수식이 아니라 세 가지의 핵심적인 의사결정 나무(Decision Tree)입니다. 첫 번째 질문은 "**이 AI에게 별도의 지식이 필요한가?**"입니다. 모델이 학습하지 않은 우리 회사만의 데이터나 최신 정보가 필요하다면 우리는 **검색 증강 생성 RAG**(**Retrieval-Augmented Generation**)를 선택합니다. 
 

```python
# [Python Code] 답변에 필요한 자료를 찾고, 답변 생성

docs = vector_db.similarity_search(query)
response = llm.invoke(f"다음 문서를 참고해서 답변:\n{docs}")
```

 
위와 같은 간단한 로직으로 모델의 지능에 데이터라는 날개를 달아주는 것이죠. 2023년부터 활발히 연구된 RAG는 LLM의 환각증상을 어느정도 없애는데 기여했다고 봅니다.
 
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/af8aba73-b17e-47db-9335-223bb864c339/image.png)
AI 서비스 설계를 위한 3가지 질문 (출처: 챗GPT 생성)
 
 
### 2. 해결 과정이 단계적인가?
두 번째 질문은 "**해결 과정이 단계적인가?**"입니다. 복잡한 비즈니스 로직은 한꺼번에 모든 재료를 넣고 끓이는 라면처럼 한 번의 호출로 뚝딱 해결되지 않습니다. 아무리 좋은 재료라도 순서 없이 한 냄비에 넣고 끓이면 엉망이 되고 말죠. 마치 우리가 백엔드에서 결제 API를 만들 때 '재고 확인 → 결제 처리 → 배송 요청'이라는 순차적인 트랜잭션을 설계하듯, **AI에게도 재료를 손질하고(Node) 이를 적절한 다음 단계(Node)로 연결하는 과정(Edge)이 필요**합니다. 하나의 단계는 각 재료를 정교하게 준비하는 단일 노드(Node)의 구성입니다. 
 

```python
#[Python Code] 개별 재료를 손질하는 '노드'를 정의. LangChain

chain = prompt | retriever | model
result = chain.invoke({"question": query})
```

 
위 코드는 사용자의 질문을 이해하고, 필요한 데이터를 가져와, 결론을 내는 하나의 완성된 '재료 손질' 과정입니다. 하지만 진짜 요리는 이 손질된 재료들을 어떤 타이밍에 넣느냐에서 결정됩니다. 여기서 **백엔드 엔지니어의 주무기인 워크플로우 설계(Workflow Design) 역량이 등장**합니다.
 

```python
# [Python Code] 손질된 재료들을 순서에 맞게 연결하는 '흐름(Edge)' 제어. StateGraph

graph = StateGraph(AgentState)
graph.add_node("planner", planning_agent) # 재료 선별 단계 (Node)
graph.add_node("executor", tools_executor) # 불 조절 및 조리 단계 (Node)
graph.add_edge("planner", "executor") # 재료 선별과 조리를 이어주는 흐름 (Edge)
```

 
백엔드 개발자가 복잡한 워크플로우를 최적화하고 각 단계의 입출력을 정교하게 맞추던 '프로세스 엔지니어링' 능력. 이 능력이 AI라는 도구를 가지고 최고의 요리를 만들어내는 결정적인 차이를 만듭니다.
 
 
### 3. 역할을 나누어야 하는가?
세 번째 질문은 "역할을 나누어야 하는가?"입니다. 과거의 시스템이 모든 재료가 섞여 있어 하나만 상해도 전체를 버려야 하는 비빔밥이었다면, 현대적인 마이크로서비스 아키텍처(MSA)는 밥, 나물, 육회가 각각 독립된 접시에 담긴 '뷔페'와 같습니다. 특정 재료에 문제가 생겨도 그 접시만 교체하면 서비스 전체는 끄떡없죠.
 
이처럼 기획자 에이전트, 개발자 에이전트, 검수자 에이전트로 역할을 명확히 분리하는 **Multi-Agent 구조**는 바로 이 MSA의 철학과 완벽히 맞닿아 있습니다. 각 에이전트라는 독립된 '접시'들이 각자의 책임을 다하며 API라는 통로로 소통하게 만드는 것, 이 세 가지 질문에 답을 내리는 과정 자체가 이미 백엔드 엔지니어가 수년간 훈련해온 '시스템 구조 설계' 그 자체입니다.
 

```python
[Python Code] 멀티에이전트 + 오케스트레이션 코드 흐름. Orchestration.

plan = planner_agent.invoke(query) # 무엇을 할지 나눈다
results = executor_agent.batch(plan.tasks) # 각 작업을 실행한다
review = reviewer_agent.invoke(results) # 결과를 검토한다
answer = synthesizer_agent.invoke(review) # 하나의 답으로 종합한다 
```

 
 
불과 몇 년 전까지 AI 개발은 모델 중심이었습니다. 데이터를 모으고, 직접 모델을 학습시키고, 가중치를 튜닝하며 소수점 단위의 정확도를 높이는 것이 핵심이었습니다. 하지만 지금은 상황이 완전히 달라졌습니다. 
 
사티아 나델라(Satya Nadella) 마이크로소프트 CEO는 “모든 회사는 AI 회사가 될 것이다”라고 단언했습니다. 이 말의 진짜 의미는 모든 회사가 자신만의 모델을 밑바닥부터 만든다는 뜻이 아닙니다. 이미 세상에는 오픈AI, 앤트로픽, 구글 같은 빅테크가 만든 초거대 모델들이 API 형태로 널려 있습니다. 이제 성능 차이는 점점 줄어들고 누구나 최고의 지능을 빌려 쓸 수 있는 시대가 되었습니다. 
 
 
## 결국 차별점은 그 지능을 어떻게 서비스로 설계하느냐에서 갈립니다
**어떤 데이터를 넣고(Input Control), 어떤 흐름으로 처리하며(Process Flow), 어떤 역할로 나누어 효율을 극대화할 것인가(Resource Allocation)**. 이 모든 질문은 사실 백엔드 개발자들이 API 서버를 구축하고, DB 스키마를 짜고, 트래픽을 분산할 때 하던 고민과 완벽하게 일치합니다. 그래서 지금 AI의 중심은 모델 제작자에서 시스템 설계자로 이동하고 있습니다.
 
여기서 우리는 한 단계 더 나아가야 합니다. 프롬프트 엔지니어링이 단순히 '말을 잘 거는 기술'이라면, 그 위에는 AI를 강력하게 통제하고 최적화하는 **하네스 엔지니어링**(**Harness Engineering**)이라는 레이어가 존재합니다. 
 
하네스라는 단어를 들으면 무엇이 떠오르시나요? 강아지와 산책할 때 채우는 가슴줄이나 말의 힘을 제어하기 위해 씌우는 마구를 떠올리시면 정확합니다. 강아지의 목을 조르지 않으면서도 안전하게 방향을 지시하듯, **하네스 엔지니어링은 AI 에이전트가 업무를 수행할 때 엇나가지 않도록 외부 실행 환경, 규칙, 제약 조건, 피드백 시스템을 설계하는 기술**입니다. 아무리 힘이 센 말(강력한 LLM)이라도 고삐와 안장(하네스)이 없다면 제 멋대로 뛰어다니는 말 때문에 기수도 위험하겠죠? 
 
특히 최신 논문인 [Meta-Harness: End-to-End Optimization of Model Harnesses](https://arxiv.org/abs/2603.28052)는 이 개념을 완성시킵니다. 이 논문은 "모델을 바꾸려 하지 말고, 모델이 일하는 방식인 '하네스' 자체를 AI가 스스로 최적화하게 만들자"고 제안합니다.
 
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/3824d5be-4386-40e3-9f08-4e092da81561/image.png)
메타 하네스의 압도적 성능 그래프
(출처: Meta-Harness: End-to-End Optimization of Model Harnesses)
 
 
다음 그래프를 보시면 Meta-Harness(빨간선)가 기존의 최적화 도구들(ACE, TTT-Discover 등)을 단 몇 번의 시도만으로 가볍게 추월하는 것을 볼 수 있습니다. 오른쪽 바 차트에서는 사람이 직접 짠 코드보다 Meta-Harness가 생성한 로직이 실제 문제 해결 성능(Pass Rate)에서 훨씬 우위에 있음을 입증합니다. **모델이 똑같아도 '어떻게 시키느냐(Harness)'에 따라 결과가 이렇게 달라집니다**. 
 
이 어려운 개념을 우리에게 친숙한 '최고의 라면 레시피를 찾는 AI 요리사' 비유로 풀어보겠습니다. 핵심 알고리즘 을 보면 네 가지 준비물이 등장합니다.
 
1. **과제(X)**: 손님들이 주문한 다양한 메뉴 (**해결해야 할 문제들**)
2. **요리사(M)**: 실제로 불 앞에서 요리할 숙련된 요리사 (**LLM 모델**)
3. **제안자(P)**: 새로운 레시피를 머릿속으로 구상하는 연구원 (**레시피 생성 에이전트**)
4. **비법 노트(D)**: 지금까지 써본 모든 레시피와 평점을 기록한 저장소 (**Filesystem**)

 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/48b4e86b-5c83-4201-81de-710cd12a4c76/image.png)
하네스 엔지니어링을 라면 요리에 비유 (출처: 챗GPT 생성)
 
 
과정은 이렇습니다. **Step 1**에서는 일단 세상에 알려진 기본 레시피(H)들로 요리를 시작합니다. 요리사(M)에게 이 레시피대로 만들어보라고 시킨 뒤 손님의 평점을 매기고, 그 결과와 과정을 비법 노트(D)에 꼼꼼히 적습니다.
 
**Step 2**가 가장 흥미로운 지점입니다. 연구원(P)은 비법 노트(D)를 처음부터 끝까지 정독합니다. "어? 3번 레시피는 설탕을 넣었더니 점수가 낮았는데, 5번은 마늘을 넣으니 점수가 확 올랐네? 그럼 이번엔 마늘을 더 넣고 고추가루을 섞은 새로운 레시피를 만들어볼까?"라며 이전의 성공과 실패를 분석해 다음 안을 제안합니다.
 
마지막 **Step 3**에서는 이 새로운 레시피가 실제 조리가 가능한지 검증하고 다시 요리사에게 시킵니다. **이 과정을 N번 반복**하면 결국 비법 노트에는 그 어떤 인간 요리사도 생각지 못한 최상의 레시피들, 즉 파레토 프론티어(Pareto frontier)라 불리는 '인생 레시피 모음집'이 남게 됩니다.
 
 
이 알고리즘의 진정한 힘은 '기록의 힘'에서 나옵니다. 기존의 방식들은 방금 한 요리의 맛만 기억했다면, **Meta-Harness는 과거에 했던 모든 실패와 성공의 기록(D)을 매 순간 전부 다 읽어보고 다음 수(Next step)를 결정**합니다. 이것이 바로 백엔드 엔지니어가 잘하는 '로그 분석'과 '시스템 최적화'의 정점입니다. 여러분이 평소에 에러 로그를 분석해 시스템의 병목을 찾아내고 인프라 구조를 개선하듯, 이제는 AI 에이전트의 실행 로그를 분석해 그들이 일하는 환경(하네스)을 개선해야 합니다.
 
하네스 엔지니어링은 단순히 코드를 짜는 것을 넘어 AI 시대의 새로운 '규약'과 '기준'을 설정하는 일입니다. **에이전트들이 서로 어떻게 대화해야 효율적인지, 어떤 제약 사항을 주어야 안전한지 정의하는 아키텍트**가 되는 것입니다.
 
 
## AI의 엔진은 같아도, 하네스를 설계하는 당신이 미래를 지휘합니다
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/0814d759-86a1-4dcd-b43e-f3bf9c699ce3/image.png)
백엔드 엔지니어의 여정 (출처: 챗GPT 생성)
 
 
AI 개발이라는 여정에서 백엔드 엔지니어는 가장 강력한 무기를 쥐고 있습니다. 모델이라는 엔진은 API로 평등해졌고, 이제 차이를 만드는 것은 그 엔진을 감싸는 정교한 하네스 엔지니어링입니다. 데이터를 RAG으로 연결하고, 프로세스를 Chain으로 엮으며, 역할을 Multi-Agent로 나누고, 이 모든 것을 하네스로 통제하는 설계의 미학. 이것이야말로 백엔드 개발자가 AI 엔지니어링의 주인공이 될 수 밖에 없는 이유입니다.
 
여러분이 지금까지 쌓아온 구조 설계 능력과 시스템 통제력은 결코 사라지지 않습니다. 오히려 AI라는 파도를 타고 더 넓은 바다로 나아갈 수 있는 가장 튼튼한 배가 되어줄 것입니다. 지금 바로 하네스의 고삐를 쥐고, 여러분만의 AI 아키텍처를 설계해 보시길 바랍니다. 그 길의 끝에는 단순히 모델을 쓰는 사용자가 아닌, AI를 지휘하는 진정한 마스터로서의 여러분이 서 있을 것입니다.
 
 
### 📌 함께 읽으면 좋은 글
* [AI 기술을 가진 개발자, 실제 채용에서 유리할까?](https://community.programmers.co.kr/post/13433?utm_source=&utm_medium=&utm_campaign=&utm_content=data_13433)
* [AI 개발자의 역량: 위대한 개인의 탄생](https://community.programmers.co.kr/post/13369?utm_source=&utm_medium=&utm_campaign=&utm_content=data_13369)
* [프로그래머의 성장관점에서 바라본 CES 2026](https://community.programmers.co.kr/post/13168?utm_source=&utm_medium=&utm_campaign=&utm_content=data_13168)


 
 

![정경문 작가님 프로필 카드.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/5e64c3af-26b1-4b64-9a3f-b5ec14236695/%E1%84%8C%E1%85%A5%E1%86%BC%E1%84%80%E1%85%A7%E1%86%BC%E1%84%86%E1%85%AE%E1%86%AB%20%E1%84%8C%E1%85%A1%E1%86%A8%E1%84%80%E1%85%A1%E1%84%82%E1%85%B5%E1%86%B7%20%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%84%91%E1%85%B5%E1%86%AF%20%E1%84%8F%E1%85%A1%E1%84%83%E1%85%B3.png)

LLM 성능의 '천장'을 깨는 시대: 백엔드 엔지니어를 찾아라

[취업 인터뷰] 데브코스로 백엔드 전문성을 키우고, CJ 올리브영에 합격했어요 - 백엔드 5기 수료생 이은주 님

프로그래머스 시니어 개발자분들과 나눈 인터뷰 내용을 바탕으로, 각 분야 전문가들이 말하는 '프론트엔드 개발자에게 가장 중요한 역량'에 대해 정리해 보았습니다. 개발자의 성장을 위한 팁과 실제 면접에서 사용되는 질문들도 준비했으니, 궁금하신 분들은 인터뷰 내용을 끝까지 살펴보세요!
 
# 프론트엔드 개발자에게 필요한 핵심 역량은?
### 💬 이ㅇㅇ님 (풀스택 개발자)
프론트엔드나 백엔드를 떠나서, 개발자라면 꼭 가져야 한다고 생각하는 역량은 두 가지입니다. '**논리의 흐름을 파악하는 것**'과 '**추상화 정도를 어떻게 그룹핑할 수 있는가**'인데요. 개발자적 사고라고 할 수 있겠네요. 이 두 가지를 가지고 있으면 좋은 개발자라고 생각합니다.
 
> **Q. 컴퓨팅 사고력과 비슷한 개념인가요?**
> A. 그렇게 볼 수도 있지만, 컴퓨터를 떠나서 개발자들은 설계를 하거나 논리의 흐름을 그려요. 그런데 이 논리에도 단계가 있어서 논리의 흐름을 크게 살펴보기도 하고, 세세하게 보기도 해야합니다. 또 문제를 해결하기 위한 여러 방법 중 최적의 방법이 무엇인지 파악하는 능력이 중요하다고 생각합니다.
> 
> 프론트엔드라고 하면 리액트나 뷰를 이용해서 컴포넌트를 만들어 내는데요. 컴포넌트를 어느 정도의 크기로 만들 것인가, 그 크기로 만드는 이유는 무엇이고, 이렇게 만들었을 때 어떤 논리의 흐름으로 로직이 작성되어야 하는가에 대한 것들을 위의 두 가지 능력을 갖춘 사람은 빠르게 결정할 수 있습니다.
> 
 
### 💬 송ㅇㅇ님 (프론트엔드 개발자)
프론트엔드든 백엔드든, 함께 일하는 동료들을 떠올려 보면 어떤 뚜렷한 능력이 반드시 필요하다고 말하긴 어렵습니다. 하지만 꼭 하나의 역량을 꼽자면 '**문제를 바라보고, 가설을 세우며, 그 과정을 즐기고 잘 해내는 능력**'이라고 생각합니다.
 
예전에 유튜브에서 맨손으로 숲 속에 진흙집을 짓는 영상을 본 적이 있어요. 이걸 보면서 느낀 건, 도구에 익숙해지는 건 그다음 문제라는 겁니다. 더 중요한 건 '문제를 해결하겠다는 의지'와 그 과정을 즐길 수 있는 태도죠. 결국 핵심은 **문제 해결 능력**입니다. 도구를 얼마나 잘 다루는지는 다음 단계인 것 같아요.
 
# 개발자의 성장 단계에 따라선 어떤 역량이 필요할까요?
### 💬 김ㅇㅇ님 (프론트엔드 개발자)
주니어 개발자라면, 우선 요구사항에 맞게 화면을 구현할 수 있는 능력이 중요합니다. 하지만 경력이 쌓이고 더 높은 레벨로 나아가려면, 다른 개발자의 성장을 도울 수 있는 사람이 되어야 합니다. 단순히 주어진 업무를 수행하는 것을 넘어서, 직접 업무를 제안하고 최적화나 설계 방식에 대해 의견을 낼 수 있는 역량이 필요하죠.
 
팀 리더나 시니어 개발자가 되면 역할은 더 확장됩니다. 팀 내 업무를 분배하고 환경을 조성하는 것은 물론, 회사에 주어진 일이 없더라도 새로운 가능성을 제시할 수 있는 사람이어야 하죠.
 
한편, 기술 리더는 일반적인 '매니저'와는 다르다는 점입니다. 매니저가 감독이나 코치 같은 역할이라면, 기술 리더는 말 그대로 팀의 '주장' 역할을 하는 사람이에요. 기술적으로 팀을 이끌고, 다른 개발자의 잠재력을 이끌어내는 책임이 바로 시니어 개발자에게 있다는 점을 강조하고 싶어요.
 
# 개발자의 역량을 효과적으로 평가하는 방법은 무엇일까요?
### 💬 박ㅇㅇ님 (프론트엔드 개발자)
실리콘밸리에서는 사전 인터뷰를 0~3번 정도 봅니다. 경력이 좋으면 어느 정도 통과해서 온사이트 인터뷰로 바로 갈 수도 있고, 아무 백그라운드가 없으면 3번도 볼 수 있습니다. 온사이트 인터뷰는 5~7개의 테스트를 보는데요. 코딩을 보는 테스트가 1~2개, 그 외에는 회사 컬쳐와의 핏, 아키텍처, 도메인 지식 등을 봅니다. 코딩 질문 등은 이미 노출되었다고 보고, 최소 요건으로만 봅니다.
 
> Q. 면접에서 사용하는 질문 등이 있다면?
> A. **시스템 아키텍처나 자신의 프로젝트에 대한 설명을 중점적으로 보고 있습니다**. 예를 들어, "아마존 사이트를 만든다면, 어떻게 만들건가요?", "최대 스케일업이 될 때 어떻게 하실건가요?" 이런 식으로 분산처리, 데이터 구조 등에 대한 백그라운드 스킬을 알아보는 거죠.
> 
> 프로젝트의 경우, 가장 인상 깊었던 것이나 공유하고 싶은 프로젝트에 대해 알려달라고 요청합니다. **규모가 큰 프로젝트나 기술적인 챌린지가 있었던 프로젝트, 또는 신기술을 활용했던 프로젝트** 등을 언급하면 됩니다. 면접관들은 기술에 대해서도 묻고, 기존 아키텍처랑 무엇이 다른지에 대해 물어봅니다. 질문의 핵심은 지원자가 경험했던 것을 바탕으로 신규 프로젝트를 진행할 때, 어떤 기술 스택을 활용할 수 있을지를 알아보기 위한 것이죠. 회사에 따라 과제를 통해 실력을 확인하기도 합니다.

 
역량이 뛰어난 프론트엔드 개발자가 되기 위해서는 문제를 바라보고, 가설을 세운 후 해결해 나가는 과정이 무엇보다 중요합니다. 문제 해결력을 가진 프론트엔드로 성장하고 싶으시다면, 프로그래머스 프론트엔드 데브코스에 참여해보세요!
 
 
[![coding_test-2.jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/3e63876b-7244-4281-b373-35f60ae77e3d/coding_test-2.jpg)](https://school.programmers.co.kr/learn/courses/25072?utm_source=mailchimp&utm_medium=DM&utm_campaign=school_25072_sales&utm_content=25072_cstg_d7)

시니어 개발자들이 말하는 프론트엔드 개발자 필수 역량

웹이나 앱을 이용하는 유저와 가장 먼저 상호작용하며, 서비스 경쟁력에 큰 영향을 미치는 프론트엔드! 시각적인 결과물이나 경험 최적화에 즐거움을 느껴 프론트엔드를 선택하는 분들도 많을 텐데요.
 
**프론트엔드 데브코스 1기 수료 후 삼성 SDS에 합격한 김찬민 님의 인터뷰**를 가지고 왔습니다. 찬민 님이 데브코스를 선택한 이유와 수료까지의 여정이 궁금하시다면, 지금 바로 인터뷰를 읽어보세요!
 
 
# 안녕하세요 찬민님. 프론트엔드 분야에 관심을 가지게 된 계기가 궁금합니다.
사용자가 서비스를 이용할 때 가장 먼저 마주하게 되는 부분이 프론트엔드이고, **사용자가 해당 서비스를 이용할지를 결정하는데 큰 영향을 주는 중요한 영역이라고 생각**해요. 어떻게 UI, UX를 설계하냐에 따라 서비스의 만족도가 달라지는데, 그 영역을 직접 설계하고 구현해나가는 과정이 재밌더라고요!
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/cba59fd4-e6c2-47e6-bc4c-68a9b87f6c0f/image.png)
# 프로그래머스 데브코스는 어떻게 알게 되셨나요?
많은 기업들이 프로그래머스를 통해 코딩 테스트를 진행하기 때문에, 최대한 익숙한 환경에서 연습을 하자는 차원에서 평소 프로그래머스 사이트를 자주 방문했어요. 그러다가 프로그래머스에서 프론트엔드 데브코스를 모집한다는 공고를 보고 지원하게 되었습니다.
 
# 다양한 부트캠프 중 프로그래머스 데브코스를 선택한 이유는 무엇인가요?
평소 부트캠프 과정을 통해 프론트엔드 분야를 전문적으로 배워보고 싶다는 생각을 하고 있었기에 여러 부트캠프를 살펴보았어요. 그중 저는 **데브코스에서 '자생력을 갖춘 개발자'를 양성한다는 말이 가장 끌렸어요**. 개발자는 평생 공부해야 하는 직업이라고 하잖아요. 그렇기 때문에 스스로 학습하고, 성장하는 역량을 갖추는 것이 가장 중요하다고 생각했어요.
 
**멘토링 시스템** 또한 마음에 들었어요. 속도를 내는 것도 중요하지만 방향을 제대로 잡고 가는 것도 중요하다고 생각해요. 제가 열심히 하는 것도 중요하지만 **올바른 방향으로 가고 있는지를 살펴봐주는 사람이 있다면 더욱 빠르게 성장할 수 있다 생각**했고, 그래서 프로그래머스가 더 끌렸던 것 같아요.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/e37fd9bb-b2ff-41ae-a88f-f5ebd364eace/image.png)
 
# 프로그래머스 데브코스를 통해 이루고자 했던 목표가 있었나요?
프로그래머스 데브코스를 통해 이루고 싶었던 목표가 3개 정도 있었는데요.
* **함께 성장하는 즐거움 경험하기**
* **함께 일하고 싶은 개발자 되기**
* **자생력을 갖춘 개발자 되기**
 

지금까지 1, 2번째 목표는 작게나마 달성했다고 생각해요. 데브코스를 진행하는 동안 팀 프로젝트는 2번 있었는데요. **두 번의 프로젝트 기간 동안 협력하는 역량, 소통하는 역량, 개발하는 역량이 향상**되었어요. 해당 역량들은 팀원 모두가 더 나은 방향으로 나아가려고 고민하고 부딪혀 나가면서 함께 만들어간 결과물이라고 할 수 있죠. 또 팀원 모두 프로젝트가 힘들지만 즐거웠고, 다음에 다시 프로젝트를 하면 이 팀 그대로 다시 하고 싶다는 말을 자주 하거든요. 그러한 측면에서 2번째 목표도 조금은 달성했다고 생각해요.
 
3번째 목표는 꾸준한 노력이 필요하다고 생각해요. 하고 싶거나 필요한 공부가 있으면 찾아서 하고 있지만, 아직은 공식 문서보다는 유튜브, 책에 좀 더 의존하거든요. 다양한 영역에 도전하려면 영상보다는 공식 문서가 더 익숙해야 하는 만큼 앞으로는 문서를 보면서 학습하는 연습을 해보려고 합니다.
 
# 데브코스 과정 중 기억에 남는 활동이 있다면 무엇인가요?
가장 기억에 남는 건 당연히 팀 프로젝트예요. 그 기간 동안 정말 **원 없이 밤새우고, 토론하고, 고민**했던 것 같아요. 고통의 시간처럼 들릴 수 있지만, 저는 사실 재밌었어요. 😄 
공통의 문제를 같이 고민하다가 해결하면 그만큼 짜릿한 순간이 또 없거든요! 온라인상으로만 대화를 나누고 프로젝트를 진행하는 것이 가능할까 싶었는데, 막상 해보니 그게 되더라고요. 그래서 더욱 인상 깊었던 것 같아요.
 
<div style="position: relative; max-width: 100%; padding-bottom: 56.25%; height: 0;"><iframe width="560" height="315" src="https://www.youtube.com/embed/J1S71PjxSXg?si=PR7GXIAzEgt_DbSD" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen="" style="position: absolute; position: absolute; top: 0; left: 0; width: 100%; height: 100%;"></iframe></div>
 

# 어떤 개발자로 성장하고 싶으신가요?
**함께 일하고 싶은 개발자**가 되고 싶어요. 개발은 혼자 하는 게 아니잖아요. 각자 자신이 잘하는 분야를 맡아 결과물을 만들어내는 작업인 만큼 협업하는 능력이 가장 중요하다고 생각해요. 제가 생각하는 이성적인 함께 하고 싶은 개발자는 **소통 역량, 개발 역량, 다양한 개발 지식** 등을 겸비한 개발자입니다. 이 3가지 역량을 모두 갖추는 게 쉽지는 않겠지만, 데브코스에서 얻게 된 역량을 바탕으로 꾸준히 노력하면 언젠가 함께 일하고 싶은 개발자가 되어 있지 않을까 생각합니다.
 
# 데브코스가 취업에 도움이 되었나요?
당연하죠! 현업에서 개발자로 활동 중이신 강사님들의 강의, 멘토링을 바탕으로 개인 프로젝트, 팀 프로젝트를 수행하면서 **이론과 실무 간의 간극을 해결하는 데 많은 도움**이 되었습니다.
 
혼자서 학습을 하다 보면 실무에서 활용하는 도구, 개발 방식 등을 프로젝트에 적용해 볼 기회가 거의 없기 때문에 취업 공고에서 요구하는 스킬들을 왜 필요한 건지도 모르고 학습하는 경우가 많은데요. **데브코스를 통해 도구의 필요성과 활용법들을 익혀 나갔고, 이를 바탕으로 개발에 필요한 도구를 스스로 선택하고 활용하는 역량을 향상** 시킬 수 있었습니다.
 
또한 다양한 팀원들과 개발 관련 이야기를 나눌 기회가 많다 보니 소통하는 방법에 대해서도 요령이 생겼고, 면접관 분들께도 평소 팀원들과 대화를 나누듯이 저의 경험과 생각을 자연스럽게 전달할 수 있었기에 취업에 성공할 수 있었다고 생각해요.
 
# 데브코스 후배 수강생을 위해 응원의 한마디 부탁드려요.
5개월 동안 오로지 개발에만 집중하고 몰입하는 것이 결코 쉬운 일은 아니에요. 다시 고3으로 돌아간 듯한 느낌이 들기도 했어요. 그런데 지금 돌이켜 생각해 보면 그 시간이 있었기에 지금의 제가 있다고 확신해요. **조금 더 몰입하는 시간, 나의 성장과 발전에 투자하는 시간**이라고 생각하면 좋을 것 같아요.
 
저는 데브코스 덕분에 학습을 꾸준히 이어갈 수 있었던 것 같아요. '온라인으로만 소통하는데 과연 가능할까?'라고 생각하는 분들도 많을 거예요. 저도 처음엔 그렇게 생각했거든요. 근데 막상 참여해 보니 전혀 그렇지 않더라고요.
 
여러 이유로 데브코스 지원을 고민하는 분들도 계실 거예요. 하지만 **막상 참여하고 나면 '여기 들어오길 정말 잘했구나'라는 생각이 들 거라고 확신**합니다. 데브코스에 참여하는 모든 분들이 이 과정을 통해 원하는 바를 꼭 이루시길 응원합니다!
 
 
*※본 글은 2022년 2월에 최초 작성된 콘텐츠입니다.*
 
 
[![FE_배너.jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/ea53c666-87f7-4b6f-a5a7-935644b5436e/FE_%E1%84%87%E1%85%A2%E1%84%82%E1%85%A5.jpg)](https://school.programmers.co.kr/learn/courses/25243?utm_source=prgmblog&utm_medium=social&utm_campaign=school_25243_blog&utm_content=25243_banner)

[데브코스 후기] 개발에 몰입한 5개월, 데브코스 덕분에 해낼 수 있었어요 - 프론트엔드 1기 수료생 김찬민 님

개발자의 커리어 연말정산: 내 성장을 측정하는 법

전 세계 개발자들이 매년 주목하는 보고서가 있습니다. 바로 Stack Overflow 개발자 서베이인데요. 2025년에도 약 49,000명의 개발자가 참여해 AI 도구 사용, 인기 기술 스택, 커뮤니티 사용 등 다양한 주제를 다뤘습니다. 특히 올해는 AI에 대한 기대와 동시에 경계심이 교차하는 흐름이 뚜렷하게 나타났습니다.
 
오늘 포스팅에서는 2025 Stack Overflow 개발자 서베이 주요 결과를 살펴보고, 개발 현장의 변화와 앞으로의 인사이트를 함께 나눠보겠습니다.
 
 
## 1. AI 도구, 사용은 늘었지만 신뢰도는 하락
올해 설문에 따르면 **개발자들의 AI 도구 사용률이 약 80%로 나타났습니다**. 하지만 오히려 **AI 도구에 대한 신뢰도는 29%로 하락**하였으며, 이는 작년 대비 11%가 감소한 수치입니다.
 
* AI 결과 신뢰도 급락: 작년 40% → 올해 29%로 하락
* 가장 큰 이유: 응답자의 45%가 "거의 맞긴 한데, 완전히 맞지 않음"을 AI 솔루션의 가장 큰 불만으로 응답
* 그 결과, **66%의 개발자가 AI가 작성한 코드를 수정하는 데 더 많은 시간을 쓰고 있다고 응답**

 
AI 결과가 만족스럽지 않을 때 개발자들이 선택하는 방법은 '사람에게 물어보는 것'인데요. 약 75%의 개발자들이 복잡한 코드를 작성하거나 중요한 상황에서 AI 결과를 신뢰할 수 없을 때 다른 사람에게 물어본다고 합니다.
 
이는 결국 **AI가 빠르게 발전하더라도, 사람 중심의 검증과 협업이 여전히 필수적**임을 보여줍니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/c00d96c2-8c5c-4d3a-8868-8f80b1f06165/image.png)
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/bfdac048-ebbb-4b30-ac63-fe97385a57e4/image.png)
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/d279203e-8695-4cbb-87fa-1ba7168ae4db/image.png)
 
 
## 2. 대규모 언어 모델
### ✅ GPT 모델의 압도적 사용률
* **OpenAI GPT 모델은 응답자의 82%가 지난 1년간 개발 작업에 사용했다고 응답**하면서, 가장 많이 사용되는 대규모 언어 모델(LLM) 1위로 나타났습니다.
* 이는 GPT가 여전히 개발자 생태계에서 표준 도구로 자리 잡고 있으며, 다른 모델 대비 **접근성과 활용성이 높다**는 것을 보여줍니다.

 
### ✅ Claude Sonnet 모델의 차별적 위치
* Claude Sonnet 모델은 학습자(코딩 배우는 사람)보다 **현업 개발자에게 더 많이 사용**되고 있습니다. (학습자 30% vs 전문 개발자 45%)
👉 즉, 입문보다는 실무 중심 활용에서 강점을 보이고 있다는 의미입니다.
* 또 하나 주목할 점은, **Claude가 올해 가장 '감탄받는(Admired)' LLM으로 응답**되었다는 것입니다.
* 가장 사용해보고 싶은 모델(Desired) 항목에서는 33%로 2위에 올랐습니다.

 
즉, GPT는 대중성과 범용성에서 독보적이며, 개발자들이 가장 먼저 접하는 LLM입니다. Claude는 전문 개발자들이 선호하는 모델, 품질/경험 측면에서 높은 평가를 받는 모델이라는 점에서 주목할 만합니다.

 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/616d2904-24c6-4aff-9933-16833f0015ee/image.png)
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/3ab94016-0f91-4375-80c0-e410d079df94/image.png)
 
 
## 3. 인기 기술 스택의 변화: Python, Rust, Go의 약진
프로그래밍 언어 사용 트렌드에서도 눈에 띄는 변화가 있었습니다. **Python와 SQL의 사용이 증가했고, Rust, Go 등의 시스템 언어가 성장**했습니다. 반면 Java와 Kotlin은 하락세를 보였습니다.
 
* Python: 전년 대비 7% 상승
* SQL: 전년 대비 7.5% 상승
* Rust와 Go: 각각 2% 증가, 특히 AI 인프라 및 고성능 서비스 개발에서 채택률 상승
* Rust 빌드 도구 Cargo는 올해 가장 "감탄받는" 개발 툴 1위

 
전반적으로 AI와 데이터 중심의 개발 환경이 확대되면서, **안정성과 성능을 중시하는 언어들이 함께 성장**하고 있음을 보여주는 응답 결과였습니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/9c72626c-967f-429f-ac55-f90cfd7d211b/image.png)
 
 
## 4. 여전히 강력한 커뮤니티의 힘
AI의 영향력이 점점 커지고 있지만, 개발자들은 여전히 커뮤니티를 통해 핵심 정보를 얻고 있습니다. 개발자들이 주로 활용하는 플랫폼과 사용률은 다음과 같습니다.
* Stack Overflow: 84%
* GitHub: 67%
* YouTube: 61%

 
특히, **35%의 개발자가 AI 관련 문제 해결을 위해 Stack Overflow를 방문**한다고 응답했습니다. 이는 Stack Overflow가 단순한 커뮤니티 공간을 넘어, AI가 생성한 코드를 검증하는 신뢰할 만한 소스로 자리잡고 있다는 것을 보여줍니다.
 
또한, Stack Overflow 방문 시 **댓글 읽기**가 최상위 활동으로 나타났는데요. 이는 많은 개발자들이 단순히 '정답'을 찾기보다는 댓글과 토론을 보며 맥락을 이해하려고 한다는 것을 나타냅니다. 결국 **AI가 제공하는 단편적 답변이 채울 수 없는 부분을 커뮤니티가 보완**하고 있음을 알 수 있습니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/3b96dfc0-998e-4798-b2c1-35a6f9e94113/image.png)
 
 
## 5. 개발자 생태계와 학습 방식의 변화
올해 서베이 참여자 중 절반 이상(약 53%)은 10년 이상의 경력을 보유하고 있으며, 약 70%가 현재 정규직 또는 고용 상태를 유지하고 있다고 응답했습니다. 이는 여전히 **시니어 개발자들이 산업 트렌드 전반에 강한 영향력을 발휘**하고 있음을 보여줍니다. 
 
반면, 서베이 응답자 규모는 2024년 65,000명에서 2025년 49,000명으로 감소했고, 특히 18~24세 연령대가 3% 줄어든 것은 젊은 개발자층의 이탈과 함께 Stack Overflow 이용률이 하락했음을 나타냅니다. 이는 AI 기술 확산으로 인한 개발자 커뮤니티 구조의 변화가 빠르게 진행되고 있음을 보여줍니다.
 
학습 방식에서도 변화를 확인할 수 있습니다. **응답자의 44%는 AI 도구를 활용해 코딩을 학습해본 경험이 있다고 답했으며, 69%는 AI를 통해 생산성이 향상되었다고 응답**했습니다. 이는 개발 학습과 업무 방식이 AI 중심으로 전환되고 있음을 보여주고 있습니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/939352c2-1412-48bf-9957-e6e846dce979/image.png)
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/f4270d99-5385-4f74-bb2f-8bba10bba897/image.png)
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/b9c34658-1f4a-42df-8724-e3daed0097fb/image.png)
 
 
이번 2025 Stack Overflow 개발자 서베이는 **AI 도구의 빠른 확산과 동시에 신뢰도의 한계**를 보여주었습니다. GPT는 여전히 가장 널리 사용되는 LLM으로 자리잡았지만, Claude와 같은 대안 모델들이 전문 개발자들의 선택을 받으며 새로운 균형을 만들어가고 있습니다. 
 
또 Python, Rust, Go 같은 언어의 약진과 함께, 개발자들이 여전히 커뮤니티에서 맥락 있는 지식을 얻고 있다는 점도 눈에 띄었습니다. 결국, **AI와 사람이 공존하며 상호 보완하는 개발 환경**이 앞으로도 중요한 흐름이 될 것입니다.
 
 
### 📌 참고 사이트
* [2025 Developer Survey](https://survey.stackoverflow.co/2025/)
 
 
[![AI BE_배너.jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/03aa1e95-b178-4956-8f5e-951463419d90/AI%20BE_%E1%84%87%E1%85%A2%E1%84%82%E1%85%A5.jpg)](https://school.programmers.co.kr/learn/courses/25330?utm_source=prgmblog&utm_medium=social&utm_campaign=school_25330_blog&utm_content=25330_banner)

2025 Stack Overflow 개발자 서베이로 보는 개발 트렌드와 인사이트

요리를 잘하려면 레시피만 많이 아는 것으로는 부족하듯, 개발자의 성장도 단순한 기술 습득을 넘어서는 시점이 찾아옵니다. 이 글은 개발자로서 ‘정체기’를 겪는 순간에 마주하는 불안과 답답함을 어떻게 받아들이고, 어떤 방식으로 돌파할 수 있을지에 대해 이야기합니다. 표면적인 성장을 넘어 진짜 실력을 다져가는 과정이 궁금하다면, 끝까지 읽어보세요!
 
 
# 레시피는 많이 아는데 요리가 맛이 없는 이유
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/d5cbac65-aaa9-41f1-838d-45aae6f10eb8/image.png)
 
요리를 처음 시작할 때가 기억납니다. 라면 끓이기부터 시작해서 계란후라이, 볶음밥 순서로 하나씩 배워나갔을 때의 그 성취감은 마치 내가 주방장이 된 느낌이 듭니다. 매번 새로운 요리법을 시도할 때마다 "오, 이렇게 하면 맛있네!"라며 눈에 띄게 실력이 늘어가는 것을 느낄 수 있었죠. 유튜브에서 레시피를 하나씩 따라 하는 것만으로도 충분히 맛있는 음식을 만들 수 있었고, 친구들도 맛있다고 칭찬해 줄 때마다 요리에 대한 자신감이 쌓여갔습니다.
 
하지만 어느 정도 시간이 지나면서 묘한 벽에 부딪치게 되었습니다. 기본적인 요리법은 거의 다 알고 있고, 레시피만 보면 실패 없이 만들 수 있습니다. 하지만 뭔가 많이 아쉽습니다. 조미료 덕분에 맛은 있지만 특별하지 않고, 식당에서 먹는 것과는 큰 차이가 있습니다. "내 요리에는 뭔가가 부족해"라는 생각이 들기 시작하죠. ‘레시피 따라쟁이' 수준에서 벗어나지 못하는 기분입니다.
 
"더 복잡한 요리를 배워야 하나? 아니면 더 비싼 재료를 써야 하나?" 하지만 진짜 문제는 따로 있었습니다. 바로 자신만의 '요리 철학'과 '미각 감각'을 개발하지 못했기 때문입니다.
 
개발자의 성장 여정도 이와 놀랍도록 닮아있습니다. **처음 프로그래밍을 배우기 시작했을 때의 짜릿한 성취감, 새로운 언어나 프레임워크를 익힐 때마다 느꼈던 뿌듯함이 어느 순간 사라집니다**. 예전 같으면 일주일이면 '마스터'했을 기술이 몇 달을 투자해도 제자리걸음인 것 같고, 동료들은 계속 성장하는 것 같은데 나만 정체되어 있는 기분이 듭니다.
 
"이제 더 이상 늘지 않는 건 아닐까?" 이런 불안감이 마음 한켠을 파고들기 시작합니다. 하지만 요리에서 진정한 셰프가 되는 것이 바로 이 지점부터 시작되듯이, 개발자도 이 정체기를 돌파해야 진정한 전문가의 경지에 도달할 수 있습니다.
 
# 정체기의 신호들
학습 곡선의 정체기는 보통 조용히 찾아옵니다. 갑작스럽게 실력이 멈추는 것이 아니라, 서서히 성장 속도가 둔화되면서 어느 순간 깨닫게 됩니다.
 
가장 흔한 신호는 **새로운 것을 배우는 속도의 둔화**입니다. 예전에는 새로운 라이브러리나 도구를 하루 이틀이면 대충 파악했는데, 이제는 일주일을 투자해도 겉핥기 식 이해에 그칩니다. 문서를 읽어도 예전만큼 빠르게 흡수되지 않고, 튜토리얼을 따라 해도 "아하!" 하는 순간이 드물어집니다.
 
**두 번째는 반복되는 패턴의 늪**입니다. 새로운 프로젝트를 시작해도 결국 비슷한 방식으로 해결하게 되고, 코드 스타일이나 접근 방법이 몇 년 전과 크게 달라지지 않았다는 것을 발견합니다. 마치 같은 길만 계속 걷고 있는 기분이 듭니다.
 
저의 경우를 예로 들면, 개발 경력 4년 차쯤 이런 정체기를 경험했습니다. Spring Boot로 REST API를 개발하는 일이 너무나도 익숙해진 나머지, 새로운 요구사항이 와도 "아, 이것도 결국 CRUD네"라는 생각이 먼저 들었습니다. 기술적으로는 능숙해졌지만, 그 능숙함이 오히려 새로운 관점을 차단하는 족쇄가 되어있었던 것이죠.
 
**세 번째 신호는 학습 의욕의 저하**입니다. 새로운 기술 소식을 들어도 "또 새로운 게 나왔네" 정도의 반응에 그치고, 깊이 파고들고 싶은 호기심이 예전만큼 강하지 않습니다. 기술 블로그나 컨퍼런스 영상을 보다가도 중간에 집중력이 떨어져 다른 일을 하게 됩니다.
 
이런 신호들을 발견했다고 해서 자신을 탓할 필요는 없습니다. 오히려 이는 여러분이 어느 정도의 전문성을 쌓아가고 있다는 증거이기도 합니다. 문제는 이 지점에서 멈추느냐, 아니면 다른 단계로 나아가느냐의 선택에 있습니다.
 
# 우선 받아들이기
정체기에 부딪혔을 때 가장 먼저 해야 할 일은 받아들이는 것입니다. 불안감과 조급함은 오히려 학습 효율을 떨어뜨리고, 잘못된 방향으로 에너지를 소모하게 만듭니다.
 
성장 곡선은 마치 주식 차트처럼, 상승과 하락을 오가는 형태를 띠곤 합니다. 이는 뇌가 새로운 정보를 통합하고 내재화하는 데 필요한 시간이기도 합니다. 정체기에 있는 개발자들이 흔히 하는 실수는 여전히 '양적 성장'에만 집중하는 것입니다. "새로운 언어를 몇 개나 배웠는가", "얼마나 많은 라이브러리를 알고 있는가"와 같은 지표 말입니다.
 
**하지만 이 시점에서는 질적 성장도 주목해야 합니다**. 같은 문제를 더 우아하게 해결할 수 있게 되었는가? 코드의 가독성과 유지보수성이 향상되었는가? 시스템 전체를 바라보는 시야가 넓어졌는가? 이런 내적 성장은 외부에서 쉽게 드러나지 않지만, 진정한 전문성의 토대가 됩니다.
 
# 기존 방식의 한계 인정
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/04640654-aef1-4bc8-8086-e54961c597e3/image.png)
 
정체기에 빠진 개발자들이 자주 하는 실수는 기존의 학습 방법을 더 열심히 반복하는 것입니다. 마치 수백 번 돌려본 영화를 중독처럼 계속 반복해서 시청하는 것처럼 말이죠. 이 시점에서는 학습 방법을 바꿔야 합니다.
 
문제를 해결하는 학습으로의 전환이 필요합니다. 예전에는 "이 프레임워크의 모든 기능을 다 알아야지"라는 접근을 했다면, 이제는 "이 문제를 해결하기 위해 어떤 도구와 방법이 최적일까?"라는 관점으로 바꿔야 합니다.
 
구체적인 방법론 전환 사례를 들어보겠습니다:
 
첫째는 **능동적 학습으로의 전환**입니다. 기존에는 유명한 개발자의 블로그나 유튜브를 시간 날 때마다 수동적으로 소비했다면, 이제는 구체적인 문제나 궁금증을 먼저 정의하고 그것을 해결하기 위한 자료를 능동적으로 탐색해야 합니다. 마치 요리할 음식을 정하지 않고 마트에서 이것저것 구경하는 것과, 명확한 레시피를 염두에 두고 필요한 재료를 찾아가는 것의 차이와 같습니다.
 
둘째는 **깊은 학습으로의 전환**입니다. 새로운 기술이 나올 때마다 표면적으로 훑어보는 것에 머물지 않고, 현재 사용하는 기술의 내부 동작 원리와 철학을 깊이 있게 이해하는 것입니다. 수많은 요리법을 대충 알고 있는 것보다, 몇 가지 요리라도 그 원리와 변형 방법을 완전히 터득하는 것이 더 가치 있는 것처럼 말입니다.
 
셋째는 **맥락적 학습으로의 전환**입니다. 각각의 기술을 독립적으로 학습하던 방식에서 벗어나 기술들 간의 연관성과 전체 시스템에서의 역할을 이해해야 합니다. 개별 요리 기법만 아는 것이 아니라, 한 끼 식사 전체의 조화와 균형을 생각하는 셰프의 관점으로 접근하는 것입니다.
 
제 경험을 나누자면, 정체기 때 가장 도움이 되었던 학습법은 '역공학(Reverse Engineering) 학습'이었습니다. 내가 자주 사용하는 라이브러리나 프레임워크의 소스코드를 직접 분석해 보는 것이었죠.
 
예를 들어, jQuery의 $(selector) 문법이 어떻게 동작하는지 궁금해서 라이브러리 코드를 열어봤습니다. 겉으로는 마법처럼 보이던 기능들이 실제로는 어떤 원리로 구현되어 있는지 알게 되면서, 단순히 사용법을 아는 것과 동작 원리를 이해하는 것의 차이를 깨달았습니다.
 
이런 깊이 있는 학습은 단기간에 눈에 띄는 성과를 보여주지는 않지만, 장기적으로는 훨씬 견고한 전문성을 만들어줍니다.
 
# 구체적 실천 방법
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/76ceb34d-603a-4bc5-ac8e-488dc70dede2/image.png)
 
### **✅ 전략 1: 굳이 어렵게 만들어보기**
평소 하던 작업에 인위적으로 어려움을 만들어 보세요. 이는 마치 요리사가 평소 사용하던 조미료를 빼고 요리하거나, 새로운 조리도구로 같은 요리를 만들어보는 것과 같습니다. 예를 들어, **항상 사용하던 라이브러리 없이 구현해 보기, 더 적은 메모리나 더 빠른 속도로 같은 기능 구현하기, 다른 패러다임(함수형, 객체지향 등)으로 같은 문제 해결해 보기** 등입니다.
 
저는 한 번 "axios나 fetch 래퍼 없이 순수 XMLHttpRequest로 HTTP 클라이언트 만들기"라는 도전을 했습니다. 평소에는 당연히 사용하던 라이브러리의 편의 기능들을 직접 구현하면서, 네트워크 통신의 깊은 부분을 이해할 수 있었습니다. 에러 핸들링, 타임아웃 처리 등을 직접 구현하면서 axios가 내부적으로 얼마나 많은 복잡성을 숨기고 있었는지 깨달았습니다.
 
또 다른 예로는 "CSS 프레임워크 없이 반응형 디자인 구현하기"를 시도해 볼 수 있습니다. Bootstrap이나 Tailwind 없이 순수 CSS 만으로 그리드 시스템과 컴포넌트를 만들어보면, CSS의 근본 원리와 레이아웃 메커니즘을 더 깊이 이해하게 됩니다. 처음에는 답답하고 비효율적으로 느껴지지만, **이런 경험이 쌓이면 어떤 상황에서든 유연하게 대응할 수 있는 기반**이 됩니다.
 
### **✅ 전략 2: 인사이트 가져오기**
개발 외의 다른 분야에서 인사이트를 가져오는 것도 좋은 방법입니다. 디자인, 경영학, 심리학, 수학, 음악 등에서 배운 개념을 개발에 적용해 보세요. 이는 마치 퓨전 요리처럼 서로 다른 요리 문화의 장점을 결합하여 새로운 맛을 창조하는 것과 같습니다.
 
**예를 들어, 디자인의 '사용자 경험' 개념을 코드에 적용하면 '개발자 경험(DX)'을 개선하는 방향으로 사고가 확장됩니다**. 코드를 작성하는 개발자의 입장에서 더 직관적이고 사용하기 쉬운 API를 설계하게 되죠. 함수명이나 매개변수 구조를 정할 때도 "이 코드를 처음 보는 개발자가 쉽게 이해할 수 있을까?"라는 관점에서 접근하게 됩니다.
 
### **✅ 전략 3: 기술 토크**
저는 정체기 때 지인들과 함께 "기술 토크"라는 작은 모임을 만들었습니다. 1시간 정도로 짧게, 최근에 배운 것이나 해결한 문제를 동료들과 공유하는 시간이었죠. 준비하는 과정에서 제 지식의 빈틈을 발견하게 되었고, 동료들의 질문을 통해 새로운 관점을 얻을 수 있었습니다.
 
**특히 "왜?"라는 질문을 받을 때마다, 단순히 "이렇게 하면 동작하니까!"가 아닌 더 근본적인 이유를 설명해야 했습니다**. 이 과정에서 제가 무의식적으로 사용하던 패턴들을 의식적으로 분석하게 되었고, 더 나은 대안을 찾아보게 되었습니다.
 
**신입 개발자 멘토링을 해보는 것도 추천**합니다. 멘티의 질문은 대부분 매우 기본적이지만, 그 기본을 명확하게 설명하려고 하다 보면 오히려 자신의 지식 체계에서 놓치고 있던 부분을 발견하게 됩니다.
 
### ✅ 전략 4: 평가 받아보기
개인 프로젝트나 오픈소스 기여를 통해 **실제 사용자가 있는 문제를 해결**해보세요. 학습용 토이 프로젝트와 실제 서비스는 고려해야 할 요소가 완전히 다릅니다. 이는 마치 요리 연습용으로 만드는 음식과 실제 손님에게 내놓을 음식의 차이와 같습니다. 성능, 보안, 확장성, 유지보수성, 사용자 피드백 등을 모두 고려한 개발 경험은 새로운 차원의 성장을 가져다줍니다.
 
제가 추천하는 방법은 **작지만 실제로 사용할 수 있는 도구를 만들어보는 것**입니다. 예를 들어, 팀에서 반복적으로 하는 작업을 자동화하는 스크립트나, 개인적으로 불편했던 점을 해결하는 간단한 웹 애플리케이션 등입니다. 실제 사용자가 있다는 것은 코드 품질에 대한 책임감을 높이고, 예상치 못한 버그나 엣지 케이스를 경험할 기회를 제공합니다.
 
**오픈소스 프로젝트에 기여하는 것도 좋은 방법**입니다. 처음에는 문서 오타 수정이나 간단한 버그 픽스부터 시작해서, 점차 새로운 기능 개발에 참여해 볼 수 있습니다. 다른 개발자들과 협업하면서 코드 리뷰 문화와 소프트웨어 개발 프로세스를 배울 수 있고, 전 세계 개발자들의 다양한 관점과 접근 방법을 경험할 수 있습니다.
 
또한 실제 사용자들의 피드백을 받아보는 경험도 중요합니다. 개발자 관점에서는 완벽해 보이는 기능도 사용자에게는 불편할 수 있고, 예상치 못한 방식으로 사용되기도 합니다. **이런 경험을 통해 사용자 중심적 사고를 기를 수 있고, 더 나은 제품을 만드는 능력을 개발**할 수 있습니다.
 
개인 프로젝트를 진행할 때는 완벽을 추구하기보다는 **빠르게 프로토타입을 만들고 지속적으로 개선해나가는 방식을 추천**합니다. 실제 서비스의 생명주기를 경험하면서 초기 설계의 중요성, 확장성 고려 사항, 레거시 코드 관리 등 실무에서 마주치는 다양한 도전들을 미리 경험해 볼 수 있습니다.
 
# 전문가를 향해
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/0665b132-9799-48a8-860a-f58df5f1a1ea/image.png)
 
정체기는 끝이 아닌 새로운 시작입니다. 마치 등반가가 고원지대에서 잠시 숨을 고르며 다음 구간을 준비하듯, 개발자의 정체기도 다음 단계로 도약하기 위한 준비 과정입니다.
 
중요한 것은 조급해하지 않는 것입니다. 나무가 뿌리를 깊이 내릴 때는 겉으로 보이는 성장이 더딜 수 있지만, 그 뿌리가 더 큰 나무로 자라날 수 있는 토대가 됩니다. 여러분의 정체기도 마찬가지입니다. **지금 쌓고 있는 깊이 있는 이해와 새로운 학습 방법론이 앞으로의 비약적 성장을 위한 든든한 기반이 될 것**입니다.
 
정체기를 겪고 있는 모든 개발자분들께 말씀드리고 싶습니다. **여러분은 지금 성장하지 않는 것이 아니라, 다른 방식으로 성장하고 있는 것**입니다. 그 성장은 겉으로 드러나지 않을 수 있지만, 분명히 여러분을 더 성숙한 개발자로 만들어가고 있습니다. 조금 더 인내심을 가지고, 새로운 방법으로 도전해 보세요. 그 끝에는 여러분이 상상했던 것보다 더 높은 곳에서 바라보는 새로운 풍경이 기다리고 있을 것입니다.
 
 
![고코더 작가님 프로필 카드.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/56e1c3ba-f501-4621-9dc7-fd42d62a8093/%E1%84%80%E1%85%A9%E1%84%8F%E1%85%A9%E1%84%83%E1%85%A5%20%E1%84%8C%E1%85%A1%E1%86%A8%E1%84%80%E1%85%A1%E1%84%82%E1%85%B5%E1%86%B7%20%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%84%91%E1%85%B5%E1%86%AF%20%E1%84%8F%E1%85%A1%E1%84%83%E1%85%B3.png)

개발자의 학습 곡선 정체기: 더 이상 실력이 늘지 않을 때

팀 단위로 소프트웨어 개발을 할 때 필수적으로 사용하는 도구 중 하나가 버전 관리 시스템 Git입니다. Git은 add, commit, log, stash 등 버전 관리를 위한 다양한 명령어를 제공합니다. 혹시 자주 쓰는 Git 명령어를 조합하거나 직접 수정해서 사용하고 싶은 적 없으셨나요?
 
예를 들어, 흔히 사용하는 `git pull` 명령어는 `git fetch & git merge`와 같이 두 가지 명령어를 조합한 명령어입니다.
 
```
# 원격 저장소의 내용을 다운로드합니다.
$ git fetch

# 로컬 저장소에 내용을 병합합니다.
$ git merge

# 원격 저장소의 내용을 다운로드해서 로컬 저장소에 병합합니다.
$ git pull
```
 
pull 명령어 한 번이면 두 단계의 명령어를 한 번에 실행할 수 있어서 사용자 편의성이 더 높아지고 작업 흐름이 단순화됩니다. 이러한 원리를 활용하여 Git 명령어를 직접 조합해서 사용하면 작업자의 입맛에 맞게 Git을 더 능숙하게 사용할 수 있습니다.
 
이 글에서는 Git의 별칭(alias) 기능을 활용하여 사용자 고유의 명령어를 만드는 방법을 알아봅니다. `git pull`과 같이 여러 명령어를 한 명령어로 조합하는 것뿐만 아니라 하나의 명령어에서 여러 옵션을 간소화하여 사용하는 방법도 함께 살펴보겠습니다.
 
> * 본 글에서는 Git CLI(Command Line Interface) 환경에서 사용하는 방법을 다룹니다.
> * 본 글에서 만드는 별칭 명령어가 수행하는 기능은 Visual Studio Code 같은 에디터나 GitKraken 같은 유명한 GUI(Graphical User Interface) 프로그램에서 이미 제공되고 있을 수 있습니다.

 
# 준비
연습용 저장소를 준비합니다. 본인이 작업하고 있는 저장소도 좋습니다. 커밋 히스토리가 적당히 있으면 됩니다.
저는 정적 사이트를 만들어주는 오픈 소스 프로젝트 Nextra를 가져오겠습니다.
 
```
$ git clone https://github.com/shuding/nextra.git
$ cd nextra
```
 
# 커밋 로그 그래프를 한눈에 확인하기
> * 언제 사용하나요? 커밋 로그 그래프를 한눈에 확인하고 싶을 때 사용합니다.
> * 어떻게 만드나요? `git log` 명령어에서 제공하는 옵션을 미리 지정하여 별칭을 만듭니다.

 
Git에서 중요한 내용은 대부분 커밋(commit)에 기록되어 있습니다. 프로젝트에서 어떤 일이 진행되었는지, 어떤 코드가 언제 추가되었거나 삭제되었는지, 누가 무엇을 변경했는지 알고 싶다면 커밋 기록을 살펴보면 됩니다. 커밋 기록을 살펴보는 강력한 명령어가 `git log`인데요. `git log`에서는 제공하는 옵션을 활용하여 커밋 기록을 빠르게 살펴볼 수 있는 alias를 만들겠습니다.
 
git log에서 제공되는 다음과 같은 옵션을 적용하면 기본적인 형태의 커밋 로그 그래프를 확인할 수 있습니다.
 
```
$ git log --oneline --decorate --graph
```
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/7598dedf-054c-48f9-810e-ca2337a7c2f8/image.png)
 
하지만 커밋이 언제 작성되었는지, 누가 작성했는지는 나타나지 않네요. 다음과 같이 커밋의 작성 날짜와 작성자를 볼 수 있다면 더 좋겠습니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/59a1cbd8-bc25-4fe0-891b-aec56feb23e0/image.png)
 
커밋에 대한 정보가 한눈에 더 잘 들어오지 않나요?
위와 같은 그래프를 보려면 다음과 같이 명령어를 입력해야 합니다.
 
```
$ git log \
 --color --graph --decorate \
 --date=format:'%Y-%m-%d' \
 --abbrev-commit \
 --pretty=format:'%C(red)%h%C(auto)%d %s %C(green)(%cr)%C(bold blue) %an'
```
 
너무 길죠? 이 명령어를 간단하고 쉽게 사용할 수 있도록 별칭을 만들겠습니다.
 
별칭 기능을 사용하려면 Git의 설정 파일을 수정하면 됩니다.
 
```
# 로컬 프로젝트 범위에 적용되는 설정 파일을 변경합니다.
$ git config --edit --local

# 또는 원하는 에디터로 직접 열어서 수정해도 됩니다.
$ vi .git/config # vim으로 설정 파일 열기
$ code .git/config # vscode로 설정 파일 열기
```
 
아래와 같이 alias 항목을 추가합니다.
 
```
[alias]
 l = "log \
 --color --graph --decorate \
 --date=format:'%Y-%m-%d' \
 --abbrev-commit \
 --pretty=format:'%C(red)%h%C(auto)%d %s %C(magenta)(%cr)%C(bold green) %an'"
```
 
이제 직접 만든 커스텀 명령어를 실행해보세요.
 
```
$ git l
```
 
위에서 봤던 커밋 해시, 브랜치, 커밋 이름, 날짜, 작성자 이름 같은 주요 항목들이 모두 출력되고, 각 항목을 색상별로 확인할 수 있습니다.
 
### 참고 자료
* [git log - 포맷 옵션](https://git-scm.com/docs/git-log#_pretty_formats)
* [git config - 설정 파일 적용 방법](https://git-scm.com/book/ko/v2/Git%EB%A7%9E%EC%B6%A4-Git-%EC%84%A4%EC%A0%95%ED%95%98%EA%B8%B0)

 
# 여러 개의 커밋을 하나로 합치기
> * 언제 사용하나요? 여러 커밋을 하나로 합치고 싶을 때 사용합니다.
> * 어떻게 만드나요? log, reset, commit 명령어를 조합해서 별칭을 만듭니다.

 
작업을 하다 보면 비슷한 작업을 했던 여러 커밋을 하나로 합치고 싶을 때가 있습니다. 명령어 한 번으로 여러 개의 커밋을 하나로 합치는 방법을 알아보겠습니다.
 
아래 커밋 그래프를 확인해주세요. 각 커밋을 보면 작업자가 다음과 같이 코드를 변경했습니다.
* `b6c57a24`: 사이드바 UI에 버그가 있어서 고치는 작업을 했습니다.
* `e3dbbf4f`: 그런데 해당 버그와 관련된 수정할 부분이 추가로 발견되어 한 번 더 작업을 했습니다.
* `46015e38`: 웬걸, 해당 버그와 관련된 부분이 또 있었습니다.

 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/390967f7-a841-4bf6-a01c-198590d9f598/image.png)
 
동일한 버그를 수정한 작업이라서 하나의 커밋으로 합치고 싶습니다. 어떻게 해야 할까요?
일반적으로 `git rebase -i` 명령어를 사용해서 인터랙티브 모드에 진입하여 해결합니다.
 
```
$ git rebase -i b6c57a24
```
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/993ee1f6-265d-44db-b05d-22b89b351daf/image.png)
 
인터랙티브 모드에 진입하여 추가로 작업한 두 개의 커밋 앞에 s(=squash) 커맨드를 입력하면, 두 개의 추가 커밋이 첫번째 작업 커밋으로 합쳐집니다.
 
인터랙티브 모드로도 커밋을 합칠 수도 있지만, 여러 단계를 밟지 않고 명령어 한 번으로 수행할 수 있으면 어떨까요?
위에서 했던 것처럼 git 설정 파일을 열어서 `squash`라는 이름으로 alias를 추가합니다.
 
```
[alias]
 l = "log \
 --color --graph --decorate \
 --date=format:'%Y-%m-%d' \
 --abbrev-commit \
 --pretty=format:'%C(red)%h%C(auto)%d %s %C(magenta)(%cr)%C(bold green) %an'"

 squash = "!f() { \
 messages=$(git log --format=%B --reverse ${1}~..HEAD); \
 git reset --soft ${1} && \
 echo \"${messages}\" | git commit --amend --allow-empty -F -; \
 unset -f f; \
 }; f"
```
 
명령어에 대한 설명은 뒤에서 하기로 하고, 사용법부터 살펴보면 다음과 같습니다.
 
```
# git squash <합쳐질 부모 커밋>
$ git squash b6c57a24
```
 
직접 실행해서 보여드리겠습니다. 현재 커밋 로그는 다음과 같습니다. 커밋 메시지를 자세히 보기 위해 `git log` 명령어를 실행했습니다. 이제 아래와 같은 커밋 로그가 어떻게 변하는지 확인해보세요.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/10760e7b-9c72-4333-b41a-db16ad02e848/image.png)
 
위 명령어를 실행했을 때 기대하는 결과는 커밋 `46015e38`, `e3dbbf4f`, `b6c57a24`가 **하나로 합쳐지는 것(squash)** 입니다.
이때 커밋에 포함된 변경사항만 합치는 것이 아니라 커밋에 기록된 커밋 메시지도 함께 보존하겠습니다.
 
```
$ git squash b6c57a24
```
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/6db15c90-c610-4649-acc4-ff3878862b69/image.png)
 
3개의 커밋이 하나로 합쳐지면서 커밋에 변경사항이 생겼기 때문에 b6c57a24는 새로운 해시 d6ffced2로 변경되었고, 기존 커밋 메시지가 보존된 채로 변경 사항이 하나로 합쳐졌습니다.
 
우리가 만든 `git l` 명령어를 실행해보면 커밋 로그가 더 깔끔해진 것을 확인할 수 있습니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/632fdcda-aa8f-42b9-876b-94fd59ee361a/image.png)
 
그런데 코드를 더 나은 방식으로 작성할 수 있습니다. 예를 들어 `git squash` 뒤에 파라미터를 전달하지 않으면 다음과 같이 경고 메시지를 출력하고 싶습니다.
 
```
$ git squash
Please provide the commit hash of the parent commit where other commits will be squashed into.
```
 
아래와 같이 수정하면 됩니다.
 
```
[alias]
 l = "log \
 --color --graph --decorate \
 --date=format:'%Y-%m-%d' \
 --abbrev-commit \
 --pretty=format:'%C(red)%h%C(auto)%d %s %C(magenta)(%cr)%C(bold green) %an'"

 squash = "!f() { \
 if [ -z \"$1\" ]; then \
 echo 'Please provide the commit hash of the parent commit where other commits will be squashed into.'; \
 else \
 messages=$(git log --format=%B --reverse ${1}~..HEAD); \
 git reset --soft ${1} && \
 echo \"${messages}\" | git commit --amend --allow-empty -F -; \
 fi; \
 unset -f f; \
 }; f"
```
 
이제 주석을 추가하여 위 코드가 하는 일을 간략하게 설명하겠습니다.
 
```
[alias]
 l = "log \
 --color --graph --decorate \
 --date=format:'%Y-%m-%d' \
 --abbrev-commit \
 --pretty=format:'%C(red)%h%C(auto)%d %s %C(magenta)(%cr)%C(bold green) %an'"

 squash = "!f() { \
 # 인자($1)를 전달하지 않으면 경고 메시지를 출력합니다.;\n \
 if [ -z \"$1\" ]; then \
 echo 'Please provide the commit hash of the parent commit where other commits will be squashed into.'; \
 else \
 # 인자($1)로 전달한 부모 커밋부터 현재 브랜치(HEAD)의 모든 커밋 메시지를 가져옵니다.;\n \
 messages=$(git log --format=%B --reverse ${1}~..HEAD); \
 # 현재 브랜치를 인자($1)로 전달한 부모 커밋으로 되돌립니다. 이때 부모 커밋 이후의 모든 변경사항을 staging area에 추가합니다.;\n \
 git reset --soft ${1} && \
 # 가져온 커밋 메시지를 사용해서 현재 커밋에 덮어씌웁니다.;\n \
 echo \"${messages}\" | git commit --amend --allow-empty -F -; \
 fi; \
 unset -f f; \
 }; f"
```
 
### 참고 자료
* [git rebase](https://git-scm.com/book/ko/v2/Git-%EB%B8%8C%EB%9E%9C%EC%B9%98-Rebase-%ED%95%98%EA%B8%B0)
* [git reset](https://git-scm.com/book/ko/v2/Git-%EB%8F%84%EA%B5%AC-Reset-%EB%AA%85%ED%99%95%ED%9E%88-%EC%95%8C%EA%B3%A0-%EA%B0%80%EA%B8%B0)

 
# 마무리
제가 자주 사용하는 alias를 몇 가지 간략하게 공유하면서 글을 마치겠습니다.
 
```
# 기존 명령어 간소화 또는 일부 변경
s = status

sw = switch 
swc = switch -c

ac = "!git add --all && git commit -v" 
amend = commit -a --amend --no-edit 
precommit = commit --allow-empty -n

pushthis = push origin HEAD

# 추적하지 않는 파일도 포함해서 stash 하기
stash = stash --include-untracked

# n번째 stash의 내용 확인하기
stash-show = "!f() { git stash show -p --include-untracked \"${1:-0}\"; }; f"

# 현재 가리키고 있는 커밋 해시 출력
hash = "!git rev-parse --short HEAD"

# 현재 체크아웃된 브랜치의 이름 출력
head = !git rev-parse --abbrev-ref HEAD

# 현재 브랜치의 백업 브랜치 만들기
bak = "!git switch -c \"bak/$(git head)\""

# 백업 브랜치 일괄 삭제하기
bak-clean = "!git for-each-ref refs/heads/bak --format='%(refname)' | while read ref ; do branch=${ref#refs/heads/} ; git branch -D $branch ; done"

# 동일한 이름의 로컬 브랜치를 원격 저장소와 동기화하기
synchard = "!f() { git fetch --all && git checkout ${1:-main} && git reset --hard origin/${1:-main} && git switch - ; }; f"
```
 
본 글에서 만든 alias에 대한 전체 코드는 [링크](https://gist.github.com/datalater/2e89ff92c264f3ee3a5fed1e1385827e)에서 확인할 수 있습니다.
 
### 함께 읽으면 좋은 글
* [git-scm.com - Git Aliases](https://git-scm.com/book/en/v2/Git-Basics-Git-Aliases)
* [왕초보를 위한 Git 명령어 모음집 (1)](https://community.programmers.co.kr/post/11749)
* [왕초보를 위한 Git 명령어 모음집 (2)](https://community.programmers.co.kr/post/11848)

 
 
글 작성: 조민철 (Grepp 프론트엔드 개발자)
 
 
[![AI BE_배너.jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/f2ef708f-59d8-4e51-a27e-49b0b60d77fe/AI%20BE_%E1%84%87%E1%85%A2%E1%84%82%E1%85%A5.jpg)](https://school.programmers.co.kr/learn/courses/25186?utm_source=prgmblog&utm_medium=social&utm_campaign=school_25186_blog&utm_content=25186_banner)

Git 명령어 사용 꿀팁: 자주쓰는 Git 명령어 한 줄로 줄여보기

데브코스 수료 이후, 실제 실무와 유사한 환경에서 프로젝트를 경험할 수 있는 프로그래머스 인턴십 1기가 진행되었습니다.
이번 인터뷰에서는 데브코스 백엔드 8기를 수료한 한민희 님과 함께, 한 달간의 인턴십 과정에서 경험한 실무형 협업에 대한 이야기를 나누어보았습니다.
코드 리뷰, PR 관리, 인프라 구성, 멘토링까지. 민희 님이 경험한 '진짜 실무' 이야기, 지금 확인해보세요!
 
 
#### 📌 프로그래머스 인턴십이란?
<div style="border-radius: 4px;padding:22px 20px; background: #F5F5F5; display: flex;">프로그래머스 인턴십은 데브코스에서 쌓은 개발 역량을 실제 서비스 개발 경험으로 확장할 수 있도록 설계된 인턴십 프로그램입니다. 4주 동안 AI 서비스의 기획부터 개발, 배포, 최종 발표까지 전 과정을 팀 단위로 수행하며, 그렙(프로그래머스)의 재택 근무 문화를 반영해 전면 재택으로 운영됩니다. 참가자들은 Slack, Notion, GitHub, GLM API, AWS 등 실무에서 활용되는 협업 도구를 사용하며 현업과 유사한 개발 환경을 경험하고, 현업 멘토의 정기 멘토링을 통해 실무 협업 방식과 문제 해결 역량을 함께 키워나갑니다.
</div>

 
 
 
## 안녕하세요. 간단한 자기소개와 인턴십에 참여하게 된 계기를 소개해주세요.
안녕하세요. 프로그래머스 데브코스 백엔드 8기를 수료한 한민희입니다. 대학교 졸업 전, 실무에 필요한 개발 역량과 경험을 쌓고자 데브코스에 참여하게 되었습니다.
 
이후 실제 현업과 유사한 환경에서 프로젝트를 경험해보고 싶다는 생각이 들어, 그렙(프로그래머스)에서 진행한 한 달 간의 체험형 인턴십에도 참여하게 되었습니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/9edd1f10-854d-485b-bc72-17b620951354/image.png)
 
 
## 참여 전 가장 기대됐던 부분과 걱정됐던 부분은 무엇이었나요?
가장 기대됐던 부분은 실제 서비스 환경과 유사한 인프라 위에서 프로젝트를 구축하고, 현업 멘토링을 통해 실제 회사에서 진행하는 개발 방식과 협업 프로세스를 직접 경험해볼 수 있다는 점이었습니다.
 
반면, 인턴십이 처음이다 보니 협업 방식이나 개발 속도에 잘 적응할 수 있을지, 그리고 실무 수준에 비해 부족한 부분이 있지는 않을지에 대한 걱정도 있었습니다.
 
 
## 인턴십 기간 동안 어떤 프로젝트에 배정되었나요?
저는 **AI 기능을 중심으로 한 프로젝트에 참여**했습니다. **기획부터 설계, 구현, 배포, 최종 발표까지 약 한 달 동안 전체 개발 사이클을 경험**했습니다.
 
특히 API 설계, 예외 처리, 인프라 구성, 협업 방식까지 팀 내에서 함께 고민하고, AI 기능을 서비스에 자연스럽게 녹여내기 위해 사용자 경험 측면에서도 많은 고민을 해볼 수 있었던 프로젝트였습니다.
 
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/3ed5105c-3b74-4c6e-9fdf-a3515430b85a/image.png)
⬆️ 기획 단계의 아이디어
 
 
## 실제 실무에 참여해보니, 기존 학습이나 사이드 프로젝트와 가장 달랐던 점은 무엇이었나요?
기존 프로젝트와 유사하게 MVP 기능을 개발하고 점차 고도화해나가는 흐름은 비슷했습니다. 다만, 실무 환경에서는 훨씬 더 많은 요소를 함께 고려해야 한다는 점이 가장 크게 다가왔습니다.
 
예를 들어 장애 상황이나 발생할 수 있는 엣지 케이스를 더 깊이 고민해야 했고, 서비스가 안정적으로 운영될 수 있는 구조인지 여러 차례 검증하는 과정도 필요했습니다. 또한 유지보수성과 확장성까지 고려하여 탄탄하게 설계해야 했기 때문에, **기존 프로젝트보다 시스템 안정성에 대해 더 많이 고민**했던 것 같습니다.
 
 
## 프로그래머스 개발자와의 멘토링은 어떤 방식으로 진행되었나요? 가장 인상 깊었던 부분은 무엇이었나요?
소속된 슬랙 채널에서 사전에 조율한 시간에 약 30분 정도 진행되었습니다. 미리 준비한 질문이 있으면 멘토님께서 답변해주셨고, 이후에는 프로젝트 진행 상황에 대해 함께 이야기 나누며 방향성을 잡아주시는 방식으로 진행되었습니다. 멘토링 내용은 문서화하여 이후에도 참고할 수 있도록 정리해두었습니다.
 
**가장 인상 깊었던 부분은 실제 그렙(프로그래머스)에서 어떤 방식으로 업무를 진행하고 있는지 들을 수 있었다는 점**입니다. 예를 들어, 프로젝트에서 양방향 암호화를 위한 마스터 키 관리가 필요했는데, 현업에서는 키가 변경되는 경우가 잦으니 관리를 위해 추가적인 인프라를 고려해보면 좋다고 멘토님께서 짚어주시며, 실제 그렙에서 사용하는 방식도 간단히 소개해주셨던 경험이 특히 기억에 남습니다.
 
 
![Frame 1000004610 (5).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/f1e0ad8d-55d6-4550-97d8-ac3f9aa75a4d/Frame%201000004610%20%285%29.png)
⬆️ 멘토링 내용을 정리해 문서화했던 멘토링 일지
 
 
## 코드 리뷰나 협업 과정에서 "아, 이게 진짜 실무구나"라고 느낀 순간이 있었나요?
PR을 자잘하게 쪼개는 작업을 진행했던 경험이 가장 기억에 남습니다. 저희 팀은 Jira를 통해 작업을 관리했는데, 기존에는 하나의 작업이 하나의 기능을 담당하게 하는 경우가 많았습니다. 하지만 **멘토님께서 실무에서는 리뷰 효율과 유지보수성을 위해서 PR을 더 작은 단위로 나누어 작업한다고 말씀해주셨고, 실제 사례와 함께 자세히 설명**해주셨습니다.
 
예를 들어, 기존에는 Controller, Service, Repository, DTO, Entity 등을 모두 구현한 뒤 하나의 PR로 올렸다면, 이후에는 서로 영향이 적은 단위로 분리해 PR을 작성하려고 노력했습니다. 작업을 나누면 리뷰어 입장에서도 변경 사항을 더 쉽게 이해할 수 있고, 문제 상황이나 에러도 빠르게 발견할 수 있다는 점을 체감할 수 있었습니다.
 
특히 멘토님께서 해주신 "코드가 +100줄이면 리뷰가 여러 개 달리지만, +1000줄이면 LGTM만 남는다"라는 말이 인상 깊었습니다. 이후에는 팀 내에서 PR 크기를 줄이는 식으로 협업 방식을 개선해나가려 노력했습니다.
 
 
## 인턴십 전후로 가장 크게 달라진 점이나, 기술적으로 성장한 부분이 있다면 무엇인가요?
기술적으로는 **CI/CD 환경 구축 경험과 인프라 활용 역량, 그리고 성능 개선 측면에서 가장 크게 성장**했다고 느낍니다. 배포 자동화나 운영 환경을 고려한 개발, 성능 개선을 위한 부하 테스트 등이 이제는 당연하게 진행해야 하는 과정이라고 느껴질 정도로 익숙해졌습니다.
 
이뿐만 아니라 **협업 방식에 대한 이해도**도 크게 높아졌습니다. 작업 단위를 어떻게 나눌지, PR을 어떻게 쪼개야 하는지, 일정 관리는 어떻게 해야 하는지, 중간 공유와 커뮤니케이션이 왜 중요한지를 직접 경험할 수 있었습니다. 이를 통해 팀 단위 개발에 대한 감각도 한층 더 키울 수 있었던 것 같습니다.
 
 
## 이번 인턴십 경험이 취업 준비에 어떤 도움이 되었나요?
기획과 기술 선택 과정에서 단순히 특정 프레임워크나 도구를 사용해보는 데 그치지 않고, **"왜 이 기술을 선택했는가"를 깊이 고민**해볼 수 있었던 점이 가장 큰 도움이 되었습니다.
 
예를 들어 다른 대안에는 어떤 것들이 있었는지, 각각의 트레이드오프는 무엇인지, 그럼에도 불구하고 현재 상황에서 왜 이 기술이 가장 적절한 선택이었는지를 팀원들과 논의하며 의사결정을 진행했습니다.
 
덕분에 단순한 구현 경험을 넘어, 문제를 어떻게 정의하고 해결해나갔는지까지 설명할 수 있게 되었고, 면접에서도 실제 저의 사례를 기반으로 더 구체적으로 답변할 수 있을 것 같습니다.
 
 
## "이 인턴십 정말 좋은 경험이었다"라고 느낀 부분이 있다면 무엇인가요?
가장 좋았던 점은 **멘토링을 통해 현업 개발자분들의 시야와 사고방식을 제 프로젝트에 직접 적용**해볼 수 있었던 점입니다.
 
프로젝트 초반에는 핵심 기능이 우선 동작할 수 있도록 MVP 구현에 집중하고, 이후에는 점진적으로 성능 개선이나 구조 개선, 예외 처리 등을 고도화해나가는 방식으로 프로젝트를 진행했습니다.
 
이 과정을 통해 **현재 단계에서 무엇이 우선순위인지 판단하는 경험**을 쌓을 수 있었고, **확장성과 유지보수성까지 고려**하는 백엔드 개발자로서의 관점을 다시 한 번 정립할 수 있었던 시간이라고 생각합니다.
 
 
## 데브코스 수료 이후 바로 실제 프로젝트를 경험해보며 가장 좋았던 점은 무엇이었나요?
**데브코스에서 학습한 백엔드 기술 스택과 협업 컨벤션을 인턴십에서 그대로 적용하고 검증**해볼 수 있었다는 점이 가장 만족스러웠습니다. 단순히 강의를 듣고 끝나는 것이 아니라, 실제 프로젝트 환경에서 직접 사용해보며 왜 이런 방식으로 개발하는지를 몸소 체감할 수 있었습니다.
 
또한 **멘토님들의 피드백을 통해 코드 품질이나 설계 방식, 협업 문화 등 실무에서 중요하게 생각하는 기준들을 배울 수 있었던 점**도 큰 장점이었습니다. 짧은 기간이었지만 다양한 실무 내용들을 들을 수 있어 개발자로서 한 단계 더 성장할 수 있었던 시간이었다고 생각합니다.
 
 
## 어떤 분들에게 데브코스 인턴십을 특히 추천하고 싶으신가요?
**실제 팀 단위 협업 경험이 부족하다고 느끼는 분들께 추천**드리고 싶습니다. 기획부터 배포까지 한 달 동안 인턴십이 진행되기 때문에, 단순한 기능 구현을 넘어 일정 관리, 역할 분담, 코드 리뷰, 의사결정 과정까지 실제 협업에 필요한 다양한 경험을 해볼 수 있었습니다.
 
또한 뛰어난 팀원들과 함께 작업하며 몰랐던 부분도 많이 배워갈 수 있었습니다.
 
무엇보다 현업 개발자 멘토님들의 피드백을 받으며 프로젝트를 개선해나가는 과정은 혼자서는 쉽게 경험하기 어려운 부분이라고 생각합니다. **실무와 유사한 환경에서 개발 경험을 쌓아보고 싶은 분들에게 정말 좋은 기회**가 될 것 같습니다.
 
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/817e299d-e7e0-4deb-a2b3-81cb5ebaa06e/image.png)
⬆️ 놓치거나 몰랐던 부분을 개선할 수 있었던 팀원들과의 PR 리뷰
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/119491a8-b6d1-4b8c-aa99-64b9f5b2a806/image.png)
⬆️ Jira를 통해 작업을 관리
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/4d45e730-56c1-445f-89af-cb7bb2e935d9/image.png)
⬆️ 진행 상황 트래킹 및 실시간 확인을 위해 Github-Jira-Discord를 연결
Discord로 작업 상황 알림
 
 
## 데브코스 수강을 고민하는 분들에게 해주고 싶은 말이 있다면요?
**데브코스의 가장 큰 장점은 학습 과정에서 궁금한 점이 생겼을 때, 현업 멘토분들께 바로 질문하고 피드백을 받을 수 있다는 점**이라고 생각합니다. 단순히 강의를 수강하는 것이 아니라, 실제 개발자분들의 사고 방식과 문제 해결 과정, 그리고 현업에서의 경험을 함께 배울 수 있습니다.
 
또한 단순히 기술을 배우는 것이 아니라, 팀 프로젝트를 통해 협업 방식과 개발자로서의 태도까지 함께 성장할 수 있었습니다. 실무 경험이 궁금하거나 개발자로서 한 단계 성장해보고 싶은 분들에게 정말 좋은 기회가 될 것 같습니다.
 
 
 
### 💡 백엔드 데브코스 11기 모집 중
수료 후 실무 인턴십까지 경험할 수 있는 기회!
백엔드 데브코스 모집 마감: ~5/26(화)
 
[![DEV-BE-coding-test-02(1456x180) 오전 10.03.54.jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/f4bcf01b-3773-474a-a363-f1eda17efd0d/DEV-BE-coding-test-02%281456x180%29%20%E1%84%8B%E1%85%A9%E1%84%8C%E1%85%A5%E1%86%AB%2010.03.54.jpg)](https://school.programmers.co.kr/learn/courses/25957?utm_source=prgmblog&utm_medium=social&utm_campaign=school_25957_sales&utm_content=intern_interview_13766)

[데브코스 인턴십 후기] 데브코스에서 배운 기술, 프로그래머스 인턴십에서 직접 적용해봤어요! - 백엔드 8기 한민희 님

백엔드 데브코스 수료 후 미리 캔버스 백엔드 개발자로 취업한 문정현 님 인터뷰입니다. 데브코스를 통해 실무 역량을 쌓고 미리캔버스에 취업하기까지, 정현 님의 여정이 궁금하시다면 인터뷰를 끝까지 읽어보세요!

 
# 안녕하세요 정현님, 소개 부탁드립니다.
안녕하세요. 저는 프로그래머스 백엔드 데브코스 2기 활동을 수료하고, 프로그래머스 썸머 코딩을 통해 미리 캔버스에서 백엔드 개발자로 활동하고 있는 문정현이라고 합니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/f1601c28-5d64-47f9-8c77-eb704bfa6b4e/image.png)
 
# 미리 캔버스에 취업할 수 있었던 비결은 무엇인가요?
데브코스를 진행하면서 채용 공고를 수시로 확인하고, **지원 자격이 된다면 일단 도전해보자는 마음으로 채용 과정을 직접 경험**하려고 했습니다. 자꾸 시도하다 보니 서류를 어떻게 작성해야 하는지 파악할 수 있었고, **코딩 테스트 문제도 꾸준히 풀며 알고리즘에 대한 감을 유지**하려고 노력했습니다. 운이 좋게 면접까지 가게 되는 경우에는 그 또한 하나의 경험이라 생각하며, 어떤 점을 보완해야 할지 계속 고민했고, 이러한 과정들이 실제 면접에서 큰 도움이 되었습니다.
 
# 취업 준비를 하면서 가장 신경 썼던 부분은 무엇인가요?
취업에 필요한 역량이 다양하다 보니 시간 관리가 가장 중요하다고 느꼈습니다. 코딩 테스트, 포트폴리오 준비, 기술 면접을 위한 CS 공부까지 어느 것 하나 소홀히 할 수 없었기에 **각 영역에 적절히 시간을 분배하며 균형 있게 공부**하려고 노력했습니다.
 
# 데브코스가 실제 취업에 도움이 되었나요?
스프링을 혼자 공부해 보려고 했지만 러닝 커브가 높아 쉽지 않았어요. 제가 원하는 IT 서비스 회사 대부분이 백엔드 프레임워크로 스프링을 사용하고 있어서, **데브코스를 통해 학습하면서 이전보다 지원할 수 있는 기업의 폭이 넓어졌어요**. 또한 데브코스에서 스프링을 활용한 프로젝트를 진행했기에 포트폴리오 작성에도 유리한 점이 많았습니다.
 
# 백엔드에 관심을 갖게 된 계기는 무엇이었나요?
학부 시절 해커톤과 다양한 프로젝트를 진행하면서 API를 활용해 사용자에게 유용한 기능을 제공할 수 있다는 점에 흥미를 느꼈습니다. 특히 직접 API를 개발하고 비즈니스 로직을 구현하는 과정에서 다양한 도메인 지식을 쌓을 수 있었고, 그 경험이 백엔드 개발에 대한 관심으로 이어졌습니다.
 
# 백엔드 데브코스엔 어떤 계기로 참여하셨나요?
백엔드 개발자로 취업하기 위해선 많은 기업들이 요구하는 스프링 프레임워크 역량이 필수라고 생각했어요. 그런데 **스프링은 독학하기엔 러닝 커브가 높다고 느껴 전문적인 교육이 필요하다고 판단**했습니다. 그러던 중 프로그래머스의 데브코스 모집 공고를 보게 되었고, 바로 지원하게 되었습니다.
 
👉 [정현 님 블로그에 작성된 백엔드 데브코스 지원 후기](https://velog.io/@y005/%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%A8%B8%EC%8A%A4-%EB%8D%B0%EB%B8%8C%EC%BD%94%EC%8A%A4-2%EA%B8%B0-%EC%A7%80%EC%9B%90-%ED%9B%84%EA%B8%B0)
 
# 많은 기관 중 프로그래머스를 선택한 이유는 무엇인가요?
프로그래머스는 개발자라면 누구나 한 번쯤 접해본 코딩 테스트 플랫폼이기도 하고, 그동안 다양한 채용 연계를 제공해왔기 때문에 프로그램에 대한 신뢰가 있었습니다. 이런 점들이 프로그래머스를 선택하는 데 큰 이유가 되었어요.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/6b228970-e7ab-42b4-b6a5-7fd0d8271722/image.png)
 
👆 [프로그래머스 코딩테스트](https://school.programmers.co.kr/learn/challenges?order=acceptance_desc&page=1)
 
# 데브코스에서 가장 기억에 남는 활동은 무엇인가요?
코로나로 인해 2년 동안 비대면 수업이 이어지면서 대부분 혼자 공부를 해왔습니다. 그런데 **데브코스에는 동료들과 함께 프로젝트를 진행하고, 멘토에게 코드 리뷰를 받으며 개발에 대해 서로 논의**할 수 있었던 것이 가장 좋았습니다. 모두가 같은 목표(백엔드 개발자)를 가지고 있어서 협업과 커뮤니케이션이 더 활발했던 것 같습니다. 또한 현업에 계신 리더분들이 진행한 세미나와 특강도 큰 도움이 되었어요.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/8504799d-1665-4784-b96d-84385ca571a7/image.png)
👆 다양한 세미나와 특강이 열렸던 백엔드 데브코스 2기
 
# 성장했다고 느꼈던 순간은 언제였나요?
현업에서 스프링을 활용해보면서 이전에 공부해왔던 개념들을 실제로 적용할 수 있었고, 코드를 더 수월하게 작성하게 되면서 성장을 체감했습니다. **멘토들의 지속적인 피드백을 통해 구조적으로 더 나은 코드를 작성**할 수 있게 되었고, 예전 코드를 다시 보며 스스로 발전했다는 것을 느꼈어요.
 
# 데브코스 전과 후, 본인의 가장 큰 변화는 무엇이라고 생각하시나요?
처음에는 단순히 취업을 목표로 공부를 시작했지만, 데브코스를 통해 웹 개발은 끊임없이 발전하는 분야라는 걸 알게 되었어요. 단기적인 취업이 아닌 **장기적인 자기 성장을 위해 계속해서 배우고 공부해야겠다는 마음**이 생겼어요. 이 점이 가장 큰 변화라고 생각합니다.
 
# 앞으로 어떤 개발자가 되고 싶으신가요?
회사와 동료에게 도움이 되는 개발자로 성장하고 싶습니다. 우선은 회사에 잘 적응하고, 백엔드 개발자로서의 역량을 지속적으로 키우는 것을 최우선으로 두고 있습니다.
 
# 데브코스 과정을 잘 따라가기 위한 팁이 있다면 공유해주세요!
데브코스는 과제와 강의량이 많지만, 기본 커리큘럼만 잘 따라가도 충분히 많은 것을 얻을 수 있습니다. 중요한 것은 매일 주어진 공부와 프로젝트를 미루지 않고 성실하게 수행하는 것이라고 생각해요. 그리고 공부하다 어려운 부분이 있으면 **혼자서 해결하기보다는 동료나 멘토에게 적극적으로 도움을 요청하는 것을 추천**합니다!
 
 
[![BE_배너.jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/ac65dc12-1f27-461f-84a3-e8dff6149501/BE_%E1%84%87%E1%85%A2%E1%84%82%E1%85%A5.jpg)](https://school.programmers.co.kr/learn/courses/25244?utm_source=prgmblog&utm_medium=social&utm_campaign=school_25244_blog&utm_content=25244_banner)

[데브코스 후기] Spring의 벽을 넘어 백엔드 개발자로 성장했어요 - 백엔드 2기 수료생 문정현 님

이직을 준비하며 많은 개발자분들이 가장 고민하는 부분 중 하나는 바로 이력서 작성입니다. 여러분의 고민을 덜어드리기 위해, 면접관 경험이 풍부한 경력자들이 함께 모여 이력서에 대한 현실적이고 실질적인 피드백을 나눴습니다. 개발자들이 가장 자주 하는 이력서 고민을 중심으로, 핵심 내용을 정리해드릴게요!
 

***
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/94d0eb2a-c24e-41cf-8ae1-9593a6648e46/image.png)
 
### "면접관은 가능성을 봅니다"
어떤 프로젝트를 진행하는 것이 도움이 될지는 채용 공고에 잘 드러나 있습니다. 개발자 채용은 **이 사람이 우리와 함께 협업할 수 있는 사람인지 그 가능성을 보는 형태**죠. 단순히 열심히 공부한다고 취업할 수 있는 것이 아니라, 기업이 원하는 경험을 갖추는 것이 중요합니다. 내가 원하는 회사가 요구하는 경력을 먼저 파악하고, 그것을 쌓기 위한 노력이 필요합니다.
 
### "공백기보다 어떻게 대처하는지가 더 중요해요"
공백 기간이 생기는 것은 어쩔 수 없습니다. 그 공백 기간을 나의 성장을 위해 어떻게 활용했는지가 중요합니다. 보통 채용 담당자들은 6개월 이상의 공백은 반드시 물어봅니다. 그 시간에 무엇을 했는지가 궁금한 것이 아니라, **사실은 대답을 어떻게 하는지가 궁금한 거죠**. 공백 기간에 좀 더 구체성을 부여하면서 이 시간이 내 삶에 의미 있는 시간이었음을 드러내세요.
 
### "내가 생각하는 방향성을 이야기해보세요"
많은 지원자분들이 재수에 삼수까지 할 정도로 이름있는 기업에 도전을 하시는 것 같더라고요. 이렇게 오랜 기간 도전하다보면 공백기가 생기는 건 당연한거예요. 여기서 차별점을 두려면 **이 공백기에 내가 왜 이런 선택을 했는지, 내가 생각하고 있는 방향성은 무엇인지**를 함께 얘기해주시면 도움이 될 것 같습니다. 이를 통해서 기업이 목표로 하는 것과 지원자의 방향성이 일치하는지 아닌지를 알아볼 수 있기 때문이죠.
 
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/4a6b3809-e258-45ff-a8ce-6050a8aab117/image.png)
 
### "나와 핏이 맞는 회사를 찾으세요"
채용하려는 회사마다 원하는 이력은 제각각이기 때문에, 모든 리뷰어의 입맛에 맞추는 것은 사실상 불가능합니다. 그렇기 때문에 **중요한 것은 나의 이력을 필요로 하는 회사를 찾는 것**입니다. 조급해할 필요 없이, 나와 핏이 맞는 회사를 찾는 데 집중해보세요.
 
많은 분들이 "가고 싶은 회사에 맞는 이력서를 어떻게 써야 할까?"라는 고민을 하시는데요. 사실 그 해답은 채용 공고에 명확히 나와 있는 경우가 많습니다. 스스로가 그 요건에 부합하는지 먼저 점검해보는 것이 중요하죠.
 
결국 **이력서를 어떻게 쓰느냐보다 중요한 건, 그 회사가 원하는 경험을 어떻게 쌓아가느냐**입니다. 현재 회사에서 그런 경험을 쌓기 어렵다면, 외부 모임이나 사이드 프로젝트를 통해 직접 기회를 만들어보는 것도 좋은 방법입니다. 그 프로젝트 안에서 어떤 역할을 했고, 어떻게 성장했는지, 그리고 그 경험이 지원하려는 회사에 어떤 기여로 연결될 수 있는지를 어필해 보세요.
 
### "이력서는 제한적일 수밖에 없습니다"
말씀해주신 것처럼, 이력서에는 어쩔 수 없이 제한된 정보를 담을 수 밖에 없어요. 심지어 2시간 분량의 과제 테스트조차 지원자의 모든 역량을 보여주기엔 부족하죠. 이 점은 지원자도, 면접관도 모두 인지하고 있는 부분입니다.
 
그럼에도 불구하고, 우리는 그 안에서 자신을 최대한 어필해야 합니다. 경력기술서도 중요하지만, GitHub에 잘 정리된 포트폴리오는 훨씬 더 효과적인 인상을 줄 수 있습니다. 그리고 그보다 **더 강력한 것은 바로 직접 배포한 앱이나 서비스 경험**입니다. 새로운 프로젝트를 시작해 보는 것도 좋은 방법이 될 수 있습니다.
 
### 약점보다는 강점을 부각하세요"
현재 재직 중인 업계와, 이직을 희망하는 업계가 달라 고민된다고 하셨는데요. 오히려 지금 몸담고 있는 업계에서의 경험이 차별화된 강점이 될 수 있습니다. 서비스 기업에만 있었던 분들이 겪기 힘든, 특정 업계만의 업무나 기술적 경험을 쌓아오셨을 가능성이 높기 때문이죠. 이러한 배경을 단순한 약점으로 보기보다, **내가 가진 강점으로 재해석해 어필**해 보세요. 분명 새로운 업계에서도 나만의 가치와 경쟁력으로 작용할 수 있을 것입니다.
 
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/3ffd4277-3975-462d-a8a0-750cc3a26d05/image.png)
 
### "이력서는 솔직하게 작성하는 것이 가장 중요합니다"
저는 이력서에서 형식보다 내용이 훨씬 중요하다고 생각합니다. 결국 지원자의 업무 경험이 충분한지 여부는 채용하는 회사의 기준에 따라 판단되는 것이기 때문에, **작성자는 자신이 직접 경험한 내용을 솔직하게 기록하는 것이 가장 중요**합니다.
 
때문에, "업무 경험이 부족한 것 같다"는 고민보다는, 해당 기업이 원하는 기술 스택과의 일치 여부를 점검해보는 것이 우선입니다. 대부분의 경우 경험이 부족한 게 아니라, 기술 스택이 맞지 않아서 발생하는 문제인 경우가 많습니다. 이 부분을 꼼꼼히 확인하고, 필요하다면 그에 맞게 내용을 보완해보시길 추천드립니다.
 
### "변화하는 모습을 이력서에 녹여내세요"
프로젝트를 진행하면서 팀 구성원이나 맡은 역할이 바뀌는 등, 시간이 지남에 따라 성장하고 변화했을 것이라고 생각합니다. **이런 변화의 흐름을 이력서에 자연스럽게 담아낸다면, 지원자의 성장 가능성과 역량을 더욱 잘 보여줄 수 있습니다**.
 
또한, 백엔드 개발자로 이직을 희망하신다고 하셨지만, 이력서에서는 그에 대한 동기나 향후 방향성이 명확하게 드러나지 않아 다소 아쉬웠습니다. 간단한 자기소개와 함께, 앞으로 어떤 개발자가 되고 싶은지, 어떤 방향으로 나아가고 싶은지를 서두에 명확하게 적어주시면 좋겠습니다.
 
아울러, 각 프로젝트에서 어떤 역할을 맡았고, 실무에서 어느 정도 기여를 했는지를 더 구체적으로 기술해주시면, 실제 업무 투입 시 어떤 역량을 발휘할 수 있을지 판단하는 데 큰 도움이 됩니다.
 
 
💡 **경력 백엔드 개발자들이 실제로 작성한 이력서**가 궁금하신가요? 아래 영상을 통해 직접 확인해 보세요! 위에 소개된 피드백 외에도 현직자들에게 바로 적용할 수 있는 실질적인 팁들이 가득 담겨 있습니다. 😉
 
<div style="position: relative; max-width: 100%; padding-bottom: 56.25%; height: 0;"><iframe width="560" height="315" src="https://www.youtube.com/embed/uTR7Bt1Ipqk?si=UhY55DQhyNWEx-lG" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen="" style="position: absolute; position: absolute; top: 0; left: 0; width: 100%; height: 100%;"></iframe></div>
 
 

[![coding_test-2 (1).jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/144d2151-0214-44aa-91b9-b45662a606c6/coding_test-2%20%281%29.jpg)](https://school.programmers.co.kr/learn/courses/25244?utm_source=prgmblog&utm_medium=social&utm_campaign=school_25244_blog&utm_content=25244_banner)

이력서 클리닉 2탄: 백엔드 개발자 경력 이력서 작성법 파헤치기!

지난 2월, 데브코스의 첫 심화 과정인 <백엔드 단기심화> 4기 수료식이 열렸습니다. 약 40명의 수강생과 함께 프로그래머스 오프라인 강의장에서 진행되었는데요. 최종 프로젝트 발표부터 수료생의 솔직한 인터뷰까지, 사진과 영상을 통해 뜨거웠던 현장을 만나보세요!
 
<div style="position: relative; max-width: 100%; padding-bottom: 56.25%; height: 0;"><iframe width="560" height="315" src="https://www.youtube.com/embed/qtK_8KIMO7c?si=iQSh_cAm4n2JWa6H" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen="" style="position: absolute; position: absolute; top: 0; left: 0; width: 100%; height: 100%;"></iframe></div>
 
 
 

 
## 백엔드 단기심화 4기 수료생 인터뷰 🎙️
### 🧑‍🎓 박찬희 수료생
![스크린샷 2026-04-06 오후 3.17.49.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/25043a94-b0a1-452f-9cb1-df8d0de161ca/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202026-04-06%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%203.17.49.png)
 
### **Q. 백엔드 단기심화 데브코스만의 강점이나 특별하다고 느낀 점은 무엇인가요?**
제가 느낀 가장 큰 강점은 **배운 기술을 바로 프로젝트에 적용해 볼 수 있는 실습 중심 구조**였습니다. 최소 기능 구현 조건과 같은 명확한 제약이 있었기 때문에 단순 기능 구현이 아니라, 실제 서비스에서 발생할 수 있는 문제와 설계를 고려하며 개발할 수 있었습니다. 또한 단기간에 집중적으로 프로젝트를 수행하는 방식이어서, 빠르게 적용하고 개선하는 사이클을 경험할 수 있었고 그만큼 성장의 밀도가 높았다고 느꼈습니다.
 
### **Q. 백엔드 단기심화의 온·오프라인 병행 학습의 장점은 무엇이라고 생각하시나요?**
온·오프라인 병행 구조의 가장 큰 장점은 **학습의 깊이와 실전 감각을 동시에 가져갈 수 있다는 점**이라고 생각합니다. 온라인에서는 개념을 스스로 정리하고 반복 학습하며 이해도를 높일 수 있었고, 오프라인에서는 프로젝트를 진행하며 팀원들과 빠르게 소통하고 즉각적인 피드백을 주고받을 수 있었습니다. 그 과정이 실제 업무 환경과 유사해 협업 능력과 문제 해결 속도를 함께 향상시킬 수 있었다고 느꼈습니다.
 
### 👩‍🎓 오세인 수료생
![스크린샷 2026-04-06 오후 3.21.40.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/418c6a1a-f545-43d4-8250-9300de654126/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202026-04-06%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%203.21.40.png)
 
### Q. 백엔드 단기심화 과정에 참여하게 된 가장 큰 계기는 무엇이었나요?
이전에 진행했던 프로젝트를 돌아보며 단순 기능 구현에만 집중했던 점이 아쉽게 느껴졌습니다. 결과물을 만들어내는 데에는 익숙해졌지만, 왜 이 기술을 선택했는지, 구조를 어떻게 설계했는지까지 깊이 고민해 본 경험은 부족했습니다. **Spring AI나 MSA처럼 한 단계 더 나아간 기술을 제대로 다뤄보고 싶었지만, 혼자서 구조를 설계하고 검증해 보는 데에는 한계**가 있다고 느꼈습니다. 
 
마침 프로젝트 중심으로, 대면 협업을 통해 실제로 부딪혀볼 수 있는 과정이 있다는 걸 알게 되었고, 이런 환경이라면 제가 부족하다고 느낀 부분을 채워볼 수 있겠다고 판단해 참여하게 되었습니다.
 
### Q. 프로젝트를 함께한 동료들과의 협업 경험은 어땠나요?
프로젝트를 진행하며 협업을 통해 크게 성장했다는 것을 느꼈습니다. MSA 구조로 도메인을 나누어 작업하다 보니 기능 구현을 넘어 이벤트 흐름과 책임을 어떻게 설계할지 계속 함께 고민하게 되었고, 자연스럽게 설계 중심의 대화를 많이 나누게 되었습니다. 특히 두 달 동안 대면으로 함께하고, 그 이전부터도 실시간으로 소통하며 작업하다 보니 단순한 프로젝트 팀이 아니라 **또래 동료들과 실제 회사에서 요구사항을 해결해 가는 듯한 경험**을 할 수 있었습니다.
 
이슈가 생기면 바로 공유하고 함께 해결하는 과정에서 이해의 깊이도 달라졌고, 코드 리뷰 역시 단순 오류 확인을 넘어서 이후의 확장성과 문제 가능성까지 고민해 보는 방향으로 발전했습니다. 경험이 많은 팀원들의 관점을 가까이에서 배우며 제 시야도 한층 넓어졌다고 생각합니다.
 
### 👩‍🎓 정원희 수료생
![스크린샷 2026-04-06 오후 3.18.54.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/54c7d96f-2b11-46e7-b1ff-871cf10185b1/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202026-04-06%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%203.18.54.png)
 
### Q. 멘토님들의 코드 리뷰와 피드백은 어떠했나요?
새로운 아키텍처로 프로젝트를 처음 진행하다 보니, 단순한 기능을 구현하는 과정에서도 구조적인 고민과 의문이 많이 생겼습니다. 멘**토링 시간이 약 90분 정도로 충분히 확보되어 있었기 때문에 궁금했던 부분을 깊이 있게 질문하고 방향성을 정리**할 수 있었던 점이 특히 좋았습니다.
 
저는 기능 구현 자체뿐 아니라, 실무에서는 유사한 상황을 어떻게 해결하는지, 그리고 향후 어떤 에러 상황이 발생할 수 있는지에 대해 질문을 많이 드렸는데요. 멘토님들께서 단순한 정답이 아니라 실무 경험을 기반으로 설명해 주셔서 문제를 더 넓은 관점에서 바라볼 수 있게 되었고, 실제 적용까지 수월하게 이어질 수 있었습니다.
 
### Q. 과정을 통해 가장 많이 성장했다고 느낀 부분은 무엇인가요?
경력자분들과 협업하며 **실제로 취업한 것처럼 프로젝트를 경험**해 볼 수 있었다는 점에서 큰 성장을 느꼈습니다. 단순한 학습용 프로젝트라기보다는 실무라고 생각하며 접근하려고 노력했습니다.
 
특히 기능 구현 자체에만 집중하기보다는, **실제 서비스에서 발생할 수 있는 예외 상황과 에러 케이스를 먼저 가정하고 이를 어떻게 방어하고 보완할지 고민**하는 데 더 많은 시간을 들였습니다. 그 과정에서 자연스럽게 개발의 관점을 넘어 서비스 운영의 관점으로 사고하게 되었고, 실무적인 문제 해결 역량이 한 단계 성장했다고 느낍니다.
 
### 🧑‍🎓 신동걸 수료생
![스크린샷 2026-04-06 오후 3.20.19.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/0f067f9b-7682-4640-8fd8-2c5a85789beb/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202026-04-06%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%203.20.19.png)
 
### Q. 9주간의 백엔드 단기심화 과정을 모두 마친 소감을 들려주세요.
9주라는 짧다면 짧은 기간 동안 정말 많은 것을 배운 것 같습니다. 수업 구성도 좋았고 강사님께서 열정적으로 가르쳐 주셔서 정말 많은 도움이 되었습니다. 무엇보다 이렇게 밀도 높은 팀 프로젝트를 경험하기 쉽지 않은데 좋은 경험이 된 것 같습니다.
 
### Q. 취업 준비에 있어 백엔드 단기심화 과정이 어떤 도움이 되었나요?
실무 중심의 프로젝트를 경험해 본 것이 가장 큰 메리트였다고 생각합니다. 기술 스택에 대해서도 이전에는 그냥 가져다 쓰는 경우가 많았는데, 백엔드 단기심화 과정을 통해 조금 더 깊이 있게 이해하고 설명할 수 있게 되었습니다. 커뮤니케이션 방법, 협업 방식 등에 대해서도 큰 도움이 되었습니다.
 
### 🧑‍🎓 박태영 수료생
![스크린샷 2026-04-06 오후 3.23.46.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/db0e641e-3344-4d83-9d16-7a8530da11dd/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202026-04-06%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%203.23.46.png)
 
### Q. 수강 전과 비교했을 때, 지금 가장 달라졌다고 느끼는 점은 무엇인가요?
2개월 동안 매일 9시부터 18시까지 프로젝트에 몰입하면서, 무엇보다 팀 협업 능력과 설계 능력을 키울 수 있었던 게 가장 큰 변화입니다. 전에는 이론으로만 알던 기술들을 직접 적용해 보니 **'왜 이 기술을 써야 하는지' 고민하는 설계의 중요성을 확실히 체감**하게 됐습니다.
 
특히 막히는 순간마다 강사님과 멘토님의 빠른 피드백 덕분에 시행착오를 줄이고 최선책을 찾아가는 법을 배울 수 있었어요. 이제는 기술적 근거를 가지고 동료들과 소통하며 문제를 해결해 나갈 수 있다는 자신감이 생겼습니다.
 
### Q. 어떤 분들께 이 과정을 추천하고 싶으신가요?
기본적인 기술은 익혔지만, **팀 단위의 밀도 높은 협업 경험**을 원하는 분들께 꼭 추천하고 싶습니다. 단순히 기능을 구현하는 것을 넘어 깊은 기술적 고민을 동료들과 나누며, 한 단계 더 성장하고 싶은 분들에게 최적의 과정인 것 같습니다.
 
무엇보다 하루 9시간 이상 프로젝트에만 온전히 쏟아부을 만큼 열정적으로 몰입할 준비가 된 분들이라면 이곳에서 기대 이상의 성장을 경험하실 수 있을 겁니다.
 
 
 
## 백엔드 단기심화 데브코스 4기 수료식 현장스케치 🎬
![스크린샷 2026-04-06 오후 3.14.44.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/5497033e-bae3-48d2-ae3e-e14d3688cfab/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202026-04-06%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%203.14.44.png)

![스크린샷 2026-04-06 오후 3.15.31.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/4afb85ea-4eaa-4a06-963b-428e5c392d69/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202026-04-06%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%203.15.31.png)

![스크린샷 2026-04-06 오후 3.15.27.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/300d3e0a-bdd4-4da7-b53e-1e59c0675a49/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202026-04-06%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%203.15.27.png)

![스크린샷 2026-04-06 오후 3.15.47.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/d1bf6133-78c6-4a3d-b30e-8f25b51c8de9/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202026-04-06%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%203.15.47.png)

![스크린샷 2026-04-06 오후 3.16.12.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/ccfce5e6-39c1-4c87-8683-f053224e5624/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202026-04-06%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%203.16.12.png)

![스크린샷 2026-04-06 오후 3.24.30.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/bf008a7b-06c5-4bc6-b7a7-4e312277a4fa/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202026-04-06%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%203.24.30.png)

![스크린샷 2026-04-06 오후 3.24.47.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/d958fe7f-7b95-485b-b708-3cd98f7d8812/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202026-04-06%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%203.24.47.png)
 
 
[![DEV-BE-DEEP-coding-test-02(1456x180).jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/fbf81688-98b4-4bc1-908d-047519dea8c0/DEV-BE-DEEP-coding-test-02%281456x180%29.jpg)](https://school.programmers.co.kr/learn/courses/25629/25629-5%EA%B8%B0-k-digital-training-%EC%8B%AC%ED%99%94-spring-ai%EC%99%80-msa%EB%A5%BC-%ED%99%9C%EC%9A%A9%ED%95%9C-%EB%B0%B1%EC%97%94%EB%93%9C-%EA%B0%9C%EB%B0%9C)

[데브코스 수료식] 백엔드 단기심화 4기 수료식 현장스케치 & 생생한 수료생 인터뷰까지!

GitHub에 새 프로젝트 폴더를 또 만들었지만, 지난 프로젝트를 보면 README만 덩그러니... 몇 달째 멈춘 프로젝트도 많습니다. 왜 우리는 사이드 프로젝트를 끝내지 못할까요? 풀스택 개발자 고코더님이 전하는, 사이드 프로젝트를 끝까지 완성하는 현실적인 방법과 꿀팁을 지금 확인해보세요.
 
 
## GitHub에 쌓인 미완성의 무덤
![스크린샷 2025-11-26 오후 12.02.42.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/ef21877a-7169-4c69-bfb7-13b0c3700a7d/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202025-11-26%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%2012.02.42.png)
 
GitHub에 접속했습니다. 'Personal Projects' 폴더에는 10개의 저장소가 있습니다. README.md만 작성된 프로젝트 5개, 마지막 커밋이 6개월 전인 프로젝트 4개, 실제로 배포된 프로젝트는 단 한 개도 없습니다.
 
"이번엔 다를 거야."
새로운 프로젝트 폴더를 또 만들면서 다짐합니다. 과연 이번에는 다를까요? 많은 개발자들이 같은 경험을 합니다. 열정적으로 시작했던 프로젝트들이 어느새 디지털 무덤에 쌓여갑니다. Medium의 "Career Programming" 채널에 글을 쓰는 Dr. Derek Austin은, 자신이 검토해온 수많은 개발자 이력서를 바탕으로 "코더의 약 90%가 사이드 프로젝트를 끝내지 못한다"라고 주장하기도 합니다.
 
왜 우리는 시작은 잘하는데 끝은 못 낼까요? 오늘은 사이드 프로젝트를 완성하지 못하는 진짜 이유와 실제로 끝낼 수 있는 현실적인 방법들을 이야기해 보려 합니다.
 
 
## 우리를 막는 다섯 가지 함정
![스크린샷 2025-11-26 오후 12.03.09.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/447a288e-390c-41a0-936f-f4a91221beb7/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202025-11-26%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%2012.03.09.png)
 
### 함정 1: 완벽주의의 저주
개발자 K씨는 간단한 날씨 앱을 만들기 시작했습니다. 기본 기능은 단 3일 만에 완성했습니다. 현재 위치의 날씨를 보여주고, 5일 예보를 확인할 수 있는 앱이었습니다. 충분히 사용 가능한 상태였습니다. 하지만 K씨는 "배포하기 전에 코드를 좀 더 깔끔하게 정리해야지"라고 생각했습니다.
 
리팩토링을 시작한 지 2주가 지났습니다. 코드를 정리하다 보니 "디자인 패턴을 적용하면 더 좋겠어"라는 생각이 들었습니다. 전면 수정에 들어갔습니다. 그러다 "상태 관리 라이브러리를 도입하면 더 깔끔한 텐데"라는 생각이 또 들었습니다. 그리고 프로젝트는 멈췄습니다. 완성된 80%의 코드는 완벽한 20%를 기다리며 GitHub 저장소에서 잠들었습니다.
 
완벽주의는 개발자의 직업병입니다. 우리는 매일 버그 없는 코드를 작성하려 노력합니다. 더 나은 알고리즘, 더 효율적인 구조를 고민합니다. 하지만 사이드 프로젝트에서 이 완벽주의는 독이 됩니다. "완벽하지 않으면 남들에게 보여줄 수 없다"라는 두려움이 우리를 마비시킵니다.
 
 
### 함정 2: 과도한 야망
개발자 M씨의 'Todo 앱' 기획서를 봅시다. 사용자 인증은 Google, Facebook, GitHub, Apple, 카카오 총 5종의 소셜 로그인을 지원합니다. 실시간 동기화 기능으로 여러 기기에서 동시에 사용 가능합니다. 팀원을 초대해서 협업할 수 있고, AI 기반 우선순위 추천 시스템도 있습니다. 음성 인식으로 할 일을 등록할 수 있고, 다크 모드와 7개 국어를 지원합니다.
 
현재 진행 상황은? 로그인 화면 디자인만 3주째 작업 중입니다. 소셜 로그인 중 어떤 것을 먼저 구현할지 고민하다가 결국 아무것도 하지 못했습니다. M씨의 기획서에 있는 기능 하나하나가 독립된 프로젝트급 난이도였습니다.
 
우리는 처음 아이디어가 떠올랐을 때 흥분합니다. 상상 속에서 프로젝트는 이미 완성되어 있고, 수많은 사용자들이 찬사를 보냅니다. 그 순간의 높은 동기부여 상태에서 우리는 현실성 없는 계획을 세웁니다. "간단한 프로젝트는 포트폴리오가 안 된다"라는 착각이 이를 부추깁니다.
 
 
### 함정 3: 끝없는 기술 스택 실험
프로젝트 시작 1주 차, React로 개발을 시작했습니다. 
2주 차, "Vue 3가 더 간단하다"라는 글을 읽고 Vue로 마이그레이션을 시작합니다. 
3주 차, "Svelte가 더 빠르다"라는 소식에 또다시 고민에 빠집니다. 4주 차, 기술 스택 비교 글만 100개를 읽습니다. 
5주 차, 프로젝트는 그대로인데 열정만 소진되었습니다.
 
기술 선택의 마비 상태에 빠진 것입니다. "최신 기술을 써야 취업에 유리하다"라는 압박감이 우리를 흔듭니다. 학습 목적인지 완성 목적인지 혼란스러워집니다. 결국 어떤 기술도 제대로 배우지 못하고, 프로젝트도 완성하지 못합니다.
 
 
### 함정 4: 외로운 마라톤
첫 주는 흥분 상태입니다. "이거 대박 날 것 같아!"
매일 밤 2시간씩 코딩합니다.
 
둘째 주, 현실과 마주합니다. "생각보다 복잡하네."
버그가 예상보다 많이 나옵니다.
 
셋째 주부터 지칩니다. "언제 끝나지?"
진도가 더디게 나갑니다.
 
한 달이 지나면 프로젝트는 방치됩니다. "내일부터 다시 시작해야지"라는 말만 반복합니다.
 
사이드 프로젝트는 외로운 마라톤입니다. 회사 프로젝트와 달리 함께 달릴 팀원도, 응원해 줄 동료도 없습니다. 피드백이 없으니 동기부여가 점점 떨어집니다. 막히는 부분이 생기면 며칠째 같은 자리에 멈춰있기도 합니다. 퇴근 후 피곤한 몸으로 개인 프로젝트까지 하기는 쉽지 않습니다.
 
 
### 함정 5: 새로운 시작의 유혹
프로젝트 A를 30% 진행하던 중, 더 좋은 아이디어 B가 떠올랐습니다.
"이건 더 재미있을 것 같아!", B를 시작합니다.
B를 40% 진행하던 중, 또 다른 아이디어 C가 생겼습니다.
"이번엔 정말 차별화된 서비스야!", C를 시작합니다.
이렇게 완성된 프로젝트는 0개, 미완성 프로젝트만 늘어갑니다.
 
새로운 시작은 항상 매력적입니다. 깨끗한 코드베이스, 새로운 가능성, 실수를 되풀이하지 않겠다는 다짐까지.
반면 진행 중인 프로젝트는 버그와 기술적 부채로 점철되어 있습니다.
"이 프로젝트는 이미 비슷한 게 많아. 차별화가 안 돼"라고 합리화하며 새 프로젝트를 시작합니다.
 
 
## 끝내는 사람들의 비밀
![7416558_4795.jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/66788de9-edb7-4cfc-8eb1-66ebbf0eb519/7416558_4795.jpg)
그렇다면 실제로 사이드 프로젝트를 완성하는 사람들은 뭐가 다를까요? 그들만의 비밀을 알아봅시다.
 
### 전략 1: MVP로 시작하고 v0.1로 끝내기
성공적인 사이드 프로젝트의 첫 번째 원칙은 작게 시작하는 것입니다. MVP(Minimum Viable Product), 즉 최소 기능 제품으로 접근해야 합니다.
 
Todo 앱을 만든다면, 할 일 추가, 삭제, 완료 표시, 이 세 가지만 구현하면 됩니다.
날씨 앱이라면 현재 위치의 오늘 날씨만 보여주면 됩니다.
소셜 로그인, 프로필 사진, 알림 기능 같은 것들은 모두 "나중에"로 미룹니다.
 
핵심은 단시간 안에 배포 가능한 버전을 만드는 것입니다. 주말 이틀을 온전히 투자하면 완성할 수 있는 규모로 시작합니다. 실제로 사용 가능한 상태로 먼저 만들고, 추가 기능은 정말로 나중에 붙입니다.
 
처음부터 복잡하게 접근하지 맙시다. Google, Facebook, GitHub 소셜 로그인을 다 넣으려 하지 말고, 이메일과 비밀번호만으로 시작합니다. 이것만으로도 1시간이면 충분합니다. 나머지는 v0.2에서 추가하면 됩니다.
 
 
### 전략 2: 완성의 기준을 미리 정하기
프로젝트를 시작하기 전에 완성 조건을 명확히 정의해야 합니다. 다음과 같은 문서를 작성해 봅시다.
 
#### 이 프로젝트의 완성 조건
필수 기능 (이것만 있으면 완성):
* 사용자가 할 일을 추가할 수 있다
* 할 일을 완료 처리할 수 있다
* 할 일 목록을 볼 수 있다
 

완성 기준:
* 위 3가지가 동작하면 1.0 버전으로 배포
* 디자인은 기본 CSS만 사용
* 테스트 코드는 나중에 추가
* 배포는 Vercel 무료 플랜 사용
 

완성 전까지 금지:
* 새로운 기능 추가 금지
* 기술 스택 변경 금지
* 대규모 리팩토링 금지

 
이렇게 명확한 기준을 세우면 언제 끝났는지 알 수 있습니다.
"조금만 더"라는 유혹에 빠지지 않게 됩니다.
완성의 기준선이 없으면 프로젝트는 영원히 끝나지 않습니다.
 
 
### 전략 3: 떠벌림 효과(Profess Effect)
떠벌림 효과는 자신이 달성하고자 하는 목표를 알림으로써 주위 사람들의 지원을 얻는 방법입니다.
 
온라인 커뮤니티 혹은 LinkedIn에 선언합니다. "앞으로 2주간 간단한 Todo 앱을 만들어서 12월 1일에 배포하겠습니다!"
매일 30분씩 작업하고 진행 상황을 공유합니다. "오늘은 로그인 기능 구현 완료!" 같은 작은 성취를 인증합니다.
 
친구나 동료에게 떠벌리는 것도 좋습니다. 같은 기간 동안 각자 프로젝트를 진행하고, 매주 진행 상황을 공유하며 피드백을 주고받습니다. 혼자서는 포기하기 쉽지만, 다른 사람의 응원과 관심이 있으면 끝까지 달릴 수 있습니다.
 
"포기하면 창피해"라는 긍정적인 압박이 생깁니다. 이것이 떠벌림 효과입니다.
 
 
### 전략 4: 시간 압박으로 집중력 극대화
명확한 데드라인은 집중력을 높입니다. 주말 48시간 해커톤 방식으로 접근해 봅시다.
 
* 금요일 저녁 2시간: 프로젝트 초기 설정과 기본 구조를 잡습니다.
* 토요일 8시간: 오전에는 백엔드 로직을 구현하고, 오후에는 프론트엔드 UI를 만듭니다.
* 일요일 8시간: 오전에는 버그를 수정하고 마무리 작업을 합니다. 오후에는 배포하고 README를 작성합니다. 저녁에는 실제로 사용해 보고 소감을 기록합니다.


 
제한된 시간에는 완벽함을 추구할 수 없습니다. 자연스럽게 완성에 집중하게 됩니다. 주말 동안 몰입하면 맥락 전환도 최소화됩니다. 월요일 회사에 가기 전에 배포까지 마치는 것, 충분히 가능합니다.
 
 
### 전략 5: 동작하는 코드를 먼저
마인드셋을 바꿔야 합니다. 완벽한 코드가 아니라 동작하는 코드를 먼저 만듭시다.
 
"이 코드는 나중에 부끄러울 것 같아"라는 생각을 버립시다.
"클린 코드 원칙을 다 지켜야 해"라는 강박도 내려놓읍시다.
"일단 동작하게 만들자"로 전환합니다. 완성 후 리팩토링은 v2에서 하면 됩니다. 작동하는 더러운 코드가 완벽한 미완성 코드보다 낫습니다.
 
변수명이 완벽하지 않아도 괜찮습니다. 중복 코드가 좀 있어도 괜찮습니다. 나중에 리팩토링하면 됩니다. 에러 처리가 부족해도 괜찮습니다. 기본적인 것만 있으면 됩니다. 주석이 없어도 괜찮습니다. 코드 자체로 이해 가능하면 충분합니다.
 
"Done is better than perfect." 이 말을 기억합시다.
 
 
## 완성이 주는 진짜 가치
완성된 프로젝트 한 개가 미완성 프로젝트 열 개보다 낫습니다. 왜 그럴까요?
 
첫째, **완성 경험 자체가 자산**이 됩니다. 한 번 끝까지 해본 사람은 다음 프로젝트를 더 쉽게 완성합니다. "나도 끝낼 수 있다"라는 자신감이 생깁니다. 배포와 운영 경험도 얻습니다. 이런 것들은 아무리 좋은 강의를 들어도 얻을 수 없는 경험입니다.
 
둘째, **포트폴리오 가치**가 다릅니다. 면접관이 보는 것은 단순히 기술 스택이 아닙니다. 문제 해결 능력, 프로젝트 완수 능력, 실제 서비스 경험을 봅니다. 미완성 프로젝트 10개는 "시작은 잘하지만 끝을 못 내는 사람"이라는 인상을 줍니다. 완성된 프로젝트 1개는 "끝까지 해내는 사람"이라는 신뢰를 줍니다.
 
셋째, **실제 사용자 피드백**을 받을 수 있습니다. 내가 만든 코드를 다른 사람이 실제로 사용합니다. 예상치 못한 버그를 발견하고, 개선 방향에 대한 인사이트를 얻습니다. 이런 경험은 성장의 촉매제가 됩니다.
 
넷째, 완성의 경험은 **다음 프로젝트의 설계도**가 됩니다. 어디서 시간을 낭비했는지, 어떤 기능이 정말 필요했는지, 어떤 기술 선택이 옳았는지 알게 됩니다. 이런 배움은 코드가 아닌 판단력으로 축적됩니다. 다음 프로젝트는 더 빠르고, 더 현명하게 완성할 수 있게 됩니다.
 
주변 개발자들의 이야기를 들어보면 흥미로운 패턴이 있습니다. 첫 프로젝트를 완성한 사람들은 대부분 "생각보다 반응이 좋았다"라고 말합니다.
완벽하지 않은 것에 대한 걱정과 달리, 사용자들은 오히려 "간단해서 좋다", "딱 필요한 기능만 있어서 좋다"라는 피드백을 줍니다.
 
더 놀라운 것은 완성 이후의 변화입니다. 한 번 끝까지 해본 개발자는 다음 프로젝트도 완성합니다. 완성의 경험이 완성을 낳는 선순환이 시작됩니다.
 
 
## 11번째 저장소에 거는 희망
![스크린샷 2025-11-26 오후 12.03.25.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/d6a35a7d-7fc8-4e55-9107-9f8a5ca6aa3b/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202025-11-26%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%2012.03.25.png)
 
다음 사이드 프로젝트를 시작하기 전에 이것들을 기억합시다.
 
완성 조건을 먼저 정의합니다. 2주 이상 걸릴 것 같으면 규모를 줄입니다.
공개 약속을 합니다. 완벽함보다 완성을 택합니다. 완성하면 꼭 배포합니다.
 
완벽한 프로젝트는 없습니다. 완성된 프로젝트만 있습니다.
80% 완성도의 배포가 100% 완성도의 미완성보다 낫습니다.
첫 프로젝트는 작게, 완성은 확실히 합시다.
 
GitHub의 11번째 저장소가 처음으로 'v1.0 Released' 태그를 달 수 있기를, 그리고 그것이 여러분의 포트폴리오에 자랑스러운 한 줄로 남을 수 있기를 진심으로 응원합니다.
 
시작도 용기지만, 완성은 더 큰 용기입니다.
이번 주말, 작은 프로젝트 하나를 끝까지 완성해 보는 건 어떨까요?
 
 
### 📚 참고 문헌
* [90% of Coders Never Finish Side Projects. Here’s How To Be the 10%](https://medium.com/career-programming/90-of-coders-never-finish-side-projects-heres-how-to-be-the-10-745f62c5ce97)
 

### 📌 함께 읽으면 좋은 글
* [개발자의 실수 노트: 실패에서 배우는 기술](https://community.programmers.co.kr/post/12838?utm_source=&utm_medium=&utm_campaign=&utm_content=gocoder_12838)
* [개발자의 인간관계: 코드보다 어려운 인간관계](https://community.programmers.co.kr/post/12607?utm_source=&utm_medium=&utm_campaign=&utm_content=gocoder_25oct)
* [개발자의 번아웃, 조용히 찾아오는 위험 신호들](https://community.programmers.co.kr/post/12542?utm_source=&utm_medium=&utm_campaign=&utm_content=gocoder_25aug)
 
 

![고코더 작가님 프로필 카드.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/0fda2445-0f60-47d2-8a17-024015c411c8/%E1%84%80%E1%85%A9%E1%84%8F%E1%85%A9%E1%84%83%E1%85%A5%20%E1%84%8C%E1%85%A1%E1%86%A8%E1%84%80%E1%85%A1%E1%84%82%E1%85%B5%E1%86%B7%20%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%84%91%E1%85%B5%E1%86%AF%20%E1%84%8F%E1%85%A1%E1%84%83%E1%85%B3.png)

사이드 프로젝트, 시작은 했는데 끝이 안 나는 이유

프로그래머스 프론트엔드 데브코스 3기를 수료한 배채연 님의 인터뷰입니다. 채연 님은 단순히 기술을 배우는데 그치지 않고 스스로 고민하고 반복하며 진짜 실력을 쌓아나갔다고 하는데요. 협업 프로젝트에서 PO 역할을 맡아 팀을 이끌고, 개발자로서 한 단계 더 성장할 수 있었던 채연 님의 여정이 궁금하시다면, 아래 인터뷰를 확인해보세요!
 
 
# 안녕하세요. 자기 소개 부탁드립니다.
안녕하세요! 저는 프로그래머스 프론트엔드 데브코스 3기를 수료한 주니어 프론트엔드 개발자 배채연입니다. 사용자에게 더 나은 경험을 제공하는 화면을 만드는 데 큰 매력을 느껴 프론트엔드 개발을 시작하게 되었고, 현재는 수료 이후 취업을 준비하고 있습니다.

![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/393b42b4-ded7-4616-bce5-475430b929d1/image.png)
# 프로그래머스 데브코스는 어떻게 알게 되셨나요?
부트캠프를 통해 체계적으로 프론트엔드 기술을 배우고 싶다는 생각이 들어, 구글에 '프론트엔드 부트캠프'를 검색하던 중 프로그래머스 데브코스를 처음 알게 되었습니다.
 
수강생 후기들을 보면서 **실무 중심의 커리큘럼과 꼼꼼한 코드 리뷰, 협업 기반의 프로젝트가 인상 깊었고, 이곳이라면 제대로 배울 수 있겠다는 확신**이 들어 지원하게 되었습니다.
 
# 타사도 있지만 프로그래머스를 선택하신 이유가 있을까요?
비슷한 교육 과정들도 많이 찾아봤지만, 프로그래머스를 선택한 가장 큰 이유는 **코딩 교육 분야에서의 높은 인지도와 신뢰도**였습니다. 특히 PCCP(프로그래머스 코딩 역량 인증 시험)와 코딩 테스트 등 **자체적인 평가 시스템이 잘 마련되어 있어 학습 후 실력을 객관적으로 점검할 수 있다는 점**이 신뢰를 주었습니다.
 
또한 **마지막 프로젝트를 백엔드 개발자 분들과 협업해 실무처럼 진행한다는 점**도 인상 깊었습니다. 단순히 기술을 배우는 데 그치지 않고, 실무에 필요한 협업 역량까지 함께 키울 수 있다는 확신이 들어 프로그래머스를 선택하게 되었습니다.
 
# 약 6개월동안 데브코스에 참여해주셨는데요. 어떤 것이 가장 기억에 남나요?
가장 기억에 남는 순간은 **매일 아침 팀원들과 함께 했던 스크럼 시간**이었습니다.
 
바로 수업이나 코딩을 시작하기 전에 서로의 컨디션을 체크하고, 어제 학습한 내용과 오늘의 계획을 공유하는 이 시간이 자연스럽게 아이스브레이킹이 되었던 것 같아요.
 
이 시간을 통해 **팀원들과 유대감도 쌓을 수 있었고, 하루의 방향을 정리하면서 더 집중력 있게 학습을 시작**할 수 있었던 점이 특히 인상 깊게 남아 있습니다.
 
# 데브코스를 하면서 성장했다고 느꼈던 계기가 있다면 말씀해주세요.
데브코스를 처음 시작했을 땐 저보다 지식도 많고 실력 있는 분들이 많아 보여서, 제가 팀장을 맡게 될 일은 없을 거라고 생각했어요. 그런데 마지막 백엔드와의 협업 프로젝트에서는 프론트엔드 팀장을 넘어 **프로젝트 오너(PO) 역할을 맡게 되었고, 전체 프로젝트를 조율하며 팀원들과 끝까지 함께 달려 기한 내에 완성**해낼 수 있었습니다.
 
물론 부담이 컸지만 그만큼 책임감도 생겼고, 마지막 프로젝트가 끝난 뒤에는 데브코스에 처음 데브코스에 참여했을 때의 제 모습과 비교해 정말 많이 성장했다는 것을 크게 느낄 수 있었습니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/fe3edafd-a6e5-4cf4-9a03-359c9e9a5373/image.png)
👆 최종 프로젝트에서 PO를 맡은 채연 님과 함께 했던 팀원들

 
# 최종 프로젝트에 대해 소개해주세요.
저희 팀은 'Planit(플랜잇)'이라는 **여행 통합 플랫폼**을 만들었습니다. 여행 일정을 날짜별로 정리하고, 위치 기반 지도를 통해 동선을 설계하며, 원하는 숙소를 확인하고 예약까지 할 수 있는 서비스입니다. 또한 챗봇 기능을 통해 여행 관련 정보를 쉽게 얻을 수 있고, 시각적으로 일정을 구성해 완벽한 여행을 준비할 수 있도록 돕는 것이 목표였습니다.
 
이 프로젝트에서 특히 좋았던 점은 팀원 모두가 서로의 의견을 존중하고, 항상 부드러운 말투로 소통해 주셨다는 점이에요! 덕분에 갈등 없이 끝까지 협력할 수 있었고, **긍정적인 팀워크를 경험**할 수 있었어요.
 
다만 아쉬웠던 점도 있었는데요. 협업이 처음인 팀원들이 많아 한 기능을 구현할 때 어디까지 논의하고 정리해야 하는지에 대한 경험이 부족했습니다. 그래서 개발을 시작했다가 다시 의견을 나누고, 그에 따라 코드를 수정하는 과정을 반복하면서 일정이 조금씩 지연되기도 했습니다.
 
하지만 이 경험을 통해 **사소한 부분이라도 명확히 소통하고, 논의한 내용은 문서화하여 정리하는 습관**을 들일 수 있었던 점은 큰 배움이고 경험이었던 것 같아요.
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/d6e8c6cf-aed3-49fb-8e04-02ad2e77c4ae/image.png)
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/925d3017-034e-4710-825b-7c99087a1427/image.png)
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/a7e26f8f-3f6e-4a48-aa40-11551b210f22/image.png)
 
👆 채연 님의 최종 프로젝트 발표 자료 중 발췌
 
# 데브코스를 통해 이루고자 했던 목표가 있었나요? 어느 정도 이뤘다고 생각하세요?
부트캠프를 시작하기 전에 약 1년 정도 개발을 쉬고 있었고, 이전에 프론트엔드 웹 개발을 겉핥기 식으로만 배웠던 터라, 이번 기회에 **기초부터 다시 제대로 배우고 싶다는 목표**가 있었습니다. 또한 실무에서 많이 사용되는 최신 프레임워크나 라이브러리들을 자유롭게 다룰 수 있는 개발자가 되고 싶다는 목표도 있었어요.
 
목표를 10이라고 본다면 지금은 7까지는 도달했다고 생각합니다. 그 과정에서 가장 크게 느낀 점은, 단순히 수업을 듣고 프로젝트를 수행한다고 해서 실력이 저절로 늘지는 않는다는 것이었습니다. **진짜 실력은 결국 스스로 고민하고, 반복해서 도전하는 과정 속에서 쌓인다는 것**을 몸으로 느낄 수 있었습니다.
 
# 수업을 진행해주신 강사님은 어떠셨나요?
약 6개월 동안 함께했던 이해성 강사님은 지금까지도 기억에 많이 남아있는데요. 프론트엔드 강사님이셨지만 백엔드까지 아우르는 폭넓은 지식과 실력을 갖추신 모습을 보며, **저도 언젠가는 풀스택 개발자가 되고 싶다는 동기부여**를 많이 받았어요.
 
늘 웃는 모습으로 학생들을 대해주셨지만 때로는 따끔한 피드백도 아끼지 않으셨는데요. '당근과 채찍'을 적절히 주시는 덕분에 저도 프로젝트에 더 몰입할 수 있었습니다.
 
또한 프로젝트 발표를 총 4번 중 3번을 맡아 진행했는데, 그때마다 발표를 잘했다고 칭찬해주셨던 것이 특히 기억에 남습니다. 그 말 한마디가 큰 자신감이 되었고, 지금도 소중한 기억으로 남아 있습니다.
 
# 운영 매니저와 함께한 6개월은 어떠셨나요?
프론트엔드 3기 4회차의 운영을 맡아주신 페이지 매니저님이 기억에 많이 남습니다. 처음에는 조금 무서운(?) 느낌도 있어서 줌에 함께 있으면 말을 쉽게 꺼내지 못하곤 했는데요. 제가 수업에 조금 늦거나 하면 '무슨 일 있으신가요?'하고 먼저 챙겨주시고, 궁금한 점이 생겨 질문하면 늦은 시간에도 빠르게 답변을 주셔서 정말 감동이었어요.
 
어느 순간부터는 '**장난기 넘치지만 일은 정말 정확하게 하시는 매니저님!**'이라 느꼈고, 많은 학생들을 통솔하고 챙기시는 모습이 정말 대단하게 느껴졌습니다. 페이지 매니저님 외에 다른 운영 매니저님들도 모두 친절하게 도와주셔서, **6개월 동안 불편함이나 불만없이 과정에 집중**할 수 있었던 것 같아요.
 
# 함께 스터디한 동료는 어땠나요? 수료 후에도 소통하고 있으신가요?
총 4번의 프로젝트를 진행하며 다양한 팀원들과 함께했는데, 매번 분위기가 정말 좋았어요. 덕분에 스트레스를 받거나 불편함 없이 프로젝트에 몰입할 수 있었고, **협업에 대한 긍정적인 인상**을 많이 남길 수 있었어요.
 
최종 프로젝트 당시 사용하던 디스코드 방과 프론트엔드-백엔드 공동 디스코드 방도 여전히 접속해 있습니다. 요즘은 자격증 공부와 취업 준비로 바쁘다 보니 자주 소통하진 않지만, **궁금한 점이 생기거나 공유할 이야기가 있을 땐 언제든지 편하게 이야기할 수 있는 커뮤니티**로 남아 있습니다.
 
# 전반적인 멘토링 경험은 어땠는지 말씀해주세요.
데브코스 기간 동안 두 분의 멘토님께 멘토링을 받았는데, 두 분 모두 밝고 친절하셔서 정말 인상 깊었습니다. 사실 이전에는 '개발자는 조금 시니컬할 것 같다'는 편견이 있었는데, 멘토님들을 만나면서 그런 고정관념이 완전히 사라졌어요.
 
멘토링 시간에는 기술적인 질문은 물론이고, **실무 환경에 대한 이야기나 제가 가지고 있던 고민, 최신 기술 트렌드까지 폭넓게 이야기**할 수 있었고, 매번 많은 도움을 받을 수 있었습니다.
 
특히, **"지금 내가 어떤 방향으로 공부해야 하는지"에 대해 구체적인 지표**를 세울 수 있었던 점이 가장 좋았고, 덕분에 막연했던 불안감도 많이 줄일 수 있었습니다.
 
# 데브코스 수강을 고민하고 있는 분들에게 추천한다면?
프로그래머스 데브코스는 '**직접 해보며 배우는 과정**'이라는 말이 딱 어울리는 부트캠프였습니다.
 
총 4번의 프로젝트를 통해 다양한 주제를 다루며 경험을 쌓을 수 있었고, 특히 마지막에는 **실제 백엔드 개발자분들과 협업 프로젝트를 진행하면서 실무에 가까운 협업을 경험**할 수 있었어요.
 
또 프로그래머스 **코딩 테스트가 있어서 학습을 진행하면서 제 실력을 점검**해보기에도 좋았어요. 무엇보다 운영 매니저님, 강사님, 멘토님 모두 수강생 한 명 한 명을 진심으로 챙겨주시고, 고민을 내 일처럼 함께 해결해주려는 **따뜻한 분위기가 데브코스의 큰 장점**으로 느껴졌습니다.
 
프론트엔드 개발을 진지하게 배우고 싶은 분이라면, 데브코스를 통해 실력은 물론 자신감과 협업 경험까지 모두 얻을 수 있을 거라고 생각합니다!
 
# 앞으로 어떤 개발자로 성장하고 싶으신가요?
제 성격을 살려 **협업에 강한 개발자**가 되고 싶습니다. 친화력 있고 따뜻한 성격 덕분에 팀 프로젝트에서도 소통에 힘이 되었던 경험이 많았고, 앞으로도 팀 안에서 꼭 필요한 존재가 되고 싶어요.
 
또 빠르게 변화하는 프론트엔드 생태계 속에서 현실에 안주하지 않고, 꾸준히 공부하고 도전하며 성장해나가는 개발자가 되고자 합니다. **기술뿐만 아니라 업무에 임하는 태도에서도 신뢰받을 수 있는 개발자**로 성장하고 싶습니다.
 
# 마지막으로 후배 수강생들을 위한 응원의 한 마디, 부탁드립니다.
개발자가 된다는 건 정말 쉽지 않은 길이라고 생각해요. 데브코스든 다른 어떤 부트캠프든, 그 과정이 줄 수 있는 건 흙과 물, 햇볕 같은 환경일 뿐이에요. 그 안에서 **씨앗인 내가 꽃을 피울 수 있을지는 결국 나 자신의 노력에 달려 있다고 느꼈습니다**. 좋은 결과를 얻기 위해선 주도적인 자세가 무엇보다도 중요한 것 같아요.
 
이미 이 길을 선택하셨다면, 끝까지 최선을 다해 꽃을 피워보세요. 언젠가 어딘가에서 '데브코스를 수료한 동료 개발자'로 만나 뵐 수 있으면 좋겠습니다. 진심으로 응원합니다!
 
 
*강의 운영 사정에 따라 세부 프로그램 내용은 변경될 수 있습니다.*
 
 
[![FE_배너.jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/0b788977-b1a0-4cff-a6c9-449c8ca260d3/FE_%E1%84%87%E1%85%A2%E1%84%82%E1%85%A5.jpg)](https://school.programmers.co.kr/learn/courses/25243?utm_source=prgmblog&utm_medium=social&utm_campaign=school_25243_blog&utm_content=25243_banner)

스스로 고민하고 반복해서 도전하며, 진짜 실력을 쌓았어요 - 프론트엔드 3기 수료생 배채연 님

백엔드 데브코스 3기 수료생 김누리 님의 인터뷰입니다. 누리 님은 SM 업무를 하던 중 새로운 길을 찾고자 백엔드 데브코스에 참여해주셨는데요. 6개월간의 여정을 통해 기술 역량뿐만 아니라 협업과 문제 해결 능력까지 성장할 수 있었다는 누리 님의 이야기, 지금 바로 만나보세요!
 

<div style="position: relative; max-width: 100%; padding-bottom: 56.25%; height: 0;"><iframe width="560" height="315" src="https://www.youtube.com/embed/cB1FkeaHwU8?si=X5a4etxuwzugI9od" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen="" style="position: absolute; position: absolute; top: 0; left: 0; width: 100%; height: 100%;"></iframe></div>

 
 
# 안녕하세요. 자기 소개 부탁드립니다.
안녕하세요. 웹 백엔드 3기에 참여한 김누리입니다. 
재취업을 위해 부족한 부분을 채우고자 이번 부트캠프에 참여하게 되었습니다.
 
# 프로그래머스 데브코스는 어떻게 알게 되셨나요?
2024년, SM 업무를 맡고 있던 중 '내가 왜 이 일을 계속 해야 하지?'라는 생각이 들면서 변화가 필요하다고 느꼈습니다. 그래서 일단 뭔가 시작하자는 마음으로 프로그래머스에서 코딩 테스트 준비를 하다가, 우연히 데브코스 모집 배너를 보게 되었습니다.
 
프론트엔드와 백엔드 데브코스가 동시에 모집 중이었는데, 기존에 SM 업무를 진행하면서 SQL 관련 지식이 어느정도 있었기에 프론트엔드보다는 백엔드가 좀 더 접근하기 수월하겠다고 생각해 지원하게 되었어요.
 
# 타사도 있지만, 프로그래머스를 선택하신 이유는 무엇일까요?
우아한테크코스, 네이버 부스트캠프, 사피 등 저명한 부트캠프들도 많지만, 프로그래머스는 무엇보다도 **공신력 있는 플랫폼**이라는 인식이 컸습니다. 실제로 많은 기업들이 코딩 테스트를 진행할 때 자사 문제를 활용하기도 하지만, 그 외에는 **프로그래머스를 통해 진행되는 경우가 많기 때문**이었어요. 
 
이뿐만 아니라 **개발 커뮤니티에서도 추천**이 많았고요. 그래서 부족한 부분을 제대로 보완하기에 가장 적합한 곳이라 판단해, 결국 프로그래머스 데브코스를 선택하게 되었습니다.
 
# 데브코스가 약 6개월 동안 진행되었는데요. 데브코스 중 어떤 것이 가장 기억에 남나요?
아무래도 최종 프로젝트가 가장 기억에 남습니다. 비록 2~3차 프로젝트 때 담당했던 것과 동일하게 로그인 및 인증 인가 부분을 담당했지만, **2~3차 프로젝트 때는 AI를 이용해서 기능 구현하는 것에 초점을 두었다면, 최종 프로젝트에서는 구현 기능에 대해 구체적인 피드백을 받으며 좀 더 많은 고민**을 할 수 있었어요.
 
특히 기능 구현에 AI의 도움을 받았다고는 해도 내가 진짜 이해하면서 이를 활용하고 있는 것인지, 단순히 복사-붙여넣기를 해온 것은 아닌지에 대한 고민도 해보는 시간이었습니다.
 
# 데브코스 중 성장했다고 느낀 순간이 있나요?
데브코스를 하며 **조금 더 깊이 생각하는 습관**이 생겼습니다. 이전에는 조금만 어려운 소스코드나 복잡한 로직의 코드를 보면 GPT에게 어떤 의도인지 분석해달라곤 했는데요. 데브코스를 거치면서 **먼저 고민하고, 팀원들과 소통하며 문제를 풀어가게 되었습니다**.
 
예를 들어, 최종 프로젝트에서 로그인 기능을 구현할 때였어요. JWT 기반의 accessToken과 refreshToken을 '쿠키'를 통해 서버에서 클라이언트로 전달했는데, accessToken과 쿠키의 만료 시간을 동일하게 설정하는 바람에 클라이언트 쪽에서 쿠키가 증발해버려 인증 부분에서 계속 꼬이는 문제가 발생했어요.
 
이 부분을 팀원들과 함께 이야기하면서 원인을 정확히 파악할 수 있었고, 서로 JWT 관련 문서를 공유해 읽으며 피드백을 나눈 끝에 조금 더 완성된 기능을 구현해낼 수 있었습니다. 이 경험을 통해 기술적인 성장뿐만 아니라 협업과 문제 해결 능력도 함께 키울 수 있었어요.
 
# 최종 프로젝트에 대해 소개해 주세요.
최종 프로젝트로 **블로그 시스템을 개발**했습니다. 미디어에 나온 유명 장소들을 공유할 수 있는 블로그 플랫폼으로, 백엔드 5명, 프론트엔드 1명으로 구성된 팀 프로젝트였습니다. 자세한 내용은 [GitHub 프로젝트 페이지](https://github.com/prgrms-web-devcourse-final-project/WEB3_4_NDGL_BE)에서 확인하실 수 있습니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/3402e8d6-2120-4544-a11b-9072288a039e/image.png)
👆 누리 님이 참여한 최종 프로젝트
 
최종 프로젝트를 진행하면서 **Terraform 스크립트를 활용해 AWS 환경을 구성하고, 자동화 배포 기능까지 직접 다뤄볼 수 있었는데요**. GitHub에 소스가 병합되면 생성한 AWS 환경에 GitHub 이미지가 적재되어 순간적으로 중단되는 경우도 있었지만, 이러한 실습을 해볼 수 있었던 경험 자체가 유익하고 좋았습니다.
 
아쉬웠던 점은 이전 프로젝트와 마찬가지로 인증 기능을 맡게 되어 새로운 역할에 도전해보지 못했다는 점인데요. 하지만 이 경험을 통해 이전에 놓쳤던 개념들을 다시 짚을 수 있었고, 기술적으로 더 깊이 이해할 수 있었기에 결과적으로는 전화위복이 되었다고 생각합니다.
 
제가 아무래도 인프라 쪽에 관심이 더 있었던 터라, **이번 프로젝트를 계기로 개발뿐만 아니라 인프라 분야도 함께 학습해보고 싶다는 동기부여**가 되었다는 점에서도 뜻깊은 시간이었습니다.
 
# 데브코스를 통해 이루고자 했던 목표가 있었나요? 어느 정도 달성하셨나요?
혼자 Java 및 Spring을 활용하여 백엔드 환경을 구성하는 것이 목표였어요. 솔직히 답하자면 아직 이 목표를 달성하진 못한 것 같아요. 아직 AI에 의존하는 부분도 있고요. 하지만 지금까지의 프로젝트 경험을 통해 **어떻게 시작을 해야할지는 깨달은 것 같아요**. 아직 목표에 다다르진 않았지만, 출발선에는 도착한 느낌이에요.
 
# 기억에 남는 강사님이 있나요?
백엔드 메인 강사님이셨던 장희성 강사님이 가장 기억에 남습니다. 기본적인 개념을 알려주셨을 뿐만 아니라 프로젝트 진행 전 실습을 통해 이를 체득할 수 있도록 도와주셨습니다. 또한 프로젝트가 끝날 때마다 적절한 피드백을 통해 **어떻게 더 개선해 나갈 수 있을지 방향을 제시**해 주셨던 것도 좋았습니다.
 
# 운영 매니저와 함께 한 6개월은 어떠셨나요?
만족스러웠습니다. 
필요한 문서나 정보 요청에도 빠르고 친절히 응대해주셨습니다.
 
# 멘토링 경험은 어떠셨나요? 전반적으로 만족하셨나요?
너무 좋은 경험이었습니다. **멘토링을 통해 프로젝트 중간중간 제가 놓쳤던 부분, 놓쳤던 개념들을 다시 생각**해 볼 수 있었어요. 여기서 조금 더 나아가 생각해 볼 수 있도록 이끌어 주신 부분도 좋았습니다. 데브코스의 멘토링은 학습과 성장에 정말 좋은 기회라 생각합니다.
 
# 데브코스 수강을 고민하는 분들께 조언을 해주신다면, 어떤 이야기를 해주고 싶으세요?
**데브코스는 다양한 실습과 프로젝트를 통해 Java, Spring, SQL 등 백엔드 개발에 필요한 기술들을 체득하는 데 큰 도움이 되는 과정**이라 생각해요. 다른 부트 캠프는 어떤 식으로 진행되는지 모르겠지만, 데브코스의 경우 리모트 환경에서 강의와 프로젝트가 진행되다 보니 이동 시간이 없어 **학습에 더 많은 시간을 쏟을 수 있다는 점도 큰 장점**입니다. 동기들과의 협업도 큰 자산이 될 수 있으니 적극적으로 참여하길 추천드립니다.
 
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/98bf795d-80af-42cd-8675-309a81168661/image.png)
 
# 앞으로 어떤 개발자가 되고 싶으신가요?
특정 분야에 국한되지 않고, **다양한 영역을 다루며 문제를 해결할 수 있는 개발자**가 되고 싶습니다. 백엔드 중심으로 교육을 받았지만, 프론트엔드나 인프라도 다룰 수 있는 유연한 개발자로 성장하고 싶어요.
 
# 마지막으로 후배 수강생들에게 응원의 한마디 부탁드립니다.
데브코스를 통해 이루고자 하는 바가 있다면, 그 목표를 이루기 위한 좋은 계기로 삼으시길 바랍니다. 그리고 동기 및 팀원들과 활발히 소통하고 교류해서 인사이트를 넓히는 기회로 만드시길 바랍니다. 여러분, 화이팅입니다!
 
 
*강의 운영 사정에 따라 세부 프로그램 내용은 변경될 수 있습니다.*
 
 
[![BE_배너.jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/961ddffa-8fd1-456d-817c-9ce35082cd67/BE_%E1%84%87%E1%85%A2%E1%84%82%E1%85%A5.jpg)](https://school.programmers.co.kr/learn/courses/25244?utm_source=prgmblog&utm_medium=social&utm_campaign=school_25244_blog&utm_content=25244_banner)

[데브코스 후기] 재취업을 위해 시작한 데브코스, 더 깊이 생각하는 법을 배웠어요. - 백엔드 3기 수료생 김누리 님

웹 풀스택 3기 수료생 윤다혜 님의 인터뷰입니다. 다혜 님은 협업하는 기술을 익히고, 전체적인 웹 개발 사이클 경험해보고자 데브코스에 참여하게 되었다고 하는데요. 좋은 동료, 멘토님들과 협업하며 개발 역량을 쌓고, 수료 후 금융권 취업까지 성공한 다혜 님의 이야기, 궁금하시다면 인터뷰 전문을 읽어보세요!
 
# 안녕하세요. 자기 소개 부탁드립니다.
안녕하세요. 데브코스 웹 풀 사이클 3기 수료생 윤다혜입니다. 현재는 과정 수료 후 금융권에서 계정계 개발을 하고 있습니다.

![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/7ec39c0c-3bdf-471b-ac69-9c3e162be2cd/image.png)

# 프로그래머스 데브코스를 선택하신 이유가 무엇인가요?
졸업 후 취업을 준비하면서 웹 개발을 더 깊이 공부하고 싶었고, 이를 위해 강의, 스터디, 부트캠프 등 다양한 교육 과정을 찾아보았습니다. 그 과정에서 프로그래머스 데브코스를 알게 되었고, 그중 백엔드와 프론트엔드를 모두 경험할 수 있는 풀스택 과정이 매력적으로 다가왔습니다.

학부 시절에는 웹 개발을 제대로 접해본 적이 없었기 때문에 풀스택 개발을 경험할 수 있는 이 과정이 저에게 가장 적합하다고 생각했습니다. 또한, **현업 개발자의 멘토링과 여러 번의 프로젝트를 통해 실무 경험을 쌓을 수 있다는 점도 프로그래머스를 선택한 중요한 이유**였습니다.

# 약 6개월간의 데브코스 기간 동안 가장 기억에 남는 순간은 언제인가요?
아무래도 프로젝트 경험이 가장 기억에 남는 것 같아요. 제대로 된 팀 프로젝트를 경험해 본 적이 없었는데, **동료들과 함께 아이디어 회의부터 기획, 설계, 실제 구현까지 모든 과정을 겪어보며 많이 성장**했다고 생각해요. 특히 멘토링을 통해 현업에서는 어떤 식으로 업무를 진행하는지 조언을 구할 수 있었던 것도 좋았어요! 노션, 슬랙, 깃헙 등 여러 협업 툴을 경험해 볼 수 있었다는 점도 좋았습니다.

# 데브코스에 참여하면서 성장을 느낀 계기가 있나요?
첫 프로젝트로 작은 규모의 반려동물 스케줄러 서비스 백엔드 개발을 혼자 맡아 진행했습니다. **API와 DB 설계, 서버 구현을 맡아 개발을 진행하며 기술적으로 성장**하는 경험을 할 수 있었습니다. 특히, 서버에서 JWT를 쿠키로 넘겨주는 과정에서 CORS 에러로 며칠을 고생했던 기억이 있습니다. 당시에는 막막하고 힘들었지만, 지나고 보니 문제에 부딪히고 해결해나가는 과정에서 한 단계 더 성장할 수 있었던 것 같아요!

![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/6e253c41-43a5-45ef-803c-cf228a0fb16b/image.png)

# 최종 프로젝트에서 어떤 서비스를 개발하셨나요?
최종 프로젝트로 "펫메디서치" 서비스를 만들었습니다. **반려동물 병원과 약국을 쉽게 찾을 수 있도록 돕는 플랫폼으로, 저는 백엔드 개발을 담당**했습니다. 주요 기능으로는 근처 병원 및 약국 검색, 별점 및 후기 작성, 사용자 커뮤니티 등이 있습니다.

평소 필요성을 느꼈던 서비스를 직접 만들어볼 수 있어 프로젝트를 진행하는 내내 재미있게 개발할 수 있었고, 외부 API를 활용한 서비스를 구현해 볼 좋은 기회가 되었습니다. 다만, 예상보다 개발 일정이 지연되면서 일부 기능을 완성하지 못한 점은 아쉬움으로 남았습니다. 그럼에도 불구하고, 최종 프로젝트는 많은 것을 배우고 성장할 수 있었던 값진 경험이었습니다!

![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/d04e8453-904e-4de8-a5e3-f578fbdbdee4/image.png)

# 데브코스를 통해 이루고자 했던 목표는 무엇이었나요? 얼마나 달성하셨다고 생각하시나요?
데브코스에 참여하면서 처음 정했던 목표는 **협업하는 기술을 익히고, 전체적인 웹 개발 사이클을 경험해보는 것**이었습니다. 데브코스는 열정적인 동료들과의 협업 기회 뿐만 아니라, 스터디 등도 지원해주었기 때문에 자율적으로 학습할 기회가 많았습니다. 실제로 저는 팀원들과 함께 모던 자바스크립트 딥다이브 스터디를 진행했는데, 굉장히 유익했습니다! 

또한, 프로젝트마다 원하는 포지션을 선택할 수 있어 프론트엔드, 백엔드를 모두 경험할 수 있었고, 이를 통해 제가 데브코스를 들으며 세웠던 목표들을 모두 달성할 수 있었습니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/1732f31d-6cd4-44cb-b131-8515089e1870/image.png)

# 수료와 동시에 취업에 성공하셨다고 들었습니다! 현재 어떤 업무를 맡고 계신가요? 또한, 데브코스가 취업에 어떤 도움이 되었는지 공유해주세요.
현재 금융권에서 계정계 개발자로 일하고 있습니다. 은행에서 사용하는 코어 뱅킹 개발과 위성 시스템 관리 업무를 맡고 있습니다.

데브코스에서 진행한 여러 프로젝트 경험이 포트폴리오 및 서류 작성에 큰 도움이 되었습니다. 또한, 서류 합격 후 면접 준비가 막막했는데 데브코스에서 지원해주는 취업 컨설팅 덕분에 방향을 잡고 체계적으로 준비할 수 있었습니다.

# 기억에 남는 강사님이 있으신가요? 특별히 인상 깊었던 이유도 함께 들려주세요.
가장 기억에 남는 강사님은 김송아 강사님입니다. 첫 번째 스프린트를 진행해주셨는데, 백엔드에 대한 개념을 쉽고 이해하기 편한 방식으로 설명해 주셔서 흥미를 가질 수 있었습니다. 개발을 처음 접하는 사람도 부담스럽지 않게 들을 수 있겠다고 생각했어요.

같이 코딩하고 하나씩 오류를 고쳐나가면서 자연스럽게 백엔드 개발에 익숙해질 수 있었습니다. 딱딱한 이론보다는 실습 위주의 강의라 특히 저에게 잘 맞았던 것 같아요!

# 함께 공부했던 동료들은 어떠셨나요? 동료들과의 협업 경험에 대해 들려주세요.
같은 목표를 가진 동료들과 함께하며 더 많은 성장을 이룰 수 있었습니다. 특히 팀 프로젝트를 함께 진행하면서 자연스럽게 가까워졌고, 추가로 스터디를 구성해 JavaScript를 함께 공부하기도 했습니다.

과정이 진행될수록 동료들과의 유대감이 깊어져 서로 도움을 주고받으며 재미있게 학습할 수 있었고, 힘든 순간도 서로 의지를 다질 수 있어 좋았습니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/54f161a3-d261-4236-9ffa-ec80a372bfed/image.png)

# 진행된 멘토링 중에서 특별히 기억에 남는 순간이 있나요? 인상 깊었던 경험을 공유해주세요.
김영하 멘토님과의 멘토링 시간이 가장 기억에 남습니다. 과정 특성상 온라인으로 진행되었는데, 최종 프로젝트를 김영하 멘토님과 함께하면서 오프라인으로 팀 미팅을 할 기회가 있었습니다.

점심 식사를 함께하며 현업 개발자로서의 경험과 취업 준비에 대한 현실적인 조언을 많이 들을 수 있었는데, 막막했던 취업 준비 과정에서 큰 도움이 되었습니다.

# 데브코스 수강을 고민하는 분들에게 추천한다면, 어떤 점을 강조하고 싶으신가요?
**데브코스는 열정만 있다면 무한하게 성장할 수 있는 기회**라고 생각합니다. 특히, 혼자 취업을 준비하는 분들은 좋은 동료들과 멘토를 만날 기회가 많지 않지만, 데브코스에서는 능력 있는 멘토님들과 열정적인 동료들과 함께하며 성장할 수 있어요.

# 앞으로 어떤 개발자로 성장하고 싶으신가요?
운 좋게 취업에 성공했지만, 아직 배워야 할 것이 많다고 생각합니다. 항상 배움의 자세로 하루하루 성장하는 개발자가 되고 싶어요!

# 데브코스를 준비하는 후배 수강생들에게 응원의 한 마디 부탁드려요!
데브코스는 자신이 노력하는 만큼 많은 것을 얻어 갈 수 있는 과정이라 생각해요. 좋은 동료, 멘토님들과 함께 프로젝트를 진행하며 자연스럽게 성장할 수 있을 거예요. 질문을 두려워하지 마세요. 모르는 것이 있다면 적극적으로 질문하며 배워가시길 응원합니다!

 
 
[![full-coding-test2(729x90).jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/5efd9be6-366d-45ed-adfb-4117e1e495e0/full-coding-test2%28729x90%29.jpg)](https://school.programmers.co.kr/learn/courses/24941?utm_source=prgmblog&utm_medium=social&utm_campaign=school_FS_blog&utm_content=FS_banner)

[데브코스 후기] 열정적인 동료들과 성장하며, 금융권 개발자로 취업에 성공했어요 - 웹 풀스택 3기 윤다혜 님

풀스택 데브코스 수료생 이호성 님의 수강 후기 인터뷰입니다. 비전공자 출신인 호성님은 평소 개발 역량을 기르기 위해 프로그래머스에서 도움을 받았다고 하셨는데요. 프로그래머스에서 웹 풀스택 부트캠프를 진행한다는 모집 글을 보고 데브코스에 지원하게 되었다고 합니다. 이호성 님의 웹 풀스택 데브코스 후기가 궁금하신 분들은 아래 인터뷰를 끝까지 읽어보시길 추천드립니다.

![시안 2.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/431a06eb-7665-41bd-a490-17f2ccf2d14c/%E1%84%89%E1%85%B5%E1%84%8B%E1%85%A1%E1%86%AB%202.png)
 
# 안녕하세요. 자기소개 부탁드립니다.
안녕하세요. 저는 교육대학교를 졸업한 후, 개발자로 진로를 변경한 이호성입니다. 프로그래머스 웹 풀스택 데브코스 1기를 수료 후, 백엔드 개발자로 취업을 준비 중에 있습니다.

# 데브코스는 어떻게 알게 되셨나요?
독학을 하던 도중 유튜브를 통해 프로그래머스에서 데브코스를 운영한다는 사실을 알게 되었고, 상세 운영 내용을 프로그래머스 사이트에서 확인하였습니다.

# 타 기관도 있지만 프로그래머스를 선택하신 이유는?
저는 비전공자 출신으로, 처음 코딩을 시작했을 때 Hello World 한 줄 작성해 본 적도 없었습니다. 개발자가 되기 위한 저의 첫걸음은 지방 국비 학원에서 자바, 스프링 부트캠프 웹 풀스택 과정을 수료하는 것으로 시작되었습니다. 배운 기술 스택이 조금 오래되었지만, 충실히 배울 수 있는 부분을 배우려고 노력했습니다.

제 첫 프로그래밍 언어는 자바였는데, 프로그래머스 코딩테스트를 적극 이용하며 학습하였습니다. 프로그래밍 언어를 다뤄 문제를 해결한다는 것이 이런 것이구나 느끼며 코딩, 개발 역량을 기를 수 있었습니다. 이전에 다녔던 국비학원 수료 후에는 최신 기술 스택에 대한 학습의 필요성을 느꼈고, 리액트 독학을 하던 중 프로그래머스 웹 풀스택 데브코스 모집 소식을 듣게 되었습니다.
 
### 📌 제가 프로그래머스를 선택한 이유는 다음과 같습니다.
* 코딩 테스트 서비스 제공으로 저의 성장에 많은 도움을 주었던 기관에서 운영한다는 점
* 배우고 싶었던 비교적 최신 기술 스택들을 다룬다는 점
* 타입스크립트 한 가지 언어로 풀스택을 경험할 수 있다는 점
* 이전에 경험해 보지 못한 CI/CD, 배포를 강의 중에 다룬다는 점

# 5개월 동안 데브코스를 진행하면서 무엇이 가장 기억에 남나요?
**멘토링, 리액트 강의, 그리고 팀 프로젝트**가 가장 기억에 남습니다.
멘토링과 리액트 강의는 이후 질문에서 언급하고, 여기선 팀 프로젝트에 대해 이야기해 보겠습니다.

데브코스 이전 국비 학원에서는 제가 팀장 역할을 하면서, 구상부터 프론트와 백엔드 코드 작성, 마무리까지 모든 부분을 관여하며 정신없이 프로젝트를 진행했습니다. 그래서인지 동작은 하지만 객체 지향적, 클린 코드와는 거리가 멀었고, 유지 보수가 힘든 코드가 작성되었습니다. 또한 과정명은 풀스택이었지만 강사님들이 백엔드 개발자 출신이라 프론트엔드에 대한 배움이 상대적으로 부족했고, 사용 기술 스택이 오래되었다는 점이 아쉬웠습니다.

데브코스에서는 이러한 부분을 해소하기 위해 스스로 노력했습니다. 특히 과정 중 코드를 작성할 일이 많았는데, 이때 강의를 따라가기보다는 **주제와 요구 사항 등 큰 틀만 보고 프론트, 백엔드 코딩을 따로 2, 3회 차 진행하면서 주도적으로 학습**했습니다. 이를 통해 테스팅, 디자인 패턴 등 새로 배운 점들을 팀 프로젝트에도 적용함으로써 발전하고 성장할 수 있었습니다. 또한 취업 후 직장에서 팀원과 역할을 분담하고 협업해서 일을 한다는 느낌으로 프로젝트를 수행했기 때문에 **실전감**도 기를 수 있었습니다.

# 데브코스 기간 중 성장했다고 느낀 순간
함께 한 동기들이 모두 개발에 관심이 많고, 서로를 지지해 주는 환경이라 학습의 단초가 되는 키워드를 많이 얻을 수 있었습니다. 특히 제 나름대로의 백엔드 코드 구조와 패턴을 조직하고 통합 테스트를 연습하는 등 혼자 공부한 내용들을 스프린트 내내 그리고 팀 프로젝트에 적용시킨 것이 좋았습니다. 이뿐만 아니라 프로젝트 진행 도중 누가 요구하거나 문제 되지 않았음에도 **유지 보수와 성능 최적화 측면에서 스스로 고민하고 코드를 더 개선했던 경험**도 저의 성장을 느낄 수 있었던 순간이었습니다.

# 어려운 과제를 극복하고 기술적으로 성장한 경험이 있다면 이야기해 주세요.
팀 프로젝트 중에 트러블 슈팅 경험이 많았는데요. 그중에서도 기억나는 것들을 이야기해 보겠습니다.

### 1. 라이브러리 이슈 해결
자주 사용하던 라이브러리 express-async-errors가 팀원들과의 개발 환경 조율로 인한 버전업 때문인지 작동하지 않았을 때, **래퍼 함수를 이용한 클로저 패턴으로 수동 구현**했습니다. 이를 통해 백엔드의 모든 지점에서 어떤 에러가 발생하든 공통으로 에러 처리에 대응할 수 있었습니다.

### 2. Express와 Socket.IO 구조 조정
Express 구조와 채팅을 담당한 Socket.IO의 레퍼런스 구조가 맞지 않을 때, **따로 클래스를 선언하거나 구조를 조금 바꿔서 코드 패턴을 맞췄습니다**. 이전에 경험해 본 프로젝트에서도 외부 API를 활용할 때 해본 것이지만, 개발을 하다 보면 레퍼런스 문서가 제공하는 정보 그 이상의 구조나 기능 커스텀을 하고 싶을 때가 많습니다. 이번 팀 프로젝트에서도 해당 경우에 기초가 튼튼하다면 얼마든지 커스텀해 내가 원하는 목표를 달성하기 위해 사용할 수 있다는 자신감이 생겼습니다.

### 3. 프론트엔드 팀과의 협업
프론트엔드를 담당하는 분들이 제공된 API 활용에 어려움을 겪을 때, 백엔드 담당이어도 프론트 분들이 작성할 코드 구조나 방식을 구상해서 제안하거나 테스팅을 거친 코드더라도 문제가 발생했을 시 무엇이 원인인지 파악해 해결했습니다. 피어 리뷰에서도 해당 경험을 장점으로 언급해주셔서 고마웠습니다.

### 4. 추가 변경 사항 대응
프로젝트 진행 중 액세스 토큰만 발급하던 구조에서 리프레시 토큰도 함께 발급해야 하는 추가 변경 사항이 생겼습니다. 이미 엑세스 토큰만을 발급하는 것을 기준으로 작성된 프론트엔드와 백엔드 코드가 많았지만, 명세화된 API 문서와 코드를 검토하여 수정할 부분을 파악하고 모두 수정했습니다. 프론트엔드 팀과도 소통하여 필요한 변경 사항을 함께 논의한 결과, 문제없이 리프레시 토큰을 활용하도록 프로젝트를 성공적으로 변경할 수 있었습니다.

### 5. 배포 단계 문제 해결
개발용 테스트 서버에서는 문제가 없었지만, 빌드 후 배포 단계에서 문제가 발생했습니다. 원인은 태그 관련 연산을 최적화하기 위해 미리 생성해 둔 인덱스 파일이 빌드 시 누락된 것이었습니다. 인프라를 담당하셨던 팀원분께서 자신이 문제의 원인이라 생각하시고, 해당 문제를 혼자서 3일 동안 고민하셨습니다. 마감일이 다가오자 저에게 문제를 공유했고 여러 방면으로 문제 지점을 좁혀나갔습니다. **최종적으로 try-catch 구문을 추가해 에러를 콘솔에 표시한 결과 문제를 발견**하고, 인덱스 파일을 빌드에 포함시켜 문제를 해결했습니다.

### 6. 30분의 원칙
저는 프로젝트를 진행하면서 강조하는 원칙이 있는데, 바로 30분 원칙입니다. 작업할 때 30분 이상 막히는 경우 항상 협업하는 팀원들과 문제 상화에 대해 소통해야 한다는 것입니다. 막히는 문제를 서로 협업해서 해결할 수 있고, 또 혼자 고민하는 것보다 여럿이 고민하는 것이 함께 성장할 수 있는 길이기 때문입니다.

### 7. 멀티태스킹 능력
문제 상황에서 저의 강점 중 하나는 동시에 발생하는 여러 상황들 속에서 프로젝트의 전반적인 구조와 개발 방향성을 온전히 이해하고, 이를 동시에 대처할 수 있는 멀티태스킹 능력이라고 생각합니다. 이번 프로젝트에서 이러한 강점을 좀 더 강화할 수 있었습니다. 하지만 가장 좋은 것은 구상, 기획, 설계, 명세화 단계에서 좀 더 세심하게 고려해서 애초에 문제 상황이 발생하는 것을 최소화하는 것이며, 데브코스 수료 후에도 이를 위해 계속해서 노력할 것입니다.

# 최종 프로젝트로는 무엇을 만들었나요?
저희 프로젝트는 SNS나 데이팅 앱이 범람하는 요즘 시대에 사진, 동영상 등 자신을 어필해야 하는 포인트가 너무 많고 복잡하다는 문제 의식에서 출발했습니다. 저희 팀은 전통적이면서도 강력한 자기 어필의 수단이 될 수 있는 텍스트 미디어인 '일기'를 소재로 한 **일기 기반 소개팅 웹 어플리케이션을 개발**했습니다. 바로 (마음을) 연 다(이어리)라는 캐치 프레이즈에서 따온 '연다 Yeonda' 입니다.
 
> **좋았던 점**
> 팀원들 각자 담당했던 부분을 믿고 맡길 수 있었기에 저는 백엔드 개발에만 온전히 집중할 수 있었습니다. 또한 팀원들에게 배울 점이 많았다는 것, 그리고 기존에 익숙했던 기술 스택이 아닌 새로운 기술 스택을 따로 공부하여 프로젝트에 적용할 수 있었다는 점이 좋았습니다.

> **아쉬웠던 점**
> 초기 구상과 기획, 설계, 명세가 충분히 세밀하지 못해 프로젝트 진행 중에 변경 사항에 대응해야 했고, 이로 인해 다른 팀원들께 추가적인 부담을 드리게 되어 아쉽습니다.
또한, GitHub Actions 등을 활용해 CI/CD 파이프라인을 완전히 구축했더라면 좋았을 것 같습니다. 아울러 실제 서비스 환경을 가정한 테스트 기간과 CI/CD 및 배포에 관한 피드백이 프로젝트 완료와 별개로 별도로 주어졌다면 더욱 도움이 되었을 것 같아 아쉽습니다.

![스크린샷 2024-11-05 오후 2.15.49.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/9d767bd7-5bca-4698-a648-af38dda19821/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202024-11-05%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%202.15.49.png)

# 데브코스를 통해 이루고자 했던 목표는 무엇이며, 어느정도 달성하셨나요?
제가 이번 프로그래머스 데브코스를 통해서 이루고자 했던 목표는 과정 내외에서 배움을 체화해서 개발자 취업의 마지막 걸음에 도달하는 것이었습니다. **데브코스를 통해 제가 세운 목표 대부분을 달성**할 수 있었습니다.

아쉬웠던 점은 CI/CD 배포 학습 과정에서 많은 어려움을 겪었던 것과 프로젝트에서 역할, 시간 상의 이유로 적용해 볼 법한 아키텍처를 온전히 적용하지 못했던 것입니다.

강의 덕분에 어느 정도 구조에 대한 개념은 잡을 수 있었지만 강사님께서 실습하시는 환경과 많이 달라서, 스스로 설정 파일 코드나 세팅 등을 따로 진행했어야 했는데요. 마지막 연결 과정에서 발생한 문제를 해결하지 못했고, 이에 대한 도움을 적극적으로 요청하지 못했던 것이 아쉬운 점으로 남습니다.

# 기억에 남는 강사님이 있다면? 이유는?
저는 현재 백엔드 개발자를 지망하고 있지만, 입사 후 프론트엔드나 데브옵스 팀과의 원활한 소통과 협업을 위해, 그리고 회사 사정에 따라 풀스택 개발자가 필요할 경우를 대비해 React와 CI/CD 관련 기술을 배우고 싶었습니다.

그래서인지 **멘토링까지 겸하시면서 React를 강의해주신 문윤기 강사님의 수업이 특히 인상 깊었습니다**. 십수 년의 경력을 보유하신 문윤기 강사님께서 하나의 주제를 중심으로 프론트엔드 코드를 구현하시며 기본기와 실제 자주 사용하는 예제들을 소개해 주셨고, 이를 통해 많은 것을 배울 수 있었습니다. 덕분에 React에 대한 이해가 부족하다고 생각했던 제가 팀 프로젝트를 진행할 때 React에 익숙한 프론트엔드 팀원들과 원활하게 소통하고 협업할 수 있었습니다.

# 함께 스터디한 동료들은 어땠나요?
총 세 번의 조 구성(스프린트 과정 중 두 번, 팀 프로젝트 조 한 번)이 이루어졌는데요, 첫 번째 조에서는 리팩토링, 클린 코드, 그리고 타입스크립트 스터디를 자체적으로 진행하여 큰 도움이 되었습니다. 특히 **개발에 대한 관심과 열정이 가득한 조원분들 덕분에 진로가 크게 바뀌면서 혼자서는 파악하기 어려운 성장의 단초가 될 키워드들을 새롭게 발견**할 수 있었습니다. 팀 프로젝트 조에서는 손발이 잘 맞고 소통과 협업이 원활하게 이루어져 즐겁게 진행할 수 있었고, 이 인터뷰 내용을 작성하기 직전에도 조원들과 함께 프로젝트 이후 뒤풀이를 하며 즐거운 시간을 보냈습니다. 데브코스 이후에도 동기들과 계속 교류하며 함께 개발자로 취업하고 성장해 나가고 싶습니다.

![이호성님 인터뷰사진.jpeg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/71a9ee73-d17b-4b45-865a-26c9bd11c55d/%E1%84%8B%E1%85%B5%E1%84%92%E1%85%A9%E1%84%89%E1%85%A5%E1%86%BC%E1%84%82%E1%85%B5%E1%86%B7%20%E1%84%8B%E1%85%B5%E1%86%AB%E1%84%90%E1%85%A5%E1%84%87%E1%85%B2%E1%84%89%E1%85%A1%E1%84%8C%E1%85%B5%E1%86%AB.jpeg)

# 기억에 남는 멘토링 시간이 있나요?
프론트엔드에 문윤기 멘토님이 계셨다면, **백엔드에서는 마르코 멘토님께서 열정적으로 소통해 주시고 코드 리뷰까지** 세심하게 해주셨습니다. 데브코스 중 저는 스프린트별 주제와 관련된 백엔드 코드를 개인적으로 세 번씩 작성해 보며 배운 내용을 코드로 정리해 나갔는데, **요청하지 않았음에도 마르코 멘토님께서 직접 코드 리뷰를 해주셨습니다**. 덕분에 개선하고 배워야 할 부분을 세세하게 점검받고, 잘된 부분은 긍정적인 피드백을 받을 수 있었습니다.

이전에도 국비 지원 학원에서 코드 리뷰를 받은 경험이 많지만, 그 당시 팀 프로젝트 코드는 에러 해결에 초점을 맞춘 리뷰가 대부분이었고, 기초 개념을 다루는 코드들에 한해 리뷰를 받았습니다. 그래서 실제 개발자로서 필요한 역량을 갖추었는지, 입사 후 제대로 업무를 수행할 수 있을지에 대한 고민이 컸습니다. 하지만 많은 개발자들이 모인 데브코스에서 현직 멘토님들로부터 긍정적인 피드백을 받으면서 비로소 제 역량에 대한 확신을 가질 수 있어 매우 뜻깊었습니다.

# 데브코스 수강을 고민하고 있는 분들께 데브코스를 추천한다면, 어떻게 이야기하고 싶으신가요?
기본적인 개발 기초가 있고, 스스로 학습하며 동시에 동료들과 교류하며 성장하고자 하는 의지가 있는 분이라면 데브코스를 통해 저처럼 많은 것을 얻어가실 수 있을 것입니다. 또한, 모든 과정이 온라인으로 진행되어 필수 참여가 요구되는 코어 타임 외에는 스케줄을 유연하게 조정할 수 있어, 오프라인에서의 빡빡한 일정을 소화하기 어려운 분들에게 최적의 선택이 될 수 있을 것입니다.

# 앞으로 어떤 개발자가 되고 싶으세요?
개발과 무관한 진로를 걸어온 제가 선배와 동료 개발자들의 도움으로 한 명의 개발자로 성장할 수 있었던 것처럼, 앞으로는 제가 후배 개발자에게 도움이 되는 선배 개발자가 되고 싶습니다. 그동안 이용자의 입장에서만 경험했던 다양한 서비스들을 이제는 직접 개발하여, 더 많은 사람들에게 유용하고 이로운 경험을 제공할 수 있는 개발자로 성장하는 것이 제 목표입니다.

# 후배 수강생들에게 응원의 한 마디를 남겨주세요!
console.log("Hello Juniors! You've got this!");
 
더 자세한 인터뷰는 📌[유튜브](https://youtu.be/nBQo44A5c58?feature=shared)에서 확인하실 수 있습니다.
 
 
*강의 운영 사정에 따라 세부 프로그램 내용은 변경될 수 있습니다.*
 
 
[![full-coding-test2(729x90).jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/f6b58711-bc22-456f-886e-4dfcb474da92/full-coding-test2%28729x90%29.jpg)](https://school.programmers.co.kr/learn/courses/24941?utm_source=prgmblog&utm_medium=social&utm_campaign=school_FS_blog&utm_content=FS_banner)

[데브코스 후기] 비전공자 출신이지만 데브코스를 통해 많은 걸 얻었어요 - 웹 풀스택 1기 이호성 님

### 그렙 개발자가 들려주는 업무 이야기
그렙 개발자가 들려주는 업무 이야기는 그렙(프로그래머스)에서 4년 차 백엔드 개발자가 직접 작성하는 생생한 콘텐츠입니다. 이 시리즈에서는 실제 개발 업무를 진행하며 겪는 고민과 해결 과정, 최신 기술 적용 사례, 그리고 팀워크와 프로젝트 관리에 관한 이야기를 공유할 예정입니다. 저희가 준비한 이야기를 통해 **개발자와 그렙이 함께 성장하는 모습**을 발견해보세요!
 

***

 
안녕하세요. 저는 프로그래머스에서 AI 시험감독 솔루션 '모니토'라는 제품의 서비스를 담당하고 있는 **4년 차 백엔드 개발자** 에이다(Ada)입니다. 사용자들에게 더 나은 테스트 환경을 제공하기 위해 고민하고, 이를 해결하기 위한 개발 작업을 이어가고 있는데요. 작업 과정에서 마주했던 다양한 이슈와 그 해결 과정을 여러분과 공유하고자 합니다. **그렙 개발자가 들려주는 업무 이야기**를 통해 개발을 꿈꾸는 분들, 혹은 현업 개발자분들께 조금이나마 도움을 드릴 수 있는 기회가 되었으면 좋겠습니다.
 
오늘 이야기 나눠볼 주제는 그렙의 효율적인 알파 서버 운용 방식입니다. 소프트웨어 개발 과정에서 테스트 환경은 개발팀의 생산성과 협업 효율성에 큰 영향을 미칩니다. 특히, 여러 팀이 동시에 작업하는 경우 하나의 알파 서버를 공유하면 병목현상이 발생할 가능성이 높아지는데요. 이를 해결하기 위해 프로그래머스에서는 **독창적인 방식의 일회성 알파 서버를 도입해 운영 효율성과 비용 절감을 모두 달성**했습니다. 아래 글을 통해 이를 자세히 알아보겠습니다.
 
 
# 효율적인 알파 서버 운영의 중요성
개발 작업은 보통 [기획 > 코드 작업 > 테스트 > 스펙/오류 수정 > 테스트 > 프로덕션 배포] 순서로 진행됩니다. 이 중 **프로덕션 배포 전 테스트 및 QA는 필수 단계**이며, 주로 사내 개발자 및 기획자/디자이너만 접근 가능하도록 **내부적으로 구축된 서버에서 이루어집니다**. 이러한 서버를 보통 '알파 서버', '베타 서버'라 부릅니다. 사내 개발 팀이 적다면 단일 알파 서버로도 충분하지만, 여러 팀이 존재할 경우 알파 서버를 둘러싼 병목현상이 발생할 수 있습니다. 간단한 예를 들어보겠습니다.

```
A팀 a개발자: 기능1 작업 완료 후 알파 서버에 배포했습니다. 테스트 부탁드립니다. 
A팀 b테스터: 감사합니다. 확인 후 답변드릴게요. 
(30분 후) 
B팀 c개발자: 빠르게 핫픽스 작업 완료했고 알파 서버에 배포하겠습니다. 빠르게 테스트 부탁드립니다. 
A팀 a개발자: 지금 저희 팀에서 알파 서버 사용 중이라 조금 뒤에 부탁드려도 될까요? 
B팀 c개발자: 저희 배포가 급해서 먼저 사용해도 될까요? 
```


이처럼 단일 알파 서버를 사용하는 경우 여러 팀의 작업이 맞물리면서 배포 병목현상이 발생할 수 있으며, 이를 해결하기 위해 팀별 알파 서버를 구축할 수 있지만, 비용 부담이 커지는 문제가 있습니다.

# 프로그래머스의 효율적인 알파 서버 운영
## 일회성 알파
프로그래머스에서는 이러한 문제를 해결하고자 **일회성 알파**를 도입했습니다. 일회성 알파란 팀 내부에서 알파 서버를 생성하여 개발 및 테스트를 진행한 후, 일정 시간이 지나면 해당 서버를 제거해 비용을 절감하는 프로세스를 의미합니다. 일회성 알파를 간단하게 그림으로 나타내보겠습니다.

![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/bb832ac7-5114-4dba-b929-2bb0c738bd4a/image.png)

> **프로세스 요약**
> 1. 알파 서버 사용자는 알파 서버 생성 템플릿으로 작성합니다.
> 2. 작성된 템플릿을 바탕으로 알파 생성 파이프라인을 통해 알파 서버 생성합니다.
> 3. 사용 시간이 만료되면 일정 주기마다 돌아가는 크론잡에 의해 알파 서버 제거됩니다.

## 어떻게 일회성 알파를 구축했나요?
### 1. AWS 리소스를 사용하여 일회성 알파 구축
프로그래머스에서는 AWS 리소스를 활용해 일회성 알파를 처음으로 구축했습니다. 이 과정에서 [Scalable GHA Self Hosted Runner](https://github.com/philips-labs/terraform-aws-github-runner)를 참고했으며, 주요 프로세스는 다음과 같습니다.

1. GHA로 구축된 알파 서버 배포 파이프라인을 통해 AWS에 알파 서버 관련 리소스를 배포합니다. 해당 코드는 테라폼을 이용하여 구축하였습니다.
2. AWS에 로드밸런서, EC2 등 알파 서버 관련된 리소스가 배포되었다면, 이후 개발팀에서 QA를 진행합니다.
3. 알파 서버 사용 시간이 만료되면 일정 주기마다 돌아가는 scale-in 람다에 의해 알파 서버 관련된 리소스를 제거합니다.

![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/350e9927-d00b-4ce9-a7ea-8e1650392bae/image.png)

하지만 AWS 리소스를 활용한 방식은 다음과 같은 한계가 있었습니다.
* 알파 서버 제거 과정에서 일부 리소스가 누락되어 계속해서 AWS 클라우드 에 남아있는 문제
* AWS 리소스 생성하느라 배포 시간이 길어지는 문제
 
### 2. 쿠버네티스를 사용하여 일회성 알파 구축
AWS 리소스를 활용한 방식의 문제를 해결하고자 AWS 리소스를 사용하는 것이 아닌 k8s에 일회성 알파 인프라를 구축하였습니다.

![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/ec0967bf-906f-40fd-9f9b-0ec0c4d17606/image.png)

**k8s 기반 구축 프로세스**
1. GHA로 구축된 알파 서버 배포 파이프라인을 통해 AWS에 알파 서버 관련된 리소스를 배포합니다. 해당 코드는 helm을 이용하여 구축하였습니다.
2. 알파 서버 관련된 helm chart가 배포되었다면 이후 개발팀에서 QA를 진행합니다.
3. 알파 서버 사용시간이 만료되면 일정 주기마다 돌아가는 scale-in 크론잡에 의해 알파 서버 관련된 helm chart를 제거합니다.
 

k8s로 일회성 알파 인프라를 전환함으로써 **배포 시간의 단축과 효율적인 리소스 관리가 가능**해졌습니다.
* helm chart내 정의된 파드들만 생성함으로써 빠르게 리소스 생성 
* karpenter를 통해 빠르게 노드 스케일링이 가능해져 빠르고 효율적으로 리소스를 관리
* 배포 시간 단축 및 AWS 리소스 관리 이슈 해소

# 일회성 알파 도입의 효과
프로그래머스에서는 **일회성 알파를 도입하면서 비용은 절감하고, 개발 생산성은 크게 향상되는 효과**를 볼 수 있었습니다. 기존에는 각 팀이 24시간 동안 알파 서버를 독립적으로 운영하여 팀 수만큼 서버가 지속적으로 실행되었고, 이로 인해 불필요한 비용이 발생했습니다. 하지만 일회성 알파를 도입한 이후, **팀별로 필요한 시간에만 알파 서버를 생성해 운영함으로써 비용을 크게 절감**할 수 있었습니다.

또한, 이전에는 각 팀이 개별적으로 알파 서버를 관리해야 했으나, 일회성 알파 적용 후에는 **공용 인프라를 통해 모든 팀이 효율적으로 작업할 수 있는 환경**을 구축했습니다. 이로 인해 개발자들은 서버 관리의 부담에서 벗어나 오로지 기능 개발에만 몰두할 수 있게 되었습니다.
 
| |각 팀 별 알파 서버 운용 |일회성 알파 도입 |
| --- | --- | --- |
|서버 수 |팀 수 |작업 개수 |
|서버 운용 시간 |24시간 |일정 시간 |
|서버 관리 |각 팀 별 개발자 |공통 |
 
프로그래머스에서는 일회성 알파뿐만 아니라 CI/CD를 비롯한 다양한 환경에서 Scalable 인프라 구축을 시도하고 있습니다. 비용 절감 뿐만 아니라 개발 생산성 향상을 위한 환경 개선 작업을 꾸준히 이어 나가고 있으며, 앞으로 이러한 내용들도 블로그를 통해 공유드리도록 하겠습니다.
 
#### 같이 읽어보면 좋을 레퍼런스
* https://github.com/philips-labs/terraform-aws-github-runner
* https://kubernetes.io/ko/docs/home/
* https://istio.io/latest/docs/
* https://docs.github.com/ko/actions
* https://www.terraform.io/
 
 
[![coding-test2(729x90).jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/62448f31-d100-4b15-bc8d-f44ad827f593/coding-test2%28729x90%29.jpg)](https://school.programmers.co.kr/learn/courses/25186?utm_source=prgmblog&utm_medium=social&utm_campaign=school_25186_blog&utm_content=25186_banner)

[그렙 개발자가 들려주는 업무 이야기] 그렙에서는 어떻게 알파 서버를 운용할까?

[데브코스 후기] 4개월간 학습과 실습을 반복하며 기술적인 성장을 실감했어요. - 데이터 엔지니어링 4기 김정희 님

생성형 AI를 의존하는 도구가 아닌, 검증하며 활용하는 파트너로 삼고자 데브코스를 선택한 윤주찬 님의 인터뷰입니다.
6개월간의 학습과 파이널 프로젝트를 통해 백엔드 기본기부터 AI 기반 서비스 설계 경험까지 확장해 나간 성장 과정과 인사이트를 지금 확인해보세요.
 
 
## 안녕하세요. 자기 소개 부탁드립니다.
안녕하세요. **생성형 AI 활용 백엔드 개발 데브코스 3기** 수료생 윤주찬입니다. 저는 학부와 동아리 활동을 하면서 꾸준히 백엔드 엔지니어링을 해왔고, 계속해서 다양한 코드들과 기술을 접해보고 싶은, 호기심이 많은 백엔드 개발자입니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/8fe249c8-74e4-45a0-b409-883453305f09/image.png)
 
 
## 프로그래머스 데브코스는 어떻게 알게 되셨나요? 타 기관도 있지만, 데브코스를 선택하신 이유가 궁금합니다.
프로그래머스는 코딩 테스트를 준비하며 자주 사용하던 플랫폼이라 익숙했습니다. 개발 실력과 같은 하드 스킬뿐만 아니라, 다양한 사람들과 협업하고 소통하는 능력도 함께 키우고 싶어 부트캠프를 찾아보던 중, **이미 데브코스를 먼저 수료한 지인들의 추천**을 받았습니다. 특히 성장 속도가 빠른 **인공지능 기술 트렌드에 합류해 백엔드 개발자로서의 경쟁력을 갖추고자** <생성형 AI 활용 백엔드 개발> 데브코스 3기에 참여하게 되었습니다.
 
 
## 기존 백엔드 과정이 아닌, 생성형 AI 백엔드 개발 과정을 선택한 이유는 무엇인가요? 6개월이라는 긴 교육 기간에 대한 부담은 없으셨나요?
학부 시절 백엔드 동아리 활동을 통해 기본적인 개발 구조는 익혔지만, 최근 AI 도구를 활용한 개발이 빠르게 확산되는 흐름 속에서 뒤처지지 않기 위해 **AI를 보다 효율적이고 주체적으로 활용하고 싶다는 목표**가 생겼습니다.
 
저는 단순히 AI에 의존해 답을 얻는 개발자가 아니라, AI와 동등한 위치에서 개발을 진행할 수 있는 역량을 갖추고 싶었습니다. 이를 위해서는 **충분한 학습 기간 동안 AI와의 상호작용을 반복하며, 정보를 스스로 검증하고 선별하는 경험이 필요**하다고 생각했습니다.
 
그러한 이유로 오히려 6개월이라는 교육 기간이 짧게 느껴졌고, 배운 지식을 바탕으로 AI를 비판적으로 활용하며 필요한 정보만 정확히 골라낼 수 있는 똑똑한 개발자로 성장하는데 도움이 된 것 같습니다.
 
 
## 약 6개월 동안 데브코스에 참여하며, 가장 기억에 남았던 경험은 무엇인가요?
이번에 진행했던 데브코스의 파이널 프로젝트가 가장 기억에 남았고, 동시에 많은 교훈을 얻은 경험이었습니다. 스터디, 멘토링, 코드 리뷰 등 데브코스에서 했던 모든 경험들이 의미있었지만, 그 **모든 경험들을 실제로 적용하고 드러낼 수 있었던 무대가 바로 파이널 프로젝트**였다고 생각합니다.
 
특히 100% 온라인 과정이었고, MBTI I 성향의 내향적인 팀원들이 많았던 환경에서, 팀원들과 두 차례 오프라인으로 만났던 경험이 특히 뜻깊었습니다. 직접 만나 함께 식사하고 대화를 나누며 **같은 목표를 가진 동료로서 더욱 가까워지게 되었고, 그만큼 커뮤니케이션이 한층 더 수월해지며 프로젝트 개발 속도 역시 눈에 띄게 향상**되는 변화를 느낄 수 있었습니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/e8c4e333-a1bf-47da-b770-eb40358cb082/image.png)
🔼 팀원들과 더욱 가까워진 오프라인 모임
 
 
## 학습 과정 중 주기적으로 역량진단평가가 진행되는 것으로 알고 있는데요. 데브코스의 역량진단평가가 학습 과정이나 성장에 어떤 도움이 되었나요?
혼자 공부할 때는 알고리즘과 비즈니스 로직을 병행하며 꾸준히 학습하는 것이 쉽지 않았습니다. 하지만 데브코스에 참여하며 자연스럽게 학습 패턴과 리듬이 점차 맞춰졌고, 그 흐름을 점검할 수 있었던 기회가 바로 **역량진단평가**였습니다.
 
역량진단평가는 **수업에서 배운 내용을 확인하는 것뿐만 아니라, 알고리즘 감각을 유지**하는 데에도 많은 도움이 되었다고 느꼈습니다. 또한 평가 결과를 통해 스스로 부족한 부분을 명확히 인지할 수 있었고, **이를 바탕으로 이후 학습 방향성을 보다 체계적으로 설계**할 수 있었습니다.
 
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/ee23b089-5fd5-42f7-adfc-2af85ea0241d/image.png)
🔼 데브코스에서 주기적으로 진행했던 역량진단평가
 
 
## 최종 프로젝트에서 어떤 서비스를 만들었나요? 그 과정에서의 경험은 어떠했는지 공유해주세요.
저는 '일단 진행해' 팀에서 누구나 사용할 수 있는 **취미 장비 대여 플랫폼** '**취밋(ChwiMeet)**' 서비스를 개발했습니다. 이 프로젝트에서 제가 맡았던 주요 기능 중 하나는 **2-Stage RAG 방식을 적용한 AI 검색 기능**이었습니다.
 
프로젝트 초기에는 Spring AI에 대한 이해가 거의 없어 기초 개념부터 학습했습니다. 처음에는 Vector DB를 활용한 단순 유사도 기반 검색 결과를 바탕으로 답변을 제공하는 수준이었습니다. 하지만 **사용자 피드백과 내부 테스트를 반복하며 성능과 효율성 개선이 필요하다고 판단했고, 이를 위해 RAG 구조를 본격적으로 학습**하게 되었습니다.
 
RAG를 도입한 이후에는 부하 테스트를 통해 **응답 속도와 답변 품질을 동시에 개선하는 방향으로 구조를 재설계했고, 그 결과 2-Stage RAG 방식까지 적용**할 수 있었습니다. 단순 검색 결과를 바로 생성에 활용하는 것이 아니라, 1차 검색 결과를 정제 및 재선별한 뒤 최종 답변 단계로 전달하는 구조를 구성해 정확도와 안정성을 높였습니다.
 
처음에는 RAG 개념조차 명확하지 않은 상태에서 출발했지만, 팀원들과 지속적으로 논의하며 문제를 정의하고 해결해 나가는 과정 속에서 서비스 안정성을 위한 새로운 기술 도입까지 이어질 수 있었습니다. 이 경험을 통해 이미 존재하는 기술이라 하더라도, 상황에 맞게 검증하고 적용해 나가는 과정 자체가 서비스 품질을 결정짓는 중요한 요소라는 점을 깊이 체감했습니다.
 
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/803cc272-d752-4a3c-8d0e-713f6a898131/image.png)
🔼 팀원들과 함께 완성도 높은 결과물을 만들어 낸 최종 프로젝트
 
 
또한 팀원들 모두 개발 역량이 뛰어나고 협업이 원활해 안정적으로 프로젝트 속도를 유지할 수 있었습니다. 그 덕분에 기본 기능 구현에만 그치지 않고, 학습과 병행하며 기능을 지속적으로 개선할 수 있는 여유가 있었습니다.
 
이번 파이널 프로젝트는 그동안 배우고 공부했던 내용들을 종합적으로 적용해볼 수 있는 기회였다고 생각합니다. 완성도를 높이기 위해 많은 시간을 투자했고, 그 결과 **프로젝트 전반의 품질과 완성도를 인정받아 운영진 평가 1위, 참여기업 평가 1위, 교육생 평가 2위라는 성과**를 얻을 수 있었습니다. 정말 의미 있는 경험이었고, 함께한 팀원들 모두에게 감사한 프로젝트였습니다.
 
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/fcfd0dd7-67a1-47bd-bb29-4104d81b0488/image.png)
🔼 팀원들과 함께 이루어낸 최종 프로젝트 성과
 
 
## 데브코스를 통해 이루고자 했던 목표는 무엇이었나요? 얼마나 달성했다고 느끼시나요?
학부와 동아리에서의 경험만으로는 제 개발 역량이 충분하지 않다는 한계를 느꼈고, 스스로가 우물 안 개구리처럼 느껴졌습니다. 그래서 졸업 후에는 개발에 대한 시야를 넓히고, 보다 체계적으로 성장하고 싶다는 목표를 갖게 되었습니다.
 
데브코스를 통해 기존에 알고 있던 Spring, JPA, RDBMS 활용을 넘어, Grafana, Prometheus, QueryDSL, Spring AI, CI/CD 구축 등 그동안 부족하다고 느꼈던 영역은 물론, 이전에는 존재조차 몰랐던 다양한 기술들을 접할 수 있었습니다. 특히 **실무에서 실제로 많이 사용되는 기술과 그 활용 맥락을 함께 이해**할 수 있었던 점이 큰 도움이 되었습니다.
 
개발에 대한 시야가 넓어지면서 하나의 기술을 학습하다가, 자연스럽게 연관된 다른 기술로 학습이 확장되는 경험도 할 수 있었습니다. 예를 들어 **Spring AI를 학습하는 과정에서 Vertor DB와 RAG 개념까지 함께 공부**할 수 있었고, 이를 통해 각각의 기술이 어떻게 연결되어 실제 서비스에 활용되는지를 이해할 수 있었습니다.
 
아직 모르는 기술이 훨씬 많다고 느끼지만, 오히려 배워야 할 것이 많다는 사실 자체가 긍정적인 동기 부여가 되었습니다. 앞으로도 새로운 기술을 즐겁게 학습하며, 꾸준히 성장해 나가고 싶다는 방향성을 분명히 하게 된 경험이었습니다.
 
 
## 수업을 진행해주셨던 강사님은 어떠셨나요?
기존에 백엔드 중심으로 학습해 왔기 때문에, 초반에 프론트엔드를 배우는 과정이 다소 어렵게 느껴졌습니다. 하지만 **강사님께서 학습 속도와 난이도를 적절히 조절**해 주신 덕분에 뒤처지지 않고 차근차근 따라갈 수 있었습니다.
 
무엇보다 수업 중간중간 수강생들의 이해도를 지속적으로 확인하며 세심하게 이끌어 주신 점이 너무 좋았습니다. 또한 **제가 몰랐던 기술이나 적용해 보고 싶었던 기술에 대한 자료를 빠르게 공유**해 주셔서, 학습에 필요한 시간을 효율적으로 사용할 수 있었습니다.
 
저는 평소 식사 시간에 가벼운 게임 영상이나 재밌는 영상들을 보곤 했는데, 강사님께서 매일 필수 학습 영상을 공유해 주신 덕분에 식사 시간을 보다 알차게 활용할 수 있었습니다. 덕분에 일상 속에서도 자연스럽게 개발 지식을 접할 수 있었던 점이 특히 감사하게 느껴졌습니다.
 
 
## 동료들과 함께한 스터디는 어땠나요?
저는 매주 꾸준히 '꽉 자바' 스터디에 참여했습니다. 초반에는 **Java를 활용해 각자 알고리즘 문제를 풀이**하고, 코드 리뷰를 통해 서로의 접근 방식과 의견을 공유했습니다.
 
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/35cf2568-532e-4240-b7ed-9a4724fc9f7e/image.png)
🔼 알고리즘 문제 풀이와 코드 리뷰를 통해 의견을 공유했던 스터디
 
 
중·후반에는 **「Effective Java」를 파트별로 나누어 읽고 발표하며, 각자 이해한 내용을 설명하고 정리하는 방식으로 스터디를 진행**했습니다. 그동안 Java를 책으로 체계적으로 학습하기보다는 실습 위주로 접해왔기 때문에 처음에는 다소 어렵게 느껴지기도 했습니다.
 
하지만 스터디 팀원들이 각자의 시선에서 내용을 쉽게 풀어 설명해 주었고, 그 과정에서 함께 성장하고 있다는 느낌을 받을 수 있었습니다. 특히 책의 내용이 매우 알차서, 캡슐화의 중요성이나 결합도와 응집도처럼 **그동안 깊이 고민하지 않고 사용하던 개념들을 "왜 이렇게 설계해야 하는지" 이해**하며 읽을 수 있었습니다.
 
그 결과 Java에 대한 이해도가 한 단계 더 깊어졌고, 프로젝트에서도 해당 개념들을 자연스럽게 적용할 수 있었습니다.
 
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/9151dfbf-141b-4fa8-bccb-5997c2e00399/image.png)
🔼 도서를 파트별로 나누어 읽고 발표하며 정리했던 스터디
 
 
## 데브코스에서의 멘토링 경험은 어떠했나요?
최원진 멘토님과 매주 멘토링을 진행하며 다양한 질문을 드릴 수 있었고, 그에 대해 하나하나 구체적이고 성심껏 답변해 주셨습니다. 단순한 문제 해결에 그치지 않고, **프로젝트에 적용하면 좋을 기술 스택과 그 선택 이유, 코드 가독성을 높이는 방향까지 함께 설명해 주셔서 서비스의 완성도를 높이는 데 큰 도움이 되었습니다**.
 
또한 포트폴리오와 이력서 구성, 코딩 테스트 준비 등 **신입 개발자로서 미리 알아두면 좋은 전략들을 공유**해 주신 덕분에, 수료 이후의 진로와 준비 방향성까지 잘 잡을 수 있었습니다.
 
 
## 데브코스 취업 지원 중 도움이 되었던 부분은 무엇인가요?
**이름만 들어도 알 수 있는 기업의 현직자분들로부터 다양한 특강을 들을 수 있었던 점이, 데브코스에서 제공하는 가장 큰 취업 지원**이라고 느꼈습니다. 저는 매번 빠짐없이 참여하며 실무와 취업 준비에 도움이 되는 구체적인 조언들을 얻을 수 있었습니다.
 
데브코스에 참여하기 전에는 무엇부터 준비해야 할지, 이력서와 포트폴리오는 어떻게 구성해야 할지에 대한 감이 부족했지만, 특강을 통해 얻은 인사이트와 그동안 수집한 정보들을 바탕으로 방향성을 잡을 수 있었습니다. 이를 잘 적용해 원하는 곳으로 취업하는 것이 목표입니다!
 
 
## 생성형 AI 활용 백엔드 개발 데브코스를 한 문장으로 표현한다면?
개발이 더욱 재미있어지는 경험
 
 
## 앞으로 어떤 개발자가 되고 싶으신가요?
모든 사람들과 원활하게 소통하는 개발자가 되고 싶습니다.
또한 "**AI는 활용하되, 검증은 내가 한다**"는 기준을 꾸준히 지켜가며 개발 역량을 키워, 회사에 실질적인 가치를 줄 수 있는 개발자로 성장하고 싶습니다.
 
 
## 마지막으로 데브코스 수강을 고민하는 분들에게, 추천의 한마디 부탁드립니다.
고민하는 데 시간을 쓰기보다는, **배우고 싶은 마음이 분명하거나 개발에 진지하게 몰입하고 싶은 분들이라면 큰 걱정 없이 도전**해 보셔도 좋을 것 같습니다. 수업과 프로젝트 전반에서 강사님, FT님, 매니저님, 멘토님 모두가 체계적으로 지원해 주셨고, 함께한 동기분들과도 좋은 자극을 주고받을 수 있었습니다.
 
**6개월이라는 기간이 결코 길게 느껴지지 않았고, 오히려 빠르게 지나갈 만큼 밀도 있는 시간**이었습니다. 이 인터뷰를 보고 계신다면, 더 늦기 전에 한 번 도전해 보시기를 추천드립니다!
 
 
*강의 운영 사정에 따라 세부 프로그램 내용은 변경될 수 있습니다.*

 
 
[![블로그 배너_AI BE.jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/b9fdc446-84fa-4e83-9673-556bffa40d18/%E1%84%87%E1%85%B3%E1%86%AF%E1%84%85%E1%85%A9%E1%84%80%E1%85%B3%20%E1%84%87%E1%85%A2%E1%84%82%E1%85%A5_AI%20BE.jpg)](https://school.programmers.co.kr/learn/courses/25330?utm_source=prgmblog&utm_medium=social&utm_campaign=school_25330_blog&utm_content=25330_banner)

[데브코스 후기] AI를 잘 다루는 개발자로 성장한 6개월, 개발이 더 즐거워졌어요 - 생성형 AI 활용 백엔드 개발 3기 윤주찬 님

### SOTA(States Of The Arts)를 아시나요?
인공지능 분야인 딥러닝과 머신러닝에서 최고의 성능을 내는 알고리즘을 SOTA(States Of The Arts)라고 부릅니다. 이 SOTA 알고리즘에 대한 `논문(Paper)`과 `코드(Code)`를 한 번에 제공해주는 곳이 있는데요. 바로 "[Papers with code](https://paperswithcode.com/)"입니다.
 
여기에서 2025년 1월, 세계 최고 이슈가 된 DeepSeek의 논문, 코드, 데이터셋, 최신 AI 모델의 성능비교(DeepSeek-R1 vs. OpenAI-o1) 등 최신 AI 논문과 코드를 볼 수 있습니다. 이곳에 공개된 인공지능 논문을 읽으면, 그 아이디어와 코드, 수학적인 전개에 감동을 받지 않을 수 없습니다. "아! 저자는 천재구나, 어떻게 코드와 딱 맞는 수식을 작성했을까?"라고 말이죠.
 
그런데 여러분, 지금 이 생각에는 잘못된 부분이 있습니다. 눈치채셨나요? 바로 "코드에 딱 맞는 수식"이라는 부분입니다. 왜 이 말이 잘못 되었을까요? 간단한 수학문제를 예로 들어보겠습니다.
 
[문제] 1+2+3+...+10 의 정답을 알고 있나요? 55. 어떻게 계산하셨어도 좋습니다. 1+2+3+...+1000 그럼 이 문제의 정답은요?
 
[수학] 이 문제를 일반화하기 위해 수학으로 표현하면 아래와 같이 표현할 수 있죠.
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/38f9dc54-cfb7-4438-b1bd-7c6863682580/image.png)
 
[코드] 그리고 이제 컴퓨터에게 계산을 시킨다면 sum(range(1, n+1)) 의 형태로 프로그래밍 할 수 있습니다.
 
이처럼 어떤 [문제]를 풀기 위해서, 일반적인 형태의 [수식]을 만들고, 컴퓨터 프로그래밍으로 알고리즘을 구현한 것이 [코드] 입니다.
 
### 문제 → 수식 → 코드
하지만 오늘날 많은 사람들은 코드가 애초에 먼저 생겼다고 착각합니다. 그래서 머신러닝 딥러닝, 데이터 분석이라고 하면 의레 코딩부터 떠올리게 됩니다. 하지만 코딩을 배우면서 조금 지나다 보면 그 한계에 도달합니다. 책에도, 블로그에도, 모르는 수학적 기호들이 등장합니다. 알고리즘에 대한 개념에 대한 이해가 되지 않으니 책을 따라하는 수준, 남이 짜놓은 코드를 따라가는 수준에 그칠 수 밖에 없습니다. 
 
![문제수식코드.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/1b91ba32-1e25-4b9b-aee3-84ea4ed65c82/%E1%84%86%E1%85%AE%E1%86%AB%E1%84%8C%E1%85%A6%E1%84%89%E1%85%AE%E1%84%89%E1%85%B5%E1%86%A8%E1%84%8F%E1%85%A9%E1%84%83%E1%85%B3.png)
 
### "인공지능을 잘 하기 위해서는 수학이 중요하다."
이 말을 한번쯤 들어보셨을 겁니다. 실제 문제를 풀기 위해 기존의 논문을 읽고, 코드를 응용할 때도 어김없이 수학이 발목을 잡습니다. 우리가 수학과 친하지 않은 이유는 바로 “활용” 경험이 없기 때문입니다. 중고등학교 때의 수학은 문제를 풀기 위해서 였다면, 이제는 개념을 이해하고, 원리를 활용에 접목하기 위한 공부가 필요합니다. 
 
겁먹을 것이 없습니다. 인공지능을 이해하고 활용하는 데 필요한 수학은 우리가 학교다닐때 배운 “모든” 수학이 아닙니다. 핵심적인 몇 가지 개념만 제대로 이해해도 복잡한 논문을 읽고, 코드를 개발하며, 나아가 창의적인 문제 해결을 할 수 있습니다. 
 
대표적으로 **함수, 확률과 통계, 미분, 선형대수** 네 가지를 꼽을 수 있습니다. 함수는 입력을 받아 특정 규칙에 따라 출력을 생성하는 개념이며, 확률과 통계는 데이터의 패턴을 분석하고 불확실성을 다루는 데 활용됩니다. 미분은 변화율을 측정하여 최적화 문제를 해결하는 데 필수적이며, 선형대수는 다차원 데이터를 효과적으로 표현하고 변환하는 데 중요한 역할을 합니다.
 
이 중에서도 함수는 인공지능의 가장 기초적인 개념인데요, 인공신경망을 비롯한 대부분의 AI 모델은 여러 개의 함수가 결합된 형태로 작동하며, 입력 데이터를 변환하여 원하는 결과를 만들어냅니다. 오늘은 가장 먼저 함수의 개념과 그 응용을 이해하면서서 AI의 원리를 파악하는 첫걸음을 딛어보기로 하겠습니다. 고등학교 수학을 어렴풋이 기억하고 있다면 절대 어렵지 않습니다. 
 
준비가 되셨다면, 한번 같이 가보실까요?
 
# 인공지능은 함수다.
다음 □에 들어갈 말은 무엇일까요?
```
□에 돈(입력)을 넣으면 음료(출력)가 나온다.
□에 검색어(입력)를 넣으면, 검색결과(출력)가 나온다.
□에 질문(입력)을 넣으면, 답변(출력)이 나온다.
```
 
첫번째 문장에서 빈 칸에 들어갈 말은 "자동판매기"입니다. 두번째는 "구글 검색창", 마지막 세번째는 "챗GPT"가 되겠네요.
 
자, 그럼 다음은 어떤가요?
 
```
□에 1을 넣으면, 2가 나오고 (1 → □ → 2)
□에 2를 넣으면, 4가 나온다. (2 → □ → 4)
```
 
이것을 다시 쓰면 x=1, y=2 그리고 x=2, y=4 입니다.
이것을 일반화 해서 □에 x를 넣으면, y가 나온다는 것을 다음과 같이 표현합니다.
 
 y=f(x)= 2x 
 
우리는 이것을 "함수"라고 부릅니다. 즉, 함수는 어떤 입력을 넣으면, 정해진 규칙을 거쳐 출력을 만들어내는 기능(function)입니다. 예를 들어 이미지를 인식하는 AI는 다음 과정을 통해 결과를 출력하죠.
 
```
입력: 사진 데이터 (픽셀 값)
함수: 신경망 (Neural Network)
출력: 사진 속의 사물이 무엇인지 예측 (예: "고양이" or "강아지")
```

# 함수란 무엇일까?
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/7805ff6a-bd92-466c-8a53-de0fb15f0d8c/image.png)
 
함수는 하나의 기능을 가질 수도 있지만, 두 개 이상의 함수를 연속으로 결합할 수도 있습니다. 우리는 이것을 합성 함수라고 부릅니다. **합성 함수는 순차적으로 적용하는 개념**이라고 보면 되는데요. 수학적으로, 두 개의 함수 f와 g가 있을 때, 새로운 합성 함수 h는 다음과 같이 정의됩니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/fd051dee-331b-4647-8611-f8d3fd1d6707/image.png)
 
즉, 먼저 함수 g(x)를 계산한 후, 그 결과를 다시 함수 f(x)에 넣는 구조입니다. 이 개념은 **딥러닝, 신경망, 트랜스포머** 등의 인공지능 모델에서 핵심 원리로 사용됩니다.
 
딥러닝에서는 입력 데이터를 여러 단계의 합성 함수로 변환하여 패턴을 학습합니다. 딥러닝 모델은 기본적으로 여러 개의 변환을 거치는 합성 함수 구조로서, 합성함수는 CNN, GAN 등 대부분의 딥러닝 모델에 적용됩니다.
**CNN(Convolutional Neural Network, 합성곱 신경망)*
 
예를 들어 CNN의 구조와 합성 함수를 간단히 설명해보겠습니다. CNN은 **이미지 처리**에 최적화된 딥러닝 모델인데요. CNN의 각 계층은 다음과 같이 합성 함수 형태로 표현됩니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/fda80b1a-7456-45b0-bb5f-78707f2438c8/image.png)
👆 CNN 모델의 아키텍처 (출처: [Dharmaraj](https://medium.com/@draj0718?source=post_page---byline--716fb197b243---------------------------------------))
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/a396b91d-e44a-4cc6-8140-9baf249bf52c/image.png)
 
* f1(x) : **합성곱(Convolution) 연산** → 필터를 이용해 이미지의 특징을 추출
* f2​(x) : **ReLU 활성화 함수** → 비선형 변환
* f3​(x) : **풀링(Pooling) 연산** → 차원 축소 및 중요한 정보 유지
* f4​(x) : **완전 연결(Fully Connected) 계층** → 최종 분류
 

이처럼 CNN은 **여러 개의 변환 함수(합성 함수)로 이루어진 구조**를 가집니다.

또 다른 예로 GAN(생성적 적대 신경망)은 이미지 생성, 딥페이크, 스타일 변환 등에서 사용됩니다. GAN은 생성자(Generator, G)와 판별자(Discriminator, D)의 두 네트워크로 구성됩니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/f4b58cdb-2810-402f-9d43-6bacfabe9e27/image.png)
 
* G(z): 생성자는 입력된 랜덤 노이즈 z를 변환하여, 가짜 데이터를 생성하는 함수
* D(x): 판별자는 입력 x가 진짜인지 가짜인지 판별하는 함수
 

**전체 모델**은 D(G(z))라는 합성 함수 형태를 가집니다. GAN은 생성자와 판별자가 **경쟁하면서 발전하는 구조**를 가지며, 이는 **합성 함수 개념**을 기반으로 동작합니다. 
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/5642e64e-8738-414e-8cf6-527e62c4add7/image.png)
👆 GAN 모델의 손실함수 (출처: [Pedro Henriques Abreu](https://www.researchgate.net/profile/Pedro-Henriques-Abreu?_tp=eyJjb250ZXh0Ijp7ImZpcnN0UGFnZSI6Il9kaXJlY3QiLCJwYWdlIjoiX2RpcmVjdCJ9fQ))

# 겹겹이 쌓은 함수 파이
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/b985505d-8928-4a64-8b1b-72c374de7a75/image.png)
 
인공지능은 결국 함수를 쌓아 올린 거대한 체계입니다. 우리가 자판기에 동전을 넣고 원하는 음료를 받듯이, AI도 입력 데이터를 받아 특정 규칙에 따라 출력을 생성합니다. 단순한 수학적 함수에서 시작해 신경망, CNN, GAN과 같은 복잡한 모델까지, 모든 AI 시스템은 본질적으로 함수의 조합으로 이루어져 있습니다.
 
인공지능은 마법이 아닌, "**겹겹이 쌓인 함수 파이**"입니다. AI는 마술상자가 아니라, '함수'라는 수학을 기반으로 한 도구이자 기능의 집합입니다. 수학을 조금만 이해해도 AI가 어떤 원리로 작동하는지 이해할 수 있고, 그 기술을 더 효과적으로 활용할 수 있습니다. 더 나아가 창의적인 방식으로 새롭게 조합할 수도 있을 것입니다. 인공지능은 마법이 아니라 함수의 조합이지만, 우리의 창의적인 사고와 응용 방식에 따라 마법 같은 변화를 만들어낼 수 있습니다.
 
 
![정경문 작가님 프로필 카드.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/9b1ba639-5df1-478c-abfd-65cdfc86234a/%E1%84%8C%E1%85%A5%E1%86%BC%E1%84%80%E1%85%A7%E1%86%BC%E1%84%86%E1%85%AE%E1%86%AB%20%E1%84%8C%E1%85%A1%E1%86%A8%E1%84%80%E1%85%A1%E1%84%82%E1%85%B5%E1%86%B7%20%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%84%91%E1%85%B5%E1%86%AF%20%E1%84%8F%E1%85%A1%E1%84%83%E1%85%B3.png)

인공지능은 겹겹이 쌓은 함수 파이

LIG 넥스원 소프트웨어 연구원으로 근무 중인 김재영 수료생을 만났습니다. 데브코스에서의 멘토링, 스터디, 협업 프로젝트 경험은 단순한 학습을 넘어 취업 준비와 실무 적응까지 든든한 발판이 되었다고 하는데요.
 
이번 인터뷰에서는 재영 님이 직접 들려주는 데브코스 경험과 취업 성공 스토리, 그리고 앞으로의 커리어 목표까지 함께 들어보았습니다. 프론트엔드 데브코스를 수강 중이거나 관심 있는 분이라면 끝까지 읽어보시는 걸 추천드립니다!
 
 
## 안녕하세요. 간단한 자기소개 부탁드립니다.
안녕하세요! 프론트엔드 데브코스 3기를 수료하고 **LIG 넥스원**에서 **소프트웨어 연구원**으로 근무 중인 김재영입니다. 현재 회사에서는 무인기(드론) 사업에 참여하고 있습니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/059505bf-a4e5-4e59-a53d-cc23e5c78ff2/image.png)
 
## 데브코스 중 어떤 트랙을 수료하셨나요? 해당 과정에 참여하게 된 계기가 궁금합니다.
저는 **프론트엔드 데브코스 3기** 과정을 수료했습니다.
처음에는 어떤 분야로 취업해야 할지 고민이 많았는데, 대학교 4학년 때 학점 연계 인턴십을 하면서 프론트엔드 개발의 매력에 빠지게 되었습니다. 직접 만든 결과물을 바로 웹 페이지에서 확인할 수 있다는 점이 특히 흥미로웠고, 자연스럽게 프론트엔드 분야에 관심을 가지게 되었습니다.
 
이후 프론트엔드 역량을 본격적으로 강화하고 싶어서 여러 부트캠프를 고민하다가 데브코스를 선택하게 되었습니다. 대학 동기의 추천이 큰 영향을 줬고, 또 데브코스가 부트캠프 중에서 좋은 평이 많다는 얘기를 들어왔던 터라 믿고 선택할 수 있었습니다.
 
 
## 데브코스에 참여하며 가장 인상 깊었던 경험은 무엇인가요?
크게 세 가지를 말씀드릴 수 있을 것 같습니다.
 
### ✅ 멘토링
첫 번째는 멘토링입니다. 프로젝트를 진행하면서 현업 개발자분께 지속적으로 멘토링을 받을 수 있었는데, 이게 정말 큰 도움이 됐습니다. **코드 리뷰를 통해 현업 시각에서 피드백을 받다 보니 혼자 공부할 때보다 훨씬 빠르게 성장**할 수 있었습니다. 또 팀 프로젝트에서도 멘토링 덕분에 팀원들이 같은 방향성을 가지고 협업할 수 있었고, 프로젝트 진행이 훨씬 원활했습니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/608b7080-6734-41d9-ab7c-58201fb18c7c/image.png)
🔼 현업 시각에서 피드백을 받을 수 있었던 코드 리뷰와 멘토링 🧑‍🏫
 
### ✅ 스터디
두 번째는 스터디 경험입니다. **데브코스에서는 스터디를 적극 장려하고 있으며, 스터디에 필요한 개발 서적 구매도 지원**해주고 있습니다. 그 덕분에 혼자서는 끝내기 어려웠던 개발 서적을 완독할 수 있었고, 팀원들과 스터디 내용을 공유하며 부족했던 개발 지식을 채울 수 있었습니다. 무엇보다 이 과정을 통해 스터디 습관을 기르게 된 것이 의미 있었습니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/7d93e088-fca7-4500-b078-43b424a8676e/image.png)
🔼 유익했던 스터디 시간들 📚
 
 ### ✅ 프로젝트
마지막으로는 백엔드 데브코스와의 협업 프로젝트입니다. 약 한 달 동안 백엔드 과정의 수강생들과 함께 프로젝트를 진행하면서, 프론트엔드뿐만 아니라 서비스 전체 개발 과정에 참여할 수 있었습니다. **매일 모여 협업에 몰두하다 보니 개발 역량뿐만 아니라 협업 능력도 크게 키울 수 있었고**, 이 경험을 통해 백엔드에도 흥미가 생겨 따로 공부를 시작할 만큼 인상 깊은 시간이었습니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/ba0e2fe1-629a-4476-b549-a21cd70cba4d/image.png)
🔼 개발 역량과 협업 능력을 키울 수 있었던 최종 프로젝트 💪
 
 
## 취업 준비는 어떻게 하셨나요? 포트폴리오 준비, 자기소개서 작성 방법, 면접 준비 등 자유롭게 알려주세요.
### ✅ 자기소개서
저는 자기소개서를 작성할 때 **제가 성장하고 배운 점이 뚜렷한 경험을 중심으로 작성**했고, 이러한 부분이 인사담당자에게 어필이 될 것이라 생각했습니다. 특히 **그 경험 속에서 직면했던 문제 상황과 어떤 고민을 통해 문제를 해결했는지, 그 과정에서 무엇을 배우게 되었는지**를 담으려고 했습니다. 요즘 취업 준비생분들이 다양한 경험을 가지고 계신 걸로 알고 있는데요. 꼭 많은 경험을 나열하기보다는 몇 가지 경험이라도 깊이 있게 풀어낸다면, 충분히 경쟁력 있는 자기소개서가 될 것이라 생각합니다.
 
### ✅ 포트폴리오
포트폴리오의 경우에는 **문제 상황과 해결 방법을 핵심만 간단히 정리**하려고 했습니다. 또 본인이 맡은 역할과 해당 페이지를 캡처해서 넣으면, 보는 분들이 한눈에 이해하기 좋을 것 같습니다.
 
### ✅ 면접 준비
면접 준비는 '갑자기 잘하게 되는 것'보다는 **꾸준한 연습이 중요**하다고 생각합니다. 저 역시 면접 처음에는 너무 떨려서 제대로 말도 못하고 떨어진 적이 있습니다. 하지만 여러 기업에 지원하면서 실전 면접을 계속 겪다 보니 긴장도 줄고 답변도 훨씬 자연스러워졌습니다.
 
면접에 대한 부담감이 있는 분들은 일단 모의 면접이라도 찾아서 경험해 보시면 좋을 것 같습니다. 만약 서류 지원에 대한 여유가 있으시다면 **여러 기업에 지원하면서 실제 면접을 통해 면접 역량을 키우는 것**도 좋은 방법이라 생각합니다. 확실히 집에서 연습할 때와 실제 면접 자리에 앉아 있을 때의 느낌은 완전히 다르거든요.
 
또 한 가지 중요한 건 **면접 준비의 깊이**라고 생각합니다. 회사 선택 이유가 뻔하거나 회사 아이템을 겉핥기식으로만 알고 있다면 좋은 인상을 주기 어렵습니다. **왜 이 회사를 가고 싶은지, 다른 곳이 아닌 꼭 이 회사여야 하는 이유를 나만의 스토리와 함께 어필**하는 것이 필요합니다. 어려운 일이겠지만 어떻게든 남들보다 더 간절하다는 점을 보여주는 것이 신입 채용에서는 굉장히 중요한 것 같습니다.
 
또한 회사의 서비스나 아이템도 단순히 이름만 아는 수준이 아니라, **동작 원리나 아키텍처 같은 부분도 꼼꼼하게 조사**해 간다면 면접에서 큰 도움이 될 것 같습니다.
 
 
## 취업에 성공하기까지의 과정은 어땠나요?
저는 취업을 준비하며 약 40~50개 기업에 지원했습니다. 주로 대기업과 중견기업 위주로 지원했고, 대학교 4학년 2학기부터 본격적으로 시작해 약 1년 정도 준비한 끝에 현재 회사에 합격할 수 있었습니다.
 
주변을 보면 '준비를 완벽히 한 뒤 지원해야지'라고 생각하는 경우가 많은데요. 저는 **꾸준히 지원하는 것이 훨씬 중요**하다고 생각합니다. **자기소개서나 면접은 실제로 경험해 보면서 점점 나아지기도 하고, 예상치 못한 곳에서 좋은 기회**를 잡을 수도 있기 때문입니다. 오히려 준비가 부족하다는 이유로 지원조차 하지 않는다면, 기회 자체를 놓칠 수밖에 없다고 생각합니다.
 
무엇보다 취업 준비에서 완벽한 준비란 없기 때문에, 계속해서 지원하며 기회를 만들어 가는 것이 가장 중요한 것 같아요.
 
 
## 면접에서 받았던 인상 깊은 질문은 무엇이었나요? 어떻게 대답을 하셨는지도 궁금합니다!
"연구원이란 어떤 것이라 생각하는가?"라는 질문이 가장 인상 깊었습니다.
보통 취업을 준비할 때, 우리가 지원하는 직무가 본질적으로 어떤 역할을 하고, 어떤 마음가짐을 가지고 임해야 하는지까지 깊게 고민하는 경우는 많지 않은 것 같습니다. 1차 역량 면접에서는 기술적인 질문이 주가 되겠지만, **2차 인성 면접에서는 직무에 대한 나의 생각과 입사 후 어떤 자세로 일할 것인지**를 묻는 경우가 많습니다. 또 입사 후 어떤 성장 방향을 그리고 있는지, 앞으로 어떤 업무를 해보고 싶은지 질문받을 수도 있으니 미리 고민해 보면 도움이 됩니다.
 
결국 면접은 사람과 사람 사이의 소통이기 때문에, 지원자의 진심은 분명히 전해진다고 생각합니다. 그래서 **해당 직무에 대해 진지하게 고민하고 나만의 생각을 준비**해 간다면, 면접관분들도 그런 태도를 긍정적으로 평가해 주실 것이라고 생각합니다.
 
 
## 프로그래머스 데브코스의 어떤 지원이 취업에 도움이 되었나요?
가장 큰 힘이 되었던 것은 **강사님의 적극적인 지원**이었습니다. 프론트엔드 3기를 맡아주신 이해성 강사님은 학생들의 취업을 진심으로 응원해 주셨습니다. **서류나 면접 일정이 있으면 먼저 상담을 제안해 주셨고, 넥스원 1차 PT 면접 준비 때는 발표 자료까지 직접 검토해 주시며 구체적인 피드백과 실질적인 팁**을 아낌없이 주셨습니다. 그 덕분에 자신감을 가지고 면접에 임할 수 있었고, 취업에도 큰 도움이 되었습니다.
 
이외에도 데브코스에서 수료생들을 대상으로 취업 특강을 꾸준히 진행해 주시는데, 이 부분 역시 취업 준비 과정에 큰 힘이 되었습니다.
 
 
## 실제 현업에 투입된 지금, 데브코스에서 배운 내용이 실무에 어떻게 도움이 되고 있나요?
실제 현업에서도 프론트엔드 관련 업무가 많기 때문에, 데브코스에서 진행한 강의와 프로젝트 경험이 큰 도움이 되었습니다. 개발 언어가 다를 수는 있지만 결국 같은 프론트엔드 영역이기에, **과정에서 배웠던 모든 내용들이 현업에서도 그대로 필요**했습니다.
 
또한 **데브코스에서 제공했던 특강들도 큰 도움**이 되었습니다. 특히 당근에서 근무하시는 김태희 강사님께서 "모든 IT 지식은 서로 연결되어 있고, 개발자는 끊임없이 지식을 확장해 나가야 한다"라고 말씀해 주신 것이 인상 깊었습니다. 이 특강을 계기로 프론트엔드뿐만 아니라 **네트워크, OS, 소프트웨어 공학 등 전반적인 소프트웨어 지식의 중요성을 깨닫게 되었고, 지금도 현업에서 큰 도움**이 되고 있습니다.
 
데브코스에서 학습한 것들을 바탕으로, 현재도 퇴근 후 부족한 부분을 보완하기 위해 꾸준히 공부를 이어가고 있습니다.
 
 
## 데브코스를 통해 기술 외적으로 성장한 부분이 있다면 무엇인가요?
데브코스에서는 여러 차례의 팀 프로젝트를 경험하며 **협업 역량과 커뮤니케이션 역량**을 크게 키울 수 있었습니다. 저는 우연히 팀 프로젝트마다 팀장을 맡게 되었는데요. 처음에는 부담스럽기도 했지만 조원들과 적극적으로 소통하며 프로젝트를 올바른 방향으로 이끌기 위해 노력했고, 그 결과 제 자신이 성장하는 것을 실감할 수 있었습니다.
 
또한 팀장을 맡으면서 팀원들에게 핵심만 논리적으로 전달하려고 노력하다 보니 자연스럽게 커뮤니케이션 역량이 강화되었고, 발표도 도맡아 하면서 많은 사람들 앞에서 말하는 연습이 되었습니다. 이러한 경험 덕분에 실제 면접이나 PT 면접에서도 자신 있게 말할 수 있었습니다.
 
 
## 지금 돌아보면, 데브코스 과정에서 "이건 좀 더 잘했으면 좋았겠다" 싶은 부분이 있을까요?
백엔드 수강생들과의 협업 프로젝트에서, 백엔드 부분에 조금 더 깊이 관심을 가지고 개발 관련 이야기를 나눠볼 걸 하는 아쉬움이 있습니다. 한 달 동안 매일 함께 협업할 수 있는 좋은 기회였던 만큼, 서로 더 많이 배우고 나눴다면 더 값진 경험이 되었을 것 같습니다.
 
프론트엔드 개발자라 하더라도 **다른 파트와 적극적으로 소통하고, 웹 서버가 어떻게 동작하며 서버의 응답이 어떻게 오는지 이해한다면 개발자로서 한 단계 더 성장**할 수 있을 것 같습니다.
 
 
## 현업에서 일해보니, 데브코스에서 배운 점 중 특히 도움이 된 부분은 무엇인가요? 아직 수강을 고민 중인 분들께 추천 한마디 부탁드립니다.
현업에서 일해보니 프로젝트에서 다양한 구성원들과 원활하게 협업하는 역량이 정말 중요하다는 것을 느꼈습니다. **데브코스는 팀 프로젝트 비중이 높아 이러한 협업 역량을 자연스럽게 키울 수 있다는 점이 큰 장점**이었습니다.
 
또한 팀 프로젝트를 진행하며 맡은 업무를 스스로 계획하고 일정에 맞게 수행하려고 노력했던 경험이, 기한이 철저히 지켜져야 하는 현업 환경에서도 큰 도움이 되고 있습니다.
 
 
## 마지막으로, 앞으로의 커리어 목표를 공유해 주세요!
**무인기 관련 소프트웨어 역량을 지속적으로 키워나갈 계획**입니다.
나중에는 제가 참여한 사업의 무기체계가 실전 배치까지 이뤄지는 모습을 꼭 보고 싶습니다!
 
 
 
*강의 운영 사정에 따라 세부 프로그램 내용은 변경될 수 있습니다.*
 
 
 
[![FE_배너.jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/ba385368-3bed-4d40-9892-6e07a1977cec/FE_%E1%84%87%E1%85%A2%E1%84%82%E1%85%A5.jpg)](https://school.programmers.co.kr/learn/courses/25243?utm_source=prgmblog&utm_medium=social&utm_campaign=school_25243_blog&utm_content=25243_banner)

[취업 인터뷰] 데브코스에서의 모든 경험이 커리어 도약의 발판이 되었어요 - 프론트엔드 3기 수료생 김재영 님

지난 겨울방학, 프로그래머스 데브코스에서 진행한 **'개발자 DNA 진단'** 이벤트! 기억하시나요? 🕵️‍♀️
 
"나는 어떤 포지션이 어울릴까?" "내 코딩 성향은 실무에서 어떻게 발현될까?"라는 고민을 가진 분들을 위해 준비했던 이벤트에 약 500명의 예비 개발자분들이 뜨거운 관심을 보여주셨습니다! 🙌
 
[![DEV-DNATEST-ig-img(1080x1350)-02.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/47ac3125-5769-4ead-a6f0-81be91575b93/DEV-DNATEST-ig-img%281080x1350%29-02.png)](https://smore.im/quiz/MR5AgKlzMW)
 
과연 가장 높은 비중을 차지한 '압도적 1위' DNA는 무엇이었을까요? 
지금 바로 그 결과를 공개합니다! 🥁
 
 
## 📊 개발자 DNA 진단 결과
![DEV-TEST-blog-img(630x550).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/21eb1b0e-12ce-4e92-88ab-f9934cdc7bc0/DEV-TEST-blog-img%28630x550%29.png)
 
이번 진단 결과에서 가장 눈에 띄는 점은 대규모 트래픽에도 흔들리지 않는 '탄탄한 설계'와 기술의 경계를 허무는 '성장형 해결'을 선호하는 분들이 많았다는 점입니다.
 
- 🛡️ 견고한 시스템 건축가 (백엔드): 28% (1위!)
- 🤖 혁신 주도형 솔루셔니스트 (생성형 AI 백엔드): 24% (공동 2위)
- 🏆 만능 해결사 올라운더 (풀스택): 24% (공동 2위)
- 🧭 비지니스 통찰가 (데이터 분석): 13%
- 🎨 디테일 장인 (프론트엔드): 11%
 
 
## 🔎 유형별 “찐” 모습 분석: 우리는 팀플할 때 이렇다!
개발자 업무에서 빠질 수 없는 게 협업이죠?
 
각 개발자 DNA가 실제 팀 프로젝트나 협업 상황에서 어떤 모습으로 보일지, 상황별로 더 자세히 살펴볼까요?
 
🛡️ **견고한 시스템 건축가 (백엔드 28%): 튼튼한 기초 위에 무너지지 않는 성을 쌓는 사람**
![DEV-TEST-blog-img(630x200)02-1.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/37c2725b-88b6-405e-84d3-4ec3b34de7a8/DEV-TEST-blog-img%28630x200%2902-1.png)
 
- 팀 회의할 때: "그 기능 넣으면 DB 구조 너무 복잡해지지 않을까요? 예외 케이스부터 생각해보죠." → 리스크 파악기
- 코드 짤 때: 변수명 하나도 '이게 최선인가?' 고민, 주석 없이도 술술 읽히는 클린 코드에 희열을 느낌
 
 👉 핵심 DNA: 보이지 않는 곳의 질서를 잡는 설계의 미학!

 
🤖 **혁신 주도형 솔루셔니스트 (생성형 AI 백엔드 24%): 도구를 지배하는 자, 남들 1시간 걸릴 일 10분 만에 끝냄**
![DEV-TEST-blog-img(630x200)02-1 (1).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/571bf0a6-d202-440c-bf56-205c1ec51fd9/DEV-TEST-blog-img%28630x200%2902-1%20%281%29.png)
 
- 팀 회의할 때: "그거 직접 짤 필요 있나요? AI API 연결하면 금방 구현될 것 같아요!" → 도구 활용 끝판왕
- 코드 짤 때: 프롬프트 한 줄로 반복 코드를 생성하고 남는 시간에 모델 성능을 튜닝하는 영리함
 
 👉 핵심 DNA: 단순 반복은 거부한다! 최신 기술로 생산성을 200% 올리는 스마트함

 
**🏆 만능 해결사 올라운더 (풀스택 24%): 앞뒤 가리지 않고 일단 서비스가 돌아가게 만드는 해결사**
![DEV-TEST-blog-img(630x200)02-1 (2).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/3ee70227-d7a9-4c47-82c7-b9cb791b561b/DEV-TEST-blog-img%28630x200%2902-1%20%282%29.png)
 
- 팀 회의할 때: "백엔드에서 이렇게 넘길 테니까, 프론트에서 이렇게 뿌리죠. 제가 확인할게요." → 최강 조율사
- 코드 짤 때: 서버 로직 짜다가 갑자기 CSS 수정 중. 화면과 서버를 종횡무진하며 전체 그림을 그려냄
 
 👉 핵심 DNA: 서비스의 탄생부터 완성까지 내 손으로 끝내는 장악력

 
**🧭 비지니스 통찰가 (데이터 분석 13%): 근거 없는 추측은 거부한다, 오직 데이터로 말하는 사람**
![DEV-TEST-blog-img(630x200)02-1 (3).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/b6cead85-a193-4041-8518-da309f6e85a5/DEV-TEST-blog-img%28630x200%2902-1%20%283%29.png)
 
- 팀 회의할 때: "제 생각엔 지난주 유입 데이터를 보니까 이 기능이 더 시급해 보여요." → 팩트 폭격기
- 코드 짤 때: 코드 한 줄 짜고 결과 그래프 확인, 또 한 줄 짜고 데이터 분포 확인하며 신중하게 전진함
 
 👉 핵심 DNA: 막연한 안개 속에서 '데이터'라는 길을 찾아내는 탐험가 정신

 
**🎨 디테일 장인 (프론트엔드 11%): 내가 만든 코드가 누군가에게 기쁨이 되길 바라는 디테일러**
![DEV-TEST-blog-img(630x200)02-1 (4).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/c6a54a91-beb9-4f8a-baad-2822d00e72bc/DEV-TEST-blog-img%28630x200%2902-1%20%284%29.png)
 
- 팀 회의할 때: "기능도 중요한데, 여기서 버튼 누를 때 반응이 없으면 답답해하지 않을까요?" → 사용자 빙의
- 코드 짤 때: 0.1px의 오차도 허용 못 함. 애니메이션이 자연스럽게 넘어갈 때까지 무한 수정 중
 
 👉 핵심 DNA: 세상과 소통하는 가장 앞단에서 감동을 주는 섬세함

 
예비 개발자분들이 보여주신 DNA는 제각각이었지만, 분석 결과 흥미로운 공통점을 발견할 수 있었습니다. 
 
내가 가진 성향을 실제 시장이 원하는 '직무 역량'으로 어떻게 치환하느냐입니다. 
 
탄탄한 논리력을 가진 백엔드 개발자도, 트렌드에 민감한 AI 개발자도 결국은 실전 프로젝트를 통해 그 DNA를 증명해야 하기 때문이죠
 
 
## 🚀 진단 결과는 시작일 뿐, 이제 '진짜 실력'으로!
여러분은 어떤 유형에 속하시나요? 결과가 내가 원하던 방향과 일치하나요?
 
DNA 진단 결과는 여러분의 **잠재력**을 보여주는 지도일 뿐입니다. 이 지도를 따라 실제 목적지(취업)까지 가기 위해서는 **실무 프로젝트 경험**이라는 연료가 필요하죠.
 
DNA가 '확신'이 되는 곳, 프로그래머스 데브코스에서 함께 성장해요!
 
[![DEV-AIBE-coding-test-02(1456x180) (5).jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/b134a892-62bd-4acf-9850-8bf1993c6de5/DEV-AIBE-coding-test-02%281456x180%29%20%285%29.jpg)](https://school.programmers.co.kr/learn/courses/25630?utm_source=instagram&utm_medium=social&utm_campaign=school_25630_sales&utm_content=blog_banner_13333)

[데브코스 이벤트] 개발자 DNA 진단 결과 공개! 예비 개발자들이 가장 많이 가진 성향은?

2026년 설날에도 데브코스와 함께 달려요🐴
여러분의 든든한 러닝 메이트가 되어 드릴게요.

 
**이벤트 기간에만 수강 가능!** 
누구나 쉽게 들을 수 있는 AI 강의를 **무료로** 받아가세요!
 
![PRGMS-NEWYEAR-EVENT-ig-img(1080x1350)-01.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/dd5ff166-7716-47f3-99a8-d6817d4138d2/PRGMS-NEWYEAR-EVENT-ig-img%281080x1350%29-01.png)
 
 
## 📌 이벤트 기간
**2026.02.04(수) ~ 2026.02.22(일) 23시 59분**

## 🎁 이벤트 참여 방법
1️⃣ **이벤트 신청 구글폼 작성**
👉 [**이벤트 신청 바로가기**](https://forms.gle/fZQAakkrvUPe3Kvu9)
 
2️⃣ **이메일로 강의 링크 자동 발송**
구글폼에 입력한 이메일 주소로 무료 수강 링크가 자동으로 발송됩니다.
*(구글폼 제출 완료 링크에서도 확인 가능합니다.)*
 
💡**끝까지 데브코스와 완주한 분들** 주목!
 아래 링크를 통해 **수강 완료 인증하면 보너스 AI 강의 제공!** (이벤트 종료 후)
 👉 **[수강 완료 인증하러 가기](https://forms.gle/5Tb7G9Ch2GoUq72P8)**
 
 
올 한 해의 성장을 시작하는 지금, 데브코스와 함께해요! 🚀

[데브코스 이벤트] 기간 한정! AI 강의 무료로 받고, 설날에도 데브코스와 함께 달려봐요!

## 나만의 포트폴리오 사이트 키우기 with Google AI Studio
상반기 취업을 위해 지금 꼭 알아야 할 바이브 코딩!
﻿프로그래머스 데브코스와 길벗이 포트폴리오 사이트 만들기 무료 특강을 준비했습니다.
 
**비전공자도 1시간 만에 포트폴리오 사이트 결과물**을 만들 수 있도록 가장 쉬운 방법으로 처음부터 끝까지 설명해드립니다.
 
![webposter1.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/bfaaf77e-7721-4a9f-acbf-16119deb6563/webposter1.png)
 
코딩을 단 한번도 해보지 않아도 괜찮습니다.
 
✅ 취업에 당장 써먹을 포트폴리오 사이트가 필요하신 분
✅ 단순한 PPT 포트폴리오에서 벗어나고 싶은 분
✅ 개인 브랜딩을 시작하고 싶은 20~30대 취준생
✅ AI 활용 경험이 필요한 비전공자
 
모두 부담없이 따라올 수 있도록 바이브 코딩을 가장 쉽게 설명해드리겠습니다.
 
### 특강 일시
- 일시: **2026년 4월 8일(수) 19:00 - 21:00** (총 2시간)
- 장소: 온라인 LIVE (Zoom 웨비나)

*본 특강은 무료로 진행됩니다. 

 
### 강사 소개
🧑‍🏫 **강성규** 강사

현) 1인 기업가 (인디 해커(Indie Hacker))
전) 헬스케어·핀테크 스타트업 프론트엔드 리드 개발자
전) 삼성전자 소프트웨어 엔지니어

바이브 코딩 입문서 <커서xAI로 완성하는 나만의 웹 서비스> 저자
 
### 타임테이블
19:00 - 19:05 ㅣ 오프닝
19:05 - 20:10 ㅣ **1부: 취업을 위한 개인 브랜딩 사이트 만들기**
20:10 - 20:40 ㅣ **2부: 프로그래머스가 분석한 2025 개발자 취업 리포트**
20:40 - 21:00 ㅣ 클로징 이벤트 안내
 
### 참여 혜택
![스크린샷 2026-03-20 오전 10.11.06.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/2de73e46-7f8a-4076-8fd0-fed58d8cec75/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202026-03-20%20%E1%84%8B%E1%85%A9%E1%84%8C%E1%85%A5%E1%86%AB%2010.11.06.png)
 
만족도 조사 우수 참여자 대상으로 **<커서xAI로 완성하는 나만의 웹 서비스> 도서 무료 증정!**
 
이번 특강을 통해 포트폴리오를 단순한 문서에서 '**나만의 브랜딩 공간**'으로 바꿔보세요!

 
### 👉 [특강 신청하기](https://www.programmers.co.kr/pages/gilbut-2026#?utm_source=prgmblog&utm_medium=social&utm_campaign=school_portfolio&utm_content=poster)

 
[![codingtest-tablet(728x90).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/f3d63d3b-6e9b-413b-9111-0a74e2ecc964/codingtest-tablet%28728x90%29.png)](https://www.programmers.co.kr/pages/gilbut-2026#?utm_source=prgmblog&utm_medium=social&utm_campaign=school_portfolio&utm_content=poster)

[데브코스x길벗] 나만의 포트폴리오 사이트 만들기 특강

요즘 대세라는 클로드 코드, 아직 시작하지 못하신 분 있나요?
 
관심은 있지만 설치부터 어렵게 느껴지거나, 어디서부터 배워야 할지 막막했다면 주목해 주세요.
바이브 코딩 입문부터 실무 활용까지 단계별로 익힐 수 있는 길벗출판사의 신간 《**클로드 코드 제대로 시작하기**》를 추천드립니다!
 
## 클로드 코드 활용법, 이 책 하나로 끝내세요!
![\[프로그래머스\]클로드 코드 제대로 시작하기_블로그.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/b86b4697-61bb-4fea-9925-8f1bcd92a7fb/%5B%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%84%80%E1%85%B3%E1%84%85%E1%85%A2%E1%84%86%E1%85%A5%E1%84%89%E1%85%B3%5D%E1%84%8F%E1%85%B3%E1%86%AF%E1%84%85%E1%85%A9%E1%84%83%E1%85%B3%20%E1%84%8F%E1%85%A9%E1%84%83%E1%85%B3%20%E1%84%8C%E1%85%A6%E1%84%83%E1%85%A2%E1%84%85%E1%85%A9%20%E1%84%89%E1%85%B5%E1%84%8C%E1%85%A1%E1%86%A8%E1%84%92%E1%85%A1%E1%84%80%E1%85%B5_%E1%84%87%E1%85%B3%E1%86%AF%E1%84%85%E1%85%A9%E1%84%80%E1%85%B3.png)


 <div style="border-radius: 4px;padding:22px 20px; background: #F5F5F5; border: 1px solid #D6D6D6;">✔️ 최신 클로드 코드 기능 완벽 반영! ✔️ 바이브 코딩부터 숏폼 자동화, AI 비서, SDD, 하네스 엔지니어링까지 ✔️ 순한맛 바이브 코딩으로 시작해 매운맛 하네스 엔지니어링으로 완성한다!</div>

 
 
### 《클로드 코드 제대로 시작하기》
* IT·모바일 분야 1위 베스트셀러 《면접을 위한 CS 전공지식 노트》 저자와 현직 IT 대기업 개발자가 함께 집필했습니다.
* 바이브 코딩 경험이 없다면? 순한맛부터 차근차근 단계별로 학습해 보세요.
* 바이브 코딩 경험이 있거나 입문을 끝냈다면? 매운맛으로 한 단계 레벨업해 보세요.
* 저자들이 직접 경험한 노하우와 시행착오도 숨김없이 담았습니다.

 
 
💡 공부하다 막히는 부분이 있다면? 
저자가 직접 답변해 주는 오픈채팅방에 질문해 보세요!
🔗 **[오픈채팅방 바로가기](https://open.kakao.com/o/goXNMFBg)**

 
 
## 이런 분들께 추천드려요
* 클로드 코드, 들어는 봤지만 시작이 막막했던 입문자라면?
👉 기초 설치부터 심화 응용까지 이 책 한 권으로 끝내보세요!
* 이미 ChatGPT나 커서 같은 생성형 AI 도구를 활용해 본 바이브 코딩 경험자라면?
👉 터미널 에이전트가 열어주는 새로운 신세계를 경험해 보세요!
* 클로드 코드를 더 깊이 활용하고 싶은 현업 개발자라면?
👉 스펙 주도 개발, 하네스 엔지니어링 등 실무 밀착형 테크닉을 만나보세요!

 
📚[**《클로드 코드 제대로 시작하기》 보러 가기**](https://gilbut.co/c/26079883ss)

[길벗출판사] 클로드 코드 제대로 시작하기

"문송합니다"를 지나 이제는 "컴송합니다"라는 말까지 등장한 시대.
AI가 코드를 대신 짜주는 세상에서, 개발자는 과연 어떤 존재로 남게 될까요?
 
지금 우리는 개발자의 종말이 아니라, '개발'의 정의가 바뀌는 거대한 전환점 앞에 서 있습니다.
AI 시대에 더욱 빛나는 개발자의 핵심 역량과 대체 불가능한 인재로 성장하는 방법을 데이터 사이언티스트 정경문 님의 아티클에서 확인해 보세요!
 
 
## 1. AI 시대, 개발이란 무엇인가?
#### 💬 문송합니다? 컴송합니다.
오늘 아침 회사 후배님이 제게 흥미로운 신조어를 하나 던졌습니다. 바로 "컴송하다"라는 말입니다. 불과 몇 년 전, 취업시장의 높은 벽 앞에서 인문계 학생들이 자조 섞인 목소리로 외치던 '문송합니다(문과라서 죄송합니다)'가 이제는 기술의 심장부인 컴퓨터공학과 학생들 사이에서 "컴퓨터공학과라서 죄송합니다"라는 농담으로 번지고 있는 것입니다.
 
인공지능이 눈 깜짝할 사이에 수백 줄의 코드를 짜내고 복잡한 알고리즘을 최적화하는 모습을 보며, 정작 4년 동안 밤을 새워 파이썬, C언어와 자바를 공부한 노력이 물거품이 되는 건 아닌지 불안해하는 마음이 담겨있습니다.
 
### 기술의 발전에 따른 의미와 역할의 진화
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/30e41063-4461-4c22-ad51-a1724bbe29d6/image.png)
 
하지만 지금은 개발자의 종말이 아니라, **개발이라는 행위의 정의가 완전히 뒤바뀌는 거대한 변곡점**일 뿐입니다. '자동차(Car)'라는 단어를 예로 들어볼까요?. 역사를 돌이켜보면, 1800년대에 누군가 ‘차’를 탄다고 했다면 그것은 당연히 말이 끄는 ‘마차’를 의미했습니다. 증기기관이 발명된 후에는 거대한 ‘기차’를 떠올렸고, 헨리 포드의 대량 생산 이후에는 ‘내연기관’ 자동차를, 그리고 지금 우리는 엔진 소리 없이 달리는’ 전기차’도 차라고 부릅니다. 
 
단어는 동일하게 유지되었지만, 기술의 발전이 의미를 진화시켰습니다. '개발' 또한 마찬가지입니다. 문법과 라이브러리를 외워 타이핑하는 코더(Coder)의 시대는 저물고 있지만, **AI를 활용해 기술을 조율하고 비즈니스 가치를 설계하는 진정한 의미의 디벨로퍼**(**Developer**)에게는 역사상 가장 찬란한 태양이 떠오르고 있는 것입니다. 혹자는 코딩을 기반으로 AI를 꿰뚫어 보고 있는 능력은 무엇이든 만들어낼 수 있는, ‘창조주, 신이 된 기분이다’ 라고까지 말합니다.
 
#### 💬 역사상 유례없이 개인에게 기회가 열린 세상
세계적인 인공지능의 석학이자 구글 브레인의 설립자 앤드류 응(Andrew Ng)은 이렇게 말합니다. “역사상 유례없이 개인에게 기회가 열린 세상이다.”이라는 말은 결코 과장이 아닙니다.
 
최근 제가 만난 한 스타트업 대표님은 AI 덕분에 코딩의 벽을 완전히 넘어서게 된 후, 전담 개발자 없이도 하루에 수십 건씩 깃허브(GitHub)에 커밋을 올리며 서비스를 직접 고도화하고 있었습니다. 그분은 AI가 때때로 사소한 오류를 범하기도 하지만, 그동안 고용했던 그 어떤 개발자보다 똑똑하고, 지치지 않으며, 무엇보다 압도적으로 저렴하다는 사실에 경탄을 금치 못했습니다.
 
전 세계를 여행다니며, SaaS 서비스를 만드는 1인 개발자 피터 레벨스(Pieter Levels)가 대표적이죠. 'Remote OK'라는 원격 근무 구인구직 사이트를 비롯해 연간 30억이상 매출을 올리는 기업가이기도 합니다. 그가 AI 바이브 코딩으로 3시간 만에 만든 게임은 출시 한 달 만에 월 1억 원 수익을 돌파하기도 했습니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/4f2273f3-75f4-44b5-9f0d-dde5dc6370f9/image.png)
 
지금 세상은 초거대 시장에서 “**초니치**” **시장**으로 이동 중입니다. 니치(niche)는 특정분야의 작은 시장을 의미하는데요. 초(Ultra)는 그 안에서도 더 세분화한 시장입니다. 예를 드면, 링크드인 전용 프로필 사진 생성 서비스, Next.js 개발자용 이미지 생성 AI 같은 것들입니다.
 
이처럼 개발 분야에서도 과거에는 자본과 인력이 성패를 결정했다면, **이제는 개인의 아이디어와 실행력, 그리고 AI가 가장 강력한 무기가 되었습니다**. 수백만 원의 서버 비용이나 수개월의 개발 기간을 걱정할 필요 없이, 일단 아이디어를 던지고 AI와 함께 결과물을 확인하며 수정해 나가는 이 과정 자체가 지금 시대를 살아가는 가장 현명한 개발 전략이 되었습니다.
 
 
## 2. AI 개발자의 핵심 역량
#### 💬 천재 개발자 1명 + AI 에이전트 >> 기존방식 개발자 10명
상황이 이렇다 보니, 코딩을 할 줄 아는 기획자가 바이브 코딩으로, 또는 개발자 1명이 거대 소프트웨어사를 무너뜨리는 현상도 생겼습니다. 월 구독료 기반의 SaaS(Software as a Service, 서비스형 소프트웨어)와 종말(Apocalypse)의 합성어인 '사스포칼립스(SaaSpocalypse) 입니다.
 
실리콘 밸리에서는 개발자가 한 명만 투입되는 프로젝트가 매우 늘었습니다. 반대로 보면, 단순 구현 능력만 가진 개발자 대신 서비스의 본질을 꿰뚫고 기획적 마인드를 장착한 ‘전략가형 개발자’가 절실해졌다는 신호입니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/260a306f-ad0b-42e9-a894-bcfad98da384/image.png)
 
코드를 짜는 기술보다 사용자가 겪는 불편함의 지점을 정확히 포착하고 이를 어떤 아키텍처로 해결할지 설계하는 능력, 사람들이 무엇에 행복감과 즐거움을 느끼는지를 캐치하고 서비스화할 수 있는 기획력이 연봉을 결정하는 잣대가 된 것입니다.
 
이제 더 이상 에러 디버깅과 씨름할 것이 아니라, AI라는 초고속 제트기에 올라타야 합니다. “기획이 곧 개발이고, 개발이 곧 비즈니스가 되는 경계의 붕괴”를 목격하고 있는 지금, 해결해야 할 문제의 본질에 더 깊이 다가가야 합니다. 이러한 변화는 코딩이라는 전문 기술을 대중화시킴과 동시에, 인간만이 할 수 있는 ‘의사결정’과 ‘창의적 발상’의 가치를 극한으로 끌어올리고 있습니다. 이러한 시대에 과연 우리는 어떤 역량을 갖추어야 할까 곰곰이 생각해보는 시간이 필요합니다.
 
### 1️⃣ AI를 활용해서 AI를 만드는 시대, 도구를 잘 활용하라.
AI를 개발하는 개발자에게 가장 중요한 것은 역설적으로 AI 도구를 잘 쓰는 능력입니다. "지금 최고의 도구는 무엇인가?"라는 질문에 자신 있게 답할 수 없다면, 여러분은 이미 도태의 길에 들어서고 있는지도 모릅니다.
 
현재 AI 코딩 스택의 왕좌를 차지하고 있는 ‘커서(Cursor)’와 ‘클로드 코드(Claude Code)’의 조합을 보면 그 발전 속도가 실로 경이로울 정도여서, 한 번의 업데이트만으로도 어제의 상식이 오늘의 구식 기술이 되어버리곤 합니다. 이 바닥의 왕좌는 우리가 적응할 틈도 주지 않고 미친 속도로 교체되고 있으며, 특정 도구에 대한 충성심보다는 상황에 맞는 최적의 솔루션을 즉각 도입하는 기민함이 생존을 결정합니다.
 
#### 💬 빠른 기술발전 속도는 편리함과 현기증을 동시에 준다.
저 역시 현장에서 동료들이 느끼는 기술발전 속도에 대한 피로감을 잘 알고 있지만, 변화를 거부하는 순간, 기술의 파도가 우리를 덮치게 됩니다. 바쁜 업무 때문에 새로운 기술을 공부할 시간이 없다는 핑계는 이제 통하지 않으며, 오히려 **최신 기술을 실제 프로젝트에 과감히 던져보는 것만이 가장 효율적인 학습 루트**가 됩니다. 기술을 배우고 나서 프로젝트를 하는 것이 아니라, 프로젝트를 하면서 기술을 활용하고 배울 수 있다는 역발상이 필요합니다. 결국 이 시대에 여러분을 대체 불가능한 존재로 만들어 줄 유일한 생존 열쇠는, 끊임없는 학습능력과 학습 자체를 즐기는 태도에 있습니다.
 
#### 💬 모든 사람은 자신의 지능 수준에 걸맞은 AI를 갖게 될 것이다 (Every person will get the AI their level of intelligence deserves)
그렇다고 해서 도구의 활용법만 익히는 것으로 충분할까요? 절대 그렇지 않습니다. AI가 코드를 다 짜준다는데 개발자들은 오히려 더 바빠졌다고 말합니다. 결국 바이브 코딩으로 생성된 코드를 리뷰, 검증 리팩토링 하는 단계에 더 시간을 쏟게 됩니다.
 
“**모든 사람은 자신의 지능 수준에 걸맞은 AI를 갖게 될 것이다.**” 이 말, 어떻게 생각하시나요? 내가 물어본 질문에 대한 답변을 이해할 수 없다면? AI가 쏟아내는 수만 줄의 코드는 겉보기엔 화려해 보일지 모르나, 그것을 다루는 사람의 논리 구조와 알고리즘에 대한 이해가 부족하다면 결국 그 결과물은 모래 위에 쌓은 성이나 아이들의 장난감 수준에 머물게 됩니다. AI는 우리가 던지는 질문의 깊이만큼만 답변을 내놓기 때문에, **AI 개발자는 자신이 활용하는 도구의 작동 원리와 AI 서비스의 밑단에 흐르는 기술적 맥락을 정확히 꿰뚫고, 사용자에게 설명할 수 있어야 합니다**. 
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/45829594-eda0-4b6a-9bc8-360f379c040e/image.png)
 
단순히 프롬프트를 입력하는 수준을 넘어 **딥러닝의 기본 원리부터 LLM의 구조, RAG(검색 증강 생성)의 활용, 그리고 최근 각광받는 에이전틱 AI(Agentic AI)의 흐름까지** 폭넓은 학습이 뒷받침되어야 합니다. 또한 백엔드와 프론트엔드의 유기적인 연결, 데이터베이스의 효율적인 아키텍처 설계 능력이 없다면 AI는 결코 완성도 높은 프로덕트를 만들어줄 수 없습니다. 간단한 코드를 디버깅하는데만 수일이 걸릴 수 있습니다.
 
최신 프레임워크와 라이브러리가 쏟아지는 환경을 두려워할 것이 아니라, 이를 지능형 코딩 블록으로 인식하고 자유자재로 조합할 수 있는 기본기를 닦아야 합니다.
 
### 2️⃣ 어떻게 시킬 것인가? 아키텍처 설계 역량을 길러라.
현업에서 수많은 프로젝트를 수행하며 깨달은 사실은, 정말 뛰어난 개발자와 평범한 개발자를 가르는 결정적 한 끗은 바로 ‘아키텍처 설계 역량’에 있다는 점입니다. 코드는 AI가 대신 써줄 수 있지만, **그 코드들이 모여 하나의 견고한 시스템을 이룰 수 있도록 지도를 그리는 일은 여전히 인간의 고유한 영역**이기 때문입니다.
 
실제로 제가 참여했던 어떤 프로젝트는 3개월 내내 아키텍처 설계 단계에서 갈피를 잡지 못하고 헤맨 적이 있는데, 이는 ‘요구사항’과 ‘기능 구현’, 그리고 ‘품질’이라는 세 마리 토끼를 어떻게 조화시킬지에 대한 역량이 부족했기 때문입니다. 
 
잘 설계된 시스템은 마치 치밀한 도시 계획하에 건설된 신도시와 같아서 도로가 정돈되어 있고, 인프라가 미래를 내다보고 미리 준비되어 있으며, 운영 비용이 최소화되도록 설계되어 있습니다. 반대로 구조적 고민 없이 AI가 주는 코드만 그때그때 붙여 넣은 시스템은 구도심의 얽힌 전선처럼 복잡해져서, 작은 트래픽 변화에도 쉽게 장애가 발생하고 유지보수 비용이 기하급수적으로 늘어나는 재앙을 초래합니다. 
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/04b492e3-ccbe-4377-bf84-a6f6792a266b/image.png)
 
좋은 개발자는 키보드에 손을 올리기 전에 먼저 화이트보드 앞에서 시스템의 구조를 치열하게 고민하는 사람이며, 전체적인 데이터 파이프라인과 서비스 간의 의존성을 설계하는 아키텍트여야 합니다. 고객의 막연한 요구사항을 구체적인 서비스 기능으로 분해하고, 이를 다시 기술적 아키텍처로 변환하는 과정은 마치 복잡한 퍼즐을 만드는 것과 같습니다. 이러한 설계도를 그리고 AI가 알아들을 수 있도록 분할하여 프롬프트를 제공할 수 있는 개발자가 필요합니다.
 
이제, 개발자의 실력과 경험은 코딩 실력이 아니라, **시스템 전체를 조망하는 아키텍처의 안목**에서 나옵니다.
 
### 3️⃣ 정보처리 기술의 가치는 하락하고, 대인관계의 협업 역량의 가치는 상승한다.
AI 서비스를 개발하는데 역설적으로 더욱 중요해지는 역량은 프로그래밍 언어가 아닌, 우리가 일상적으로 사용하는 ‘자연어’를 얼마나 논리적으로 구사하느냐입니다. 예전에는 C++이나 파이썬의 복잡한 문법을 얼마나 많이 외우느냐가 경쟁력이었다면, 이제는 **도메인 전문가와 소통하며, 문제를 정확하게 정의하고, AI 개발을 설명할 수 있으며, 요구사항을 명확한 언어로 설명하는 능력**이 훨씬 더 중요해졌습니다. 
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/eb556dca-edfe-42dc-9609-4eaf40640ac7/image.png)
 
스탠퍼드 대학교의 연구에 따르면, AI 에이전트와 함께 일하는 미래의 업무 환경에서는 단순 정보처리 기술보다 대인관계 역량과 조직 내 협업 역량이 높은 직무의 가치가 급격히 상승할 것으로 보고 있습니다. 결국 AI 시대의 개발자는 차가운 기계와 소통하는 기술자이기 이전에, 뜨거운 가슴을 가진 인간들과 소통하고 공감하는 커뮤니케이터여야 합니다.
 
#### 💬 여러분이 같이 일하고 싶은 개발자는 누구입니까?
여러분은 누구와 함께 일하고 싶으세요? 소통이 잘 되는 개발자, 풀스택적 사고를 가진 개발자, 그리고 새로운 도구를 두려움 없이 수용하는 유연한 태도를 가진 사람인가요?
 
네, 여러분이 원하는 바로 그 사람이 직접 되어야 합니다. 요즘 개발자는 단순히 코드를 빨리 짜는 사람이 아니라, 사용자와 고객의 의도를 정확히 이해하고, 딱 맞는 AI 애플리케이션을 제시하는 사람 아닐까요? 실제 실리콘밸리에서 가장 앞서나가는 개발자들은 최고의 코딩 실력을 자랑하는 괴짜들이 아니라, **사용자의 불편함에 깊이 공감하고 그 문제를 해결하기 위해 끊임없이 대화하는 사람들**입니다.
 
사람 대하는 일이 서툴고 불편한 사람들은 AI에게 대체될 수밖에 없습니다. 기술은 인간을 돕기 위해 존재하며, 그 기술을 완성하는 마지막 퍼즐 조각은 언제나 인간다운 공감입니다. 진정한 실력자는 복잡한 코드를 읊는 사람이 아니라, 복잡한 문제를 쉬운 언어로 풀어내고 팀원들의 마음을 움직여 하나의 목표로 나아가게 만드는 사람임을 잊지 말아야 합니다.
 
## 3. 마무리하며
우리는 지금 인류 역사상 코딩을 할 수 있는 개인에게 가장 거대한 기회가 주어진 축복 받은 시대를 지나고 있습니다. “컴송합니다”라는 농담 속에 숨은 막연한 공포에 굴복하기에는, 우리 앞에 놓인 도구들이 너무나 강력하고 가능성이 무궁무진합니다.
 
최신 도구를 내 몸처럼 부리는 적응력, AI가 내놓은 결과물의 결함을 찾아내고 고도화할 수 있는 깊이 있는 기술적 이해, 그리고 전체 시스템의 뼈대를 세우는 탄탄한 아키텍처 역량만 있다면 AI는 여러분의 자리를 뺏는 약탈자가 아니라 여러분의 상상력을 실현해 주는 가장 충실한 조력자가 될 것입니다. 여기에 사용자의 마음을 읽는 공감 능력과 팀을 하나로 묶는 소통의 기술을 더한다면, 여러분은 대체 불가능한 ‘인간다운 개발자’로서 독보적인 가치를 증명해낼 수 있습니다.
 
결국 AI 개발자의 본질은 단순히 ML/DL/LLM 코드를 생성하는 기술자가 아니라, 세상의 문제를 해결하고 새로운 가치를 창출하는 ‘가치 창조자(Value Creator)’라는 사실을 명심하세요.
 
“**세상은 더 이상 코드를 타이핑할 줄 아는 사람을 필요로 하지 않습니다. 하지만 기술을 도구 삼아 세상의 문제를 해결하고, 가치를 제공해 줄 아이디어가 있는 당신을 간절히 기다리고 있습니다**.” 
 
변화를 두려워하지 말고, AI라는 날개를 달고 여러분만의 위대한 서비스를 향해 비상하시길 진심으로 응원합니다.
 
 
### 📌 함께 읽으면 좋은 글
* [프로그래머의 성장관점에서 바라본 CES 2026](https://community.programmers.co.kr/post/13168?utm_source=&utm_medium=&utm_campaign=&utm_content=data_13168)
* [온톨로지와 Agentic AI 진화](https://community.programmers.co.kr/post/13006?utm_source=&utm_medium=&utm_campaign=&utm_content=data_13006)
* [LLM의 생성(Generation) 성능을 높이는 실무 전략](https://community.programmers.co.kr/post/12739?utm_source=&utm_medium=&utm_campaign=&utm_content=data_12739)
 
 

![정경문 작가님 프로필 카드.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/5e64c3af-26b1-4b64-9a3f-b5ec14236695/%E1%84%8C%E1%85%A5%E1%86%BC%E1%84%80%E1%85%A7%E1%86%BC%E1%84%86%E1%85%AE%E1%86%AB%20%E1%84%8C%E1%85%A1%E1%86%A8%E1%84%80%E1%85%A1%E1%84%82%E1%85%B5%E1%86%B7%20%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%84%91%E1%85%B5%E1%86%AF%20%E1%84%8F%E1%85%A1%E1%84%83%E1%85%B3.png)

AI 개발자의 역량: 위대한 개인의 탄생

안녕하세요. 저는 프로그래머스에서 평가 서비스를 담당하고 있는 4년차 백엔드 개발자 에이다(Ada) 입니다. 앞서 "그렙에서는 어떻게 알파 서버를 운용할까?"라는 글에서 처음 인사를 드렸는데요. 안정적인 서비스 배포를 위해 프로그래머스에서 알파 서버를 활용하는 방법을 소개했습니다.

이번에는 "그렙 개발자는 어떻게 개발할까?"라는 주제로 이야기를 나눠보고자 합니다. 특히 **협업과 배포 과정에서 발생하는 문제를 어떻게 해결했는지, TDD(Test-Driven Development)를 중심으로** 소개 드리겠습니다.
 
# 협업과 배포 과정에서의 문제점
## 1. 협업 중 발생하는 피로감
그렙에서는 대부분의 작업이 기획자, 디자이너, 개발자가 협업하는 과정에서 이루어집니다. 하지만 이런 협업은 예상치 못한 문제를 동반하기도 합니다. 예를 들어, 홈페이지 메인 화면에 프로그래머스 마스코트인 "머쓱이" 캐릭터를 추가하는 작업을 한다고 가정해 보겠습니다.
 
```
기획자: 이번에 머쓱이 캐릭터가 리뉴얼되었는데, 이를 홍보할 겸 유저 상세 페이지에 머쓱이를 넣어 이벤트를 진행하면 어떨까요?
디자이너: 좋습니다! 머쓱이를 어느 페이지에서 홍보하면 될까요?
기획자: 유저 눈에 잘 띄도록 메인 페이지에 배치하는 것이 좋을 것 같아요. 그리고 프로필 사진을 머쓱이로 바꾼 사람 중 일부에게 쿠폰을 지급하면 어떨까요?
개발자: 좋은 아이디어네요!
```

*며칠이 지난 후...*

```
디자이너: 머쓱이 이미지가 차지하는 부분이 너무 작아요. 픽셀을 조금만 더 수정하는 것이 좋을 것 같아요.
기획자: 그리고 프로필 사진을 머쓱이로 바꾼 유저들에게 쿠폰을 지급하기로 했는데, 이미 머쓱이 이미지를 프로필 사진으로 해두었던 유저들도 포함해야 될 것 같아요.
개발자: ...(다시 작업해야 하네..)
```
 
이처럼 협업하는 과정에서 기획이 변경되거나 커뮤니케이션의 문제로 개발 작업이 지연될 수 있습니다. 이러한 일이 계속해서 발생한다면 불필요한 피로감까지 느낄 수 있겠죠. 이 문제를 어떻게 해결하면 좋을까요?

## 2. 배포 시의 불안감
개발자라면 누구나 프로덕션 배포가 긴장되는 순간일 겁니다. 혹시 이러한 경험을 해보신 적이 있으신가요?
 
```
개발자 A: 개발 완료했고, 알파서버에 배포해놓았어요. 확인 부탁드립니다.
기획자: 이상 없는 것 같아요!
디자이너: 저도 좋은 것 같습니다.
개발자 A: 확인 감사합니다.
```

*하지만 배포 직전...*

```
개발자 A: 혹시 내가 놓친 건 없겠지...? 프로덕션 배포했다가 버그가 발생하지는 않겠지?
```
 
프로젝트를 진행하면서 충분히 QA를 했음에도 불구하고 막상 배포하기 직전에 불안감이 엄습해오기도 했습니다. 경험이 쌓이면 괜찮아지려나 했지만 시간이 지날수록 서비스와 관련하여 더욱 밀접한 작업들을 담당하게 되면서, 배포 직전 불안감은 점점 커져만 갔습니다. 이를 해결하기 위한 방법이 있을까요?

# 해결책: TDD(Test-Driven Development) 도입
앞선 두 가지 문제점을 정리해 보면 다음과 같습니다.
* 개발 중간에 기획이 바뀌거나 기획자, 디자이너와 싱크가 맞지 않아 다시 작업하는 경우가 빈번하다.
* 프로덕션에 배포할 때마다 불안하다.

저는 위의 두 가지 문제에 대한 해결책을 동료 개발자로부터 찾을 수 있었는데요. 바로 TDD(Test-Driven Development)입니다. 

## TDD란?
**TDD**(**Test-Driven Development**)에 대해서는 대부분의 개발자들이 알고 있는 개념이지만, 모르시는 분들을 위해 간략히 설명드리도록 하겠습니다.

TDD는 동작하는 코드를 작성하기 이전에 테스트를 먼저 작성하고, 그 테스트를 통과하는 코드를 작성함으로써 테스트된 동작을 하는 코드를 얻는 개발 방법입니다. 다음 그림을 통해 설명을 돕겠습니다.

![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/090839ab-c9ab-4426-b117-6d708f169fe6/image.png)
[이미지 출처](https://velog.io/@park0eun/TDD%ED%85%8C%EC%8A%A4%ED%8A%B8-%EC%A3%BC%EB%8F%84-%EA%B0%9C%EB%B0%9C-%ED%85%8C%EC%8A%A4%ED%8A%B8%EC%BD%94%EB%93%9C%EC%97%90-%EB%8C%80%ED%95%B4-%EC%95%8C%EC%95%84%EB%B3%B4%EC%9E%90)
 
* **RED**: 스펙에 맞게 테스트를 작성합니다. 해당 테스트는 아직 구현된 코드가 없기 때문에 당연히 실패합니다.
* **GREEN**: 테스트를 통과하도록 코드를 구현합니다.
* **REFACTOR**: 코드를 올바르게 작성합니다. (팀 컨벤션, 메서드 분리 등)

즉, **TDD란 기능을 구현하기에 앞서 테스트를 먼저 작성하는 방법**인데요. 그렇다면 TDD가 앞서 언급한 문제들을 어떻게 해결해 주었을까요?

## 해결 1: 테크 스펙을 명확하게 파악하기
TDD를 처음 접했을 때는 겉보기에 간단해 보였지만, 막상 실제로 적용하려니 '테스트를 어떻게 작성해야 할까?'라는 막막함이 들었습니다. TDD 도입 전 지금까지의 개발 습관은 다음과 같았습니다.
 
```python
# 1. 유저 생성하는 코드 작성

def validate_email(email):
	...

def validate_password(password):
	...

def create_user(email, password):
	validate_email(email)
	validate_password(password)
	User.objects.create(email=email, password=password)
	
	return “Created User successfully”

# 2. 테스트 코드 작성

def test_validate_email():
	...

def test_validate_password():
	...

def test_create_user():
	# validate_email 호출됐는지
	# validate_password 호출됐는지
	# 유저 생성됐는지
```
 
지금까지는 테스트 코드 작성 시 앞서 구현한 코드에 맞춰 테스트를 작성하였습니다. 하지만 TDD를 처음 시도했을 때는, 구현해놓은 코드가 없다 보니 어떻게 테스트를 작성해야 할지 막막했습니다.
 
```
# 1. 테스트 코드 작성

# 테스트 뭘 작성해야되지..?
```
 
그러나 개발 습관을 바꾸면서 테스트 작성이 훨씬 수월해졌습니다. 바로 **테스트 코드를 작성하기 전에 스펙을 명확히 파악하고, 이를 문서로 정리**했기 때문입니다.
 

| Scenario |Given |When |Then |
| --- | --- | --- | --- |
| 유저 회원가입|비정상 이메일 정상 패스워드|유저가 이메일과 패스워드를 입력하였을 때|유저 생성 불가|
|-|비정상 이메일 비정상 패스워드|-|유저 생성 불가|
|-|정상 이메일 비정상 패스워드|-|유저 생성 불가|
|-|정상 이메일 정상 패스워드|-|유저 생성|
 
이를 기반으로 테스트를 작성하니 훨씬 수월하게 진행할 수 있었습니다.
 
```python
def test_create_user_with_invalid_email_and_valid_password():
	# 비정상 이메일과 정상 패스워드로 입력했을 때
	
def test_create_user_with_invalid_email_and_invalid_password():
	# 비정상 이메일과 비정상 패스워드로 입력했을 때
	
def test_create_user_with_valid_email_and_invalid_password():
	# 정상 이메일과 비정상 패스워드로 입력했을 때
	
def test_create_user_with_nvalid_email_and_valid_password():
	# 정상 이메일과 정상 패스워드로 입력했을 때

```
 
시나리오 작성은 테스트 코드 작성 뿐만 아니라, 이후 **기획자디자이너와의 의견 조율에도 큰 도움**이 되었습니다.
 
```
개발자: 지난번에 얘기한 머쓱이 이벤트 관련해서 시나리오 문서를 작성해 봤는데요. 생각하신 게 이게 맞을까요?
기획자: 네, 맞습니다!
개발자: 그리고 시나리오 작성하면서 떠오른 건데, 이미 머쓱이 프로필을 가진 사용자들도 있을 거 같아요. 해당 사용자들은 어떻게 할까요?
기획자: 아 그러네요. 해당 사용자들도 포함시키죠!
```
 
본격적으로 작업에 들어가기 전에 스펙을 정리한 뒤, 기획자와 디자이너에게 한 번 더 확인을 받고 작업을 진행함으로써 기획 변경이 줄어들었고, 불필요한 피로감도 크게 줄일 수 있었습니다.

## 해결 2: 나의 테스트 코드는 스펙 내용을 충분히 포함하고 있다.
TDD를 통해 작성된 테스트 코드는 스펙을 충실히 반영합니다. 이 덕분에 자신감 있게 배포할 수 있었습니다.
 
```
개발자 A: 개발 완료했고 알파서버에 배포해놨어요. 확인 부탁드립니다!
기획자, 디자이너: 네, 확인하겠습니다!
```

*20분 뒤*

```
기획자: 이상 없습니다.
디자이너: 저도 좋습니다!
개발자 A: 확인 감사합니다.
```

*이후 배포하기 직전*

```
개발자 A: QA 도 끝나고 테스트 코드도 모두 통과했으니 배포해야겠다! 
```
 
배포 전에 직접 작성한 스펙 문서를 확인하며 놓친 부분이 없는지 점검하고, 부족한 점이 발견되면 또 다른 하나의 시나리오와 테스트 코드를 추가해 기능을 보완합니다. 이전에는 구현된 코드를 검증하는 테스트 코드에 의존했지만, 이제는 **스펙을 기반으로 작성된 테스트 코드 덕분에 신뢰를 가지고 자신 있게 배포**할 수 있었습니다.

# 마무리하며: TDD는 단순한 방법론이 아니다.
이번 글에서는 실무에서 겪었던 문제들과 이를 TDD를 통해 어떻게 해결했는지 공유해 보았습니다. 하지만 이 글의 목적은 TDD를 무조건적으로 추천하기보다는 "내 성격에 맞는 개발 방법은 무엇일까?"를 고민해 보시길 바라는 마음에서 작성되었습니다.

저는 성격이 다소 급한 편인데요. 이런 성격 덕분에 일을 빠르게 처리할 수 있었지만, 동시에 놓치는 부분이 많아 장애를 발생시킨 적도 있고, 기획자들과 싱크가 맞지 않아 작업을 처음부터 다시 해야 했던 경험도 있습니다. 이러한 단점을 극복하기 위해 저는 TDD를 선택했고, 결과적으로 많은 도움이 되었습니다.

그러나 TDD가 모든 사람에게 이상적인 방법은 아닐 수 있습니다. 어떤 사람들에게는 오히려 피로감을 가져다주는 개발 방법일 수도 있습니다. 결국 중요한 것은 **모두에게 맞는 완벽한 개발 방법은 없으며, 자신만의 스타일에 맞는 개발 레시피를 찾아가는 것**입니다. 여러분도 자신의 성격과 작업 스타일에 잘 맞는 개발 방식을 찾아보시길 바랍니다!
 
 
[![BE_배너.jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/1c3ceac1-7304-4264-b5f5-52108f4b6bca/BE_%E1%84%87%E1%85%A2%E1%84%82%E1%85%A5.jpg)](https://school.programmers.co.kr/learn/courses/25244?utm_source=prgmblog&utm_medium=social&utm_campaign=school_25244_blog&utm_content=25244_banner)

[그렙 개발자가 들려주는 업무 이야기] 그렙 개발자의 개발 방법: TDD를 중심으로

IT 분야 브런치 작가이자 <오늘도, 우리는 코딩을 합니다>의 저자인 **13년차 풀스택 개발자 고코더 님**의 통찰력 있는 글을 이제 매월 프로그래머스 블로그에서 만나보실 수 있습니다. 현업 개발자의 시선에서 풀어낸 생생한 이야기와 인사이트를 함께 경험해보세요!

[![Frame 1000003812 (6).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/69775ff9-9c57-4190-979a-e8573d7a0da3/Frame%201000003812%20%286%29.png)](https://linktr.ee/gocoder)

***
 
# 등반가의 도전, 개발자의 여정
![스크린샷 2024-12-02 오전 11.39.06.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/6debbe74-05a9-42be-9d56-ba42f0670bfb/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202024-12-02%20%E1%84%8B%E1%85%A9%E1%84%8C%E1%85%A5%E1%86%AB%2011.39.06.png)
라인홀트 매스너 (Reinholde Messner)는 인류 최초로 히말라야 산맥의 8,000미터급 14좌를 등반한 등산가 입니다. 그가 등반한 14개의 산을 이어 붙여 세워보면 서울타워(236.7m)를 494개 쌓은 높이가 됩니다. 서울에서 수원까지를 3번 달리고도 남는 거리입니다. 만약 제 발걸음으로 걷는다면 29시간이 걸리는 거리입니다. 이탈리아 국적의 산악인 라인홀트 메스너는 거기서 멈추지 않고 에베레스트를 최초로 무산소로 등반을 합니다. 그리고 남극을 스키로 횡단하는 기록을 세우기도 하고, 2004년에는 고비 사막을 횡단하기도 했습니다. 정말 대단하고 멋진 도전입니다.

그런데 사실 저도 산을 꽤 좋아합니다. 주말이면 경의선 숲길을 따라 산책을 즐기며 서대문 안산에 오르기도 합니다. 높이는 겨우 296M 이지만 어릴적부터 최소 100번은 넘게 등반을 했습니다. 등반한 높이를 모두 합하면 에베레스트 3배가 넘는 높이가 됩니다. 와우.. 저도 사실은 에베레스트를 3번이나 다녀온 셈입니다. 그런데 왜 제 도전은 아무도 주목하지 않을까요? 라인홀트 메스너의 기록이 더 주목 받을까요? 그건 아마도 동네 뒷산만 오른게 아닌 다양한 산을 오르며 자신의 한계를 극복하고 새로운 등산 철학을 정립했기 때문일 것입니다. 여러 산을 정복하며 경험을 쌓았고 여러 산을 정복함으로써 전설적인 등반가가 되었습니다.

**단 하나의 등산로만 수백 번 오르내리는 것과, 여러 산의 다양한 등산로를 경험해보는 것 중 어떤 것이 더 좋은 등산가가 되는 길일까요?** 아마도 라인홀트 매스너처럼 다양한 높이의 산을 오르며 기록을 쌓아가는게 현명할 것입니다. 개발자의 성장도 이와 비슷합니다.

# 주니어 개발자의 딜레마
![스크린샷 2024-12-02 오전 11.39.21.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/e5ff67fd-6a6b-4362-8e64-0c92c9063756/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202024-12-02%20%E1%84%8B%E1%85%A9%E1%84%8C%E1%85%A5%E1%86%AB%2011.39.21.png)
많은 주니어 개발자들이 공통적으로 마주하는 고민이 있습니다. **"하나의 기술을 깊이 있게 파야 할까, 아니면 여러 기술을 골고루 익혀야 할까?"** 저 역시 주니어 시절 이런 딜레마에 빠졌었죠. 시간이 흘러 시니어 개발자가 된 지금, 그때의 고민에 대한 답을 어느 정도 찾은 것 같습니다.

그 답은 히말라야의 전설적인 등반가 라인홀트 메스너의 여정에서 찾을 수 있습니다. 그는 한 산만 반복해서 오르지 않고, 다양한 산들을 도전하며 자신만의 이름을 알려 최고의 등반가가 되었습니다. 개발자의 성장 역시 이와 다르지 않습니다. 이상적으로는 한 가지 기술을 깊이 파면서도 여러 기술을 두루 익히는 것이 최고겠지만, 대부분의 평범한 개발자들에게는 현실적이지 않은 목표일 수 있습니다. 그래서 저는 일반적인 개발자들을 위한 현실적인 조언을 하고자 합니다. 처음에는 다양한 기술들을 경험하며 자신만의 전문 분야를 찾아가는 것이 더 바람직한 방향이 될 수 있습니다.

# 코딩을 위한 넓고 얕은 공부 (코넓얕)
"코딩을 위한 넓고 얕은 공부", 줄여서 "코넓얕". 이 말은 베스트셀러 "지적 대화를 위한 넓고 얕은 지식"에서 영감을 받아 만든 문장입니다. 마치 시식 코너에서 오늘의 저녁 거리를 고를 때 여러 음식을 조금씩 맛보는 것처럼, 주니어 개발자들에게는 다양한 기술을 맛보며 자신의 입맛을 찾아가는 과정이 필요합니다. 그 이유를 알아보겠습니다.
 
## 첫 번째, 흥미와 적성을 파악하기 좋다.
![스크린샷 2024-12-02 오전 11.39.32.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/15d03f70-303a-4c2d-8b8a-fe7f7216a034/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202024-12-02%20%E1%84%8B%E1%85%A9%E1%84%8C%E1%85%A5%E1%86%AB%2011.39.32.png)
첫 번째로 주목할 점은 바로 '흥미와 적성 파악'입니다. 개발 세계는 마치 거대한 놀이동산과 같습니다. 프론트엔드라는 롤러코스터, 백엔드라는 회전목마, 데이터베이스라는 범퍼카, 그리고 클라우드라는 자이로드롭까지. 처음 놀이동산에 갔을 때는 화려하고 스릴 넘치는 롤러코스터가 가장 재미있을 거라 생각했습니다. 하지만 모든 놀이기구를 체험해보니, 제게는 오히려 멀미 나는 격한 놀이기구보다 회전목마처럼 잔잔하게 놀이동산의 분위기를 즐길 수 있는 놀이기구가 더 잘 맞았습니다. 이처럼 다양한 경험을 통해서만 진정 자신에게 맞는 것을 발견할 수 있습니다.

**주니어 개발자의 학습에 있어서 초기 단계는 특정 기술에만 몰두하는 것보다, 다양한 기술 스택과 도구를 맛보듯 경험해보는 것이 더 큰 이점을 줍니다**. 제 경우를 예로 들어보겠습니다. 처음 코딩을 시작할 때 저는 .NET을 선택했습니다. 사용하기 편리한 Visual Studio와 친숙한 Microsoft라는 이름이 주는 신뢰감 때문이었죠. 당시에는 다른 언어들에 전혀 관심을 두지 않았습니다. 그러다 우연한 기회로 Java를 접하게 되었는데, 이것이 전환점이 되었습니다.

프로그래밍 언어는 단순한 도구에 불과하다고들 하지만, **분명 개개인에게 더 잘 맞는 언어가 있습니다**. 마치 비슷해 보이는 볼펜들 중에서도 내 손에 딱 맞는 필기구가 있는 것처럼, 코딩도 마찬가지입니다. 지금은 Java 개발을 하면서 .NET에서는 느끼지 못했던 특별한 재미와 적성을 발견하며 즐겁게 개발하고 있습니다.이처럼 넓은 범위의 코딩 공부는 자신의 취향과 적성을 발견할 수 있는 좋은 방법입니다. 인생이 짧은 만큼, 자신이 진정으로 즐길 수 있는 기술을 찾아보는 것은 매우 중요합니다.

## 두 번째, 협업과 커뮤니케이션의 향상
![스크린샷 2024-12-02 오전 11.39.54.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/b3586b02-1c37-4a18-87bb-dc4ea3bf1f05/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202024-12-02%20%E1%84%8B%E1%85%A9%E1%84%8C%E1%85%A5%E1%86%AB%2011.39.54.png)
두 번째로 주목할 점은 '협업과 커뮤니케이션의 향상'입니다. 개발 팀은 마치 오케스트라와 같습니다. 프론트엔드는 바이올린, 백엔드는 첼로, 데이터베이스는 비올라, 데브옵스는 트라이앵글 처럼 각자의 역할이 있습니다. 오케스트라 단원이 다른 악기의 특성과 소리를 이해할 때 더 조화로운 연주가 가능한 것처럼, 개발자도 다양한 기술을 이해할 때 더 효과적인 협업이 가능합니다.

실무에서 느낀 경험을 나눠보자면, 처음에는 백엔드 개발자로서 프론트엔드 기술에 대해 전혀 모르다 보니 협업에 어려움이 많았습니다. "이 기능을 구현하는 데 왜 이렇게 오래 걸리지?"라고 생각했던 적도 있었습니다. 하지만 프론트엔드 기술을 조금씩 공부하면서, 브라우저의 호환성 문제나 사용자 경험을 고려해야 하는 복잡성을 이해하게 되었습니다. 이러한 이해를 바탕으로 더 현실적인 일정 산정과 효율적인 API 설계가 가능해졌습니다.

다양한 분야에 대한 지식은 팀 내에서 더 큰 가치를 발휘합니다. 마치 통역사가 두 나라의 언어를 모두 알아야 원활한 소통이 가능한 것처럼, **개발자도 여러 기술 분야를 이해할 때 팀원들과 더 효과적으로 소통**할 수 있습니다. 이는 결국 프로젝트의 성공과 팀의 생산성 향상으로 이어지며, 신뢰받는 개발자로 성장하는 밑거름이 됩니다.

## 세 번째, 문제 해결 능력의 확장
![스크린샷 2024-12-02 오전 11.40.10.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/7f8ea010-a65f-4d29-8cfc-9d19bc054895/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202024-12-02%20%E1%84%8B%E1%85%A9%E1%84%8C%E1%85%A5%E1%86%AB%2011.40.10.png)
세 번째로 주목할 점은 “문제 해결 능력의 확장” 입니다. 개발자의 도구 상자는 마치 의사의 의료 가방과 같습니다. 감기약만 가득한 의료 가방보다는 다양한 약과 도구가 구비된 의료 가방이 더 많은 환자를 치료할 수 있는 것처럼, 다양한 기술을 알고 있는 개발자가 더 효과적으로 문제를 해결할 수 있습니다.

**개발자의 관점에서 보면, 프론트엔드, 백엔드, 데이터베이스, 클라우드, 보안 등 다양한 분야를 경험하는 것이 마치 의사의 수련 기간 동안 체험하는 임상 실습과 같습니다**. 제 경험을 예로 들어보겠습니다. 몇 년 전, 서버 성능 개선이라는 과제를 받았을 때 단순히 백엔드 코드 최적화만으로는 문제를 해결할 수 없었습니다. 다행히 이전에 데이터베이스와 캐시 서버에 대한 경험이 있었기에, 데이터베이스 인덱싱 최적화와 캐시 서버 도입으로 문제를 효과적으로 해결할 수 있었습니다.

또한, 보안 취약점 개선 작업에서도 프론트엔드부터 인프라까지 전반적인 이해가 있었기에 각 계층에서 발생할 수 있는 보안 위협을 더 포괄적으로 대응할 수 있었습니다. 이는 마치 내과 의사가 순환기 질환을 치료하면서 신경계나 소화기계에 대한 이해가 치료에 도움이 되는 것처럼, 개발자도 다양한 기술 스택에 대한 이해가 있을 때 더 효과적인 해결책을 제시할 수 있습니다.

의사가 다양한 과를 경험하며 전반적인 능력을 기르듯, 개발자도 여러 기술을 경험하며 종합적인 문제 해결 능력을 키울 수 있습니다. 이는 앞으로 전문 분야에서 마주칠 복잡한 문제들을 해결하는 데 든든한 기반이 됩니다.

# 넓고 얕은 시작, 위대한 여정의 첫걸음
코딩을 위한 넓고 얕은 공부, **즉 "코넓얕"은 다양한 기술을 시도해보는 것을 의미**합니다. 이는 마치 등반가가 여러 산을 도전하며 자신의 한계를 시험하는 것과 같습니다. 한 산에 머무르지 않고 다양한 산을 오르며 경험을 쌓는다면, 여러분은 더 유연하고 다재다능한 개발자로 성장할 수 있습니다. **다양한 기술을 접하면서 자신에게 맞는 분야를 발견하고, 더 나아가 전문성을 키워갈 수 있는 기반을 마련**할 수 있습니다.

등반가가 모든 산을 도전하듯, 개발자도 여러 언어와 기술을 등반해보세요. 각기 다른 산을 오를 때마다 새로운 도전과 성취감을 느낄 수 있을 것이며, 이는 곧 여러분의 개발 역량을 더욱 풍부하게 만들어줄 것입니다. 넓고 얕게 시작하더라도 꾸준히 도전하고 노력한다면, 언젠가 여러분도 자신만의 높은 산을 정복한 개발자로 자리매김할 수 있을 것입니다.

주니어 개발자 여러분, 다양한 기술이라는 산들을 향해 두려움 없이 도전하세요. 여러분의 여정이 더욱 풍부하고 의미 있는 성취로 가득 차길 응원합니다.
 
 
[![coding-test2(729x90).jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/62448f31-d100-4b15-bc8d-f44ad827f593/coding-test2%28729x90%29.jpg)](https://school.programmers.co.kr/learn/courses/25186?utm_source=prgmblog&utm_medium=social&utm_campaign=school_25186_blog&utm_content=25186_banner)

주니어 개발자의 학습 전략: 코딩을 위한 넓고 얕은 공부

![\[길벗\]22기_프로그래머스_블로그 (1).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/8dad26ea-27b3-4bc7-8106-a0f3ecedb4b1/%5B%E1%84%80%E1%85%B5%E1%86%AF%E1%84%87%E1%85%A5%E1%86%BA%5D22%E1%84%80%E1%85%B5_%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%84%80%E1%85%B3%E1%84%85%E1%85%A2%E1%84%86%E1%85%A5%E1%84%89%E1%85%B3_%E1%84%87%E1%85%B3%E1%86%AF%E1%84%85%E1%85%A9%E1%84%80%E1%85%B3%20%281%29.png)
 
안녕하세요, 프로그래머스입니다.
길벗 출판사에서 신청자 전원 참여가 가능한 코딩 자율학습단 22기를 모집 중입니다.
코딩 자율학습단은 길벗출판사의 프로그래밍 도서 + AI 도서의 완독을 돕는 프로그램인데요!
4주간 프로그래밍과 AI 입문을 배워보고 싶으신 분들은 주목해주세요!
 
 
 
## 코딩 자율학습단 22기 모집 중!
![코자 22기 홍보 이미지 (정방형) (1).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/6fc688a2-4433-4e19-a144-d901145c870a/%E1%84%8F%E1%85%A9%E1%84%8C%E1%85%A1%2022%E1%84%80%E1%85%B5%20%E1%84%92%E1%85%A9%E1%86%BC%E1%84%87%E1%85%A9%20%E1%84%8B%E1%85%B5%E1%84%86%E1%85%B5%E1%84%8C%E1%85%B5%20%28%E1%84%8C%E1%85%A5%E1%86%BC%E1%84%87%E1%85%A1%E1%86%BC%E1%84%92%E1%85%A7%E1%86%BC%29%20%281%29.png)
 
### 코딩 자율학습단이란?
길벗출판사의 프로그래밍 도서 + AI 도서로 한 달 동안 책 1권의 완독을 도와주는 프로그램입니다. 
입문자 입장에서 학습하실 수 있도록 책 자체에서도 친절하게 안내하고 있으며, 커리큘럼과 학습가이드도 제공하고 있습니다. 
 
완독하신 분들께는 **도서 구매용 포인트 2만 점**과 **네이버 포인트** 등 다양한 선물을 드려요!
 
 
## 책만 준비하면 누구나 참여 가능!
![코자 22기 홍보 이미지 (정방형) (2).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/4f43ac86-0ef8-4c1f-b1a9-e5ffff9d5e2a/%E1%84%8F%E1%85%A9%E1%84%8C%E1%85%A1%2022%E1%84%80%E1%85%B5%20%E1%84%92%E1%85%A9%E1%86%BC%E1%84%87%E1%85%A9%20%E1%84%8B%E1%85%B5%E1%84%86%E1%85%B5%E1%84%8C%E1%85%B5%20%28%E1%84%8C%E1%85%A5%E1%86%BC%E1%84%87%E1%85%A1%E1%86%BC%E1%84%92%E1%85%A7%E1%86%BC%29%20%282%29.png)
 
코딩 자율학습단은 총 7개 분야로 나뉘어 진행됩니다.
 

* 코딩 자율학습 나도코딩의 파이썬 입문 
* 코딩 자율학습 HTML+CSS+자바스크립트
* 코딩 자율학습 나도코딩의 C 언어 입문
* 코딩 자율학습 나도코딩의 자바 입문
* AI 자율학습 밑바닥부터 배우는 AI 에이전트
* AI 자율학습 처음 만드는 AI 에이전트 서비스
* 바이브 엔지니어링
 

👉 [**코딩 자율학습단 22기 신청하기**](https://gilbut.co/c/26085765EC)

 
 
## 학습단 안내
![코자 22기 홍보 이미지 (정방형) (3).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/ff50006a-83b9-45a4-b0d2-8793429aa8a5/%E1%84%8F%E1%85%A9%E1%84%8C%E1%85%A1%2022%E1%84%80%E1%85%B5%20%E1%84%92%E1%85%A9%E1%86%BC%E1%84%87%E1%85%A9%20%E1%84%8B%E1%85%B5%E1%84%86%E1%85%B5%E1%84%8C%E1%85%B5%20%28%E1%84%8C%E1%85%A5%E1%86%BC%E1%84%87%E1%85%A1%E1%86%BC%E1%84%92%E1%85%A7%E1%86%BC%29%20%283%29.png)
 
* 신청 기간: **~8월 21일(금)**
* 선정자 안내: 신청 후 2일 이내 문자와 메일로 연락 (신청시 전원 참여 가능)
* 학습 기간: 8월 24일 ~ 9월 18일 (4주)
* 학습 미션: 학습 일지 및 후기 작성

 
### 신청 방법
1. 사이트를 통해 신청해주세요. ([링크](https://gilbut.co/c/26085765EC))
2. 신청해주신 분들께는 순차적으로 이메일과 문자로 안내드립니다.
3. 문자+이메일 연락을 받고 도서를 구매해주시면, 시작일부터 카톡으로 학습 시작 안내를 드립니다.

 
### 스터디 그룹
학습자 분들의 한결 수월한 학습 소화를 위해 구성된 제도입니다.
모집 기간 중 자율적으로 3인 이상의 팀을 구성하여 신청해 주시면 전원 참여가 가능하며, 신청 시 커피 쿠폰을 증정합니다.
신청 및 활동 방식은 공지를 참고해 주세요.

👉 **[스터디 그룹 공지 자세히 보기](https://cafe.naver.com/gilbutitbook/15685)**

 
 
## 학습단 혜택 살펴보기
![코자 22기 홍보 이미지 (정방형) (4).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/d2535375-29fa-4c70-8047-d9cdb567c880/%E1%84%8F%E1%85%A9%E1%84%8C%E1%85%A1%2022%E1%84%80%E1%85%B5%20%E1%84%92%E1%85%A9%E1%86%BC%E1%84%87%E1%85%A9%20%E1%84%8B%E1%85%B5%E1%84%86%E1%85%B5%E1%84%8C%E1%85%B5%20%28%E1%84%8C%E1%85%A5%E1%86%BC%E1%84%87%E1%85%A1%E1%86%BC%E1%84%92%E1%85%A7%E1%86%BC%29%20%284%29.png)
 
### 참고 사항
- 기존 기수로 신청했으나 완독하지 못하신 분들은 이전과 동일하게 다시 신청해주셔야 합니다.
- 이전 기수 수료자는 동일 도서로 참여할 수 없습니다.
 (예시)
 - 5기 파이썬 수료 → 8기 파이썬 신청 (X)
 - 5기 파이썬 수료 → 8기 C언어 신청 (O)

 
#### 입문자 대상 도서 선택 참고!
"프로그래밍 경험이 전혀 없으면?"
👉 <파이썬> 또는 <HTML + CSS + 자바스크립트>를 추천합니다!

 
#### 초급자 대상 도서 선택 참고!
"파이썬을 학습한 적이 있다면?"
👉 <AI 자율학습 밑바닥부터 배우는 AI 에이전트>, <AI 자율학습 처음 만드는 AI 에이전트 서비스> 추천!

[길벗출판사] 코딩 자율학습단 22기를 모집합니다!

오늘날 기술 산업에서 백엔드 개발자와 SRE(Site Reliability Engineer)는 시스템 안정성과 성능을 유지하는데 중요한 역할을 담당하고 있습니다. 백엔드 개발자는 애플리케이션의 서버 측 기능을 구축하고, 비즈니스 로직을 구현하는 데 중점을 두는 반면, SRE는 시스템의 가용성과 신뢰성을 보장하고 운영 효율성을 극대화하는 데 초점을 맞춥니다. 백엔드 개발자와 SRE, 두 직군을 모두 경험한 전문가의 인터뷰 내용을 살펴보겠습니다.
 
# 인터뷰이 소개
안녕하세요. 저는 **카카오뱅크 SRE(Site Reliability Engineer) 직무로 일하고 있는 5년 차 프로그래머 이원진** 입니다. 이전에는 다날에서 백엔드 개발자로 약 3년간 근무하였으며 현재는 카카오뱅크에서 SRE로 3년째 근무하고 있습니다.

저는 컴퓨터 공학을 전공했고, 취업 준비 과정에서 정보처리기사와 리눅스 마스터 1급 자격증을 취득했습니다. 당시에는 백엔드 개발자를 목표로 자바와 스프링 같은 백엔드 기술 스택을 익히며 취업을 준비했습니다. 취업 준비 과정에서 프로그래머스 사이트 내 코딩 테스트를 많이 이용했었는데, 이렇게 인터뷰를 하게 되어 매우 뜻깊습니다.

# 백엔드 개발자와 SRE 직군별 비교
## 백엔드 개발자
백엔드 개발자는 서비스의 서버 사이드에서 작동하는 부분을 개발하는 직무로, 눈에 보이지 않는 부분을 개발하고 유지 보수하는 역할을 담당합니다. 사용자가 직접 상호작용하는 부분을 담당하는 프론트엔드와 달리 서버, 데이터베이스, 애플리케이션 로직 등 뒷단의 부분을 책임지게 됩니다.
 

![프론트엔드vs백엔드 비교.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/565e3ab1-f375-41d5-996f-d685a4ee44a4/%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%86%AB%E1%84%90%E1%85%B3%E1%84%8B%E1%85%A6%E1%86%AB%E1%84%83%E1%85%B3vs%E1%84%87%E1%85%A2%E1%86%A8%E1%84%8B%E1%85%A6%E1%86%AB%E1%84%83%E1%85%B3%20%E1%84%87%E1%85%B5%E1%84%80%E1%85%AD.png)
[이미지 출처](https://medium.com/@adityagaba1322/streamlining-backend-frontend-integration-a-quick-guide-145eca3cca05)
 

백엔드 개발자는 다양한 클라이언트에게 필요한 기능을 제공하는 것을 목표로 여러 가지 업무를 수행합니다. 가장 중요한 작업 중 하나는 **API 설계와 개발**입니다. 클라이언트가 필요로 하는 기능을 파악하고, 그에 맞는 데이터를 어떻게 전달할 것인지, 데이터의 구조와 이를 저장할 데이터베이스를 설계합니다. 이를 바탕으로 프로그래밍 언어와 프레임워크를 활용해 클라이언트와의 통신을 위한 규약인 API를 개발합니다.

새로운 기능을 개발하는 것뿐만 아니라, **기존 기능의 버그 수정이나 미래의 위험 요소를 사전에 제거**하는 작업도 중요합니다. 예를 들어, 사용성이 떨어진(Deprecated)된 라이브러리를 교체하거나 평균 TPS 증가로 인한 요청 처리 방식 개선 등의 작업이 있을 수 있습니다. 또한, **레거시 코드를 개선하거나 코드의 통일성과 가독성을 높이기 위한 리팩토링**도 백엔드 개발자의 주요 업무 중 하나입니다.

이러한 작업들을 진행하면서 반드시 거쳐야 하는 단계는 **테스트, 코드 리뷰, 그리고 문서화 작업**입니다. 백엔드 개발자는 자신이 작성한 코드의 문제가 없는지 확인하기 위해 여러 종류의 테스트를 수행합니다. 단위 테스트, 통합 테스트 등 다양한 테스트 방법이 있으며, JUnit, JMeter, Postman 같은 도구를 사용해 테스트를 진행합니다.

또한, 코드 리뷰는 품질 향상을 위한 중요한 과정입니다. 일반적으로 개발자가 형상관리 시스템(예: GitHub, GitLab)에 생성한 MR(Merge Request) 또는 PR(Pull Request)을팀원들이 리뷰하여 피드백을 주고받습니다. 이 과정은 회사나 팀에 따라 다를 수 있지만, 대체로 동료들과 함께 코드의 문제점이나 이슈를 논의하면서 최종 승인을 받는 방식으로 진행됩니다.

백엔드 개발자의 업무에서 빼놓을 수 없는 것, 바로 문서화 작업입니다. 자신이 개발한 API 명세, 데이터베이스 명세, 테스트 문서, 버그 리포트, 릴리스 노트, 설정 가이드, 사용자 매뉴얼 등 다양한 문서들을 작성해야 합니다. 한때 개발자는 글을 쓸 일이 많지 않을 것이라 생각했지만 이는 큰 오산이었습니다. 문서화 작업이 많은 만큼 글쓰기 능력 역시 개발자가 갖춰야 할 중요한 역량 중 하나라는 것을 깨달았습니다.
 

> 💡 **코드 리뷰의 중요성**
실무에서 백엔드 개발을 경험하신 이원진 님께서 강조하신 코드 리뷰! 개발한 코드를 동료들과 함께 리뷰하며 품질을 향상시키는 작업인데요. 프로그래머스 백엔드 데브코스 과정에서는 실시간으로 멘토와 함께 코드 리뷰를 하며 피드백을 받을 수 있답니다! ⭐
 
## SRE (Site Reliability Engineer)
SRE는 서비스나 시스템의 높은 가용성과 안정성을 추구하는 직무로, 서비스의 신뢰성을 높이기 위한 다양한 업무를 수행합니다. 주요 업무 중 하나는 **모니터링**입니다. SRE는 다양한 모니터링 도구와 알람 시스템을 사용해 서비스의 이상 징후를 확인하고, 문제의 원인이 되는 지점을 파악하는 역할을 맡습니다. 대부분의 IT 서비스는 24시간 운영되기 때문에, 모니터링은 정규 업무 시간뿐만 아니라 퇴근 이후 그리고 심지어 우리가 자고 있는 시간에도 다양한 채널(알람, 관제 등)을 통해 이루어집니다.

모니터링을 통해 인지한 **서비스 장애에 대한 대응**도 SRE의 핵심 업무 중 하나입니다. 서비스 장애는 애플리케이션 오류, 네트워크 문제, 서버 리소스 부족 등 다양한 원인으로 발생할 수 있습니다. 이때 SRE는 장애 발생 시 개발자, 인프라 엔지니어 등 여러 유관 담당자들이 신속하게 서비스 복구에 집중할 수 있도록 지원하는 역할을 합니다.서비스 로그와 여러 지표를 분석해 원인을 파악하고, 해결 방안을 모색하며 서비스 중단과 사용자의 불편을 최소화하는 데 주력합니다.

서비스 장애가 발생하지 않는 것이 가장 이상적이지만, 현실에서는 여러 이유로 장애가 종종 발생하게 됩니다. 따라서 장애 대응뿐만 아니라, 재발 방지를 위한 대책을 세우고 사전 예방하는 것도 매우 중요합니다. SRE는 유사한 장애가 다시 발생하지 않도록 이를 회고, 리뷰하며 개선 방안을 마련해 적용하는 일을 수행합니다.
![SRE.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/ac7a0476-54be-4c66-b19b-d111621641b0/SRE.png)

# 백엔드 개발자 및 SRE 커리어 준비 Tip
## 백엔드 개발자 필요 역량
백엔드 개발자를 목표로 커리어를 준비한다면, 가장 먼저 **자신 있고 능숙하게 다룰 수 있는 프로그래밍 언어** 최소 하나쯤은 확실히 무기로 가지고 있어야 합니다. 서버 사이드 개발에 사용되는 언어는 자바, 파이썬, 자바스크립트, 코틀린 등 매우 다양합니다. 저는 취업 준비때부터 지금까지 자바를 주력으로 사용하고 있습니다. 최근에는 파이썬, 코틀린, Go 같은 최신 트렌드 언어를 도입하는 회사들이 많아지고 있지만, 여전히 많은 회사들이 자바와 자바 진영의 프레임워크를 활용해 서비스를 개발하고 있습니다. 자바는 시장에서 여전히 큰 수요가 있기 때문에, 이를 선택하는 것도 좋은 전략이라 생각합니다. 프로그래밍 언어를 학습할 때, 단순히 문법을 익히는 것을 넘어서, 언어의 메모리 구조와 관리, 데이터 구조, 예외 처리 등 언어 고유의 특성들을 깊이 이해하는 것이 더 중요합니다.

프로그래밍 언어 외에도 **데이터베이스, 형상 관리, 프레임워크** 등 다양한 기술을 학습해야 한다는 점은 이미 많은 분들이 알고 있을 것입니다. 이와 더불어 제가 강조하고 싶은 부분은 **네트워크에 대한 이해**입니다. 결국 모든 서비스는 네트워크 통신을 기반으로 이루어지기 때문에, 이를 지탱하는 네트워크 프로토콜에 대한 이해는 필수적입니다. 특히 HTTP와 TCP/IP 같은 서버 통신의 기본이 되는 프로토콜은 반드시 익히고 내 것으로 만들어야 합니다. 저는 신입 개발자 시절부터 O'REILLY의 <HTTP 완벽 가이드>라는 책을 늘 곁에 두고 필요할 때마다 참고하고 있습니다. 그만큼 네트워크는 백엔드 개발 실무에서 매우 중요한 요소이며, 백엔드 시스템의 근간을 이루는 기술입니다.

![백엔드 프로그래밍 툴 유형.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/16a55af7-41f8-4e26-8385-5de7717a4db4/%E1%84%87%E1%85%A2%E1%86%A8%E1%84%8B%E1%85%A6%E1%86%AB%E1%84%83%E1%85%B3%20%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%84%80%E1%85%B3%E1%84%85%E1%85%A2%E1%84%86%E1%85%B5%E1%86%BC%20%E1%84%90%E1%85%AE%E1%86%AF%20%E1%84%8B%E1%85%B2%E1%84%92%E1%85%A7%E1%86%BC.png)
## SRE 필요 역량
SRE를 목표로 취업을 준비하시는 경우에도 크게 다르지 않습니다. SRE 직무 역시 다양한 개발을 하며 장애 예방과 대응을 위한 코드 분석을 진행하기 때문에 프로그래밍 언어를 능숙하게 다룰 수 있어야 합니다. 다만, SRE 직무 특성상 코드 레벨보다는 **Linux, Unix와 같은 운영체제 시스템에 대한 지식**과 **TCP/IP, DNS, HTTP, 로드 밸런싱 등 네트워크 기본 지식**을 익히는 것이 더 중요하다고 생각됩니다. 더 나아가서 nGrinder, JMeter 등 다양한 도구를 활용하여 성능 테스트를 경험해 보거나 클라우드 서비스, 컨테이너 환경 구성, 쿠버네티스를 활용한 오케스트레이션을 구성해 보는 것도 SRE 취업을 준비하는 데 도움이 될 수 있습니다.
 
# 백엔드 직군 커리어 준비 Tip
어느 직군이든 준비 과정에서 학습한 것들을 온전히 내 것으로 만드는 것이 커리어 준비에 있어 매우 중요하다고 생각합니다. 저는 **기술 블로그를 운영하며 학습했던 내용들을 기록**하였는데요. 다른 사람들도 접근할 수 있는 오픈된 공간인 만큼 정확한 내용을 전달하려고 노력하다보니 학습한 것들을 제 것으로 만들 수 있었습니다. 또한 이해하기 쉽게 글을 작성하는 과정에서 문서화 능력도 향상되어 실무에서 Wiki 작성과 같은 문서화 업무를 진행할 때 많은 도움이 되었습니다.

개발자로 취업하기 위해 거쳐야 하는 필수 관문인 **코딩 테스트는 [프로그래머스 코딩테스트](https://school.programmers.co.kr/learn/challenges?order=recent)를 많이 활용하여 준비**했습니다. 많은 IT 회사들이 프로그래머스를 통해 코딩 테스트 전형을 진행하고 있기 때문에, 프로그래머스의 코딩 테스트 플랫폼(e.g. IDE)에 익숙해지는 것이 좋을 것이라 판단했고, 잡페어, 썸머/윈터 코딩, 공채 기술 등 다양한 문제들을 풀어보는 것이 실제 코딩 테스트 합격에 큰 도움이 되었습니다.

> 💡 프로그래머스 데브코스에서는 WIL(Weekly I learned)을 진행합니다. 매주 배운 내용을 글로 작성하여 학습한 내용을 내 것으로 만들고, 동료들의 피드백을 받기 위함인데요! 이 과정에서 부족한 점을 보완하여 성장하고, 향후 실무에 필요한 문서 작성 능력까지 기를 수 있습니다. 💪
(WIL: 일부 과정에 한하여 진행)

> 💡 이원진 님께서 취업 준비에 적극 활용하셨던 프로그래머스 코딩 테스트는 **국내 개발자 절반 이상이 프로그래밍 학습에 사용**하고 있다는 사실! 프로그래머 취업을 준비하고 계시다면 프로그래머스 코딩테스트 꼭 활용해 보세요. 😉
(출처: 23년도 프로그래머스 개발자 설문조사 결과)

 
지금까지 제가 경험했던 백엔드 개발 직무와 SRE 직무에 대해 자세히 설명드렸는데요. 백엔드 개발자는 기능 구현과 시스템 성능을 책임지고, 사용자에게 가치를 전달하는 코드와 아키텍처를 만듭니다. SRE는 이러한 시스템이 실제 환경에서 신뢰성 있게 운영될 수 있도록 지원하고, 예기치 않게 발생할 수 있는 문제들을 예방하며, 이를 대응하는 역할을 담당합니다. 이 두 직무는 단순히 분리된 것이 아닌, 각각의 전문성을 바탕으로 서비스의 안정성과 품질을 높여가는 중요한 파트너로 볼 수 있습니다.
 

글 작성: 이원진 (카카오뱅크 SRE)
편집자: Chloe (Grepp 콘텐츠마케터)

 
 
> **프로그래머스 백엔드 엔지니어링 데브코스** 👨‍💻
> 1,700개 기업의 채용 공고를 완벽 분석하여 취업에 필요한 핵심 기술을 엄선한 프로그래머스 백엔드 과정
 
> *"프로그래머스 백엔드 데브코스는 탄탄한 커리큘럼뿐만 아니라 현직자 특강, 채용 연계 프로그램 데브패스 등 다양한 취업 연계 서비스를 제공해 단순히 교육으로 끝나는 것이 아니라 채용 과정까지 지속적으로 서포트 해준다는 점이 매력적으로 느껴집니다." 
-카카오뱅크 SRE 이원진 님과의 인터뷰 중*

 
[![be-coding-test2(729x90).jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/2eb5b602-485b-4a93-a3ab-3e67a8626189/be-coding-test2%28729x90%29.jpg)](https://school.programmers.co.kr/learn/courses/25244?utm_source=prgmblog&utm_medium=social&utm_campaign=school_25244_blog&utm_content=25244_banner)

카카오뱅크 현직 전문가가 알려주는 백엔드 개발자와 SRE

안녕하세요, 개발자 채용의 기준을 만들어온 **프로그래머스**입니다 🚀

이제는 단순히 "AI를 사용해 보셨나요?"라고 묻는 시대는 지났습니다.  
실무 현장에서 AI를 활용해 **진짜 성과**를 낼 수 있는가를 
검증해야 하는 골든타임입니다⏰

개발자 채용 시장을 혁신해온 프로그래머스가 그간의 독보적인 전문성을 
바탕으로, 이제 **전 직군 AI 역량의 새로운 기준**을 정의합니다 ✨

---

## **💡 프로그래머스 AI 역량평가, 무엇이 다를까요?**
![AI 역량평가 소개.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/ecbb34af-5e17-4fe4-b6ca-217676265912/AI%20%E1%84%8B%E1%85%A7%E1%86%A8%E1%84%85%E1%85%A3%E1%86%BC%E1%84%91%E1%85%A7%E1%86%BC%E1%84%80%E1%85%A1%20%E1%84%89%E1%85%A9%E1%84%80%E1%85%A2.png)
프로그래머스 전 직군 AI 역량평가는 단순한 지식 측정을 넘어, 
실무 중심의 입체적인 검증 프로세스를 제공합니다.


**🔹 전 직군 실무형 평가** 
: 기획, 마케팅, 디자인 등 각 직무별 업무 환경에 최적화된 문항으로 실질적인 AI 활용 능력을 검증합니다.

**🔹 입체적 검증 프로세스** 
: 단순 결과물만 보는 것이 아닙니다. AI를 다루는 **프롬프트 구성**부터 **결과 도출 과정**까지 정밀하게 평가합니다.

 **🔹 HR 통합 솔루션** 
: 채용, 교육, 진단을 하나로 연결하여 기업이 필요한 AI 인재를 선발하고 육성할 수 있도록 돕습니다.

---

## **🎯 이런 고민을 가진 HR 담당자님께 추천합니다**

✅ "AI 툴을 쓴다고는 하는데, 실력 차이를 모르겠어요."
✅ "우리 직무에 딱 맞는 AI 평가 도구가 필요해요."
✅ "AI 도입 후 실제 업무 효율이 얼마나 올랐는지 수치화하고 싶어요."

---

## **🚀 도입을 넘어 성과로 증명하는 AX의 시작**

모호했던 AI 역량, 이제 프로그래머스가 명확한 데이터로 보여드립니다. 📊  
우리 조직에 최적화된 AI 인재를 찾고 있다면, 지금 바로 프로그래머스 AI 역량평가와 함께하세요!

**[👉 AI 역량평가 자세히 알아보기](https://programmers.co.kr/ai-assessment)**

AI 인재 평가의 새로운 기준, 프로그래머스 전 직군 AI 역량평가 출시!

데이터 분석 데브코스를 수료한 옥예진 님의 수강 후기 인터뷰입니다. 예술을 전공했지만 데이터 분석에 대한 열정을 갖고 새로운 도전을 시작하신 예진 님은, 데브코스의 체계적인 학습과 실무 중심의 프로젝트 경험을 통해 자신감을 얻었다고 하는데요. 비전공자로서 데이터 분석가의 길을 준비하게 된 계기부터 데브코스를 통해 얻은 성장 이야기까지, 예진 님의 생생한 경험담을 지금 바로 만나보세요!
 
# 안녕하세요. 자기소개 부탁드립니다.
안녕하세요! 저는 대학에서 데이터와 무관한 전공을 공부했지만, 마지막 학기에 새로운 도전을 결심하며 데이터 분석의 길로 뛰어든 옥예진 입니다. 프로그래머스 데이터 분석 데브코스 4기를 수료했고, 현재 데이터 분석가 또는 데이터 기반 마케터로 취업을 준비하고 있습니다.

![image 339.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/b5c506c4-654f-400f-8388-334ec88ecadd/image%20339.png)

# 프로그래머스 데브코스는 어떻게 알게 되셨나요?
비전공자로서 데이터 분석 학습을 처음 시작하는 만큼, 체계적인 국비지원 교육이 필요하다고 판단하여 여러 부트캠프를 열심히 찾아보았습니다. 이 과정에서 부트캠프 정보를 한눈에 볼 수 있는 ‘부트텐트’와 같은 사이트를 참고했고, 다양한 교육 기관의 인스타그램 계정을 살펴보며 정보를 수집하던 중 프로그래머스 데이터 분석 데브코스를 알게 되었습니다.

# 타 기관도 있지만, 프로그래머스를 선택하신 이유가 있을까요?
우선적으로 **교육기관의 신뢰도**를 가장 중요하게 고려했어요. 프로그래머스는 개발자 준비생이라면 누구나 알 정도로 명성이 있는 기관이었기에 자연스럽게 신뢰가 갔습니다. 또한, SQL을 공부하며 프로그래머스의 코딩테스트 문제를 활용했던 경험이 있었는데, 이러한 **수준 높은 코딩 테스트 환경을 제공하는 기관이라면 질 높은 교육을 받을 수 있을 것이라는 확신**이 들었습니다.

프로그래머스 데브코스만의 유연한 일정도 큰 장점이었습니다. 다른 부트캠프와 달리, 9 to 6의 고정된 실시간 스케줄을 강제하지 않는 점이 마음에 들었어요. 여러 부트캠프 후기를 살펴보니, 수업만큼이나 개인 공부 시간이 중요하다는 의견이 많았거든요. 데브코스는 1시부터 6시까지의 코어 타임을 유지하면서도 그 외 시간은 자율적으로 활용할 수 있도록 구성되어 있었는데, 이 점이 복습과 예습 시간을 충분히 확보하는 데 큰 도움이 되었습니다. 실제로 수강하는 동안 이와 같은 유연한 학습 환경 덕분에 더욱 만족스러운 학습 경험을 할 수 있었습니다.

![image 340.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/4e293ba6-04de-4339-a7c8-c8055ca42477/image%20340.png)
👆 데브코스의 시작을 도와준 데브코스 사전 OT

# 5개월 동안 데브코스에 참여하며 무엇이 가장 기억에 남나요?
아무래도 가장 기억에 남는 경험은 최종 프로젝트인 것 같아요. **약 3주 동안 진행된 최종 프로젝트는 많은 고생과 함께 큰 성과를 얻을 수 있었던 의미 있는 시간**이었습니다. 수업이 끝난 저녁에도 작업을 이어갔고, 팀원들과 매일 회의를 통해 피드백을 받고 수정하는 과정을 반복했습니다.

특히, 분석 기준이 여러 번 바뀌면서 처음부터 다시 시작해야 하는 상황도 많았는데, 그 과정에서 모든 팀원이 많이 고생했던 기억이 납니다. 하지만 어려움 속에서도 함께 해결책을 찾고 서로 격려하며 끝까지 최선을 다했고, 결과적으로 최종 발표회에서 1등을 차지하게 되었어요. 이때 기분은 말로 표현할 수 없을 정도로 기뻤답니다.

데이터 분석은 저에게 새로운 도전이었기에 이렇게 성취를 이뤄낸 경험이 더욱 큰 의미로 다가왔고, 이를 계기로 데이터 분석가의 길로 나아가는 것에 대한 자신감과 용기를 많이 얻을 수 있었어요.

![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/5722a9c2-8843-4584-a029-14813ca721fc/image.png)
👆 최종 발표회에서 1등 수상 후 받은 소소한 상품

# 데브코스를 통해 스스로의 성장을 실감했던 순간이 있나요?
데브코스를 시작했을 때 저는 SQL과 Excel은 다룰 수 있었지만, 데이터 분석 기초 개념이 부족한 상태였습니다. 하지만 데브코스를 통해 **프로젝트를 4차까지 진행하며 Python Pandas, Tableau, Maatplotlib 등 다양한 기술을 익히며 큰 성장을 경험**할 수 있었습니다.

그중 가장 성장했다고 느낀 순간은 2차 프로젝트를 수행할 때였습니다. 이 프로젝트는 여행 웹페이지에서 유저의 참여도가 여행 상품 구매에 어떤 영향을 미치는지를 분석하는 작업이었습니다. 여기서 로지스틱 회귀와 랜덤 포레스트 모델을 활용해야 했는데, 통계와 머신러닝이 익숙하지 않았던 제게는 큰 도전이었습니다. 특히, 제가 랜덤 포레스트 모델 학습을 담당하게 되었고, 이를 제대로 수행해 내기 위해 주어진 시간 외에도 추가로 학습을 시작했습니다.

통계 강의를 다시 듣고, 관련 서적을 보며 독학했으며, 필요할 때는 구글링으로 정보를 찾아가며 문제를 해결했습니다. **주말에는 멘토님과 1:1 멘토링을 통해 프로젝트와 관련된 구체적인 피드백을 1시간 넘게 주고받기도 했습니다**. 

![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/b83c6770-998f-453b-b327-49fcd2c714bf/image.png)

이러한 노력 끝에 0.9884라는 높은 성능을 가진 랜덤 포레스트 모델을 구축할 수 있었고, 이를 통해 여행 페이지에서 유저의 참여도와 구매 확률 간의 관계를 파악할 수 있었습니다. 이 과정은 저에게 단순히 기술적인 성장을 넘어 **스스로 학습하는 방법을 익히고, 문제 해결 역량을 키우는 중요한 경험**이 되었습니다.

# 최종 프로젝트에 대해 말씀해주세요. 프로젝트를 수행하며 좋았던 점과 아쉬웠던 점은 무엇인가요?
최종 프로젝트에서는 **구글 빅쿼리에서 제공하는 가상의 의류 이커머스 데이터를 활용한 RARRA 분석을 통해 CRM 전략을 제시**했습니다. 프로젝트의 초기 목표는 실무에 가까운 프로젝트를 수행하는 것이었으며, 이를 위해 실무에서 자주 활용되는 분석 프레임워크를 적용하고 A/B 테스트 설계까지 진행하는 방향으로 설정했습니다. 특히, 새로운 유저 유입보다는 기존 고객의 재구매를 유도하는 것이 최근 트렌드라는 점에 착안하여, 재구매 고객의 특성을 분석하고 단일 구매 고객을 재구매 고객으로 전환하기 위한 전략을 제시하는 데 초점을 맞췄습니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/c2561f7b-3ccb-4c30-9db7-df42cf5d8af8/image.png)
 
> **✅ 좋았던 점**
> 초기에는 AARRA라는 일반적인 분석 프레임워크를 활용하려 했지만, 멘토님께서 재구매 분석에는 고객 유지에 중점을 둔 RARRA 프레임워크가 더 적합하다는 조언을 주셨습니다. 이에 더해, 단일 구매 고객이 재구매로 전환되는 '아하 모먼트'를 발견하고 이를 기반으로 A/B 테스트 설계를 진행하는 방향을 제안받았습니다. **멘토님의 실무 경험이 반영된 피드백 덕분에 분석의 초점을 재구매로 더욱 명확히 맞출 수 있었고, 실무적인 관점에서 프로젝트 완성도를 높일 수 있었던 점**이 특히 만족스러웠습니다.

> **✅ 아쉬웠던 점**
> 가상 데이터의 한계로 인해 분석 과정에서 여러 제약이 있었습니다. 데이터 분석에서는 도메인 지식이 중요한데, 가상의 이커머스 데이터이다 보니 도메인에 대한 정보 부족으로 심도 있는 인사이트를 도출하는 데 어려움이 있었습니다. 또한, 데이터의 변수 값이 지나치게 균일하게 구성된 경우가 많아 변별력 있는 분석이 제한되었습니다. 사용자 로그를 담은 이벤트 테이블에서는 유입 경로만 제공되고, 더 세부적인 UTM 파라미터 정보가 부족하여 '아하 모먼트'를 도출하는 데에도 한계가 있었습니다. **만약 실제 기업 데이터를 활용할 수 있었다면 보다 풍부하고 현실적인 분석이 가능했을 것이라는 아쉬움**이 남습니다.

# 데브코스를 시작하며 이루고자 했던 목표는 무엇이었나요? 그리고 그 목표를 어느 정도 달성했다고 느끼시나요?
제가 데브코스를 통해 이루고자 했던 목표는 **의미 있는 프로젝트를 수행하고, 이를 포트폴리오에 담아내어 데이터 분석가로의 경쟁력을 갖추는 것**이었습니다. 저는 비전공자였기 때문에 데브코스에 참여하기 전에는 데이터 분석 프로젝트를 함께할 팀원을 찾기도 어려웠고, 기술적인 역량도 부족해 혼자서 프로젝트를 진행하기에는 한계가 많았습니다.

하지만 데브코스에 참여하면서, **비슷한 배경과 학습 목표를 가진 동료들을 만나 서로의 부족한 점을 보완하며 협력**할 수 있었습니다. 어려운 과제를 함께 해결하고 더 나은 결과물을 만들기 위해 노력했던 과정은 매우 뜻깊은 경험이었습니다.

특히, 프로젝트를 진행하는 동안 **실무 경험이 풍부한 멘토님들로부터 현실적인 조언을 들을 수 있었던 점이 큰 도움**이 되었습니다. 분석 방향을 설정하거나 사용한 모델의 적합성을 검증받는 과정은 물론, 멘토님이 제공해 주신 참고 자료와 피드백을 통해 프로젝트의 완성도를 한 층 더 높일 수 있었습니다. 또한, 기업이 긍정적으로 평가할 수 있는 요소들을 포트폴리오에 반영할 수 있도록 방향성에 대한 구체적인 피드백을 받으며, 보다 경쟁력 있는 포트폴리오를 구성할 수 있었습니다.

결과적으로 총 4개의 프로젝트를 성공적으로 수행하며, 포트폴리오에 담아낼만한 의미 있는 결과물을 만들어낼 수 있었습니다. 이를 통해 처음 목표한 바를 달성하며 데이터 분석가로서 한걸음 더 나아가는 계기가 되었습니다.

# 데브코스에서 특별히 기억에 남는 강사님이 계신가요?
Python Pandas를 강의해 주셨던 스펜서 강사님이 가장 인상 깊었습니다. Pandas를 처음 접했을 때 수업을 잘 따라갈 수 있을지 걱정이 많았는데, 강사님께서 **Series와 DataFrame의 기본 개념부터 심화 내용까지 단계적으로 알기 쉽게 설명**해 주셔서 매우 유익했습니다. 추가 과제 역시 강의의 핵심 내용을 복습할 수 있도록 구성되어 있어 학습 효과를 극대화할 수 있었습니다. 강사님 덕분에 처음 Pandas에 입문했음에도 어렵게 느껴지지 않았고, 오히려 재밌고 흥미롭게 학습할 수 있었습니다.

# 동료들과의 스터디는 어땠나요?
데브코스를 수강하며 무엇보다도 수강생들의 넘치는 열정에 깊은 인상을 받았습니다. 대부분의 동료들이 학습에 진심을 다하는 모습을 보며, 저 역시 더 열심히 해야겠다는 강한 동기부여를 얻을 수 있었습니다.

**매주 강의 중 궁금했던 점들을 묻고 답하는 시간인 데브코스의 'RBF(Random Bit Flip)' 활동도 인상적**이었습니다. 때로는 두 시간 넘게 이야기가 이어질 정도로 학습에 열정적이었던 동료들의 모습이 아직까지 기억에 남습니다. 이외에도 데이터 분야를 먼저 접한 분들이 학습에 도움이 되는 자료를 공유해 주거나, 서로가 서로의 강사가 되어 학습을 도와주는 협력적인 학습 분위기도 특별했습니다.

다른 분야에서 일하다가 데이터 분석을 공부하기 위해 데브코스에 참여한 분들도 많았는데, 현업에서 겪었던 다양한 경험을 공유해 주셔서 다방면의 도메인과 실무 노하우에 대해 전달받을 수 있었습니다. 덕분에 프로젝트를 진행할 때도 실무적인 관점에서 문제를 바라보고 해결할 수 있었습니다. **함께 스터디한 동료들과의 교류는 제게 큰 동기와 배움의 기회를 제공했으며, 덕분에 한층 더 성장**할 수 있었습니다.

![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/6677ba66-9e63-4f2a-a745-9d3c5d1a74be/image.png)
👆 ZEP 회의실에서 모여 프로젝트 회의하던 팀원들의 모습

# 멘토링 경험 중 가장 기억에 남는 순간은 언제였나요?
데브코스에서 4명의 멘토님과 1:1 멘토링을 진행했는데, 모든 멘토링 시간이 유익했지만, 특히 3차 프로젝트 당시 진행했던 멘토링이 가장 기억에 남습니다. 3차 프로젝트를 진행할 때쯤 궁금한 점이 많아져 다른 멘토링 때보다 훨씬 많은 질문을 드렸는데, 멘토님께서 세심하고 친절하게 답변해 주셨던 점이 인상 깊었습니다.

특히, **데이터 분석가의 실무 방식부터 포트폴리오 구성 팁, 최종 프로젝트 데이터셋 확보 방법까지 실질적인 조언**을 얻을 수 있었습니다. 이뿐만 아니라, 도메인이 비슷한 팀원을 찾고 싶다는 저의 요청에 **적합한 팀원을 추천해 주셔서 좋은 협업을 이룰 수 있었던 점**도 좋았습니다.

취준생으로서 실무자의 조언을 직접 들을 기회가 흔치 않은데, 멘토링을 통해 취업 준비에도 실질적으로 도움을 받을 수 있어서 매우 뜻깊었습니다. 매번 미리 질문을 준비하여 멘토링 시간을 최대한 알차게 활용하려고 노력했고, 이를 통해 데이터 분석가로서의 방향성을 더 잘 설정할 수 있었습니다. **데브코스가 끝난 이후에도 멘토님들께 지원서 작성 등과 관련해 조언을 구할 계획**입니다.

# 데이터 분석을 준비하는 분들에게 데브코스를 추천한다면?
데이터 분석 데브코스는 혼자서 데이터 분석가로 취업을 준비하는 데 어려움을 겪는 분들에게 강력히 추천드리는 과정입니다. **데브코스의 핵심은 '동료 성장'과 '멘토링'입니다**.

데브코스에서는 '동행 스크럼'이나 'RBF' 같은 프로그램을 통해 **동료들과 협력하며 학습할 수 있는 기회**를 제공합니다. 이러한 프로그램 덕분에 혼자 학습하는 데서 오는 어려움을 줄이고, 서로 의견을 나누며 주도적으로 배워나갈 수 있었습니다. 데브코스가 끝난 후에도 동료들과 정보를 공유할 수 있는 장이 마련되어 있어, 지속적인 네트워크를 이어나갈 수 있습니다.

또한, 매주 진행되는 'WTL(Weekly Team Learning)'에서는 **멘토님과 팀원들이 함께 모여 프로젝트와 학습 관련 이야기**를 나눌 수 있고, '1:1 멘토링'을 통해서는 깊이 있는 질문을 하거나 개인적인 피드백을 받을 수 있습니다. 이처럼 데브코스에는 데이터 분석가로 빠르게 성장할 수 있는 기회가 풍부하기 때문에, 수강을 고민 중이시라면 꼭 추천드리고 싶습니다.

# 예진 님께서 꿈꾸는 데이터 분석가는 어떤 모습인가요?
저는 데이터 분석을 통해 인사이트를 도출하고 실질적인 해결책을 제시함으로써, **기업이 직면한 문제를 해결하고 긍정적인 방향으로 이끌어가는 데이터 분석가**가 되고 싶습니다.

사실 저는 예술을 전공하며 데이터와는 거리가 먼 사고방식을 가지고 있었습니다. 예술에서는 수치를 통해 표현하려는 시도 자체가 모순적으로 여겨지기도 했고, 저 또한 처음에는 데이터를 지나치게 신뢰하거나 의존하는 것에 거부감을 느꼈던 때가 있었습니다. 하지만 인턴 경험을 통해 실무 환경을 접하면서, 더 나은 결과를 얻기 위해 데이터 기반의 논리적인 결론이 얼마나 중요한지를 깨닫게 되었습니다. 기업의 의사결정에서 데이터가 핵심적인 역할을 한다는 사실을 직접 경험하며, 데이터 분석의 가치를 새롭게 인식하게 되었습니다.

이후 데이터 분석을 배우면서 직감이나 감각에 의존했던 과거의 방식에서 벗어나, 데이터를 기반으로 논리적이고 체계적인 사고를 할 수 있게 된 점에서 큰 만족감을 느끼고 있습니다. 지금은 **데이터를 통해 추상적이었던 문제를 구체적으로 분석하고, 실질적인 해결책을 제시할 수 있는 능력을 키워가는 데 집중**하고 있습니다. 이를 바탕으로 데이터를 통해 기업의 성장과 발전에 기여하는 데이터 분석가로 성장하고자 합니다.

# 새로운 도전을 시작하는 모든 비전공자 수강생분들께 응원의 한마디 부탁드려요.
절대로 늦었다고 생각하지 마세요. 실패에 대한 두려움은 잠시 내려놓고, 자신이 원하는 목표를 향해 도전해 보셨으면 좋겠습니다. 프로그래머스 데이터 분석 데브코스를 통해 많은 것을 배우고 성장하시길 응원합니다. 언젠가 현업에서 만나 반갑게 인사할 수 있는 날을 기대하겠습니다.
 
 
*강의 운영 사정에 따라 세부 프로그램 내용은 변경될 수 있습니다.*
 
 

[![da-coding-test2(729x90).jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/66b6dcc5-75c4-4370-a64d-6a490b4f921e/da-coding-test2%28729x90%29.jpg)](https://school.programmers.co.kr/learn/courses/25254?utm_source=prgm&utm_medium=social&utm_campaign=school_25254_blog&utm_content=25254_banner)

[데브코스 후기] 데브코스를 통해 비전공자에서 데이터 분석가로 성장할 수 있었어요. - 데이터분석 4기 수료생 옥예진 님

풀스택 개발자로의 취업을 준비 중이신가요? 그렇다면 면접에서 자주 등장하는 핵심 질문들을 미리 파악하고 준비하는 것이 큰 도움이 됩니다. 이번 글에서는 풀스택 개발자 면접에서 자주 출제되는 질문들을 정리해 보았는데요. 면접 준비에 실질적인 도움이 될 수 있도록 구성했으니, 성공적인 취업을 위한 발판으로 활용해 보세요!
 
# 풀스택 개발자 면접 질문 및 답변 TIP
## 1. 프로젝트 및 성과 관련 질문
### 💬 개인 프로젝트나 오픈 소스 프로젝트를 진행한 경험이 있으신가요? 어떤 기술 스택을 사용했나요?
프로젝트 경험을 설명하고, 해당 프로젝트에서 사용했던 기술 스택을 언급하면 됩니다. 자신의 기술과 경험을 강조하는 간결하면서도 구체적인 답변을 제시하는 것이 좋습니다.
 
### 💬 개발자로서 성장하기 위해 어떤 학습과 노력을 하고 있나요?
개발 관련 책, 온라인 강의, 블로그를 통해 지식을 쌓고 개인 프로젝트를 통해 새로운 기술을 학습하고 있습니다. 또한 커뮤니티 밋업과 컨퍼런스에 참여하여 동료 개발자들과 네트워킹하며 새로운 아이디어와 인사이트를 얻고 있습니다.
 
위 예시 답변과 같이 자신이 어떤 활동을 통해 어떤 지식을 얻었고, 네트워킹을 통해 어떤 인사이트를 얻고 있는지를 설명할 수 있어야 합니다. 최근에 읽거나 학습한 개발 관련 도서, 블로그, 강의를 미리 생각해두는 것도 좋습니다.
 
### 💬 어떤 방식으로 문제 해결 능력을 향상시키고 있나요?
문제 해결 능력을 향상시키기 위해 알고리즘과 자료 구조를 공부하고, 학습한 것들을 점검하기 위해 프로그래머스에서 문제를 풀고 있습니다. 또한, 다른 개발자들과 함께 코드 리뷰를 진행하며 피드백을 통해 개선점을 찾고 있습니다. 프로젝트를 진행하며 발생하는 문제를 해결하는 과정에서 논리적 사고와 디버깅 능력을 향상시키고 있습니다.
 
위 예시 답변처럼 개발자에게 꼭 필요한 문제 해결 능력, 사고력을 향상시키기 위해 현재 하고 있는 학습이나 활동들을 답변하면 됩니다.
 
### 💬 어려운 과제를 극복하고, 기술적으로 성장한 경험이 있다면 이야기해주세요.
위 답변에 이어 꼬리를 물고 나올 수 있는 질문입니다. 실제 프로젝트나 과제 진행 시 발생했던 이슈와 이를 어떻게 해결했는지 구체적인 답변을 미리 생각해두면 좋습니다. 과제나 프로젝트를 할 때 TIL(Today I Learned) 또는 회고록을 써두면 면접을 준비하면서 참고할 수 있게 때문에 꾸준히 작성하시는 것을 권장 드립니다.
 
### 💬 팀 프로젝트를 진행해 본 경험이 있나요? 팀으로 일할 때 주의해야 할 점은 무엇이라고 생각하나요?
팀 내 의사소통이 중요하다고 생각합니다. 프로젝트 진행 상황을 계속 업데이트하고, 팀원들과 의견을 공유함으로써 업무 시 발생할 수 있는 오해와 혼란을 방지할 수 있었던 경험이 있습니다. 또한 문제가 발생했을 땐 팀원들과 협력하여 해결책을 찾으려고 하는 편입니다. 개인적인 갈등보다는 문제를 해결하고 프로젝트를 성공리에 진행하는 데 초점을 맞추고 있습니다.
 
개발자는 기획, 디자인, CS 등 다양한 부서와 협업하는 직군입니다. 따라서 팀 내, 그리고 타 팀과의 협업 능력이 무엇보다 중요한 역량인데요. 팀 프로젝트 경험을 통해 이러한 역량을 어떻게 쌓았는지 구체적인 사례를 들어 설명하면 신뢰도 높은 답변을 할 수 있습니다.
 
 
## 2. 기술 면접 질문
### 💬 웹 페이지의 로딩 시간을 최적화하기 위해 어떤 기술 또는 방법을 사용하나요?
이미지를 최적화하여 압축을 통해 품질을 유지합니다. CSS 및 JavaScript 파일을 번들링하고 압축하여 HTTP 요청 수를 줄입니다. 브라우저 캐싱을 활용하고, 렌더링을 최적화하면 초기 로딩 시간을 줄일 수 있습니다. 그외 코드 최적화, 지연 로딩 사용 등이 있습니다.
 
### 💬 HTML과 CSS를 사용하여 웹 페이지를 설계하고 스타일링한 경험이 있다면 이야기해주세요.
HTML로 웹 페이지의 기본 구조를 작성하고, 각 섹션을 구조화하여 적절하게 마크업 했습니다. 또 CSS를 사용하여 폰트 스타일 및 색상 레이아웃, 반응형 디자인까지 적용한 경험이 있습니다.
 
이와 같은 답변과 동시에 작업한 작업물에 대한 기획 의도와 접근성을 높이기 위해 고민했던 경험을 추가하면 좋습니다.
 
### 💬 웹 접근성과 웹 표준에 대한 이해도가 어떻게 되나요?
웹 접근성은 웹 콘텐츠 및 애플리케이션을 가능한 모든 유저가 포괄적으로 사용할 수 있도록 만드는 것입니다. 모든 유저가 콘텐츠를 인식하고, 기능을 사용할 수 있어야 합니다.
 
웹 표준은 웹 기술과 규칙의 모음을 의미합니다. 어떻게 구조화하고 디자인하여 잘 동작시킬지 정의한 것인데요. 웹 표준은 웹 페이지 및 웹앱을 일관성 있게 구현하고, 여러 브라우저 및 플랫폼에서 잘 작동하도록 돕는 중요한 요소입니다.
 
### 💬 MEAN/MERN 스택이 무엇인가요?
웹 애플리케이션을 개발하는 데 사용되는 기술 스택의 약어입니다. MEAN 스택은 MongoDB, Express.js, Angular, Node.js가 있으며, MERN 스택은 MongoDB, Express.js, React 및 Node.js로 이루어져 있습니다. 모든 구성 요소가 JavaScript로 작성되어 있으며, 클라이언트와 서버 간의 데이터 교환을 용이하게 하는 도구입니다.
 
### 💬 웹 애플리케이션 보안을 강화하기 위해 어떤 조치를 취할 수 있을까요?
HTTPS를 사용하고, SSL/TLS 인증서를 설치하여 데이터 전송을 암호화할 수 있습니다. 사용자 인증 및 권한을 관리하여 무단 액세스를 방지합니다. 사용자 입력을 효과적으로 필터링하고, SQL 인젝션 공격을 방지합니다. 사용 중인 모든 소프트웨어와 라이브러리를 최신 상태로 유지하고, 보안 패치 및 업데이트를 적용합니다.
 
### 💬 클래스형 컴포넌트와 함수형 컴포넌트의 차이는 무엇일까요?
클래스형 컴포넌트는 `State`, 라이프사이클 메서드를 사용할 수 있으며, `this` 키워드를 통해 클래스 내부의 메서드나 상태에 접근합니다. 반면, 함수형 컴포넌트는 훨씬 간결하고 읽기 쉬운 구조를 가지며, React Hooks를 통해 상태 관리와 부수 효과 처리가 가능합니다. 또한 최적화 작업을 적용하기도 용이합니다.
 
### 💬 SQL Injection은 무엇이며 어떻게 방지할 수 있나요?
SQL Injection은 애플리케이션의 입력 필드를 통해 SQL 쿼리를 주입하여 데이터베이스를 조작하거나 민감한 정보를 노출시키는 공격입니다. SQL Injection을 방지하기 위해 매개 변수화된 쿼리 또는 준비된 문을 사용하고 입력 유효성 검사를 수행해야 합니다. ORM 라이브러리를 사용하여 SQL 쿼리 대신 프로그래밍 언어의 객체로 데이터베이스 작업을 수행하거나, 데이터 검증 및 이스케이핑을 수행합니다.
 
### 💬 NoSQL 데이터베이스의 목적은 무엇이며 언제 사용하나요?
NoSQL 데이터베이스는 구조적 유연성과 확장성을 갖추도록 설계되었습니다. 비구조화 또는 반구조화 데이터를 처리하거나 쉽게 수평 확장해야 하는 경우 적합합니다. 대량의 데이터를 다뤄야 하거나, 데이터 모델이 자주 변경되는 경우에 사용되지만, NoSQL 데이터베이스를 선택할 때에는 데이터 모델, 성능, 일관성, 복제, 쿼리 언어 등 여러 측면을 고려해야 합니다.
 
### 💬 상태 관리는 무엇이고, 상태 관리를 해야 하는 이유는 무엇일까요?
상태 관리는 애플리케이션 내에서 데이터를 효과적으로 관리하는 것을 말합니다. 상태는 애플리케이션의 모든 데이터와 인터페이스의 현재 상태를 나타내는데요. 상태 관리를 하면 복잡한 애플리케이션을 효과적으로 다룰 수 있고, 데이터 흐름을 체계적으로 관리하여 애플리케이션을 확장하고 유지하기 쉬워집니다.
 
 
풀스택 개발 면접을 준비하시느라 다양한 참고 자료를 살펴보고, 예상 질문에 대비하며 열심히 노력하고 계실 텐데요. 면접에서는 이력서와 포트폴리오를 바탕으로 한 질문이 많이 나오는 만큼, 단순히 답변을 외우기보다는 실제 프로젝트나 코딩 경험 속에서 느낀 점, 직면했던 문제와 그 해결 과정, 이를 통해 얻은 인사이트나 기술적 성장에 대해 스스로 정리해 보는 것이 중요합니다.
 
또한, 풀스택 개발자는 프론트엔드와 백엔드를 모두 아우르기 때문에 기술뿐 아니라 커뮤니케이션 능력과 문제 해결 능력도 중요한 평가 요소로 작용합니다. 따라서 다양한 협업 경험을 통해 팀워크와 소통 역량을 함께 키워나가시길 권장 드립니다. 취업을 준비하고 계신 모든 예비 개발자 여러분, 그동안의 노력이 좋은 결실로 이어지길 진심으로 응원합니다! 😊
 
 
[![full-coding-test2(729x90).jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/e92b7851-7b33-4324-9b32-b256dae87b5c/full-coding-test2%28729x90%29.jpg)](https://school.programmers.co.kr/learn/courses/24941?utm_source=prgmblog&utm_medium=social&utm_campaign=school_FS_blog&utm_content=FS_banner)

풀스택 개발자 면접 준비하기: 질문 및 답변 TIP

심화 단계의 난이도 높은 과제에 도전하며 기술적 성장을 이뤄낸 백엔드 단기심화 2기 수료생 전수연 님을 만나보았습니다.
실무에 가까운 프로젝트를 수행하며 어떤 문제를 마주했고, 이를 어떻게 정의하고 해결해 나갔는지 인터뷰를 통해 생생하게 들려주셨습니다.
단기심화 과정을 완주한 후 수연 님에게 찾아온 변화가 궁금하다면, 지금 바로 인터뷰에서 확인해보세요!
 
 
## 안녕하세요. 간단한 자기소개 부탁드립니다.
안녕하세요. 컴퓨터 공학을 전공하고 약 5년 정도 개발자로 일하다 **백엔드 단기심화 데브코스 2기**에 합류하게 된 전수연이라고 합니다.
 
다른 직무 개발을 약 5년 정도 하다가, 웹 백엔드 직무에 흥미와 관심이 생겨 백엔드로 직무 전향을 하며 데브코스에 참여하게 되었습니다.
 
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/25da6cda-449f-4148-bc54-d8ddb272239f/image.png)
 
 
## 백엔드 단기심화 과정을 선택하게 된 계기는 무엇인가요?
타 부트캠프를 통해 스프링 기반의 웹 백엔드 개발을 처음 시작했습니다. 해당 과정을 통해 백엔드의 기초 지식이나 웹 개발에 대한 전반적인 이해는 쌓았지만, 실무 경험이 부족함을 느꼈습니다.
 
백엔드 단기심화 데브코스의 커리큘럼과 강의 구성이 이러한 한계를 보완해 줄 수 있을 것이라 생각해 지원하게 되었습니다.
 
 
## 타 기관도 많지만, 특별히 프로그래머스 데브코스를 선택한 이유는 무엇인가요?
프로그래머스는 개발자라면 무조건 찾게 되는 플랫폼이라고 생각해요. 그런 프로그래머스에서 운영하는 데브코스라면 **커리큘럼의 완성도와 현업 실무 반영도가 높을 것이라는 신뢰**가 있었습니다.
 
실제로 단기심화 과정의 커리큘럼을 보니 현업에서 실제로 사용하는 기술 스택을 다루고 있었고, 무엇보다 **현업 개발자 멘토님의 코드 리뷰와 피드백을 받을 수 있다는 점이 가장 큰 매력**이라 느꼈습니다.
 
강의와 세미 프로젝트는 온라인으로 진행되었지만, **최종 프로젝트부터는 오프라인으로 진행되어 다양한 팀과 교류할 수 있다는 점도 좋았습니다**. 이를 통해 다양한 동료들과 소통하며 개발자 네트워크를 형성할 수 있었습니다.
 
 
## 백엔드 단기심화 과정의 난이도는 실제로 어땠나요? 수강 전 기대와 비교했을 때 어땠는지도 솔직하게 말씀해주세요.
단기심화 과정인 만큼 시간이 부족할 수 있을거라 예상했어요. 막상 프로젝트를 시작해 보니 초반에는 비교적 여유가 있다고 느꼈는데, 역시나 마감이 가까워질수록 시간이 부족했던 것 같아요.
 
짧은 기간 안에 강사님과 멘토님의 피드백을 반영하며 실무와 유사한 수준의 서비스를 구현하고자 하는 목표가 생기다 보니, 시간이 더 부족하다고 느꼈던 것 같습니다.
 
특히 MSA 환경에서 서비스 간 통신, 분산 트랜잭션 관리 등 **실무 수준의 기술적 도전 과제**들이 많아서 난이도 자체는 높았습니다. 하지만 그만큼 집중적으로 몰입해서 빠른 속도로 배울 수 있었고, **실제 운영 환경에서 고려해야 할 요소들을 짧은 기간 안에 경험**할 수 있어서 개인적으로는 매우 만족스러웠습니다.
 
 
## '이건 진짜 심화 과정이다'라고 느꼈던 학습 포인트가 있었나요?
'이건 진짜 심화 과정이다'라고 느꼈던 순간은 **멘토님, 팀원들과 함께한 코드 리뷰 시간**이었습니다.
 
처음에는 주기적으로 멘토님께 코드 리뷰를 받는 것이 부담스럽게 느껴지기도 했습니다. 제가 짠 코드를 누군가가 직접 보고 평가하는 경험이 익숙하지 않았거든요. 하지만 실제로 리뷰를 받아보니, **이 과정이 진짜 실력을 키울 수 있는 방법**이라는 것을 깨달았습니다.
 
제가 구현한 서비스에 대해 "기능은 잘 동작하네요"에서 끝나는 것이 아니라, "트랜잭션 범위가 너무 크지는 않은가요?", "이 예외 상황은 어떻게 처리하셨나요?"와 같은 질문을 통해 제가 미처 고려하지 못했던 부분들을 짚어주셨습니다.
 
이후에는 팀원들과도 GitHub에 머지하는 시간을 가지며 코드 리뷰를 통해 의견을 나눴고, 결과적으로 프로젝트의 품질을 높일 수 있었습니다.
 
 
## 백엔드 단기심화 과정이 포트폴리오 측면에서 어떤 도움이 되었나요?
이전 포트폴리오는 기능 구현에 집중되었다면, 단기심화 과정을 통해 만든 프로젝트는 **왜 이 기술을 선택했는지, 어떤 문제를 어떻게 해결했는지를 명확히 설명할 수 있는 포트폴리오**가 되었습니다.
 
특히 기술 선택 과정에서 팀원들과 함께 고민하는 시간을 많이 가졌어요. 예를 들어 서비스 간 통신 방법을 정할 때 처음에는 단순하게 접근했지만, 팀원들과 논의를 거치며 결제 시스템에 문제가 발생하면 주문 시스템도 함께 멈추는 문제나, 결제 처리가 지연될 경우 사용자가 계속 대기해야 하는 상황 등 여러 케이스를 발견하게 되었습니다.
 
이에 따라 즉시 응답이 필요한 경우와 시간이 걸리더라도 안정적으로 처리해야 하는 경우를 구분해 설계하기로 결정했고, 이러한 선택의 배경과 이유를 문서로 정리해 남겼습니다.
 
또한 동시성 제어 방식 역시 여러 방법을 비교하며 팀 내에서 충분히 논의했습니다. 각 방식의 장단점을 따져보고, 저희 서비스 특성상 데이터 정확성이 가장 중요하다는 결론을 내려 이에 맞는 방식을 선택했습니다. **이러한 기술적 의사결정 과정 자체를 포트폴리오에 담을 수 있었고, 각 기술 선택에 대해 구체적으로 설명**할 수 있게 되었습니다.
 
이외에 다른 고민 사항들에 대해서도 모두 문서로 정리하며, 프로젝트를 진행했습니다.
 
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/b99c3a2d-8ce2-4678-b355-a65ba32e29f0/image.png)
 
 
## 백엔드 단기심화 과정에서 진행한 프로젝트는 어떤 서비스였나요? 맡은 역할과 기술적 도전에 대해서도 공유해주세요.
저희 팀은 여러 판매자가 공동구매 상품을 등록하고, 소비자는 선착순·수량 조건에 맞춰 참여할 수 있는 **마이크로서비스 기반 이커머스 서비스** '**0909 공구공구**'를 만들었습니다.
 
단기심화 과정에서 이커머스 서비스를 주제로 프로젝트를 진행하기 때문에 어떤 주제가 차별화될 수 있을지 고민했고, 공동구매라는 도메인을 선택함으로써 동시성 제어, 재고 관리, 선착순 처리 등 기술적으로 도전할 만한 요소들을 담을 수 있었습니다.
 
저는 **주문 서비스와 상품·공동구매 관리 서비스를 담당**했으며, **주문 생성부터 결제 서비스와의 연동, 주문 상태 관리까지 전체 흐름을 구현**했습니다. 결제는 팀원이 별도 서비스로 개발했고, 두 서비스는 Kafka를 통한 이벤트 기반 통신으로 협업하도록 설계했습니다.
 
특히 Spring Batch를 통해 공동구매 시작 및 마감 처리 자동화를 구현하는 것, 동시에 여러 사용자가 같은 공동구매에 참여할 때 발생할 수 있는 동시성 문제를 해결하는 것, 그리고 비동기 환경에서 결제 실패나 타임아웃 같은 예외 상황을 처리하는 것이 가장 큰 기술적 도전이었습니다.
 
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/5703c564-7eba-4fb1-b45b-a52c1d598c25/image.png)
 
 
## 프로젝트를 진행하며 어려운 과제에 도전해 기술적으로 크게 성장한 순간이 있다면 말씀해주세요.
이커머스 서비스 프로젝트였기 때문에, 프로젝트를 진행하며 서비스의 전반적인 흐름을 이해하는 것이 중요하다고 느꼈습니다. 상품 선택 - 주문 - 결제로 이어지는 시스템이 간단하게 보여지지만, 실제로는 그 안에 많은 흐름이 있고, 특히 **MSA 환경에서 여러 서비스에 걸친 트랜잭션을 안전하게 처리하는 것이 가장 큰 도전 과제**였습니다.
 
가장 기억에 남는 경험은 주문 - 결제 흐름을 구현했던 부분입니다. 초기에는 주문 생성 과정 안에서 결제까지 모든 흐름을 처리했습니다. 주문 생성 후 결제 서비스 API를 호출하고, 결제 처리가 완료되면 Kafka 이벤트로 주문 상태를 확정하고, 실패 시에는 주문 취소와 재고 복구를 하는 보상 트랜잭션을 구현했습니다. 또한 주문 멱등성 키를 도입해 주문의 중복 생성을 방지했습니다.
 
또 하나 크게 성장했다고 느낀 순간은 **코드 설계를 개선했던 경험**입니다. 초기에는 주문 서비스 안에 주문 생성, 재고 확인, 결제 요청, 이벤트 처리 등 모든 로직이 하나의 서비스 클래스에 몰려있었습니다. 기능은 동작했지만 하나의 트랜잭션에 너무 많은 로직이 들어가면서, 트랜잭션이 길어지고 테스트도 어려웠습니다. 멘토님께서 "트랜잭션을 분리해보라"는 조언을 주셨고, 이를 계기로 주문 생성, 재고 관리, 이벤트 처리를 각각 독립적인 서비스와 트랜잭션으로 분리했습니다.
 
 
## 멘토링 중 인상 깊었던 코드 리뷰나 피드백은 무엇이었나요? 그 멘토링을 통해 이후 어떤 변화가 있었나요?
멘토님께서 해주신 말씀 중 가장 인상 깊었던 조언은, MSA 아키텍처이기 때문에 기능의 담당자와 서비스 모듈이 나뉘어져 있지만, 서비스 담당자와 지속적인 커뮤니케이션을 통해 문제가 될 수 있는 부분과 에러 상황에 대비할 수 있는 코드를 구현할 수 있어야 한다는 것이었습니다.
 
실제로 팀 프로젝트를 진행하며 설계에 대한 부분은 회의를 통해 결정했지만, 구현 단계에서는 각자의 기능을 구현하느라 다른 서비스 모듈의 상황까지 충분히 고려하지 못한 부분이 있었습니다.
 
**멘토님의 조언을 통해 저희 팀은 테스트 코드 작성을 통해 예외 상황을 미리 검증하는 방식을 도입**했습니다. "정상 케이스만 동작하는 코드"가 아니라, "예외 상황에서도 안전한 코드"를 작성하기 위해 다양한 실패 시나리오에 대한 테스트 케이스를 정의하고 이에 대한 테스트 코드를 작성했습니다.
 
그 과정에서 팀원들과 "이 서비스가 실패하면 다른 서비스는 어떻게 대응해야 하는가"에 대한 논의가 자연스럽게 이루어졌고, 각 서비스의 에러 응답 스펙 또한 명확하게 정의할 수 있었습니다. **그 결과 실제 통합 단계에서 발생하는 오류가 크게 줄었고, 배포 전에 대부분의 엣지 케이스를 미리 발견하고 대응**할 수 있었습니다.
 
이를 통해 테스트 코드가 단순히 버그를 찾는 도구가 아니라, 팀 간 커뮤니케이션 도구이자 시스템 안정성을 보장하는 문서 역할도 한다는 것을 깨달았습니다.
 
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/758696b0-b237-4ee7-9cf8-b2211ea2e87b/image.png)
⬆️ 각자 구현한 서비스 모듈의 테스트 케이스 정의
 
 
## 백엔드 단기심화 과정이 취업(또는 이직) 준비에 있어 어떤 도움이 되었나요?
가장 큰 도움은 **실무 수준의 포트폴리오**를 만들 수 있었다는 점입니다.
 
단기심화 프로젝트를 통해 MSA, Kafka, 분산 트랜잭션 같은 실무 기술을 실제로 적용한 경험을 담을 수 있게 되었습니다.
 
그리고 멘토님들의 코드 리뷰뿐만 아니라 팀원들과의 협업도 큰 도움이 되었습니다. 각자 맡은 서비스를 구현하면서 서로 모르는 부분을 알려주기도 하고, 기술적인 고민을 나누며 **혼자서는 배우기 어려웠을 부분들을 자연스럽게 습득**할 수 있었습니다.
 
특히 팀원들이 자신의 도메인에서 적용한 기술이나 해결 방법을 공유해줘서 간접적으로 많이 배울 수 있었고, 이런 경험들이 모여 더 풍부한 포트폴리오를 완성할 수 있었습니다.
 
 
## 백엔드 단기심화 과정은 어떤 분들에게 잘 맞는 과정이라고 생각하시나요?
백엔드 기초는 어느 정도 갖추었지만, **실무 수준의 기술 스택과 아키텍처 경험이 부족한 분들에게 정말 잘 맞는 과정**이라고 생각합니다. 특히 Spring Boot로 기본적인 기능은 만들어봤지만, MSA나 분산 시스템, 이벤트 기반 아키텍처 등 **실무에서 요구하는 기술들을 직접 적용해보고 싶은 분들에게 추천**합니다.
 
빠른 학습을 통해 짧은 기간 내에 집중적으로 성장하고 싶은 분들에게도 적합한 과정인 것 같습니다. 단기심화라는 과정명처럼 기간은 짧지만 그만큼 학습 밀도는 높고, 현업 멘토님들의 코드 리뷰와 피드백을 통해 실무 감각을 빠르게 익힐 수 있습니다.
 
백엔드 개발을 처음 시작하시는 분들보다는 기본기를 갖춘 상태에서 한 단계 더 성장하고 싶은 분들에게 더 잘 맞는 과정이라고 생각합니다. 팀 프로젝트 경험이 있거나 협업에 익숙하신 분들이라면 더 큰 시너지를 낼 수 있을 것 같습니다.
 
 
## 백엔드 단기심화 과정을 마친 지금, 어떤 개발자로 성장하고 싶으신가요?
데브코스를 시작할 때는 단순히 새로운 기술을 경험해보자는 생각이 컸습니다. 하지만 과정을 마친 지금은 **주어진 문제를 정의하고 해결할 수 있는 개발자**가 되고 싶다는 구체적인 목표가 생겼습니다.
 
백엔드 단기심화 과정을 거치며 이전에는 '좋다고 하니까 사용하는 기술'이었다면, 이제는 왜 이 기술이 필요한지, 어떤 문제를 해결하기 위한 선택인지부터 고민하게 되었습니다. 앞으로도 문제의 본질을 이해한 뒤 적절한 기술로 해결하는 개발자가 되고 싶습니다.
 
 
## 수강을 고민 중인 분들께, 추천의 한마디나 현실적인 조언 부탁드립니다.
백엔드 단기심화 과정은 짧은 기간 안에 프로젝트를 완성해야 하기 때문에 시간 관리와 체력 관리가 매우 중요합니다. 그만큼 쉽지 않은 과정이지만, **집중적으로 성장할 수 있는 기회**인 것 같습니다.
 
솔직히 말하자면, 새로운 기술 스택을 배우면서 동시에 프로젝트를 진행하고, 이를 바로 적용해야 하기 때문에 부담이 적지 않습니다. 하지만 이 과정을 완주하고 나면, "이 정도 수준의 프로젝트를 만들 수 있구나"라는 자신감과 함께 **실무에서도 바로 통하는 역량**을 갖출 수 있다고 느꼈습니다.
 
과정을 수강하며 새롭게 배우는 기술에 대한 학습을 충분히 하고, 이를 프로젝트에 적용해보시기를 추천드립니다. 팀원들과의 소통도 적극적으로 이어가며 팀 프로젝트를 통해 협업 역량을 키워보세요! 혼자서는 **경험하기 어려운 실무 수준의 코드 리뷰와 협업 경험이 이 과정의 가장 큰 자산**이 될 수 있다고 생각합니다.
 
백엔드 개발자로서 한 단계 더 성장하고 싶고, 포트폴리오의 완성도를 높이고 싶다면 꼭 도전해보시길 추천드립니다!
 
 
*강의 운영 사정에 따라 세부 프로그램 내용은 변경될 수 있습니다.*
 
 
[![DEV-BE-DEEP-coding-test-02(1456x180).jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/e3332bf8-d582-42d1-9a62-7f39fbcaf445/DEV-BE-DEEP-coding-test-02%281456x180%29.jpg)](https://school.programmers.co.kr/learn/courses/25629?utm_source=prgmblog&utm_medium=social&utm_campaign=school_25629_sales&utm_content=blog_banner_13335)

[데브코스 후기] 백엔드 단기심화, 짧지만 가장 밀도 높았던 성장의 시간 - 백엔드 단기심화 2기 전수연 님

비전공자로 시작해 AI 서비스 개발, 그리고 기업 협업까지 이어진 데브코스 수료생의 이야기! 프로그래머스 백엔드 데브코스 수료생 백상현 님을 만나보았습니다.
 
상현 님은 데브코스 과정 중 AI 기반 상담 앱 ‘마인드톡’을 직접 개발하고, 이를 계기로 AI 솔루션 기업과의 협업까지 이어졌다고 하는데요.
 
비전공자에서 1인 서비스 개발자로, 더 나아가 AI를 실무에 활용하는 백엔드 개발자로 성장하기까지! 상현 님의 생생한 경험을 지금 확인해보세요.
 

<div style="position: relative; max-width: 100%; padding-bottom: 56.25%; height: 0;"><iframe width="560" height="315" src="https://www.youtube.com/embed/-u71GyH5cGY?si=Th80pOWSHPPwseFr" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen="" style="position: absolute; position: absolute; top: 0; left: 0; width: 100%; height: 100%;"></iframe></div>

 
 
## 간단한 자기 소개 부탁드립니다!
안녕하세요. 백엔드 데브코스 6기 수료생 백상현입니다. 저는 금융보험을 전공한 비전공자 출신으로 2025년 10월에 프로그래머스 백엔드 데브코스를 수료했습니다.
 
데브코스 수료 이후에는 **제가 직접 만든 AI 상담 앱 '마인드톡'을 계기로 AI 모델 및 솔루션 제공 기업과 협업 프로젝트에 참여**하며 국산 AI 모델 기반의 챗봇을 만들었습니다.
 
지금은 외주 프로젝트를 마무리하고 취업을 준비하면서 새로운 개인 프로젝트들도 계속 진행하고 있습니다. **최근 '사주박사'라는 앱을 출시**했는데, 궁금하신 분들은 플레이스토어나 앱인토스에서 확인해보시면 좋을 것 같습니다 🙂
 
 
![스크린샷 2026-04-29 오후 5.17.22.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/0935253b-9755-4892-bd0c-d1cbae80177e/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202026-04-29%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%205.17.22.png)
⬆️ 상현 님이 출시한 '사주박사' 앱
 
 

 
 
## 개발을 처음 시작하게 된 계기는 무엇인가요? 특히 비전공자로서 개발에 관심을 가지게 된 배경이 궁금합니다.
제가 개발을 처음 시작하게 된 계기는 **우연히 ChatGPT를 활용해서 바이브 코딩으로 간단한 웹사이트를 만들어본 경험**이었습니다. 코드를 한 줄도 모르는 상태였는데도, AI와 함께 뭔가를 직접 만들 수 있다는 게 신기하고 재밌더라고요. 그때 '내 손으로 무언가를 만든다'는 감동을 처음 느꼈고, 그 경험이 개발에 대한 관심으로 이어졌습니다.
 
이후 독학으로 조금씩 개발 공부를 시작하게 되었습니다. 저는 개발과 전혀 다른 금융보험을 전공했지만, 오히려 새로운 분야에 도전한다는 점이 더 설레게 느껴졌던 것 같습니다.
 
 
## 데브코스에 참여하게 된 가장 큰 이유는 무엇이었나요?
처음에는 독학으로 개발 공부를 시작했는데, 혼자 공부하다 보니 어느 순간 한계를 느끼게 되었습니다. 지금 내가 맞는 방향으로 가고 있는지 판단하기도 어려웠고, **체계적인 커리큘럼과 함께 성장할 동료가 필요**하다고 느꼈습니다.
 
여러 교육 과정을 비교해 봤는데, 프로그래머스 데브코스는 **실무 중심 커리큘럼과 프로젝트 경험을 쌓을 수 있다는 점에서 가장 매력적**이었습니다. 특히 백엔드 개발에 집중된 과정이라는 점이 제가 원하는 방향과 잘 맞았고, 수료 후 실무에서 필요한 역량을 갖출 수 있을 것 같아 선택하게 되었습니다.
 
 
## 데브코스 수료 후 기업과 협업을 진행했다고 들었습니다. 어떤 서비스를 만들었고, 어떻게 협업까지 이어지게 되었나요?
데브코스 참여 중 **'마인드톡'이라는 AI 상담 앱**을 직접 만들었습니다. 다양한 개성을 가진 AI 캐릭터들과 대화하며 상담을 받을 수 있는 앱이고, **기획부터 개발, 배포까지 혼자서 진행**했습니다.
 
앱을 출시한 이후 한 AI 모델 및 솔루션 제공 기업의 대표님께서 마인드톡을 보시고 직접 연락을 주셨습니다. 1인 개발자가 AI 기반 서비스를 완성도 있게 만들었다는 점에 관심을 가져주셨고, **그 계기로 국산 AI 모델 기반 챗봇을 함께 개발하는 프로젝트 협업**으로 이어지게 되었습니다.
 
 
![스크린샷 2026-04-29 오후 5.19.34.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/5eb58b3d-2dca-4b7c-aaec-206bed18d3ea/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202026-04-29%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%205.19.34.png)
![스크린샷 2026-04-29 오후 5.20.21.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/57310a93-f4c6-4ca9-8cce-a6e087cb92ae/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202026-04-29%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%205.20.21.png)
⬆️ 상현 님이 직접 만들고 배포까지 완료한 AI 기반 상담 앱 '마인드톡'
 
 
## 기업과의 협업 프로젝트를 수행하는 데 있어 백엔드 데브코스에서 배웠던 부분이 어떻게 도움이 되었나요?
데브코스에서 배운 **백엔드 기본기가 외주 업무에서 정말 큰 도움**이 되었습니다. 특히 **Spring Boot 기반 서버 개발, RESTful API 설계, 데이터베이스 설계와 같은 핵심 역량**을 데브코스에서 탄탄하게 다졌기 때문에, 실무에서 요구하는 수준의 코드를 작성할 수 있었습니다.
 
또한 데브코스에서의 **팀 프로젝트 경험 덕분에 실무 협업 프로세스에 빠르게 적응**할 수 있었고, 코드 리뷰나 Git 브랜치 전략 등 실무적인 부분도 자연스럽게 수행할 수 있었습니다.
 
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/c940d688-734c-47bd-9983-1e29a402d105/image.png)
⬆️ 기본기를 탄탄히 다질 수 있었던 백엔드 데브코스
 
 
## 비전공자에서 개발자로, 그리고 1인 서비스 개발까지 쉽지 않은 커리어를 이어오고 계신데요. 이렇게 빠르게 성장할 수 있었던 가장 큰 이유는 무엇이라고 생각하시나요?
가장 큰 이유는 **'일단 해보자'는 마인드와 꾸준함**이라고 생각합니다. 저는 비전공자이기 때문에 모르는 것이 당연하다고 생각했고, 모르면 찾아서 배우면 된다는 마음으로 임했습니다. 또한 **AI를 적극적으로 활용한 것도 성장 속도를 높여준 중요한 요소**였습니다.
 
무엇보다 **배운 것을 바로 실전에 적용해 본 경험이 결정적**이었습니다. 데브코스에서 배운 내용을 '마인드톡'이라는 실제 서비스에 적용하면서, 이론과 실전의 간극을 빠르게 좁힐 수 있었습니다.
 
 
## 혼자 서비스를 만들면서 가장 어려웠던 점과 가장 보람 있었던 순간은 언제였나요?
혼자 서비스를 만들면서 가장 어려웠던 점은 **모든 의사결정을 혼자 해야 한다는 것**이었습니다. 기술 스택 선정부터 UI/UX 설계, 배포 환경 구성까지 모든 판단을 스스로 해야 했습니다. 특히 서비스 배포 이후 발생하는 버그나 서버 이슈를 실시간으로 대응하는 것도 만만치 않았습니다.
 
하지만 가장 보람 있었던 순간은 앱스토어에 마인드톡을 출시하고 **실제 사용자들이 생기기 시작했을 때**였습니다. 내가 만든 서비스를 누군가가 실제로 사용하고 있다는 것 자체로 엄청난 보람이었고, 이 경험이 기업과의 협업으로까지 이어진 것이 가장 뿌듯합니다.
 
 
## 데브코스 참여 중 특히 기억에 남는 프로젝트나 경험이 있다면 무엇인가요?
최종 프로젝트가 가장 기억에 남습니다. **공공 API를 활용해서 외국인 관광객에게 한국 관광지를 추천해 주는 챗봇 서비스를 개발**했습니다.
 
이 프로젝트를 통해 단순히 코드를 작성하는 것을 넘어서, 팀원들과 역할을 분담하고 Git으로 협업하는 방법, 그리고 API를 설계하고 연동하는 과정 등 실무에 가까운 경험을 쌓을 수 있었습니다.
 
특히 백엔드 아키텍처를 직접 설계하고 팀원들과 코드 리뷰를 진행하면서 협업의 중요성을 많이 배울 수 있었습니다.
 
 
### 🔍 최종 프로젝트 보러가기
* [GitHub (백엔드)](https://github.com/Mrbaeksang/korea-travel-guide-backend)
* [GitHub (프론트엔드)](https://github.com/Mrbaeksang/korea-travel-guide-frontend)
 
 
## 비전공자로서 개발자 부트캠프에 참여하며 어려웠던 부분은 무엇이고, 어떻게 극복하셨나요?
비전공자로서 가장 힘들었던 점은 모든 것이 처음이라는 점이었습니다. 전공자에게는 익숙한 용어나 개념들이 저에게는 완전히 새로운 세계였어요. 그래서 저는 남들보다 더 많이 공부하는 방법을 선택했습니다. 
 
수업이 끝나면 반드시 복습을 했고, 이해가 안 되는 부분은 추가로 찾아보면서 정리했습니다. 심지어 산책을 할 때도 ChatGPT에게 계속 꼬리 질문을 하면서 개념을 확인했습니다. 지금 돌아보면 **결국 양으로 질을 만든 과정**이었다고 생각합니다. 포기하지 않고 꾸준히 하다 보니 어느 순간 따라잡을 수 있었습니다.
 
 
## 백엔드 데브코스를 수강하면서 가장 크게 성장했다고 느낀 순간은 언제였나요?
프로젝트에서 저의 역할이 달라졌을 때 성장을 느꼈던 것 같습니다. 초반 1차 프로젝트 때는 팀원들을 따라가기에 급급한 상태였는데요. 후반부로 갈수록 제가 주도적으로 기능을 설계하고 구현하고, 또 팀원들에게 설명하는 모습을 발견하게 되었습니다.
 
처음에는 코드 한 줄 작성하는 것도 막막했는데, **어느 순간 팀 프로젝트에서 아키텍처를 제안하는 역할**을 하고 있더라고요. 그 변화를 스스로 체감했을 때 “내가 정말 많이 성장했구나” 하고 느꼈습니다.
 
 
## 개발 과정에서 AI를 어떻게 활용하고 계신지도 궁금합니다.
저는 특정 도구 하나만 고집하기보다는 **최신 AI 동향을 꾸준히 팔로우하면서 다양한 도구들을 계속 시도**해보는 편입니다. 현재는 Claude Code를 가장 많이 활용하고 있고, **코드 작성이나 리팩토링, 디버깅 등 개발 전반에 걸쳐 활용**하고 있습니다. OpenAI Codex도 함께 사용하며 상황에 따라 적합한 도구를 선택합니다.
 
AI를 단순히 코드 생성 도구로만 쓰기보다는 **아키텍처 설계를 같이 고민하거나 새로운 기술을 학습할 때 질문을 계속 던지며 깊이 있게 이해하는 용도**로도 적극 활용하고 있습니다. 새로운 AI 도구나 업데이트 소식이 있으면 바로 써보면서 개발 워크플로우에 어떻게 녹일 수 있을지 항상 고민하는 편입니다.
 
 
## 카카오 AI TOP 100 본선 진출을 하셨다고 들었습니다. 해당 경험에 대해서도 소개해주실 수 있으실까요?
AI를 활용한 개발 경험을 쌓으면서 AI 활용 능력을 객관적으로 증명해 보고 싶었는데, 마침 **카카오 AI TOP 100 대회**가 열린다는 소식을 듣고 참가하게 되었습니다. 이 대회는 다양한 문제들이 주어지고, AI를 자유롭게 활용해서 해결하는 방식이었습니다.
 
평소에 AI 도구들을 개발에 적극적으로 활용해왔던 경험이 도움이 되었고, **문제를 분석하고 AI를 활용하는 전략을 세워서 본선까지 진출**할 수 있었습니다.
단순히 AI에게 답을 맡기기보다는 문제를 정확히 이해하고, **AI와 협업하는 방식이 좋은 평가를 받았다고 생각**합니다.
 
 
[![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/29f415de-bc1e-47d4-8310-0ac9851f1da3/image.png)](https://www.kakaocorp.com/page/detail/11816)
⬆️ AI를 활용하여 새로운 문제해결 방식을 실험하는 '카카오 AI TOP 100'
 
 
## 데브코스를 수강하기 전과 비교했을 때, 지금 가장 달라진 점은 무엇인가요?
문제를 대하는 태도입니다. 데브코스 참여 이전에는 모르는 것이 나오면 막막하고 두려웠는데, **지금은 뭐든지 부딪히면 알아보고 해결하는 힘**이 생겼습니다.
 
기술적으로는 당연히 많이 성장했지만 그보다 더 중요한 건 개발자로서의 사고방식이 달라진 것입니다. **문제를 분석하고, 원인을 찾고, 해결책을 시도하는 과정을 자연스럽게 반복**하게 되었어요.
 
또한 혼자만의 생각에 갇히지 않고, 다른 사람의 코드를 읽고 피드백을 주고받는 과정이 얼마나 중요한지도 알게 되었습니다.
 
 
## 마지막으로, 데브코스 수강을 고민하고 있는 분들께 한마디 부탁드립니다!
고민하고 계신다면 일단 시작해 보시라고 말씀드리고 싶습니다. 저도 금융보험 전공의 완전한 비전공자였지만 데브코스를 통해 백엔드 개발자로 성장할 수 있었고, 수료 이후에는 직접 앱을 출시하고 기업과 협업하는 경험까지 하게 되었습니다.
 
중요한 건 전공이나 배경이 아니라 **얼마나 열정을 가지고 꾸준히 몰입하느냐**입니다. 데브코스는 체계적인 커리큘럼과 함께 성장할 동료들, 그리고 실무 경험을 쌓을 수 있는 좋은 환경을 제공해 주는 과정입니다.
 
완벽하게 준비된 상태에서 시작하는 사람은 없습니다.
**부딪히면서 배우는 것이 가장 빠르게 성장하는 길**이라고 생각합니다.
 
 
*강의 운영 사정에 따라 세부 프로그램 내용은 변경될 수 있습니다.*
 
 
[![DEV-BE-coding-test-02(1456x180) 오전 10.03.54.jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/1533e3ed-f462-4beb-bda4-cd9ec143b39b/DEV-BE-coding-test-02%281456x180%29%20%E1%84%8B%E1%85%A9%E1%84%8C%E1%85%A5%E1%86%AB%2010.03.54.jpg)](https://school.programmers.co.kr/learn/courses/25957?utm_source=prgmblog&utm_medium=social&utm_campaign=school_25957_sales&utm_content=blog_banner)

[데브코스 후기] 혼자 만든 앱 하나로 기업 협업까지 이어졌어요 - 백엔드 6기 백상현 님

본 글은 비전공자 출신 백엔드 개발자 최락준 님의 글을 일부 재편집하였습니다.
비전공자로 개발자 취업을 고민하고 계신 분들이라면 끝까지 읽어보시는 것을 추천드립니다.
 
 
# 개발자가 되는 데는 거창한 이유가 필요 없다.
가벼운 이야기부터 시작해 보도록 할까요? '왜 개발자가 되었나?'는 비전공자가 개발자로 전향할 때 자주 맞닥뜨리는 질문입니다. 사람마다 개발자가 되려는 이유는 다양합니다. 누구는 저처럼 돈을 잘 벌고 싶어서(물론 아직 달성하지 못했지만), 누군가는 마치 기계를 조립하듯 코드를 작성하는 과정이 재밌어서, 또 누군가는 기술을 통해 이 세상에 혁신을 가져오고 싶어서와 같이 위대한 이유 때문일 것입니다.
 
하지만 개발자가 되는데 반드시 특별한 이유가 필요한 것은 아닙니다. 모든 직업이 그러하듯, 내가 앞으로 최소 주 40시간씩은 코드와 (혹은 그 관련된 업무와) 씨름할 수 있는 책임감이 있고, 그 안에서 나름의 만족감을 느낄 수 있다면 충분하다고 생각합니다.
 
# 시작은 코딩 부트캠프를 추천
비전공자가 개발자가 되는 방법은 크게 코딩 부트캠프를 수료하는 것과 독학 두 가지가 있습니다. 하지만 독학은 잘못된 커리큘럼을 짤 확률이 높습니다. 이제 막 프로그래밍을 시작한 입장에서 무엇이 중요한지 알기 힘들기 때문입니다.
 
반면 부트캠프는 대체로 실무와 밀접한 커리큘럼으로 이루어져 있습니다. 국비지원을 활용하면 부트캠프를 무료로 수료할 수 있다는 것도 큰 장점입니다. 무엇보다 부트캠프를 추천하는 가장 큰 이유는 진행하는 부트캠프에서 진행하는 프로젝트 때문입니다. 동료들과 팀웍을 발휘하고, 어설프지만 설계부터 배포까지 해내는 것은 부트캠프에서 얻을 수 있는 소중한 경험입니다.
 
![Frame 16 (3).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/7908426c-9f3a-41e2-8942-fb29d7803b87/Frame%2016%20%283%29.png)
👆 [프로그래머스 부트캠프](https://school.programmers.co.kr/learn?tag=%EB%8D%B0%EB%B8%8C%EC%BD%94%EC%8A%A4)
 
# 수료 후에는 어떻게 준비하는 것이 좋을까?
부트캠프 수료 후에는 어떻게 준비하는 것이 좋을까요? 먼저 비전공자로서 부족한 점이 분명히 존재합니다. 전공자들이 4년간 대학에서 두꺼운 전공책과 씨름하고 시험을 준비하며 쏟았던 노력을 무시할 수는 없기 때문입니다.
 
그렇다면 비전공자로서 취업전선에 뛰어들기 위해 그와 동등한 과정을 겪어야 한다는 것일까요? 저는 꼭 그렇지는 않다고 생각합니다. 여기에 제가 생각하는 현실적인 대안을 제시해보려 합니다.
 
## 1. 비전공자로서 부족한 것 채우기: IT 지식
개인적으로 비전공자로서 가장 어려움을 느꼈던 부분 중 하나는 각종 IT 용어와 지식이었습니다. 특히 비전공자이며 평생을 개발과 관련 없는 삶을 살았다면, 이러한 것들이 낯설 수밖에 없습니다. 
 
예를 들어, IT 업계에서 자주 쓰이는 "프로토콜"이라는 용어는 비전공자에게 어디선가 들어봤지만 쉽게 정의할 수 없는 단어입니다. 그런데 프로토콜을 모른다면, HTTP가 무엇인지 이해하기 힘들어집니다. 이렇듯 IT 지식은 서로 연결되어 있는 경우가 많습니다.
 
여기서 제가 추천하는 방법은 얇고 넓게 익히기입니다. 물론 깊고 넓게 익히면 더할 나위 없이 좋습니다. 하지만 우리는 주어진 자원(시간과 집중력 등)내에서 효율성의 문제를 간과할 수 없습니다. 프로토콜 얘기로 돌아가 보겠습니다. 통신 시스템이 어떠하고, 프로토콜의 종류에는 무엇 무엇이 있는지는 당장 중요하지 않습니다. '장치 간의 통신을 위해 정해진 약속'이라는 것만 우선 알게 되면 HTTP가 무엇인지 와닿게 됩니다. 그러다 웹개발자로서 HTTP 컨셉에 대한 공부가 필요하다고 느껴지면 그때 깊게 공부하면 됩니다.
 
IT 지식에 하나하나에 너무 매몰되면 지치기 쉽습니다. 사실 파고들면 끝이 없기도 하구요. 우선 IT기술과 친해지는 것이 중요합니다. 다양한 컨셉들이 익숙해질수록 지식의 저변이 확장되는 것을 느끼게 될 것입니다. 그리고 저변이 확장될수록 다른 것들을 익히기도 쉬워집니다. 이러한 이유로 먼저 얇고 넓게 익히는 것을 추천드립니다.
 
## 2. 비전공자로서 부족한 것 채우기: 알고리즘/자료구조
알고리즘/자료구조는 아쉽게도 지름길이나 왕도가 없는 분야이기도 합니다. 여기서 제가 드리는 현실적인 조언은 필요한 만큼만 공부하는 것입니다. 내가 목표로 하는 회사에 따라, 목표로 하는 개발 분야에 따라 필요로 하는 수준은 천차만별입니다. 예를 들어, 게임 개발과 같이 알고리즘 요구량이 높은 분야에 도전한다면 좀 더 깊게 공부할 필요가 있습니다. 반면 일반 웹 개발이라면 그보다는 요구사항이 낮을 것입니다. 따라서 우선 내가 목표로 하는 곳에 맞춰 공부하는 것을 추천드립니다.
 
그리고 알고리즘을 공부할 때는 해당 알고리즘/자료구조의 컨셉을 이해하는데 먼저 집중하는 것이 좋습니다. 또한 이러한 알고리즘/자료구조는 어떤 문제를 해결하는데 쓰이는지 (즉, 왜 사용하는지)를 이해하는 것도 중요합니다. 그렇지 않으면 문제풀이를 위한 단순 지식에 그치기 쉽습니다.
 
초보분들은 하단의 책 두 권을 추천드립니다.  ‘알고리즘 도감’은 '컨셉'을 이해하는데 좋은 책입니다. ‘알고리즘 문제해결 전략’은 조금 어렵지만 '어떤 문제를 해결하는데 쓰이는지' 이해하는데 도움이 되는 책입니다. 
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/fed49b67-8db6-4bd6-b178-c78f77e661bf/image.png)
👆 알고리즘 도감(제이펍)과 프로그래밍 대회에서 배우는 알고리즘 문제해결 전략(인사이트)
 
 
기본적으로 문법은 이해하고 있으나, 알고리즘 공부가 힘든 분들은 하단의 강의를 추천합니다.
 
![Frame 17.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/7874c2d6-5a14-4d8b-8c81-3373e89dd418/Frame%2017.png)
👆[ \[프로그래머스\] 어서와! 자료구조와 알고리즘은 처음이지?](https://school.programmers.co.kr/learn?page=1&keyword=%EC%96%B4%EC%84%9C%EC%99%80&utm_medium=social&utm_campaign=school_13577_content&utm_content=kdc_info_209)
 
## 3. 많은 코드를 접하기
비전공자들에게는 접하는 코드의 절대적인 양이 부족할 수 있습니다. 그리고 이것은 자칫 본인만의 방식과 사고에 갇히는 위험이 되기도 합니다. 가장 쉽게 양질의 코드를 접할 수 있는 방법은 기술블로그를 읽는 것입니다. 기술블로그는 대게 특정 문제 상황과 해결에 대한 글이 많기에 좋은 코드와 해결 방식도 함께 살펴볼 수 있습니다. 책이나 인터넷 강의에 나오는 코드들도 좋은 소스가 될 수 있습니다. 대체로 코드가 단순한 편이지만 매뉴얼과 같은 코드들을 접할 수 있습니다.
 
또한 조금 도전적이지만 추천드리는 방법 중 하나는 깃헙 등에서 오픈소스를 살펴보는 것입니다. 이때, 스타(star)가 많고 나에게 익숙한 기술을 사용한 프로젝트를 대상으로 하는 것이 좋습니다. 프로젝트 구조가 어떻게 되고, 도메인은 어떻게 설정했는지, 코드들이 서로 어떻게 상호작용하는지 등을 살펴보면 어느새 코드를 보는 나의 실력도 높아져 있을 것입니다.
 
## 4. 스터디 참여
비전공자 분들은 주변에 같은 길을 걸어가는 동료들이 적습니다. 스터디 참여는 좋은 대안이 될 수 있습니다. 다만, 취업준비생들로만 이루어진 스터디는 추천드리지 않습니다. 실무의 온도를 느낄 수 없고, 잘못된 우선순위를 갖게 될 확률이 높기 때문입니다.
 
스터디를 참여하면 얻을 수 있는 장점은 매우 많습니다. 우선, 기술에 대해 함께 토론하고 얘기를 나누는 것은 개발자로 성장하는데 좋은 밑거름이 될 것입니다. 그리고 취업과 관련된 정보를 얻을 수 있습니다. 현직자분들은 이미 험난한 취업과정을 겪어보았기에, 이 과정에서의 노하우나 꿀팁들을 얻을 수 있을 것입니다. 또한 개발에 열정이 있는 많은 분들과 교류할 수 있습니다. 개발자 동료들과 교류하는 것의 장점은 여러 가지가 있지만 무엇보다 함께 하는 것만으로도 훌륭한 동기부여가 된다는 것입니다.
 
# 마치며
비전공자분들이 쉽게 하게 되는 걱정들이 있습니다. 너무 늦은 것은 아닐까? 비전공자라서 불리한 것은 아닐까? 논리의 비약을 무릅쓰고 얘기해 보겠습니다.
 
"비전공자는 늦고 경쟁력이 떨어진다."라는 명제는 귀납법에 의해 하나의 반례만 있어도 거짓이 됩니다.
 
하지만 실제로 훌륭한 성과를 보이고 있는 비전공자분들을 정말 많이 볼 수 있습니다. 사실 이제는 그러한 구분도 의미 없기도 하구요. 따라서 우리에게 필요한 것은 지금 노트북 앞에 앉아 열심히 코드를 작성하는 것이 아닐까 생각해 봅니다.
 
 
[![coding-test2(729x90).jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/c0cf844c-3054-4ab8-8b9a-762756b5722a/coding-test2%28729x90%29.jpg)](https://school.programmers.co.kr/learn/courses/25186?utm_source=prgmblog&utm_medium=social&utm_campaign=school_25186_blog&utm_content=25186_banner)

비전공자의 개발자 취업 방법, 이렇게 준비해보세요!

인공지능은 텍스트, 이미지, 음성 등 다양한 데이터를 수치화하여 처리합니다. 이 과정에서 데이터를 벡터와 행렬로 표현하고 계산하는 선형대수의 개념이 핵심적인 역할을 합니다. AI 모델의 구조 설계부터 입력 데이터 처리, 학습 전반에 이르기까지 선형대수가 활용되기에, AI를 깊이 이해하고 개발하려면 선형대수에 대한 이해가 반드시 필요합니다. 이번 아티클에서는 선형대수가 AI에서 어떤 역할을 하는지 함께 살펴보겠습니다.
 
 
# 1. 선형대수란 무엇인가?
데이터 분석과 인공지능 개발 업무를 하면서, 고등학교 수학책을 다시 펼쳐보는 경우가 종종 있습니다. 공통수학 I의 가장 마지막 파트 IV, '행렬'이 그 중 하나인데요. 교과서는 행렬의 덧셈과 뺄셈, 곱셈, 그리고 이것들에 대한 교환/결합/분배 법칙 등 온통 계산에 초점이 맞춰져 있습니다.
 
"행렬은 무엇인가요?"
 
누군가에게 행렬이 무엇이냐고 묻는다면 대부분은 이렇게 생긴 것이라고 답할 것 입니다.

![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/a9244847-10d6-4f47-9af2-63357732af68/image.png)
 
큰 괄호로 묶은 수들의 집합처럼 보이는 이것은 대체 무엇이며, 어디에 쓰일까요?
 
우리는 행렬마저도 이런 중요한 정보와 지식이 빠져있는, 그러니까 '목적'이 없는 하나의 '계산' 과목처럼 대했는지도 모르겠습니다. 대학교에서는 공학 계산기가 그 계산 역할을 대신했고, 간단한 파이썬 라이브러리 하나로 가능해지더니, 이제 생성형 AI에게 말로 시키면, 눈깜짝할 사이에 값이 나옵니다. 그렇기 때문에 이제는 시험 문제를 풀기 위한 계산이 아닌, 행렬의 목적과 쓰임에 집중이 필요합니다.
 
선행 AI 연구 알고리즘을 이해하고 응용하기 위해서, 그리고 한 단계 더 발전시키기 위해 필요한 세 가지 수학적 기초는 확률과 통계, 미분과 적분, 그리고 선형대수입니다. 지난 두 차례의 아티클에서는 [확률과 통계](https://community.programmers.co.kr/post/11518), 그리고 [미분과 적분](https://community.programmers.co.kr/post/12079)을 기반으로 인공지능의 원리를 살펴보았는데요. 오늘은 그 마지막 주제로, **행렬과 벡터로 설명되는 인공지능 개발의 꽃 — 선형대수**(**Linear Algebra**)에 대해 알아보겠습니다.
 
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/54cf522e-3d5d-4d23-813d-b0b73b9ae6db/image.png)
 
'선형대수'는 이름부터 남다른 포스(?)가 느껴집니다. 이름을 둘로 나눠보면 선형(linear)과 대수(algebra)입니다. 먼저, 선형은 그나마 친근한 단어죠? 선형이란, 대표적인 선형함수 y=ax와 같이 직선(line)의 관계를 가지는 것을 의미합니다. 여기서 조금만 더 확장하면, 선형함수는 수학적으로 다음의 두 성질을 가지고 있습니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/7906af1e-6a80-4c43-8bf0-dd5befbcf95e/image.png)
 
첫 번째 성질은 입력값들의 합인 x+y에 대한 함수의 결과 f(x+y)가, 각각의 입력값에 대한 함수 결과들의 합 f(x)+f(y)와 동일하다는 것입니다. 두 번째 성질은 입력값 x에 임의의 수 c를 곱했을 때의 함수 결과 f(c·x)가, 원래 함수 결과 f(x)에 c를 곱한 것 c·f(x)와 동일하다는 것입니다.
 
조금 더 실용적으로 생각해보면, 첫 번째 성질은 사진을 픽셀 단위로 나누고, 각 픽셀의 밝기를 조절한 후 합치면, 사진 전체가 밝아진 것과 같은 원리입니다. 그리고 두 번째는, 특정 주파수를 띄는 음성 신호의 크기를 증폭시켜서, 출력 신호로 만드는 작업을 예로 들 수 있습니다.
 
 
# 2. 행렬은 선형변환이다.
앞서 설명한 이미지의 변환, 소리의 증폭처럼, 선형함수는 축소/확대, 이동, 회전, 변환 기능을 합니다. **선형대수에서 가장 중요한 사실은 "모든 선형함수는 행렬로 표현될 수 있다"는 점**입니다. 반대로 말하면, **"행렬은 선형변환 기능을 한다"는 것**입니다. 그래서 행렬은 입력을 원하는 형태로 변환하거나, 다른 데이터와의 관계를 계산할 때 쓰는 도구(Tool)입니다. 여기서 "선형"이 중요한 이유는 선형적 특성을 이용하면, 아무리 복잡한 현실 문제도 단순화해서 해결할 수 있기 때문입니다.
 
### "행렬은 선형변환 기능을 한다"
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/cfa9f5b4-9657-41e9-895a-c19e6c6e26e4/image.png)
 
 
# 3. 데이터는 행렬로 표현할 수 있다.
우리가 일상에서 다루는 많은 정보는 '행렬' 구조로 대신 표현할 수 있습니다. 아래 그림을 보면 이를 아주 명확하게 이해할 수 있습니다. 왼쪽에는 학생들의 과목별 성적이 담긴 표가 있습니다. 각 학생이 국어, 영어, 수학에서 받은 점수가 정리된 이 표는 행이 학생, 열이 과목으로 구성된 4x3 크기의 행렬로 표현할 수 있습니다.

![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/a560c80a-dcab-4d65-b3f4-37f1a5bbbc35/image.png)
 
그 옆에는 각 대학이 학생의 과목 점수를 얼마나 반영하는지를 보여주는 표가 있습니다. 예를 들어 서울대는 국어 점수의 30%, 영어 20%, 수학 50%를 반영하고, 부산대는 각각 40%, 30%, 30%, 인천대는 30%, 30%, 40%의 비율을 반영한다고 되어 있습니다. 이 표는 3x3 행렬로 정리할 수 있습니다. 과목별로 각 대학의 반영 비율을 수치로 나타낸 것입니다.
 
이제 학생들의 성적 행렬과 대학별 반영 비율 행렬을 곱하면, 각 학생이 각 대학에 지원했을 때의 총점이 계산됩니다. 예를 들어 학생 1이 서울대에 지원한다고 했을 때, 그의 점수는 국어 100점 x 0.3 + 영어 90점 x 0.2 + 수학 80점 x 0.5 = 88점이 됩니다. 이런 방식으로 모든 학생과 대학에 대해 점수가 계산되며, 최종적으로 4x3 크기의 결과 행렬이 만들어집니다. 이 행렬의 각 칸은 학생과 대학 간의 조합에서 나온 최종 점수입니다.
 
즉, 성적 데이터와 대학의 반영 기준이라는 서로 다른 정보를 행렬로 표현하고, 이를 행렬 곱 연산을 통해 계산합니다. 실제 데이터는 수많은 행과 열을 가진 데이터를 구조화함으로써, 계산을 빠르고 정확하게 수행할 수 있습니다. 이처럼 다양한 데이터는 행과 열로 구성된 수치의 집합, 즉 '행렬'로 구조화할 수 있으며, **이러한 행렬 연산을 통해 실질적인 판단과 의사결정에 필요한 정보를 얻을 수 있습니다**. 이것이 바로 "**데이터는 행렬로 표현된다**"는 말의 의미입니다.
 
 
# 3. 벡터와 벡터 공간, 그리고 인공지능에서의 쓰임
선형대수의 두 번째 단어, '대수'의 어원은 페르시아어 algebra입니다. 이것은 "흩어진 부분들을 묶음"이라는 뜻으로, 방정식을 풀 때 수(數)를 대(代)신해 문자를 사용한 것에서 유래되었습니다. 따라서 숫자를 문자가 아닌 '행렬'과 '벡터'라는 것으로 표현하고, 그것들의 연산이 만드는 공간(벡터 공간)에 대해 다루는 학문이 대수학입니다.
 
벡터란 크기와 방향을 모두 가진 양을 의미하며, 보통 화살표로 이해하면 쉽습니다. 예를 들어 2차원 벡터 v = [ 2 1 ]은 x축 방향의 크기가 2이고, y축 방향의 크기가 1이면서, 그 점을 가리키는 방향을 가지고 있습니다. 3차원 벡터도 마찬가지입니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/784b0bfb-b896-47e2-a5b5-74db36231dee/image.png)

이 행렬과 벡터가 대체 인공지능 개발에 어떻게 쓰일까요? 우리가 사용하는 자연어는 컴퓨터가 바로 이해할 수 없기 때문에, 단어 하나하나를 수학적인 형태인 숫자의 나열, 즉 '벡터'로 변환하게 됩니다. 예를 들어 '원숭이, '악어', '바나나', '딸기' 같은 단어들이 있다면, 인공지능은 이들을 벡터 공간 속의 n차원 숫자로 표현합니다. 이런 작업을 '임베딩(Embedding)'이라고 하며, 이 임베딩을 수행하는 모델을 '임베딩 모델'이라고 부릅니다.
 
**벡터로 표현된 단어들끼리는 서로 곱셈이나 거리 계산을 통해 의미적 관계를 파악**할 수 있습니다. 예를 들어, '원숭이'와 '바나나'가 가까운 위치에 있다면, 이 둘은 의미적으로도 가까운 관계라는 뜻입니다. 이처럼 단어 간의 의미 차이나 유사성을 수치로 계산할 수 있기 때문에, 단어뿐만 아니라 문서, 이미지, 영상, 음성 등 다양한 데이터를 모두 벡터 공간에서 표현하고, 선형변환과 벡터 연산을 통해 처리할 수 있게 됩니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/d40958ca-be2a-46f7-9e2c-497259ef3313/image.png)
 
벡터화된 데이터의 집합이 완성되었다면, 인공지능이 단어로 이루어진 문장을 이해하고, 새로운 문장을 만들어내는 과정이 필요하죠. 이 과정은 '인코더(Encoder)'와 '디코더(Decoder)'라는 두 개의 핵심 구조로 설명할 수 있습니다. 인코더는 문장을 입력받아, 그 안의 의미를 연산을 통해 특정 벡터로 압축하고, 문장과 단어간의 연산을 통해서 디코더가 새로운 문장을 생성하는 역할을 합니다. 이렇게 단어의 시퀀스를 문맥 정보로 전달한다고 해서 **Seq2Seq 모델**이라고 부릅니다.
 
초기 Seq2Seq 구조는 인코더가 입력 문장의 모든 정보를 하나의 벡터, 즉 컨텍스트 벡터로 압축한 뒤, 디코더가 그 벡터만 보고 예측을 수행했습니다. 그러나 문장이 길어질수록 정보가 손실되거나 왜곡되는 문제가 발생했고, 이를 해결하기 위해 '**어텐션(Attention)**'이라는 개념이 도입되었죠. 어텐션은 디코더가 단어를 생성할 때, 인코더가 만들어낸 모든 단어의 정보를 압축해 만든 은닉 상태(Hidden state)를 전체적으로 살펴보고, 현재 시점에 어떤 정보가 가장 중요한지 판단하는 방식입니다. 이러한 모델은 오늘날 거대 언어 모델의 근간이 되는 '**트랜스포머(Transformer)**' 입니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/1040723b-3647-4662-8b72-eb050cce46de/image.png)
 
트랜스포머(Transformer)는 기존의 순차적인 시퀀스 구조의 한계를 극복하고자 고안된 모델로, 인코더와 디코더 모두 셀프 어텐션(Self-Attention) 기반으로 설계되어 있습니다. **입력된 문장의 모든 단어가 동시에 서로의 관계를 계산**할 수 있기 때문에, 효율성과 성능 면에서 혁신적입니다.
 
**셀프 어텐션(Self-Attention)** 연산의 핵심은 입력 문장을 구성하는 각 단어 벡터가, 다른 모든 단어 벡터들과의 관계를 수치적으로 계산하여, 현재 문맥에서 어떤 단어가 중요한지를 스스로 판단하는 구조입니다. 이때 사용되는 세 가지 행렬은 Query(Q), Key(K), Value(V)입니다. 입력 X는 각각 W^Q, W^K, W^V 라는 학습 가능한 가중치(Weight) 행렬과 곱해져 Q, K, V 세 가지 벡터로 변환됩니다.
 
그 다음은 **어텐션 스코어(Attention score)** 계산 단계입니다. Query와 Key 간의 유사도를 내적으로 계산하고, 이를 단어 벡터 차원의 제곱근으로 나눈 뒤 softmax 함수를 적용하여 확률분포로 변환합니다. 이렇게 얻은 어텐션 스코어는 각 단어가 다른 단어에 주목하는 정도를 나타냅니다. 이 값은 Value 벡터에 곱해져 선형 결합되며, 이 값이 바로 최종적으로 다음 레이어로 전달되어 Z 벡터가 됩니다.
 
트랜스포머는 이러한 셀프 어텐션 연산을 여러 개의 head로 동시에 수행하는 Multi-Head Attention 구조를 채택하고 이습니다. 각 head는 입력의 다른 부분에 주목할 수 있게 하여, 보다 다양한 문맥 정보를 학습할 수 있도록 합니다. 그리고 이러한 어텐션 출력은 다시 잔차 연결(Residual Connection)과 정규화(LayerNorm)를 통해 안정적인 학습이 가능하도록 돕습니다.
 
예를 들어 "원숭이는 바나나를 좋아한다"라는 문장에서, '원숭이'라는 단어는 '바나나'에 높은 어텐션 스코어를 줄 수 있습니다. 이는 두 단어 사이의 의미적 연관성을 모델이 학습하고 있다는 증거이며, 이렇게 계산된 어텐션 스코어는 문장의 의미를 이해하고 다음 단어를 생성하는 데 결정적인 역할을 합니다.
 
이러한 구조 덕분에 **트랜스포머는 길이가 긴 문장에서도 정보 손실 없이 효과적으로 문맥을 이해**할 수 있으며, 순차적 계산이 아닌 병렬 계산이 가능해 연산 효율성까지 확보하게 됩니다. 이처럼 트랜스포머의 구조와 셀프 어텐션 연산은 모두 행렬 곱셈, 내적, 정규화 등 선형대수의 원리를 기반으로 작동합니다. 이미지, 텍스트, 음성 등 다양한 데이터가 벡터와 행렬로 표현되고, 모델은 이러한 수학적 구조를 통해 의미를 학습하고 예측을 수행합니다.
 
지금까지 행렬과 벡터의 기본 개념과 목적, 그리고 인공지능에서의 쓰임에 대해 알아보았습니다. **거대 언어 모델 또한 단어를 벡터로 임베딩하고, 연산을 통해 중요한 정보를 추출하는 모든 과정에서 선형대수의 개념을 활용**하고 있습니다. 선형대수는 처음부터 완벽히 이해하기는 어렵지만, AI 알고리즘을 하나씩 학습해 나가면서 그 개념들을 차근차근 익혀 간다면, 인공지능 개발에 있어 탄탄한 기반이 될 것입니다.
 
 
### 함께 읽으면 좋은 글
* [베이지안 확률과 AI의 비밀: 데이터로 더 똑똑해지는 인공지능의 핵심 원리](https://community.programmers.co.kr/post/11518)
* [곰돌이 젤리로 알아보는 인공지능 수학 KL Divergence](https://community.programmers.co.kr/post/12079)

 
 
![정경문 작가님 프로필 카드.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/506f62e6-8946-4fb8-bd8b-6e45661e7d4e/%E1%84%8C%E1%85%A5%E1%86%BC%E1%84%80%E1%85%A7%E1%86%BC%E1%84%86%E1%85%AE%E1%86%AB%20%E1%84%8C%E1%85%A1%E1%86%A8%E1%84%80%E1%85%A1%E1%84%82%E1%85%B5%E1%86%B7%20%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%84%91%E1%85%B5%E1%86%AF%20%E1%84%8F%E1%85%A1%E1%84%83%E1%85%B3.png)
 
 
[![DE_배너.jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/79f34a67-44b0-42ee-9637-42d62b9eb311/DE_%E1%84%87%E1%85%A2%E1%84%82%E1%85%A5.jpg)](https://school.programmers.co.kr/learn/courses/25302?utm_source=prgmblog&utm_medium=social&utm_campaign=school_25302_blog&utm_content=25302_banner)

인공지능의 꽃, 행렬과 벡터: 선형대수(Linear Algebra)

올 상반기 데브코스에서 주목받은 우수 프로젝트들을 한자리에 모아 소개합니다.

2026 상반기 데브코스 어워즈 프로젝트 확인하고 **시크릿 취업 가이드북** 받아가세요!

(**참여자 선착순 10명**에게는 시원한 선물까지!) 
 
![PRGMS-AWARD-EVENT-yjgd-poster(1000x1414) (2).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/0386415b-bc5c-4370-9bfa-112d3b9f35b1/PRGMS-AWARD-EVENT-yjgd-poster%281000x1414%29%20%282%29.png)
 
 
## 📌 이벤트 기간
**2026.07.07(화) ~ 2026.07.31(금)**
 
 
## 🎁 이벤트 참여 방법
1️⃣ [2026 상반기 데브코스 어워즈] 참여 구글폼 작성

👉 **[이벤트 참여하고 시크릿 취업 가이드북 받기](https://docs.google.com/forms/d/e/1FAIpQLSfOHZb5xtbnjvZ23MwjzMSVnGeLNr68c1frbfbLkj0itlA60w/viewform)**

2️⃣ 우수 프로젝트 중 인상 깊은 프로젝트 1개 투표, 1줄 감상평 제출

3️⃣ **메일함에서 시크릿 취업 가이드북 확인🍀**

(**참여자 선착순 10명**에게 **배라 기프티콘** 제공!)
 
 
이벤트 참여해서 데브코스 우수 프로젝트 인사이트도 얻고
선착순 선물까지 받아가세요😉

[데브코스 이벤트] 2026 상반기 데브코스 어워즈 개막! 우수 프로젝트 대공개 🔥

개발자라면 누구나 언젠가 레거시 코드를 마주하게 됩니다. 깔끔하게 정리된 예제 코드와 달리, 실제 현업의 코드는 수많은 조건과 패치가 쌓여 복잡하게 얽혀 있죠. 처음엔 당황하고 두려울 수 있지만, 레거시 코드는 개발자로 성장하는 데 있어 중요한 배움의 기회가 됩니다. 이번 달 고코더 님의 아티클에서는 레거시 코드를 이해하고 개선하며, 나아가 성장의 발판으로 삼는 방법을 함께 살펴보겠습니다.
 
 
## 그 코드를 본 순간의 충격
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/f202d605-e722-4b72-a5ff-44c0caa3ff73/image.png)
 
첫 회사 입사 첫날, 선배 개발자가 저에게 화면을 보여주며 말했습니다.
"이 기능에 버그가 있어서 수정해야 해. 코드는 여기 있고..."
제가 본 것은 주석 하나 없는 3,247줄짜리 단일 파일이었습니다. 변수명은 data1, result2, temp_value 같은 것들로 가득했고, 하나의 함수 안에 if문이 15단계나 중첩되어 있었습니다. 마치 스파게티 면이 뒤엉켜 있는 것 같은 코드 앞에서 저는 완전히 얼어붙었습니다.
 
"이게 정말 돌아가는 코드야?"
 
당시의 충격적인 기억이 지금도 생생합니다. 학원에서 배운 깔끔하고 정리된 예제 코드와는 완전히 다른 세상이었습니다. 그때는 몰랐습니다. **이 "무서운" 레거시 코드가 훗날 제게 가장 훌륭한 스승**이 될 것이라는 사실을요.
 
많은 신입 개발자들이 레거시 코드 앞에서 같은 두려움을 느낍니다. 하지만 이 두려움을 극복하고 레거시 코드와 친해지는 순간, 여러분의 개발 실력은 한 단계 도약하게 될 것입니다.
 
*본 글의 코드 예시와 비즈니스 시나리오는 이해를 돕기 위한 가상의 내용입니다.
 
 
## 왜 이렇게 만들어졌을까?
레거시 코드를 마주했을 때 가장 먼저 드는 생각은 "도대체 왜 이렇게 만들었지?"입니다. 하지만 성급하게 판단하기 전에, 그 코드가 만들어진 맥락을 이해하는 것이 중요합니다.
 
### 시간에 쫓기는 비즈니스 압박
실제로 제가 분석했던 한 레거시 코드에는 이런 주석이 있었습니다:
 
```java
//2019년 할인 이벤트 긴급 패치 - 절대 건드리지 말 것
if(paymentAmount > 1000000) {
 // 임시 해결책: 고액 결제 시 특별 처리
 return processLargePayment(paymentAmount);
}
```
 
당시 대규모 할인 이벤트 중 결제 시스템에 오류가 발생했고, 서비스 중단을 막기 위해 3시간 만에 급하게 만든 패치였습니다. 완벽하지 않지만 당시 상황에서는 최선의 선택이었던 것이죠.
 
### 당시 기술의 한계와 제약사항
10년 전에는 지금처럼 풍부한 라이브러리와 프레임워크가 없었습니다. 현재는 한 줄로 해결되는 날짜 처리나 문자열 조작을 위해 수십 줄의 복잡한 코드를 직접 작성해야 했습니다. 당시에는 그것이 최선이었고, 그 코드들이 지금까지 서비스를 안정적으로 지탱해왔습니다.
 
### 계속 변화된 요구사항
아래는 비즈니스 요구사항이 계속 변화하면서 코드도 덩달아 복잡해진 전형적인 사례입니다. 매번 새로 만들 수는 없으니 기존 코드에 조건을 하나씩 추가한 결과입니다.
 
```java
// 처음에는 단순한 할인 로직이었지만...
public double calculateDiscount(Order order) {
 double discount = 0;
 
 // 2018년 추가: VIP 고객 10% 할인
 if(order.getCustomer().isVIP()) {
 discount += 0.1;
 }
 
 // 2019년 추가: 특정 브랜드 추가 5% 할인
 if(order.getBrand().equals("SpecialBrand")) {
 discount += 0.05;
 }
 
 // 2020년 추가: 코로나 지원 할인...
 // 2021년 추가: 신규 회원 할인...
 // ... 20여 개의 조건이 계속 추가됨
}
```
 
 
## 레거시 코드를 발굴 해보자
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/7ce54df6-2fee-4ab8-b036-7685fe63ed9e/image.png)
 
레거시 코드 앞에서 막막함을 느끼는 것은 당연합니다. 마치 오래된 유적지에 처음 발을 들인 고고학자처럼, 어디서부터 시작해야 할지 알기 어렵죠. 하지만 고고학자가 보물을 찾기 위해 체계적으로 발굴을 진행하듯, **레거시 코드도 단계적으로 접근하면 그 안에 숨겨진 비즈니스 로직과 개발자들의 노하우를 발견**할 수 있습니다.
 
### 1. 전체 그림 그리기
레거시 소스는 전체적으로 큰 그림을 봐야 합니다. 먼저 전체적인 구조를 파악해보세요.
* 폴더 구조 살펴보기: 어떤 기능들이 어디에 위치하는지 파악
* 데이터 흐름 추적하기: 입력 데이터가 어떻게 변환되어 출력되는지
* 핵심 비즈니스 로직 찾기: 가장 중요한 기능이 어디에 구현되어 있는지

 
저는 복잡한 레거시 시스템을 분석할 때 화이트보드에 직접 그림을 그려가며 이해했습니다. 그 과정에서 시스템의 전체 구조를 명확히 파악할 수 있었습니다.
 
### 2. 작은 단위로 나누어 이해하기
큰 소스를 한번에 이해하기는 불가능합니다. 조금씩 정복해가야 합니다.
 
```java
// 이해하기 어려운 복잡한 함수
public Result processUserData(String data, int type, boolean flag) {
 // 200줄의 복잡한 로직...
}

// 먼저 입력과 출력만 파악하기
// 입력: 사용자 데이터(문자열), 처리 타입(숫자), 플래그(불린)
// 출력: Result 객체 (어떤 정보가 담겨있을까?)
```
 
함수의 내부 로직을 모두 이해하려 하지 말고, 먼저 "무엇을 받아서 무엇을 돌려주는지"만 파악해보세요. 그 다음 함수 내부를 몇 개의 블록으로 나누어 각각의 역할을 추측해보는 것입니다.
 
### 주석 남기기
이해한 내용을 주석으로 남기는 것은 소스를 이해하는 가장 좋은 투자 중 하나입니다. 복잡한 레거시라면 최대한 주석을 많이 남겨보세요. 혹시나 주석을 남길 수 없는 환경이라면, 따로 소스를 복사해 주석을 달아보세요.
 
```java
// 이해하기 전
if(user.getAge() > 18 && user.getCountry().equals("KR") && 
 user.getVerificationStatus() == 2) {
 // 복잡한 로직...
}

// 이해한 후 주석 추가
// 성인 한국 사용자이고 본인인증이 완료된 경우
if(user.getAge() > 18 && user.getCountry().equals("KR") && 
 user.getVerificationStatus() == 2) {
 // 프리미엄 서비스 이용 가능 처리
}
```
 
## 레거시 코드 안전하게 개선하기
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/50a430e8-4b51-4859-b680-47d2598b1cc6/image.png)
 
레거시 코드를 개선할 때는 신중해야 합니다. 성급한 리팩토링은 예상치 못한 버그를 만들어낼 수 있습니다.
 
### 1. Boy Scout Rule 적용하기
보이스카우트 규칙: "캠프장을 떠날 때는 찾았을 때보다 더 깨끗하게 남겨놓기"
 
```java
// 기존 코드
public void updateUser(String id, String n, String e, int a) {
 User u = findUserById(id);
 u.name = n;
 u.email = e;
 u.age = a;
 saveUser(u);
}

// Boy Scout Rule 적용 후
public void updateUser(String userId, String name, String email, int age) {
 User user = findUserById(userId);
 user.name = name;
 user.email = email;
 user.age = age;
 saveUser(user);
}
```
 
변수명을 명확하게 하는 것만으로도 코드 가독성이 크게 향상됩니다. 이런 작은 개선들이 모여 점차 코드 전체의 품질이 높아집니다.
 
### 2. 테스트 코드부터 작성하기
리팩토링의 황금 규칙: "동작하는 코드를 건드리기 전에 테스트부터 작성하라"
 
```java
@Test
public void 할인_계산_테스트() {
 // Given: VIP 고객의 주문
 Order order = new Order();
 order.setCustomer(new Customer("VIP"));
 order.setAmount(10000);
 
 // When: 할인을 계산했을 때
 double discount = discountService.calculateDiscount(order);
 
 // Then: 10% 할인이 적용되어야 함
 assertEquals(1000, discount, 0.01);
}
```
 
기존 기능이 제대로 동작한다는 것을 보장하는 테스트를 먼저 작성하면, 안심하고 리팩토링을 진행할 수 있습니다.
 
### 3. 점진적 개선 전략
한 번에 모든 것을 바꾸려 하지 마세요. 새로운 기능을 추가할 때는 새로운 방식으로 구현하고, 기존 코드는 조금씩 개선해나가는 것입니다.
 
```java
// 레거시 방식 (기존 코드는 그대로 유지)
public class LegacyUserService {
 // 기존 로직...
}

// 새로운 방식 (새 기능은 개선된 방식으로)
public class UserService {
 private LegacyUserService legacyService; // 점진적 마이그레이션
 
 public User createUser(UserRequest request) {
 // 새로운 방식으로 구현
 return User.builder()
 .name(request.getName())
 .email(request.getEmail())
 .build();
 }
}
```
 
 
## 최고의 학습 교재
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/47b982d1-8bb0-41e7-ac7a-0d5c7d762483/image.png)
 
놀랍게도 레거시 코드는 개발자에게 **가장 훌륭한 학습 교재**입니다.
 
### 다양한 개발 패턴과 시행착오 사례
교과서에서는 "올바른" 방법만 가르치지만, 레거시 코드에는 "실제로 시도했던" 모든 방법을 볼 수 있습니다. 성공한 패턴도, 실패한 패턴도 모두 학습할 수 있는 살아있는 박물관입니다.
 
### 비즈니스 로직의 복잡성 이해
실제 서비스의 비즈니스 로직은 학교에서 배운 단순한 예제와는 차원이 다릅니다. 수많은 예외 상황, 특수한 요구사항, 법적 제약사항들이 코드에 녹아있습니다. 이런 복잡성을 이해하는 것은 진정한 개발자로 성장하는 필수 과정입니다.
 
### 시스템 설계의 진화 과정 학습
```java
// 2018년: 단순한 구조
class PaymentProcessor {
 void processPayment(int amount) { ... }
}

// 2019년: 다양한 결제 수단 지원
class PaymentProcessor {
 void processPayment(int amount, PaymentMethod method) { ... }
}

// 2020년: 해외 결제 지원
class PaymentProcessor {
 void processPayment(PaymentRequest request) { ... }
}

// 2021년: 마이크로서비스 분리
interface PaymentService {
 PaymentResult process(PaymentRequest request);
}
```
 
코드의 변화 과정을 통해 시스템이 어떻게 진화해왔는지, 어떤 고민들이 있었는지를 생생하게 배울 수 있습니다.
 
 
## 레거시 코드는 적이 아닌 스승
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/48da9035-edc1-4705-9790-4768c382eca0/image.png)
 
레거시 코드에 대한 저의 관점이 완전히 바뀐 순간이 있었습니다. 복잡하고 이해하기 어려웠던 결제 시스템의 코드를 분석하던 중, 작은 주석을 하나 발견했습니다.
 
```java
// 2020.03.15 - 코로나19로 인한 환불 급증 대응
// 기존 24시간 -> 1시간으로 단축 (임시)
// TODO: 상황 안정화 후 원복 예정
if (refundRequest.isUrgent()) {
 return processImmediateRefund(refundRequest);
}
```
 
그 순간 깨달았습니다. 이 코드는 단순한 버그나 나쁜 설계가 아니라, 어려운 상황에서 사용자를 위해 최선을 다한 개발자들의 흔적이었습니다. 코로나19라는 예상치 못한 상황에서 급증한 환불 요청을 처리하기 위해 밤을 새워 만든 해결책이었던 것입니다.
 
그날부터 저는 레거시 코드를 다른 시각으로 바라보기 시작했습니다. 두려워할 대상이 아니라 **선배 개발자들의 고민과 노하우가 담긴 소중한 자산**으로 말입니다.
 
### 겸손함을 배우다
완벽한 코드는 존재하지 않습니다. 지금 제가 작성하는 깔끔하고 우아한 코드도 몇 년 후에는 누군가에게 "레거시 코드"가 될 것입니다. 이런 인식은 코드를 작성할 때 더 신중하게 만들고, 동시에 기존 코드에 대해 더 관대하게 만들어줍니다.
 
### 문제 해결 능력의 향상
레거시 코드를 분석하고 개선하는 과정은 마치 탐정이 되어 미스터리를 푸는 것과 같습니다. 단서를 찾고, 가설을 세우고, 검증하는 과정을 반복하면서 논리적 사고력과 문제 해결 능력이 크게 향상됩니다.
 
## 마치며
레거시 코드와의 첫 만남은 분명 충격적일 것입니다. 하지만 그 두려움을 극복하고 한 걸음씩 다가가다보면, 어느새 레거시 코드가 여러분에게 많은 것을 가르쳐주는 훌륭한 스승이 되어있을 것입니다.
 
기억하세요. 모든 코드에는 그만한 이유와 이야기가 있습니다. 성급하게 판단하지 말고, 먼저 이해하려 노력해보세요. 그리고 조금씩, 조금씩 개선해나가세요.
 
여러분이 오늘 레거시 코드에서 배운 것들이 내일 더 나은 코드를 작성하는 밑거름이 될 것입니다. 그리고 언젠가는 여러분도 후배 개발자들에게 이런 조언을 해줄 수 있는 멘토가 되어있을 거예요.
 
레거시 코드와 친해지는 여정, 지금 시작해보세요!
 
 
### 📌 함께 읽으면 좋은 글
* [개발자의 학습 곡선 정체기: 더 이상 실력이 늘지 않을 때](https://community.programmers.co.kr/post/12213?utm_source=&utm_medium=&utm_campaign=&utm_content=gocoder_25jun)
* [개발자의 첫 1년: 신입 개발자의 생존과 적응 가이드](https://community.programmers.co.kr/post/11452?utm_source=&utm_medium=&utm_campaign=&utm_content=gocoder_25mar)

 
 
![고코더 작가님 프로필 카드.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/981a201b-a627-4787-8d04-526f9bd95efb/%E1%84%80%E1%85%A9%E1%84%8F%E1%85%A9%E1%84%83%E1%85%A5%20%E1%84%8C%E1%85%A1%E1%86%A8%E1%84%80%E1%85%A1%E1%84%82%E1%85%B5%E1%86%B7%20%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%84%91%E1%85%B5%E1%86%AF%20%E1%84%8F%E1%85%A1%E1%84%83%E1%85%B3.png)

레거시 코드와 친해지는 법: 두려움에서 도구로

프롬프트 한 줄로 코드가 뚝딱 만들어지는 '바이브 코딩'의 짜릿함에 많은 사람들이 열광했습니다. 하지만 신기함도 잠시, "이 코드 왜 돌아가는지 나도 모르겠어"라는 한계에 부딪히는 데는 그리 오랜 시간이 걸리지 않았죠.
 
단순히 AI에게 코드를 '시켜서' 만드는 단계를 넘어, 서비스 전체를 이해하고 검증하는 'AI Native Engineering'은 과연 무엇일까요? 데이터 사이언티스트 정경문 님이 풀어내는 AI 시대 진짜 엔지니어로 생존하는 법, 지금 확인해 보세요!
 
 
## 어느 날, 코드가 말로 만들어지기 시작했다
2025년 초, 개발자 커뮤니티에 이상한 유행어 하나가 돌기 시작했습니다.
 
"**바이브 코딩(Vibe Coding)**"
 
프롬프트 창에 "이런 '느낌'의 앱 만들어줘"라고 말하면, AI가 뚝딱 코드를 뱉어내고, 그걸 복사해서 돌려보고, 에러가 나면 다시 붙여 넣고... 신기하게도 뭔가가 '돌아가는' 경험.
많은 비전공자와 주니어 개발자들이 여기서 짜릿함을 느꼈습니다. 사실 그런 느낌을 받은 사람들은 수십만, 수백만 명이었습니다. 하지만 몇 주 뒤, 사람들은 똑같은 벽에 부딪힙니다.
 
"원하는 대로 화면 수정이 안돼"
"DB는 어떻게 붙이지?"
"로그인 관리는 어떻게 하지?"
 
코드 검토와 리뷰에 많은 시간을 들이지만, 결국에는 "이 코드, 왜 돌아가는지 나도 모르겠어"로 귀결됩니다. 바로 이 지점에서 새로운 용어가 탄생합니다.
 
"**AI Native Engineering**" - 말로 만드는 단계에서, 구조를 이해하고 검증하며 운영하는 단계로 넘어가는 것
제가 만든 마인드맵의 한 가운데에 이 문장을 적어둔 이유이기도 합니다.
 
 
[![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/a7f0af73-3ceb-430a-b2ac-4efbdfb371b9/image.png)](https://ai-native-roadmap-final.vercel.app/)
⬆️ 마인드맵: 바이브 코딩으로 AI 네이티브 엔지니어링까지
 
*🔗 이미지를 클릭하면 링크가 있는 웹페이지로 이동합니다.*
 
 
## 이 용어, 어디서 왔을까?
프롬프트 엔지니어링, 컨텍스트 엔지니어링, 하네스 엔지니어링, 최근에는 루프 엔지니어링까지.
새로운 용어들이 쏟아지는 시대입니다. 모르면 뒤처질 것 같다는 불안도 생기죠.
하지만 AI Native Engineering은 이런 복잡한 개념이라기보다는, **AI 시대를 아우르는 더 큰 개념의 단어**입니다.
 
솔직히 말씀드리면 AI Native Engineering은 아직 교과서에 실릴 정도의 표준 용어는 아닙니다. 2025~2026년 사이에 빠르게 확산되고 있는 개념이고, OpenAI, IBM, WWT(World Wide Technology) 같은 기업들과 컴퓨터 과학 학술 단체 ACM(Association for Computing Machinery) 계열 논문들에서 이 표현 혹은 매우 유사한 개념을 사용하고 있습니다. 재미있는 것은 이 단어는 두 가지 의미로 쓰인다는 점입니다.
 
**첫 번째는 개발 방법론으로서의 의미**입니다. AI를 그저 "코드 자동 완성 도우미"로 쓰는 것이 아니라, 요구사항 정의부터 설계, 구현, 테스트, 배포, 운영까지 개발의 전 과정을 AI를 중심에 두고 재설계하는 방식을 말합니다. 클라우드 시대에 "Cloud Native"라는 말이 나왔던 것과 똑같은 문법이죠. 클라우드를 '쓰는 것'과 클라우드를 '전제로 설계하는 것'이 다르듯, AI를 쓰는 것과 AI를 전제로 엔지니어링 하는 것은 완전히 다른 이야기입니다.
 
**두 번째는 연구 분야에서 주로 사용하는 용어인 Software Engineering 3.0**입니다. SE 1.0이 사람이 코드를 한 줄 한 줄 짜던 시대, SE 2.0이 프레임워크와 도구로 생산성을 끌어올린 시대였다면, SE 3.0에서 개발자는 코드를 직접 작성하는 사람이 아니라 **의도(Intent)를 정의하고, AI Agent를 설계하고, 그 결과물을 검증하는 사람**으로 변합니다. 무엇을 만들 것인가를 정확히 말하고, AI가 만든 것이 맞는지 판단하는 능력이 핵심 역량이 되는 것이죠.
 
 
## 개발 환경과 도구 설정
"AI가 다 해주면, 나는 뭘 공부해야 하죠?" 많은 사람들이 이렇게 묻습니다.
제 답은 조금 역설적입니다. **AI가 다 해주기 때문에, 오히려 전체 구조를 알아야 합니다**.
 
AI는 실력 좋은 시공팀과 같습니다. 하지만 그 설계도를 읽고 검수하는 것은 결국 사람의 몫입니다. 그리고 그 설계도를 이해하는 가장 좋은 교재는 여러분이 매일 사용하는 **무신사, 에이블리, 나이키, 쿠팡과 같은 앱**입니다. 지금부터 여러분이 티셔츠 하나를 결제하는 그 10초 동안, 화면 뒤에서 어떤 일들이 벌어지는지 함께 따라가 보시죠.
 
시작하기 전에 준비물부터 간단히 살펴보겠습니다. 위 마인드맵에서 개발 환경(①)과 개발 도구(⑦)는 요리를 하기 위한 주방과 조리도구 같은 것들이죠. 요즘은 Window나 Mac 또는 Linux 운영체제 위에 VS Code나 Cursor라는 작업대를 놓고, Python이나 Node.js와 같은 인터프리터를 설치하죠. 그리고 요즘은 여기에 Claude Code와 같은 **AI 코딩 에이전트**가 시니어 동료처럼 합류합니다. 바이브 코딩에서 많은 사람들이 처음 막히는 곳은 의외로 코드가 아니라 이 환경 설정입니다.
 
 
## 티셔츠 하나가 결제되는 10초 - 개발은 이렇게 굴러간다
자, 이제 앱을 엽니다. 여러분 눈에 보이는 모든 것이 **Front End**(②)입니다. 상품 목록, 옆으로 넘기는 사진, 누르면 색이 바뀌는 '장바구니 담기' 버튼.
 
HTML(HyperText Markup Language)이 이 꺾쇠(<>) 태그를 써서 텍스트, 이미지, 링크에 대한 화면의 뼈대를 잡고, CSS(Cascading Style Sheets) 가 컬러풀한 색상과 폰트 같은 스타일을 입히고, JavaScript가 버튼을 누르면 숫자가 올라가는, 사이즈가 선택되면 색이 바뀌는 움직임을 만듭니다.
 
여기서 React 같은 라이브러리는 이 화면을 레고 블록처럼 조립하면서 데이터가 변경될 때마다 효율적으로 화면을 갱신하는 역할을 합니다. 프론트엔드를 먼저 배우는 이유는 간단합니다. **결과가 눈에 바로 보여서, AI가 만든 것을 즉시 검증**할 수 있기 때문입니다.
 
이제 '구매하기' 버튼을 누릅니다. 여기서부터는 보이지 않는 세계, **Back End & API**(③)의 영역입니다. 버튼을 누른 뒤 단 1초 사이에 실시간 재고를 다시 확인하고, 회원 등급 할인을 계산하고, 결제사 승인을 받고, 주문 번호를 저장하는 일꾼이 바로 백엔드입니다.
 
**화면과 백엔드가 주고받는 정해진 대화 양식이 API**(Application Programming Interace)고요. 우리가 인스타그램이나 웹브라우저로 우연히 광고를 보다가 구매를 하려고 카카오톡으로 3초 만에 로그인하는 것(OAuth), 토큰으로 로그인 상태가 유지되는 것(JWT)도 전부 이 세계의 일입니다.
 
여기서 서버와 클라이언트는 통신을 하는데, 서버는 숫자로 대답합니다. 2xx면 성공, 4xx면 요청한 쪽 문제(품절, 로그인 만료), 5xx면 서비스 쪽 문제(서버가 터짐)를 의미합니다. AI가 코드를 다 짜줘도, 이 숫자를 읽을 줄 아는 사람과 모르는 사람의 디버깅 속도는 차이가 나게 됩니다.
 
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/c08083e5-aed3-4bd6-9fa3-89c162330318/image.png)
⬆️ 눈에 보이지 않는 10초 간의 프로세스
 
 
방금 그 주문은 어디에 저장됐을까요? **데이터베이스와 저장소**(④), **바로 쇼핑몰의 물류센터**입니다. 회원·상품·주문처럼 표로 딱 떨어지는 데이터는 MySQL 같은 관계형 DB에, '최근 본 상품' 같은 임시 정보는 Redis라는 초고속 메모장에, 수만 장의 상품 사진은 AWS S3 같은 대형 창고에 들어갑니다.
 
마지막 질문입니다. 이 쇼핑몰은 **왜 새벽 3시에도 열려 있을까요?** 내 노트북은 잠들면 꺼지지만, 서비스는 24시간 꺼지지 않는 컴퓨터, 즉 서버 위에서 돌기 때문입니다. 이게 **서버와 DevOps**(⑨)의 세계입니다. 몰려드는 접속을 입구에서 정리하고(Nginx), 서비스를 컨테이너 박스에 담아 어디로든 옮기고(Docker), 코드를 고치면 자동으로 검사해서 반영하는 컨베이어 벨트(CI/CD)를 돌립니다. 블랙프라이데이에 쇼핑몰이 버티느냐 터지느냐, 쇼핑몰이 하루에도 몇 번씩 조용히 업데이트되는 비결이 전부 여기에 있습니다.
 
정리하면 이렇습니다. 

 <div style="border-radius: 4px;padding:22px 20px; background: #F5F5F5; border: 1px solid #D6D6D6;">화면(②)에서 담고 → 백엔드(③)가 처리하고 → 물류센터(④)에 저장되고 → 24시간 서버(⑨) 위에서 돌아간다</div>

 
티셔츠 하나가 결제되는 10초는, 사실 이 네 개의 세계가 릴레이하는 10초입니다.
 
 
## 그 쇼핑몰에 'AI 두뇌'를 넣는 법
2000년대 이후 쇼핑몰에는 하나 더 생겼습니다. 바로 홈의 "회원님을 위한 추천", "비슷한 스타일"입니다. 나를 어떻게 알아보는 걸까요?
 
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/0318eba6-113c-4356-9326-db00c3f28bd4/image.png)
⬆️ 쇼핑몰에 AI 두뇌를 넣는 방법
 
 
먼저, **추천은 워낙 많이 인용된 장바구니 추천(Apriori)과 같은 AI 모델(⑤)의 결과물**입니다. 수백만 명의 클릭과 구매 기록에서 "검은색 와이드 팬츠를 산 사람은 며칠 뒤 스니커즈를 본다" 같은 패턴을 기계가 스스로 찾아내는 것, 이게 머신러닝이고, 그걸 훨씬 깊고 큰 규모로 하는 게 딥러닝, 세상의 글을 어마어마하게 읽어 말을 배운 모델이 LLM입니다. 
 
모델을 직접 만들 필요는 없습니다. 사이킷런(scikit-learn, 줄여서 sklearn)과 같은 오픈 소스 라이브러리에서 제공하는 모델을 튜닝만 해도 좋습니다. 다만 AI가 "**데이터를 모아 → 학습시키고 → 평가해서 → 내보내는**" 과정의 결과물이라는 것만 알아도, AI가 왜 가끔 엉뚱한 추천을 하는지(학습 데이터 밖이라서), 왜 모든 회사가 데이터에 목숨을 거는지(데이터가 곧 재료라서)가 보입니다.
 
이제 직접 만들어 볼 차례입니다. 우리 쇼핑몰에 "다음 주 제주도 여행 가는데 4만 원대로 뭐 입을까요?"라고 물으면 대답하는 **AI 점원**을 채용한다고 상상해 보세요. 이게 바로 **생성형 AI와 Agent Engineering**(⑥)입니다. 필요한 기술은 두 가지입니다.
 
하나는 **일 시키는 기술**입니다. 계속 우리를 힘들게 했던 용어들, 프롬프트, 컨텍스트, 하네스 같은 용어가 나오지만, 본질은 신입 점원 교육과 같습니다. "손님 응대해"라고만 하면 사고가 나지만, "우리 몰의 말투는 이렇고, 품절 상품은 권하지 말고, 모르면 상담사를 연결해"라고 배경과 규칙을 정해주면 일이 됩니다.
 
다른 하나는 **우리 쇼핑몰의 자료를 쥐여주는 기술, RAG**(Retrieval-Augmented Generation)입니다. AI는 똑똑하지만 우리 몰의 상품도, 환불 규정도 모릅니다. 그래서 상품 설명과 리뷰를 잘게 잘라 의미를 숫자로 바꾼 뒤, 아까 나온 그 **Vector DB**에 넣어둡니다. 손님이 질문하면 관련 자료를 찾아서 AI에게 함께 건네주는 거죠. 말하자면 **AI 점원에게 오픈북 시험을 보게 하는 것**입니다. 덕분에 AI는 "그 티셔츠는 정사이즈인데, 세탁 후 줄었다는 리뷰가 있어요"처럼 우리 몰의 진짜 정보로 대답하게 됩니다. LangChain 같은 프레임워크는 이 과정을 조립해주는 프레임워크이고요.
 
마지막으로, 이 세계의 신상은 어디서 들어올까요? **AI 지식 생태계**(⑧)입니다. 쇼핑몰 MD가 도매시장에서 신상을 발굴하듯, 새 AI 기술은 arXiv(논문) → Hugging Face(모델 공유) → 벤치마크(성능 비교)라는 길목을 거쳐 세상에 나옵니다. 지금 논문을 읽으라는 게 아닙니다. 신상이 들어오는 길목만 알아두면, 유행을 따라가는 사람이 아니라 먼저 읽는 사람이 됩니다. 저를 포함한 대부분의 연구자, 크리에이터 들은 기사나 논문, 최신 모델을 이렇게 얻습니다.
 
 
## 그래서, 어떤 순서로 배우면 될까? AI Native Engineering 학습 로드맵
여기까지 읽고, "그래서 뭐부터 하라고요?"라는 생각이 들었다면, 정확합니다. 그 질문에 대한 답이 바로 **마인드맵의 ⑩ 학습 흐름**이고, 사실 이 글도 그 순서에 맞춰 구성되어 있습니다.


 <div style="border-radius: 4px;padding:22px 20px; background: #F5F5F5; border: 1px solid #D6D6D6;">웹/앱 → API/DB → 배포 → AI/LLM → RAG/Agent → AI Native Engineering</div>

 
* 눈에 보이는 화면을 먼저 만들고
* 그 뒤의 백엔드와 데이터를 연결하고
* 세상에 배포해서 남이 쓰게 만들고
* 그 위에 AI를 얹고
* 우리 서비스의 자료를 쥐여주고
* 마지막으로 이 전체를 검증하며 운영하는 것

각 단계마다 "나만의 미니 쇼핑몰"을 조금씩 키워간다고 생각하면 됩니다.
상품 목록 화면 하나로 시작해서, 주문 API를 붙이고, 배포하고, AI 추천 점원을 채용하는 식으로요.
 
중요한 건 순서 자체가 아니라 방향입니다. 열 개의 영역은 열 개의 과목이 아니라, **하나의 서비스가 자라나는 한 편의 스토리**입니다. 완벽하게 마스터하고 다음으로 넘어가는 게 아니라, 얇게 한 바퀴 돌고 다시 깊게 도는 것. 그게 AI 시대의 학습법입니다. 모르는 게 나오면 옆자리의 AI에게 물어보면 되니까요.
 
 
## 앞으로의 미래 - 개발자는 사라질까?
단언컨대, 개발자는 사라지지 않습니다. **다만 역할이 바뀔 뿐입니다**. 과거에는 타자기로 글자를 작성하는 타이피스트라는 직업이 있었습니다. 그 직업은 사라졌지만, 글을 쓰는 사람이 사라진 것은 아니었습니다.
 
개발자도 마찬가지입니다. 코드를 직접 작성하는 일은 점점 AI에게 넘어가겠지만, "무엇을, 왜, 어떤 구조로 만들 것인가"를 결정하고, 만들어진 것을 검증하고, 장애가 났을 때 원인을 추적하는 사람은 반드시 필요합니다.
 
오히려 AI 덕분에 한 사람이 기획부터 개발, 배포, 운영까지 전 과정을 아우르는 풀사이클 엔지니어가 될 수 있는 시대이기도 합니다. 그래서 마지막으로 꼭 드리고 싶은 말은 이것입니다.

 <div style="border-radius: 4px;padding:22px 20px; background: #F5F5F5; border: 1px solid #D6D6D6;">바이브 코딩의 짜릿함을 즐기세요. 하지만 거기서 멈추지 마세요.</div>

 
AI가 만들어준 코드 앞에서 "이게 뭐지?"라고 한 번 더 묻는 습관. 
그것이 여러분을 '말로 만드는 사람'에서 'AI Native Engineer'로 성장시킬 것입니다. AI가 만든 결과를 검증하고, 운영하고, 지속적으로 정련하는 것. 지도는 이미 여러분 손에 있습니다.
 
 
### [🔗 AI Native Engineer Map 보러가기](https://ai-native-roadmap-final.vercel.app/)

 
 
### 📌 함께 읽으면 좋은 글
* [바이브 코딩 앱이 현업 서비스가 되기 전에 반드시 넘어야 할 백엔드의 벽](https://community.programmers.co.kr/post/13861?utm_source=&utm_medium=&utm_campaign=&utm_content=data_13861)
* [LLM 성능의 '천장'을 깨는 시대: 백엔드 엔지니어를 찾아라](https://community.programmers.co.kr/post/13729?utm_source=&utm_medium=&utm_campaign=&utm_content=data_13729)
* [AI 기술을 가진 개발자, 실제 채용에서 유리할까?](https://community.programmers.co.kr/post/13433?utm_source=&utm_medium=&utm_campaign=&utm_content=data_13433)


 
 

![정경문 작가님 프로필 카드.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/5e64c3af-26b1-4b64-9a3f-b5ec14236695/%E1%84%8C%E1%85%A5%E1%86%BC%E1%84%80%E1%85%A7%E1%86%BC%E1%84%86%E1%85%AE%E1%86%AB%20%E1%84%8C%E1%85%A1%E1%86%A8%E1%84%80%E1%85%A1%E1%84%82%E1%85%B5%E1%86%B7%20%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%84%91%E1%85%B5%E1%86%AF%20%E1%84%8F%E1%85%A1%E1%84%83%E1%85%B3.png)

바이브 코딩을 넘어 AI Native Engineering으로: AI 시대 개발자 로드맵

OpenAI에서 AI Success Engineer로 일하고 있는 임지훈 님과의 인터뷰, 이번에는 2편을 소개합니다.
 
[1편에서는 AI 시대에 새롭게 주목받는 직무 'AI Success Engineer'의 역할과 업무](https://community.programmers.co.kr/post/13895)에 대해 이야기해보았는데요. 이번에는 한 걸음 더 나아가 AI 시대 개발자의 역할은 어떻게 달라지고 있는지, 앞으로 더욱 중요해질 개발자 역량은 무엇인지, 그리고 AI 분야 취업을 준비하는 방법에 대한 현실적인 이야기를 나눴습니다.
 
AI 시대에도 경쟁력 있는 개발자로 성장하기 위한 현실적인 조언이 궁금하다면, 인터뷰를 끝까지 확인해 보세요!
 
 

<div style="position: relative; max-width: 100%; padding-bottom: 56.25%; height: 0;"><iframe width="560" height="315" src="https://www.youtube.com/embed/uAubSZz43CI?si=UBQVgiU91KlpT1rw" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen="" style="position: absolute; position: absolute; top: 0; left: 0; width: 100%; height: 100%;"></iframe></div>

 
 
 
## AI 트렌드를 선도하는 기업에서 일하시면서, 가장 크게 체감하는 AI 산업의 변화는 무엇인가요?
제가 가장 크게 체감하는 변화 중 하나는 ‘Build vs Buy’에 대한 의사결정이 많이 바뀌고 있다는 점입니다.
 
예전에는 기업이나 개발자가 필요한 기능이 있으면 SaaS를 구매해서 쓰는 것이 일반적이었어요. 직접 개발하는 데 드는 비용이나 시간이 너무 컸기 때문입니다.
 
그런데 AI가 들어오면서 개발 생산성이 크게 올라가고, 특히 초기 프로토타입이나 내부 도구를 만드는 비용이 많이 낮아졌습니다. 예전에는 ‘사는 게 당연했던 것들’을 이제는 ‘직접 만들어도 되지 않을까?’라고 고민하는 경우가 많아진 것 같아요.
 
결국 단순히 기능을 쓰느냐의 문제가 아니라, 이걸 SaaS로 쓸지, 아니면 우리에게 맞게 직접 만들어서 경쟁력으로 가져갈지에 대한 판단 기준 자체가 바뀌고 있다고 느껴요.
 
그래서 요즘은 단순히 구현하는 능력보다, 어디까지를 직접 만들고 어디까지를 가져다 쓸지 결정하는 능력, 즉 아키텍처와 의사결정 역량이 훨씬 더 중요해지고 있다고 생각합니다.
 
 
## 이러한 변화 속에서 개발자의 역할은 어떻게 달라지고 있다고 보시나요?
저는 개발자의 역할이 예전보다 훨씬 넓어졌다고 생각합니다. 예전에는 주어진 요구사항을 받아서 “이 기능을 구현하는 사람”으로 개발자를 보는 시각이 강했다면, 이제는 그것만으로는 충분하지 않다고 느낍니다. 이미 “구현하는 사람” 의 개발자는 없어졌다고 생각합니다.
 
지금은 개발자가 단순히 기능을 만드는 데서 끝나는 것이 아니라, 사용자가 무엇을 원하는지 이해하고, 실제 문제를 정확히 정의한 뒤, 그것을 기술적인 요구사항으로 바꿔서 빠르게 개선까지 연결할 수 있어야 한다고 생각합니다.
 
특히 AI가 들어오면서 단순 구현 자체의 장벽은 점점 낮아지고 있기 때문에, 앞으로는 “무엇을 왜 만들어야 하는지”, “이게 정말 사용자의 문제를 해결하는지”, “피드백을 받아서 얼마나 빠르게 더 나은 방향으로 바꿀 수 있는지”를 이해하고 실행하는 능력이 더 중요해지고 있다고 봅니다.
 
결국 AI 시대의 개발자는 단순히 코드를 작성하는 사람이 아니라, 문제를 이해하고 해결 방향을 설계하고, 빠르게 실행하면서 피드백까지 루프를 닫을 수 있는 사람에 더 가까워지고 있다고 생각합니다.
 
 
## AI 시대에 개발자에게 특히 중요해진 역량은 무엇일까요?
그래서 요즘은 개발자의 역할도 단순히 구현하는 것보다, 어디까지를 직접 만들고 어디까지를 가져다 쓸지 결정하는 능력, 즉 아키텍처와 의사결정 역량이 훨씬 더 중요해지고 있습니다.
 
AI 덕분에 구현 속도 자체는 훨씬 빨라졌기 때문에, 이제는 단순히 코드를 빨리 짜는 것만으로는 차별화되기 어려운 시대가 된 것 같아요. 그래서 더 중요해진 건 무엇을 직접 만들고, 무엇을 활용하고, 어떤 방식으로 시스템을 구성해야 실제 문제를 가장 잘 해결할 수 있는지를 판단하는 능력이라 생각합니다.
 
가장 앞선 AI 기업들조차 이제는 모델을 만드는 데서 끝나지 않고, 그 기술을 실제 현장에 구현하고 정착시키는 데 더 많은 힘을 쏟고 있습니다. 이런 변화는 Forward Deployed Engineer 같은 역할이 점점 늘어나고 있다는 점에서도 상징적으로 드러난다고 생각합니다. FDE 역할은 단순히 AI를 소개하는 것이 아니라, 고객의 실제 환경 안으로 들어가서 문제를 이해하고, 프로덕션 시스템을 만들고, 그 과정에서 얻은 인사이트를 다시 제품 개선으로 연결하는 역할입니다.
 
그만큼 이제는 기술 자체뿐 아니라, 그 기술을 실제로 돌아가게 만드는 실행력이 중요한 경쟁력이 된 것 같습니다. 그래서 앞으로는 AI를 단순히 써본 사람이 아니라, AI를 실제 서비스와 워크플로우에 붙여보고, 배포하고, 운영하고, 개선해본 사람이 더 강한 개발자가 될 거라고 생각합니다. 
 
결국 AI 시대에 개발자에게 특히 중요한 역량은 문제를 정의하고, 구조를 설계하고, 빠르게 실행해서 가치로 연결하는 능력일 것입니다.
 
 
## 요즘 지훈님께서 특히 주목하고 계신 AI 기술 트렌드는 무엇인가요?
저는 백그라운드가 인프라 쪽이라, 개인적으로는 AI 인프라 트렌드를 가장 흥미롭게 보고 있습니다.
 
지금 AI 산업은 기본적으로 “더 많은 compute를 넣으면 모델이 더 똑똑해진다”는 전제 위에서 빠르게 스케일링되고 있고, 그 과정에서 GPU, 네트워크, 데이터센터 같은 인프라 레벨에서 큰 변화가 일어나고 있다고 느낍니다.
 
예를 들어 최근에는 단순히 모델만 발전하는 게 아니라, AI를 위한 전용 칩이나 초대형 데이터센터 같은 인프라가 함께 구축되는 흐름이 나오고 있습니다. 이 정도 규모의 컴퓨팅이 실제로 온라인에 올라왔을 때, 모델의 능력이나 우리가 만들 수 있는 서비스가 어떻게 달라질지 굉장히 기대가 됩니다.
 
또 흥미로운 점은 인프라가 단순히 기술 영역에 머무는 게 아니라 전력, 에너지, 지역 인프라, 환경 같은 영역까지 연결되고 있다는 점입니다. 데이터센터 하나가 들어서면 그 지역의 전력 구조나 산업에도 영향을 주기 때문에, AI 인프라는 앞으로 기술뿐만 아니라 사회적인 트렌드로도 확장될 가능성이 크다고 생각합니다.
 
그래서 이제는 AI 자체뿐 아니라, 이 인프라를 어떻게 활용해서 실제 애플리케이션을 만들고, 유의미한 가치로 연결할 수 있는지를 아는 것이 점점 더 중요해지고 있습니다. AI가 할 수 있는 영역이 점점 많아지고 있기에, 이를 어떻게 똑똑하게 잘 쓸까를 고민하는 것이 중요합니다.
 
그래서 저는 인프라가 덜 중요하다기보다는 오히려 AI 시대에는 가장 근본적인 경쟁력이 되는 영역 중 하나로 보고 있습니다.
 
 
## 취업 준비 과정에서 가장 도움이 되었던 경험은 무엇인가요?
테크 분야에는 정말 엄청난, 많은 회사들이 있습니다. 그리고 그 안에서도 보안, 네트워킹, 데이터베이스, 머신러닝, AI, 웹, 오토모티브, 금융, 블록체인, 로보틱스, 미디어, 엔터테인먼트, 실리콘, 칩 등 많은 분야들이 있습니다. 또 그 안에는 많은 직무들이 존재합니다.
 
꼭 테크 회사가 아니더라도, 산업군마다 필요한 기술 직군이 다 다르고, SAP나 세일즈포스 같은 소프트웨어를 담당하는 스페셜티 직군들도 많습니다.
 
저의 경우에는 이런 회사들, 산업들이 어떤 직무를 필요로 하는지 채용 사이트를 통해 직접 찾아보는 게 많은 도움이 되었습니다. 그러면 내가 할 수 있는 스킬셋 외에, 추가로 배우면 좋을 스킬셋이 뭔지 방향을 잡을 수 있습니다.
 
무작정 준비하기보다는 내가 어떤 분야에 맞는지 탐색해보고, 그 안에서 스페셜티를 찾아 깊게 배우게 된다면 많은 도움이 될 것 같습니다.
 
 
## AI 분야로 취업을 준비하는 분들께 추천하고 싶은 공부 방법이 있을까요?
요즘은 AI 시대 이후에 개발자가 되신 분들을 흔히 ‘AI Native’라고 부르는데요. AI Native 개발자가 되는 것이 중요한 것 같습니다.
 
언제 어떻게 AI를 쓰는 게 가장 효과적인지 아는 것도 중요하고, Twitter(X), Reddit, Hackernews 등의 매체를 통해 지금 시장의 트렌드를 파악하는 것도 필요하다고 생각합니다.
 
지금 어떤 기술이 나오고 있고, 업계에서 어떤 변화가 일어나고 있는지, SOTA(State Of The Art)가 무엇인지 알고 있는 것도 큰 도움이 됩니다.
 
 
## 마지막으로, AI 시대에 개발자 커리어를 준비하는 분들께 한 마디 조언 부탁드립니다.
AI 덕분에 이제는 많은 사람들이 ‘기술’을 갖게 되었습니다. 스킬은 학습 가능한 영역인데, AI가 가르쳐주기도 하고 일부는 대신 해주기도 하죠. 그래서 평균 스킬 레벨은 확실히 올라갔다고 생각합니다.
 
그런데 커리어에서 결국 가장 중요한 건 성과, 즉 임팩트예요. 영어로는 흔히 Measurable Impact라고 하죠. 내가 어떤 문제를 정의했고, 어떤 기준으로 우선순위를 정했고, 어떤 방법과 기술을 써서 결과적으로 무엇이 얼마나 좋아졌는지를 설명할 수 있어야 해요.
 
그래서 개발자 커리어를 준비하실 때 단순히 기술 공부만 하기보다는, 작은 문제라도 끝까지 해결해서 결과를 남기는 연습을 추천드리고 싶어요. 예를 들면 개인 프로젝트나 인턴, 동아리 활동에서도 기능 구현에서 끝내지 말고, 사용자나 팀이 겪는 문제를 얼마나 줄였는지, 시간, 비용, 에러율, 품질이 얼마나 개선됐는지까지 정리해보는 거죠. 그게 쌓이면 면접에서도 스킬이 아니라 임팩트로 이야기할 수 있고, 그게 곧 차별화로 이어집니다.
 
“왜 이 문제를 해결해야 했는지”, “왜 이 방식이 필요했는지” 같은 메타적인 질문들을 스스로 던져보고 답해보는 것도 중요하다고 생각해요.
 
한 마디로, AI 시대에는 ‘잘 만드는 사람’보다 ‘문제를 선택하고 실제로 해결해서 결과를 증명할 수 있는 사람’이 더 좋은 기회를 만들어낼 수 있을 것입니다.

 

 <div style="border-radius: 4px;padding:22px 20px; background: #F5F5F5; border: 1px solid #D6D6D6;">AI의 시대의 흐름 속에서 개발자의 역할은 계속해서 확장되고 있습니다. 변화하는 IT 시장에서도 결국 문제를 정의하고 실제 가치를 만들어내는 것은 개발자 여러분의 역량에 달려 있다는 것, 잊지 마세요! 프로그래머스는 앞으로도 AI 시대의 다양한 IT 직군의 인터뷰와 이야기를 소개해드릴 예정입니다. 다음 인터뷰도 기대해주세요!</div>

 
 
### 📌 OpenAI 임지훈 님 인터뷰 1편 보러가기
* [개발자 취업만 준비했다면 놓칠 수 있는 직무](https://community.programmers.co.kr/post/13895)

AI가 코딩하는 시대, 진짜 경쟁력은 따로 있습니다 | OpenAI AI Success Engineer 임지훈 인터뷰 (2편)

백엔드 데브코스 수료 후 프로그래머스 체험형 인턴십에 참여한 원수연 님을 만나보았습니다. 수연 님은 실제 서비스에 AI를 접목하며 실무 역량을 키우고자 인턴십에 참여했다고 하는데요. AI를 서비스에 녹여내는 과정을 통해 AI 활용 역량은 물론, 실무에 가까운 협업 경험까지 깊이 있게 쌓을 수 있었다고 합니다. 인턴십을 통해 더 넓은 시야를 갖추게 된 수연 님의 이야기를 지금 인터뷰에서 확인해보세요!
 
 
#### 📌 프로그래머스 인턴십이란?
<div style="border-radius: 4px;padding:22px 20px; background: #F5F5F5; display: flex;">프로그래머스 인턴십은 데브코스에서 쌓은 개발 역량을 실제 서비스 개발 경험으로 확장할 수 있도록 설계된 인턴십 프로그램입니다. 4주 동안 AI 서비스의 기획부터 개발, 배포, 최종 발표까지 전 과정을 팀 단위로 수행하며, 그렙(프로그래머스)의 재택 근무 문화를 반영해 전면 재택으로 운영됩니다. 참가자들은 Slack, Notion, GitHub, GLM API, AWS 등 실무에서 활용되는 협업 도구를 사용하며 현업과 유사한 개발 환경을 경험하고, 현업 멘토의 정기 멘토링을 통해 실무 협업 방식과 문제 해결 역량을 함께 키워나갑니다.
</div>

 
 

<div style="position: relative; max-width: 100%; padding-bottom: 56.25%; height: 0;"><iframe width="560" height="315" src="https://www.youtube.com/embed/cvn30dR78KY?si=5K2EWjXwf8ALhCPp" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen="" style="position: absolute; position: absolute; top: 0; left: 0; width: 100%; height: 100%;"></iframe></div>

 
 
 
## 안녕하세요. 간단한 자기소개와 인턴십에 참여하게 된 계기를 소개해주세요.
안녕하세요. 데브코스 백엔드 8기 수료 후 프로그래머스 체험형 인턴십에 참여한 원수연입니다.
 
데브코스 최종 프로젝트에서 Spring Boot를 활용해 실시간 알고리즘 문제 배틀 서비스를 구현하고 배포하며 백엔드 역량을 집중적으로 키웠습니다. 당시에는 생성형 AI를 프로젝트에 적용하자는 의견도 있었지만, 우선은 백엔드 개발 역량을 탄탄히 다지는 데 집중하고자 해당 기능은 제외했었습니다.
 
이번 프로그래머스 인턴십에서는 **AI를 실제 서비스에 직접 적용해볼 수 있고, 실무 중심으로 진행**된다고 들어서 신입 개발자로 취업을 준비하는 저에게 꼭 필요한 경험이라 생각하여 참여하게 되었습니다.
 
 
## 참여 전 가장 기대했던 부분과 걱정됐던 부분은 무엇이었나요?
가장 기대했던 부분은 현업과 가장 가까운 형태의 프로젝트를 직접 경험할 수 있다는 점이었습니다. 실제 실무와 유사한 환경에서 협업하고 개발을 진행해볼 수 있다는 점이 특히 기대되었습니다.
 
한편으로는 제가 실제 업무 환경에 잘 적응해 원활하게 협업하고 맡은 역할을 수행할 수 있을지에 대한 걱정도 있었던 것 같습니다.
 
 
## 인턴십 기간 동안 어떤 프로젝트에 배정이 되었나요?
AI를 활용한 서비스를 직접 기획하고 구축하는 프로젝트를 진행했습니다. 회의를 보조하는 **AI 비서 프로그램인 '플로디(FLODI)'를 기획**했고, 이를 **디스코드 봇 형태로 구현**했습니다.
 
![스크린샷 2026-05-29 오전 11.08.32.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/b32513f1-70b3-4e65-b44e-a52db4156b4e/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202026-05-29%20%E1%84%8B%E1%85%A9%E1%84%8C%E1%85%A5%E1%86%AB%2011.08.32.png)
 
플로디는 음성 회의에 함께 참여해서 실시간으로 질의응답을 지원하는데요. 이전 회의 내용과 현재 프로젝트의 맥락을 함께 이해해서, 과거 회의 데이터를 참고해 답변할 수 있다는 게 가장 큰 특징입니다. 여기에 실시간 자막 서비스, 회의 종료 후 분석 기능, 그리고 프로젝트와 회의 내용을 한눈에 볼 수 있는 웹 페이지까지 구현했습니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/25f279ec-6983-4e22-94b2-63eaba709d99/image.png)
 
저는 **인증/인가 기능과 회의 후 요약·분석 기능 구현**을 맡았어요. 인증/인가 부분은 사용자가 불편함을 느끼지 않을 최소한의 절차만 거치도록 하는 데 집중했습니다.
 
회의 후 요약 및 분석 기능은 회의 원문에서 발화자 정보를 확인하여 어떤 사람이 어떤 업무를 맡았는지, 진행 상황은 어떤지, 그리고 프로젝트 내 주요 의사결정 사항은 무엇인지를 적절히 추출하는 데 중점을 두었습니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/ce6ff37c-fe7f-4cf0-8474-b107305a2dcd/image.png)
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/59456518-f016-4f9a-a72f-4f2b5b6e42c4/image.png)
 
 
## 이번 인턴십 프로젝트만의 특징은 무엇이었나요?
데브코스에서 진행했던 기존 프로젝트들은 백엔드 역량을 강화하고, 이를 명확하게 보여주는 데 초점을 맞췄기 때문에 웹 서비스에 한정하여 프로젝트를 기획했습니다.
 
하지만 이번 인턴십에서 진행한 프로젝트에서는 **특정 기술 스택이나 서비스 형태에 제한이 크지 않았기 때문에 훨씬 자유로운 기획이 가능**했다는 점이 가장 크게 달랐습니다. 그 덕분에 디스코드 봇이나 크롬 확장 프로그램처럼 다양한 프로젝트가 나올 수 있었다고 생각합니다.
 
**생성형 AI를 반드시 접목시켜야 하는 점**도 달랐는데, 단순히 특정 기능에 적용하는 것에 그치지 않고 AI 응답 속도나 품질을 높이기 위한 작업까지 고려되어 깊이 있는 활용이 가능했습니다.
 
또한 **현업자 멘토분들의 피드백과 멘토링**이 프로젝트를 진행하는 데 큰 도움이 되었습니다. 프로젝트 진행 상황 공유를 위해 보고서를 지속적으로 작성하고 공유하는 과정에서 제3자에게 프로젝트를 설명하기 위한 **문서화 역량**까지 함께 기를 수 있었습니다.
 
 
## 프로그래머스 개발자와의 멘토링은 어떤 방식으로 진행되었나요? 가장 인상 깊었던 부분은 무엇이었나요?
멘토링은 현재 프로젝트의 진행 상황과 앞으로의 개발 방향을 공유드리고, 이에 대한 피드백을 받는 방식으로 진행되었습니다. **멘토링을 통해 실제 사용자의 입장에서 서비스를 바라볼 수 있었던 점**이 특히 좋았습니다.
 
멘토님께서 사용자 경험 측면에서 명령어를 최대한 간결하게 구성하는 방향을 제안해주신 부분과 회의 보조 프로그램이라는 서비스 특성상 인증/인가 부분이 지나치게 복잡해지면 사용성이 크게 떨어질 수 있다는 점을 짚어 주신 부분이 인상 깊었습니다.
 
 
## 코드 리뷰나 협업 과정에서 "아, 이게 진짜 실무구나"라고 느낀 순간이 있었나요?
단순히 기능을 구현하는 데서 끝나는 것이 아니라, **사용자가 실제로 불편함 없이 사용할 수 있는 수준까지 성능을 개선하는 과정**이 있었습니다. 이 과정에서 단순한 개발을 넘어 서비스 품질과 사용자 경험까지 함께 고민해보며 실무에 가까운 경험을 하고 있다는 느낌을 강하게 받았습니다.
 
 
## 인턴십을 통해 가장 크게 성장한 부분은 무엇인가요?
AI는 이전까지 프로젝트에 적극적으로 활용해본 경험이 많지 않았는데, 이번 인턴십을 통해 **실제 서비스에 AI를 적용해보면서 많은 것을 배우고 성장**할 수 있었습니다. 어떤 방식으로 프롬프트를 설계할지, 서비스에 어떻게 자연스럽게 접목할지, 또 어떤 모델을 선택할지에 대해 깊이 고민해볼 수 있었습니다.
 
또한 직접 기획한 프로젝트가 실제 서비스 형태로 구현되는 과정에서, 개발 역량뿐만 아니라 **협업 역량이 크게 성장**했음을 느꼈습니다. 동료들과 원활하게 소통하기 위해 전달 방식을 계속 고민했고, 의견 충돌 시 적합한 해결책을 건설적으로 찾아가고자 노력했습니다. 팀 전체가 함께 논의해야 할 문제와 개인이 담당할 문제를 구분하는 과정에서도 섬세한 협업 능력을 기를 수 있었습니다.
 
![스크린샷 2026-05-29 오전 11.10.11.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/44f10d3a-6d73-4cda-b610-a7dc51b0de3a/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202026-05-29%20%E1%84%8B%E1%85%A9%E1%84%8C%E1%85%A5%E1%86%AB%2011.10.11.png)
⬆️ 동료, 멘토님과 긴밀하게 협업하며 완성한 플로디 프로젝트
 
 
## 이번 인턴십 경험이 취업 준비에 어떤 도움이 되었나요?
**기획부터 목표 설정, 개발, 최종 발표까지 프로젝트의 전체 사이클을 단기간에 경험**할 수 있어서 밀도 높은 개발 환경을 직접 체감할 수 있었어요. 포트폴리오와 실무 감각을 키우는 데도 큰 도움이 됐고요.
 
특히 이번 프로젝트에서는 저희 강점과 차별점이 발표에서 최대한 잘 드러나도록 많은 공을 들였는데, 그 경험이 앞으로 면접이나 협업 자리에서 제 역량을 설명해야 할 때 도움이 될 것 같습니다.
 
 
## "이 인턴십 정말 좋은 경험이었다"라고 느낀 부분이 있다면 무엇인가요?
마지막 성과 발표 시간에는 다른 팀들의 결과물과 진행 과정을 함께 확인할 수 있었습니다. 이를 통해 저희 프로젝트의 개선점도 찾을 수 있었고, 다양한 아이디어와 인사이트도 얻을 수 있어 매주 좋은 경험이었습니다.
 
**다른 팀들이 성능 개선을 위해 어떤 노력을 기울였는지, 또 사용자 경험을 고려해 얼마나 디테일하게 유저 플로우를 설계했는지를 보며 많은 자극**을 받았던 점도 좋았습니다.
 
 
## 데브코스 수료 이후 바로 실제 프로젝트를 경험해보며 가장 만족했던 부분은 무엇이었나요?
데브코스에서는 주로 백엔드 역량 강화에 집중해 프로젝트를 진행했는데, 인턴십에서는 AI를 접목한 프로젝트를 수행해보며, **최근 중요성이 커지고 있는 AI 활용 경험을 쌓을 수 있었다는 점**이 가장 만족스러웠습니다.
 
제가 참여한 플로디(FLODI) 프로젝트에서는 사용자의 음성 데이터를 텍스트로 변환하는 STT 기능, 컨텍스트가 길어지는 경우 압축하는 기능, 회의 중 질의응답 기능, 그리고 회의 종료 후 회의 전체 내용을 요약·분석하는 기능에 AI가 사용되었습니다.
 
STT의 경우 오픈소스인 Whisper AI를 사용했고, 그 외 기능에는 일반 LLM API를 적용했습니다. 특히 STT에 어떤 AI를 사용할지 결정하는 과정에서 한국어 인식 품질과 비용 등의 요소를 상세히 고려하며 팀원들과 깊이 논의했던 것이 기억에 남습니다.
 
이처럼 AI를 다방면으로 사용하는 경험을 충분히 가질 수 있었고, 단순한 API호출을 넘어 **프롬프트 설계, AI 응답 검증, 비동기 처리 등 실제 서비스에 AI를 안정적으로 접목하는 과정을 직접 경험**할 수 있었습니다. 이를 통해 AI 기능을 백엔드 시스템과 유기적으로 연결하는 역량을 키울 수 있었습니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/ae1c0a3e-a8f8-4b25-9715-c290550857bc/image.png)
⬆️ STT AI를 결정할 때 사용했던 비교표 및 논의 과정
 
 
## 어떤 분들에게 데브코스 인턴십을 특히 추천하고 싶으신가요?
**데브코스 수료 이후 한 단계 더 밀도 있는 프로젝트 경험을 쌓아보고 싶은 분들에게 추천**하고 싶습니다. 특히 AI 활용 경험이 부족하다고 느끼는 경우에 더욱 도움이 될 것 같습니다.
 
 
## 데브코스 수강을 고민하는 분들에게 해주고 싶은 말이 있다면요?
데브코스는 **체계적인 학습 환경**과 **세심한 학습 관리**가 큰 장점이라고 생각합니다. 
개발자로서의 역량을 확실히 발전시키고, 다른 개발자들과의 연결점을 가질 수 있어 소중한 경험이었습니다. 
데브코스 수강을 고민 중이시라면, 적극 추천합니다!
 
 
 
### 💡 생성형 AI 활용 백엔드 데브코스 9기 모집 중
수료 후 실무 인턴십까지 경험할 수 있는 기회!
⏰ 모집 마감: ~8/20(금)
 
![DEV-AIBE8-coding-test-tablet&screen(1456x180).jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/72f45375-d13a-48b8-8114-6f37bd50dbfa/DEV-AIBE8-coding-test-tablet%26screen%281456x180%29.jpg)

[데브코스 인턴십 후기] AI를 접목한 실무 프로젝트로 한 단계 더 성장했어요 - 백엔드 8기 원수연 님

데브코스를 통해 백엔드 실무 역량과 협업 경험을 쌓아온 오혜승 님의 수강 후기 인터뷰입니다.
네 번의 프로젝트에서 백엔드 팀장을 맡으며 개발 역량은 물론, 협업과 리더십까지 폭넓게 성장할 수 있었다고 하는데요.
단순한 학습을 넘어, 문제를 정의하고 해결하는 실무형 개발자로 성장해 온 과정을 인터뷰에서 확인해 보세요!
 
 
## 안녕하세요. 자기 소개 부탁드립니다.
안녕하세요. 방금 막 따끈따끈하게 수료식을 마치고 온 **백엔드 데브코스 7기** 수료생 오혜승입니다. 컴퓨터 공학을 전공하며 프론트엔드를 공부했지만, 기능이 실제로 동작하는 흐름을 만들고 문제를 해결해 나가는 과정에 더 큰 흥미를 느끼게 되어 백엔드로 전향하게 되었습니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/40c32219-25c4-432d-b025-41142e594a8e/image.png)
 
 
## 프로그래머스 데브코스는 어떻게 알게 되셨나요? 타 기관도 있지만 프로그래머스의 데브코스를 선택하신 이유가 궁금합니다.
졸업 후 여러 프로젝트를 진행하면서 개발 경험을 쌓아갔지만, 실무에 바로 투입되기에는 아직 부족한 점이 많다고 느꼈습니다. 그 과정에서 한 멘토님께 부트캠프를 권유 받았고, 다양한 부트캠프 교육을 찾아보던 중 프로그래머스 데브코스를 알게 되었습니다.
 
데브코스는 **현업 개발자 멘토링 시스템과 프로젝트 중심의 커리큘럼**, 프론트엔드 기수와의 실무형 협업 경험을 제공한다는 점에서 큰 매력을 느꼈습니다. 또한 **비대면으로 진행되어 지역에 제약이 없다는 점**, 그리고 6개월이라는 충분한 학습 기간이 저에게 가장 적합하다고 판단해 데브코스를 선택하게 되었습니다.
 
 
## 데브코스에 참여하며, 가장 기억에 남는 경험은 무엇인가요?
### ✅ 팀 프로젝트
첫 번째로 가장 기억에 남는 것은 프로젝트 경험입니다.
 
**총 네 번의 프로젝트에서 백엔드 팀장을 맡아 모두 우수팀으로 선정되는 값진 성과**를 얻었습니다. 모든 프로젝트가 의미 있었지만, 그중에서도 첫 번째 프로젝트가 가장 기억에 남습니다.
 
교육 과정 초반에 구성된 팀이어서 서로 어색한 분위기 속에서 시작했지만, **하루 10시간 이상 몰입**하며 프로젝트를 진행한 경험도, 처음 만난 팀원들과 **협업하며 팀을 이끌어 본 것**도 모두 처음이었기 때문입니다.
 
팀원 모두가 적극적으로 참여해 준 덕분에 우수팀으로 선정되는 성과를 거둘 수 있었고, 개인적으로도 그 어느 때보다 열정적으로 임한 프로젝트였습니다. 이 경험은 다음 프로젝트에서도 더욱 적극적으로 참여할 수 있는 원동력이 되었습니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/88831049-fe90-4fad-a399-f2663a9c5af7/image.png)
 
### ✅ 현업 개발자와의 멘토링
두 번째로 인상 깊었던 경험은 프로젝트를 진행하며 만났던 현업 개발자 멘토님과의 멘토링입니다.
 
**각 프로젝트마다 현업 개발자 멘토님이 배정되어, 프로젝트 전반에 걸쳐 지속적인 피드백**을 받을 수 있었습니다. 주니어 개발자인 제가 시니어 개발자의 관점에서 코드를 바라보고 조언을 들을 수 있다는 점이 데브코스의 가장 큰 강점이라고 느꼈습니다.
 
멘토링은 단순히 "이게 맞다, 틀리다"를 판단하는 게 아니라, **왜 이런 선택이 필요한지, 어떤 트레이드오프가 있는지, 그리고 병목은 어디에서 발생할 수 있는지**를 함께 짚어주는 방식으로 진행되었습니다. 그 덕분에 스스로 문제를 해결할 수 있는 시야를 키울 수 있었습니다.
 
멘토링 경험은 기술적인 성장뿐 아니라, 개발자로서 어떤 방향으로 성장해야 할지에 대한 기준을 세우는 데에도 큰 도움이 되었습니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/6b3e65c4-dbd1-40fc-a0f0-5b89c07226de/image.png)
 
 
## 데브코스 중간에 실시되는 역량진단평가가 학습에 있어 어떤 도움이 되었나요?
프로젝트에 몰입하다 보면 CS 지식이나 알고리즘을 소홀히 하기 쉬운데, **데브코스에서 분기마다 진행되는 역량 진단 평가를 통해 이러한 부분을 체계적으로점검**할 수 있었습니다. 그 덕분에 학습 방향을 다시 조정하기도 하고, **내가 어떤 부분이 부족한지 객관적으로 점검**할 수 있어 큰 도움이 되었습니다.
 
 
## 최종 프로젝트에서 어떤 서비스를 만들었나요? 그 과정에서의 경험도 말씀해주세요.
최종 프로젝트로 시간과 공간이라는 물리적 조건을 디지털 메시지에 접목한 **감성 커뮤니케이션 플랫폼** '**Dear.__(디어)**'를 만들었습니다. **특정 시간이나 특정 장소에 도달해야만 열리는 메시지**를 통해, '지금'이 아니라 '적절한 순간'에 도달하는 경험을 제공하고자 기획한 서비스입니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/a6130fed-898b-4179-874c-5a226fe24bf6/image.png)
 
저는 백엔드 팀장을 맡아 프로젝트 전반의 기술적 의사결정과 문제 해결 과정에 참여했으며, 특히 **선착순 캡슐의 동시성 제어**와 **해제 조건 이상 탐지 모니터링 기능**을 담당했습니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/fbc5bc66-89ec-41ea-9e69-360d834a7315/image.png)
 
선착순 인원을 10명으로 설정한 경우, 100명이 동시에 접근하더라도 정확히 10명만 열람할 수 있어야 했습니다. 동시성 제어 방식을 여러 차례 개선하는 과정에서 트랜잭션 경계 설정 문제와 커넥션 풀 고갈 이슈를 발견했고, JMeter로 부하 테스트를 진행하며 문제를 재현했습니다. 최종적으로 Redission 기반 분산 락으로 재설계하여 안정적으로 해결할 수 있었습니다. **이론으로만 알고 있던 동시성 제어를 실제 부하 상황에서 직접 경험하며 체득**할 수 있었습니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/49318e33-51b8-4dd1-bbcc-966a5f4ca2b7/image.png)
 
또한 위치나 시간 조작을 통한 불공정한 이득을 방지하기 위해 해제 조건 이상 탐지 시스템을 구축했습니다. 캡슐 열람 시 시간·위치 데이터를 지속적으로 로깅하고, 비정상적인 GPS 이동, 서버 시간 대비 과도한 클라이언트 시간 차이, 반복 실패 요청 패턴 등을 감지해 의심 점수를 누적했습니다. Redis 기반 7일 TTL 시스템으로 100점 이상 누적 시 자동 정지되도록 했고, IP 차단과 Rate Limit을 단계적으로 적용하는 보안 체계를 완성했습니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/83589dfd-1cf7-4c50-a769-13085a9532f0/image.png)
 
최종 프로젝트는 프론트엔드 기수와 협업했다는 점에서 이전 프로젝트들과 달랐습니다. 단순히 백엔드에서 에러 코드를 반환하는 수준을 넘어, 각 에러 코드가 어떤 상황에서 발생하는지, 프론트엔드에서 어떻게 처리해야 하는지를 명시한 API 문서를 작성해 공유했습니다. 에러 코드 체계와 응답 구조를 함께 설계하며 상호 이해를 높였고, 프론트엔드에서 필요한 값을 서버에서 선제적으로 계산해 제공함으로써 프론트엔드의 부담을 줄였습니다. **서로의 구조를 이해하고 배려하며 소통하는 과정에서 실무에 가까운 협업 방식**을 배울 수 있었습니다.
 
또한 강사님, FT님, 멘토님의 중간 점검을 통해 **기능 구현을 넘어 설계 의도와 트레이드오프까지 고민하며 코드를 개선**할 수 있었고, 실제 서비스를 운영하는 관점에서 **보안과 신뢰도를 고민**해볼 수 있었습니다.
 
프론트엔드와 백엔드가 서로를 이해하고 배려하는 문화를 만들어가며 협업했고, 그 결과 최종 프로젝트에서 최우수팀과 인기상을 동시에 수상하는 성과를 얻을 수 있었습니다.
 
 
### 🔍 최종 프로젝트 보러가기
* [GitHub](https://github.com/prgrms-web-devcourse-final-project/WEB7_9_FullChamZal_BE)
* [배포 URL](https://web.dear4u.cloud/)

 
 
## 데브코스를 통해 이루고자 했던 목표는 무엇이었나요? 얼마나 달성했나요?
개발자로 취업을 준비하면서 "과연 내가 개발자로 적합한 사람일까?", "실무에서 통할 만큼의 역량이 있을까?"라는 고민을 끊임없이 해왔고, 자신감도 많이 떨어져 있던 상태였습니다.
 
데브코스를 시작할 당시에는 개발 역량을 끌어올리는 데만 집중하자는 마음이었습니다. 하지만 **프로젝트를 거듭하며 새로운 기술을 사용하는 것에 대한 두려움이 줄고, 오히려 도전하는 데 자신감**을 얻게 되었습니다.
 
처음 만난 사람들과도 팀을 이루어 적극적으로 소통하고 협업하며, **커뮤니케이션 능력 역시 많이 향상**되었다고 느낍니다.
 
무엇보다 가장 큰 변화는 **기술을 바라보는 관점**이었습니다. 이전에는 기술이나 라이브러리를 '좋다고 해서 써보는' 수준이었다면, 데브코스를 거치며 문제 상황을 먼저 정의하고, 왜 이 기술이 필요한지, 어떤 트레이드오프가 따르는지를 고민할 수 있게 되었습니다. 예전에는 에러가 발생하면 당황했지만, 이제는 로그를 분석하고 원인을 추적할 수 있게 되었습니다.
 
이러한 변화를 통해 단순히 코드를 작성하는 개발자가 아니라, **문제를 정의하고 해결할 수 있는 실무형 백엔드 엔지니어로 한 단계 성장**했다고 느끼고 있습니다.
 
 
## 수업을 진행해주셨던 강사님은 어떠셨나요?
강사님께서는 단순히 이론을 전달하는 데 그치지 않고, **실습 과정에서 어떤 흐름으로 결과가 도출되는지를 상세히 설명**해 주셨습니다. 또한 모든 강의를 녹화해 공유해 주셔서, 반복해서 복습하며 이해를 깊이 있게 다질 수 있었던 점도 큰 도움이 되었습니다. **프로젝트 진행 중에도 놓치기 쉬운 부분이나 개선이 필요한 지점을 짚어 주시며 방향성을 제시**해 주신 덕분에, 개발자로서 한 단계 더 성장할 수 있었습니다.
 
이뿐만 아니라 강의 진행을 도와주신 FT님과, 많은 인원이 참여하고 아침 일찍 시작되는 강의임에도 불구하고 늘 세심하게 케어해 주신 매니저님 덕분에 6개월이라는 긴 기간 동안 흔들림 없이 끝까지 완주할 수 있었다고 생각합니다.
 
 
## 함께 스터디한 동료는 어땠나요? 데브코스에서의 동료 경험에 대해 공유해 주세요.
온라인 과정이기 때문에 다양한 지역, 다양한 배경의 사람들이 모였다는 점이 매우 인상 깊었습니다. 그만큼 다양한 시선과 의견을 접할 수 있었고, 모두가 개발자를 목표로 진지하게 학습에 임하고 있었기에 프로젝트 몰입도 역시 높았습니다.
 
특히 최종 프로젝트 팀원들과는 협업이 매우 잘 맞았고, 과정이 끝난 지금도 연락을 이어가며 오프라인에서 만나기로 약속할 만큼 소중한 인연으로 남았습니다. 함께 목표를 향해 몰입했던 경험이 **단순한 팀 활동을 넘어, 지속적인 동료 관계**로 이어졌다고 생각합니다.
 
![수정.jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/25f715cc-9f6f-46e1-8bc8-6c6dbebeec37/%E1%84%89%E1%85%AE%E1%84%8C%E1%85%A5%E1%86%BC.jpg)
 
또한 저는 '배고픈 블로그 챌린지: 개발편' 스터디를 직접 개설해 **5명의 스터디원들과 함께 매주 블로그 게시물을 작성하고 공유하는 활동을 진행**했는데요. 스터디는 매주 강의 영상이나 알고리즘 문제 중 하나를 공통 주제로 선정해 글을 작성하고, 개인적으로 학습한 내용도 자유롭게 정리하는 방식으로 운영했습니다.
 
스터디 덕분에 블로그를 꾸준히 작성하고 학습 내용을 문서로 정리하는 습관을 기를 수 있었고, 다른 사람의 글을 읽으며 놓쳤던 개념을 보완하는 동시에 글쓰기 역량까지 함께 높일 수 있었습니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/394d98f2-e51e-43f8-a44a-24d2e7e68e0c/image.png)
 
 
## 멘토링은 어땠나요? 학습에 많은 도움이 되었는지 궁금합니다.
데브코스 기간 동안 FT님과 각 프로젝트별 현업 멘토님과의 **멘토링이 약 10회 가까이 진행**되었고, 모든 멘토님께서 기꺼이 자신의 경험과 지식을 나누어 주셨습니다. 커리큘럼 외에 실무적인 개발 지식과 관점을 접할 수 있었고, **프로젝트의 완성도를 높이는 데 큰 도움**이 되었습니다.
 
모든 멘토링이 좋았지만, 특히 최종 프로젝트 멘토링이 가장 기억에 남습니다. 기술적인 해결책뿐만 아니라, '왜 이 방식이 실무에서 더 적합한지', '어떤 상황에서 어떤 선택을 해야 하는지'와 같은 **실무적인 판단 기준**을 배울 수 있었습니다. 이를 통해 문제를 바라보는 시야가 넓어졌고, 개발자로서의 방향성을 명확히 잡을 수 있었습니다.
 
 
## 특별히 기억에 남거나 도움이 되었던 취업 지원이 있었다면 말씀해주세요.
정규 수업 이후 저녁 시간에 **현업 개발자나 커리어 매니저를 초청한 특강이 정기적으로 진행**되었습니다. 유명 기업의 개발자분들이 직접 오셔서 실무 경험을 공유해 주시기도 했고, 알고리즘이나 특정 기술 주제에 대한 특강도 제공되었습니다.
 
수료 직전에는 **이력서, 포트폴리오, 모의 면접을 중심으로 한 커리어 세션**이 진행되어 실질적인 취업 준비에 큰 도움을 받을 수 있었습니다. **수료 이후에도 일정 기간 동안 취업 지원**을 받을 수 있다는 점도 인상 깊었습니다.
 
 
## 백엔드 데브코스를 한 문장으로 표현한다면?
개발자로서 스스로를 믿게 해 준 과정
 
 
## 앞으로 어떤 개발자가 되고 싶으신가요?
**기술적으로 신뢰할 수 있고, 함께 일하고 싶은 개발자**가 되고 싶습니다.
 
단순히 기능을 구현하는 것을 넘어, 동시성 제어나 보안처럼 눈에 보이지 않지만 서비스의 근간이 되는 부분을 고민하고 설계할 수 있는 개발자로 성장하고 싶습니다. 아키텍처와 기술적 의사결정까지 함께 고민하며, 더 나은 방향을 제시할 수 있는 개발자가 되는 것이 목표입니다.
 
 
## 마지막으로 백엔드 데브코스 수강을 고민하는 분들에게, 추천의 한마디 부탁드립니다!
저 역시 데브코스를 시작하기 전까지 많은 고민을 했습니다. 전공자인데 굳이 부트캠프가 필요할까 하는 생각도 들었지만, 지금 돌아보면 조금 더 일찍 시작하지 못한 점이 아쉽게 느껴집니다.
 
저처럼 전공자임에도 실무 역량에 대한 갈증이 있거나, **체계적인 협업 경험과 현업 멘토링이 필요하다고 느끼는 분들에게 데브코스는 분명 큰 전환점**이 될 수 있다고 생각합니다!
 
 
*강의 운영 사정에 따라 세부 프로그램 내용은 변경될 수 있습니다.*
 
 
[![DEV-BE-coding-test-02(1456x180).jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/f5675829-b310-479d-9572-9b6932a9d28b/DEV-BE-coding-test-02%281456x180%29.jpg)](https://school.programmers.co.kr/learn/courses/25579?utm_source=prgmblog&utm_medium=social&utm_campaign=school_25579_sales&utm_content=blog_banner)

[데브코스 후기] 네 번의 프로젝트를 이끌며 실무형 백엔드 개발자로 성장했어요 - 백엔드 7기 오혜승 님

상반기 취업 준비 중이라면, 이 고민 한 번쯤 해보셨죠?
 
"나 지금 제대로 준비하고 있는 걸까?"
"이 방향이 맞는지 모르겠다..."
 
혼자 끌어안고 있던 고민,
이제는 전문가에게 직접 물어보세요!
 
프로그래머스 현업 개발자 직접 여러분의 고민을 듣고 현실적인 해결 방향을 짚어드립니다.
 
지금 데브코스 고민 상담소에서 답을 찾아보세요! 📮
 
[![PRGMS-CONSULTING-EVENT-yjgd-poster(1284x1818).jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/e33ffd1e-268d-4e36-98d8-7305bfcd65ed/PRGMS-CONSULTING-EVENT-yjgd-poster%281284x1818%29.jpg)](https://docs.google.com/forms/d/e/1FAIpQLSelyG0HN12nV9kfTCOvfX1uPYhshX7hSKOiAB2ZNRaRrLifsw/viewform?utm_source=prgmblog&utm_medium=social&utm_campaign=school_devconsulting&utm_content=poster)
 
 
## 이벤트 기간
2026년 4월 1일(수) ~ 4월 22일(수)
 
 
## 참여 방법
구글폼에서 나의 취업 준비 상황과 고민을 작성하고 제출하면 끝!
**💡 구글폼 항목을 구체적으로 작성할수록 선정 확률이 높아집니다.**
 
👉 **[구글폼에서 신청하기](https://docs.google.com/forms/d/e/1FAIpQLSelyG0HN12nV9kfTCOvfX1uPYhshX7hSKOiAB2ZNRaRrLifsw/viewform?utm_source=prgmblog&utm_medium=social&utm_campaign=school_devconsulting&utm_content=poster)**
 
 
## 참여 혜택 🎁
### ✅ 우수 참여자
* 20+년차 개발자 프로그래머스 Dev센터장의 1:1 컨설팅 기회 (3명)
* 프로그래머스 Dev센터 현업 개발자의 서면 피드백 (10명)
 
### ✅ 참여자 전원 제공
* 프로그래머스 취업 고민 상담소 리포트 (전원 제공)

 
## 프로그래머스 Dev센터란?
프로그래머스 Dev센터는 실제 서비스를 만드는 개발자들이 모여, 실무의 기준과 Best Practices를 만들어가는 프로그래머스의 핵심 개발 조직입니다.
 
실무 경력 20년 이상의 (현)Grepp Dev 센터장 · (전)SK플래닛 CTO가 직접 참여해, 개발자 커리어에 대한 현실적인 방향과 인사이트를 제공합니다.
 
 
 
<div style="border-radius: 4px;padding:22px 20px; background: #F5F5F5; border: 1px solid #D6D6D6;">상반기 취업에 속도를 내야 할 지금,
 
포트폴리오 준비부터 커리어 방향까지 막막했던 고민들을 데브코스와 함께 해결해보세요! 
프로그래머스가 여러분의 성장을 응원합니다 🚀

 

[![PRGMS-CONSULTING-EVENT-coding-test-tablet&screen(1456x180).jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/47fc83f1-6e15-4aca-9226-65eb9c624c8e/PRGMS-CONSULTING-EVENT-coding-test-tablet%26screen%281456x180%29.jpg)](https://docs.google.com/forms/d/e/1FAIpQLSelyG0HN12nV9kfTCOvfX1uPYhshX7hSKOiAB2ZNRaRrLifsw/viewform?utm_source=prgmblog&utm_medium=social&utm_campaign=school_devconsulting&utm_content=poster)

[데브코스 이벤트] 상반기 취업 고민, 데브코스 고민 상담소에서 해결하세요!

앱 개발은 다양한 산업에서 활용되며, 이에 따라 개발자에 대한 수요가 꾸준히 증가하고 있습니다. 모바일 앱 개발을 위해서는 프론트엔드, 백엔드, 풀스택, 네이티브 개발 등 여러 분야를 학습할 수 있으며, React Native, Flutter, Swift, Kotlin 등의 기술을 활용할 수 있습니다. 또한 UI/UX 디자인, 데이터베이스 관리, 유지보수 및 업데이트 등 실전 경험도 매우 중요한 요소인데요. 이번 포스팅에서는 앱 개발자의 전망과 하는 일, 앱 개발을 위해 필요한 학습 등을 살펴보겠습니다.
 
# 1. 앱 개발자의 전망
모바일 앱은 우리의 일상생활 곳곳에 깊이 자리매김하고 있어 디지털 전환을 주도하는 중요한 요소로 작용하고 있는데요. 이에 따라 앱 개발자에 대한 수요는 계속해서 증가하고 있으며, 최근엔 1인 사업을 꿈꾸며 앱 개발을 공부하는 분들의 비율도 점차 증가하고 있습니다.
 
### 1) 다양한 분야에서의 활용
앱은 건강, 교육, 금융, 엔터테인먼트 등 다양한 분야에서 활용되고 있습니다. 이렇게 다양한 분야에서 앱을 활용한다는 것은 앱 개발자에게 다양한 프로젝트의 기회를 제공한다는 의미입니다.
 
### 2) 비교적 쉬운 개발 난이도와 창업 기회
모바일 앱 개발은 비교적 낮은 진입 장벽을 가지고 있어 독립적인 개발자나 스타트업 기업에게도 매력적인 분야입니다. 번뜩이는 아이디어가 떠올랐다면, 직접 앱을 개발하여 출시하고 수익을 올릴 수 있습니다.
 
### 3) 글로벌 시장
모바일 앱은 지역 제한 없이 전 세계적으로 서비스될 수 있는 제품입니다. 이러한 글로벌 시장에서의 활동은 앱 개발자에게 큰 장점을 제공합니다. 다양한 문화와 언어에 적응하며 전 세계적인 사용자들에게 서비스를 제공할 수 있는 능력은 앱 개발자의 경쟁력을 높일 수 있습니다.
 
# 2. 앱 개발자가 하는 일
앱 개발자는 모바일 애플리케이션을 디자인하고 개발하는 전문가입니다. 주로 모바일 운영 체제(Android, iOS)를 기반으로 한 소프트웨어 애플리케이션을 개발합니다.
 
![33771309_2209.i201.039.F.m004.c9.mobile app development isometric.jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/2d9c0cd2-bc9f-42ac-9550-641d43a3cd5c/33771309_2209.i201.039.F.m004.c9.mobile%20app%20development%20isometric.jpg)
 
### 1) 요구 사항 분석
클라이언트 또는 팀과 함께 모바일 앱의 요구 사항을 이해하고 분석합니다. 이를 토대로 앱의 기능, 사용자 경험, 디자인 등을 결정하고 기획합니다.
 
### 2) 앱 디자인
사용자의 요구 사항과 기능을 바탕으로 앱의 디자인을 계획하고 UI/UX를 설계합니다. 이를 통해 사용자가 직관적이고 편리한 사용자 경험을 얻을 수 있도록 합니다.
 
### 3) 프로그래밍
앱을 개발하기 위해 프로그래밍 언어와 프레임워크를 사용합니다. 앱의 기능을 구현하고 프로그래밍 코드를 작성합니다.
 
### 4) 유지보수 및 업데이트
앱이 출시된 후에도 개발자는 지속적으로 앱의 유지보수를 수행하고 업데이트를 제공합니다. 새로운 기능 추가, 버그 수정, 보안 강화 등을 위해 앱을 지속적으로 관리합니다.
 
### 5) 고객 지원
사용자들로부터의 피드백을 수집하고 문제를 해결하기 위해 고객 지원을 제공합니다. 사용자들의 요구에 신속하게 대응하여 만족스러운 앱 사용 경험을 제공합니다.
 
# 3. 앱 개발을 위해 어떤 부분을 고려해야 하나요?
### 1) 프로그래밍 언어
모바일 앱 개발을 위한 주요 프로그래밍 언어를 이해하고 숙지해야만 각 플랫폼에 맞는 앱을 개발할 수 있습니다. 대표적인 언어는 JavaScript, Java, Kotlin, Swift 등이 있습니다. JavaScript를 배울 경우 React Native를 통해 안드로이드 및 iOS 앱을 동시에 개발할 수 있습니다.
 
### 2) 개발 환경 및 도구
Android Studio(Android) 및 Xcode(iOS)와 같은 통합 개발 환경(IDE)을 이해하고 사용하는 것이 중요합니다. 이러한 도구들을 통해 앱의 개발, 디버깅, 테스트 등을 수행할 수 있습니다.
 
### 3) UI/UX 디자인
사용자 인터페이스(UI)와 사용자 경험(UX)을 디자인하는 능력은 모바일 앱의 성공에 중요한 역할을 합니다. 각 플랫폼(Android, iOS)의 디자인 가이드라인을 숙지하고, 직관적이고 사용자 친화적인 UI를 구현해야 합니다.
 
### 4) 데이터베이스 관리
사용자 데이터를 효율적으로 저장하고 관리하기 위해 데이터베이스 관리 시스템(DBMS)을 사용해야 합니다. SQLite, Realm 등의 경량 데이터베이스부터 MySQL, PostgreSQL 등의 관계형 데이터베이스까지 다양한 데이터베이스를 다뤄볼 수 있어야 합니다.
 
 
## 어떤 프레임워크를 선택해야 할까?
플러터(Flutter)와 리액트 네이티브(React Native)는 모바일 애플리케이션을 개발하기 위한 대표적인 프레임워크입니다. 각각의 특징과 장단점에 대해 알아보겠습니다.
 
![Frame 3.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/b1de299d-e008-4ee0-8ff5-5b1b8dbdc2be/Frame%203.png)
 
### 1) 언어 및 프레임워크
* 플러터(Flutter): 다트 언어를 사용하며, 구글이 개발하고 유지보수합니다. UI 구성 요소와 비즈니스 로직이 모두 다트 언어로 작성됩니다.
* 리액트 네이티브(React Native): 자바스크립트를 사용하며, Facebook이 개발하고 유지보수합니다. 자바스크립트로 작성된 코드는 네이티브 UI 구성 요소와 상호작용하고, 네이티브 기능에 접근할 수 있습니다.

### 2) UI 구성 요소
* 플러터(Flutter): 위젯(Widget)을 사용하여 UI를 구성합니다. UI가 랜더링되는 방식과 상태 관리가 더 직관적입니다.
* 리액트 네이티브(React Native): 리액트 컴포넌트를 사용하여 UI를 작성합니다. 리액트의 상태 및 props 시스템을 이용하여 UI를 업데이트하고 관리합니다.

### 3) 개발 환경
* 플러터(Flutter): Android Studio, IntelliJ IDEA 등의 통합 개발 환경을 사용할 수 있습니다.
* 리액트 네이티브(React Native): Visual Studio Code, Atom 등의 텍스트 편집기를 사용할 수 있습니다.

### 4) 커뮤니티 및 생태계
* 플러터(Flutter): 상대적으로 작지만 빠르게 성장하고 있습니다. 구글의 지원을 받고 있으며, 활발한 커뮤니티와 다양한 패키지를 제공합니다.
* 리액트 네이티브(React Native): 큰 커뮤니티와 다양한 패키지 생태계를 가지고 있으며, Facebook 및 다른 회사들에 의해 지원되고 있습니다.

 
# 4. 앱 개발을 위해 어떤 부분을 학습해야 하나요?
앱 개발을 위해 학습해야 하는 분야는 목표에 따라 달라질 수 있습니다. 어떤 유형의 앱을 만들고 싶은지, 개인 프로젝트인지, 취업이 목표인지에 따라 학습 방향이 달라질 수 있습니다.
 
### ✅ 프론트엔드
* 사용자가 직접 보는 UI/UX를 개발
* 기술 스택: HTML, CSS, JavaScript, React Native, Flutter
* 추천 학습: 모바일 앱 UI/UX, 반응형 디자인, 애니메이션

 
### ✅ 백엔드
* 서버, 데이터베이스, API 개발 및 관리
* 기술 스택: Node.js, Express, Django, Spring Boot, Firebase, MySQL, MongoDB
* 추천 학습: RESTful API, GraphQL, 인증 및 보안

 
### ✅ 풀스택
* 기술 스택: MongoDB, Express, React, Node.js, Flutter + Firebase
* 추천 학습: 전체 개발 프로세스, 배포 및 유지보수

 
### ✅ 네이티브 앱 개발
* iOS 또는 Android 전용 앱 개발
* 기술 스택: Swift(iOS), Kotlin(Android)
* 추천 학습: 플랫폼별 개발 가이드, 성능 최적화

 
앱 개발을 위한 학습에 있어 실습과 프로젝트가 무엇보다도 중요합니다. 배우면서 바로 적용하는 것이 앱 개발 학습의 핵심! 프로그래머스 데브코스 프론트엔드, 백엔드, 풀스택 과정과 함께 성장해보세요. 😊

앱 개발자가 되는 법: 전망과 역할 & 필수 학습 가이드

안녕하세요, 프로그래머스입니다.
개발자 취업/이직을 준비하다 보면 포트폴리오를 어떻게 구성해야 할지 막막한 순간을 한 번쯤은 겪게 되는데요.
오늘은 길벗 출판사와 함께 합격률을 높이는 포트폴리오 핵심 구성과 꿀팁들을 전해드리려고 합니다.
 
## 현장에서 픽(Pick)하는! 합격률 높이는 개발자 포트폴리오 핵심 구성 7가지
[![프로그래머스_현장픽_이미지 (1).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/d7115d49-f71b-4015-b3e9-fbf29f0d4be5/%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%84%80%E1%85%B3%E1%84%85%E1%85%A2%E1%84%86%E1%85%A5%E1%84%89%E1%85%B3_%E1%84%92%E1%85%A7%E1%86%AB%E1%84%8C%E1%85%A1%E1%86%BC%E1%84%91%E1%85%B5%E1%86%A8_%E1%84%8B%E1%85%B5%E1%84%86%E1%85%B5%E1%84%8C%E1%85%B5%20%281%29.png)](https://gilbut.co/c/26035892gX)
 
포트폴리오는 프로젝트의 성격이나 강조하고 싶은 포인트에 따라 항목을 자유롭게 선택하고 구성하는 것이 중요합니다. 프로젝트가 가장 잘 돋보이도록 순서를 구성하여 작성하면 됩니다.
 
이번 내용은 네이버 밴드 서비스 백엔드 개발을 통해 대규모 서비스 환경을 경험하고, 2020년부터 취업 준비생 대상 세미나를 꾸준히 진행해오신 신보람 저자의 『**현장에서 픽하는 IT 서비스 개발을 위한 실무 지식**』을 바탕으로 발췌·요약했습니다.
 
 
## 1. 프로젝트의 개요와 사용한 기술 스택
포트폴리오 서두에 프로젝트 개요와 기술 스택을 한눈에 파악할 수 있도록 정리해야 합니다. 이는 면접관이 전체 맥락을 이해하는 데 필수적인 정보입니다. 읽는 사람은 프로젝트를 처음 접한다는 점을 염두에 두고, 논리적인 흐름을 위해 개요와 기술 스택을 앞부분에 배치하면 좋습니다.
 
개요에는 다음 정보를 포함합니다.
 

| 구분 | 내용 |
| --- | --- |
| **프로젝트 이름과 간단한 설명** | 어떤 목적의 서비스인지 요약 |
| **개발 기간** | 개발 시작과 종료 기간 |
| **팀 구성** | 개인/팀 프로젝트 여부, 팀 프로젝트라면 인원과 역할 |
| **사용한 기술 스택** | 프론트엔드, 백엔드, 데이터베이스, 인프라 등을 항목별로 정리 |

 
기술 스택은 실무 투입 가능성을 가늠하는 중요한 기준이며, 면접관은 이를 통해 회사의 기술 환경과 적합성을 판단합니다.
기술이 다르더라도 깊이 이해하고 활용했다면 빠른 적응력이라는 장점으로 작용할 수 있습니다.
다만 기술 분류 오류나 오타는 감점 요인이므로 정확히 작성해야 하며, 사용한 프레임워크나 도구는 빠짐없이 포함시켜야 서류 전형에서 유리합니다.
 
 
## 2. 자신이 맡은 역할과 구현한 기능
개인 프로젝트라면 모든 기능을 직접 구현했을 테니 이 항목을 작성할 필요가 없지만, 팀 프로젝트라면 자신이 맡은 역할과 기여한 부분을 명확히 설명해야 합니다. 
면접관은 결과물 전체가 아니라 지원자가 실제로 무엇을 했는지에 관심이 있습니다. 
자신이 구현하지 않은 부분을 맡았다고 부풀려 썼다가는 면접 질문 몇 개만으로도 바로 들통나 버립니다. 
솔직함과 신뢰도는 기본 중에 기본입니다.
 
‘맡은 역할’은 기능 나열보다는 '프런트엔드와 협의해 댓글 구조를 설계하고, 백엔드 API 구현을 담당'과 같이 **설계, 협업, 기술적 판단이 드러나도록 작성**하는 것이 좋습니다.
 
 
## 3. 데이터베이스 설계
백엔드 프로젝트나 내부 데이터베이스를 사용하는 앱 개발의 경우 데이터베이스 설계는 구조화된 사고와 설계 역량을 보여주기에 좋은 포인트입니다. 
데이터 중심 프로젝트라면 구체적으로 다루는 것이 좋지만, 단순한 구조라면 간략하게 언급하거나 생략할 수 있습니다.
 
전체 구조를 시각적으로 보여주기 위해 **ERD**를 활용하면 서비스 구조와 기능 파악에 도움이 됩니다.
 
 
[![프로그래머스_현장픽_이미지 (4).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/49a0833f-da13-42b0-9338-e0f3310f0849/%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%84%80%E1%85%B3%E1%84%85%E1%85%A2%E1%84%86%E1%85%A5%E1%84%89%E1%85%B3_%E1%84%92%E1%85%A7%E1%86%AB%E1%84%8C%E1%85%A1%E1%86%BC%E1%84%91%E1%85%B5%E1%86%A8_%E1%84%8B%E1%85%B5%E1%84%86%E1%85%B5%E1%84%8C%E1%85%B5%20%284%29.png)](https://gilbut.co/c/26035892gX)
(이미지: EDR의 예)
 
 
포트폴리오에 ERD를 첨부할 때는 흐릿하지 않고 큼직하게 구성하고, 핵심 테이블 위주로 설명을 덧붙입니다.
예를 들어 ‘사용자(User) 1명은 여러 개의 게시글(Post)을 작성할 수 있음(1:N 관계)’처럼 관계 중심으로 설명하면 설계 의도가 분명히 드러납니다.
 
중간에 데이터베이스 구조 변경이 있다면, 변경 이유와 고려 사항을 포함해 문제 해결 과정과 판단 기준을 보여줄 수 있습니다. 
인덱스를 설정하거나 서브쿼리를 JOIN으로 바꾸는 식으로 성능을 개선한 경험이 있다면 반드시 강조하세요.
 
 
## 4. 주요 기술 키워드와 기술 상세 설명
### 기술 상세 항목
기술 상세 항목은 면접관이 문서를 계속 읽을지 판단하는 지점이므로 가독성에 신경 써서 다듬어야 합니다.
 
기술 설명은 '어떻게 만들었는지'를 나열하는 **과정 중심 설명**보다, '무엇을 만들었고, 왜 만들었으며, 어떤 효과가 있었는지'를 제시하는 **목적 중심 설명**이 효과적입니다.
 
 
**📌 과정 중심 설명**
* **특징**: 코드를 어떻게 구현했는지에 초점. **읽는 사람이 큰 그림과 목적 파악 어려움**
* **예시**: 게시글과 작성자 정보를 담기 위해 DTO에 제목, 내용, 작성자 닉네임 필드를 만들었습니다. 게시글 목록을 반복문으로 돌면서 각각의 글에 해당하는 작성자 정보를 조회해 DTO 리스트에 담았습니다.

 
**📌 목적 중심 설명**
* **특징**: 무엇을 했는지, 왜 그렇게 했는지, 어떤 결과가 나왔는지에 초점. **이해하기 쉬움**
* **예시**: 글 목록 화면에 제목과 작성자 이름을 함께 보여주기 위해 글 정보와 작성자 정보를 합친 형태의 데이터를 만들었습니다. 그리고 이 데이터를 화면에 목록으로 나타냈습니다.

 
목적 중심 설명은 기술이 사용된 상황과 이유가 바로 보여 이해하기 쉽습니다. 
핵심 봉우리만 집어 강조하듯, 왜 그 기술을 선택했고 어떤 결과가 나왔는지 분명히 설명하여 '직접 구현한 사람'이라는 신뢰를 주고 기술적 판단과 고민의 깊이를 보여줄 수 있습니다.
 
 
### 기술 설명 방식
기술 설명 방식은 **요약형**과 **서술형**으로 나눌 수 있습니다.
 
**요약형**은 기능별로 사용 기술의 핵심만 항목화하는 방식으로, 기술이 많거나 짧은 문서를 만들 때 적합합니다. 
'기술 목록 + 사용 이유 + 전체 흐름'을 간결하게 보여주되, 짧은 문장에서도 '왜 사용했는지', '무엇이 좋아졌는지'가 드러나야 합니다.
 
예를 들어 안드로이드 프로젝트는 다음과 같이 작성할 수 있습니다.
 
<div style="border-radius: 4px;padding:22px 20px; background: #F5F5F5; display: flex;">[게시글 목록/상세 조회(안드로이드 앱 개발)] 
• 서버 REST API 호출을 위해 Retrofit 사용 
• JSON 응답을 리스트로 보여주기 위해 RecyclerView 구성 
• 목록에서 상세로 자연스럽게 이동하도록 Intent 기반 화면 전환 처리
</div>

 
**서술형**은 기술을 더 깊이 설명하고 싶을 때 적합하며, 기술 이해도를 상세히 보여줄 수 있습니다.
다만 '어떻게 구현했는지'에만 매달려 가독성이 떨어지지 않도록 목적 중심 설명을 의식적으로 해야 합니다.
 
주요 기술 키워드는 굵게 표시하거나 밑줄로 강조하여 질문을 유도하는 데 활용할 수 있습니다.
내용이 길다면 기본 설명은 생략하고 인증 처리, 성능 개선, 예외 처리, 라이브러리 선택 이유 등 기술적 고민이 드러나는 핵심 기능 위주로 정리하는 것이 실력 판단에 필요한 정보를 전달하는 현명한 선택입니다.
 
 
## 5. 트러블슈팅 (문제 상황과 해결 과정)
트러블슈팅 항목은 문제 해결 능력과 논리적 사고 과정을 보여줍니다. 
실무에서 예상치 못한 오류나 장애는 흔하며, 원인 파악과 해결 과정이 매우 중요합니다. 실무 경험이 풍부한 면접관은 문제를 끝까지 해결해 본 지원자에게 주목합니다.
 
오타 수정, 파라미터 누락, API 주소 오류 등 원인이 명확한 가벼운 실수는 트러블슈팅으로 부적절하며, 오히려 기초 부족이나 꼼꼼하지 못하다는 인상을 줄 수 있으므로 신중하게 사례를 골라야 합니다. 만약 단순한 문제만 있었다면 성능 최적화, 보안 강화, 동시성 처리 등 도전적인 기능을 구현해 보는 것이 좋습니다.
 
**적합한 트러블슈팅 사례**는 문제 원인을 단계적으로 좁혀가며 해결한 과정이 드러나는 경우입니다. 특정 조건하의 예외적 오류, 예상치 못한 충돌, 환경에 따라 달라지는 문제 등이 해당됩니다. 여러 해결 방법 중 장단점을 비교하고 선택한 기준을 설명할 수 있는 사례도 좋습니다.
 
사례를 정했다면 문제 해결 과정을 **육하원칙**에 따라 논리적으로 정리합니다.
 

| 구분 | 내용 |
| --- | --- |
| **What** | 무엇이 문제였는가? |
| **Where** | 어디서 발생했는가? |
| **Why** | 왜 그런 문제가 발생했는가? |
| **How** | 어떤 해결 방법들이 있고, 그중 무엇을 선택했는가? |
| **Result** | 그렇게 해결한 이유는 무엇이며, 결과는 어땠는가? |

 
중요한 점은 문제를 인식하고 판단을 거쳐 해결한 과정을 논리적으로 보여주는 것입니다. 
주요 프로젝트당 2~3개 사례가 충분하며, 얕은 사례를 여러 개 나열하기보다 **의사결정과 해결 과정을 깊이 있게 다룬 1~2개 사례가 훨씬 효과적**입니다.
 
> 💡 **Tip** 프로젝트 진행 중 겪은 고충과 문제 해결 과정은 **그때그때 메모해 두는 습관**을 들이세요. 간단한 기록은 나중에 포트폴리오 작성 시 도움이 되며, 블로그나 깃허브의 Issues 탭에 남기면 고민의 흔적을 증명할 수 있습니다.

 
 
## 6. 성능 개선 경험
필수 항목은 아니지만 포트폴리오 경쟁력을 높이는 중요한 요소입니다. 
특히 대기업이나 기술 조직 규모가 큰 회사에서는 구조적인 개선 경험을 긍정적으로 평가합니다.
 
트러블슈팅이 발생한 문제 해결이라면, 성능 개선은 문제 발생 전에 성능 저하 가능성을 인식하고 더 나은 방향으로 바로잡는 과정입니다. 
 
개선 효과를 이전과 비교하여 **수치로 제시**하면 설득력이 높아집니다.
**앱 개발**의 경우 플랫폼에서 제공하는 모니터링 도구를 이용해 메모리 사용량, 렌더링 시간, 프레임 드롭 등의 지표를 측정할 수 있습니다. 안드로이드는 프로파일러(Profiler)나 로그캣(Logcat)을, iOS는 인스트루먼츠(Instruments)를 활용하면 됩니다. 
**백엔드**는 API 응답 속도, 쿼리 실행 시간, 메모리 사용량 등을 직접 측정하고 개선해 나가는 방식으로 성능 최적화를 진행합니다.
 
작은 것이라도 스스로 개선 사항을 찾아 시도하고 그 결과를 수치로 정리하면 개발 역량과 기술적 깊이를 보여주는 설득력 있는 포트폴리오 자료가 됩니다.
 
 
## 7. 느낀 점과 회고
이 항목은 필수적이지 않으나 프로젝트에 임하는 자세와 성장 가능성을 보여줍니다. 가벼운 소감보다는 프로젝트를 통해 **무엇을 배웠고, 그 경험이 실무에 어떻게 연결될 수 있는지**를 중심으로 정리해야 합니다.
 
기술적 성장뿐 아니라 협업 과정에서 느낀 점, 문제 인식의 변화, 앞으로 공부하고 싶은 분야 등을 구체적으로 언급합니다.
 
"이번 프로젝트를 통해 사용자 경험뿐만 아니라 성능도 고려해야 한다는 관점을 갖게 되었다"처럼 **깨달음을 실무와 연결하여 표현**하면 진정성과 잠재력을 전달할 수 있습니다.
 
 
## 마무리하며
정리하자면, 포트폴리오에 포함하면 좋은 항목은 다음과 같습니다.
 
1. 프로젝트의 개요와 사용한 기술 스택
2. 자신이 맡은 역할과 구현한 기능
3. 데이터베이스 설계
4. 주요 기술 키워드와 기술 상세 설명
5. 트러블슈팅(문제 상황과 해결 과정)
6. 성능 개선 경험
7. 느낀 점과 회고

 
AI 시대, 업무 적응에 걸리는 시간을 줄이고
바로 투입 가능한 인재로 거듭납시다!
 
 
✅ 이 내용은 『**현장에서 픽하는 IT 서비스 개발을 위한 실무 지식**』에서 발췌했습니다. 더 꼼꼼하고 자세한 내용은 도서에서 만나보세요!
 
[![프로그래머스_현장픽_이미지 (2).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/49721014-4cfb-471c-a1c9-fffa15f38c0e/%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%84%80%E1%85%B3%E1%84%85%E1%85%A2%E1%84%86%E1%85%A5%E1%84%89%E1%85%B3_%E1%84%92%E1%85%A7%E1%86%AB%E1%84%8C%E1%85%A1%E1%86%BC%E1%84%91%E1%85%B5%E1%86%A8_%E1%84%8B%E1%85%B5%E1%84%86%E1%85%B5%E1%84%8C%E1%85%B5%20%282%29.png)](https://gilbut.co/c/26035892gX)

 
 
[![프로그래머스_현장픽_이미지 (3).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/7e3fa7d6-1702-49d3-94d3-d2f7cefbcc0b/%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%84%80%E1%85%B3%E1%84%85%E1%85%A2%E1%84%86%E1%85%A5%E1%84%89%E1%85%B3_%E1%84%92%E1%85%A7%E1%86%AB%E1%84%8C%E1%85%A1%E1%86%BC%E1%84%91%E1%85%B5%E1%86%A8_%E1%84%8B%E1%85%B5%E1%84%86%E1%85%B5%E1%84%8C%E1%85%B5%20%283%29.png)](https://gilbut.co/c/26035892gX)

합격률 높이는 개발자 포트폴리오 핵심 구성 7가지

Google Agents 백서로 바라본 AI 업무구조 설계와 개발자의 성장 방향

AI 시대가 본격적으로 시작되면서 많은 개발자들이 같은 질문을 하고 있습니다.
"AI가 개발자를 대체하게 될까?"
 
하지만 실제 채용 시장에서 나타나는 신호는 조금 다릅니다. 최근 옥스퍼드 연구에 따르면 이력서에 AI 기술 경험이 있는 지원자가 인터뷰 단계까지 갈 확률이 더 높게 나타났습니다. AI가 개발자를 밀어내고 있다기보다, AI를 다룰 수 있는 개발자를 더 찾고 있다는 의미에 가깝습니다.
 
그렇다면 AI 시대에 가장 유리한 개발자는 누구일까요? 그리고 왜 백엔드 개발자가 AI 시대의 핵심 역할이 될 수 있을까요? 데이터 전문가 정경문 님의 아티클을 통해 그 이유를 살펴보세요!
 
 
## 당신이 채용 담당자라면, 누구를 뽑으시겠습니까?
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/3c08ec63-ae2d-4431-be09-ecc7b5803cf6/image.png)
 
### 32세 컴공 백엔드 5년 vs. 32세 컴공 백엔드 5년 + AI Skill
옥스퍼드 대학교에서 최근 흥미로운 연구 결과가 발표되었습니다. 실제 기업의 채용 담당자들에게 이력서 두 장을 보여주며 질문했습니다. "두 사람 중, 누구를 면접에 부르겠습니까?" 두 지원자는 나이도 같고, 학력도 같고, 경력도 같습니다. 심지어 기술 스택도 거의 동일합니다. 단 하나만 다릅니다. 한 사람은 이력서에 AI 기술 역량을 적었고, 다른 한 사람은 그렇지 않았습니다. 여러분이라면 누구를 뽑으시겠습니까?
 
지원자 A는 백엔드 개발 경력 5년입니다. API 설계 경험이 있고, AWS와 Docker를 사용해 서비스를 운영해 본 경험이 있습니다. 분산 시스템도 다뤄봤고, Kubernetes를 프로젝트에 적용해 본 경험도 있습니다.
 
지원자 B도 마찬가지입니다. 경력도 같고, 기술 스택도 같습니다. 그런데 이력서의 마지막 줄에 한 문장이 더 있습니다.
 
> **"LLM API 기반, AI 서비스 개발 경험"**

 
이 한 줄이 실제 채용 결정에 영향을 줄까요? 아니면 별 차이가 없을까요?
 
많은 분들이 이렇게 생각하실지도 모릅니다. "실제 능력이 중요하지, 이력서에 AI 기술을 적어 놓았다고 뭐가 달라지겠어?" 그런데 바로 이 질문을 실험으로 검증한 연구가 있습니다.
 
옥스퍼드 대학교 인터넷 연구소(Oxford Internet Institute)에서 미국, 영국, 독일의 채용 담당자 1,725명을 대상으로 이 실험을 진행했습니다. 연구 제목이 상당히 직설적이라 눈길을 끄는데요.
 
[**"AI Skills Improve Job Prospects: Causal Evidence from a Hiring Experiment."**](https://arxiv.org/pdf/2601.13286)
직역하면 "AI 기술을 채용 가능성을 높인다: 채용 실험을 통한 인과적 증거"입니다.
 
연구자들은 실제 채용 상황과 최대한 유사하게 가상의 이력서를 만들었습니다. 그리고 채용 담당자들에게 두 개의 이력서를 보여준 뒤, 누구를 인터뷰할지 선택하게 했습니다. 여기서 중요한 점은 연구 설계에서 단 하나의 변수만 바꾸었다는 것입니다. 바로 **AI 기술 보유 여부**였습니다.
 
 
### 변화하는 기술 환경에 적응할 수 있는 사람
결과는 어땠을까요? **이력서에 AI 기술이 명시된 지원자는 인터뷰에 초청될 확률이 평균 8~15% 증가**했습니다. 이 결과는 단순한 상관관계가 아니라, 실험을 통해 확인된 인과적 효과라는 점에서 의미가 큽니다. 즉, 원인(AI 기술 보유) → 결과(인터뷰 초청 가능성 증가)라는 관계가 실제로 관찰된 것입니다.
 
다시 말해, **AI 기술을 가진 지원자가 실제 채용 과정에서 더 유리하게 평가될 가능성이 높다**는 뜻입니다.
 
연구자들은 여기서 한 가지 흥미로운 해석을 제시했는데요. AI 기술은 단순한 기술이 아니라 노동 시장에서 강력한 "**신호(Signal)**"라는 것입니다. 채용 담당자에게 AI 기술은 이런 메시지를 전달합니다. "**이 사람은 새로운 기술을 빠르게 학습할 수 있는 사람이다**"라고 말이죠.
 
 
### AI 기술은 이력서의 약점을 보완하는 버프(Buff)
연구 결과 중 또 하나 흥미로운 부분이 있습니다. AI 기술은 단순히 가산점이 아니라 약점을 보완하는 역할도 했습니다.
 
예를 들어 나이가 조금 많은 지원자나 학력이 낮은 지원자도 AI 기술이 있으면 인터뷰 확률이 상승했습니다. AI 기술이 일종의 역량 버프(Buff)로 작동한다는 것입니다.
 
특히 사무직 직무에서는 AI 기술 보유 효과가 매우 크게 나타났는데요. 문서 작성, 보고서 생성, 데이터 분석 같은 업무는 AI 자동화와 아주 잘 맞기 때문입니다. 반면 그래픽 디자이너 직무에서는 효과가 상대적으로 작았습니다. 디자인과 같은 창의적인 직무에서는 여전히 AI에 대한 신뢰가 완전히 형성되지 않았기 때문이라고 볼 수 있죠.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/b297c1ac-2110-4afe-9ddf-8d4558e9a3ff/image.png)
*출처: [AI Skills Improve Job Prospects: Causal Evidence from a Hiring Experiment. Figure 4](https://arxiv.org/pdf/2601.13286)*
 
 
### AI 기술이 중요할까, AI 학위가 중요할까?
그럼 AI 기술을 보여주기 위해서는 학위를 따야 할까요? 아니면 기술 자체를 어필해야 할까요? 같은 Oxford Internet Institute에서 진행한 AI 노동시장 연구, [Skills or Degree? The Rise of Skill-Based Hiring for AI and Green Jobs](https://arxiv.org/pdf/2312.11942)를 보면 답이 나옵니다. 이 연구는 최근 AI 채용 시장에서 무엇이 더 중요한 기준이 되고 있는지를 분석했습니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/db168288-7d73-4dea-a7e0-c030e6f8841d/image.png)
*출처: [Skills or Degree? The Rise of Skill-Based Hiring for AI and Green Jobs. Figure 3.](https://arxiv.org/pdf/2312.11942)*
 
2018년부터 2023년까지 미국과 유럽의 채용공고 5,400만 건을 분석한 결과, **AI 기술을 보유한 인력은 평균적으로 약 23%의 임금 프리미엄을 받는 반면, 대학 학위가 만들어내는 추가 임금 효과는 점점 줄어들고 있었습니다**.
 
더 흥미로운 것은 두 변수 사이의 관계였습니다. 실제로 위 그래프를 보시면, AI 기술에 대한 수요가 높아질수록 기술의 임금 프리미엄은 더 커졌지만(C1), 반대로 AI 학위가 만들어내는 프리미엄은 감소하는 경향이 나타났습니다(C3).
 
즉 기업이 인재를 평가할 때 **"어느 대학을 나왔는가"보다 "무엇을 할 수 있는가"를 더 중요하게 보기 시작했다**는 의미입니다. 결국 노동시장은 점점 학위 기반 채용(Degree-based hiring)에서 기술 기반 채용(Skill-based hiring)으로 이동하고 있는 셈입니다.
 
 
## AI 시대에 가장 유리한 개발자는 누구일까?
그렇다면 여기서 한 가지 질문이 생깁니다. AI 시대에 가장 유리한 개발자는 누구일까요? 많은 사람들은 AI 연구자나 머신러닝 전문가를 떠올립니다. 하지만 실제 산업 현장에서는 조금 다른 흐름이 나타나고 있습니다. AI 모델을 만드는 사람보다 "**AI 서비스를 만드는 사람**"이 더 많이 필요합니다. 다시 말해 **AI Application Engineer**입니다.
 
이 직무는 AI 기술과 소프트웨어 엔지니어링을 동시에 이해하는 역할입니다. 그리고 흥미롭게도, **이 역할에 가장 가까운 사람이 바로 백엔드 개발자**입니다.
 
 
### 사용자와 데이터를 이어주는 AI 어플리케이션 엔지니어
왜냐하면 AI 서비스의 구조는 생각보다 단순하기 때문입니다. **사용자 ↔ API 서버 ↔ AI 모델 ↔ 데이터, 이 구조에서 대부분의 영역은 백엔드 엔지니어링**입니다. 인증, 권한 관리, API 설계, 데이터베이스, 클라우드 인프라, 확장성 설계 같은 것들은 모두 백엔드 개발자의 전문 영역입니다. AI 모델은 그 위에 올라가는 하나의 컴포넌트일 뿐입니다. 그래서 저는 종종 이렇게 말씀드립니다. AI 시대에 가장 유리한 개발자는 AI 연구자가 아니라 백엔드 개발자라고 말이죠.
 
개발자의 역량을 조금 더 구조적으로 바라보면, 하나의 연속선 위에 서로 다른 기술 성격이 높여 있다는 것을 알 수 있습니다. 가로축은 백엔드 중심 역량에서 AI 중심 역량으로 이동하는 축입니다. 즉 왼쪽으로 갈수록 전통적인 백엔드 엔지니어링 성격이 강하고, 오른쪽으로 갈수록 AI 모델과 AI 서비스 역량이 강해집니다. 아래쪽은 플랫폼, 운영, 파이프라인, 서빙과 같은 기반 기술이 중심이고, 위쪽은 서비스와 모델의 설계 같은 응용 기술이 중심이 됩니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/8aba5442-9ad3-4032-96c3-eb85a49e796f/image.png)
⬆️ 백엔드 중심 개발 역량과 AI 중심 개발 역량 4분면 매트릭스
 
이 두 축을 기준으로 기술들을 4분면에 배치하면 개발자의 역량 지형을 보다 입체적으로 이해할 수 있습니다.
 
먼저 백엔드 엔지니어의 핵심 역량을 정리해 보면 API 설계, 서비스 아키텍처 설계, 데이터베이스 모델링, 인증 시스템, 권한 관리, 클라우드 인프라, Docker, Kubernetes, 마이크로서비스 아키텍처, 메시지 큐, 캐싱 전략, 분산 시스템 설계, 성능 최적화, CI/CD 파이프라인, 보안 설계, 시스템 확장성 설계 등이 대표적인 항목으로 묶입니다.
*(참조: IEEE SWEBOK, 소프트웨어 엔지니어링 지식 체계)*
 
다음으로 AI 엔지니어링 역량을 보면 프롬프트 엔지니어링, RAG 설계, 벡터 데이터베이스, 임베딩 모델 이해, AI 아키텍처 설계, AI 에이전트 설계, 모델 구조 이해, 모델 평가, Fine Tuning, AI 서비스 UX 설계, 데이터 수집 파이프라인, 데이터 정제 및 전처리, AI 학습 파이프라인, 모델 서빙 인프라, 실시간 추론 시스템, MLOps 플랫폼, AI 시스템 모니터링 등이 중요한 축을 이룹니다.
*(참조 : AI workforce 연구, AI engineering competency)*
 
이 기술들을 4분면 매트릭스에 배치하면 네 개의 영역이 만들어집니다.
 
첫 번째는 **백엔드 서비스 설계 영역**입니다. API 설계, 서비스 아키텍처, 마이크로서비스 구조, 인증과 권한 관리처럼 서비스 구조와 인터페이스를 설계하는 기술이 여기에 포함됩니다.
 
두 번째는 **AI 모델·서비스 설계 영역**입니다. 프롬프트 엔지니어링, AI 에이전트 설계, RAG 구조, 모델 평가와 Fine-Tuning, AI UX 설계 등이 여기에 속합니다. 즉 AI 모델을 실제 서비스 구조 안에 설계하는 역량입니다.
 
세 번째는 **백엔드 인프라 운영 영역**입니다. 데이터베이스 모델링, 캐시 전략, 메시지 큐, 클라우드 인프라, Kubernetes, CI/CD 같은 기술이 포함됩니다. 서비스가 안정적으로 동작하도록 확장성과 운영 자동화를 책임지는 영역입니다.
 
네 번째는 **AI 시스템·인프라 구현 영역**입니다. 벡터 데이터베이스, 임베딩 모델, 데이터 파이프라인, 모델 서빙, 실시간 추론, MLOps 같은 기술이 여기에 포함됩니다. 쉽게 말해 AI를 실제 운영 가능한 시스템으로 만드는 플랫폼 엔지니어링 영역입니다.
 
 
### 백엔드 개발자는 AI 시대에 사라지지 않는다 오히려 AI 시스템을 구현하는 가장 중요한 역할을 맡는다
이 4분면에서 전통적인 백엔드 개발자는 어디에 위치할까요? 대부분 백엔드 인프라 운영 영역에 있습니다. 그리고 앞으로 이동하게 될 방향은 매우 명확합니다. 바로 **AI 시스템과 인프라 구현 → AI 모델과 서비스 설계로의 확장**입니다. 즉, 기존 백엔드 역량 위에 AI 기술을 얹는 방향으로 발전하게 됩니다.
 
LangChain과 LangGraph를 바탕으로 Agent를 설계하고, Embedding Model과 Vector DB를 바탕으로 RAG(검색증강생성) 시스템을 구축합니다. LLM을 직접 만들기보다는 기존의 OpenAI, Gemini, Claude 등 LLM API를 연결하고, 대화형으로 사용자의 UI/UX를 설계하는 능력이 여기에 포함됩니다.
 
이것은 완전히 새로운 작업이 아니라, 오히려 **기존 백엔드 개발자의 자연스러운 확장 영역**에 가깝습니다. API 서버를 만들던 사람이 이제 AI API를 붙이고, 데이터베이스를 설계하던 사람이 이제 벡터 데이터베이스를 다루는 것입니다. 기술이 완전히 바뀌는 것이 아니라, 시스템의 구성 요소가 하나 더 추가되는 것이죠.
 
다시 처음 이야기로 돌아가 보겠습니다. 옥스퍼드 연구에서 왜 AI 기술이 있는 지원자가 더 높은 인터뷰 확률을 보였을까요? 단순히 기술 하나를 더 알고 있어서가 아닙니다. 채용 담당자는 그 한 줄의 문장에서 더 많은 것을 읽어냅니다.
 
* 이 사람은 새로운 기술을 받아들이는 사람이다.
* 이 사람은 변화하는 환경에서도 스스로 학습하는 사람이다.
* 이 사람은 미래 기술을 두려워하지 않는 사람이다.
 

새로운 기술이 등장했을 때 그것을 외면하고 도태되는 사람과, 호기심을 가지고 배우는 사람이 있습니다. 과거에도, 지금도, 그리고 앞으로도 기술과 사회는 후자에게 더 유리하게 작동할 것입니다.
 
AI 시대에 가장 유리한 개발자는 어쩌면 AI 전문가도 아니고, 머신러닝 연구자도 아닙니다. 단지 기존의 기술 위에 새로운 기술을 하나 더 얹어, 변화의 흐름에 올라 탈 수 있는 사람입니다. 그리고 바로 그 사람이, AI 기술을 가진 백엔드 개발자입니다.
 
 
### 참고자료
- Oxford Internet Institute, [AI Skills Improve Job Prospects: Causal Evidence from a Hiring Experiment](https://arxiv.org/pdf/2601.13286)
- AI Workforce and Skills Research [Skills or Degree? The Rise of Skill-Based Hiring for AI and Green Jobs](https://arxiv.org/pdf/2312.11942.pdf)
- IEEE, SWEBOK: Software Engineering Body of Knowledge

 
 
### 📌 함께 읽으면 좋은 글
* [AI 개발자의 역량: 위대한 개인의 탄생](https://community.programmers.co.kr/post/13369?utm_source=&utm_medium=&utm_campaign=&utm_content=data_13369)
* [프로그래머의 성장관점에서 바라본 CES 2026](https://community.programmers.co.kr/post/13168?utm_source=&utm_medium=&utm_campaign=&utm_content=data_13168)
* [온톨로지와 Agentic AI 진화](https://community.programmers.co.kr/post/13006?utm_source=&utm_medium=&utm_campaign=&utm_content=data_13006)


 
 

![정경문 작가님 프로필 카드.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/5e64c3af-26b1-4b64-9a3f-b5ec14236695/%E1%84%8C%E1%85%A5%E1%86%BC%E1%84%80%E1%85%A7%E1%86%BC%E1%84%86%E1%85%AE%E1%86%AB%20%E1%84%8C%E1%85%A1%E1%86%A8%E1%84%80%E1%85%A1%E1%84%82%E1%85%B5%E1%86%B7%20%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%84%91%E1%85%B5%E1%86%AF%20%E1%84%8F%E1%85%A1%E1%84%83%E1%85%B3.png)

AI 기술을 가진 개발자, 실제 채용에서 유리할까?

지난 7월 데브코스에서 진행한 '**나의 개발자 유형 찾기**' 여름방학 이벤트, 기억 나시나요?
"나는 어떤 개발자일까?" "그리고 나와 어울리는 개발자 유형은 무엇일까?"를 알아볼 수 있었던 이벤트였는데요!
무려 1,000명이 넘는 분들께서 참여해주셨답니다. 🙌
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/d85dff82-fb87-4e0a-a4e4-aad10e336f96/image.png)
 
개발자 유형은 **불굴의 개척자, 논리정연한 설계자, 소통의 달인, 만능 해결사** 총 4가지로 분류되었는데요!
어떤 유형의 개발자가 가장 많았을까요? (두구두구 🥁)
 
 
## 📋 개발자 유형 검사 결과, 가장 많은 유형은 바로 이것!
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/29c92a58-3b1e-43b2-b17f-d5ddf33a7e00/image.png)
 
### **🥇 가장 많은 타입은?**
- 📐 **논리정연한 설계자가 48.7%** - 거의 절반!
- 🔧 만능 해결사 26.0%
- 🧭 불굴의 개척자 13.2%
- 💬 소통의 달인 12.1%
 

놀랍게도 논리정연한 설계자 유형이 절반 가까이 나왔습니다!
지금부터, 상황에 따른 유형별 특징을 상세히 소개해 드릴게요 🙆‍♀️
 
 
### 🧭 불굴의 개척자(13.2%) - "일단 해보자!"
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/8389c42d-7836-4f7f-a996-193972ecdb19/image.png)
* **에러 났을 때**: "어? 뭐야 이거?" → 바로 구글링이나 ChatGPT 돌려보기
* **코드 리뷰할 때**: "이 코드 다른 사람도 이해하기 쉬울까?" 하며 협업 걱정
* **새 기술 나왔을 때**: "오! 재밌어 보이네?" → 작은 프로젝트로 일단 시도!

👉 "**실패해도 괜찮아, 해보면서 배우면 되지!**" 스타일이시군요!
 
 
📌 **불굴의 개척자 최고의 짝꿍은?** 논리정연한 설계자, 소통의 달인

![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/416e82ec-884b-4c15-9ecb-167682cc8960/image.png)
 
역시, 완성도 있는 프로젝트를 만들기 위해서는 도전정신과 더불어 튼튼한 설계, 따뜻한 소통이 필요하죠!
 
 
### 📐 논리정연한 설계자 (48.7%) - 참여자 절반이 이 타입!
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/d498e802-dda1-43c8-95aa-a3b2e2217335/image.png)
* **에러 났을 때**: "잠깐, 로그부터 차근차근 읽어보자" 하며 원인 파악부터
* **코드 리뷰 할 때**: "이 로직 맞나? 혹시 버그 생길 가능성은?" 꼼꼼 체크
* **프로젝트 시작할 때**: "어떤 도구 쓸까? 라이브러리는 뭐가 좋을까?" 미리미리 준비

👉 "**미리미리 여러가지 안을 세워두는**" 체계적인 스타일이시군요!
 
 
📌 **논리정연한 설계자 최고의 짝꿍은?** 불굴의 개척자, 만능 해결사

![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/c20c7953-c3aa-448d-9814-490089d4989f/image.png)
 
계획은 완벽하지만 부족한 실행력을, 불굴의 개척자 & 만능 해결사 동료들의 도움으로 보완해보세요.
함께라면 계획 → 도전 → 완성까지, 매끄럽게 이어질 거예요!
 
 
### 🔧 만능 해결사 (26.0%) - 팀의 든든한 기둥!
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/c357332d-50d7-4d02-ba6e-418c742a1b1e/image.png)
* **에러 났을 때**: "흠... 이 부분이 문제네" 최소한 코드로 빠르게 원인 찾기
* **코드 리뷰 할 때**: "버그? 내가 다 잡아줄게!" 팔 걷고 나서기
* **프로젝트 시작할 때**: "아, 이거? 최신 기술로 이렇게 하면 돼" 직접 구현까지!

👉 "**문제? 해결하면 그만이지!**" 실행력이 뛰어난 타입이네요!
 
 
📌 **만능 해결사 최고의 짝꿍은?** 논리정연한 설계자, 소통의 달인

![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/c145e65d-00ec-48c4-9d39-3740fbfec879/image.png)
 

만능 해결사의 해결 능력은 최고!
논리정연한 설계자 & 소통의 달인 동료들의 안정적인 설계와 협력이 더해지면, 일사천리로 진행될 거예요!
 
 
### 💬 소통의 달인 (12.0%) - "함께하면 더 좋아!"
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/0a1ccbf2-e5c4-4eb0-97bb-032a02fa1b14/image.png)
* **에러 났을 때**: "어? 이거 누가 아는 사람 없나?" 바로 동료들에게 SOS
* **팀에서 의견 충돌 날 때**: "자자, 진정하고 서로 얘기해 봐요" 중재자 역할
* **프로젝트 시작할 때**: "이런 경험 있었는데..." 적극적으로 경험 공유

👉 "**혼자보다 같이!**" 협업의 달인이시군요!
 
 
📌 **소통의 달인 최고의 짝꿍은?** 불굴의 개척자, 만능 해결사

![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/7d633c1c-4561-4677-aa1d-0a633d0ed62b/image.png)
 


팀 프로젝트에서 소통은 필수!
불굴의 개척자의 추진력과 만능 해결사의 실행력이 더해지면 더할 나위 없는 완벽한 조합!
동료들과의 협업으로 최고의 결과물을 만들 수 있어요.
 
 
## ⁉️ 개발자 유형 테스트로 우리가 알 수 있는 재밌는 사실은?
이번 개발자 유형 검사 이벤트에서는 참여자의 절반이 📐**논리정연한 설계자**로 나타났는데요!
개발자 = 분석형으로 이해하는 분들도 있을 거예요.
 
하지만 개발 업무에선 다양성이 무엇보다 중요하다는 사실, 아시나요?
다양한 스타일이 모여야 서로를 보완하며 더 단단한 스택을 만들어갈 수 있습니다.
 
접근 방식은 달라도, 모두의 마음은 같죠.
바로 "문제를 해결하자!"는 것!
 
어떤 분은 분석으로, 어떤 분은 실험으로, 어떤 분은 소통으로, 어떤 분은 실행으로!
 
📐 분석파가 없다면? → 버그투성이 코드가 나오고,
🧭 개척자가 없다면? → 늘 같은 기술만 반복할 테고,
💬 소통파가 없다면? → 팀워크가 흔들리고,
🔧 해결사가 없다면? → 급한 문제는 그대로 남겠죠.
 
**결국 중요한 건, 함께할 때 시너지가 폭발한다는 사실!** 🚀
 
 
[![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/e5cefda9-d4f8-4861-b6fb-b55ae9c9da35/image.png)](https://school.programmers.co.kr/learn/KDT)
 
그렇다면, 이렇게 다양한 동료들은 어디서 만날 수 있을까요?
 
다양한 유형의 사람들을 검증된 사전 역량 진단으로 선발하는 곳!
**프로그래머스 데브코스**에서 동료 학습을 시작해보는 건 어때요?
 
🚨 **프론트엔드, 백엔드, 백엔드 단기심화 데브코스 모집 중**
실무에 가장 가까운 프로젝트, 최고의 동료들과 함께할 기회를 놓치지 마세요!
 
 
 

### 🔍 **데브코스 선배들의 최종 프로젝트 결과물 살펴보기**
 
<div style="position: relative; max-width: 100%; padding-bottom: 56.25%; height: 0;"><iframe width="560" height="315" src="https://www.youtube.com/embed/1rwhSifC2K0?si=gHU0y4sgCfXPKyVI" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen="" style="position: absolute; position: absolute; top: 0; left: 0; width: 100%; height: 100%;"></iframe></div>

 
 
 
### **📌 현재 모집 중인 과정, 자세히 보고 싶다면?**
 
[![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/6658d876-85f5-419f-9ce1-06e7fccff084/image.png)](https://school.programmers.co.kr/learn/courses/25442?utm_source=&utm_medium=&utm_campaign=&utm_content=KDT_devtestreview_FE)
 
[![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/14668e75-17f3-45b0-9391-5e2d6f37db24/image.png)](https://school.programmers.co.kr/learn/courses/25443?utm_source=&utm_medium=&utm_campaign=&utm_content=KDT_devtestreview_BE)
 
[![DEV-BE-DEEP--blog-banner(1456x180).jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/afb6e846-8d04-4ce7-bf4b-86a004dea35f/DEV-BE-DEEP--blog-banner%281456x180%29.jpg)](https://school.programmers.co.kr/learn/courses/25335?utm_source=&utm_medium=&utm_campaign=&utm_content=KDT_devtestreview_ADBE)

[데브코스 이벤트] 개발자 유형 테스트 결과 공개: 가장 많은 유형은 바로 이것!

안녕하세요, 프로그래머스입니다!
 
화면 속 배경만 바꿔도 하루가 달라지는 기분! ✨
9월에도 공부를 더욱 즐겁게 만들어 줄 머쓱이 디지털 굿즈가 도착했습니다!
 
온라인 미팅도 깔끔하게, 컴퓨터 배경화면도 산뜻하게!
머쓱이와 함께 9월도 알차게 채워보세요 📚
 
 
## 9월 머쓱이 캘린더
![캘린더 9월 머쓱이(Center)-01.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/f43d5bc5-97db-4acf-ae37-abfbbce2285a/%E1%84%8F%E1%85%A2%E1%86%AF%E1%84%85%E1%85%B5%E1%86%AB%E1%84%83%E1%85%A5%209%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%86%E1%85%A5%E1%84%8A%E1%85%B3%E1%86%A8%E1%84%8B%E1%85%B5%28Center%29-01.png)
 
![캘린더 9월 머쓱이(Center)-03.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/8abf0b8e-497d-45cd-bd65-0ad33e3d8410/%E1%84%8F%E1%85%A2%E1%86%AF%E1%84%85%E1%85%B5%E1%86%AB%E1%84%83%E1%85%A5%209%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%86%E1%85%A5%E1%84%8A%E1%85%B3%E1%86%A8%E1%84%8B%E1%85%B5%28Center%29-03.png)
 
![캘린더 9월 머쓱이(Center).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/e1d317f2-289f-426e-9099-3b9957a1bc6d/%E1%84%8F%E1%85%A2%E1%86%AF%E1%84%85%E1%85%B5%E1%86%AB%E1%84%83%E1%85%A5%209%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%86%E1%85%A5%E1%84%8A%E1%85%B3%E1%86%A8%E1%84%8B%E1%85%B5%28Center%29.png)
 
![캘린더 9월 머쓱이(mac)-04.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/303a485a-065e-46ab-a32f-2cdb5777f9f9/%E1%84%8F%E1%85%A2%E1%86%AF%E1%84%85%E1%85%B5%E1%86%AB%E1%84%83%E1%85%A5%209%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%86%E1%85%A5%E1%84%8A%E1%85%B3%E1%86%A8%E1%84%8B%E1%85%B5%28mac%29-04.png)
 
![캘린더 9월 머쓱이(Window)-05.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/12248755-c833-4018-b562-4f1f2945955d/%E1%84%8F%E1%85%A2%E1%86%AF%E1%84%85%E1%85%B5%E1%86%AB%E1%84%83%E1%85%A5%209%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%86%E1%85%A5%E1%84%8A%E1%85%B3%E1%86%A8%E1%84%8B%E1%85%B5%28Window%29-05.png)
 
더 많은 배경화면(Mac, Window)은 아래 링크에서 확인 가능합니다.
👉 **[머쓱이 9월 캘린더 다운받기](https://prgrms.notion.site/zip-1993e47046bf80629692c4ddef6a01bf)**
 
 
## 9월 머쓱이 줌 배경
![줌 9월 머쓱이(기본)-39.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/f548c0a6-1fe9-416f-baa5-7ab1a03aa7a0/%E1%84%8C%E1%85%AE%E1%86%B7%209%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%86%E1%85%A5%E1%84%8A%E1%85%B3%E1%86%A8%E1%84%8B%E1%85%B5%28%E1%84%80%E1%85%B5%E1%84%87%E1%85%A9%E1%86%AB%29-39.png)
 
![줌 9월 머쓱이(기본)-40.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/3a9e6db9-63b5-4b75-8cfe-570f886ae2ac/%E1%84%8C%E1%85%AE%E1%86%B7%209%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%86%E1%85%A5%E1%84%8A%E1%85%B3%E1%86%A8%E1%84%8B%E1%85%B5%28%E1%84%80%E1%85%B5%E1%84%87%E1%85%A9%E1%86%AB%29-40.png)
 
![줌 9월 머쓱이(기본)-41.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/59363763-04f1-4602-9066-54dbacd50bbd/%E1%84%8C%E1%85%AE%E1%86%B7%209%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%86%E1%85%A5%E1%84%8A%E1%85%B3%E1%86%A8%E1%84%8B%E1%85%B5%28%E1%84%80%E1%85%B5%E1%84%87%E1%85%A9%E1%86%AB%29-41.png)
 
더 많은 줌 배경화면은 아래 링크에서 확인 가능합니다.
👉 **[머쓱이 줌 배경화면 다운받기](https://prgrms.notion.site/zip-1993e47046bf80629692c4ddef6a01bf)**

머쓱이 9월 캘린더 & 줌 배경화면 무료 배포 💻

데브코스 수료 후, 트렌비로 취업에 성공한 문종운 님의 인터뷰입니다. 개발자 부트캠프를 찾을 때 가장 중요한 조건이었던 멘토링과 코드 리뷰, 이 두 가지 조건을 충족하는 데브코스를 발견해 수강하게 되었다고 하셨는데요. 문종운 님의 데브코스 수강 후기가 궁금하시다면, 아래 인터뷰를 끝까지 읽어보시기를 추천드립니다.
 
![데브코스 백엔드 후기.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/3ce54091-dde9-4030-aa11-5bda41958799/%E1%84%83%E1%85%A6%E1%84%87%E1%85%B3%E1%84%8F%E1%85%A9%E1%84%89%E1%85%B3%20%E1%84%87%E1%85%A2%E1%86%A8%E1%84%8B%E1%85%A6%E1%86%AB%E1%84%83%E1%85%B3%20%E1%84%92%E1%85%AE%E1%84%80%E1%85%B5.png)
 
# 데브코스는 어떻게 알게 되셨나요?
저는 학부에서 다양한 프로젝트를 경험하고 졸업했는데, 취업 시장에는 정말 역량이 뛰어난 주니어 개발자분들이 많았습니다. 당시 저는 사실 개발자라기보다는 문제가 생기면 구글에 검색해서 복사-붙여넣기를 하는 코더에 가까웠습니다. 이대로는 뛰어난 개발자로 성장할 수 없겠다 생각하여 독학하다가 코드 레벨에서 멘토링을 받을 수 있는 부트캠프에 참여해야겠다고 생각했어요. 검색을 통해 프로그래머스 데브코스를 발견했고, 유튜브나 커뮤니티 등에서 평이 좋은 것을 확인했습니다.

# 다양한 부트캠프 기관이 있는데, 그 중 프로그래머스를 선택하신 이유를 알고싶어요!
가장 먼저 중요하게 생각한 부분은 단순히 개발을 하는 것이 아니라, 내가 지금 사고하고 있는 것에 대해 **방향성을 잡아주시는 멘토님들과 코드 레벨에서 리뷰를 통해 피드백을 받을 수 있는 환경**이었습니다. 프로그래머스는 이러한 환경을 제공해 주는 부트캠프였습니다.

# 5개월 동안 데브코스에 참여하면서 어떤 부분이 가장 기억에 남나요?
여러 가지가 떠오르는데, 가장 좋았던 경험은 동료 성장입니다. 멘토님에게 멀티 모듈을 구축해 보라는 요구사항을 받은 적이 있는데요. 그때, 같은 팀에 있었던 도연 님과 함께 밤을 새워가며 모놀리틱 구조를 멀티 모듈 설계로 바꿔가면서 많은 이슈를 겪었고, 이를 해결해 냈을 때 짜릿함은 지금까지도 기억에 생생히 남습니다!

# 최종 프로젝트로는 무엇을 만들었나요?
일상생활에서 발생할 수 있는 문제들을 요청하고 해결해 줄 수 있는 서비스, 심부름 대행 서비스인 [원데이 히어로](https://www.youtube.com/watch?v=GVe8yh769Yg&t=13s)라는 프로젝트를 수행했습니다. 아이디어는 좋았으나 아쉬웠던 점도 있었는데요. 프로젝트를 설계하면서 너무 이상적인 아키텍처를 설계하다 보니 개발 기간에 대한 예측이 어려웠고, 여러 가지 인프라를 도입했다는 점이었습니다. 외부 기술에 의존하기보다는 코드 레벨에서 조금 더 고민을 해보았으면 어땠을까 하는 아쉬움이 남지만 팀원들과 함께 성장할 수 있었던 귀한 기회였던 것 같습니다.
 
<div style="position: relative; max-width: 100%; padding-bottom: 56.25%; height: 0;"><iframe width="560" height="315" src="https://www.youtube.com/embed/GVe8yh769Yg?si=fitJWhnb-zwWeZHI" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen style="position: absolute; position: absolute; top: 0; left: 0; width: 100%; height: 100%;"></iframe></div>

# 데브코스에 참여하며 성장을 느낀 순간은?
데브코스에서의 미션 중 실제 서비스를 클론 해보는 과제가 있었고, 저희 팀은 캐치 테이블을 클론 코딩했는데요. 그 과정에서 예약과 대기열에 기능을 구현할 때 예상했던 것보다 더 많은 문제들을 마주했습니다. 동시성을 고려해야 했고, 자주 조회를 해야 해 캐시도 신경 써야 했습니다. 또한 점주용, 고객용 애플리케이션을 분리하면서 멀티 모듈을 구성한 것도 이 미션을 통해 처음 경험했는데요. 이때 미션을 수행하며 많이 성장했음을 느꼈던 것 같습니다.

# 데브코스를 통해 이루고자 했던 목표는 무엇이었나요?
처음 데브코스에 참여했을 때 목표는 코더가 아닌 개발자로 성장하는 것이었습니다. 1년이 지난 지금, 아직 많이 부족하지만 그래도 이제는 코더가 아닌 한 명의 주니어 개발자가 되었다는 생각이 듭니다.
 
![김종운님(백엔드 후기).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/d44b9cdd-348f-4436-83d7-5c16e527729c/%E1%84%80%E1%85%B5%E1%86%B7%E1%84%8C%E1%85%A9%E1%86%BC%E1%84%8B%E1%85%AE%E1%86%AB%E1%84%82%E1%85%B5%E1%86%B7%28%E1%84%87%E1%85%A2%E1%86%A8%E1%84%8B%E1%85%A6%E1%86%AB%E1%84%83%E1%85%B3%20%E1%84%92%E1%85%AE%E1%84%80%E1%85%B5%29.png)

# 기억에 남는 강사님이 있다면?
스프링 시큐리티 강의를 해주셨던 잭슨님이 가장 기억에 남습니다. 스프링 시큐리티라는 추상화가 많이 되어 있는 어떠한 라이브러리 디버깅을 통해서 분해해 가는 모습을 보고 "와! 디버깅은 저렇게 하는 거구나. 결국 모든 건 코드이니 천천히 따라가다 보면 이해할 수 있겠구나."라는 생각을 하게 되었습니다.

# 운영 매니저와 함께 한 5개월은 어땠나요?
저에게 있어 은사와 같다고 말할 수 있습니다. 개발자로서의 덕목이나 방향성을 제시해 주셨을 뿐만 아니라 일과 인생을 대하는 자세, 그리고 사람 간의 의사소통에 대해서도 많은 가르침을 주셨습니다.

# 함께한 동료들은 어땠나요? 수료 후에도 소통하고 있나요?
함께했던 동료들과는 수료 후에도 꾸준히 소통을 이어나가고 있습니다. 개발을 하다가 궁금한 것이 있으면 물어보기도 하고, 함께 스터디를 진행하기도 합니다. 때로는 만나서 같이 밥도 먹고 근황을 나누며 스트레스를 해소하기도 합니다.
 
![스크린샷 2024-10-22 오후 1.55.44.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/49a7c97d-fe1d-4328-9021-313a5b2ebbb0/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202024-10-22%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%201.55.44.png)

# 기억에 남는 멘토링 시간이 있다면?
개발할 때 저는 고민을 많이 하는 편인데요. 고민하는 과정에서 다양한 해결 방안이 나오게 되고, 그렇게 나온 결과가 가장 최적의 방안이라 생각해왔습니다. 하지만 멘토님께서는 오랜 기간 고민해서 나온 결과가 최적의 방안인지 주니어 입장에서 정확히 모를 수도 있고, 그 방안이 도출된 이유에 대해서도 정확히 얘기하지 않으면 모른다는 XY 문제에 대해 말씀해 주셨어요. 

그 후 개발 과정에서 발생한 문제와 이를 어떻게 해결하고 있는지에 대해 자세하게 멘토링을 통해 공유했고, 멘토님께 더 좋은 피드백을 받을 수 있게 되었습니다. 또 저는 개발을 하면서 멘토님께 질문을 하루에 2개 이상씩 굉장히 많이 했었는데요. 이러한 부분에 멘토님과 서브 멘토님께서 빠르게 답변해 주셔서 학습에 굉장한 도움이 되었던 것 같아요.

# 취업에 성공하셨다고 들었습니다! 취업을 위해 특별히 신경쓴 부분이 있나요?
저는 데브코스 수료 후 트렌비라는 회사에 입사를 하게 되었습니다. 취업을 하면서 가장 중요하게 신경 썼던 부분은 이력서와 코딩테스트입니다. 이력서는 저라는 사람을 가장 잘 어필할 수 있는 수단이기도 하고, 면접 시 이력서를 바탕으로 면접관과 이야기를 나누기 때문에 이력서 작성을 중요하게 생각했습니다. 

코딩테스트는 알고리즘 부분도 있었고, SQL 문제도 같이 풀었는데요. 코딩테스트의 경우 데브코스에 참여하기 전부터 꾸준히 준비하고 있었습니다. 이렇게 꾸준히 학습하고 준비했던 과정들이 모여 최종 입사로 연결되었던 것 같습니다.

# 취업에 성공할 수 있었던 나만의 비결!
프로젝트를 하며 고민했던 것들을 어떤 과정을 통해 해결했는지를 이력서와 면접에서 최대한 자세히 표현하려고 했습니다. 특히 이력서에는 개발을 하며 고민했던 부분들을 모아놓은 작은 목차를 따로 두었는데요. 어떤 고민을 했고, 어떻게 해결했는지 블로그 포스팅을 링크로 담아 개발자로의 저의 사고방식과 역량을 어필하려고 했습니다. 트렌비는 커뮤니케이션을 통해 코드 리뷰나 피드백, 문제 해결을 위한 토론이 활성화되어있는 조직 문화를 가지고 있는 회사인데요. 제가 경험했던 동료들과의 소통 방식과 문제 해결 방식이 회사 적응에 많은 도움이 된 것 같습니다.
 
![스크린샷 2024-10-22 오후 2.32.04.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/4c733567-383d-4e9e-8487-8b4c6b0561f3/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202024-10-22%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%202.32.04.png)

# 데브코스, 취업에 도움이 되었나요?
개인적으로 정말 많은 도움이 되었다고 생각합니다. 전 컴퓨터 공학을 전공했지만 구글에서 검색하고 진행하는 코더와 같았습니다. 저의 고민이나 생각이 담긴 코드가 아니다 보니 유지 보수에도 어려움을 겪었습니다. 하지만 데브코스를 통해 저의 사고를 코드로 옮기는 과정을 체득했고, 데브코스 수료 후에는 더 이상 코더가 아닌 한 명의 주니어 개발자로 불릴 수 있겠구나 생각했습니다.

# 데브코스 수강을 고민하는 분들께 한 마디 부탁드려요.
데브코스의 가장 큰 장점은 네트워크입니다. 개발을 하다 마주친 고민들에 대해 함께 고민하고 해결할 수 있는 동료들은 제 생각보다 더 많은 힘이 되었습니다. 동료들의 코드를 보며 제가 미처 생각하지 못했던 부분들을 발견할 수도 있고요. 백엔드 개발자로서 좋은 개발자로 성장하고자 한다면, 데브코스 백엔드 과정 추천드립니다!
 
![백엔드 후기.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/3cee1494-3358-4578-b3c2-fc40934bb825/%E1%84%87%E1%85%A2%E1%86%A8%E1%84%8B%E1%85%A6%E1%86%AB%E1%84%83%E1%85%B3%20%E1%84%92%E1%85%AE%E1%84%80%E1%85%B5.png)

# 마지막으로 후배 수강생들을 위한 응원과 조언 부탁드립니다!
6개월이라는 시간은 길다면 길고, 짧다면 정말 짧은 시간입니다. 저는 실제로 데브코스에 참여하면서 과제를 몇 번 수행하다 보면 "벌써 한 달이 지났다고?"라는 생각을 많이 했었습니다. 그렇다고 너무 무리하다 보면 쉽게 번아웃이 올 수도 있죠. 6개월이라는 기간 동안 컨디션 관리를 위해 수면 사이클을 꼭 맞추시는 것을 추천드립니다. 개발자는 단거리 달리기가 아니라 마라톤과 같이 꾸준히 공부해야 하는 직업이기에 건강 관리가 필수입니다.
 
더 자세한 인터뷰는 📌[유튜브](https://youtu.be/pIzL-YJzRTw?feature=shared)에서 확인하실 수 있습니다.
 
<div style="position: relative; max-width: 100%; padding-bottom: 56.25%; height: 0;"><iframe width="560" height="315" src="https://www.youtube.com/embed/pIzL-YJzRTw?si=SmV0X1fG8c6yup1R" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen style="position: absolute; position: absolute; top: 0; left: 0; width: 100%; height: 100%;"></iframe></div>

 
 
> **프로그래머스 백엔드 엔지니어링 데브코스** 👨‍💻
> 1,700개 기업의 채용 공고를 완벽 분석하여 취업에 필요한 핵심 기술을 엄선한 프로그래머스 백엔드 과정


[![be-coding-test2(729x90).jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/0395ba42-584f-432a-b371-9b0be199b482/be-coding-test2%28729x90%29.jpg)](https://school.programmers.co.kr/learn/courses/25244?utm_source=prgmblog&utm_medium=social&utm_campaign=school_25244_blog&utm_content=25244_banner)

[데브코스 후기] 제대로 배울 수 있는 부트캠프가 간절했어요 - 백엔드 4기 문종운 님

신입 개발자라면 누구나 한 번쯤, 질문 하나 못 하고 몇 시간을 흘려보낸 경험이 있을 것입니다. "이런 걸 물어봐도 될까?"라는 망설임은 개발자라면 자연스럽게 겪는 성장의 과정입니다. 하지만 질문을 미루는 순간, 문제는 해결되지 않고 시간과 자신감만 줄어듭니다. 이 글에서는 개발자가 효율적으로 질문하고 도움을 받는 방법에 대해 이야기합니다.
 
 
## 질문하지 못하는 개발자
![Gemini_Generated_Image_xvs816xvs816xvs8 3 (1).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/4cbf5991-fef3-4d82-81aa-1ac789ea48f4/Gemini_Generated_Image_xvs816xvs816xvs8%203%20%281%29.png)
 
신입 개발자 K씨는 3시간째 같은 에러와 씨름 중입니다. 구글링도 해보고, 공식 문서도 뒤져봤지만 문제는 해결되지 않습니다. 옆자리 시니어 개발자라면 5분 만에 해결할 수 있을 것 같습니다. 하지만 K씨는 질문하지 못합니다.
 
"이런 걸 물어봐도 될까?", "너무 기초적인 질문 아닐까?", "바쁜데 방해하는 거 아닐까?", "실력 없어 보이면 어떡하지…"
결국 K씨는 5시간 동안 혼자 끙끙대다, 저녁 7시가 되어서야 시니어가 먼저 물어봅니다.
 
"아직도 그거 하고 있어? 뭐가 문제야?"
"아... 이거요. 계속 이 에러가 나서요."
"아, 이거? 환경 변수 설정 안 한 거네. 1분이면 되는데?"
K씨는 그렇게 하루를 날려버렸습니다.
 
많은 개발자들이 질문을 두려워합니다.
"이런 걸 물어보면 무능해 보이지 않을까?"
"다들 아는 건데 나만 모르는 건 아닐까?"
"괜히 질문했다가 눈도장 찍히면 어떡하지?"
 
하지만 시니어 개발자들의 생각은 다릅니다.
"솔직히 3시간 혼자 고민하는 것보다, 5분 만에 물어봐 주는 게 훨씬 낫죠"
"팀 전체 생산성을 생각하면 당연한 선택이에요."
 
코딩, 디버깅, 설계만큼이나 **질문하는 것 역시 개발자가 반드시 익혀야 할 기술**입니다. 오늘은 개발자가 효과적으로 도움을 받는 방법을 알아보겠습니다.
 
 
## 왜 질문하기 어려운가?
![image 51 (1).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/c5f86150-f4e6-4dd4-a1df-9b1d90da3099/image%2051%20%281%29.png)
 
### "물어봐도 된다"는 말의 이면
개발자 문화에는 역설이 있습니다. 표면적으론 "궁금한 거 있으면 언제든 물어봐"라고 하지만, 암묵적으로는 "하지만 스스로 해결할 수 있어야 해", "AI한테 물어보면 다 나오는데..."라는 압력이 존재합니다. 실제로 질문했을 때 "그것도 몰라?", "아까 설명했잖아", "공식 문서 읽어봤어?"라는 반응을 받으면, 다음부터는 질문하기가 더욱 어려워집니다.
 
제가 신입 개발자였을 때, 용기를 내어 질문을 했지만 돌아온 말은 "그 정도는 알아야지?"였습니다. 악의에서 나온 말은 아니었겠지만, 그 한마디에 저는 금세 풀이 죽고 말았습니다. 그리고 그 이후 몇 달 동안, 어떤 질문도 쉽게 꺼내지 못했습니다. 이처럼 단 한 번의 부정적인 경험은 질문을 막는 큰 장벽이 됩니다.
 
### "나만 모르는 것 같아"
"나만 모르는 것 같아"라는 생각이 들면 질문하는 것 자체가 두려워집니다. 들킬까 봐, 부족해 보일까 봐 질문을 미루게 되고, 그럴수록 모르는 것은 더 쌓여가는 악순환이 반복됩니다.
 
하지만 사실 대부분의 개발자는 비슷한 지점에서 막히고, 시니어 개발자 역시 매일 새로운 것을 배우며 일합니다. 10년 차 개발자라고 해도, 새로운 프레임워크 앞에서는 신입 개발자와 크게 다르지 않습니다.
 
### 한국 특유의 눈치보는 문화
한국의 위계 문화와 눈치보는 문화도 영향을 미칩니다.
"선배한테 이런 거 물어봐도 되나...", "팀장님 바쁘신데...", "다들 바빠 보이는데..."라는 생각에 질문을 미루다가 결국 타이밍을 놓치고 맙니다.
 
아침에는 "오전 스탠드업이 있으니까 그 후에", 점심에는 "식사 후에 물어봐야지", 오후에는 "회의 끝나고", 저녁에는 "내일 아침에..."를 반복하다 결국 질문하지 못하는 경우가 많습니다.
 
결국 질문하지 못한 채 하루를 날리고, "내가 무능해서 이렇게 시간이 오래 걸리는 거야"라며 자책하게 됩니다.
 
 
## 질문하기 전 스스로 시도할 것들
![image 52 (1).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/a1dd23b8-1aad-4207-ab15-ceed064b567f/image%2052%20%281%29.png)
 
### 30분 룰
그렇다고 무조건 빨리 질문하는 것이 답일까요? 그것도 아닙니다. 5분 고민하고 바로 질문하면 "스스로 생각을 안 하네"라는 인상을 줄 수 있고, 성장 기회도 놓치게 됩니다. 반대로 5시간 혼자 끙끙대다 질문하면, 팀 전체의 생산성이 떨어집니다.
 
저는 30분 룰을 추천합니다. **고민의 시간을 30분으로 설정**하고, 집중해서 혼자 시도해 봅니다. 30분 후 평가했을 때 조금이라도 진전이 있으면 30분 더 시도하고, 완전히 막혔거나 같은 곳을 반복하고 있다면 질문을 준비합니다. 물론 프로덕션 장애처럼 급한 상황에서는 이러한 룰을 무시하고, 즉시 질문해야 합니다.
 
### 에러 메시지 제대로 읽기
질문 전에 확인해야 할 것들이 있습니다. 먼저, 에러 메시지를 제대로 읽어야 합니다. "에러 나요"라고만 말하는 것이 아니라, **에러 메시지 전체를 읽고 에러 타입을 확인하며 스택 트레이스를 따라가 봅니다**. 예를 들어 "Cannot read property 'name' of undefined"라는 에러를 제대로 읽으면, undefined의 'name'을 읽으려 했다는 것, 즉 객체가 undefined라는 것을 알 수 있고, 이미 해결 방향이 보이기 시작합니다.
 
### 구글링과 AI 활용하기
구글링도 하나의 기술입니다. "에러 해결", "안 돼요"같은 막연한 검색어 대신, **에러 메시지 전문을 따옴표로 감싸서 그대로 검색**하거나, **"기술 스택+발생한 현상"처럼 구체적으로 검색**해보세요.
 
AI 도구도 적극적으로 활용해 보세요. **ChatGPT나 Claude 같은 AI에게 질문**하는 것도 좋은 방법입니다. 특히 에러 메시지를 그대로 붙여 넣고 "이 에러가 무슨 뜻인지, 어떻게 해결할 수 있는지 알려줘"라고 물으면 빠르게 방향을 잡을 수 있습니다.
 
AI는 24시간 언제든 사용할 수 있고, "바보 같은 질문"이라고 판단하지도 않으며, 같은 질문을 여러 번 해도 눈치 주지 않습니다. **다만 AI의 답변을 맹신하지 말고, 제안받은 해결책이 왜 작동하는지 이해하려는 노력이 필요**합니다.
 
 
## 좋은 질문의 구조
![스크린샷 2026-01-02 오후 2.48.36.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/0f5f436c-343d-4eac-a584-3b849338298c/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202026-01-02%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%202.48.36.png)
 
### 진짜 문제를 말하기
질문할 준비가 되었다면, 어떻게 질문해야 될까요? 먼저 진짜 해결하고 싶은 문제가 있는데, 그것을 해결하려다 막힌 부분만 질문하는 것은 좋지 않습니다.
 
예를 들어 "문자열에서 마지막 3글자를 어떻게 제거하나요?"라고 물으면, 답변자는 "substring을 쓰면 됩니다"라고 답하겠죠. 하지만 실제로 원하는 것이 파일 확장자 제거였다면 이야기가 달라집니다. 이 경우에는 처음부터 "파일명에서 확장자를 제거하고 싶은데, 문자열에서 마지막 3글자를 제거하면 될까요? 아니면 더 좋은 방법이 있을까요?"라고 질문하는 편이 훨씬 낫습니다. 그러면 답변자는 곧바로 "path.parse() 사용하세요"라고 정확한 해결책을 제시할 수 있습니다.
 
문제의 맥락을 충분히 공유하지 않으면, 이처럼 불필요한 질문과 답변이 오가며 서로의 시간을 낭비하게 됩니다.
 
### 나쁜 질문 vs 좋은 질문
나쁜 질문은 이렇습니다.
"React에서 API 호출이 계속되는데 어떡하죠?"
상황도 불명확하고, 시도한 것도 없고, 코드도 없어서 답변자가 모든 것을 추측해야 합니다.
 
좋은 질문은 이렇습니다.
* 제목: React useEffect에서 API 무한 호출 문제
* 상황: 사용자 목록을 불러오는 페이지를 만들고 있어요.
* 문제: API가 계속 호출되고 브라우저가 느려집니다.
* 코드:
```
javascript
useEffect(() => {
 fetch('/api/users')
 .then(res => res.json())
 .then(data => setUsers(data));
}); // 의존성 배열 없음
```
* 시도한 것
 * 구글링: "react useEffect infinite loop" 검색
 * ChatGPT에게 물어봤는데 의존성 배열을 추가하는 코드를 보여줬으나 원하는 대답이 아님

* 질문: 컴포넌트 로드 시 딱 한 번만 API를 호출하려면 어떻게 해야 되나요?

 
이런 질문은 **상황이 명확하고, 핵심 코드가 있으며, 시도한 것이 정리**되어 있어서 답변자가 빠르게 도와줄 수 있습니다.
 
### 코드 첨부의 기술
코드를 첨부할 때는 몇 가지 원칙이 있습니다. 프로젝트 전체를 덤프하지 말고, 문제가 발생하는 부분만 간결하게 추출해야 합니다. 200줄짜리 컴포넌트가 아니라 **핵심 10줄**만 보여주세요.
 
그리고 **스크린샷이 아닌 텍스트**로 올려야 답변자가 복사해서 테스트해 볼 수 있습니다. 코드 블록을 사용해서 포맷팅도 깔끔하게 해주면 더 좋습니다. 에러 메시지도 마찬가지로 스크린샷이 아닌 텍스트로 첨부해야 검색도 가능하고 답변자가 확인하기 쉽습니다.
 
 
## 누구에게, 언제, 어떻게 질문할까
### 적절한 질문 대상 찾기
질문 대상 선택도 중요합니다. 급한 버그 수정은 같은 기능을 만든 담당자에게, 기술 선택 고민은 시니어나 테크 리드에게, 개발 환경 설정은 DevOps 담당자에게 물어야 효율적입니다. 잘못된 사람에게 질문하면 "저도 잘 모르는데요, OO님한테 물어보세요"라는 답변만 듣고 시간을 낭비하게 됩니다.
 
학습 목적의 질문이라면 멘토나 친한 동료에게 물어보는 것이 좋습니다. 이들은 시간을 들여 자세히 설명해 줄 수 있고, "바보 같은 질문"이라고 생각하지 않을 것입니다.
 
### 오프라인 vs 온라인
온라인과 오프라인 중 어떤 방식을 선택할지도 상황에 따라 다릅니다. 급한 문제나 화면 공유가 필요한 경우, 코드를 같이 봐야 하는 복잡한 문제는 직접 찾아가는 게 좋습니다. 단, 상대방이 집중 중인지 확인하고 "지금 5분 괜찮으세요?"라고 먼저 물어봐야 합니다. 헤드폰을 끼고 있다면 지금은 집중 타임이니 나중에 다시 찾아가야 합니다. 개발자의 집중 상태를 깨는 것은 생각보다 큰 비용입니다.
 
급하지 않은 질문, 문서로 설명 가능한 질문, 기록이 남아야 하는 질문은 Slack이나 메신저로 보내는 게 좋습니다. 상대방이 시간 될 때 답변할 수 있고, 다른 사람도 참고할 수 있으며, 기록이 남아서 나중에 비슷한 문제가 생겼을 때 찾아볼 수 있습니다.
 
### 팀 채널 vs DM
팀 채널과 DM 중 어디에 올릴지도 판단이 필요합니다. 팀원 전체가 알면 좋은 것, 누가 답변해도 상관없는 것, 나중에 참고할 만한 것은 팀 채널에 올리고, 특정인만 답변 가능한 것, 개인적인 조언이 필요한 것은 DM으로 보냅니다. 팀 채널에 올리면 여러 사람이 답변해 줄 수 있고, 다양한 관점의 솔루션을 얻을 수도 있습니다.
 
### 질문하기 좋은 타이밍
질문 타이밍도 중요합니다. 회의 직전, 점심시간 직전, 퇴근 직전, 배포 직전이나 직후는 피해야 합니다. 배포 직전에 "이거 급한데 도와주세요"라고 하면, 답변자도 배포 준비로 바쁘고 긴장된 상태라 제대로 도와줄 수 없습니다.
 
개인적으로는 점심 식사 후 여유 시간, 오후 2-4시경이 비교적 좋은 타이밍입니다. 이 시간대는 사람들이 여유롭고 도와줄 준비가 되어 있을 가능성이 높습니다.
 
 
## 질문도 성장이다
![스크린샷 2026-01-02 오후 3.00.14.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/682077ba-653c-48f9-82f6-2a6085d2134e/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202026-01-02%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%203.00.14.png)
 
### 질문 후에도 할 일이 있다
좋은 질문을 하는 개발자는 빠르게 성장합니다. 막혔을 때 적절한 타이밍에 도움을 받아 시간을 절약하고, 질문을 정리하는 과정에서 문제를 구조화하는 능력이 생기며, 답변을 통해 새로운 관점과 해결 방법을 배웁니다. **질문 자체가 학습의 과정**입니다.
 
답변을 받았다면 "감사합니다"로 끝내지 말고, 제대로 이해했는지 확인해야 합니다. "이해했습니다"와 "해결됐습니다"는 다릅니다. 코드가 돌아간다고 해서 원리를 이해한 것은 아니니까요. 가능하다면 "아, 그러니까 의존성 배열이 비어있으면 마운트 될 때 한 번만 실행되는 거군요!"처럼 자신의 이해를 확인해 보세요.
 
문제가 해결되었다면 간단히 기록해두세요. 같은 문제로 6개월 후에 또 고민하지 않도록 **노션이나 개인 위키에 "오늘 배운 것" 페이지를 만들어 정리**합니다. "useEffect 의존성 배열 - 빈 배열이면 마운트 시 1회만 실행"처럼 짧은 메모만 남겨도 충분합니다.
 
**다른 팀원도 겪을 수 있는 문제라면 팀 위키나 슬랙 채널에 공유**하는 것도 좋습니다. 여러분의 질문과 해결 과정이 다음 동료의 시간을 절약해 줄 수 있습니다.
 
### 작은 질문부터 시작하기
처음에는 질문하기가 두렵고 어색할 수 있습니다. 하지만 연습하면 늘어나는 기술입니다. 작은 질문부터 시작해 보세요. "이 에러 메시지가 무슨 뜻인지 아시나요?"처럼 간단한 질문도 괜찮습니다. 질문을 하고 도움을 받은 후에는 "감사합니다, 덕분에 해결했습니다"라고 피드백을 주는 것도 잊지 마세요. 이런 선순환이 쌓이면 팀 내에서 질문하기 좋은 문화가 만들어집니다.
 
 
## 이제 질문해 보세요
개발자 K씨는 이제 더 이상 5시간을 혼자 끙끙대지 않습니다. 30분 시도하고, 질문을 정리하고, 적절한 사람에게 적절한 방식으로 물어봅니다. 그리고 5분 만에 해결하고 다음 작업으로 넘어갑니다. 그가 달라진 건 실력이 아니라, 질문하는 법을 배웠기 때문입니다.
 
질문하지 않고 5시간을 혼자 끙끙대는 것보다, 30분 시도하고 질문해서 5분 만에 해결하는 것이 팀 전체에 이롭다는 사실을 기억하세요. 그리고 오늘 여러분이 던진 질문 하나가, 내일 같은 문제로 고민할 또 다른 동료의 시간을 지켜줍니다.
 
질문은 약점이 아닌, 배우려는 의지의 표현입니다. 좋은 개발자는 좋은 코드를 작성하는 사람이기도 하지만, 좋은 질문을 하는 사람이기도 합니다.
 
혼자 고민하며 시간을 낭비하는 것보다, 용기 내어 질문하고 함께 성장하는 것이 훨씬 가치 있습니다. 여러분의 질문이 팀 전체를 더 나은 방향으로 이끌 수 있다는 것을 기억하세요. 완벽한 개발자는 없습니다. 하지만 계속 배우려는 개발자는 있습니다.
 
지금 막혀있는 문제가 있다면 30분 타이머를 켜고 시도해 보세요. 그리고 타이머가 울리면 용기 내어 질문해 보세요. 그 작은 한 걸음이 여러분을 더 나은 개발자로 만들어줄 것입니다.
 
 
### 📌 함께 읽으면 좋은 글
* [사이드 프로젝트, 시작은 했는데 끝이 안 나는 이유](https://community.programmers.co.kr/post/12938?utm_source=&utm_medium=&utm_campaign=&utm_content=gocoder_12938)
* [개발자의 실수 노트: 실패에서 배우는 기술](https://community.programmers.co.kr/post/12838?utm_source=&utm_medium=&utm_campaign=&utm_content=gocoder_12838)
* [개발자의 인간관계: 코드보다 어려운 인간관계](https://community.programmers.co.kr/post/12607?utm_source=&utm_medium=&utm_campaign=&utm_content=gocoder_25oct)
 
 

![고코더 작가님 프로필 카드.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/0fda2445-0f60-47d2-8a17-024015c411c8/%E1%84%80%E1%85%A9%E1%84%8F%E1%85%A9%E1%84%83%E1%85%A5%20%E1%84%8C%E1%85%A1%E1%86%A8%E1%84%80%E1%85%A1%E1%84%82%E1%85%B5%E1%86%B7%20%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%84%91%E1%85%B5%E1%86%AF%20%E1%84%8F%E1%85%A1%E1%84%83%E1%85%B3.png)

개발자가 알아야 할 질문의 기술

프론트엔드 데브코스 수료 후 무신사 프론트엔드 개발자로 취업한 정지영 님의 인터뷰입니다. 지영님은 데브코스를 통해 이루고 싶었던 목표를 모두 달성할 수 있었다고 하셨는데요. 무신사 프론트엔드 개발자로 입사할 수 있었던 지영님의 비결이 궁금하다면 인터뷰를 끝까지 읽어보세요.
 
# 간단한 자기소개와 취업한 회사에서의 직무에 대해 소개해 주세요.
안녕하세요. 프론트엔드 개발자 정지영입니다. 저는 무신사의 글로벌 개발팀에서 프론트엔드 개발자로 일하고 있습니다. 저희팀은 무신사가 새로 도전하고 있는 글로벌 무신사 플랫폼 개발 업무를 맡고 있어요. 지금 막 시작한 지 얼마 되지 않은 플랫폼이지만, 로켓 성장하고 있답니다. 새로운 기능 추가뿐만 아닌 프로모션 페이지 개발, 플랫폼 디자인 개편, SSR로의 전환 작업 등 재미있는 업무들을 하나씩 해치워 나가고 있습니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/6cf613b7-ec37-4809-8778-ef7c409f6726/image.png)

# 취업을 준비하면서 가장 신경 쓴 부분이 있다면 무엇인가요?
단순히 어떤 지식을 달달 외우는 것보다는 이해하려고 많이 노력했어요. 사실 프론트엔드 면접 질문이라고 검색을 해보면 정말 많은 참고 문서들이 나오는데, 그 질문에 대한 답만 외워 준비해가면 어느 순간 들통나더라고요.

또한 코딩을 할 때 어떤 이슈가 발생하면, 이슈에 대한 원인을 찾는 과정에서 내가 얼마나 이 부분에 대해 얕은 지식을 가지고 있는지가 드러났어요. 따라서 기초부터 쌓아 올리는 게 정말 중요함을 알았습니다. 이후에 어떤 지식에 대해 학습할 때는, 근본적인 배경부터 동작 원리까지 파악한 뒤 암기했습니다. 전체적인 흐름을 파악하려고 노력했던 것 같아요.

# 취업에 성공할 수 있었던 나만의 비결이 있다면 공유해 주세요!
비결이라고 하기에는 부끄럽지만, 멈추지 않았던 것이 저의 가장 큰 장점이라고 생각해요. 2020년 학부 연구생을 시작한 뒤부터 정말 열심히 살았거든요. 2022년 데브코스를 수료하고 나서도 약 20~30개의 기업에 지원했고, 주에 약 3개의 전형을 동시에 진행했던 경험도 있어요. 비록 짧은 기간이었지만 취업 준비 기간 동안 수많은 탈락을 경험했고, 그때마다 지치고 포기하고 싶던 순간이 많았어요. 하지만 계속해서 새로운 도전을 찾아 나섰기 때문에 다수의 회사에 합격할 수 있었지 않았나 생각합니다.
 
### 무신사에 취업하고 싶은 분들을 위한 면접 Tip!
기술에 대한 숙련도는 어느 회사나 비슷하게 여쭤보는 것 같아요. 무신사의 면접을 떠올리자면, 무신사라는 기업에 대해 그리고 지원하는 팀에 대한 충분한 이해가 필요하다고 생각합니다. 회사와 팀에 대한 충분한 이해와 동시에, 내가 왜 이 회사, 그리고 이 팀에 가고 싶은지 열정적으로 설명했던 게 저의 합격 포인트라고 생각해요. 실제로 회사 팀 분도 제 열정이 남달랐다고 말씀해주셨습니다.

# 프론트엔드 데브코스를 하면서 가장 기억에 남는 활동이 있었다면 무엇인가요?
너무 많아요. 교육 과정 강의, 프로젝트, 별도로 진행했던 스터디 등 모두 기억에 남습니다. 그래도 가장 기억에 남았던 건 게임대회였어요.
우선 힘든 교육과정 속에서 게임대회를 통해 잠시 머리를 식힐 수 있어 너무 좋았어요. 슈의 라면가게 하루 동안 열심히 연습했었습니다. 또한 TF팀에 속해서 게임대회를 기획하고 진행했었는데, 모든 분들이 적극적으로 참여해 주셔서 정말 좋았어요. 제가 남들 앞에서 말하는 역량이 부족해 많이 떨곤 하는데, 격려해주신 TF팀, 매니저님들 그리고 엄청난 호응을 보여준 뎁코 분들 덕분에 잘 끝낼 수 있었던 것 같아요. 너무 감사했고, 이 경험 덕분에 제 PT 역량도 키울 수 있었습니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/ab14eb11-d4a1-4af3-ad0a-97d85fa26540/image.png)

![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/28347670-eda1-42e5-a488-3c957a24feea/image.png)

# 데브코스에서 어려운 과제를 극복하고 기술적으로 성장한 경험이 있다면 이야기해주세요.
뎁코에서 두번째 팀 프로젝트를 진행할 때 크고 작은 기술적인 문제에 많이 부딪혔었는데요. 저희 프로젝트가 모달을 정말 많이 사용했기 때문에, 각 모달의 상태를 관리하는 것에서 어려움을 겪었던 기억이 나요.

사실 완벽하게 해결하지는 못했어요. 많은 개선을 이뤄냈지만 아직도 복잡한 상태를 가지고 있습니다. 다만 이 방식은 어떨까 저 방식은 어떨까 계속해서 고민하고 시도하는 과정에서 기술적인 성장을 이뤄냈던 경험이었습니다.

👉 [**팀 프로젝트 회고록**](https://blog.haeyum.me/devcourse/project/retrospective/LinkBook/)

# 프론트엔드 데브코스를 통해 이루고자 했던 목표가 있었나요? 어느 정도 달성하셨나요?
프론트엔드 개발 툴인 React, nextJS 등 여러 툴을 학습하고 프론트엔드 개발자가 되기 위한 준비를 하는 것이 1차 목표, 프론트엔드 개발자로 취업하는 것이 2차 목표였습니다. 추가적으로 프론트엔드 개발자로서의 진로를 희망하는 분들과 활발한 네트워킹도 얻어가고 싶었습니다.

데브코스 과정을 통해 이루고 싶었던 모든 목표는 이뤘다고 생각해요. 다만 여기서 안주하지 않고, 앞으로의 새로운 목표를 여럿 세웠어요. 하나 말해보자면, 당장의 목표는 회사에 잘 녹아들고, 잘 흡수하는 것이에요. 팀에서 혼자 유일한 주니어이기 때문에 현업에서 배울 수 있는 실무 지식뿐만 아니라 여러 협업 방법, 일하는 방식 등을 빠르게 흡수해 제 것으로 만들기 위해 노력하고 있어요.

# 데브코스 과정이 실제로 취업에 어떤 도움을 주었다고 생각하시나요?
학부에서 프론트엔드 과목이 없었던 저에게는 정말 큰 도움이 되었어요. 커리큘럼을 통한 프론트엔드 지식 습득, 멘토링, 팀 프로젝트 모두 저에게 큰 도움이 되었던 경험들입니다. 또한 데브코스를 수료하고 나서 마음이 맞는 분들과 스터디를 계속 진행하고 있어요. 모든 분들이 취업하시고 난 다음에는 이직 스터디로 이름을 바꾸려고 합니다. 이렇게 소중한 프론트엔드 인연들을 만나게 된 것도 데브코스 덕이라고 생각해요.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/9d90f164-7541-42e7-b0eb-04fda9150ad1/image.png)

![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/8eb4946c-b7c1-4ed1-bcea-0074da866c43/image.png)

![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/84fac37f-02f8-4304-9acd-451d5341c00f/image.png)

# 타 기관이 아닌, 프로그래머스를 선택하신 이유가 있을까요?
우선 저는 학부에서 프론트엔드 관련 과목이 없었기 때문에 프론트엔드 전문 교육을 듣고 싶었습니다. 또한 프로그래머스 데브코스가 어느 정도 프로그래밍에 대한 지식이 있는 개발자 지망생들을 대상으로 한 커리큘럼이기 때문에, 교육의 수준이 낮지 않다는 점도 마음에 들었어요. 결론적으로는 제가 듣고 싶은 교육 커리큘럼과 프로그래머스 교육 커리큘럼이 일치해 선택하게 되었어요.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/a7b37474-31bd-40f5-9b83-275e881c6fcd/image.png)

# 앞으로 어떤 개발자가 되고 싶으신가요?
즐기며 일할 수 있는 개발자가 되고 싶어요. 즐기는 자를 이길 수 없다는 말이 있잖아요. 저는 프론트엔드 개발이 정말 재밌고, 앞으로도 지치지 않고 쭉 즐기면서 개발하고 싶어요. 사실 지금도 일과 삶의 구분이 잘 없는 것 같긴 해요. 집에 와서도 사이드 프로젝트를 하며 머리를 식히고 있습니다.

# 후배 교육생들에게 응원의 한마디나 조언 부탁드립니다.
데브코스를 통해 아무 회사에 프론트엔드 개발자로 취업하고 싶던 제가 구체적인 취업 목표를 정했고, 앞으로 개발자로서 어떻게 성장을 해야 할지 가이드라인을 잡을 수 있었어요. 또한, 5개월이라는 시간 동안 개발에 몰두하며, 저는 정말 개발을 즐기며, 이 직업이 나에게 적합하다는 것을 확실히 알 수 있었습니다.
결론적으로 데브코스는 프론트엔드 개발자가 되고 싶은 지망생들에게는 정말 좋은 교육과정이라고 생각해요. 교육 과정, 부트 캠프를 알아보고 있는 지망생들에게 꼭 추천하고 싶습니다. 다만 자신이 이 교육에서 무엇을 얻어가고 싶은지 확실한 목표를 미리 정하면, 더 얻어갈 수 있는 것이 많을 것이라 생각해요.
 
 
[![fe-coding-test2(729x90).jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/a6abbf85-414d-4dca-9916-46aab3595a5c/fe-coding-test2%28729x90%29.jpg)](https://school.programmers.co.kr/learn/courses/25243?utm_source=prgmblog&utm_medium=social&utm_campaign=school_25243_blog&utm_content=25243_banner)

[데브코스 후기] 데브코스 수료하고 무신사 개발자로 합격! - 프론트엔드 2기 수료생 정지영님

프로그래머스에도 고퀄리티 코딩 강의를 무료로 제공하고 있다는 사실, 알고 계셨나요? 파이썬, 자바, 자바스크립트 등 인기 언어를 포함해, 입문자를 위한 기초 강의부터 실무 팁까지 다양하게 마련되어 있습니다. 이번 포스팅에서는 프로그래머스에서 제공하는 무료 강의들을 주제별로 깔끔하게 정리해봤어요. 프로그래밍을 처음 시작하는 분들부터 실력을 한 단계 더 끌어올리고 싶은 분들까지, 지금 바로 알짜배기 강의들을 만나보세요!
 
# 초보자를 위한 프로그래밍 입문 강의
프로그래밍 공부를 처음 시작하려고 마음먹었다면, 무료 강의부터 가볍게 도전해보는 건 어떨까요? 학습에 투자하는 것도 중요하지만, 유료 강의를 결제해 놓고 정작 제대로 보지 못하는 경우도 많잖아요. 무료 강의로 나와 잘 맞는지, 어떤 언어가 나에게 맞을지 먼저 체험해보는 것이 훨씬 효율적인 시작이 될 수 있습니다.
 
## 1. 파이썬 입문
프로그래머스 파이썬 입문은 파트 18, 83개의 코딩 실습으로 알차게 구성되어 있는 강의입니다. 현재까지 64,645명의 수강생이 함께했으며, 평점 4.9점, 275개의 후기가 증명하는 고퀄리티 파이썬 입문 강의랍니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/76bc6d73-b9c5-4cff-8b63-9f4226e9cca0/image.png)
👉 **[파이썬 입문 강의 바로가기](https://school.programmers.co.kr/learn/courses/2/2-%EB%AC%B4%EB%A3%8C-%ED%8C%8C%EC%9D%B4%EC%8D%AC-%EC%9E%85%EB%AC%B8)**
 
## 2. 자바 입문
가장 널리 쓰이는 프로그래밍 언어 Java로 프로그래밍 기초를 다질 수 있는 강의! 현재까지 68,613명의 수강생이 함께한 강의로, 파트 10, 55개의 코딩 실습으로 구성되어 있는 강의입니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/d31a4ebf-70c5-4b7a-af89-fe9e566031a4/image.png)
👉 **[자바 입문 강의 바로 가기](https://school.programmers.co.kr/learn/courses/5/5-%EB%AC%B4%EB%A3%8C-%EC%9E%90%EB%B0%94-%EC%9E%85%EB%AC%B8)**
 
## 3. 자바스크립트 입문
파트 11, 35개의 코딩 실습으로 구성된 자바스크립트 입문 강의! 자바스크립트를 처음 접하시는 분들도 부담없이 하루 20분씩만 투자하면 학습할 수 있는 강의입니다. 기초와 실습을 동시에 학습할 수 있는 입문용 강의로 추천합니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/a89bc996-74fc-40af-bb1d-e8bf6073eaab/image.png)
👉 **[자바스크립트 입문 강의 바로가기](https://school.programmers.co.kr/learn/courses/3/3-hello-javascript-%EC%9E%90%EB%B0%94%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8A%B8-%EC%9E%85%EB%AC%B8)**
 
 
# 코딩 테스트를 준비 중인 분들을 위한 꿀팁 강의 🍯 
프로그래머스를 자주 이용하시는 분들이라면, 이미 다양한 코딩 테스트 문제를 접해보셨을텐데요. 문제를 풀다가 "조금만 힌트가 있으면 풀 수 있을 것 같은데..."라는 생각, 한 번쯤 해보신 적 있으시죠? 그렇다면 지금 소개해드릴 코딩 테스트 꿀팁 강의들을 꼭 참고해보세요! 문제 풀이의 실마리를 잡고, 더 똑똑하게 접근하는 법을 배울 수 있을 거예요.
 
## 1. 코딩테스트 연습 힌트 모음집
파트9까지 준비되어 있는 코딩테스트 연습 힌트 모음집! 수강 후기 평점 5.0점의 고퀄리티 자료를 지금 바로 만나보세요.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/31939fe4-9c57-4e31-ab1d-2f67a4e4f623/image.png)
👉 **[코딩테스트 연습 힌트 모음집 바로가기](https://school.programmers.co.kr/learn/courses/14743/14743-%EC%BD%94%EB%94%A9%ED%85%8C%EC%8A%A4%ED%8A%B8-%EC%97%B0%EC%8A%B5-%ED%9E%8C%ED%8A%B8-%EB%AA%A8%EC%9D%8C%EC%A7%91)**
 
## 2. 알고리즘 문제 해설
파트 7까지 준비되어 있는 알고리즘 문제 해설! 동적 프로그래밍으로 문제를 해결하는 과정을 연습해보세요.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/cbbf0f40-d490-4479-a3fe-99da9c86a668/image.png)
👉 **[알고리즘 문제 해설 바로가기](https://school.programmers.co.kr/learn/courses/18/18-%EC%95%8C%EA%B3%A0%EB%A6%AC%EC%A6%98-%EB%AC%B8%EC%A0%9C-%ED%95%B4%EC%84%A4)**
 
## 3. 파이썬을 파이썬답게
이 강의는 파이썬 문법을 이미 알고 있는 분들을 대상으로 만들어졌으며, 이런 분들께 특히 추천하는 강의입니다.
* 파이썬 문법을 알고 계시는 분
* 알고리즘 문제를 조금 더 쉽게 풀고 싶은 분
* Python 코드를 low-level 언어(C/C++) 코드처럼 짜시는 분

 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/f59316e4-5332-479d-ad21-9ebe0f115431/image.png)
👉 **[파이썬을 파이썬답게 바로가기](https://school.programmers.co.kr/learn/courses/4008/4008-%ED%8C%8C%EC%9D%B4%EC%8D%AC%EC%9D%84-%ED%8C%8C%EC%9D%B4%EC%8D%AC%EB%8B%B5%EA%B2%8C)**
 
수강생 평점 4.9점에 좋은 후기들이 가득한 파이썬 강의! 지금 바로 들어보세요.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/86fa316d-4812-451d-b975-65f9d188963c/image.png)
 
 
[![coding_test-2 (1).jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/ba857415-17bd-4357-ada4-a3fd514bbf74/coding_test-2%20%281%29.jpg)](https://school.programmers.co.kr/learn/courses/25244?utm_source=prgmblog&utm_medium=social&utm_campaign=school_25244_blog&utm_content=25244_banner)

프로그래머스 무료 코딩 강의 총정리: 입문부터 코딩 테스트 팁까지!

개발자의 번아웃, 조용히 찾아오는 위험 신호들

안녕하세요. 저는 그렙에서 플랫폼 개발을 담당하고 있는 4년차 프론트엔드 개발자 딜런(Dylan)입니다.
개발자로서 효율적이면서도 유지보수하기 쉬운 개발에 대해 늘 고민하고 있는데요.
오늘은 이러한 고민의 연장선에서, **Web Componenets 기술을 활용해 크로스 프레임워크 컴포넌트 개발에 도전했던 경험**을 공유해보려 합니다.
 
 
## 왜 이런 도전을 했을까?
그렙의 프론트엔드 개발 문화는 기술적 자유를 중요하게 여깁니다. 프론트엔드 개발에 React, Vue는 물론 Ruby on Rails 기반의 SSR까지, 다양한 기술 스택을 사용하고 있습니다. 게다가 마이크로 프론트엔드 구조를 지향하다 보니 이 기술들이 하나의 페이지 안에서 함께 사용되는 경우도 적지 않습니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/8af36ac0-f3f0-4f81-bcec-b613b672749e/image.png)
 
이런 환경에서 프론트엔드 개발을 하다 보면 반복해서 마주하게 되는 고민이 하나 있습니다. 바로 공통으로 사용해야 하는 UI 컴포넌트를 반복적으로 생성하고, 유지보수하게 된다는 것입니다.
 
버튼을 예로 들면 Vue용 버튼, React용 버튼, Hera용 버튼을 각각 별도로 관리하고 있는 실정입니다. 게다가 다양한 제품을 여러 팀이 함께 개발하다 보니, 동일한 컴포넌트의 프레임워크라도 여러 프로젝트에 걸쳐 중복으로 구현되는 경우가 많습니다. 그 결과, 비슷한 모양의 버튼이 최대 수십 개씩 개발되어 사용되고 있습니다.
 
이러한 상황이 지속되면 다음과 같은 문제가 발생할 수 있습니다.
* 동일한 컴포넌트의 반복적인 개발로 인해 **생산성이 저하**됩니다.
* 컴포넌트 구현이 여럿이다 보니, **컴포넌트 간 동작 및 시각적 일관성을 유지하기 어렵습니다**.
* 컴포넌트의 디자인을 조금만 수정하려고 해도, 중복되는 모든 컴포넌트를 수정해야 하기 때문에 **유지보수가 어렵습니다**.

 
그래서 저는 이런 고민을 하게 되었습니다.
**"UI 컴포넌트를 딱 한 번만 만들고, 어디서나 사용할 수는 없을까?"**
 
이 질문이 바로, 크로스 프레임워크 컴포넌트 개발에 도전하게 된 출발점이었습니다.
 
 
## 목표: 한 번만 만들고, 어디서든 사용하기
이번 도전 목표는 **단순하고 가벼운 크로스 프레임워크 컴포넌트를 만들어, 어느 환경에서든 사용할 수 있게 하는 것**이었습니다. 이를 달성하기 위한 기술 기반으로 **Web Components**가 가장 적합하다고 판단했습니다.
 
![스크린샷 2026-01-19 오후 1.59.50.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/006259a1-6233-4ed7-adcb-4b8c611f9bcc/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202026-01-19%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%201.59.50.png)
 
Web Components는 다음과 같이 정의할 수 있습니다.
> 재사용 가능하고 캡슐화된 커스텀 엘리먼트를 구현하고, 이를 웹 애플리케이션에서 사용할 수 있도록 해주는 여러 Web API 기술들을 통칭하는 개념

 
이를 통해 재사용 가능한 컴포넌트를 개발할 수 있으며, 다음과 같은 특징을 갖습니다.
* 웹 표준(네이티브) 기술에 기반하여 높은 웹 브라우저 호환성 (Chrome 67~, Safari 10~)
* HTML, React, Vue 등 프레임워크와 무관하게 재사용 가능
* Shadow DOM 기반의 강력한 컴포넌트 캡슐화

 
이런 특성 덕분에 Web Componenets는 '한 번만 만들고, 어디서든 사용한다'는 이번 도전 목표를 달성하는 데에 가장 부합하는 기술이라고 판단했습니다.
 
 
## Web Componenets의 기본 개념
Web Components는 세 가지 핵심 기술로 구성됩니다.
간단한 예제와 함께 하나씩 설명해보겠습니다.
 
### 1. Custom Elements
HTML 태그를 마음대로 정의할 수 있는 개념입니다.
단순히 `HTMLElement`클래스를 상속한 커스텀 엘리먼트 클래스를 정의하고 레지스트리(`window.customElements.define()`)에 등록하면 바로 사용 가능합니다.
 
다음은 `prgms-banner`라는 이름의 커스텀 엘리먼트를 정의, 등록 및 사용하는 예시입니다.
 
```js
<script>
// 커스텀 엘리먼트 클래스 정의 (구현은 잠시 생략)
class PrgmsBannerElement extends HTMLElement { ... }

// 엘리먼트를 레지스트리에 등록
customElements.define('prgms-banner', PrgmsBannerElement);
</script>


<prgms-banner variant="primary" onclick="handleOk"></prgms-banner>
```

 
### 2. Shadow DOM
컴포넌트 내부의 HTML 및 CSS를 외부로부터 완전히 격리할 수 있는 기술입니다.
 
Shadow DOM 내부의 요소는 기본적으로 외부 스타일의 영향을 받지 않으며, DOM 트리에서도 엘리먼트가 Shadow Root 아래로 숨겨집니다.
이로 인해 Shadow DOM 바깥(Light DOM)에서는 Shadow DOM 내부의 요소를 `getElementById()`, `querySelector()`등으로 검색할 수 조차 없습니다.
 
다음은 내부 요소를 Shadow DOM으로 캡슐화하는 방식의 커스텀 엘리먼트 예시입니다.
 
```js

<script>
class PrgmsBannerElement extends HTMLElement {
 constructor() {
 super();
 
 const shadow = this.attachShadow({ mode: 'open' });
 shadow.innerHTML = `
 <div class="banner">
 Shadow DOM Prgms Banner
 </div>
 <style>
 .banner {
 padding: 5px;
 background-color: tomato;
 }
 </style>
 `;
 }
}

customElements.define('prgms-banner', PrgmsBannerElement);
</script>


<style>
.banner {
 background-color: skyblue !important;
}
</style>


<prgms-banner></prgms-banner>
<div class="banner">
 Light DOM Just Banner
</div>
```
 
위 코드를 실행해보면 아래와 같은 결과가 나옵니다. ([Code Pen 링크](https://codepen.io/jeongtae/pen/vEGvPmj))
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/a74cc8b7-18be-4295-9fe7-32e8e3bc0e8a/image.png)
 
Shadow DOM 내부와 외부에 모두 `div.banner`요소가 존재하지만, 외부 스타일로 정의한 `skyblue`배경색 지정이 Shadow DOM 내부의 `.banner`요소에는 통하지 않는 것을 확인하실 수 있습니다.
 
### 3. HTML Templates & Slots
랜더링되지 않는 마크업 조각을 미리 정의해두고 필요할 때 찍어낼 수 있는 기술입니다.
요소를 `<template>`으로 감싸면 렌더링되지 않는 마크업 조각이 되며, 이를 클론하여 재사용할 수 있습니다. 그리고 `<slot>`으로 컴포넌트(커스텀 엘리먼트) 내에 콘텐츠가 들어갈 자리를 슬롯으로 비워둘 수 있습니다. 이들은 마치 React에서의 JSX 코드조각 및 `children`프롭과 비슷한 역할을 합니다.
 
다음은 템플릿과 슬롯을 사용하는 커스텀 엘리먼트 예시입니다.
 
```js

<template id="prgms-banner">
 <div class="banner">
 <slot></slot>
 </div>
 <style>
 .banner {
 padding: 5px;
 background-color: tomato;
 }
 </style>
</template>


<script>
class PrgmsBannerElement extends HTMLElement {
 constructor() {
 super();
 
 const shadow = this.attachShadow({ mode: 'open' });
 
 const template = document
 .getElementById("prgms-banner")
 .content.cloneNode(true);

 shadow.append(template);
 }
}

customElements.define('prgms-banner', PrgmsBannerElement);
</script>


<prgms-banner>
 Hello World!
</prgms-banner>
```
 
위 코드를 실행해보면 아래와 같은 결과가 나옵니다. ([Code Pen 링크](https://codepen.io/jeongtae/pen/EaKGMwW?editors=1010))
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/c74bcb18-8715-469d-be2f-d58585519423/image.png)
 
`<prgms-banner>`요소 내에 지정한 콘텐츠가 Shadow DOM 내부의 슬롯에 렌더링되는 것을 확인하실 수 있습니다.
 
 
## Lit으로 도전해보자
앞서 살펴본 Web Components의 기본 개념만으로도 목표 달성의 가능성은 충분히 확인할 수 있었습니다. 하지만 본격적인 컴포넌트 개발을 이렇게 바닐라 자바스크립트로 진행하기는 어려울 것입니다. 반복되는 코드 및 보일러플레이트가 너무 많아 생산성이 떨어지고, 상태 관리가 어려워 고급 컴포넌트를 만들기 어렵기 때문인데요. 다행히 이를 극복할 수 있는 Lit이라는 도구가 있습니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/5b40d3bf-7580-4ff7-b740-dbf5edd4f3b0/image.png)
([링크](https://lit.dev/))
 
Lit은 Web Components를 쉽고 빠르게 개발할 수 있도록 돕는 라이브러리입니다. Google이 주도하는 프로젝트로, Web Components 생태계에서 가장 널리 사용되는 도구입니다. Lit은 다음과 같은 특징을 가지고 있습니다.

* 클래스·데코레이터 기반 구조 → **보일러플레이트가 매우 적습니다**.
* 선언적 템플릿과 반응형 상태 시스템 제공 → **React·Vue처럼 직관적인 개발이 가능합니다**.
* 경량 라이브러리 → **기존 빌드 시스템에 부담 없이 통합할 수 있습니다**.

 
Lit의 장점을 예시 코드를 통해 살펴보겠습니다. Lit으로 버튼 컴포넌트를 구현하는 것은 다음과 같이 매우 간단합니다.
 
```js
// 데코레이터로 정의하기만 하면 레지스트리에 자동 등록
@customElement('prgms-button')
export class PrgmsButtonElement extends LitElement {
 // 스타일은 정적 프로퍼티로 간편하게 지정
 static styles = [...];
 
 // 프로퍼티는 데코레이터로 정의하기만 하면 반응형까지 보장됨
 @property()
 variant: 'primary' | 'secondary';
 
 @property({ type: Boolean })
 disabled = false;
 
 // 선언적인 형태의 템플릿 & 렌더 함수
 render() {
 return html`
 <button
 class=${this.variant}
 ?disabled=${this.disabled}
 >
 <slot></slot>
 </button>
 `;
 }
}
```
 
이전에 바닐라 자바스크립트로 구현했던 예제와 비교해보면, 코드가 훨씬 간결해졌음을 확인할 수 있습니다. 문법이 깔끔하고 전체적인 구조가 선언적이어서, 직관적이고 이해하기도 쉽습니다.
 
Lit으로 잘 구현된 디자인 시스템 사례들도 어렵지 않게 찾아볼 수 있었는데요.이러한 점을 통해, '**충분히 실무에도 적용 가능한 수준의 기술**'이라고 판단할 수 있었습니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/8e4fe799-8eeb-42c3-894b-6ca9895a1b11/image.png)
([링크](https://nordhealth.design/components/))

 
 
지금까지 살펴본 것처럼, Web Components와 Lit을 활용하면 크로스 프레임워크 컴포넌트를 구현하는 것이 이론적으로는 충분히 가능해 보였습니다.
하지만 기술 선택에 있어 가장 중요한 것은 언제나 실제 환경에서의 검증입니다.
과연 이러한 접근이 실제 제품 환경에서도 문제없이 동작할 수 있을까요?
 
이 질문에 대한 답을 확인하기 위해, **다음 단계로 Lit 기반 Web Components를 실제 제품에 적용해보는 PoC를 진행**해보았습니다.
PoC 과정, 그리고 그 결과와 인사이트는 [다음 포스팅](https://community.programmers.co.kr/post/13235?utm_source=&utm_medium=&utm_campaign=&utm_content=greppdev_13235)에서 자세히 다뤄보도록 하겠습니다.
 
 
글 작성: Dylan (Grepp 프론트엔드 개발자)
 
 
### 📌 함께 읽으면 좋은 글
* [크로스 프레임워크 컴포넌트 개발 도전기 (2): PoC를 통해 발견한 가능성과 한계](https://community.programmers.co.kr/post/13235?utm_source=&utm_medium=&utm_campaign=&utm_content=greppdev_13235)
 
 
[![블로그 배너_AI BE.jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/c9bdb6ce-528d-4374-996c-6d0af29beae3/%E1%84%87%E1%85%B3%E1%86%AF%E1%84%85%E1%85%A9%E1%84%80%E1%85%B3%20%E1%84%87%E1%85%A2%E1%84%82%E1%85%A5_AI%20BE.jpg)](https://school.programmers.co.kr/learn/courses/25487?utm_source=mailchimp&utm_medium=DM&utm_campaign=school_25487_blog&utm_content=25487_banner_mkt)

크로스 프레임워크 컴포넌트 개발 도전기 (1): Web Components와 Lit으로 가능성을 검증하다

이 글은 이선협 개발자의 [<코딩 테스트 광탈 방지 A to Z : JavaScript>](https://school.programmers.co.kr/learn/courses/13213/13213-%EC%BD%94%EB%94%A9%ED%85%8C%EC%8A%A4%ED%8A%B8-%EA%B4%91%ED%83%88-%EB%B0%A9%EC%A7%80-a-to-z-javascript) 강의 내용을 바탕으로 재구성한 글입니다. 비록 JavaScript 강의지만, 사용하는 언어와 관계없이 충분히 도움이 될 거예요.
 
# 자료구조와 알고리즘
## 1️⃣ 자료구조와 알고리즘이란?
자료구조는 메모리를 효율적으로 사용하면서 데이터를 빠르고 안정적으로 처리하기 위한 구조입니다. 자료구조는 특정 상황에 맞게 유용하게 사용될 수 있도록 만들어져 있기 때문에 어떤 상황에선 느리고 불안정할 수 있죠. 따라서 상황에 맞는 자료구조를 고를 수 있는 능력이 필요합니다.
 
알고리즘은 특정 문제를 메모리 효율적이고 빠른 성능으로 해결하는 일련의 절차입니다. 수학적인 방식으로 공식화되어 있으며, 자료구조와 마찬가지로 상황에 따라 적합한 알고리즘이 다릅니다.
 
## 2️⃣ 요리에 비유해 볼까요?
처음 자료구조와 알고리즘의 개념을 접한다면, 위의 내용만 듣고선 이해가 잘 안 갈 수 있습니다. 요리에 비유해서 생각해봅시다.
* 재료 = 데이터
* 조리도구 = 자료구조
* 레시피 = 알고리즘

예를 들어, 까르보나라를 만들기 위해서는 재료를 고르고, 도구를 사용해 조리하고, 레시피에 따라 요리를 합니다. 이처럼 개발자는 **적절한 데이터, 자료구조, 알고리즘을 조합해 프로그램을 완성**합니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/4765d0cc-ae8d-4646-9746-f567f52eda49/image.png)
 
# 자료구조와 알고리즘이 중요한 이유
그렇다면 자료구조와 알고리즘은 왜 중요한 걸까요? 다양한 이유가 있지만 이번 아티클에서는 세 가지 정도만 꼽아보겠습니다.
 
## 1️⃣ 기초 코딩 능력이 향상돼요.
실무에서는 다음 세 가지 능력이 중요합니다.
* **기초 코딩 능력**
* **전문 분야 지식**
* **CS(Computer Science) 지식**

이 중 기초 코딩 능력은 바로 자료구조와 알고리즘 공부를 통해 키울 수 있습니다. 대부분의 회사에서는 특정 프레임워크나 라이브러리에 정통한 사람을 찾지 않습니다. 빠르게 변화하는 IT 트렌드에 대응할 수 있는 문제 해결 능력을 갖춘 사람을 찾죠. 이러한 사람은 어떤 기술이든 빠르게 습득하고 적응할 수 있습니다. 따라서 **개발자의 기본기가 되어 줄 자료구조와 알고리즘을 공부하면, 자연스럽게 기초 코딩 능력**도 향상됩니다.
 
## 2️⃣ 한 번 배워두면 오래 써먹어요.
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/b723fd31-a9e0-498a-b9c8-969e8f347290/image.png)
1956년에 만들어진 다익스트라 알고리즘이 아직도 활발히 쓰이고 있다는 사실, 알고 계셨나요? 70년이 다 되어 가는데도 현역이죠. 이처럼 자료구조와 알고리즘은 시간이 지나도 변하지 않는 개념이기 때문에, 한 번 배워두면 오랫동안 유용하게 사용할 수 있습니다.
 
## 3️⃣ 실무에서도 쓰여요.
자료구조와 알고리즘은 특히 코딩 테스트를 위해 준비하는 경우가 많은데요. 사실 실무에서도 사용된답니다. 실제 사례를 살펴볼까요?
 
```
(상황)
100만 개의 고객 데이터를 최신으로 업데이트하기 위한 배치 작업 필요
- 100만 개의 고객 데이터는 CSV로 제공
- CSV 데이터 중 기존 DB에 없는 고객은 추가
- CSV 데이터엔 고객 Key 값이 없으므로 DB의 여러 필드를 대조해야 함

(구현)
100만 개 데이터를 매번 순회하여 고객을 찾은 후 업데이트, 없으면 추가
➡️ 5일 이상 소요
```
 
100만 개의 고객 데이터를 최신으로 업데이트하기 위한 작업이 필요했습니다. 이 데이터는 정제되지 않은 CSV 파일로 제공되었고, 심지어 Key가 되는 값도 없어서 일일이 여러 데이터를 대조해서 찾아야 했죠. 이 작업은 단순히 100만 개 데이터를 매번 순회하여 데이터를 찾은 후, 최신으로 업데이트를 하고 데이터가 없으면 추가하는 방식으로 구현을 했습니다. 이런 방식은 단순하고 느린 방식이라고 할 수 있어요. 결국 5일이 넘게 소요되어 다시 로직을 작성해야 했습니다.
 
기존 DB의 100만 개 데이터를 이름 기준으로 테이블에 기록하였고, 동명이인이 있을 경우 해시 테이블 Value를 링크드 리스트로 데이터를 추가했습니다. 또한, 고객을 찾을 때 이름을 Key로 찾은 후 동명이인이 여럿 존재한다면 이진 탐색을 사용하여 해결했습니다. 결과적으로 **알고리즘을 활용하여 5일 이상 소요되던 로직을 20분 만에 마칠 수 있도록 개선**했습니다.
 
```
(개선)
해시 테이블과 링크드 리스트를 이용하여 데이터 구조를 변경 후 이진 탐색 알고리즘 적용
➡️ 20분 만에 해결
```

 
# 마무리하며
자료구조와 알고리즘은 개발자의 기본기이자, 실무에서의 무기입니다. 코딩 테스트를 준비하거나 실무에서 성능 최적화에 도전하고 싶으신가요? 프로그래머스와 함께 오늘부터 차근차근 시작해보세요.
 
👉 [프로그래머스 <코딩 테스트 광탈 방지 A to Z : JavaScript> 강의 더 알아보기](https://school.programmers.co.kr/learn/courses/13213/13213-%EC%BD%94%EB%94%A9%ED%85%8C%EC%8A%A4%ED%8A%B8-%EA%B4%91%ED%83%88-%EB%B0%A9%EC%A7%80-a-to-z-javascript)
 
 
[![coding_test-2.jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/8b70fed7-a592-4d19-8b10-ea3890492c52/coding_test-2.jpg)](https://school.programmers.co.kr/learn/courses/25243?utm_source=prgmblog&utm_medium=social&utm_campaign=school_25243_blog&utm_content=25243_banner)

자료구조와 알고리즘, 왜 꼭 배워야 할까?

안녕하세요, 프로그래머스입니다!
 
초여름의 시작을 알리는 6월이 찾아왔어요 ☀️
머쓱이 디지털 굿즈와 함께 6월도 성장을 향해 달려보세요.
프로그래머스는 6월에도 여러분의 학습과 성장을 응원합니다. 💪
 
 
# 6월 머쓱이 캘린더
![캘린더 6월 머쓱이(Mac)-36.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/33e94516-2d89-40ff-a823-a99b18f686e7/%E1%84%8F%E1%85%A2%E1%86%AF%E1%84%85%E1%85%B5%E1%86%AB%E1%84%83%E1%85%A5%206%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%86%E1%85%A5%E1%84%8A%E1%85%B3%E1%86%A8%E1%84%8B%E1%85%B5%28Mac%29-36.png)
 
![캘린더 6월 머쓱이(Mac)-37.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/e12958fa-f717-48f2-975c-7fee83d52a4e/%E1%84%8F%E1%85%A2%E1%86%AF%E1%84%85%E1%85%B5%E1%86%AB%E1%84%83%E1%85%A5%206%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%86%E1%85%A5%E1%84%8A%E1%85%B3%E1%86%A8%E1%84%8B%E1%85%B5%28Mac%29-37.png)
 
![캘린더 6월 머쓱이(Mac)-38.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/9525b8f3-ce9c-4867-b0e2-b9db59997d7c/%E1%84%8F%E1%85%A2%E1%86%AF%E1%84%85%E1%85%B5%E1%86%AB%E1%84%83%E1%85%A5%206%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%86%E1%85%A5%E1%84%8A%E1%85%B3%E1%86%A8%E1%84%8B%E1%85%B5%28Mac%29-38.png)
 
![캘린더 6월 머쓱이(Mac).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/05ebe2cc-b0ff-4d8b-aade-0d679465fd3c/%E1%84%8F%E1%85%A2%E1%86%AF%E1%84%85%E1%85%B5%E1%86%AB%E1%84%83%E1%85%A5%206%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%86%E1%85%A5%E1%84%8A%E1%85%B3%E1%86%A8%E1%84%8B%E1%85%B5%28Mac%29.png)
 
![캘린더 6월 머쓱이(Window)-42.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/8c4eef11-349d-4364-b16d-be2c573ba486/%E1%84%8F%E1%85%A2%E1%86%AF%E1%84%85%E1%85%B5%E1%86%AB%E1%84%83%E1%85%A5%206%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%86%E1%85%A5%E1%84%8A%E1%85%B3%E1%86%A8%E1%84%8B%E1%85%B5%28Window%29-42.png)
 
더 많은 배경화면(Mac, Window)은 아래 링크에서 확인 가능합니다.
👉 [머쓱이 6월 캘린더 보러가기](https://prgrms.notion.site/zip-1993e47046bf80629692c4ddef6a01bf)
 
 
# 6월 머쓱이 줌 배경
![줌 6월 머쓱이(기본)-26.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/74042b06-4b97-4f84-b74a-5c70e51ac5db/%E1%84%8C%E1%85%AE%E1%86%B7%206%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%86%E1%85%A5%E1%84%8A%E1%85%B3%E1%86%A8%E1%84%8B%E1%85%B5%28%E1%84%80%E1%85%B5%E1%84%87%E1%85%A9%E1%86%AB%29-26.png)
 
![줌 6월 머쓱이(기본)-27.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/2654dff5-7876-488c-8562-62bd50d0a679/%E1%84%8C%E1%85%AE%E1%86%B7%206%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%86%E1%85%A5%E1%84%8A%E1%85%B3%E1%86%A8%E1%84%8B%E1%85%B5%28%E1%84%80%E1%85%B5%E1%84%87%E1%85%A9%E1%86%AB%29-27.png)
 
![줌 6월 머쓱이(기본)-28.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/199deef2-83b5-40fc-bf60-1885e6fd315c/%E1%84%8C%E1%85%AE%E1%86%B7%206%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%86%E1%85%A5%E1%84%8A%E1%85%B3%E1%86%A8%E1%84%8B%E1%85%B5%28%E1%84%80%E1%85%B5%E1%84%87%E1%85%A9%E1%86%AB%29-28.png)
 
![줌 6월 머쓱이(기본).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/044a39e8-9e22-4462-a061-5c08a16ab748/%E1%84%8C%E1%85%AE%E1%86%B7%206%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%86%E1%85%A5%E1%84%8A%E1%85%B3%E1%86%A8%E1%84%8B%E1%85%B5%28%E1%84%80%E1%85%B5%E1%84%87%E1%85%A9%E1%86%AB%29.png)
 
더 많은 줌 배경화면(기본, 미러 버전)은 아래 링크에서 확인 가능합니다.
👉 [머쓱이 줌 배경화면 보러가기](https://prgrms.notion.site/zip-1993e47046bf80629692c4ddef6a01bf)

머쓱이 6월 캘린더 & 줌 배경화면 무료 배포 💻

안녕하세요, 프로그래머스입니다!
 
쌀쌀한 바람이 부는 11월, 올 한 해의 마무리를 준비할 시기죠.
이번 달에도 여러분의 꾸준한 성장과 도전을 응원할 머쓱이 디지털 굿즈가 돌아왔습니다 ❄️💻
 
연말이 다가올수록 집중력이 흐트러지기 쉬운 때지만,
머쓱이와 함께라면 마지막까지 힘차게 달릴 수 있을 거예요!
 
프로그래머스와 머쓱이가 여러분의 학습 루틴과 커리어 성장을 든든히 응원합니다 ✨🚀
 
 
## 11월 머쓱이 캘린더
![캘린더 11월 머쓱이(Mac)-13.jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/e85a1077-c964-401a-ba2a-db866c08c9bc/%E1%84%8F%E1%85%A2%E1%86%AF%E1%84%85%E1%85%B5%E1%86%AB%E1%84%83%E1%85%A5%2011%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%86%E1%85%A5%E1%84%8A%E1%85%B3%E1%86%A8%E1%84%8B%E1%85%B5%28Mac%29-13.jpg)
 
![캘린더 11월 머쓱이(Mac)-14.jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/96906b5b-a118-42af-823f-93c32a1efb0a/%E1%84%8F%E1%85%A2%E1%86%AF%E1%84%85%E1%85%B5%E1%86%AB%E1%84%83%E1%85%A5%2011%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%86%E1%85%A5%E1%84%8A%E1%85%B3%E1%86%A8%E1%84%8B%E1%85%B5%28Mac%29-14.jpg)
 
![캘린더 11월 머쓱이(Window)-21.jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/63def69b-1c6c-426d-8d27-f7804860b1a8/%E1%84%8F%E1%85%A2%E1%86%AF%E1%84%85%E1%85%B5%E1%86%AB%E1%84%83%E1%85%A5%2011%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%86%E1%85%A5%E1%84%8A%E1%85%B3%E1%86%A8%E1%84%8B%E1%85%B5%28Window%29-21.jpg)
 
![캘린더 11월 머쓱이(Mac)-16.jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/648d661d-6c52-46ed-b251-70ea42331741/%E1%84%8F%E1%85%A2%E1%86%AF%E1%84%85%E1%85%B5%E1%86%AB%E1%84%83%E1%85%A5%2011%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%86%E1%85%A5%E1%84%8A%E1%85%B3%E1%86%A8%E1%84%8B%E1%85%B5%28Mac%29-16.jpg)
 
![캘린더 11월 머쓱이(Mac)-17.jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/3087edcf-6141-4efa-a4a8-ca18f3542509/%E1%84%8F%E1%85%A2%E1%86%AF%E1%84%85%E1%85%B5%E1%86%AB%E1%84%83%E1%85%A5%2011%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%86%E1%85%A5%E1%84%8A%E1%85%B3%E1%86%A8%E1%84%8B%E1%85%B5%28Mac%29-17.jpg)
 
![캘린더 11월 머쓱이(Mac)-18.jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/d5f50ae4-a314-4ada-97a0-aab9c8ca6c11/%E1%84%8F%E1%85%A2%E1%86%AF%E1%84%85%E1%85%B5%E1%86%AB%E1%84%83%E1%85%A5%2011%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%86%E1%85%A5%E1%84%8A%E1%85%B3%E1%86%A8%E1%84%8B%E1%85%B5%28Mac%29-18.jpg)
 
더 많은 배경화면(Mac, Window)은 아래 링크에서 확인 가능합니다.
👉 [**머쓱이 11월 캘린더 다운받기**](https://prgrms.notion.site/zip-1993e47046bf80629692c4ddef6a01bf)
 
 
## 11월 머쓱이 줌 배경
![줌 배경화면 11월 머쓱이-47.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/bd3bbc21-4f20-4847-a4cd-d1128f7b6c37/%E1%84%8C%E1%85%AE%E1%86%B7%20%E1%84%87%E1%85%A2%E1%84%80%E1%85%A7%E1%86%BC%E1%84%92%E1%85%AA%E1%84%86%E1%85%A7%E1%86%AB%2011%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%86%E1%85%A5%E1%84%8A%E1%85%B3%E1%86%A8%E1%84%8B%E1%85%B5-47.png)
 
![줌 배경화면 11월 머쓱이-48.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/3baf6af0-16ae-4da8-ae5f-933f97b02d4b/%E1%84%8C%E1%85%AE%E1%86%B7%20%E1%84%87%E1%85%A2%E1%84%80%E1%85%A7%E1%86%BC%E1%84%92%E1%85%AA%E1%84%86%E1%85%A7%E1%86%AB%2011%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%86%E1%85%A5%E1%84%8A%E1%85%B3%E1%86%A8%E1%84%8B%E1%85%B5-48.png)
 
![줌 배경화면 11월 머쓱이-49.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/c6b740b3-2ccd-49c6-856c-39a558ff1e5e/%E1%84%8C%E1%85%AE%E1%86%B7%20%E1%84%87%E1%85%A2%E1%84%80%E1%85%A7%E1%86%BC%E1%84%92%E1%85%AA%E1%84%86%E1%85%A7%E1%86%AB%2011%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%86%E1%85%A5%E1%84%8A%E1%85%B3%E1%86%A8%E1%84%8B%E1%85%B5-49.png)
 
![줌 배경화면 11월 머쓱이-50.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/4a93488e-135d-4ad0-b159-84f2b92ed124/%E1%84%8C%E1%85%AE%E1%86%B7%20%E1%84%87%E1%85%A2%E1%84%80%E1%85%A7%E1%86%BC%E1%84%92%E1%85%AA%E1%84%86%E1%85%A7%E1%86%AB%2011%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%86%E1%85%A5%E1%84%8A%E1%85%B3%E1%86%A8%E1%84%8B%E1%85%B5-50.png)
 
![줌 배경화면 11월 머쓱이-51.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/7b5165f0-9239-4d83-bfbf-28bf91c650f1/%E1%84%8C%E1%85%AE%E1%86%B7%20%E1%84%87%E1%85%A2%E1%84%80%E1%85%A7%E1%86%BC%E1%84%92%E1%85%AA%E1%84%86%E1%85%A7%E1%86%AB%2011%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%86%E1%85%A5%E1%84%8A%E1%85%B3%E1%86%A8%E1%84%8B%E1%85%B5-51.png)
 
더 많은 줌 배경화면은 아래 링크에서 확인 가능합니다.
👉 [**머쓱이 줌 배경화면 다운받기**](https://prgrms.notion.site/zip-1993e47046bf80629692c4ddef6a01bf)

머쓱이 11월 캘린더 & 줌 배경화면 무료 배포 💻

AI 시대가 도래하며 단순 반복적인 코딩 작업이 자동화되었고, 이에 따라 개발자의 역할도 빠르게 변화하고 있습니다. 이 변화 속에서 AI를 도구로 적극 활용하는 개발자는 더 높은 생산성과 창의성을 발휘할 수 있습니다. 오늘 포스팅에서는 변화의 흐름 속에서, AI와 공존하며 개발자로서 성장하고 살아남는 방법을 탐색해보겠습니다.
 
# AI 시대 살아남기
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/df767892-2743-43d1-aaec-d8ec62a218f6/image.png)
 
"가장 강한 자가 살아남는 것이 아니라, 가장 잘 적응하는 자가 살아남는다." -찰스 다윈
 
자연의 생태계에서 새로운 포식자가 등장하면, 다른 종들은 두 가지 중 하나를 선택합니다: 도망치거나, 적응하거나. AI라는 새로운 '종'이 디지털 생태계에 등장한 지금, 우리도 유사한 선택의 기로에 서 있습니다. 일부 개발자들은 AI가 접근하기 어려운 틈새 분야로 도피하는 전략을 택하고 있지만, 더 현명한 접근법은 AI와의 공생 관계를 발전시키는 것입니다.
 
2023년 3월, GitHub의 Copilot이 정식 출시된 지 불과 9개월 만에 사용자 수 100만 명을 돌파했다는 소식이 들려왔습니다. 같은 해 11월에는 Amazon의 Q가 개발자 어시스턴트로 등장했고, 2024년 초에는 OpenAI의 GPT-4와 Google의 Gemini, Anthropic의 출시로 코드 생성과 디버깅 역량을 급격히 향상시켰습니다. 이러한 변화는 갑작스럽게 느껴졌지만, 사실 인공지능의 물결은 수년 전부터 서서히 밀려오고 있었습니다.
 
마치 지진계가 미세한 진동을 감지하듯, 일부 개발자들은 이미 몇 년 전부터 이 변화의 조짐을 느끼고 있었습니다. 단순 반복적인 코딩 작업이 자동화되기 시작했고, Stack Overflow에서 쉽게 찾을 수 있는 문제들은 AI가 더 빠르게 해결하기 시작했습니다. 지금 우리는 역사적인 변곡점에 서 있습니다. 1990년대 웹의 등장이나 2000년대 후반 스마트폰 혁명처럼, **AI는 개발 생태계를 근본적으로 재편**하고 있습니다.
 
이런 상황에서 많은 개발자들이 불안해하는 것은 당연합니다. "AI가 내 일자리를 빼앗을까?", "10년 후에도 개발자라는 직업이 존재할까?", "지금 배우고 있는 기술이 미래에도 가치가 있을까?" 이런 질문들이 우리의 마음속에 맴돌고 있습니다.
 
그러나 역설적이게도, AI 시대는 개발자에게 위기인 동시에 전례 없는 기회이기도 합니다. 역사를 돌이켜보면, 새로운 기술의 등장은 항상 일부 직업을 소멸시켰지만, 동시에 더 많은 새로운 역할을 창출해왔습니다. 19세기 산업혁명이 수공업자를 위협했지만 결국 더 많은 새로운 직종을 만들어낸 것처럼, AI 혁명도 우리에게 새로운 가능성의 세계를 열어줄 것입니다.
 
문제는 "AI가 개발자를 대체할 것인가?"가 아니라, "**어떤 개발자가 AI 시대에 번영할 것인가**?"입니다. 오늘은 빠르게 변화하는 AI 기술 환경에서 개발자가 적응하고 성장하기 위한 실용적인 전략을 탐색해보겠습니다.
 
# AI와 친해지기
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/2ca27aa4-43ea-4f73-b970-7d3058654b77/image.png)
 
새로운 친구를 사귈 때처럼, AI 도구들과도 먼저 친해지는 시간이 필요합니다. 이 과정에서 **각 도구의 성격, 강점, 그리고 한계를 자연스럽게 파악**할 수 있게 됩니다. 처음에는 간단한 질문이나 작업으로 대화를 시작하고, 점차 복잡한 요청으로 확장해가며 도구의 반응과 능력을 관찰해보세요. 마치 새로운 친구와 대화하듯, 다양한 주제와 접근 방식으로 AI와 소통하면서 관계를 구축해 나가는 것이 효과적입니다. 이런 친밀감 형성 과정은 나중에 실제 프로젝트에서 AI 도구를 더 효율적으로, 그리고 창의적으로 활용할 수 있는 기반이 됩니다.
 
* GitHub Copilot, Amazon CodeWhisperer, Tabnine 등의 코드 생성 도구
* ChatGPT, Claude, Gemini 같은 대화형 AI 모델
* Whisper AI, Anthropic's Claude, Replit의 Ghostwriter 등 특화된 AI 도구
 

중요한 것은 이러한 도구들을 단순히 사용해보는 것을 넘어, 그들의 강점과 한계를 체계적으로 탐색하는 것입니다. 직접 다양한 시나리오에서 AI 도구를 테스트해보면서 패턴을 발견해보세요. 예를 들어, AI는 보일러플레이트 코드 생성, API 클라이언트 구현, 간단한 알고리즘 작성에 뛰어난 성과를 보이는 반면, 복잡한 비즈니스 로직, 분산 시스템 설계, 성능 최적화 같은 영역에서는 아직 부족한 모습을 보일 때가 있습니다.
 
특히 **AI가 제안한 코드가 실제로 동작하는지, 효율적인지, 보안 취약점은 없는지 검증하는 습관**을 들이는 것이 중요합니다. 실무에서 보면 AI가 자신 있게 제시한 해결책을 그대로 받아들였다가 나중에 심각한 문제를 발견하는 개발자들이 많습니다. AI는 때로 존재하지 않는 API나 라이브러리를 참조하거나, 최신 개발 흐름에 뒤처진 오래된 프로그래밍 패턴을 제안하기도 합니다. 결국 AI의 제안을 개발자의 경험과 지식으로 한번 걸러내는 과정이 필수적입니다.
 
각 AI 도구마다 특화된 영역도 파악해두면 좋습니다. 예를 들어, GitHub Copilot은 리포지토리 컨텍스트를 이해하는 데 뛰어나고, ChatGPT는 개념 설명과 코드 리팩토링에 도움이 되며, Claude는 긴 문서와 코드 분석에 강점이 있습니다. 이러한 특성을 알고 **적절한 상황에 맞는 도구를 선택하는 것이 효율적인 AI 활용의 핵심**입니다.
 
# AI에게 효과적으로 질문하기
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/ec8fda16-ae11-4beb-a1ec-7bea9ab3ebde/image.png)

현대 개발자에게 AI는 일종의 슈퍼파워가 될 수 있습니다. 오늘날의 AI 코딩 도구들은 단순한 자동 완성 기능을 넘어섰습니다. 이들은 개발자의 생각을 코드로 변환해주는 통역사이자, 새로운 해결책을 제안하는 협업 파트너로 진화했습니다. 2023년 GitHub 연구에 따르면, Copilot을 사용하는 개발자들은 반복적인 작업 시간을 크게 줄이고, 더 창의적이고 도전적인 문제 해결에 집중할 수 있게 되었다고 합니다.
 
핵심은 AI를 단순한 코드 생성기가 아닌, 사고를 확장해주는 도구로 바라보는 관점의 전환입니다. AI에게 그저 "이 기능 만들어줘"라고 요청하기보다는, "이 문제에 대한 여러 접근 방식을 알려줘" 또는 "이 코드의 성능을 높일 방법이 있을까?"와 같이 질문해보세요.
 
#### 비효율적인 프롬프트 예시
```
# "사용자 인증 기능을 만들어줘"
```
 
#### 효과적인 프롬프트 예시
```
# "JWT를 사용한 사용자 인증 시스템이 필요해. 보안 모범 사례를 따르면서,
# 토큰 갱신, 비밀번호 리셋, 다중 기기 지원 기능이 포함되어야 해.
# Node.js Express 환경에서 구현할 거고, MongoDB를 데이터베이스로 사용해.
# 구현 방식에 대한 여러 대안과 각각의 장단점도 설명해줘."
```
 
AI 도구를 잘 활용하는 것은 단순히 프롬프트 작성법을 배우는 것 이상의 의미가 있습니다. 이는 새로운 사고방식을 개발하는 과정이며, 인간과 AI의 강점을 서로 보완하는 협업 모델을 구축하는 여정입니다.
 
# 중요해진 개발자의 판단력
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/a8b35965-300b-42d6-abcd-8859c362c91d/image.png)
 
현재의 AI 모델은 놀라운 능력을 보여주지만, 여전히 명확한 한계가 있습니다. 이러한 한계를 제대로 이해하는 것이 AI 시대의 개발자에게는 중요한 경쟁력이 됩니다.
 
AI 코딩 도구의 주요 한계 중 하나는 '환각(hallucination)' 현상입니다. AI는 때때로 실제로 존재하지 않는 함수나 라이브러리를 마치 있는 것처럼 참조하거나, 잘못된 API 사용법을 제안하기도 합니다. 또한 AI는 코드의 표면적인 정확성은 검증할 수 있지만, 비즈니스 로직의 깊은 맥락이나 시스템 간의 복잡한 상호작용을 완전히 이해하지는 못합니다.
 
**경험 많은 개발자는 AI가 제안한 솔루션을 비판적인 시각으로 검토하고, 잠재적인 문제점을 찾아내며, 필요한 부분을 수정**할 수 있습니다. 이것이 바로 AI가 쉽게 대체할 수 없는 '개발자의 판단력'입니다.
 
도메인 지식과 기술적 직관은 AI가 아직 완전히 모방하기 어려운 영역입니다. AI는 일반적인 모범 사례를 학습할 수 있지만, 특정 조직의 기술 스택과 코딩 문화에 맞춰진 솔루션을 자동으로 제공하기는 어렵습니다. 또한 코드의 장기적인 유지보수성이나 확장성과 같은 비기능적 요구사항을 완전히 고려하지 못할 수 있습니다.
 
결국 AI와 개발자의 관계는 경쟁이 아닌 상호보완적입니다. **AI는 반복적인 코딩 작업을 자동화하고, 개발자는 AI가 놓칠 수 있는 맥락과 복잡성을 추가하며 최종 결정**을 내립니다. 미래의 최고 개발자는 AI의 한계를 명확히 인식하고, 이를 자신의 강점으로 보완하는 사람이 될 것입니다.
 
# AI가 만든 코드를 평가하는 것
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/9dda02f5-6c3e-4f3d-b42c-6e2846cf9af1/image.png)
 
개발자로서 우리의 역할은 점점 더 '큐레이터'에 가까워지고 있습니다. AI가 제시하는 다양한 선택지 중에서 최적의 해결책을 고르고, 이를 더 큰 시스템과 잘 어울리게 통합하는 능력이 중요해지고 있습니다. 이는 단순한 코드 작성 능력을 넘어 **아키텍처적 사고, 시스템 설계, 그리고 엔지니어링 판단력**을 필요로 합니다.
 
1. 비즈니스 요구사항을 정확히 충족하는가?
2. 예외 상황을 적절히 처리하는가?
3. 보안 취약점은 없는가?
4. 확장성을 고려했는가?
5. 유지보수가 용이한 구조인가?
6. 팀의 코딩 표준과 아키텍처에 부합하는가?
 

이러한 체크리스트는 AI가 생성한 코드를 평가하는 데 도움이 될 뿐만 아니라, 우리가 직접 작성하는 코드의 품질을 높이는 데도 유용합니다. 결국 코드 품질에 대한 최종 책임은 여전히 개발자에게 있으며, AI는 그 과정을 돕는 도구일 뿐입니다.
 
이런 관점에서 개발자는 AI 시대에도 여전히 코드의 최종 관리자이자 품질 보증자로서 핵심적인 역할을 수행합니다. **AI가 초안을 빠르게 생성할 수 있더라도, 그 코드가 실제 환경에서 안정적으로 작동하고 장기적으로 유지보수 가능한지 판단하는 것은 개발자의 몫**입니다. 깊은 도메인 지식과 시스템적 사고를 바탕으로 AI가 제안한 솔루션을 비판적으로 검토하고 필요에 따라 조정하는 능력이 미래 개발자의 가치를 결정할 것입니다.
 
# 변화를 두려워하지 않는 마음가짐
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/bd7298de-d16f-40bd-ba02-c5b79adeae59/image.png)
 
처음 프로그래밍을 배우던 때를 기억하시나요? 모든 것이 낯설고, 때로는 좌절스러웠지만, 한 줄의 코드가 실행되는 순간의 그 짜릿함과 성취감을 위해 계속해서 도전했던 시간들. 개발자로서의 여정은 실은 그 첫 경험의 연장선입니다. 새로운 언어나 프레임워크를 접할 때마다 우리는 다시 '초보자'의 마음으로 돌아가게 됩니다.
 
이런 '초보자 마인드'는 단점이 아닌 강점이 될 수 있습니다. 선입견 없이 새로운 기술을 바라보고, 실험하고, 실패하고, 배우는 과정 자체를 즐길 수 있다면, 기술의 변화는 두려움의 대상이 아닌 흥미로운 모험이 됩니다.
 
저도 처음 TypeScript를 접했을 때는 '왜 이런 복잡한 타입 시스템이 필요할까?'라는 의문이 들었습니다. JavaScript만으로도 충분하다고 생각했죠. 하지만 호기심으로 작은 프로젝트에 적용해보면서 점차 그 가치를 이해하게 되었고, 지금은 대부분의 프로젝트에서 TypeScript를 활용하고 있습니다. 새로운 기술을 거부하는 대신 실험해 본 결정이 제 개발 여정에 큰 전환점이 되었습니다.
 
# 두려움에서 가능성으로
AI가 가져올 미래에 대한 불안감은 자연스러운 반응입니다. 하지만 역사를 보면 새로운 기술이 일자리를 없애기보다는 변화시켜왔음을 알 수 있습니다. 웹 개발이 등장했을 때 많은 전통적인 프로그래밍 직종이 변화했지만, 결과적으로는 더 많은 개발자 일자리가 만들어졌습니다.
 
AI 시대의 개발자는 단순한 코드 작성자가 아닌, **복잡한 시스템의 설계자, AI 도구의 지휘자, 그리고 기술과 사람 사이의 중재자로 진화**할 것입니다. 우리의 가치는 점점 더 "얼마나 많은 코드를 작성할 수 있는가"보다 "어떤 문제를 해결할 수 있는가"에서 찾아질 것입니다.
 
중요한 것은 두려움에 압도되지 않고, **호기심과 열린 마음을 유지**하는 것입니다. AI를 위협으로만 볼 것인지, 아니면 우리의 창의성과 문제 해결 능력을 확장시켜주는 도구로 볼 것인지는 우리의 선택입니다.
 
지금 이 순간, 디지털 생태계의 큰 변화 속에서, 우리는 선택의 기로에 서 있습니다. 변화를 두려워하고 과거의 방식만 고수할 수도 있고, 변화를 받아들이고 새로운 가능성을 탐색할 수도 있습니다. 현명한 개발자는 후자를 선택할 것입니다.
 
변화의 물결 위에서 균형을 잃지 말고, 호기심과 배움의 자세로, 기술적 전문성과 인간만의 통찰력을 결합하여 AI와 함께 발전하는 법을 배워나갑시다. 
 
 
![고코더 작가님 프로필 카드.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/6116b2c9-692a-437c-918d-22b5990e917e/%E1%84%80%E1%85%A9%E1%84%8F%E1%85%A9%E1%84%83%E1%85%A5%20%E1%84%8C%E1%85%A1%E1%86%A8%E1%84%80%E1%85%A1%E1%84%82%E1%85%B5%E1%86%B7%20%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%84%91%E1%85%B5%E1%86%AF%20%E1%84%8F%E1%85%A1%E1%84%83%E1%85%B3.png)

AI 시대의 개발자: 살아남을 것인가 도망칠 것인가

열심히 일했는데도 성과를 제대로 설명하지 못해 답답했던 적 있으신가요? 시니어 개발자 고코더 님은 개발자가 자신의 기여를 더 명확하게 전달하는 방법으로 '숫자로 말하기'를 제안합니다. 코드가 아닌 지표로 성과를 표현하는 법부터, 실무에서 바로 적용할 수 있는 구체적인 방법까지 이 글에서 확인해보세요. 
 
 
## 성과를 갈라놓는 단 하나의 차이, 숫자
![스크린샷 2026-03-25 오후 1.25.28.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/4cc3f393-746a-4764-a83d-817d6caa887d/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202026-03-25%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%201.25.28.png)
(이미지 출처: 픽사베이)
 
"열심히 했는데 왜 아무도 몰라주지?"
 
평가를 위해 지난 한 해 성과를 정리하려고 빈 문서를 열면, 막막해지는 개발자들이 꽤 있습니다. 복잡한 기능을 혼자 다 구현했고, 팀에서 제일 많이 커밋했습니다. 그런데도 막상 평가 자리에 서면 왠지 할 말이 없어집니다. "열심히 했습니다"라는 말 외에는 딱히 떠오르는 게 없거든요.
 
반면 같은 팀의 A씨는 평가 때마다 술술 말합니다. "API 응답 속도를 40% 개선했고, 이로 인해 장바구니 이탈률이 15% 줄었습니다." 코드를 더 많이 짠 것도 아닌데, 왜 A씨의 성과는 선명하게 들릴까요?
 
차이는 코드가 아니라 언어에 있습니다. 정확히는 숫자에 있습니다.
 
 
## 개발자는 왜 숫자로 말하기 어려울까
개발자는 본질적으로 코드로 생각합니다. 문제를 발견하고, 해결하고, 다음 문제로 넘어가는 것이 일상입니다. 그 과정에서 "내가 얼마나 기여했는지"를 측정하는 습관을 들이는 사람은 많지 않습니다. 일 자체가 바쁘고, 측정은 왠지 내 일이 아닌 것 같고, 그냥 다음 티켓을 잡는 게 더 자연스럽습니다.
 
게다가 개발 성과는 눈에 띄지 않습니다. 영업사원은 매출이라는 명확한 숫자가 있고, 마케터는 전환율이 있습니다. 그런데 개발자는? "이 기능 만들었습니다"라고 말할 수는 있지만, 그게 얼마나 중요한 일인지는 듣는 사람이 판단하기 어렵습니다.
 
저도 입사 초기에는 그랬습니다. 몇 달을 달려서 코드를 리팩토링했는데, 성과 평가 때 팀장이 "어떤 성과가 있었나요?"라고 물었습니다. 저는 "코드가 훨씬 깔끔해졌고, 유지보수가 쉬워졌습니다"라고 답했습니다. 팀장은 고개를 끄덕였지만, 그 표정에서 뭔가 아쉬움이 느껴졌습니다. 나중에야 깨달았습니다. 팀장이 듣고 싶었던 건 "깔끔해졌다"가 아니라, 그 깔끔함이 만들어낸 구체적인 변화였다는 것을요.
 
그래서 많은 개발자들이 성과를 이렇게 표현합니다.
* **"검색 기능을 최적화했습니다."**
* **"레거시 코드를 리팩토링했습니다."**
* **"버그를 여러 건 수정했습니다."**

 
틀린 말은 아닙니다. 하지만 이 문장들은 팀장도, 인사팀도, 심지어 본인도 나중에 잘 기억하지 못합니다. 인상에 남지 않으니까요. 기억에 남는 성과는 항상 숫자와 함께 옵니다.
 
 
## 한 줄의 숫자가 열 줄의 설명보다 낫다
같은 성과를 다르게 표현해 볼게요.
 
* **"검색 기능을 최적화했습니다."**
* **"검색 응답 속도를 3.2초에서 0.8초로 줄였습니다. 이후 검색 이용률이 한 달 만에 22% 늘었고, 검색 후 구매 전환율도 8%p 상승했습니다."**

 
두 번째 문장을 읽으면 뭔가 다르게 느껴집니다. 갑자기 이 사람이 무슨 일을 했는지, 그게 얼마나 의미 있는 일인지가 확 와닿습니다. 듣는 사람 입장에서 그림이 그려지기 때문입니다.
 
숫자는 추상적인 작업을 구체적인 현실로 바꿔줍니다. 코드는 개발자만 이해하지만, 숫자는 누구나 이해합니다. 팀장도, 비개발자 임원도, 이직할 회사의 면접관도요. 
 
또 한 가지 중요한 점이 있습니다. 숫자는 기억에 오래 남습니다. "리팩토링 잘 했다"는 말은 다음 달이면 희미해지지만, "배포 시간을 12분에서 3분으로 줄였다"는 1년 뒤에도 선명합니다. 성과는 기록이 아니라 인상으로 남기 때문에, 숫자가 있는 성과와 없는 성과는 시간이 지날수록 격차가 벌어집니다.
 
 
## 개발자가 활용할 수 있는 숫자의 종류
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/b8bd1492-361c-49c7-bb10-c4b5a34b56c7/image.png)
(이미지 출처: 픽사베이)
 
숫자로 성과를 표현하는 것이 처음에는 막막하게 느껴질 수 있습니다. "우리 일이 어떻게 숫자로 나와?" 싶기도 하죠. 하지만 생각보다 개발 업무에는 숫자로 표현할 수 있는 부분이 많습니다. 크게 네 가지 영역으로 나눠볼 수 있습니다.
 
 
### 첫 번째, 속도와 성능입니다.
가장 쉬운 출발점입니다. API 응답 시간, 페이지 로딩 속도, 쿼리 실행 시간, 빌드 시간 같은 것들은 Before/After가 명확하게 나옵니다. 최적화 작업을 했다면 반드시 측정하고 기록해두세요. 크롬 개발자 도구, Lighthouse, APM 도구 어느 것이든 스크린샷 하나가 나중에 큰 역할을 합니다.
 
예를 들면 이런 식입니다. "메인 페이지 LCP를 4.8초에서 1.9초로 개선했습니다." "주문 처리 API 평균 응답 시간을 230ms에서 80ms로 줄였습니다." 이런 숫자들은 작업 당시에 측정해두지 않으면 나중에 복원하기 어렵습니다.
 
### 두 번째, 오류와 안정성입니다.
에러율을 몇 퍼센트 줄였는지, 장애 발생 횟수가 어떻게 바뀌었는지, 테스트 커버리지를 얼마나 높였는지 모두 숫자가 될 수 있습니다. "Sentry 오류 발생 건수를 월 1,200건에서 300건으로 줄였습니다"라는 문장은 그 어떤 설명보다 강력합니다. 안정성은 개발자 입장에서는 당연한 것처럼 느껴지지만, 비즈니스 관점에서는 매우 중요한 지표입니다.
 
테스트 코드를 작성했다면 커버리지 수치를 기록해두세요. "테스트 커버리지를 18%에서 62%로 높였습니다"라는 문장은 단순한 숫자가 아니라 팀 전체의 코드 신뢰도가 높아졌다는 신호입니다.
 
### 세 번째, 시간 절감입니다.
이 부분은 특히 임팩트가 큽니다. 자동화 스크립트 하나로 매주 3시간씩 걸리던 반복 작업을 없앴다면, 연간 150시간을 절약한 겁니다. 팀원이 5명이라면 750시간입니다. 이건 꽤 인상적인 숫자입니다.
 
CI/CD 파이프라인을 개선해서 배포 시간을 줄였다면, 그것도 마찬가지입니다. 하루에 세 번 배포하는 팀에서 배포 한 번에 10분씩 줄었다면 한 달이면 900분, 15시간입니다. 단순한 파이프라인 개선이 아니라 팀 생산성에 직결되는 이야기가 됩니다.
 
### 네 번째, 비즈니스와 사용자 지표입니다.
가장 설득력이 강한 숫자입니다. 내가 만든 기능이 전환율, 이탈률, 재방문율, 결제 완료율 같은 지표에 어떤 영향을 줬는지 연결할 수 있다면, 그 성과는 개발팀을 넘어 회사 전체가 이해하는 언어로 말해지는 것입니다.
 
이 숫자를 얻으려면 기획팀이나 데이터팀과 소통이 필요합니다. "제가 작업한 기능 배포 이후 지표 변화를 확인하고 싶은데, 데이터 공유 가능한가요?"라고 물어보는 것만으로도 시작할 수 있습니다. 처음엔 어색하더라도 이 습관이 쌓이면 개발자로서의 비즈니스 감각도 자연스럽게 길러집니다.
 
 
## 숫자가 없을 때는 어떻게 하나요?
"저는 내부 도구만 만들어서 수치가 없어요"라고 하시는 분들이 있습니다. 혹은 유지보수 업무가 많아서 새로 만든 게 없다거나, 데이터 접근 권한이 없다거나요. 이런 경우에도 방법은 있습니다.
 
### 규모를 보여주세요.
레거시 코드 리팩토링"이라고 쓰는 것보다 "5년 된 레거시 코드 약 1만 2천 줄을 정리해 모듈 의존성을 절반으로 줄였습니다"가 훨씬 구체적입니다. 코드 줄 수, 파일 수, 의존성 수, 관련된 기능의 수 같은 것들이 모두 규모를 나타내는 숫자입니다.
 
### 횟수와 빈도를 활용하세요.
 "코드 리뷰를 적극적으로 했습니다" 대신 "분기 동안 팀원 PR을 45건 리뷰하고, 평균 24시간 이내에 피드백을 남겼습니다"처럼 쓸 수 있습니다. 꼼꼼한 리뷰어가 팀에 얼마나 중요한지는 다들 알고 있지만, 숫자로 보여주면 그 무게감이 달라집니다.
 
### 비교를 만들어내세요.
이전에 얼마나 걸렸고, 지금은 얼마나 걸리는지. 이전에 버그가 몇 건이었고, 지금은 몇 건인지. 숫자가 없는 게 아니라 아직 측정하지 않은 것일 수 있습니다. 지금이라도 기준점을 만들어두면 3개월 뒤에는 비교가 가능해집니다.
 
### 팀의 임팩트로 환산하세요.
개인 성과가 눈에 잘 안 보일 때는 팀 단위로 생각해 보는 것도 방법입니다. 내가 구축한 공통 컴포넌트가 팀 전체에서 몇 번 재사용됐는지, 내가 작성한 문서가 신입 온보딩 시간을 얼마나 줄였는지 같은 것들입니다. 직접적인 숫자가 없더라도 "팀 6명이 이 컴포넌트를 사용하고 있습니다"는 충분히 설득력 있는 표현입니다.
 
 
## 숫자가 거짓말이 되지 않으려면
한 가지 주의할 점이 있습니다. 숫자를 강조하다 보면 과장이나 왜곡이 생기기 쉽습니다. 내 기여가 10%인데 마치 전부인 것처럼 말하거나, 외부 요인으로 좋아진 지표를 내 성과인 양 내세우는 경우입니다.
 
이런 함정을 피하는 방법은 맥락을 함께 제시하는 것입니다. "전환율이 8%p 상승했습니다"보다 "결제 플로우 개선 후 전환율이 8%p 상승했으며, 같은 기간 마케팅 캠페인도 진행됐습니다"가 더 신뢰할 수 있는 표현입니다. 완벽하게 격리된 성과는 현실에서 드뭅니다. 겸손하게 맥락을 인정하면서도 내 기여를 명확히 하는 것이 장기적으로 신뢰를 쌓는 방법입니다.
 
또 한 가지, 숫자만 좋고 내용이 없는 경우도 위험합니다. 응답 속도를 줄이기 위해 캐시를 무분별하게 사용해서 데이터 정합성 문제가 생겼다거나, 커버리지를 높이기 위해 의미 없는 테스트 코드를 양산했다거나 하는 경우입니다. 숫자는 수단이지 목적이 아닙니다. 숫자 뒤에 진짜 가치가 있어야 합니다.
 
 
## 이직할 때도, 평가받을 때도, 결국 숫자가 남는다
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/01d6d6f2-fdf7-4c31-bb65-e92fcb01ec95/image.png)
(이미지 출처: 픽사베이)
 
성과 평가만의 이야기가 아닙니다. 이직을 준비할 때 이력서를 쓰면 이 차이가 더 극명하게 드러납니다.
 
* **"대규모 트래픽 서비스 개발 경험 있음"**
* **"월 활성 사용자 80만 명 규모의 서비스에서 결제 모듈 개발 및 운영, 연간 거래 처리 건수 약 600만 건"**

 
면접관 입장에서 어느 쪽이 더 눈에 들어올지는 말하지 않아도 알 수 있습니다. 숫자가 없는 이력서는 묘사가 없는 소설처럼 느껴집니다. 상상할 수는 있지만 확신이 서지 않습니다.
 
실제로 이직 시장에서 경쟁력 있는 개발자들을 보면 공통점이 있습니다. 자신이 했던 일을 언제나 숫자와 함께 말합니다. 처음부터 그랬던 게 아니라, 일하면서 꾸준히 기록하는 습관이 몸에 밴 것입니다.
 
 
## 지금 당장 할 수 있는 한 가지
![39049.jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/a5b9e83b-0744-4482-96d3-7f1ca5a93983/39049.jpg)
(이미지 출처: Freepik)
 
숫자로 말하는 습관은 성과 평가 직전에 갑자기 만들어지지 않습니다. 일하면서 꾸준히 기록해두는 것이 핵심입니다. 노션이든 메모장이든 상관없습니다. 작업을 마칠 때마다 짧게 이렇게 적어두세요.
 
<div style="border-radius: 4px;padding:22px 20px; background: #F5F5F5; display: flex;">🔖오늘 한 일: 주문 목록 API 응답 속도 개선 / Before: 평균 1.8s -> After: 평균 0.4s / 개선 방법: N+1 쿼리 제거 및 인덱스 추가</div>

 
한 줄이면 충분합니다. 이게 3개월 쌓이면 성과 평가 자료가 되고, 6개월 쌓이면 이직할 때 쓸 이력서 소재가 됩니다. 1년이 지나면 자신이 얼마나 성장했는지를 숫자로 확인할 수 있습니다.
 
처음에는 측정하는 게 번거롭게 느껴질 수 있습니다. "이걸 꼭 해야 하나" 싶기도 하죠. 하지만 측정하지 않은 성과는 서서히 사라집니다. 6개월 전에 한 작업이 정확히 얼마나 개선됐는지 기억하는 사람은 거의 없습니다. 기록만이 그 기억을 붙잡아둘 수 있습니다.
 
열심히 일하고도 인정받지 못한다고 느끼는 개발자들의 공통점은 일을 못한 게 아니라 기록하지 않았다는 것입니다. 코드는 리포지토리에 남지만, 그 코드가 만들어낸 가치는 기록하지 않으면 사라집니다.
 
오늘 마무리한 작업 하나를 꺼내서 숫자로 바꿔보세요. "이걸 했습니다"가 아니라 "이만큼 달라졌습니다"로 바꾸는 연습입니다. 생각보다 어렵지 않고, 해보면 뿌듯합니다. 그리고 그 뿌듯함이 쌓이면, 어느 순간 평가 자리에서 할 말이 넘쳐나는 개발자가 되어 있을 겁니다.
 
 
### 📌 함께 읽으면 좋은 글
* [AI 시대, 신입 개발자가 실력을 키우는 법](https://community.programmers.co.kr/post/13432?utm_source=&utm_medium=&utm_campaign=&utm_content=gocoder_13432)
* [개발자의 커리어 연말정산: 내 성장을 측정하는 법](https://community.programmers.co.kr/post/13268?utm_source=&utm_medium=&utm_campaign=&utm_content=gocoder_13268)
* [개발자가 알아야 할 질문의 기술](https://community.programmers.co.kr/post/13102?utm_source=&utm_medium=&utm_campaign=&utm_content=gocoder_13102)
 
 

![고코더 작가님 프로필 카드.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/c227824e-8b30-4bd8-b5a3-233a53dc4546/%E1%84%80%E1%85%A9%E1%84%8F%E1%85%A9%E1%84%83%E1%85%A5%20%E1%84%8C%E1%85%A1%E1%86%A8%E1%84%80%E1%85%A1%E1%84%82%E1%85%B5%E1%86%B7%20%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%84%91%E1%85%B5%E1%86%AF%20%E1%84%8F%E1%85%A1%E1%84%83%E1%85%B3.png)

개발자가 숫자로 말해야 하는 이유

안녕하세요. 저는 그렙에서 플랫폼 개발을 담당하고 있는 4년차 프론트엔드 개발자 딜런(Dylan)입니다.
[지난 글](https://community.programmers.co.kr/post/13201?utm_source=&utm_medium=&utm_campaign=&utm_content=greppdev_13201)에서는 Web Components와 Lit을 활용해 크로스 프레임워크 컴포넌트를 구현할 수 있는 기술적 가능성을 살펴보았는데요.
이를 **실제 서비스 페이지에 적용해보는 PoC 진행 과정**과 결과를 통해 얻은 인사이트를 이어서 공유해보겠습니다.
 
 
## PoC 도전
충분한 리서치를 한 후 본격적으로 PoC에 돌입했습니다. 목표는 Lit 개발 환경을 구성한 후, 실제 제품에서 자주 사용 되는 **버튼**(`prgms-button`)과 **모달**(`prgms-modal`)을 만들어보고, 이를 **React, Vue, Rails, 순수 HTML 환경에서 모두 사용해보는 것**으로 잡았습니다.
 
PoC의 전체적인 아키텍처 구조는 다음과 같았습니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/593d013d-8863-473f-8854-61b101645782/image.png)
 
- **스타일:** Tailwind CSS + Daisy UI 플러그인 적용하여 생산성을 높였습니다.
- **클래스 네임 분기:** CVA 라이브러리를 적용하여 컴포넌트의 프로퍼티에 따라 클래스 네임을 분기하기 쉽게 하였습니다.
- **React / Vue:** `@lit/react` 라이브러리와 `@custom-elements-manifest/analyzer` 라이브러리를 적용하여 React 및 Vue에서 Web Components를 원활하게 사용할 수 있도록 돕는 React 래퍼 컴포넌트와 Vue 타입 앰비언트를 자동으로 생성하게 했습니다.
- **개발환경:** Storybook을 적용하여 실제 컴포넌트 화면을 보면서 개발할 수 있도록 하였습니다.

 
특히 Storybook 환경에서 Lit 컴포넌트를 개발하는 과정은 매우 만족스러웠습니다. 코드 저장 시 즉시 화면에 반영되는 HMR 환경에서, 결과를 빠르게 확인하며 개발할 수 있었기 때문입니다. 또한 Storybook이 갖춘 풍부한 생태계 덕분에, 추후 시각적 테스트나 Chromatic 기반의 시각 회귀 테스트 등 다양한 확장이 가능한 구조였습니다. 이러한 점에서, 초기 PoC를 넘어 이후 단계에서의 고도화까지도 좋은 환경이라 판단했습니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/02b1b40a-89ea-4c23-b820-dab118f9d937/image.png)
 
 
## 실사용 테스트
PoC의 핵심은 ‘하나의 컴포넌트로 정말 모든 기술 스택에서 사용할 수 있는가?’였습니다.
 
그래서 실제 저희 제품 중 **Vue 기반 페이지**, **React 기반 페이지**, **Rails 기반 SSR 페이지**를 하나씩 선정하고 다음과 같이 `prgms-button`과 `prgms-modal`을 사용해보았습니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/d6ef3cf5-1bc1-46d7-8c2c-1d402221cbd8/image.png)
 
결과는 성공적이었습니다.
- Vue에서는 커스텀 엘리먼트를 사용하면 프롭 및 이벤트 매핑이 자연스럽게 동작했으며
- React에서는 래퍼 컴포넌트를 통해 커스텀 엘리먼트에 안정적으로 프롭 전달이 가능했으며
- Rails SSR(HTML)에서는 일반적인 HTML 태그와 마찬가지로 커스텀 엘리먼트 사용이 가능했습니다.

즉, **Lit 컴포넌트 하나로 모든 스택에서 동일하게 사용할 수 있다**는 점을 분명하게 확인했습니다.
 
 
## PoC에서 확인한 Web Components의 장점
PoC 결과를 통해 Web Components가 가진 다음과 같은 장점을 체감할 수 있었습니다.
 
### 생산성 향상
Lit 컴포넌트 하나만 개발하면, 정말로 React, Vue, Rails, HTML 환경에서 모두 동일하게 사용할 수 있었습니다. 이렇게만 개발한다면, 더 이상의 중복 구현이 발생하지 않을 것이기에 개발 효율의 극대화를 기대할 수 있었습니다.
 
### 스타일 일관성 향상
Shadow DOM 덕분에 컴포넌트 내부 스타일이 완전히 캡슐화되어, 외부 영향으로부터 독립되는 것을 확인했습니다.
 
실제 프로덕트에서는 페이지 별로 다른 전역 스타일을 갖는 경우가 많습니다. 예를 들면 어떤 페이지에서는 Bootstrap 전역 스타일을 사용할 수 있고, 또 다른 곳에서는 Tailwind CSS의 Preflight 전역 스타일을 사용할 수 있을텐데요. 그런 전역 스타일에 전혀 영향을 받지 않게 되니, 컴포넌트에서 불필요한 스타일 오버라이드를 정의하지 않아도 됩니다.
 
컴포넌트 외부 스타일을 신경쓰지 않으며 개발할 수 있기 때문에, 컴포넌트 자체의 구현에 집중할 수 있었고, 스타일 오작동이 없는 견고한 컴포넌트를 만들 수 있었습니다.
 
### 유지보수성 개선
종류별로 단 하나의 컴포넌트만 개발하면 되기 때문에, 유지보수가 용이해집니다.
 
예를 들어 버튼의 디자인이나 동작에 변경 사항이 발생하더라도, 단순히 `<prgms-button>`컴포넌트 하나만 변경하면 되기 때문에 작업 부담이 매우 적습니다.
 
컴포넌트가 단 하나이기 때문에 일관성이 자동으로 유지되고, UI 품질 관점에서의 사용자 경험도 개선됩니다.
 
 
## 실제 적용을 가로막는 고려사항들
Web Components의 기술적 가능성과 Lit 기반으로 구축한 개발 환경 경험은 매우 만족스러웠습니다. 그런데 실제 서비스 전체로 확장하기 위해 고려해야 할 부분이 예상보다 많았습니다.
 
### ✅ 기술적 차원의 고려사항
#### 1. HTML Form 참여의 한계
Web Components는 기본적으로 `<input>`과 같은 요소와는 달리 네이티브 Form에 데이터를 제출하지 못합니다.
 
예를 들어 다음과 같이 `<prgms-text-input>`이라는 인풋 형태의 커스텀 엘리먼트를 `<form>`의 하위 요소로 두더라도 Form Submit 시에 커스텀 엘리먼트 데이터(value)가 요청 본문에 포함되지 않습니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/2baeda63-86b1-4c92-ad46-2ebe56cccf84/image.png)
 
이는 제품에서 네이티브 Form 기능을 사용해야 하는 경우에 치명적인데요. 사실 `ElementInternals` API를 사용하면 커스텀 엘리먼트도 Form에 정상적으로 참여시킬 수 있습니다. 하지만 웹 브라우저 지원 범위가 충분히 넓지는 않다는 점을 감수해야만 합니다.
 
#### 2. 일부 SSR 환경의 특수한 기능과의 호환성
일부 오래된 라이브러리나 웹 서버의 기능이 잘 호환되지 않을 수 있습니다. 예를 들면 Ruby on Rails에서는 `data-remote`애트리뷰트를 중심으로 Ajax 동작을 구현하는 기능(UJS)이 내재되어 있는데요. 이 기능이 Web Components를 대상으로는 정상적으로 동작하지 않았습니다. 이런 특수한 기능을 사용하고 있다면 Web Components에서도 동작할 수 있도록 별도의 최적화 작업을 해야합니다.
 
#### 3. 프레임워크 별 인터페이스 지향점의 차이
HTML, React, Vue에서 각각 추구하는 컴포넌트의 접근 방법이 다르다는 것은 간과하기 쉬운 문제입니다. 그래서 Web Components를 모든 프레임워크에 맞는 인터페이스로 개발하는 것에는 조금 무리가 있는데요. 드롭다운 형태의 셀렉트 컴포넌트에서 드롭다운의 콘텐츠를 지정하는 방식을 예시로 들어보겠습니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/7f8930b4-8d81-4de7-a4ff-322c797902e3/image.png)
 
HTML에서는 드롭다운의 콘텐츠까지도 모두 HTML요소로 지정하는 것이 일반적입니다. 많은 라이브러리들이 이런 방식을 채택하고 있고, 네이티브 `<select>`, `<option>` 요소도 마찬가지입니다.
 
반면에 React 및 Vue와 같은 SPA에서는 드롭다운의 콘텐츠의 형태가 일관된다면 children 보단 배열 형태의 프롭을 통해 콘텐츠를 지정하는 방법이 널리 사용됩니다.
 
여기서 어느 한 방식이 정답이라고 단정하긴 어렵습니다. 다만 개인적으로는 커스텀 엘리먼트 역시 일반 HTML 요소에 더 가깝다고 생각합니다. 따라서 HTML 표준 요소의 동작 방식에 맞게 설계하고, React나 Vue와 같은 프레임워크의 특성에 맞춘 별도의 래퍼 컴포넌트를 마련하는 것이죠. 다만 이 경우, '한 번만 만들고 어디서든 사용할 수 있다'는 Web Components의 장점이 다소 희석될 수 있다는 아쉬움도 함께 남습니다.
 
 
### ✅ 조직적 차원의 고려사항
앞서 살펴본 것처럼 Web Components는 분명한 장점을 지닌 기술입니다. 하지만 아무리 효율적이고 좋은 기술이라 하더라도, 이를 조직 전체의 표준으로 도입하기 위해서는 다음 사항을 고려해야 합니다.
 
* 모든 제품 사이에서 UI 디자인의 일관성을 충분히 갖추었는가?
* 기존 제품을 유지보수 하는 것보다 새로운 제품을 개발 비중이 더 높지는 않은가? 또한 그 신규 제품들이 기존 제품의 UI 디자인을 계승하는가?
* UI 디자인의 정확한 표준을 정의하고, 이를 모든 제품에 반영할 디자인 및 개발 리소스가 있는가?

 
위 조건 중 하나라도 충족되지 않는다면, 결국 여러 직군의 추가적인 리소스가 투입되어야 하고, 그 비용 역시 결코 작지 않을 것입니다. 특히 조직이 제품 완성도보다 빠른 실행 속도를 우선해야 하는 경우, 이러한 리소스 투입 자체가 큰 부담이 될 수 있습니다. 엄격한 UI 디자인은 제품 개발을 어렵게 만드는 모래주머니처럼 작용할 가능성도 있습니다.
 
 
## 아쉽지만, 지금은 '보류'
세상에 만능 은탄환은 없듯, 모든 기술에는 분명한 트레이드오프가 존재합니다.
이번 PoC에서 Web Components가 기술적으로 충분한 가능성을 지니고 있다는 점은 확인할 수 있었습니다. 다만 조직 구조, 현제 제품 서비스 환경, 그리고 몇 가지 기술적 고려사항을 함께 놓고 판단했을 때, 이 기술을 프로덕트 전반에 즉시 적용하기에는 아직은 신중함이 필요하다는 결론에 이르렀습니다.
 
완벽한 퀄리티보다 빠른 실험과 검증이 더 중요한 시기라면, 프레임워크별로 컴포넌트를 반복적으로 개발하는 방식이더라도 단기적으로는 더 높은 실행력과 성과를 가져올 수 있기 때문입니다.
 
그럼에도 이번 PoC는 동료들의 큰 관심을 이끌어냈고, 기술 공유를 통해 다양한 관점의 피드백을 받을 수 있습니다. 이를 통해 Web Components를 실제 제품에 적용하기 위해 어떤 조건과 준비가 필요한지 더 잘 이해할 수 있었고, 당장은 아니지만 적절한 시점이 오면 실제 적용을 검토할 계획입니다. 그때는 이번 PoC에서 얻은 경험과 인사이트가 중요한 밑거름이 될 것이라 기대하고 있습니다.
 
그래도 이번 도전에서 얻은 결과는 분명했습니다. React, Vue, Rails, HTML처럼 다양한 스택이 공존하는 환경에서도 '한 번 만들고 어디서든 사용하는 컴포넌트'는 불가능한 꿈이 아니라는 것, 그리고 Web Components는 그 꿈에 가장 근접한 현실적 후보라는 것입니다.
 
 
## 마무리하며
이번 글에서는 Web Components라는 기술이 어떻게 크로스 프레임워크 컴포넌트라는 목표를 달성할 수 있는지, 그리고 Lit 기반 PoC를 통해 확인한 경험과 인사이트를 공유했습니다.
 
프론트엔드 생태계는 계속 변화하고 있으며, 우리의 개발 방식도 그 변화 속에서 더 좋은 방향을 찾아가야 합니다. 저는 앞으로도 그렙에서 더 좋은 개발 경험과 UI 퀄리티를 위해 새로운 방법을 탐색하고, 실험하고, 공유하는 문화를 이어갈 것입니다.
 
혹시 여러분께서도 여러 기술 스택이 공존하는 환경에서 일관된 UI 유지에 대한 고민을 하고 있다면, Web Components는 충분히 고려할만한 옵션이 될 것입니다. 내용이 도움이 되었기를 바라며 글을 마치겠습니다. 읽어주셔서 감사합니다.
 
 
글 작성: Dylan (Grepp 프론트엔드 개발자)
 
 
### 📌 함께 읽으면 좋은 글
* [크로스 프레임워크 컴포넌트 개발 도전기 (1): Web Components와 Lit으로 가능성을 검증하다](https://community.programmers.co.kr/post/13201?utm_source=&utm_medium=&utm_campaign=&utm_content=greppdev_13201)
 
 
[![블로그 배너_AI BE.jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/c9bdb6ce-528d-4374-996c-6d0af29beae3/%E1%84%87%E1%85%B3%E1%86%AF%E1%84%85%E1%85%A9%E1%84%80%E1%85%B3%20%E1%84%87%E1%85%A2%E1%84%82%E1%85%A5_AI%20BE.jpg)](https://school.programmers.co.kr/learn/courses/25487?utm_source=mailchimp&utm_medium=DM&utm_campaign=school_25487_blog&utm_content=25487_banner_mkt)

크로스 프레임워크 컴포넌트 개발 도전기 (2): PoC를 통해 발견한 가능성과 한계

도메인 특화 AI 기술 RAG의 성능을 높이는 방법

프로그래머스 백엔드 데브코스 참여 후 지마켓글로벌에 Platform 개발 직무로 입사한 1기 수료생 박건희 님의 인터뷰입니다.
 
 
# 프로그래머스 백엔드 데브코스는 어떻게 알게 되셨나요?
프로그래머스 사이트는 이미 코딩 테스트를 사용하면서 알고 있었는데요. 어느 날 알고리즘 문제를 풀려고 사이트에 접속했다가 모집 중인 공고를 발견했습니다.
 
# 다른 기관도 많지만, 프로그래머스를 선택하신 이유는 무엇인가요?
4학년 2학기를 어떻게 보낼지 고민이 많았어요. 당시 인턴에 합격한 상황이었는데, 기초가 부족하다고 느껴 공부를 좀 더 해야 하나 고민을 하고 있었거든요. 마침 그러던 와중에 데브코스을 알게 되었고, 저에게 딱 맞는 교육이라 느꼈어요. 한 학기 정도의 기간 동안 제가 필요로 하는 부분을 모두 배울 수 있었어요. 또한, 학부 수업과 프로젝트를 통해 나름대로 백엔드 지식을 갖췄지만 체계적으로 학습한 것은 아니었기에 스프링 부트 프레임워크를 바탕으로 다시 한번 배우고 싶었어요.
 
또한 강사님과 멘토링, 탄탄한 커리큘럼이 마음에 쏙 들었어요. 강사님들 중 제가 알고 있는 분이 계셔서 신뢰가 갔고, 데브코스에 참여하는 5개월 동안 현직에 계신 멘토들의 코칭을 받을 수 있다는 것이 큰 장점으로 다가왔어요. 커리큘럼 또한 짜임새 있고, 수업 외에 필요한 지식을 보충할 세션들이 많은 것도 좋았습니다. 단단히 마음먹고 제작한 교육 과정이라 느껴져서, 저도 마음먹고 지원했습니다.
 
# 데브코스를 참여하며 세운 목표는 무엇이었나요?
자바 활용능력과 스프링 부트 프레임워크를 이해하는 것을 목표로 했어요. 자바를 사용해 봤지만 능숙한 편이 아니었고, 객체지향 등의 개념도 어렴풋이 알고 사용하는 정도였어요. 또한, 국내에서 큰 점유율을 차지하는 스프링(부트) 프레임워크를 다뤄본 적이 없어서 관련 경험을 쌓고 싶었습니다.
 
# 목표는 얼마나 달성하셨나요?
백엔드 데브코스를 통해 어렴풋이 알고 있던 것들을 확실히 배웠어요. 기초적인 개발 실력을 단단하게 쌓았고, 추가로 개발 공부는 속도보다는 방향이, 응용보다는 기초가 중요하다는 것을 깨달았습니다.
 
이제는 데브코스를 통해 배운 것들을 바탕으로 학생이 아닌 진정한 사회인이자 개발자로서 성장해가고 싶습니다.
 
# 5개월 동안 힘들었던 순간은 없으셨나요? 있었다면 어떻게 극복하셨나요?
매 순간이 쉽지는 않았던 것 같아요. 특히 마지막 학기에 졸업 프로젝트와 맞물리면서 여유가 없었고 지칠 때가 있었어요. 교육 과정에서 배우는 내용도 쉽지 않았고, 과제와 프로젝트도 해야 했죠. 그럴 때마다 동료들이 제 상황을 이해해주고 배려해줘서 마음을 다잡을 수 있었어요.
 
# 데브코스에서 어떤 부분이 가장 도움이 되었나요?
모두 좋았지만 하나만 꼽으면 세션 & 특강이요! 매일 영상 강의를 듣고 과제와 프로젝트를 병행하다 보니, 따로 시간을 내어 취업을 준비하기가 쉽지 않았거든요. 그런데 과정 중간중간 면접 대비 특강이나 해외 개발자와의 커리어 토크 같은 유익한 세션을 열어주셔서, 별도로 시간을 들이지 않아도 자연스럽게 취업 준비를 할 수 있었어요.
 
# 이력서와 면접 준비는 어떻게 하셨나요?
경험 삼아 지마켓글로벌에 지원했는데 면접까지 올라갔어요. 지마켓글로벌은 블라인드 채용이어서 코딩 테스트 진행 후 합격자에 한 해 면접이 진행되었어요. 자기소개서도 그때 제출하는 거였죠. 처음 이력서를 준비할 때 강사님에게 피드백을 받았는데, 자기소개서는 스스로 준비했어요.
 
면접의 경우, 첫 면접이었기에 자신이 없었어요. 그래도 최선을 다해 준비하고자 노력했어요. 강사님과 모의 면접도 진행하고, 교육 과정 중에 들었던 면접 특강을 상기하며 준비한 결과 합격할 수 있었어요. 준비 기간이 짧았지만 강사님과의 모의 면접이 실제 면접에서 많은 도움이 되었습니다.
 
# 프론트엔드 수강생 분들과 한 달 동안 협업 프로젝트를 진행하셨는데요. 어떤 프로젝트를 진행하셨나요?
온라인 중고거래 플랫폼 offer을 만들었습니다. 구매자가 판매자에게 가격을 제안할 수 있는 방식이며, 가격 제안은 2회로 제한해 적절한 시점과 가격에 거래가 성사되도록 기획했습니다. 이 프로젝트에서 저는 기획과 백엔드 개발을 담당했으며, 특히 쪽지 기능과 게시글 검색 기능을 구현했습니다. 4주간 프론트엔드, 백엔드 팀원들과 함께 기획부터 배포까지 협업하며, 재미있고 의미 있는 경험을 쌓을 수 있었습니다.
 
<div style="position: relative; max-width: 100%; padding-bottom: 56.25%; height: 0;"><iframe width="560" height="315" src="https://www.youtube.com/embed/u64Qetn-X88?si=IfCM_pTMl7unuoqv" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen="" style="position: absolute; position: absolute; top: 0; left: 0; width: 100%; height: 100%;"></iframe></div>
 
👆 박건희 님이 참여한 최종 프로젝트

 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/2c406251-3926-4336-8fec-c2afa94ba480/image.png)
 
👆 팀원들과 디스코드에서 협업하고 함께 프로젝트를 기획했던 시간들
 

# 함께한 동료들은 어땠나요?
모두 각자의 방식대로 정말 열심히 임하는 분들이었어요. 실력이나 상황은 조금씩 달랐지만, 노력하는 모습 하나하나가 인상 깊었고, 배울 점도 많았습니다. 이렇게 열정 가득한 동료들과 함께한 경험은 흔치 않은 소중한 기회였다고 생각해요.
 
순수한 교육 환경 덕분에 남과 비교하기보다는 서로 긍정적인 경험을 나누며 성장할 수 있었고, 나와는 다른 방식으로 문제에 접근하는 동료들의 생각을 보며 제 사고의 폭도 넓어졌습니다. 데브코스에서 소중한 인연이 많이 생겨서 감사한 마음이에요.
 
# 데브코스 수료 후 달라진 점이 있다면 무엇인가요?
지속적으로 공부하는 원동력을 얻었습니다. 그동안 학교 커리큘럼을 따라가는 수동적인 공부를 했다면, 이제는 무엇을 공부해야 하는지, 어떻게 공부해야 하는지 감을 잡은 것 같아요. 백엔드 데브코스 1기는 후회 없는 선택이었습니다. 저를 선발해 주신 분들, 같이 공부했던 동료들, 교강사 및 멘토님들, 매니저님들 모두 감사드립니다. 앞으로 더욱 성장할 저를 기대해 주세요.
 
# 앞으로 어떤 개발자가 되고 싶으신가요?
꾸준히 발전하는 개발자가 되고 싶습니다.
 
# 마지막으로 후배 교육생들에게 응원의 한 마디 부탁드려요.
여러분들이 알아보고 선택한 데브코스입니다. 처음의 마음가짐이라면 못할 것이 없다고 생각해요. 동료, 교강사님들, 멘토님들, 매니저님들과 함께 멋진 5개월을 보낸 후에 원하시는 바 모두 이루시면 좋겠습니다.
 
 
*※본 글은 2022년 2월에 최초 작성된 콘텐츠입니다.*
 
 
[![BE_배너.jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/14576bae-2336-4997-93a3-f413ce8492f2/BE_%E1%84%87%E1%85%A2%E1%84%82%E1%85%A5.jpg)](https://school.programmers.co.kr/learn/courses/25244?utm_source=prgmblog&utm_medium=social&utm_campaign=school_25244_blog&utm_content=25244_banner)

[데브코스 후기] 기초부터 실무까지, 데브코스로 완성한 취업 여정 - 백엔드 1기 수료생 박건희 님

CJ그룹 IT 계열사 CJ올리브네트웍스에 합격해 현재 Business System Engineer로 근무 중인 김민우 수료생을 만났습니다. 백엔드 데브코스를 수료한 뒤, 포트폴리오와 자기소개서 준비부터 최종 합격까지의 여정을 진솔하게 나누어주셨는데요. 팀 프로젝트에서의 협업 경험, 면접 준비 노하우, 그리고 실제 현업에서 체감한 데브코스의 강점까지! 취업 준비 중이라면, 끝까지 읽어보세요!
 
 
## 안녕하세요. 간단한 자기소개 부탁드립니다.
안녕하세요. CJ그룹의 IT 계열사 **CJ올리브네트웍스**에서 Business System Engineer로 근무 중인 김민우입니다. 주로 **시스템 운영 및 유지보수(SM) 업무를 담당**하고 있으며, 현재는 그룹웨어 SM을 맡고 있습니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/49eaced1-82e4-4df3-94b0-4d2c53ae2f43/image.png)
 
 
## 데브코스 중 어떤 트랙을 수료하셨나요? 해당 과정을 선택한 이유와 참여하게 된 계기를 들려주세요.
저는 **클라우드 기반 백엔드 엔지니어링 1기**를 수료했습니다.
당시 학교 웹 개발 동아리에서 백엔드 파트를 맡고 있었는데, 초보자를 대상으로 하던 동아리 활동이다 보니 더 다양한 경험이 필요하다고 느껴 부트캠프를 찾게 되었습니다. 그 중 프로그래머스라는 신뢰할 수 있는 플랫폼에서 진행한다는 점, 그리고 데브코스의 좋은 평판이 참여를 결정하게 된 가장 큰 이유였습니다.
 
 
## 데브코스에 참여하며 가장 인상 깊었던 학습 경험에 대해 알려주세요.
단연 팀 프로젝트입니다. **단계별로 프로젝트를 진행하면서 뒤로 갈수록 더 복잡한 과제에 도전**하게 되었습니다. 팀원들과 자발적으로 어려운 과제를 선택했다는 점이 특히 좋았습니다.
 
프로젝트 과정에서 서로 코드리뷰를 해주고, 밤늦게까지 통화하며 할 일을 정리하고 개발했던 경험이 기억에 남습니다. 특히 코드리뷰를 꼼꼼하게 해주는 팀원이 있어, 저도 더 신경 써서 주석을 달고 팀이 정한 형식에 맞춰 코드를 작성하게 되었습니다. **이 습관은 지금 현업에서도 큰 도움**이 되고 있습니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/6e0c41cc-156e-4dc6-ba75-841ab2fdc42f/image.png)
🔼 프로젝트하면서 썼던 PR 예시 & 팀원들과 주고 받은 리뷰들
 
 
## 취업 준비는 어떻게 하셨나요?
### ✅ 포트폴리오
포트폴리오는 인터넷에 검색하면 나오는 예시들을 참고해 준비했습니다. 특히 주의했던 점은 절대 거짓된 내용을 쓰지 않는 것, 그리고 사실이라도 내가 충분히 설명하거나 책임질 수 있는 내용만 쓰는 것이었습니다. 또한 **데브코스에서 보여주셨던 좋은 포트폴리오 사례들이 큰 도움**이 되었습니다.
 
### ✅ 자기소개서
데브코스에서 자기소개서를 첨삭 받으며 큰 도움을 받았습니다. **두괄식 구조, 경험과 배운 점, 직무 연관성까지 잡는 연습**을 통해 자기소개서의 완성도를 높일 수 있었습니다.
 
### ✅ 면접 준비
면접은 사실 한 곳밖에 보지 않았고, 다행히 그곳에 합격했습니다. 처음에 Business System Engineer라는 직무명이 낯설었는데, **채용 페이지에 올라온 현직자 인터뷰를 참고**하면서 이해할 수 있었습니다. 이후에는 매일 기사 5개 정도를 스크랩해, 면접에서 제 경험과 연결해 이야기할 수 있는 포인트들을 정리했습니다.
 
기술 면접은 포트폴리오와 자기소개서를 다시 보며, 제가 강조했던 **기술 키워드들을 중심으로 대비**했습니다. 실제 면접에서는 그 부분이 질문으로 이어질 가능성이 높기 때문입니다. 또 기술 면접에 참고할만한 블로그 글들을 틈틈이 확인하며 리마인드하는 방식으로 준비했습니다.
 
 
## 취업에 성공하기까지의 과정은 어땠나요?
여러 활동을 병행하다 보니 총 19곳 정도밖에 지원하지 못했습니다. 2024년 하반기 공채 기간(9월 초~11월) 동안 주로 그룹사 SI 기업들의 백엔드나 자바 관련 직무에 지원했는데, 초반에는 서류 전형에서 모두 탈락해 힘들었습니다. 
 
그러다 10월 중순, 처음으로 CJ에서 서류 합격 소식을 받았을 때, '드디어 한 곳이라도 뚫어보는구나' 싶었습니다. 이후 **코딩테스트, AI 면접, 역량 검사, 1·2차 면접을 거쳤고, 12월에 3주간 인턴 과정을 마친 후 최종 합격** 소식을 들을 수 있었습니다!
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/1296f2e7-1136-4fac-912a-ab0d8e68fae2/image.png)
🔼 힘들었던 서류 전형 과정이었지만, 결국 최종 합격까지! 🍀
 
 
## 기억에 남는 면접 질문은 무엇이었나요?
"CJ그룹이 하는 일에서 AI를 어떻게 활용할 수 있을까요?"라는 **AI 활용 관련 질문**이었습니다.
막연히 예상만 했던 질문이라 잠시 생각을 정리한 뒤, "AI가 노동 현장에서 사람과 기계를 이어주는 다리 역할을 할 수 있다"라고 답했습니다. 예를 들어 대한통운의 물류창고처럼 여전히 사람이 필수적인 현장에서, AI를 효율적으로 병행할 수 있는 절차를 구축할 수 있을 것이라 말씀드렸던 기억이 납니다.
 
 
## 데브코스 지원 중 취업에 특히 도움이 된 부분은 무엇이었나요?
취업에 가장 직접적으로 도움이 된 건 **포트폴리오와 자소서 활동**이었습니다.
 
포트폴리오는 좋은 예시들을 많이 보여주셔서 큰 도움이 되었어요.
"저 정도는 되어야 취업이 되는구나"하는 현실적인 자각도 했고, 단순히 예쁜 형식을 따라 쓰는 게 아니라 그 안에 담을 '내용'도 충분히 있어야 한다는 것을 깨달았습니다. 그래서 이후 **과제를 하거나 기술을 선택할 때도, "이 경험이 내 무기가 될 수 있을까?"를 생각**하며 준비할 수 있었죠.
 
자소서는 **강사님께서 한 명 한 명 꼼꼼하게 디테일까지 피드백**을 해주셔서 특히 좋았습니다. 혼자 처음 썼을 때와 피드백을 반영해서 고친 자소서를 비교해보니, "이 정도는 써야 부끄럽지 않겠다"라는 생각이 들었습니다.
 
 
## 데브코스에서 배운 내용이 실무에 어떤 방식으로 도움이 되었나요?
**데브코스에서 배운 네이티브 쿼리 작성이 실무에서 큰 도움**이 되고 있습니다. 저는 주로 쿼리를 읽고 작성하는 일이 많은데, 스프링 프레임워크 지식은 MVC 패턴과 의존성 주입 정도의 기본적인 것만 필요한 것 같습니다. 근데 레거시 시스템을 다루다 보니, 쿼리를 읽고, 작성하고, 수정하는 일이 많습니다.
 
데브코스 초반 수업에서 네이티브 쿼리를 배우며 "그냥 JPA를 쓰면 되지 않을까?"라고 생각했었지만, 실무에서는 요구사항과 DB 설계가 복잡하여 오히려 JPA보다 마이바티스, 아이바티스 등을 쓰고, 그러다보니 쿼리 작성이 중요했습니다. **수업 시간에 강사님께서 해주셨던 조언이 마치 제 상황을 예견한 듯 정확히 맞아떨어져, 실무 시작 후에도 당황하지 않을 수 있었습니다**.
 
또한, 데브코스 경험 덕분에 **긴 코드나 문서에 압도되지 않고 끝까지 이해하는 마인드셋**을 갖게 되었습니다. 프로젝트를 진행하며 튜토리얼과 문서, 새로운 기술을 접할 때마다 자연스럽게 성장할 수 있었고, 지금 업무에서 마주하는 레거시 시스템도 데브코스에서 배운 경험 덕분에 차근차근 잘 해내고 있습니다.
 
 
## 데브코스를 통해 기술 외적으로 성장했다고 느낀 부분이 있다면 무엇인가요?
데브코스를 통해 **커뮤니케이션 능력**과 **기록 습관**이 많이 성장했습니다. 팀 프로젝트를 진행하면서, 내가 하고 싶은 것과 그것을 어떻게 구현할지 명확하게 설명하는 능력이 중요하다는 걸 배웠습니다. 설명을 잘하면 신뢰를 얻을 수 있고, 그 과정을 위해 내용을 정리하고 말하는 연습을 하면 지식이 완전히 내 것이 됩니다.
 
특히 **매주 한 가지 기술을 정해 설명하는 활동**을 통해, 내용을 체계적으로 정리하고 쉽게 전달하는 연습을 할 수 있었습니다. 덕분에 지금 신입으로 일하면서도 배우는 내용을 기록하고, 문의 응대 사례도 꼼꼼히 정리하는 습관이 생겼습니다.
 
추가로, 프로젝트가 끝난 뒤 팀원들과 함께한 회식 자리에서도 좋은 추억을 쌓을 수 있었습니다. 😄
 
 
## 지금 돌아보면, 데브코스 과정에서 "이건 좀 더 잘했으면 좋았겠다" 싶은 부분이 있을까요?
"**블로그를 좀 더 꾸준히 해둘걸...**" 하는 아쉬움이 있습니다. 물론 힘들고 귀찮은 작업이지만, 해뒀다면 취업 과정이 훨씬 효율적이었을 거예요. 블로그에 글을 쓰면 자연스럽게 내가 했던 일을 정리하게 되고, **그 기록들은 포트폴리오나 자기소개서, 면접에서 바로 활용할 수 있는 멘트가 됩니다**. 또 기술을 더 자세히 기억할 수 있고, 작성한 글을 다시 보면서 중요한 내용들을 다시 상기할 수도 있고요. 취업 준비에 도움이 되는 강력한 무기로 활용할 수 있었을 것 같아요.
 
 
## 현업에서 일해보니, 데브코스의 어떤 점이 특히 좋았다고 느끼셨나요? 아직 수강을 고민 중인 분들에게 데브코스를 추천해주세요.
데브코스를 언급하면, 비교적 젊은 연차의 현직자분들은 아는 경우가 종종 있습니다. 실제로 수료했던 분들도 있었던 것 같아요. 그래서인지 "**데브코스 하셨으면 스프링 개발 잘하시겠네요**"라며 긍정적으로 봐주시는 분들도 계시고, **어느 정도 믿고 맡겨주시기도 합니다**. 물론 그렇게 기대해 주실 때는, 당연히 맡은 일을 잘 해내야 한다는 책임감도 함께 느낍니다!
 
 
## 마지막으로, 앞으로의 커리어 목표가 있다면 말씀해주세요!
앞으로 DBA(Database Administrator)가 되고 싶습니다. 요구사항을 꼼꼼히 정리하고 이를 관계형 DB 설계에 반영하는 일을 잘할 수 있을 것 같고, **백엔드 개발자와 운영 담당자 모두를 고려하며 영향력을 발휘할 수 있는 역할이 바로 DBA**라고 생각합니다. 특히 개발 생산성과 밀접하게 연결된 분야라, 개발을 배우면서도 자연스럽게 이런 일을 하고 싶다는 생각을 많이 하게 되었습니다.
 
 
 
*강의 운영 사정에 따라 세부 프로그램 내용은 변경될 수 있습니다.*
 
 
 
[![BE_배너.jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/973d28d3-a2ab-47a7-b9f5-7bbc12d52e55/BE_%E1%84%87%E1%85%A2%E1%84%82%E1%85%A5.jpg)](https://school.programmers.co.kr/learn/courses/25244?utm_source=prgmblog&utm_medium=social&utm_campaign=school_25244_blog&utm_content=25244_banner)

[취업 인터뷰] 취업부터 실무 적용까지! 데브코스로 완성한 커리어 여정 - 백엔드 1기 수료생 김민우 님

개발을 하다 보면 누구나 한 번쯤 '전설의 코드'를 마주합니다. 아무도 건드리지 못하고, 만든 사람은 이미 떠났지만, 이상하리만큼 잘 돌아가는 코드 말입니다. 시니어 개발자 고코더님은 이런 코드가 만들어지는 가장 큰 이유로 '문서의 부재'를 이야기합니다. 이번 글에서는 개발자들이 문서를 미루게 되는 이유부터, 문서가 없을 때 팀에 어떤 비용이 쌓이는지, 그리고 현실적으로 어떤 문서부터 남겨야 하는지에 대해 알아보겠습니다.
 
 
## 전설의 코드
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/036d0897-420d-42b5-b1d8-091e671927b9/image.png)
출처: ChatGPT 이미지 생성
 
 
아무도 건드리지 않는 코드가 있습니다. 
건들면 안 될 것 같은 무서운 코드. 
개발자를 찾아보면 돌아오는 답은 늘 같습니다.
"그분은 이미 퇴사하셨어요."
 
그룹웨어에서 이름을 검색해 보면 계정은 비활성화되어 있고, 인수인계 문서는 남아있지 않습니다. 그런데 이상하게도 묘하게 코드는 잘 돌아가고 있어서 아무도 손을 대지 못합니다.
 
그리고 그런 코드 옆에는 꼭 이런 주석이 달려있습니다.

 <div style="border-radius: 4px;padding:22px 20px; background: #F5F5F5; border: 1px solid #D6D6D6;">//왜 이렇게 했는지는 나도 모름. 건드리지 말 것. //TODO: 나중에 정리할 것 //2019.03 긴급 패치 - 절대 삭제 금지</div>
 

문서는 없습니다. 위키를 열어보면 제목만 그럴듯합니다.
본문에는 "추후 작성 예정"이라는 한 줄만 남아 있습니다. 그 "추후"는 몇 년째 오지 않았습니다.
README는 프로젝트 생성 당시 자동으로 만들어진 템플릿 그대로입니다. 아무도 문장을 채우지 않았습니다.
 
재미있는 건, 이 팀이 코드 관리에는 누구보다 엄격하다는 것입니다. 커밋 메시지 컨벤션이 있고, PR 템플릿이 있고, 코드 리뷰에서는 변수명 하나도 그냥 넘어가지 않습니다. 그런데 문서만큼은 완전히 다른 세계입니다. 코드에는 린터를 돌리면서, 위키는 2년 된 내용이 그대로입니다.
 
왜 이런 일이 반복될까요?
그리고 어떻게 하면 달라질 수 있을까요?
 
 
## 왜 개발자는 문서를 안 쓸까요
문서를 안 쓰는 이유를 물어보면 대부분 비슷한 대답이 나옵니다.
"코드 보면 알 수 있어요."
"나중에 정리하려고요."
"지금 너무 바빠서요."
 
전부 사실입니다. 틀린 말이 하나도 없습니다. 그런데 이 대답들이 매 분기, 매년 반복됩니다. "나중에"는 오지 않고, 업무는 항상 바쁘고, 코드로 모든 것을 알 수 있다는 믿음은 퇴사자가 나올 때마다 산산조각 납니다.
 
구조적인 문제도 있습니다. 대부분의 팀에서 문서 작성은 완료 기준에 포함되지 않습니다. 기능이 배포되면 티켓은 닫힙니다. 문서가 없어도 배포는 됩니다. 코드 리뷰에서 "README 업데이트 안 됐네요"라고 반려하는 사람은 없습니다. 자연스럽게 문서는 해도 그만, 안 해도 그만인 것처럼 취급됩니다.
 
더 솔직한 이유도 있습니다. 문서 작성이 실력처럼 보이지 않는다는 것입니다. 복잡한 알고리즘을 짜거나 성능을 개선하면 티가 납니다. 코드 리뷰에서 날카로운 코멘트를 달면 존재감이 생깁니다. 그런데 README를 열심히 업데이트하거나 위키에 운영 가이드를 꼼꼼히 적어놓아도, 그걸 알아주는 사람은 많지 않습니다. 코드는 Git 기록에 내 이름이 남지만, 문서는 누가 썼는지 잘 보이지도 않습니다.
 
완벽주의도 한몫합니다. "설계가 아직 확정되지 않았으니 나중에 쓰자", "지금 문서화해도 또 바뀔 텐데"라는 생각이 문서 작성을 계속 뒤로 미루게 만듭니다. 어느 정도 완성된 후에 제대로 쓰려고 미루지만, 막상 어느 정도 완성되면 또 새로운 요구사항과 변경이 들어옵니다. 그렇게 문서는 영원히 최신 상태가 되지 않습니다. 완벽한 문서를 작성하려다가, 아무 문서도 남지 않는 상황이 반복되는 겁니다.
 
 
## 문서가 없으면 생기는 일
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/41d675f7-b206-41fd-ac2d-18ab90f9e205/image.png)
출처: 픽사베이
 
실제로 겪었던 일입니다. 팀에서 오래 운영해온 배치 작업이 있었습니다. 어느 날 담당자가 퇴사했습니다. 코드는 남아 있었지만 왜 이렇게 동작하는지, 어떤 상황에서 재실행해야 하는지 아는 사람이 없었습니다. 결국 코드를 하나하나 읽어가며 역추적하는 데 사흘이 걸렸습니다. 그것도 그 코드를 어느 정도 알고 있던 팀원이 옆에서 함께 봐준 덕분에 사흘이었습니다. 혼자였다면 훨씬 더 걸렸을 겁니다.
 
코드는 "무엇을" 하는지 알려줍니다. 문서는 "왜", "어떤 상황에서", "무엇을 조심해야 하는지"를 알려줍니다. 이 맥락이 빠지면 코드는 수수께끼가 됩니다. 특히 복잡한 비즈니스 로직이 얽혀 있을수록, 코드만으로는 의도를 파악하기 어렵습니다. 예외 처리 하나에도 그 뒤에 긴 사정이 있을 수 있습니다. 당장은 이해할 수 없는 이상한 조건문이, 사실은 3년 전 대규모 장애를 막기 위해 급하게 넣은 패치일 수도 있습니다.
 
팀 차원의 비용은 더 직접적입니다. 같은 질문이 반복되고, 새로운 사람이 올 때마다 누군가의 시간이 온보딩에 소모됩니다. 오래된 문서를 믿고 작업했다가 엉뚱한 방향으로 시간을 낭비하는 일도 생깁니다. 문서를 작성하지 않는 비용은 당장 눈에 보이지 않지만, 조용히 팀 전체의 시간을 갉아먹습니다.
 
 
## 코드 주석은 문서가 아닙니다
"주석 열심히 달면 되지 않나요?"라는 반응이 나올 수 있습니다. 주석은 분명히 중요합니다. 하지만 주석과 문서는 역할이 다릅니다.
 
주석은 코드의 특정 줄이나 함수가 어떻게 동작하는지를 설명합니다. 직관적이지 않은 처리 방식에 이유를 달거나, 복잡한 로직의 흐름을 설명하는 건 좋은 습관입니다. 그런데 주석만으로는 전달되지 않는 것들이 있습니다.
 
이 서비스 전체가 어떤 구조로 돌아가는지, 로컬에서 개발 환경을 어떻게 세팅하는지, 배포 후 확인해야 할 체크리스트가 무엇인지, 이 API를 처음 사용하는 사람이 어디서부터 시작해야 하는지.
이런 내용은 코드 어디에도 들어갈 자리가 없습니다. 코드 파일을 열기 전에 필요한 정보이기 때문입니다. 그게 문서가 따로 존재해야 하는 이유입니다.
 
주석과 문서는 경쟁 관계가 아닙니다. 코드 바로 옆에 붙어 있는 설명과, 팀 위키나 README에 따로 존재하는 문서는 독자도 다르고 목적도 다릅니다. 하나가 다른 하나를 대체할 수 없습니다. 주석과 문서, 둘 다 있어야 합니다.
 
 
## 어떤 문서부터 써야 할까요
모든 것을 한 번에 문서화할 수는 없습니다. 우선순위가 필요합니다. 실제로 팀에 가장 도움이 되는 문서는 거창한 아키텍처 다이어그램이 아닙니다. 가장 자주 물어보는 질문에 대한 답입니다.
 
신입이 들어왔을 때 가장 먼저 물어보는 것이 무엇인지 생각해보세요. 로컬 개발 환경 세팅 방법, 자주 쓰는 명령어 모음, 배포 순서, 서비스가 이상할 때 가장 먼저 확인할 곳. 이런 내용을 담은 짧은 문서 하나가 수십 번의 반복 질문을 막아줍니다. 누군가에게 똑같은 설명을 세 번 이상 했다면, 그건 문서로 만들어야 한다는 신호입니다.
 
다음으로 우선순위를 두면 좋은 것은 운영 가이드입니다. 기능을 배포하고 나서 문제가 생겼을 때 어떻게 확인하는지, 어떤 로그를 봐야 하는지, 비정상 동작의 기준이 무엇인지를 짧게라도 적어두면 실제 장애 상황에서 큰 차이를 만듭니다. 새벽 두 시에 알람이 울리면 코드를 차분히 읽고 있을 여유는 없습니다. 그때 바로 펼쳐볼 수 있는 짧은 가이드 한 페이지가 30분을 아껴주기도 합니다.
 
API를 다른 팀과 공유하거나 외부에 제공하는 경우라면 사용법 문서도 꼭 있어야 합니다. 파라미터 설명, 응답 형식, 에러 코드 목록, 간단한 예시 코드 정도면 충분합니다. 이 정도만 있어도 "이거 어떻게 써요?"라는 메시지가 눈에 띄게 줄어듭니다.
 
 
## 습관으로 만드는 방법
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/9c19ac4e-9617-4227-bf63-d6c20b0274f4/image.png)
출처: 픽사베이
 
문서를 잘 작성하는 팀이 처음부터 완벽한 문서 시스템을 갖추고 시작하는 경우는 거의 없습니다. 대부분 아주 작은 습관에서 출발합니다.
 
첫 번째는 내가 오늘 해결한 문제는 한 단락만 남기는 것입니다. 왜 이 방법을 선택했는지, 다음에 같은 상황이 오면 뭘 주의해야 하는지를 짧게 적는 것입니다. Notion이든, 팀 위키든, PR 설명란이든 어디든 좋습니다. "이 방식을 택한 이유는 A 때문이고, B도 시도해 봤지만 C 문제가 있었다." 이 세 줄이면 충분합니다. 이 습관이 쌓이면 나중에 같은 문제를 다시 마주쳤을 때, 검색 한 번으로 실마리를 찾을 수 있게 됩니다.
 
두 번째는 새 기능을 배포할 때 운영 가이드를 함께 만드는 것을 팀 규칙으로 정하는 겁니다. 기능 배포 완료의 기준에 운영 가이드 작성을 포함시키는 것입니다. 처음에는 번거롭게 느껴지지만, 한두 번 그 문서 덕분에 장애 상황을 빠르게 수습하고 나면 팀의 인식이 달라집니다. 문서가 짐이 아니라 보험이라는 걸 직접 경험하게 됩니다.
 
세 번째는 구두로 설명한 내용을 그대로 문서에 붙여 넣는 것입니다. 누군가의 질문에 슬랙으로 답했다면, 그 답변을 복사해서 위키에 붙이고 제목만 달아두는 겁니다. 이미 한 번 정리한 내용이라 추가로 생각할 것도 없습니다. 5분이 채 걸리지 않습니다. 그 5분이 다음 사람의 한 시간을 아껴줍니다.
 
네 번째는 AI를 문서 작성 보조 도구로 활용하는 겁니다. "AI한테 물어보면 되지 않나요?"라는 생각을 해본 적 있을 겁니다. 그런데 AI는 우리 팀의 숨겨진 맥락을 모를 때가 많습니다. "이 배치 작업이 왜 이렇게 돌아가나요?"라고 물어봐도, 아무도 문서를 남기지 않았다면 AI도 답을 줄 수 없습니다. 오히려 AI에게 정확한 답을 받으려면 잘 정리된 문서가 먼저 있어야 합니다.
 
반대로 활용하는 방법도 있습니다. 슬랙에서 내가 한 설명을 AI에게 붙여 넣고 "이걸 위키 문서 형식으로 정리해 줘"라고 하면 초안이 수십 초 안에 나옵니다. 문서 쓰는 일이 귀찮은 이유 중 하나가 '어떻게 써야 할지 막막해서'인데, AI가 그 첫 문장의 벽을 허물어줍니다. 초안을 다듬는 건 처음부터 쓰는 것보다 훨씬 쉽습니다.
 
 
## 문서는 미래의 나에게 보내는 편지
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/e1a5140f-0ea1-4998-964f-56b11011dc58/image.png)
출처: 픽사베이
 
문서를 미루는 이유 중 하나가 "아직 완성되지 않았으니 제대로 쓰자"는 완벽주의입니다. 그런데 불완전한 문서가 없는 문서보다 훨씬 낫습니다.
 
잘못된 정보가 담긴 문서는 문제가 됩니다. 하지만 일부 내용이 빠져 있거나 다듬어지지 않은 문서는 그래도 시작점을 만들어줍니다. "이 부분은 아직 확인 필요"라는 메모라도 있으면, 읽는 사람이 어디서 더 확인해야 하는지 알 수 있습니다. 아무것도 없으면 어디서 시작해야 하는지조차 모릅니다.
 
아무것도 없는 빈 페이지에 내용을 채우는 것보다, 어느 정도 뼈대가 잡힌 문서에 살을 붙이는 게 훨씬 쉽습니다. 지금 당장 완벽하게 쓸 수 없다면, 최소한의 뼈대만 남겨두고 나중에 채우는 방식도 충분히 유효합니다. 코드에 기술 부채가 있듯, 문서에도 기술 부채가 있을 수 있습니다. 중요한 건 아예 없는 것과 조금 부족한 것은 완전히 다르다는 겁니다.
 
문서를 쓰는 일이 이타적인 행동처럼 느껴질 수 있습니다. 팀을 위해, 다음에 올 신입을 위해 시간을 내는 것처럼요. 하지만 가장 먼저 혜택을 받는 사람은 대부분 6개월 뒤의 자신입니다.
 
반년 전에 작성한 코드로 돌아왔을 때, 왜 이런 결정을 내렸는지 기억하는 사람은 없습니다. 그때 남긴 짧은 메모 하나가 무너지려는 맥락을 잡아줍니다. "당시 A 방법도 고려했는데 B 이유로 이 방식을 택했다"라는 두 줄이, 같은 고민을 처음부터 다시 하는 몇 시간을 아껴줍니다.
 
좋은 문서는 긴 글이 아닙니다. 다음에 이 코드를 보게 될 사람이 "왜 이렇게 했지?"라고 물을 것 같은 지점에 짧게 답을 남기는 것입니다. 그것만으로 충분합니다.
 
코드는 지금의 나를 위해 씁니다. 문서는 미래의 누군가를 위해 씁니다. 그 누군가가 대부분 나 자신이라는 사실을 기억하면, 문서 쓰는 일이 조금 덜 귀찮아집니다. 오늘 퇴근 전 딱 한 단락만 써보는 것에서 시작해 보세요. 전설의 코드를 남기지 않기 위해서요.
 
 

### 📌 함께 읽으면 좋은 글
* [코드는 잘 짜는데 발표만 하면 왜 이럴까](https://community.programmers.co.kr/post/13597?utm_source=&utm_medium=&utm_campaign=&utm_content=gocoder_13597)
* [개발자가 숫자로 말해야 하는 이유](https://community.programmers.co.kr/post/13498?utm_source=&utm_medium=&utm_campaign=&utm_content=gocoder_13498)
* [AI 시대, 신입 개발자가 실력을 키우는 법](https://community.programmers.co.kr/post/13432?utm_source=&utm_medium=&utm_campaign=&utm_content=gocoder_13432)

 
 

![고코더 작가님 프로필 카드.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/c227824e-8b30-4bd8-b5a3-233a53dc4546/%E1%84%80%E1%85%A9%E1%84%8F%E1%85%A9%E1%84%83%E1%85%A5%20%E1%84%8C%E1%85%A1%E1%86%A8%E1%84%80%E1%85%A1%E1%84%82%E1%85%B5%E1%86%B7%20%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%84%91%E1%85%B5%E1%86%AF%20%E1%84%8F%E1%85%A1%E1%84%83%E1%85%B3.png)

개발자가 문서를 안 쓰는 이유

#### "나는 어떤 개발자일까?"
MBTI보다 재밌는 **개발자 유형 검사 EVENT**!
테스트만 해도 선물이 쏟아져요 ☀️
 
내일배움카드만 있으면 100% 무료로 참여할 수 있는 부트캠프!
프로그래머스 데브코스와 함께하는 핫한 여름방학 이벤트 🔥
배라부터 로지텍 마우스까지 싹 다 챙겨가세요 🎁
 
[![여름방학 이벤트 블로그 배너.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/56d4a363-43f0-4031-8cb9-efc8fc9b047d/%E1%84%8B%E1%85%A7%E1%84%85%E1%85%B3%E1%86%B7%E1%84%87%E1%85%A1%E1%86%BC%E1%84%92%E1%85%A1%E1%86%A8%20%E1%84%8B%E1%85%B5%E1%84%87%E1%85%A6%E1%86%AB%E1%84%90%E1%85%B3%20%E1%84%87%E1%85%B3%E1%86%AF%E1%84%85%E1%85%A9%E1%84%80%E1%85%B3%20%E1%84%87%E1%85%A2%E1%84%82%E1%85%A5.png)](https://community.programmers.co.kr/post/12222?utm_source=prgmblog&utm_medium=social&utm_campaign=school_2025devtype&utm_content=banner)

 
 
## ⏰ 진행 기간
**2025년 7월 11일(금) ~ 7월 30일(수)**
딱 좋은 여름 방학 타이밍, 놓치지 마세요! 🍉
 
 
## ✅ 이벤트 참여 방법
1️⃣ [**MBTI보다 재미있는 개발자 유형 테스트 참여 이벤트**](https://smore.im/quiz/36Fh1Qz8e5) 클릭

✨ 참여만 해도 자동 응모 완료!
✨ 내 유형을 확인하고, 친구에게 공유해보세요.
 
[![스크린샷 2025-07-14 오전 8.29.20.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/dbf347f2-c780-48af-a055-920c28991460/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202025-07-14%20%E1%84%8B%E1%85%A9%E1%84%8C%E1%85%A5%E1%86%AB%208.29.20.png)](https://smore.im/quiz/36Fh1Qz8e5?utm_source=prgmblog&utm_medium=social&utm_campaign=school_2025devtype&utm_content=img)
 
 
2️⃣ **로지텍 마우스까지 받아가는 데브코스 수료 이벤트**

테스트를 완료한 후 아래 [참여 가능한 데브코스 과정] 중 하나에 지원하고 수료까지 하면 **로지텍 G304 무선 마우스 100% 증정!**
 
> ⚠️ 마우스 증정 기준 
> - 2025년 7월 11일(금) ~ 7월 30일(수) 기간 내 데브코스 지원 후 수료까지 완료한 인원
> - 지원 신청서 내 “프로그래머스 데브코스를 어떻게 알게 되었나요?” 항목에 [설문조사 이벤트]를 선택한 인원

 
 
## 🧑‍💻 수료 이벤트 참여 가능한 데브코스 과정 (7~8월 모집 과정)
- [프론트엔드 6기](https://school.programmers.co.kr/learn/courses/25243?utm_source=prgmblog&utm_medium=social&utm_campaign=school_2025devtype&utm_content=25243_FE)
- [백엔드 7기](https://school.programmers.co.kr/learn/courses/25244?utm_source=prgmblog&utm_medium=social&utm_campaign=school_2025devtype&utm_content=25244_BE)
- [데이터 분석 8기](https://school.programmers.co.kr/learn/courses/25254?utm_source=prgmblog&utm_medium=social&utm_campaign=school_2025devtype&utm_content=25254_DA)
- [웹 풀스택 8기](https://school.programmers.co.kr/learn/courses/25276?utm_source=prgmblog&utm_medium=social&utm_campaign=school_2025devtype&utm_content=25276_FS)
- 데이터 엔지니어링 7기 (7월 중 오픈)
- 생성형 AI 백엔드 개발 4기 (7월 중 오픈)

 
 
## 🎁 여름방학 이벤트 혜택
* 배스킨라빈스 싱글 레귤러 (30명 추첨)
* 컴포즈커피 아메리카노 (50명 추첨)
* **로지텍 G304 무선 마우스** (100% 전원 지급)

 
✅ 테스트만 참여해도 자동 응모되며, 당첨자는 **8월 초 개별 안내 예정**입니다.
 
✅ 로지텍 G304 무선 마우스는 [**참여 가능한 데브코스 과정] 지원 후, 지원 신청서 내 [설문조사 이벤트]를 선택한 수료 인원 대상으로 100% 지급**됩니다.

 
 
## 🔗 이벤트 참여하러 가기
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/3b954bcd-b39c-4260-b042-5f788ee066bf/image.png)
👆 [이벤트 참여 링크](https://smore.im/quiz/36Fh1Qz8e5?utm_source=prgmblog&utm_medium=social&utm_campaign=school_2025devtype&utm_content=img) 클릭 또는 QR 코드를 스캔하여 개발자 유형 확인!
 
 
이번 여름, 나의 개발자 유형도 알아보고 프로그래머스 데브코스에서 나와 찰떡인 유형의 동료들도 만나보세요!
 
**여러분의 개발자 여정, 지금 여기서 시작됩니다.** 💻

 
 
[![summer_event-coding-test2(729x90)B.jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/18f957e4-3ba3-481c-bf13-31a78a4e9e5b/summer_event-coding-test2%28729x90%29B.jpg)](https://community.programmers.co.kr/post/12222?utm_source=prgmblog&utm_medium=social&utm_campaign=school_2025devtype&utm_content=banner)

[데브코스 이벤트] ☀️ 여름방학 한정 EVENT! 개발자 유형 테스트하고 선물 받자 🎁

개발자라면 한 번쯤은 꿈꿔봤을 기업, 네카라쿠배! 많은 분들이 취업을 원하는 만큼 그 꿈에 한 발짝 더 가까이 다가갈 수 있도록, 프로그래머스를 통해 '네카라쿠배'에 취업한 개발자의 이력서/포트폴리오 작성 꿀팁을 준비했어요. 꼭 '네카라쿠배'로 취업을 희망하지 않더라도, 취업을 위한 꿀팁들이 담겨있으니 꼼꼼하게 읽어봐 주세요! 😊
 
 
# 📌 기술 스택 어필형
### Q. 포트폴리오 아이디어는 어디에서 얻으셨나요?
서류를 검토하는 사람의 관점에서 포트폴리오를 만들려고 노력했어요. 기업에서 개발자를 채용할 때, 단순히 어떤 절대적인 기준을 충족한다고 해서 채용하는 것은 아니에요. 기업의 채용 형태나(공개 채용인지 상시 채용인지 등) 그 기업이 해당 포지션에 기대하는 역량에 맞춰 포트폴리오를 구성하는 것이 중요하다고 생각했어요.
 
저만의 노하우를 공유하자면, 여러 기술을 다양하게 다뤄본 경험을 어필하는 것보다 **하나의 기술이라도 깊이 있게 이해하고 활용한 경험을 보여주는 것이 더 매력적**이라고 생각해요. 제가 면접관이라도 그런 개발자에게 더 신뢰가 갈 것 같아요.
 
-신윤재, 카카오엔터프라이즈 AI검색팀 서버 개발자
 
### Q. 다른 개발자들과 차별화된 포트폴리오를 만들려면 어떤 점에 신경 써야 할까요?
**관심 있는 회사에서 사용하는 기술 스택을 먼저 파악한 뒤, 그 기술을 활용해 프로젝트를 직접 진행해보는 것을 추천**드려요. 관심 있는 회사가 어떤 기술 스택을 쓰는지는 채용 공고를 보면 어느 정도 유추할 수 있어요.
 
포트폴리오의 완성도도 중요하지만, 사용한 기술을 왜 선택했는지에 대한 명확한 이유와 이해가 반드시 필요해요. 예를 들어, GraphQL을 사용한 프로젝트라면 단순히 적용하는 데 그치지 않고, 왜 GraphQL을 선택했는지, 해당 기술의 장단점을 이해하고 설명할 수 있어야 하죠.
 
아래는 제가 사이드 프로젝트를 하며 공부한 기술 스택과 실제 프로젝트 경험입니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/724d306b-8dd0-4033-822e-e7aaee0af302/image.png)
 
-앤드류, 카카오엔터프라이즈 데이터 분석팀 프론트엔드
 
# 📌 프로젝트 강조형
### Q. 포트폴리오도 따로 준비하셨나요? 어떤 방식으로 구성하셨나요?
저는 진행했던 여러 프로젝트를 Git에 정리해왔는데요. Git만으로는 전체 프로젝트를 한눈에 보여주기 어렵다고 판단해 별도로 포트폴리오를 준비했어요. Git에 전체 코드와 문서가 있으니, **포트폴리오에는 각 프로젝트의 핵심 내용, 제가 맡았던 역할, 그리고 어려웠던 점과 해결 과정** 등의 자세한 스토리를 담았어요.
 
포트폴리오는 분야나 직무별로 목차를 나누어 구성했고, 각 프로젝트마다 주제, 개요, 사용 기술 스택, 담당 역할 등을 정리했어요. 전체 내용을 참고할 수 있도록 Git 링크도 함께 첨부했습니다. 포트폴리오는 저의 역랑을 가장 잘 표현할 수 있는 자료라고 생각했기 때문에 포트폴리오를 제출할 수 있는 회사 위주로 지원했던 것 같아요.
 
-박민서, 라인플러스 Data & ML 센터 데이터 엔지니어
 
### Q. 이력서와 포트폴리오는 어떻게 준비하셨나요?
신입으로 지원했지만, 산업진흥원에서 일했던 경험이 있어서 이 부분을 적극 어필했어요. 또 기술 스택과 무관하게 **내가 어떤 공부를 해왔는지, 어떤 문제 해결 능력을 갖추고 있는지** 보여주고자 했습니다.
 
개인적으로는 포트폴리오를 충분히 준비하지 못했다는 아쉬움이 있어요. 그래서 드리고 싶은 조언은 여러 스터디나 프로젝트를 경험해보는 것, 그리고 실제로 만든 결과물에 대한 설명을 체계적으로 정리하는 것이 큰 도움이 될 거라는 점이에요. 그런 정리는 면접에서도 자연스럽게 이야기할 수 있는 기반이 되더라고요.
 
-김찬우, 쿠팡 소프트웨어 개발 엔지니어
 
### Q. 취업에 가장 도움이 되었던 프로젝트나 활동은 무엇이었나요? 포트폴리오는 어떻게 준비하셨나요?
저에게 가장 도움이 되었던 프로젝트는 네이버 부스트캠프에서 진행한 프로젝트였어요. 단순히 결과물만 만들어낸 것이 아니라, 웹사이트를 구축하는 과정을 통해 많은 것을 배울 수 있었거든요. 이런 경험은 면접에 들어가서 이야기를 풀어가는 데 많은 도움이 되었던 것 같아요.
 
거창한 포트폴리오는 준비하지 못했지만, **지금까지 했던 프로젝트를 간략하게 설명하고 화면은 어떻게 구현했는지 이미지를 통해 보여주고자** 했어요. 따로 운영하던 기술 블로그도 함께 활용했어요.
 
-이창엽, 넥슨코리아 테크빌더팀 웹 개발자
 
# 📌 수치 정리형
### Q. 구직을 위해 따로 준비하신 포트폴리오나 이력서가 있나요?
이력서는 프로그래머스에서 작성한 이력서로 제출했어요. 포트폴리오는 생각만 하다가 결국 만들지는 못했어요. 다만, 프로그래머스에서 제공해주는 이력서 포맷이 활동들을 카테고리에 맞춰 깔끔하고 직관적으로 보여주어 큰 도움이 되었어요.
 
### Q. 자기소개서에서는 어떻게 본인을 어필하셨나요?
**되도록이면 수치 기반으로 성과를 설명하려고 노력**했어요. 예를 들어, '속도를 개선했다'는 말 대신에 '기능 처리 속도를 30% 향상시켰다', '트래픽이 40% 감소했다'처럼 명확하고 구체적인 수치를 넣으려 했습니다. 그리고 이력서는 간결하게 작성했어요. 했던 일들을 모두 장황하게 적으면, 읽는 사람은 힘들 것이라 생각했거든요. 직접 개발하거나 진행했던 프로젝트 중에서 중요한 것만 기록했고, 이런 부분이 좋은 점수를 받지 않았나 생각하고 있습니다.
 
-이길원, 센드버드 소프트웨어 엔지니어
 
### Q. 포트폴리오를 만들면서 어떤 어려움이 있었나요?
가장 어려웠던 점은 생각보다 많은 시간을 투자해야 한다는 점이었어요. 그래서 아주 디테일하게는 준비하지 못했고, **각 프로젝트의 개요, 팀원 구성, 맡은 역할, 느낀 점 등을 표 형식으로 간략하게 정리**해서 제출했어요. 세부적인 이야기는 면접 때 어필할 수 있도록 준비했습니다.
 
-김기표, SNOW 안드로이드 개발자
 
# 📌 꾸준히 기록형
### Q. 이직을 하실 때 포트폴리오를 따로 준비하셨나요? 준비하셨다면 어떻게 준비하셨는지 궁금해요.
신입으로 입사할 당시에는 포트폴리오 준비에 집중했었는데, 경력 이직 시에는 오히려 면접 준비에 더 집중했어요. 회사에서 하는 업무에서 어떤 성과를 이루었는지 되돌아보는 시간을 가졌고, 공유할 만한 사례는 **개인적으로 관리하고 있는 블로그에 정리하여 작성**했어요. 평소에 제가 사용하는 기술의 오픈소스 기여 활동도 가끔씩 했었는데, 이 부분도 이력서에서 저를 어필하는 데 도움이 됐어요.
 
-김하림, 배달의 민족 주문웹프론트개발팀 웹 프론트엔드
 
### Q. 이력서에는 주로 어떤 내용을 담아내셨나요?
제가 해왔던 경험을 모두 다 담았어요. 3학년 때 스타트업에서 인턴으로 일하며 데이터 관련 개발을 했던 것, 이후 분석에 흥미를 느껴 공부를 더 하고, 더 큰 기업에서 데이터 분석 업무를 했던 것, 네이버에서 주최하는 데이터 분석 대회에 참여한 경험 등을 차례대로 정리했어요. 이러한 과정들을 꾸준히 블로그에 올렸더니, 블로그를 통해 연락이 와서 또 다른 일을 할 기회도 생겼어요. 이런 경험들을 이력서에 적어냈어요.
 
서버든 프론트엔드든 자신이 처음부터 끝까지 프로젝트를 해보는 경험은 중요하다고 생각해요. 기업에서 신입 엔지니어를 채용하는 경우에는 지원자의 태도나 관심, 열정을 중요하게 보는 것 같아요. **가고 싶은 회사의 도메인과 꼭 일치하지 않더라도 어떤 프로젝트를 했고 어떤 부분을 고민했는지를 어필**하면 좋습니다. 때문에 기록이 중요한 것 같아요. 저는 면접 시 제 블로그를 모두 보여드렸어요.
 
-하디, 쏘카 데이터 엔지니어링팀 데이터 엔지니어
 
### Q. 이력서와 포트폴리오는 어떻게 준비하셨나요? 준비 중 어려웠던 부분은 무엇이었나요?
이력서와 포르폴리오를 만들어보셨다면 모두 공감하시겠지만, 준비가 어려워요. 🤣
어떤 내용을 적어야 할지, 어디서부터 어디까지 적어야 할지 기준을 세우기 힘들어요. 특히 실무 경험이 없는 상태에서는 면접관이 어떤 내용을 보고 싶어 할지 예측하기가 어렵더라고요.
 
그래서 저는 면접관의 입장을 알 수 있을 만한 분께 조언을 구했습니다. **프로젝트 이력과 사용 가능 기술 등을 정리한 이력서와 포트폴리오를 미리 준비한 뒤 피드백을 부탁**드렸어요.
 
개인 포트폴리오 사이트는 취미로 재미 삼아 만들었는데요. 처음에는 제가 기획부터 디자인, 프론트, 백엔드를 모두 진행해보고 싶다는 생각으로 시작했어요. 그런데 하다보니 누군가에게 자랑하고 싶다는 마음이 커지면서 3번의 큰 리팩토링을 할 만큼 정성을 들이게 되었습니다. **무엇보다도 자신이 한 프로젝트는 반드시 기록해두는 것**, 나중에 잊어버리지 않기 위해서라도 꼭 필요하다고 생각해요.
 
-박경선, 라인게임즈 플랫폼실 백엔드 개발자
 
 
지금까지 네카라쿠배에 합류한 개발자들이 이력서와 포트폴리오를 어떻게 준비했는지, 그리고 그 과정에서 얻은 꿀팁들을 살펴보았습니다. 이를 참고하여 여러분에게 가장 잘 맞는 방식으로 차근차근 준비해 나가시길 바랍니다. 여러분의 노력과 성장이 결국 원하는 목표로 이어지기를 응원합니다! 💪
 
*※본 글은 2022년 12월에 최초 작성된 콘텐츠입니다.*
 
 
[![AI BE_배너.jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/f2ef708f-59d8-4e51-a27e-49b0b60d77fe/AI%20BE_%E1%84%87%E1%85%A2%E1%84%82%E1%85%A5.jpg)](https://school.programmers.co.kr/learn/courses/25186?utm_source=prgmblog&utm_medium=social&utm_campaign=school_25186_blog&utm_content=25186_banner)

네카라쿠배를 꿈꾸는 개발자를 위한 꿀팁: 이력서·포트폴리오 준비편

프로그래머스 백엔드 데브코스 1기 수료 후 채널코퍼레이션에 백엔드 개발자로 입사한 황일용 님과의 인터뷰입니다. 작은 스타트업에서의 실무 경험을 바탕으로 성장에 갈증을 느껴 데브코스에 합류한 일용 님의 이야기. 5개월간의 몰입 학습과 열정적인 동료들과의 협업을 통해 한 단계 도약한 성장기를 만나보세요!
 
 
# 프로그래머스 백엔드 데브코스를 어떻게 알게 되셨나요?
데브코스에 합류하기 전 작은 스타트업 백엔드 개발자로 일을 하고 있었습니다. 하지만 **업무를 진행하면서 개발 지식에 비어 있는 부분이 많다는 걸 느꼈고, 이를 체계적으로 채울 수 있는 방법을 찾다가 부트캠프 참여를 결심**했어요. 평소 알고리즘 문제를 풀 때 프로그래머스 사이트를 방문했었는데, 백엔드 데브코스 모집 배너를 보게 되었어요.
 
# 백엔드 데브코스를 선택한 이유는 무엇인가요?
커리큘럼과 진행 방식을 자세히 보니 저에게 꼭 필요한 내용이라는 생각이 들었어요. 특히, 단순히 누구나 들을 수 있는 과정이 아니라 **지원서, 실력 테스트, 면접을 통해 학습 의지와 자세를 갖춘 교육생을 선발한다는 점이 인상 깊었어요**. 이런 환경이라면 열정 넘치는 동료들을 만나 함께 자극을 받으며 성장할 수 있겠다는 확신이 들었습니다. 또, 내일배움카드를 통해 교육비를 지원받을 수 있다는 점도 결정에 큰 도움이 되었어요.
 
# 백엔드 데브코스 과정을 통해 이루고자 했던 목표는 무엇이었나요?
백엔드 데브코스를 통해 **기본기를 채움과 동시에 성장하는 자세**를 갖춘 주니어 개발자가 되는 것이 목표였습니다. 또한 교육 과정을 함께 헤쳐 나갈 **동료들을 만나, 적극적으로 소통하고 협업**하는 방법을 배우고 싶었습니다.
 
# 목표를 어느 정도 달성하셨나요? 앞으로 어떤 것들을 보완해 나가고 싶으신가요?
데브코스를 진행하면서 **부족한 개발 지식들에 대해 어떻게 채워나갈 것인지, 애자일한 협업 방식이 무엇인지 프로젝트를 진행하며 배울 수 있었어요**. 현재는 업무에 적응하느라 많이 느슨해져 있지만, 다시 블로그도 꾸준히 할 생각이고 개발 스터디에도 참여하며 부족한 부분을 보완해 나가고 싶습니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/e71736cd-20db-4ab2-a82c-2ea22a490eb2/image.png)
👆 일용 님의 기술 블로그
 
# 5개월간 공부를 하면서 가장 도움이 되었던 부분은 무엇인가요?
**멘토링과 팀 스터디**가 많은 도움이 되었습니다. 멘토님은 실무와 스터디에서 얻은 다양한 지식과 유용한 정보를 많이 공유해 주셨고, 제 커리어를 어떻게 성장시키면 좋을지, 어떤 자세를 가져야 할지에 대한 방향을 잡을 수 있었어요.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/559d9768-4ee3-4f7b-870a-37201e4d2707/image.png)
👆 유용한 정보를 수시로 공유 받을 수 있었던 멘토링
 
팀 스터디는 <실전 자바 소프트웨어 개발>이라는 책을 바탕으로 진행되었습니다. 스터디할 때 멘토님이 방향을 잘 잡아 주시기도 하셨고, 질문과 답변이 오고 가는 와중에 어려운 부분이 생기면 적극적으로 알려주셨어요. 그 외에 연관된 지식까지도 알려주셨고요. 처음 참여해 본 스터디였지만, 멘토님 덕분에 끝까지 완주할 수 있었어요.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/d1eb5cec-53ea-4cb8-9e1f-98280ef7b8d8/image.png)
👆 팀원과 함께 진행한 스터디를 정리한 일용 님
 
# 5개월간 힘든 순간은 없었나요? 있었다면 어떻게 극복하셨나요?
취업을 우선순위로 둘 지 학습을 우선순위로 둘 지에 대해 많은 고민이 있었어요. 주변 친구들이나 다른 데브코스 수강생들의 취업 소식을 들을 때마다, '나도 지금 바로 취업을 준비해야 하나?' 하는 생각이 들곤 했죠.
 
하지만 멘토님께서 "**데브코스에 참여한 이상 학습에 집중하다 보면 분명 성장한 자신을 마주하게 될 거고, 그때 더 자신 있게 취업에 도전할 수 있을 것**"이라고 말씀해 주셨어요. 그 조언 덕분에 다시 마음을 다잡을 수 있었습니다.
 
그리고 수료를 목표로 묵묵히 열심히 공부하는 동료들의 모습도 큰 동기부여가 되었어요. 함께 성장하는 환경이 정말 큰 힘이 됐어요.
 
# 프론트엔드 수강생들과 함께한 최종 프로젝트는 어떠셨나요?
**최종 프로젝트는 프론트엔드 수강생들과 함께 프로젝트 기획부터 구현까지 경험해 볼 수 있는 좋은 기회**였어요. 저희 팀은 가족 간에 사라지는 대화를 채우자는 취지로 "우리 가족 이야기를 함께 공유하는 공유 일기" 서비스를 만들었습니다. 제가 맡은 역할은 백엔드 역할 중 AWS를 이용한 인프라 구축과 저에게 분담된 도메인 개발이었습니다. 이를 통해 서비스들이 클라우드에 올라가 어떻게 동작하는지에 대해 자세히 알게 되었고, 노션으로 스크럼을 진행하면서 문서 관리를 어떻게 하면 협업할 때 효율적일지 많이 배울 수 있었어요.
 
# 함께한 동료들은 어땠나요?
모두 열정적이며 호기심이 많았어요. 그래서 팀 프로젝트나 스터디 활동에 적극적으로 참여하는 모습을 보면서 저도 동기부여가 많이 되었죠. 이런 팀원들과 함께 사소한 것이라도 나누는 점이 좋았습니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/a25e96e1-c1a0-47a6-b0da-8287a54365fd/image.png)
👆 최종 프로젝트를 개선하기 위해 팀원들과 협업한 흔적
 
# 이력서와 면접 준비는 어떻게 하셨나요?
백엔드 데브코스 특강 중 '**이력서 준비 & 면접 특강**'이 큰 도움이 되었습니다. 단순히 이력서를 작성하는 방법이 아니라, 이력서가 왜 필요하며 취업 과정에서 어떻게 쓰일지에 대해 설명해 주신 점이 매우 인상적이었어요. 또한 면접 특강을 들으며 면접에 대한 감각을 키울 수 있었습니다.
 
# 수료 후 달라진 점이 있나요?
주니어 개발자가 어떻게 성장해야 하는지에 대해 잘 알게 되었고, 제가 가진 지식을 나만 간직하고 있는 것이 아니라 다른 사람들과 공유함으로써 함께 성장하는 방법에 대해 배우게 된 것 같습니다.
 
# 후배 수강생들을 위한 응원의 한마디 부탁드려요!
많은 분들께서 취업에 대해 가장 크게 고민하고 계실 텐데요. 하지만 너무 조급할 필요가 없다고 생각합니다. **데브코스에서의 시간은 실력 있는 개발자로 성장할 수 있는 중요한 발판**이 될 수 있다고 믿거든요.
 
혹시 지금 힘들다고 느끼더라도, 옆에 있는 동기들과 함께라면 끝까지 완주할 수 있을 거예요. 끝까지 화이팅입니다!
 
 
*※본 글은 2022년 2월에 최초 작성된 콘텐츠입니다.*

 
 
[![BE_배너.jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/973d28d3-a2ab-47a7-b9f5-7bbc12d52e55/BE_%E1%84%87%E1%85%A2%E1%84%82%E1%85%A5.jpg)](https://school.programmers.co.kr/learn/courses/25244?utm_source=prgmblog&utm_medium=social&utm_campaign=school_25244_blog&utm_content=25244_banner)

[데브코스 후기] 스타트업 개발자에서 실력을 다진 주니어 개발자로! - 백엔드 1기 수료생 황일용 님

안녕하세요, 프로그래머스입니다.

2월을 맞이하여, 프로그래머스의 귀여운 마스코트 머쓱이가 그려진 **2월 캘린더 배경화면**과 줌(Zoom)이나 구글 미트(Google Meet)같은 화상 회의에서 사용 가능한 **줌 배경**을 준비했습니다. 💻

지금 바로 다운로드하고, 남은 2월을 머쓱이와 함께 즐겨보세요! 🐥 
 
 
# 2월 머쓱이 캘린더
![머쓱이 2월 캘린더(외부용)-CHOCO수정(MAC).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/442970b8-0e4f-430b-bcfd-c24ad44e476c/%E1%84%86%E1%85%A5%E1%84%8A%E1%85%B3%E1%86%A8%E1%84%8B%E1%85%B5%202%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%8F%E1%85%A2%E1%86%AF%E1%84%85%E1%85%B5%E1%86%AB%E1%84%83%E1%85%A5%28%E1%84%8B%E1%85%AC%E1%84%87%E1%85%AE%E1%84%8B%E1%85%AD%E1%86%BC%29-CHOCO%E1%84%89%E1%85%AE%E1%84%8C%E1%85%A5%E1%86%BC%28MAC%29.png)

![머쓱이 2월 캘린더(외부용)-Loveshot(MAC).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/4d993574-f657-4580-bbbb-f89d93463a44/%E1%84%86%E1%85%A5%E1%84%8A%E1%85%B3%E1%86%A8%E1%84%8B%E1%85%B5%202%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%8F%E1%85%A2%E1%86%AF%E1%84%85%E1%85%B5%E1%86%AB%E1%84%83%E1%85%A5%28%E1%84%8B%E1%85%AC%E1%84%87%E1%85%AE%E1%84%8B%E1%85%AD%E1%86%BC%29-Loveshot%28MAC%29.png)

![머쓱이 2월 캘린더(외부용)-POSTCARD(Center).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/773be0a0-9aa9-45f9-a390-f0fc16884c23/%E1%84%86%E1%85%A5%E1%84%8A%E1%85%B3%E1%86%A8%E1%84%8B%E1%85%B5%202%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%8F%E1%85%A2%E1%86%AF%E1%84%85%E1%85%B5%E1%86%AB%E1%84%83%E1%85%A5%28%E1%84%8B%E1%85%AC%E1%84%87%E1%85%AE%E1%84%8B%E1%85%AD%E1%86%BC%29-POSTCARD%28Center%29.png)

![머쓱이 2월 캘린더(외부용)-POSTCARD(MAC).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/3fb8f6ab-ffb8-42c2-b741-59f4f6bb2bd8/%E1%84%86%E1%85%A5%E1%84%8A%E1%85%B3%E1%86%A8%E1%84%8B%E1%85%B5%202%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%8F%E1%85%A2%E1%86%AF%E1%84%85%E1%85%B5%E1%86%AB%E1%84%83%E1%85%A5%28%E1%84%8B%E1%85%AC%E1%84%87%E1%85%AE%E1%84%8B%E1%85%AD%E1%86%BC%29-POSTCARD%28MAC%29.png)
 
더 많은 배경화면(Mac, Window)은 아래 링크에서 확인 가능합니다.
👉 [머쓱이 2월 캘린더 보러가기](https://prgrms.notion.site/zip-1993e47046bf80629692c4ddef6a01bf)

# 2월 머쓱이 줌배경
![2월 머쓱 줌 배경화면 -Brown_Postcard(기본버전).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/853e75e4-71e2-4f16-8015-82cb7f95c651/2%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%86%E1%85%A5%E1%84%8A%E1%85%B3%E1%86%A8%20%E1%84%8C%E1%85%AE%E1%86%B7%20%E1%84%87%E1%85%A2%E1%84%80%E1%85%A7%E1%86%BC%E1%84%92%E1%85%AA%E1%84%86%E1%85%A7%E1%86%AB%20-Brown_Postcard%28%E1%84%80%E1%85%B5%E1%84%87%E1%85%A9%E1%86%AB%E1%84%87%E1%85%A5%E1%84%8C%E1%85%A5%E1%86%AB%29.png)

![2월 머쓱 줌 배경화면 -Ivory_Postcard(기본버전).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/c021f9bf-5344-41a6-b4c7-04eaebd3cc1d/2%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%86%E1%85%A5%E1%84%8A%E1%85%B3%E1%86%A8%20%E1%84%8C%E1%85%AE%E1%86%B7%20%E1%84%87%E1%85%A2%E1%84%80%E1%85%A7%E1%86%BC%E1%84%92%E1%85%AA%E1%84%86%E1%85%A7%E1%86%AB%20-Ivory_Postcard%28%E1%84%80%E1%85%B5%E1%84%87%E1%85%A9%E1%86%AB%E1%84%87%E1%85%A5%E1%84%8C%E1%85%A5%E1%86%AB%29.png)

![2월 머쓱 줌 배경화면 -Stretch&Sweets_Pink(기본버전).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/4814e3b5-0753-4706-9acf-c41adc0b51ba/2%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%86%E1%85%A5%E1%84%8A%E1%85%B3%E1%86%A8%20%E1%84%8C%E1%85%AE%E1%86%B7%20%E1%84%87%E1%85%A2%E1%84%80%E1%85%A7%E1%86%BC%E1%84%92%E1%85%AA%E1%84%86%E1%85%A7%E1%86%AB%20-Stretch%26Sweets_Pink%28%E1%84%80%E1%85%B5%E1%84%87%E1%85%A9%E1%86%AB%E1%84%87%E1%85%A5%E1%84%8C%E1%85%A5%E1%86%AB%29.png)

![2월 머쓱 줌 배경화면 -Zoom Meeting(기본버전).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/a7a2ce34-f158-46e7-ae37-92a7160b9a26/2%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%86%E1%85%A5%E1%84%8A%E1%85%B3%E1%86%A8%20%E1%84%8C%E1%85%AE%E1%86%B7%20%E1%84%87%E1%85%A2%E1%84%80%E1%85%A7%E1%86%BC%E1%84%92%E1%85%AA%E1%84%86%E1%85%A7%E1%86%AB%20-Zoom%20Meeting%28%E1%84%80%E1%85%B5%E1%84%87%E1%85%A9%E1%86%AB%E1%84%87%E1%85%A5%E1%84%8C%E1%85%A5%E1%86%AB%29.png)
 
더 많은 줌 배경화면(기본, 미러 버전)은 아래 링크에서 확인 가능합니다.
👉 [머쓱이 줌 배경화면 보러가기](https://prgrms.notion.site/zip-1993e47046bf80629692c4ddef6a01bf)

프로그래머스 마스코트 '머쓱이' 2월 캘린더 & 줌 배경화면 무료 배포 💻 

취업 준비를 위해 프로그래머스 백엔드 데브코스에 참여한 7기 수료생 강휘윤 님의 인터뷰입니다.
휘윤 님은 약 6개월간 데브코스에 참여하며 실무 관점의 코드 작성과 협업을 경험하고, 막연했던 개발자의 길을 구체적인 성장으로 만들어 나갔다고 하는데요.
멘토링부터 프로젝트, 취업 지원까지 경험하며 성장한 휘윤 님의 학습 여정을 지금 바로 만나보세요!
 

<div style="position: relative; max-width: 100%; padding-bottom: 56.25%; height: 0;"><iframe width="560" height="315" src="https://www.youtube.com/embed/Mtr-ss3w420?si=yUvPrMztobOqjnfo" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen="" style="position: absolute; position: absolute; top: 0; left: 0; width: 100%; height: 100%;"></iframe></div>

 
## 안녕하세요. 자기 소개 부탁드립니다.
안녕하세요. 프로그래머스 **백엔드 데브코스 7기**를 수료한 강휘윤입니다.
기술적 최적화를 중요하게 생각하며, 항상 사용자가 쓰기 좋은 프로그램을 만드는 개발자가 되기 위해 노력하고 있습니다.
프로그래머스 데브코스를 통해 많은 성장을 이루었고, 현재는 현업 개발자가 되기 위해 취업을 준비하고 있습니다.
 
![스크린샷 2026-02-20 오후 1.56.28.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/b3106d76-af14-480b-a38d-08af27068aed/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202026-02-20%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%201.56.28.png)
 
### 🔍 휘윤 님의 개발 블로그 보러가기
* [개발 블로그](https://velog.io/@gnldbs1004/posts)

 
 
## 프로그래머스 데브코스는 어떻게 알게 되셨나요? 많은 부트캠프 중 데브코스를 선택하신 이유는 무엇인가요?
검색을 통해 데브코스를 알게 되었던 것 같아요. 부트캠프를 알아보다 보니 과정은 많았지만, 대면 수업은 현실적으로 부담이 있었고, 원격 과정 중에는 관리가 잘 되지 않는 곳도 있다는 이야기를 들었습니다.
 
프로그래머스 데브코스는 **체계적인 관리** 속에서 다양한 수준에 맞춘 강의를 제공하고, **수강생들이 학습에 집중할 수 있는 환경**이 잘 조성되어 있다고 느껴 선택하게 되었습니다.
 
 
## 데브코스에 참여하며 가장 기억에 남는 경험은 무엇인가요?
멘토링을 통해 **코드 리뷰**를 받았던 경험이 가장 기억에 남습니다. 현업에서 일하고 계신, 어쩌면 선배 또는 선임이 될 수도 있는 개발자분들께 직접 리뷰를 받으면서 고쳐야 할 부분은 고치고, 잘 작성한 부분에 대해서는 칭찬도 받을 수 있었습니다.
 
실무 관점에서의 코드 작성이 늘 막연하게 느껴졌는데, **멘토링을 통해 실무에서는 어떤 기준으로 코드를 바라보고 작성하는지를 배울 수 있었던 귀중한 시간**이었습니다. 특히 칭찬을 받았던 경험을 통해 '현업에 나가도 잘할 수 있겠구나'라는 자신감을 얻을 수 있었습니다.
 
![코드리뷰 깃허브 사진.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/58bb7549-6e1f-4aa8-a606-838bf1c963cd/%E1%84%8F%E1%85%A9%E1%84%83%E1%85%B3%E1%84%85%E1%85%B5%E1%84%87%E1%85%B2%20%E1%84%80%E1%85%B5%E1%86%BA%E1%84%92%E1%85%A5%E1%84%87%E1%85%B3%20%E1%84%89%E1%85%A1%E1%84%8C%E1%85%B5%E1%86%AB.png)
⬆️ 실무 관점에서의 코드 작성을 고민하도록 도와준 멘토링과 코드 리뷰
 
 
## 역량진단평가는 학습 과정에 어떤 도움이 되었나요?
코드를 작성하다 보면 잘하는 부분만 반복하거나, 반대로 취약한 부분에 매물되어 시간을 낭비하기 쉬운 것 같습니다. 또, CS 공부를 하면서도 '내가 제대로 공부하고 있는 게 맞나?'라는 고민이 들 때가 많았고요.
 
역량진단평가는 그런 점에서 **현재 나의 학습 상태를 객관적으로 점검**할 수 있는 좋은 기회였습니다. 잘하고 있는지, 대충 넘어가고 있는 부분은 없는지 돌아볼 수 있어 학습 방향을 잡는 데 큰 도움이 되었습니다.
 
 
## 최종 프로젝트에서는 어떤 서비스를 만들었나요?
**공연에 대한 경험을 개선할 수 있는 '내 콘서트를 부탁해'라는 서비스**를 만들었습니다. 공연 정보를 단순히 나열하는 데서 그치지 않고, 공연을 예매하고 관람한 뒤 돌아오기까지의 전 과정을 하나의 경험 흐름으로 보고 이를 개선하고자 한 서비스입니다. 공연 정보를 공유하고, 함께 공연을 보러 갈 사람을 모집하거나 공연 일정 관리를 할 수 있는 기능을 제공했습니다.
 
저는 **공연 도메인을 담당**해 공연 정보를 수집하고, 이를 사용자에게 제공하는 기능을 구현했습니다. 공연정보통합전산망 API를 활용해 데이터를 저장하고, API에서 제공하지 않는 공연 이메일 정보를 어떻게 다룰지 고민하는 것부터 검색, 추천 기능까지 많은 고민을 했습니다.
 
이 모든 과정을 혼자서가 아니라 팀원들과 함께 논의하며 해결해 나갔고, 결과적으로 완성도 높은 프로젝트를 만들 수 있었다고 생각합니다.
 
약 한 달간 프로젝트를 진행하며 팀원들과 협업하는 경험을 쌓을 수 있었고, 특히 프론트엔드 수강생분들과의 협업을 통해 개발자로서 한 단계 더 성장할 수 있었습니다.
 
 
![최종프로젝트(1).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/f1254693-d1a6-453a-b9c3-0b2e03c98725/%E1%84%8E%E1%85%AC%E1%84%8C%E1%85%A9%E1%86%BC%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%84%8C%E1%85%A6%E1%86%A8%E1%84%90%E1%85%B3%281%29.png)

⬆️ 최종 프로젝트 '내 콘서트를 부탁해' 서비스 메인 페이지
 
![최종프로젝트(2).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/4cf56936-965e-407a-879c-cc83817dfaee/%E1%84%8E%E1%85%AC%E1%84%8C%E1%85%A9%E1%86%BC%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%84%8C%E1%85%A6%E1%86%A8%E1%84%90%E1%85%B3%282%29.png)

⬆️ 내 콘서트를 부탁해 - 아티스트 둘러보기
 
![최종프로젝트(3).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/226aa4d6-01af-44dd-a3fb-d9feed9d7226/%E1%84%8E%E1%85%AC%E1%84%8C%E1%85%A9%E1%86%BC%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%84%8C%E1%85%A6%E1%86%A8%E1%84%90%E1%85%B3%283%29.png)

⬆️ 내 콘서트를 부탁해 - 공연 동행 찾기

 
 
### 🔍 최종 프로젝트 보러가기
* [GitHub](https://github.com/prgrms-web-devcourse-final-project/WEB7_9_codecrete_BE)
* [배포 URL](https://www.naeconcertbutakhae.shop/home)
 
 
## 데브코스를 통해 이루고자 했던 목표는 무엇이었나요? 얼마나 달성하셨나요?
솔직히 말씀드리면, 데브코스에 참여한 가장 큰 목표는 취업이었습니다. 달성도를 수치로 표현하기는 어렵지만, 이전보다 훨씬 잘 준비된 상태라고는 자신 있게 말할 수 있습니다.
 
현재는 데브코스에서 진행한 최종 프로젝트와 학습 경험을 바탕으로 포트폴리오를 정리하고 있고, 마무리되는 대로 이력서를 넣을 예정입니다. 
 
데브코스 이전에는 막연한 자신감만 있었다면, **지금은 '이런 방식으로 문제를 해결할 수 있는 개발자'라고 설명할 수 있는 근거가 생겼다는 점이 가장 큰 변화**라고 생각합니다.
 
 
## 수업을 진행해주신 강사님은 어떠셨나요?
단순히 구현 방법을 알려주는 데 그치지 않고, 기술적 고민을 어떻게 풀어가야 하는지를 중심으로 설명해 주신 점이 인상 깊었습니다. 덕분에 실전 중심의 수업임에도 불구하고 다양한 개념을 잘 이해할 수 있었습니다.
 
또한 여러 과제를 통해 스스로 학습하고 심화할 수 있는 시간을 충분히 가질 수 있었던 점도 좋았습니다. **데브코스 커리큘럼을 성실히 따라가기만 해도 충분한 성장을 이룰 수 있겠다**는 생각이 들었습니다.
 
 
## 함께한 동료들은 어땠나요?
내성적인 분들이 많으셔서, 오히려 제가 파이팅 넘치게 응원하곤 했습니다. 하지만 필요한 순간에는 모두 적극적으로 나서주셔서 좋았습니다.
 
학습 중에 어려운 부분을 팀원들에게 공유하며 "나만 어려운 게 아니구나", "다들 같은 고민을 하고 있구나"하고 위로도 받기도 했습니다.
 
**팀 프로젝트를 통해 다양한 사람들과 협업하며 소통하는 방법과 협업 방식을 배울 수 있었고, 동료들의 좋은 점을 배우며 함께 성장**할 수 있었습니다.
 
![팀원과 zep으로 소통하는 사진.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/bcf6926f-d7d9-4fb9-a592-aab7952e71fe/%E1%84%90%E1%85%B5%E1%86%B7%E1%84%8B%E1%85%AF%E1%86%AB%E1%84%80%E1%85%AA%20zep%E1%84%8B%E1%85%B3%E1%84%85%E1%85%A9%20%E1%84%89%E1%85%A9%E1%84%90%E1%85%A9%E1%86%BC%E1%84%92%E1%85%A1%E1%84%82%E1%85%B3%E1%86%AB%20%E1%84%89%E1%85%A1%E1%84%8C%E1%85%B5%E1%86%AB.png)
⬆️ Zep에서 동료들과 소통했던 시간들
 
 
## 데브코스 멘토링에 대한 만족도는 어떠한가요?
다양한 분야에서 일하고 있는 멘토님들을 만나 개발에 대한 식견을 넓힐 수 있어 좋았습니다. 한 멘토님께서는 코드를 아주 날카롭게 리뷰해주셨는데, 당시에는 많은 충격을 받았지만, **지나고 나니 오히려 큰 자극**이 되었던 것 같습니다. **더 좋은 코드를 어떻게 만들어나가야 할지 생각해보는 시간**이었던 것 같아요.
 
이외에도 멘토님의 실제 취업 경험이나 커리어 전략을 들으며 방향성을 잡을 수 있었고, 커뮤니티에서 흔히 들리는 이야기들과는 달리 **현업의 현실을 자세히 짚어주신 점**도 많은 도움이 되었습니다.
 
지금 돌이켜보면 멘토님들께 질문을 더 많이 하지 못한 점이 아쉬울 정도로, 값진 시간이었던 것 같아요.
 
 
## 데브코스의 취업 지원 서비스(데브패스)는 어떻게 이루어졌나요?
지피지기면 백전백승이라는 말이 있죠. 취업도 마찬가지라고 생각합니다. 
나를 알고 내가 가고 싶은 회사를 알면, 취업에 한 걸음 더 가까워질 수 있다고 생각했습니다.
 
 
![스크린샷 2026-02-20 오후 1.59.48.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/51444904-7f57-457b-8923-983986f02396/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202026-02-20%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%201.59.48.png)
 
 
데브코스의 취업 지원은 **취업 준비도**를 점검하고 목표를 설정한 후, 나의 현재 상황을 객관적으로 파악하는 것부터 시작되었습니다. 이후에는 **학습과 프로젝트**를 통해 꾸준히 성장하면서, 내가 지원하고 싶은 회사의 수준에 맞게 역량을 끌어올리는 과정으로 이어졌습니다.
 
또한 중간중간 진행된 **특강을 통해 현업에서 중요하게 보는 역량을 이해**할 수 있었고, **직무 인터뷰**를 통해 실제 실무 상황을 구체적으로 알 수 있었습니다.
 
마지막으로 **취업 컨설팅을 통해 나의 강점과 보완점을 점검**하고, 포트폴리오와 이력서를 다듬어 지원하고 싶은 회사에 어필할 수 있는 '필살기'를 준비할 수 있었습니다.
 
이외에도 여러 특강을 통해 CS 기반 문제 해결 능력이 탄탄한 신입 개발자를 기업에서 원한다는 점을 알게 된 것이 기억에 남습니다.
 
![취업 준비 자료 파일 사진.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/591557d2-0d7e-487b-a37b-4ea4bdaebac5/%E1%84%8E%E1%85%B1%E1%84%8B%E1%85%A5%E1%86%B8%20%E1%84%8C%E1%85%AE%E1%86%AB%E1%84%87%E1%85%B5%20%E1%84%8C%E1%85%A1%E1%84%85%E1%85%AD%20%E1%84%91%E1%85%A1%E1%84%8B%E1%85%B5%E1%86%AF%20%E1%84%89%E1%85%A1%E1%84%8C%E1%85%B5%E1%86%AB.png)
⬆️ 취업 준비를 위해 정리한 자료들
 
 
## 백엔드 데브코스를 한 문장으로 표현한다면?
모든 부분에서 배울 점이 있었던 황금 같은 시간,
챙겨가는 것은 결국 나 하기 나름이다.
 
 
## 앞으로 어떤 개발자로 성장하고 싶으신가요?
즐겁게 개발하고, 꾸준히 성장하는 개발자가 되고 싶습니다.
 
 
## 데브코스 수강을 고민하는 분들께 추천의 한마디 부탁드립니다.
'어떻게 해야 개발을 잘할 수 있을까?', '좋은 개발자가 될 수 있을까?'라는 고민을 하는 분들이 많을 거라고 생각합니다. 정답이 딱 정해져 있지 않기 때문에 더 막막하게 느껴지기도 하고요.
 
프로그래머스 데브코스는 **그런 막막함을 체계적인 교육 과정과 실무형 프로젝트를 통해 자신감으로 바꿔주는 시간**이었습니다. 적극적으로 참여한다면 분명 의미 있는 성장을 경험하실 수 있을 거라고 생각합니다.
 
 
*강의 운영 사정에 따라 세부 프로그램 내용은 변경될 수 있습니다.*
 
 
[![DEV-BE-coding-test-02(1456x180).jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/f5675829-b310-479d-9572-9b6932a9d28b/DEV-BE-coding-test-02%281456x180%29.jpg)](https://school.programmers.co.kr/learn/courses/25579?utm_source=prgmblog&utm_medium=social&utm_campaign=school_25579_sales&utm_content=blog_banner)

[데브코스 후기] 막연한 자신감에서 벗어나 문제 해결력을 갖춘 개발자로 성장했어요 - 백엔드 7기 강휘윤 님

국민취업지원제도는 **취업을 희망하는 구직자**에게 맞춤형 **취업지원서비스**와 함께 **생계 지원**을 제공하여, 구직 활동을 촉진하고 취업 역량을 강화시키기 위한 제도입니다. 
 
26년에 새롭게 적용된 내용으로, 국민취업지원제도 참여자가 **KDT 훈련을 수강할 수 있는 조건과 신청 절차**를 알려드릴게요!
 
 
## 나도 신청할 수 있을까?
2026년부터 국민취업지원제도는 신청 문턱을 낮추고 구직 혜택을 강화하는 방향으로 새롭게 개편됩니다. 
 
유형에 따라 적용되는 대상과 혜택에 약간의 차이가 있어, 나에게 맞는 유형을 아래 표로 확인해보세요!
 
| | 1유형 | 2유형 |
| --- | --- | --- |
| 대상 | 가구 단위 중위소득 60% 이하 | 1 유형에 해당하지 않는 저소득층, 청년(18~34세) 소득 무관, 중장년(35~69세) 중위소득 100% 이하 |
| 혜택 | 구직촉진 수당(월 최대 60만 원, 6개월) 지원 ***(25년 참여자도 26년부터 동일하게 적용)*** | 취업활동비용 지원 ***(26년부터 훈련참여지원수당 폐지)*** |
| KDT 훈련비 지원 | 원칙적으로 100% 전액 지원 | 일부 자부담금 발생 가능성 있음 |

 
변경 포인트를 살펴보면, 2 유형은 우리 청년들과 저소득층 분들을 위해 신청 조건이 완화되었는데요. 이제 소득 요건 걱정 없이 더 많은 분이 혜택을 누릴 수 있게 되었고 훈련수당 대신 실제 취업 활동에 꼭 필요한 비용들을 콕 집어 지원합니다!
 
1 유형은 매달 받던 구직촉진 수당이 50만 원에서 60만 원으로 상향되었어요. 25년 참여자분들도 26년부터는 똑같은 개편 혜택을 받을 수 있답니다.
 
### 💡 **국민취업지원제도 참여자도 국민내일배움카드로 KDT 수강 가능!**

국민취업지원제도 참여자일지라도 **KDT 훈련 과정은 '국민내일배움카드'를 통해 운영**됩니다. 
 
**일반 구직자보다 더 높은 수준의 훈련비** 지원을 받게 되고, **취업에 성공하면 최대 150만 원의 취업성공수당을 지원**합니다. 
 
*(지원자에 따라 훈련 지원금이 상이하므로, 고용센터에 확인 필요)*
 
 
## 국민취업지원제도 온라인 신청방법은?
국민취업지원제도는 고용24를 통해 간편하게 신청할 수 있습니다.
 
* 신청 경로: 고용24 홈페이지 접속 -> 취업지원 카테고리 -> 국민취업지원제도 -> 취업지원신청
 

![스크린샷 2025-12-16 오후 7.57.28.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/24abc8e6-0726-40eb-bc2a-bcc7ee883116/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202025-12-16%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%207.57.28.png)
 
먼저 소득 및 재산 확인 서류가 첨부된 신청서를 제출한 후, 관할 고용센터에서 지원 자격 요건을 심사합니다. 보통 신청부터 심사까지 약 1개월 내외 소요됩니다.
 
### ⚠️ 국민취업지원제도 신청 전, 고용24에서 꼭 확인해야할 사항!
* 제도 안내 동영상(1회차, 2회차) 수강
* 구직 신청 여부(반드시 구직 신청이 선행되어야 합니다)
* 준비 서류 확인(가구재산·취업경험, 취업취약계층 등)
 
 
## 국민취업지원제도 참여자가 KDT 훈련 신청하는 방법은?
국민취업지원제도 참여자로 승인받은 후, KDT 훈련을 수강하는 절차는 **반드시 담당 상담사와의 협의를 통해 진행**해야 합니다. 먼저, 담당 상담사에게 **KDT 훈련 수강 의사를 밝히고** **수립된 취업 활동 계획(IAP)을 명시적으로 포함**해야 합니다. 
 
KDT 훈련을 위해서는 국민내일배움카드가 필요한데요. 만약 기존에 카드가 없었다면 발급받아야 합니다.
 
* 국민내일배움카드 발급에 대한 자세한 정보 👉 [여기서](https://community.programmers.co.kr/post/12904) 확인!

국민내일배움카드를 발급 받은 후, 담당자와 협의하여 KDT 훈련 과정을 검색하고 수강 신청하면 완료! 
 
 
## KDT 훈련 과정, 데브코스에서 시작하세요!
국민취업지원제도와 연계된 KDT 훈련은 복잡하게 느껴질 수 있지만, 막상 시작하면 예상보다 훨씬 간편합니다.
지금 바로 온라인으로 간편하게 신청하고 국취제 지원을 통해 맞춤형 인재를 양성하는 데브코스를 수강해보세요!
 
훈련생분들의 목표 달성을 위해 데브코스는 단순한 교육을 넘어, 실력 향상부터 취업 연계까지 함께하겠습니다!
 
국민내일배움카드 발급 과정이나 KDT 훈련 수강 신청에 대한 문의사항이 있다면 채널톡을 통해 언제든 문의 남겨주세요. 🙌
 
 
**🔍 백엔드 데브코스 알아보기**
[![DEV-BE-coding-test-02(1456x180) (2).jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/4887cc39-a51f-49a0-93b1-f48c2091197d/DEV-BE-coding-test-02%281456x180%29%20%282%29.jpg)](https://school.programmers.co.kr/learn/courses/25487?utm_source=mailchimp&utm_medium=DM&utm_campaign=school_25487_blog&utm_content=25487_banner)

원하는 강의 수강하고 취업 역량까지 UP! 국민취업지원제도 신청 방법 알아보기

"흑백 요리사", 보셨나요? 넷플릭스의 요리 서바이벌 프로그램 흑백 요리사는 방송 직후 시청률 세계 1위를 기록하며 큰 화제를 모았습니다. 이 프로그램은 요리의 맛을 내는 기술뿐만 아니라, 식재료의 품질과 그 안에 담긴 가치를 어떻게 끌어내는지가 얼마나 중요한지 보여줍니다.

요리는 주어진 재료가 일련의 과정을 거쳐 음식이라는 결과로 나오는 것인데요. 이는 데이터가 일련의 과정을 거쳐 성과물로 나오는 AI 개발 과정과 유사한 점이 많습니다. 프로그램 속 출연자들이 경연을 통해 요리 기술을 익히고 성장하는 것처럼, AI 개발 역시 단계별로 필요한 기술과 역량을 습득하며 성장하는 과정입니다. 그렇다면, AI 개발자가 성장하기 위해서는 어떤 로드맵을 따라야 할까요? 실제 어떤 역량과 스킬을 익혀야 하는지 한 단계, 한 단계 살펴보겠습니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/2108c863-5297-486c-b027-7dbbd0681794/image.png)
 
# 1. 문제 정의: 메뉴 선정하기(Choosing the right problem)
"오늘 저녁으로 무엇을 만들까?"를 고민하는 것처럼, AI 프로젝트도 해결하고자 하는 문제를 정의하는 것으로 시작합니다. 예를 들어, **멋진 스테이크 저녁 만들기**라는 **목표**를 세우고, 이를 위해 소고기, 아스파라거스, 토마토 같은 재료(데이터)를 준비합니다. 여기에 프라이팬에 굽는 방법(기술)과 플레이팅 이미지(성과물)까지 구성하는 과정이 바로 문제 정의에 해당합니다.

"나에게 단 1시간이 주어진다면, 문제를 정의하는 데 55분을 쓰고, 해결책을 찾는 데는 오직 5분만 쓰겠다." 아인슈타인이 남긴 이 명언은 문제 정의의 중요성을 단적으로 보여줍니다. AI 개발 역시 시작하기 전에 문제를 철저히 정의하는 것이 핵심이며, 다음 네 가지 질문에 대한 답을 정리하며 문제를 정의할 수 있습니다.
 
```
[Goal] AI 개발의 목적이 무엇인가?
[Input] 어떤 데이터를 사용하는가?
[Method] 어떤 방법을 쓸 것인가?
[Output] 성과물이 무엇인가?
```
 
문제 정의는 곧바로 AI 개발에 뛰어들기 전에 반드시 거쳐야 하는 단계입니다. 이를 위해 먼저 생각하고 정리하고 기록하는 훈련이 중요합니다. 프로그래밍을 시작하기 전에 항상 위 네 가지 질문에 대한 답을 작성해 나간다면 개발 역량뿐만 아니라 프로젝트의 목표와 범위를 명확히 파악할 수 있어 성공 확률을 높일 수 있습니다.

# 2. 수학적 원리: 요리의 기본 원리 이해하기
수학을 모르면서 AI를 개발하는 것은, 온도계의 타이머가 없는 오븐으로 요리하는 것과 같습니다. 요리를 할 수는 있지만 재료가 다 타는지, 덜 익었는지 측정할 수 있는 기준과 개념이 없는 것이죠. 요리에서 온도, 시간, 양의 개념을 이해하는 것처럼, AI 개발에서도 확률과 통계, 함수와 미적분, 선형대수를 이해해야 합니다.

실제 프로젝트를 진행할 때, 기존에 나와 있는 코드를 그대로 사용하는 것이 아니라면, 수학적 원리를 이해하는 것이 매우 중요합니다. 이는 AI 개발자 로드맵에서 수학을 첫 번째 또는 두 번째 단계로 지목하는 이유이기도 합니다. 중고등학교 때의 수학은 문제를 풀기 위해서 배워야 했다면, AI 개발을 위해서는 개념을 이해하고 원리를 활용에 접목하기 위한 수학 공부가 필요합니다. 이에 대해서는 앞으로 시간을 가지고 좀 더 알아보기로 하겠습니다.

# 3. 프로그래밍: 요리 도구 다루기
요리를 할 때 칼, 냄비, 프라이팬 등 주방에 있는 다양한 도구들을 사용합니다. AI 개발에 있어서 Python은 이러한 주방 도구들과 같은 역할을 합니다. 칼을 사용하는 방법을 배우듯 Python의 기본 문법을 익히고, 데이터를 자르고 또 한데 모아야 합니다. 여러 도구를 조합해 요리하듯 다양한 함수와 클래스, 라이브러리를 다룹니다. 여기서 중요한 점은, 칼을 잘 다룬다고 해서 반드시 맛있는 음식을 만들 수 있는 것은 아니라는 것입니다. Python 역시 도구일 뿐, AI 개발의 본질은 문제를 어떻게 정의하고 해결할 것인지에 있다는 점을 잊어서는 안됩니다.

더구나, 생성형 AI가 등장하면서 코딩과 프로그래밍 공부 방식도 크게 변화하고 있습니다. 이제 단순히 문법을 외우고 코드를 직접 작성하는 것만으로는 충분하지 않으며, 문제를 해결하는 능력과 AI와 협업하는 능력이 더 중요해지고 있습니다. 이에 따라 앞으로의 코딩 공부의 방향성은 다음과 같은 몇 가지 핵심 포인트를 중심으로 잡아야 합니다.
 
* 기본 문법은 빠르게 배우되, 실제 문제를 풀면서 자연스럽게 익혀나가기
* 생성형 AI를 활용해 코드를 빠르게 작성하고, **코드를 이해하며 디버깅하는 능력**을 키우기
* 프로젝트 중심의 학습을 통해 **목적에 맞는 코드 작성**을 연습하기
* 데이터 활용, API 연동, Cloud 배포 등 아키텍쳐와 파이프 라인 구축에 대해 학습하기

 
예를 들면, GPT를 이용해 특정 기능을 하는 코드를 생성한 후, 오류를 수정하고 최적화한 후 모듈을 구성하는 것까지 개인이 수행합니다.

# 4. DB 데이터 추출 수집 정제: 식재료 준비하기
SQL을 이용한 데이터 관리는 요리에 필요한 재료를 준비하는 과정과 같습니다. 요리를 할 때 냉동실에 있는 고기를 냉동실에서 바로 썰지 않고 주방으로 가져와 손질합니다. 마찬가지로 기간계(Legacy) 시스템에 있는 데이터는 활용가능한 데이터베이스(DB)로 별도로 옮겨 전처리를 수행합니다. 이때 쿼리(Query)를 통해 원하는 데이터를 접근, 수집, 추출하고, 원하는 구조와 형태로 가공하는 능력이 필요합니다.

여기서 간과하지 말아야 하는 점은 데이터를 다루는 스킬 뿐만 아니라, 올바른 데이터를 선택하는 안목을 길러야한다는 점입니다. 어떤 방법론을 쓰더라도 옳지 않은 데이터를 입력하면 옳지 않은 결과가 나온다는 것은 필연적인 사실입니다. 다음 그림이 바로 데이터의 중요성을 강조하고 있습니다.
 
![Frame 1000003816.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/df4245e3-dc6b-4e5d-8b5b-315455d7ce05/Frame%201000003816.png)
출처: x/@ordax, linkedin/eordax

# 5. 데이터 핸들링 라이브러리: 고급 주방 기구 사용하기
Pandas, Numpy등은 Python으로 데이터를 다루기 위한 기본적인 도구입니다. 음식에 따라 믹서기, 오븐, 토치와 같은 고급 주방 기구가 필요하듯, 데이터 분석에서도 상황에 따라 더 고급스러운 도구와 라이브러리가 필요합니다. 개발자들의 코드 저장소 GitHub에서 커밋(Commit)된 파이썬 라이브러리의 종류와 수를 시각화해보면 다음과 같습니다.

AutoML(오토엠엘), Data(전처리), Explore(탐색적 데이터분석), Math(수학), ML(머신러닝), Viz(시각화) 6개 분야에 38개 패키지를 확인해본 결과 다음과 같은 결과를 얻었습니다. 커리어 목표에 따라 다르지만, 머신러닝 패키지인 scikit-learn(사이킷런)과 데이터 전처리를 위한 판다스(Pandas), 시각화(Matplotlib), 수학 패키지(Numpy, Scipy)가 눈에 띕니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/ee365004-c509-4607-bca7-72b8924dd459/image.png)
출처: https://www.kdnuggets.com/2020/11/top-python-libraries-data-science-data-visualization-machine-learning.html
 

# 6. 시각화: 요리 플레이팅하기
요리를 맛있게 완성하는 것만큼이나, 아름답게 플레이팅하는 것은 중요합니다. "금상첨화", 즉 비단 위에 꽃을 더하듯, 훌륭한 데이터 분석 결과나 인공지능 서비스도 시각화를 만나야 비로소 그 가치를 제대로 인정받을 수 있습니다.

데이터를 시각화하는 방법은 앞서 살펴본 Python의 시각화 패키지(Matplotlib, Bokeh)뿐만이 아닙니다. 최근에는 Microsoft Power BI, Tableau 같은 전문 시각화 툴에 대한 수요도 크게 증가하고 있습니다. 이 도구들은 데이터를 직관적으로 표현해 일반 사용자나 비전문가도 쉽게 이해할 수 있도록 돕고, 보고서 작성에도 유용하게 활용됩니다.

특히 우리나라에서는 "경영정보시각화능력"이라는 국가공인 자격증이 생긴만큼 데이터 시각화의 중요성과 수요가 점차 증가하고 있는 것을 알 수 있습니다. 시각화 능력은 AI 개발과의 협력을 통해 설명 가능한 영역을 보여주고, 인사이트를 도출하는 등 서비스의 질을 높이는데 기여한다는 점을 기억해주세요.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/9864b1d6-35ea-4698-9c8d-a417f08343f3/image.png)

# 7. 머신러닝 알고리즘과 라이브러리: 레시피 개발하기
이 단계는 기존에 알려진 레시피를 튜닝해 새로운 레시피를 개발하는 과정과 유사합니다. 과거 인기 요리 프로그램 "냉장고를 부탁해"를 기억하시나요? 요리사들이 출연자의 냉장고 속 재료를 활용해 최적의 요리를 만드는 프로그램인데요. 요리사들이 냉장고 속 다양한 식재료와 조리법을 결합해 새로운 요리법을 개발하는 것처럼, 머신러닝 개발자들도 여러 알고리즘과 라이브러리를 조합하여 최적의 모델을 만들어냅니다.

머신러닝의 핵심은 문제를 해결하기 위해 적절한 알고리즘을 선택하는 것입니다. 대표적인 머신러닝 알고리즘에는 다음과 같은 것들이 있습니다.

* **회귀 분석(Regression)**: 연속적인 값을 예측하는 알고리즘으로, 집값 예측이나 날씨 예측 등에 사용됩니다.
* **의사결정 나무(Decision Tree)**: 트리 구조를 사용하여 데이터를 분류하거나 회귀 분석을 수행하는 알고리즘으로, 직관적인 해석이 가능합니다.
* **랜덤 포레스트(Random Forest)**: 여러 개의 결정 트리를 조합하여 더욱 안정적인 예측을 제공하는 알고리즘입니다.
* **군집 분석(Clustering Analysis)**: 데이터 내에서 비슷한 특성을 가진 그룹(클러스터)을 찾는 비지도 학습(Unsupervised Learning) 기법입니다. 즉, 사전에 정의된 정답(레이블)없이 데이터를 분석하여 유사한 것끼리 묶는 과정입니다.

새로운 요리를 만들었을 때 시식 평가를 받는 것처럼, 머신러닝 모델의 성능을 평가하는 것도 중요합니다. 정확도(Accuracy), 정밀도(Precision), 재현율(Recall) 등 다양한 지표를 활용해 모델을 평가하고, 새로운 문제에 맞는 평가 기준을 고안하는 능력을 갖추는 것이 중요합니다.

# 8. 딥러닝 알고리즘과 프레임워크: 요리의 예술성 높이기
PyTorch, TensorFlow를 이용한 딥러닝은 요리에 예술성을 더하는 과정과 같습니다. 딥러닝은 다양한 분야에서 활용되며, 각 분야에 따라 적용 기법이 달라집니다. 대표적인 활용 분야는 컴퓨터 비전, 자연어 처리, 강화 학습 등이 있습니다.

* **컴퓨터 비전(Computer Vision)**
: 이미지 분류(CNN), 객체 탐지(YOLO, Faster R-CNN) 등 자율 주행, 의료 영상 분석, 비전 검사 등에 쓰입니다.

* **자연어 처리(Natural Language Processing, NLP)**
: 기계 번역(Transformer, BERT), 감성 분석(RNN, LSTM), 챗봇(GPT) 등 AI 비서, 자동 문서 요약, 검색엔진 등에 쓰입니다.

* **강화 학습(Reinforcement Learning, RL)**
: 이세돌과 바둑 대결로 잘 알려진 AlphaGo, 자율주행 AI, 금융거래 최적화 등 게임, 로보틱스, 자동화 시스템에 쓰입니다.

 딥러닝을 공부하려면 먼저 기초 개념을 익히는 것이 중요합니다. 머신러닝과 딥러닝의 알고리즘 개념을 이해하고, 확률통계, 함수, 선형대수와 같은 수학적 기초지식을 쌓으면 딥러닝의 원리를 더욱 깊이 이해할 수 있습니다.

다음으로는 TensorFlow와 PyTorch 같은 딥러닝 프레임워크를 실습하며, Kaggle, Google Colab 등을 이용해 다양한 예제를 따라 해보는 것이 좋습니다. 최신 기술을 익히기 위해 논문을 읽고 연구 동향을 파악하는 것도 중요합니다. Papers with code나 arXiv에서 최신 딥러닝 논문을 찾아보고, Hugging Face 등에서 최신 모델을 활용하여 실습한다면, 빠르게 발전하는 딥러닝 분야를 따라갈 수 있습니다.

# 9. 데이터 경진대회: 요리 대회 참가하기
머신러닝과 딥러닝을 배우며 실력을 쌓는 가장 좋은 방법 중 하나는 데이터 경진대회에 참가하는 것입니다. Kaggle, Dacon 등의 플랫폼에서는 실제 데이터 문제를 해결할 수 있는 다양한 대회를 제공합니다. 이는 마치 요리사가 요리 대회에 참가하여 실력을 검증받고 성장하는 과정과 같습니다.

처음에는 이미지 분류나 감성 분석 같은 간단한 프로젝트부터 시작할 수 있습니다. 대회를 통해 다양한 문제를 해결하며 실전 감각을 익힐 수 있고, 다른 참가자들의 코드를 분석하면서 새로운 접근법도 배울 수 있습니다. 또한, 대회를 통해 얻은 경험과 포트폴리오는 취업이나 연구 활동에도 큰 도움이 됩니다.

# 10. 실전 프로젝트: 나만의 레스토랑 열기
이제는 배운 내용을 바탕으로 직접 AI 프로젝트를 만들어볼 차례입니다. 요리사가 자신의 레스토랑을 여는 것처럼, 여러분만의 AI 프로젝트를 기획하고 개발해보세요. 예를 들어, "AI를 이용해 개인 맞춤형 건강 식단을 제공하는 서비스를 어떻게 만들 수 있을까"와 같은 문제를 정의하고 해결해 나가는 것입니다.

이 과정에서 프로젝트 기획, 데이터 수집 및 전처리, 모델 개발, 배포까지 전체적인 AI 시스템을 구축하는 경험을 할 수 있습니다. 실제 서비스를 만들어보면서 기술뿐만 아니라 사용자의 니즈를 반영하는 방법도 배울 수 있습니다. 이러한 실전 프로젝트는 AI 전문가로 성장하는 데 필수적인 과정입니다.

이제까지 AI 개발자가 되기 위한 10단계 과정을 요리에 비유하며 알아보았습니다. 10단계의 여정을 거치면서, 여러분은 AI 개발자로 멋지게 성장하게 될 것입니다. 하지만 10단계의 과정에 꼭 국한할 필요도, 순서를 지킬 필요도 없습니다. 그 과정에서 저마다 새로운 맛과 향, 그리고 도전이 기다리고 있으니까요. 이제 여러분만의 특별한 AI 개발 커리어를 만들어보는 건 어떨까요? 기대하겠습니다.
 
 
![Frame 1000003814.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/58163966-5cdf-4be1-8fb6-7b94c6f5ebda/Frame%201000003814.png)

AI 개발자가 되기 위한 10단계 로드맵

안녕하세요, 프로그래머스입니다!
 
따뜻한 봄바람과 함께 벚꽃이 활짝피는 4월이 찾아왔어요. 🌸✨
기분 좋은 4월을 머쓱이와 함께 시작해보세요!
4월 캘린더 배경화면과 화상 회의용 줌(Zoom) 배경을 준비했답니다.
 
원하는 배경을 다운받고, 업무와 학습에 조금 더 집중해보세요.
2025년 4월에도 여러분의 성장을 응원합니다. 💪
 
# 4월 머쓱이 캘린더
![4월 머쓱이 캘린더-20.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/cfc79dc9-3781-40f9-8b55-6f3b88726160/4%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%86%E1%85%A5%E1%84%8A%E1%85%B3%E1%86%A8%E1%84%8B%E1%85%B5%20%E1%84%8F%E1%85%A2%E1%86%AF%E1%84%85%E1%85%B5%E1%86%AB%E1%84%83%E1%85%A5-20.png)
 
![4월 머쓱이 캘린더-22.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/657fef94-802f-48d8-8ed3-bc7bc4ef528f/4%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%86%E1%85%A5%E1%84%8A%E1%85%B3%E1%86%A8%E1%84%8B%E1%85%B5%20%E1%84%8F%E1%85%A2%E1%86%AF%E1%84%85%E1%85%B5%E1%86%AB%E1%84%83%E1%85%A5-22.png)
 
![4월 머쓱이 캘린더-23.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/d33b3fdd-af4d-461d-8afe-a968a2e8a5b1/4%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%86%E1%85%A5%E1%84%8A%E1%85%B3%E1%86%A8%E1%84%8B%E1%85%B5%20%E1%84%8F%E1%85%A2%E1%86%AF%E1%84%85%E1%85%B5%E1%86%AB%E1%84%83%E1%85%A5-23.png)
 
![4월 머쓱이 캘린더-24.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/6e3c9080-aeaa-48d5-8f85-9a91e29de3ae/4%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%86%E1%85%A5%E1%84%8A%E1%85%B3%E1%86%A8%E1%84%8B%E1%85%B5%20%E1%84%8F%E1%85%A2%E1%86%AF%E1%84%85%E1%85%B5%E1%86%AB%E1%84%83%E1%85%A5-24.png)
 
![4월 머쓱이 캘린더-25.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/098cb6e3-8581-4828-92b8-6003dc76add0/4%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%86%E1%85%A5%E1%84%8A%E1%85%B3%E1%86%A8%E1%84%8B%E1%85%B5%20%E1%84%8F%E1%85%A2%E1%86%AF%E1%84%85%E1%85%B5%E1%86%AB%E1%84%83%E1%85%A5-25.png)
 
![4월 머쓱이 캘린더-26.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/3e5f7c3f-7f1a-43f8-b098-e150fa774bc4/4%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%86%E1%85%A5%E1%84%8A%E1%85%B3%E1%86%A8%E1%84%8B%E1%85%B5%20%E1%84%8F%E1%85%A2%E1%86%AF%E1%84%85%E1%85%B5%E1%86%AB%E1%84%83%E1%85%A5-26.png)
 
더 많은 배경화면(Mac, Window)은 아래 링크에서 확인 가능합니다.
👉 [머쓱이 4월 캘린더 보러가기](https://prgrms.notion.site/zip-1993e47046bf80629692c4ddef6a01bf)
 
 
# 4월 머쓱이 줌 배경
![4월 머쓱이 줌 배경화면-16.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/4c28be17-ac1f-4715-9b88-87dbabeac222/4%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%86%E1%85%A5%E1%84%8A%E1%85%B3%E1%86%A8%E1%84%8B%E1%85%B5%20%E1%84%8C%E1%85%AE%E1%86%B7%20%E1%84%87%E1%85%A2%E1%84%80%E1%85%A7%E1%86%BC%E1%84%92%E1%85%AA%E1%84%86%E1%85%A7%E1%86%AB-16.png)
 
![4월 머쓱이 줌 배경화면-17.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/06150e00-f45f-41e6-a6f6-4bda21d3d478/4%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%86%E1%85%A5%E1%84%8A%E1%85%B3%E1%86%A8%E1%84%8B%E1%85%B5%20%E1%84%8C%E1%85%AE%E1%86%B7%20%E1%84%87%E1%85%A2%E1%84%80%E1%85%A7%E1%86%BC%E1%84%92%E1%85%AA%E1%84%86%E1%85%A7%E1%86%AB-17.png)
 
![4월 머쓱이 줌 배경화면-18.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/f90909d2-e062-4326-b1d1-bad7fbb24230/4%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%86%E1%85%A5%E1%84%8A%E1%85%B3%E1%86%A8%E1%84%8B%E1%85%B5%20%E1%84%8C%E1%85%AE%E1%86%B7%20%E1%84%87%E1%85%A2%E1%84%80%E1%85%A7%E1%86%BC%E1%84%92%E1%85%AA%E1%84%86%E1%85%A7%E1%86%AB-18.png)
 
![4월 머쓱이 줌 배경화면-19.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/ffc0fa23-39e6-4657-8698-43b4afaa901a/4%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%86%E1%85%A5%E1%84%8A%E1%85%B3%E1%86%A8%E1%84%8B%E1%85%B5%20%E1%84%8C%E1%85%AE%E1%86%B7%20%E1%84%87%E1%85%A2%E1%84%80%E1%85%A7%E1%86%BC%E1%84%92%E1%85%AA%E1%84%86%E1%85%A7%E1%86%AB-19.png)
 
![4월 머쓱이 줌 배경화면-20.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/2d7c3e1a-ec15-453f-9242-9446666be119/4%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%86%E1%85%A5%E1%84%8A%E1%85%B3%E1%86%A8%E1%84%8B%E1%85%B5%20%E1%84%8C%E1%85%AE%E1%86%B7%20%E1%84%87%E1%85%A2%E1%84%80%E1%85%A7%E1%86%BC%E1%84%92%E1%85%AA%E1%84%86%E1%85%A7%E1%86%AB-20.png)
 
더 많은 줌 배경화면(기본, 미러 버전)은 아래 링크에서 확인 가능합니다.
👉 [머쓱이 줌 배경화면 보러가기](https://prgrms.notion.site/zip-1993e47046bf80629692c4ddef6a01bf)

머쓱이 4월 캘린더 & 줌 배경화면 무료 배포 💻

안녕하세요, 프로그래머스입니다!
 
뜨거운 태양이 내리쬐는 8월이 찾아왔습니다 ☀️
무더운 여름, 프로그래머스와 함께 이겨낼 준비 되셨나요?
 
시원한 머쓱이 디지털 굿즈로 잠깐의 리프레시를,
학습과 커리어 성장에는 더 뜨거운 열정을 더해보세요! 🔥
 
 
# 8월 머쓱이 캘린더
 
![캘린더 8월 머쓱이(mac)-48.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/a04f5e46-0917-4e4b-81ef-3a38dc688ec6/%E1%84%8F%E1%85%A2%E1%86%AF%E1%84%85%E1%85%B5%E1%86%AB%E1%84%83%E1%85%A5%208%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%86%E1%85%A5%E1%84%8A%E1%85%B3%E1%86%A8%E1%84%8B%E1%85%B5%28mac%29-48.png)
 
![캘린더 8월 머쓱이(mac)-50.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/2419c2be-f279-4b3c-ad60-03532e179e71/%E1%84%8F%E1%85%A2%E1%86%AF%E1%84%85%E1%85%B5%E1%86%AB%E1%84%83%E1%85%A5%208%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%86%E1%85%A5%E1%84%8A%E1%85%B3%E1%86%A8%E1%84%8B%E1%85%B5%28mac%29-50.png)
 
![캘린더 8월 머쓱이(Window)-49.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/355eec4b-0b78-448f-8b7c-2837029e5350/%E1%84%8F%E1%85%A2%E1%86%AF%E1%84%85%E1%85%B5%E1%86%AB%E1%84%83%E1%85%A5%208%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%86%E1%85%A5%E1%84%8A%E1%85%B3%E1%86%A8%E1%84%8B%E1%85%B5%28Window%29-49.png)
 
![캘린더 8월 머쓱이(window)-51.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/e9a04b95-c906-47cf-a509-d6d8a28aa9cb/%E1%84%8F%E1%85%A2%E1%86%AF%E1%84%85%E1%85%B5%E1%86%AB%E1%84%83%E1%85%A5%208%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%86%E1%85%A5%E1%84%8A%E1%85%B3%E1%86%A8%E1%84%8B%E1%85%B5%28window%29-51.png)
 
![캘린더 8월 머쓱이(window).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/e9833f85-7038-49de-ab70-19fa2045e2c4/%E1%84%8F%E1%85%A2%E1%86%AF%E1%84%85%E1%85%B5%E1%86%AB%E1%84%83%E1%85%A5%208%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%86%E1%85%A5%E1%84%8A%E1%85%B3%E1%86%A8%E1%84%8B%E1%85%B5%28window%29.png)
 
더 많은 배경화면(Mac, Window)은 아래 링크에서 확인 가능합니다.
👉 **[머쓱이 8월 캘린더 보러가기](https://prgrms.notion.site/zip-1993e47046bf80629692c4ddef6a01bf)**
 
 
# 8월 머쓱이 줌 배경
 
![8월 줌 배경화면(기본)-35.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/308397fd-9665-4d00-a9ee-7a50f2ac54cf/8%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%8C%E1%85%AE%E1%86%B7%20%E1%84%87%E1%85%A2%E1%84%80%E1%85%A7%E1%86%BC%E1%84%92%E1%85%AA%E1%84%86%E1%85%A7%E1%86%AB%28%E1%84%80%E1%85%B5%E1%84%87%E1%85%A9%E1%86%AB%29-35.png)
 
![8월 줌 배경화면(기본)-36.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/c0fc3fb4-8826-44c1-b44e-46b12a4d528d/8%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%8C%E1%85%AE%E1%86%B7%20%E1%84%87%E1%85%A2%E1%84%80%E1%85%A7%E1%86%BC%E1%84%92%E1%85%AA%E1%84%86%E1%85%A7%E1%86%AB%28%E1%84%80%E1%85%B5%E1%84%87%E1%85%A9%E1%86%AB%29-36.png)
 
![8월 줌 배경화면(기본)-37.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/8bb60a5a-cb32-4e38-856d-f5c261d26bdd/8%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%8C%E1%85%AE%E1%86%B7%20%E1%84%87%E1%85%A2%E1%84%80%E1%85%A7%E1%86%BC%E1%84%92%E1%85%AA%E1%84%86%E1%85%A7%E1%86%AB%28%E1%84%80%E1%85%B5%E1%84%87%E1%85%A9%E1%86%AB%29-37.png)
 
![8월 줌 배경화면(기본)-38.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/e258456d-7b8f-4e14-bafa-7971bfb326f4/8%E1%84%8B%E1%85%AF%E1%86%AF%20%E1%84%8C%E1%85%AE%E1%86%B7%20%E1%84%87%E1%85%A2%E1%84%80%E1%85%A7%E1%86%BC%E1%84%92%E1%85%AA%E1%84%86%E1%85%A7%E1%86%AB%28%E1%84%80%E1%85%B5%E1%84%87%E1%85%A9%E1%86%AB%29-38.png)
 
더 많은 줌 배경화면(기본, 미러 버전)은 아래 링크에서 확인 가능합니다.
👉 **[머쓱이 줌 배경화면 보러가기](https://prgrms.notion.site/zip-1993e47046bf80629692c4ddef6a01bf)**

머쓱이 8월 캘린더 & 줌 배경화면 무료 배포 💻

퍼블리셔였지만 프론트엔드 데브코스 1기를 마치고, 퀄슨에 합격한 임경희 님의 인터뷰를 준비했습니다. 경희 님이 프로그래머스 데브코스를 선택한 이유와 퍼블리셔에서 개발자로 커리어를 확장한 과정이 궁금하다면, 경희 님과의 인터뷰를 끝까지 읽어보세요!
 
 
# 프론트엔드 분야에 관심을 가지게 된 계기가 궁금해요.
원래는 잡지 에디터가 되고 싶었어요. 대학생 독립잡지 에디터 활동을 하면서 아무리 좋은 콘텐츠가 있어도 종이 지면을 통해서는 많은 사람에게 전달하기 어렵다는 사실을 느꼈어요.
 
**어떻게 하면 더 많은 사람에게 콘텐츠를 효율적으로 전달할 수 있을지 고민하다가, '웹사이트로 콘텐츠를 배포하면 어떨까?'라는 생각이 들어서 웹 퍼블리싱을 배우게 됐어요**. 사용자들이 원하는 데이터를 효율적으로 얻을 수 있도록 화면을 구성하는 일이 재밌더라고요. 그러다 더 복잡한 페이지 구조, 더 많은 데이터는 어떻게 관리하는 건지 궁금해졌고, 프론트엔드 개발에 대해 제대로 공부해보자 생각하게 됐어요.
 
# 다양한 부트캠프 과정 중 프로그래머스 데브코스를 선택한 이유가 있다면?
저는 부트캠프를 선택하는 데 있어 아래 3가지 조건을 중점적으로 봤습니다.
 
* **커리큘럼 중 JavaScript 기본 지식에 대한 내용이 충분히 마련되어 있는지**
* **양질의 팀 프로젝트를 경험할 수 있는지**
* **교육 기간이 너무 짧지는 않은지**

 
저는 JavaScript 기초를 쌓는 것이 무엇보다 중요하다고 생각했는데, 데브코스는 그 부분을 중점적으로 다루고 있어서 좋았어요. **이전에 프로그래머스 스터디에 참여한 경험도 있어서, 커리큘럼에 대한 신뢰도 있었고요**.
 
저는 프로젝트부터 시작하는 교육보다는, 충분히 기초 지식을 쌓은 뒤에 프로젝트를 수행하는 방식의 교육을 원했어요. 그런 점에서도 데브코스는 제 학습 스타일에 잘 맞았어요. 백엔드 개발자와 협업할 수 있다는 점도 큰 장점이었고요. 무엇보다, 수료 후 바로 신입으로 입사하려면 최소 5개월은 집중적인 학습이 필요하다고 판단해서, 데브코스를 선택하게 되었습니다.
 
# 프로그래머스 데브코스 과정을 진행하기 전, 이루고자 했던 목표가 있었나요?
**기초가 탄탄한 프론트엔드 신입 개발자가 되는 것이 목표**였어요. 감사하게도 데브코스를 통해 프론트엔드 신입 개발자가 되겠다는 목표는 이룰 수 있었어요.
 
다만, '기초를 탄탄하게 다지는 것'은 여전히 진행 중인 과제예요. 지금까지 배운 개념들을 제 언어로 정리하고, 실제 코드에 자연스럽게 녹여낼 수 있도록 꾸준히 연습하고 있어요. 또, 기초적인 CS 지식도 차근차근 공부해나가며 기반을 더 단단히 다지고자 합니다.
 
# 데브코스 과정 중 기억에 남는 활동이 있다면 무엇인가요?
과제를 하면서 **코드 리뷰를 주고받은 경험**이 가장 인상 깊었어요. 그전까지는 제 코드를 객관적으로 피드백받을 기회가 거의 없어서, 잘못된 코딩 습관이 있어도 스스로 인지하기 어려웠거든요. 하지만 **멘토님의 리뷰를 통해 개선해야 할 부분을 알게 되었고, 좋은 코드와 그렇지 않은 코드에 대한 기준도 생기기 시작**했어요.
 
또 수강생들끼리도 코드 리뷰를 주고 받았는데요. 다른 수강생들의 남긴 정성스러운 리뷰를 보며 '나도 더 잘해야겠다'는 자극을 받기도 했어요. 제가 코드 리뷰를 남길 땐 최대한 정확한 피드백을 하려고 노력하면서 자연스럽게 더 공부하게 되더라고요. 무엇보다도, 다른 사람의 코드를 읽는 연습이 많이 됐어요.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/f1d4c2f9-9292-41c1-991f-2ad7507ee7fa/image.png)
 
# 퍼블리셔에서 프론트엔드 개발자로 커리어 전환을 하셨는데, 데브코스가 어떤 도움이 되었나요?
JavaScript 지식이 많이 부족했는데, 데브코스를 통해서 기초를 탄탄하게 잡을 수 있었던 것이 가장 큰 도움이 되었어요. 또, **백엔드 개발자와 함께 프로젝트를 진행한 경험도 실무에서 프론트엔드 개발자가 협업하는 방식을 익히는 데 큰 도움**이 되었습니다.
 
처음 데브코스에 합격했을 때만 해도, 개발자가 될 수 있을지에 대한 확신이 없었어요. 하지만 데브코스 첫 주에 **매니저님과 개인 면담을 진행하며 제가 이 교육 과정에 함께 할 수 있을 만큼 가능성 있는 사람이라는 것을 알게 되었어요**. 그 순간부터는 내가 개발자가 될 수 있을까에 대한 걱정이 사라졌던 것 같아요. 매니저님의 응원 덕분에 포기하지 않고 끝까지 완주할 수 있었다고 생각해요.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/374252d2-6c72-4160-a3e6-eb8572b48054/image.png)
 
# 어떤 개발자가 되고 싶으신가요?
좋은 제품을 만드는 개발자, 함께 일하기 좋은 개발자가 되고 싶어요. 콘텐츠를 더 많은 사람들에게 전달하고 싶어서 이 일을 시작했던 만큼, **다양한 사람들이 장벽 없이 콘텐츠에 접근할 수 있도록 돕는 개발자**가 되고 싶습니다.
 
# 데브코스가 취업에 어떤 도움이 되었나요?
데브코스를 통해 기본적으로 **기업의 직무 요구사항에 맞게끔 채용 과제를 완성할 수 있을 정도의 코딩 실력**을 기를 수 있었어요. 멘토님들의 커피챗을 통해서 현직에서 어떤 신입 개발자를 필요로 하는지 계속 조언을 구할 수 있었던 것도 큰 도움이 되었습니다. 좋은 특강들이 많아서 특강을 다시 돌려 보면서 면접을 준비하기도 했고요. 매니저님께서 면접 전에 모의 면접을 도와주셨던 것도 매우 유익했습니다.
 
# 데브코스 후배 수강생들에게 전하는 응원의 한마디!
데브코스에서 공부하면서, 예전엔 도저히 이해되지 않아 포기했던 개념들이 **어느 순간 자연스럽게 이해되는 경험**을 했어요. 그래서 지금 어려운 개념을 만나더라도 너무 절망하지 않았으면 해요. 당장 이해되지 않더라도, 지금 할 수 있는 것들을 하나씩 계속해 나가다 보면 언젠간 미래의 내가 이해할 수 있을 거예요.
 
**또 다른 데브코스의 가장 큰 강점 중 하나는 좋은 동료들을 만날 수 있다는 점**이라고 생각해요. 저는 매니저님, 함께 공부한 동료들 덕분에 정말 큰 힘을 얻었어요. 서로가 서로의 버팀목이 되어주면서, 미래의 나를 믿고 꾸준히 나아간다면 분명 좋은 결과가 따라올 거예요.
 
 

*※본 글은 2022년 3월에 최초 작성된 콘텐츠입니다.*

 
 
[![FE_배너.jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/f9a3a9b6-fc4d-417a-aa35-c64c000d9870/FE_%E1%84%87%E1%85%A2%E1%84%82%E1%85%A5.jpg)](https://school.programmers.co.kr/learn/courses/25243?utm_source=prgmblog&utm_medium=social&utm_campaign=school_25243_blog&utm_content=25243_banner)

[데브코스 후기] 퍼블리셔에서 프론트엔드 개발자로 커리어 확장에 성공했어요 - 프론트엔드 1기 수료생 임경희 님

어렵게 얻은 합격 기회가 날아갈까 봐, 제시받은 연봉을 그대로 수락해 본 경험이 있으신가요? 많은 주니어 개발자들이 '회사에 밉보일까 봐' 혹은 'AI 시대라 내 가치가 부족해서'라는 두려움 때문에 협상을 포기하곤 합니다.
 
시니어 풀스택 개발자 고코더 님은 연봉 협상이 무례함이 아닌, 나의 가치를 증명하는 지혜로운 절차라고 말합니다. AI 시대에 주니어 개발자가 자신 있게 협상 테이블에 나서는 방법을 확인해 보세요!
 
 

***
 
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/9b100d74-9673-42d4-b756-7d7b1e489921/image.png)
이미지 출처: 픽사베이
 
 
주니어 개발자 A씨는 이직 제안을 받았습니다. 연봉도 지금보다 높았습니다. 그런데 오퍼레터를 받고도 선뜻 답장을 못 했습니다. "이 정도면 감사히 받아야 하는 거 아닌가", "괜히 더 달라고 했다가 합격이 취소되면 어떡하지." 결국 처음 제시받은 금액 그대로 수락했습니다. 나중에 비슷한 연차의 동료에게 물어보니, 그 동료는 처음 제시받은 금액에서 협상을 해서 더 받았다는 이야기를 들었습니다. A씨는 그제야 "협상이라는 선택지가 있었다는 것" 자체를 몰랐다는 걸 깨달았습니다.
 
많은 주니어 개발자들이 연봉 협상 앞에서 A씨와 비슷한 감정을 느낍니다. 협상이 곧 무례함이나 욕심으로 비칠까 봐 두렵고, 어렵게 잡은 기회를 놓칠까 봐 조심스럽습니다. 특히 처음 취업하는 취준생이라면 "나 같은 신입이 뭘 협상해"라는 생각이 먼저 들기 마련입니다. 오늘은 이 두려움이 어디서 오는지, 그리고 실제로 어떻게 접근하면 좋을지 이야기해 보겠습니다.

 
 
 

## 왜 우리는 협상을 두려워할까
협상을 못 하는 이유를 물어보면 대부분 비슷한 답이 돌아옵니다.
 
"괜히 회사에 밉보일까 봐"
"신입 주제에 뭘 요구하냐고 할까 봐"
"오퍼가 취소될까 봐."
 
흥미로운 건 이 두려움이 실제 경험에서 나온 게 아니라, 대부분 상상 속의 두려움이라는 점입니다.
 
이런 반응은 사실 낯선 게 아닙니다. 처음 연봉 협상을 해보는 사람이라면 누구나 비슷한 망설임을 겪습니다. 회사가 나를 뽑아준 것"이라는 감사한 마음이 앞서다 보니, 그 관계에서 뭔가를 더 요구하는 게 마치 은혜를 모르는 행동처럼 느껴지는 경우가 많습니다. 하지만 채용은 은혜를 베푸는 일이 아니라 회사와 개인이 서로의 필요를 맞춰가는 거래입니다. 회사는 필요한 인재를 구하고, 개인은 자신의 노동과 시간을 제공하는 대가로 정당한 보상을 받습니다. 이 프레임을 이해하면 협상이 훨씬 자연스럽게 느껴집니다.
 
또 하나, 협상을 "싸움"으로 오해하는 경우도 많습니다. 협상은 상대를 이기는 게 아니라, 서로가 받아들일 수 있는 지점을 찾아가는 대화입니다. 이 관점의 차이만으로도 협상에 임하는 마음가짐이 달라집니다.
 
 
## AI가 다 하는데, 제가 협상해도 될까요
요즘 들어 새로운 형태의 망설임도 자주 보입니다. "요즘은 AI가 코드도 다 짜주는데, 제가 뭘 잘한다고 협상을 해요." 코딩 테스트에서 AI 도구 사용이 익숙해지고, 채용 공고에서도 "AI 활용 능력"이 언급되는 시대다 보니, 스스로의 가치를 의심하는 주니어들이 늘고 있습니다.
 
이 질문에는 두 가지 오해가 섞여 있습니다. 첫째, 회사가 채용하는 건 "코드를 짜는 손"이 아니라 "문제를 정의하고 판단하는 사람"입니다. **AI가 코드 작성을 도와줄수록, 오히려 무엇을 만들지 결정하고 그 결과를 검증하는 사람의 역할이 더 중요해집니다**. 채용 담당자 F씨는 이렇게 말합니다. "요즘 면접에서는 AI가 짜준 코드를 그대로 쓰는 사람인지, 왜 그 코드가 맞는지 설명할 수 있는 사람인지를 훨씬 유심히 봅니다. 후자를 뽑고 싶은 건 예나 지금이나 똑같아요."
 
둘째, 연봉 협상의 근거는 "내가 AI보다 코드를 더 잘 짜는가"가 아닙니다. 회사가 이미 나를 채용하기로 결정했다는 사실 자체가, 내 가치를 그 시장가에서 인정했다는 뜻입니다. 협상은 그 인정된 가치를 시장 데이터에 맞춰 조정하는 과정이지, 처음부터 "내가 이 자리에 자격이 있는가"를 다시 증명하는 시험이 아닙니다. AI 도구의 발전은 업계 전체의 생산성 기준을 바꾸는 변화이지, 특정 개인의 협상 자격을 깎아내리는 이유가 될 수 없습니다.
 
오히려 이런 관점도 가능합니다. AI를 활용해 더 빠르고 효율적으로 일할 수 있다는 것 자체가 하나의 강점입니다. "이런 반복 작업은 AI 도구로 자동화해서 처리 시간을 줄였습니다" 같은 경험이 있다면, 이것도 협상 테이블에서 충분히 쓸 수 있는 근거가 됩니다. **AI는 협상을 포기할 이유가 아니라, 오히려 새로운 협상 근거를 만들어주는 도구**이기도 합니다.
 
 
## 협상은 무례함이 아니라 절차입니다
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/83ae0db2-205d-4f19-b822-214df356d048/image.png)
이미지 출처: 픽사베이
 
 
먼저 짚고 넘어갈 게 있습니다. 채용 담당자에게 제시받은 연봉에 대해 조정을 요청하는 건 특별한 일이 아니라 채용 프로세스의 정상적인 한 단계입니다. 회사도 이 과정을 예상하고 있습니다. 실제로 많은 기업의 초기 오퍼는 협상의 여지를 두고 설계됩니다. 처음 제시된 숫자가 회사가 줄 수 있는 최대치인 경우는 생각보다 드뭅니다.
 
채용 담당자 D씨는 이렇게 말합니다. "저희는 처음부터 최종 예산을 제시하지 않습니다. 후보자의 경력, 다른 제안, 협상 여부를 고려해서 몇 단계의 여지를 남겨두는 경우가 많아요. 그런데 정작 협상을 시도하는 지원자는 절반도 안 됩니다." 이 말은 곧, 협상을 시도하지 않는 사람은 회사가 애초에 남겨둔 여지를 그냥 포기하고 있다는 뜻이기도 합니다.
 
그런데도 많은 주니어들이 협상을 요청하면 오퍼가 취소되거나, 회사에 "욕심 많은 사람"으로 찍힐까 봐 걱정합니다. 실제로는 정중하고 근거 있는 협상 요청 때문에 오퍼가 철회되는 경우는 매우 드뭅니다. 채용까지 이미 여러 단계의 면접과 검토를 거친 후보자를, 정중한 협상 요청 하나로 포기하는 회사는 애초에 그 정도로 확신을 갖고 뽑은 게 아니었을 가능성이 큽니다.
 
오히려 채용 담당자 입장에서는 협상 자체를 "이 사람이 자기 가치를 이해하고, 커뮤니케이션을 할 줄 아는 사람이구나"라는 신호로 받아들이는 경우도 많습니다.
 
 
## 협상 전에 준비해야 할 것
무작정 "더 주세요"라고 말하는 건 협상이 아닙니다. 근거가 필요합니다.
 
첫째, 시장 데이터를 확인하세요. 비슷한 연차, 비슷한 직군의 개발자들이 어느 정도 받는지 파악해두면 요청할 금액의 근거가 생깁니다. 채용 플랫폼의 연봉 정보, 지인 네트워크, 개발자 커뮤니티의 연봉 공유 게시글 등을 참고할 수 있습니다. 한 가지 정보원만 믿지 말고 여러 출처를 교차 확인하는 게 좋습니다. 커뮤니티 글은 극단적인 사례가 많이 공유되는 경향이 있어서, 평균치보다는 범위를 파악하는 용도로 참고하는 게 안전합니다.
 
둘째, 다른 오퍼가 있다면 활용하세요. B씨는 두 곳에서 동시에 오퍼를 받았습니다. 낮은 쪽 회사에 "다른 곳에서 이 정도 금액을 제시받았는데, 이 회사에 더 가고 싶다"고 솔직하게 전했고, 회사는 금액을 조정해줬습니다. 다른 오퍼는 가장 강력하고 명확한 협상 근거입니다. 다만 없는 오퍼를 있다고 꾸며내는 건 절대 하지 말아야 합니다. 채용 담당자들은 이런 시도를 생각보다 쉽게 알아챕니다. 업계가 좁아서 나중에 확인 전화 한 통으로 들통나는 경우도 있고, 발각되면 그 회사와의 관계는 완전히 끝나버립니다.
 
셋째, 내가 가진 구체적인 강점을 정리하세요. "저 열심히 하겠습니다" 같은 말은 협상 근거가 되지 않습니다. "**이전 인턴십에서 이런 프로젝트를 주도했고, 이 기술 스택에 대한 실무 경험이 있습니다**"처럼 구체적인 사실이 필요합니다. 신입이라 경력이 없다면, **사이드 프로젝트나 스터디, 오픈소스 기여 경험** 같은 것도 충분히 근거가 될 수 있습니다. 핵심은 "내가 이 회사에 어떤 가치를 가져다줄 수 있는가"를 숫자나 사례로 구체화하는 것입니다.
 
넷째, 내가 받아들일 수 있는 범위를 미리 정해두세요. 협상을 시작하기 전에 최소 마지노선과 이상적인 목표치를 스스로 정리해두면, 실제 대화에서 감정에 휘둘리지 않고 판단할 수 있습니다. 급하게 결정하지 않기 위해서라도 이 기준은 협상 전에 미리 세워두는 게 좋습니다.
 
 
## 실제로 어떻게 말해야 할까
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/c740f7df-5a58-474f-9034-3e9e01e4a7ba/image.png)
이미지 출처: 픽사베이
 
 
협상은 요구가 아니라 대화입니다. C씨는 협상 메일에서 이렇게 썼습니다. 
"**합류하게 되어 정말 기쁩니다. 다만 현재 다니는 회사에서 관리하고 있는 프로젝트 규모와 최근 습득한 인프라 경험을 고려했을 때, 제시받은 금액보다 조금 더 조정될 수 있다면 감사하겠습니다.**" 
 
회사는 이 요청을 받아들였고, C씨는 이후 입사해서도 "그때 정중하게 요청해 줘서 오히려 신뢰가 갔다"라는 이야기를 들었습니다.
 
톤에서 중요한 건 감정을 배제하고 사실 위주로 말하는 것입니다. "너무 적어서 서운합니다"보다는 "시장 조사 결과 이 정도 범위가 일반적이라고 파악했습니다"가 훨씬 설득력이 있습니다. 또한 협상 요청이 채용 자체를 거부하는 신호가 아니라는 걸 분명히 하는 것도 중요합니다. "합류하고 싶은 마음은 확실하다"라는 전제를 먼저 깔아두면, 회사도 이 대화를 훨씬 편하게 받아들입니다.
 
전화나 대면보다 이메일이나 문서로 요청하는 것도 방법입니다. 즉흥적으로 대답해야 하는 부담이 줄고, 회사 쪽도 내부 검토를 거쳐 답할 시간을 가질 수 있습니다. 다만 회사에서 먼저 전화로 논의하자고 제안하면, 그에 맞춰 유연하게 대응하는 것도 좋습니다.
 
 
## 협상이 어려운 상황도 있습니다
모든 상황에서 협상이 통하는 건 아닙니다. 스타트업의 초기 시드 단계처럼 예산 구조 자체가 빡빡한 곳도 있고, 대기업처럼 연봉 테이블이 직급별로 정해져 있어 개인 협상의 여지가 거의 없는 곳도 있습니다. 이런 경우 협상이 불가능하다고 해서 그 회사가 나쁜 곳이라는 뜻은 아닙니다.
 
이럴 때는 연봉 외의 조건을 살펴보는 것도 방법입니다. 사이닝 보너스, 입사일 조정, 재택근무 비율, 교육비 지원, 장비 지원 같은 항목들도 충분히 협상 가능한 대상입니다.
 
E씨는 희망 연봉이 받아들여지지 않자 대신 입사 6개월 후 재평가 후 다시 한번 협상을 하자고 요청했습니다. "지금 당장 금액을 못 올려주더라도, 성과가 확인되면 그때 다시 논의하자"는 약속을 구체적으로 남긴 셈입니다. 이런 조건들은 당장의 숫자만큼 눈에 띄지 않지만 장기적으로는 비슷하거나 더 큰 가치를 가질 수 있습니다.
 
또한 협상 여지가 정말 없는 조직인지, 아니면 담당자 선에서 판단하기 어려운 것뿐인지 구분할 필요도 있습니다. "혹시 이 부분에 대해 내부적으로 논의해 주실 수 있는지" 정중하게 물어보는 것도 좋은 방법 입니다. 
 
 
## 협상을 못 해도 괜찮습니다
이 모든 걸 알아도 막상 협상 요청 메일을 보내는 건 여전히 떨립니다. 처음부터 능숙하게 협상하는 사람은 없습니다. 중요한 건 이번 협상의 성패가 아니라, "협상이라는 선택지가 존재한다"라는 걸 아는 것 자체입니다.
 
이번에 시도하지 못했더라도 자책할 필요는 없습니다. 대신 이번 경험을 기록해두세요. 어떤 부분에서 망설였는지, 어떤 말이 입 밖으로 나오지 않았는지. 다음 이직이나 연봉 협상 시즌에는 조금 더 준비된 상태로 대화를 시작할 수 있을 겁니다. 자신의 가치를 스스로 설명하는 연습은, 결국 협상 테이블 밖에서도 커리어 전반에 도움이 되는 기술입니다. 성과 평가 자리에서, 이직 면접에서, 심지어 팀 내에서 새로운 역할을 제안할 때도 같은 근육이 쓰입니다.
 
연봉 협상은 한 번의 이벤트가 아니라 커리어 내내 반복해서 마주치는 대화입니다. 처음이 가장 어렵고, 그다음부터는 조금씩 수월해집니다. 지금 당장 완벽하게 해내지 못해도 괜찮습니다. 다만 그 선택지가 애초에 존재한다는 것만은 잊지 마세요.
 
 
 

### 📌 함께 읽으면 좋은 글
* [AI 시대의 포트폴리오](https://community.programmers.co.kr/post/13928?utm_source=&utm_medium=&utm_campaign=&utm_content=gocoder_13928)
* [개발자가 문서를 안 쓰는 이유](https://community.programmers.co.kr/post/13767?utm_source=&utm_medium=&utm_campaign=&utm_content=gocoder_13767)
* [코드는 잘 짜는데 발표만 하면 왜 이럴까](https://community.programmers.co.kr/post/13597?utm_source=&utm_medium=&utm_campaign=&utm_content=gocoder_13597)

 
 

![고코더 작가님 프로필 카드.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/c227824e-8b30-4bd8-b5a3-233a53dc4546/%E1%84%80%E1%85%A9%E1%84%8F%E1%85%A9%E1%84%83%E1%85%A5%20%E1%84%8C%E1%85%A1%E1%86%A8%E1%84%80%E1%85%A1%E1%84%82%E1%85%B5%E1%86%B7%20%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%84%91%E1%85%B5%E1%86%AF%20%E1%84%8F%E1%85%A1%E1%84%83%E1%85%B3.png)

연봉 협상, 해도 되는 걸까? 주니어 개발자를 위한 연봉 협상 전략

## 누구를, 어떻게 다시 배치할 것인가 : AI 시대 조직 재편의 새로운 숙제 📂

 
 ※ 본 글은 BCG 리포트 
 <a href="https://www.bcg.com/publications/2026/ai-will-reshape-more-jobs-than-it-replaces?utm_source=chatgpt.com" target="_blank" style="color: #888888; text-decoration: underline;">
 AI Will Reshape More Jobs Than It Replaces
 </a>
 를 참고해 재구성했습니다.
 

 

AI를 둘러싼 논의는 종종 “내 자리가 사라질까?”라는 두려움에 집중됩니다. 하지만 글로벌 컨설팅 그룹 **BCG**의 분석 결과는 조금 다릅니다. AI에 의한 일자리의 완전한 대체는 생각보다 느리게 진행될 것이며(5년 내 10~15%), 진짜 핵심은 **전체 일자리의 절반 이상(50~55%)이 AI에 의해 재편된다**는 점입니다.

실제로 BCG는 **전체 직무의 43%가 업무의 40% 이상 자동화될 가능성**이 있다고 분석합니다. 이는 직무 자체가 사라진다기보다, 기존 업무의 상당 부분이 AI로 대체되며 **사람에게 요구되는 역할과 기대 성과 역시 크게 변화**할 수 있음을 의미합니다.
![bcg 리포트 이미지_1.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/e14f80fc-6859-48e6-bcd2-9f9fce60ea5e/bcg%20%E1%84%85%E1%85%B5%E1%84%91%E1%85%A9%E1%84%90%E1%85%B3%20%E1%84%8B%E1%85%B5%E1%84%86%E1%85%B5%E1%84%8C%E1%85%B5_1.png)

즉, 직무 자체는 사라지지 않더라도 **일하는 방식과 성과를 평가하는 기준은 완전히 달라질 것**이라는 의미입니다. 이제 리더에게 필요한 것은 단순 감원이 아니라, **자동화·업스킬링·인재 재배치를 어떻게 균형 있게 설계할 것인가**에 대한 전략적 판단입니다.

 

### 1. 변화의 두 축: ‘대체’와 ‘증강’ 🧩

BCG는 AI가 직무에 미치는 영향을 두 가지 관점으로 분류합니다. 이 차이를 이해해야 우리 조직의 인력 전략을 바로 세울 수 있습니다.

* **대체(Substitution):** 반복적이고 구조화된 업무가 중심인 직무입니다. AI가 처음부터 끝까지 업무를 처리하게 되며, 인력 수요 감소로 이어질 가능성이 높습니다. (예: 콜센터 상담원)
* **증강(Augmentation):** 판단, 설계, 비즈니스 맥락의 번역이 핵심인 직무입니다. AI가 업무를 가속화하지만 인간의 책임과 검증이 필수적입니다. 오히려 수요가 늘어 채용이 유지되거나 확대될 수 있습니다. (예: 소프트웨어 엔지니어)

결국 **AI가 비용을 낮췄을 때, 그 서비스에 대한 수요가 확장되는가?** 에 따라 인재 전략의 방향은 완전히 달라집니다.

 

### 2. 우리 조직의 직무는 어디에 속해 있는가? (6가지 세그먼트) 📍

BCG는 AI로 인한 직무 변화 양상을 6가지 유형으로 구분하며,
각 유형마다 HR이 준비해야 할 대응 전략도 달라진다고 설명합니다.

| 세그먼트 | 특징 | HR의 핵심 과제 |
| :--- | :--- | :--- |
| **1. Amplified (증폭)** | AI로 능력 증강 + 수요 급증 | 핵심 인재 유지 및 AI 협업 최적화 |
| **2. Rebalanced (재균형)** | 증강은 되나 수요 제한적 | 반복 업무 자동화 후 고부가가치 업무로 재투입 |
| **3. Divergent (분화)** | 주니어 업무 대체 + 시니어 업무 증가 | 초급 인력 육성 경로 보존 및 스킬 공백 방지 |
| **4. Substituted (대체)** | AI가 핵심 업무 직접 대체 | AI 중심 프로세스 재설계 및 인력 재배치 |
| **5. Enabled (활성화)** | 일상 업무에 AI가 기본 탑재 | 전 조직의 AI 활용 역량 표준화 |
| **6. Limited-Exposure (제한)** | 인간 상호작용 및 물리적 존재 중심 | 단기적 변화 적으나 지속적 모니터링 |

 

### 3. 변화를 가로막는 4가지 불확실성 ⚠️ 

직무가 유지된다고 해서 안심할 수 있는 것은 아닙니다. BCG는 조직 재편 과정에서 다음과 같은 리스크를 경고합니다.

* **엔트리 레벨의 위기:** 반복 업무를 AI가 가져가면서 주니어들이 경험을 쌓을 기회가 줄어듭니다.
* **역량 기준의 상향:** 재설계된 역할은 더 높은 전문성과 감독 능력을 요구합니다.
* **인지 부하 증가:** 고차원적 의사결정 업무만 남게 되면서 구성원들의 피로도가 급증할 수 있습니다.
* **실행 인재 부족:** AI를 도입하려 해도 이를 현업과 연결할 전문가가 턱없이 부족합니다.


### 4. 결론: HR 전략의 중심, 이제 '진단'으로 옮겨야 합니다 🚀

BCG 리포트의 결론은 명확합니다. 인력 전략은 자동화의 부수적인 결과가 아닌 **사업 경쟁 전략의 핵심**이 되어야 합니다. 그리고 이를 실행하기 위해선 반드시 **데이터 기반의 인재 진단**이 선행되어야 합니다.

**📊 정교한 역량 진단이 필요한 이유:**
1. **세그먼트 분류:** 우리 조직의 어떤 직무가 '재편' 대상이고 '대체' 대상인지 구분하기 위함입니다.
2. **재배치 경로 설계:** AI로 남는 시간을 어떤 고부가가치 업무에 투입할지 결정할 근거가 됩니다.
3. **성과 기준 재정의:** AI 도입 후 변화된 직무에 맞는 새로운 KPI를 설정해야 합니다.

 
 
### 💡 AI 시대, HR의 질문은 달라져야 합니다.

따라서 이제 단순히 “AI 교육을 할까?”가 아닌, **우리 조직에서 어떤 직무가 가장 먼저 바뀌고 있는가?** 를 물어야 합니다. 그리고 그 답을 찾기 위해 가장 먼저 해야 할 일은 **직무별 AI 역량을 가시화하는 일**입니다.

AI가 직무를 재편하는 시대, 성공적인 변화의 시작은 교육이 아니라 **우리 조직의 현재 역량을 정확히 읽어내는 진단**입니다.


 

---

### ✨ 우리 조직의 AI 전환, '진짜 실력'을 읽는 데이터로 시작하세요

단순 설문이나 이론 시험으로는 **AI를 실무에 즉시 활용할 수 있는 인재**를 가려낼 수 없습니다. 개발자 채용 시장을 혁신해온 프로그래머스가 **이제 전 직군 실무 중심의 AI 역량평가 새로운 기준을 제시합니다.**

### **왜 프로그래머스 AI 역량평가인가요?**

* **🚀 실무형 워크플로우 평가** : 단순 지식이 아닌 'AI 활용 문제 해결 능력'을 실제 시나리오 속에서 측정합니다.
* **🎯 직무별 맞춤 진단** : BCG가 제시한 세그먼트별 특성에 맞춰 개발·마케팅·기획 등 직무별로 최적화된 진단을 제공합니다.
* **📊 다차원 데이터 리포트** : 구성원의 현재 수준과 스킬 갭(Gap)을 가시화하여, 전략적인 재배치와 업스킬링의 근거를 마련합니다.
* **📈 검증된 신뢰성** : 국내 최고 수준의 검증 알고리즘으로 성과와 직결되는 진짜 인재를 식별합니다.

> **성공적인 AI 전환은 최적의 인재를 가려내는 것에서 시작됩니다 🏆**
> **이제 프로그래머스의 검증된 데이터로 우리 조직만의 AI 인재 기준을 세워보세요! ✨**

 

**👉 [프로그래머스 AI 역량평가 자세히 보기](https://programmers.co.kr/ai-assessment)**
**👉 [우리 조직 맞춤형 도입 상담 신청하기](https://business.programmers.co.kr/contact-us?utm_source=programmers&utm_medium=landing_page&utm_campaign=ai_assessment&utm_content=hero_contact)**

[AI Trend] AI는 사람을 대체하기보다, 직무의 기준을 다시 쓰고 있다 

AI 덕분에 이제는 누구나 며칠 만에 그럴듯한 서비스를 만들 수 있는 시대가 됐습니다. 그래서 면접으로 합격 여부를 가르는 기준도 달라졌죠. 시니어 풀스택 개발자 고코더 님은 이제 포트폴리오에서 중요한 것은 완성도가 아니라 왜 그런 선택을 했는지 설명할 수 있는 사고의 과정이라고 말합니다. AI 시대, 면접관의 기억에 남는 포트폴리오는 무엇이 다른지 함께 살펴보겠습니다.
 
 

***
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/b3186211-2e6b-48ad-b0aa-2121a808c45b/image.png)
 
면접관은 오늘 아침에도 포트폴리오 12개를 훑어봤습니다. 화면 하나만 캡처해서 봐도 비슷합니다. AI 챗봇을 붙인 일정 관리 앱, 깔끔한 다크모드 투두리스트, 그럴듯한 OCR 영수증 정리 서비스. 코드는 모두 잘 동작하고, README도 깔끔합니다. 다이어그램까지 곁들여진 포트폴리오도 있습니다. 그런데 12개를 다 보고 나서도 면접관의 머릿속에 남는 이름은 하나도 없었습니다.
 
"다들 잘 만들었는데, 왜 아무도 기억나지 않을까."
 
채용 팀장은 회의에서 이렇게 말했습니다. 동료 면접관들도 비슷한 얘기를 했습니다.
"예전엔 풀스택으로 서비스 하나를 완성한 것 자체가 인상적이었는데, 요즘은 다들 그 정도는 하더라고요." 
"화려한데 막상 물어보면 대답을 못 하는 경우가 더 많아요."
 
한 동료는 이런 말도 덧붙였습니다. 
"솔직히 비교하기도 지칩니다. 다들 똑같은 구조, 똑같은 디자인 시스템, 똑같은 기능 목록이에요. 마치 한 사람이 12개를 다 만든 것 같아요."
 
몇 년 전만 해도 취업 준비생이 혼자서 회원가입, 결제, 실시간 알림까지 갖춘 서비스를 만들면 그 자체로 눈에 띄었습니다. 기획부터 배포까지 끝까지 해냈다는 사실이 곧 실력의 증명이었습니다.
 
지금은 다릅니다. AI 코딩 도구에 며칠만 시간을 들이면 누구나 동작하는 서비스를 만들어낼 수 있습니다. 인증, 결제 연동, 반응형 디자인까지도 자연어 몇 줄로 뽑아낼 수 있는 시대입니다. 완성도는 더 이상 차별점이 아닙니다. 그렇다면 이제 무엇으로 변별력을 보여줘야 할까요?
 
 
## 변별력이 사라진 자리
생각해 보면 당연한 흐름입니다. 예전에는 '무엇을 만들 수 있는가'가 진입장벽이었습니다. 풀스택 서비스를 혼자 완성하려면 프론트엔드, 백엔드, 데이터베이스, 배포까지 두루 익혀야 했고, 그 과정 자체가 실력의 증거였습니다. 그런데 AI 도구가 그 진입장벽을 크게 낮춰버렸습니다. 코딩을 막 배우기 시작한 사람도 며칠 안에 그럴듯한 서비스를 완성할 수 있습니다.
 
문제는 결과물의 겉모습만으로는 그 사람이 정말 이해하고 만든 것인지, AI가 시키는 대로 따라간 것인지 구분이 안 된다는 점입니다. 화면을 캡처해서 비교하면 둘 다 똑같이 깔끔합니다. 코드 저장소를 열어봐도 큰 차이가 안 보일 때가 많습니다.
 
그래서 면접관들이 점점 결과물보다 그 뒤에 숨은 과정을 캐묻기 시작하는 겁니다. 이건 단순히 "AI를 썼는지 걸러내겠다"라는 의도가 아닙니다. 결과물이 비슷비슷해진 상황에서, 그 사람의 사고방식을 확인할 수 있는 거의 유일한 통로가 질문이기 때문입니다.
 
 
## 면접관이 진짜 보는 것
면접관이 포트폴리오를 펼쳤을 때 첫눈에 보이는 건 결과물입니다. 화면 캡처, 사용된 기술 스택, 배포 링크. 하지만 채용 결정을 가르는 건 그다음 단계, 면접 자리에서 던지는 질문에 대한 답입니다.
 
**"이 기술을 왜 선택했고, 다른 대안은 검토해 보셨나요?"
"다시 만든다면 뭘 바꾸시겠어요?" 
"이 부분 코드, 왜 이렇게 짜셨어요?"**
 
여기서 답이 막히는 지원자들이 많습니다. 기능은 줄줄 설명하지만, 왜 그렇게 결정했는지를 물으면 "강의에서 본 대로 했어요", "AI가 추천해 줘서요"라는 답이 돌아옵니다.
 
제가 면접관으로 참여했을 때도 비슷한 경험이 있었습니다. "포트폴리오에 'Redis로 캐싱 처리'라고 적혀 있어서, 왜 Redis를 선택했는지 물어봤더니 '인메모리 캐시라서요'라고만 답하고 더 이상 설명을 못하더라고요. 그래서 '메모리 캐시라면 다른 기술도 있을 텐데, 왜 Redis였나요?'라고 다시 질문했더니 거기서부터 설명이 막혔습니다. 결과물은 그럴듯한데, 그 기술을 왜 선택했고 어떤 고민 끝에 적용했는지에 대한 생각의 흔적은 보이지 않았던 것입니다.
 
한 지원자는 포트폴리오에 알림 시스템에 메시지 큐를 도입했다고 자랑스럽게 적어두었습니다. 면접관이 "왜 메시지 큐가 필요했나요? 트래픽이 어느 정도였나요?"라고 묻자, '실제 사용자는 없었지만 나중에 트래픽이 많아질 것을 대비해서 도입했습니다"라는 답이 돌아왔습니다. 이 답변을 들으면서 저는 이런 생각이 들었습니다. "실제로 필요하지도 않은 기술을 이력서에 한 줄 추가하기 위해 가져다 쓴 것처럼 느껴졌어요. 오히려 '지금은 필요 없지만 이런 상황에서는 도입을 고려할 것 같다'라고 솔직하게 설명했다면 훨씬 좋은 인상을 받았을 것 같습니다."
 
반대로 합격하는 지원자들의 포트폴리오를 보면 공통점이 있습니다. **만든 기능보다 문제를 정의한 과정을 먼저 설명합니다**. "사용자가 어디서 이탈하는지 직접 관찰했고, 그 지점을 해결하기 위해 이 기능을 넣었습니다"라는 식입니다. 예를 들어볼까요? 중고 거래 플랫폼을 만들면서 "왜 채팅 기능이 필요했는지"를 이렇게 설명해 봅시다. "처음엔 거래 게시판만 만들었습니다. 그런데 친구들에게 테스트를 부탁했더니, 가격 협상을 하려면 게시글 댓글로는 불편하다는 피드백을 받았어요. 그래서 1:1 채팅을 추가했습니다." 기능 하나에도 관찰과 이유가 붙어 있는 좋은 답변이 됩니다.
 
그리고 이들은 트레이드오프를 숨기지 않습니다. "시간이 부족해서 인증 기능은 단순화했고, 이런 한계가 있습니다"라고 솔직하게 말합니다. 완벽한 결과물보다, 제약 속에서 어떤 선택을 했는지가 더 신뢰를 줍니다. 면접관 입장에서는 "이 사람이 실무에서 시간 압박을 받을 때 어떻게 판단할까"를 미리 보여주는 자료가 되는 셈입니다.
 
 
## 의사결정 과정이라는 변별력
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/4071a405-6d25-408a-ba06-090d30a8f312/image.png)
조금 더 구체적으로 들어가 보겠습니다. 채용 현장에서 변별력으로 작용하는 요소는 크게 네 가지로 나뉩니다.
 
**첫째, 문제 정의입니다**. 무엇을 만들었는지 보다 왜 그것을 만들기로 했는지가 먼저입니다. "투두리스트 앱을 만들었습니다"보다 "팀 프로젝트를 하면서 할 일 분배가 자꾸 누락되는 걸 보고, 담당자별로 자동 알림이 가는 투두리스트를 만들었습니다"가 훨씬 구체적입니다. 전자는 흔한 연습용 프로젝트로 읽히지만, 후자는 직접 관찰한 문제에서 출발한 결과물로 읽힙니다. 문제 정의가 명확한 지원자는 보통 사용자 인터뷰나 직접 사용해 본 경험을 함께 언급합니다. "주변 친구 5명에게 일주일간 써보게 했더니 이런 불편함을 말해줬다"라는 식의 한 줄이, 화려한 기능 열 개보다 더 강한 인상을 남깁니다.
 
**둘째, 기술 선택의 이유입니다**. "React를 사용했습니다"라고만 쓰면 정보가 없습니다. "초반에는 Vue로 시작했는데, 컴포넌트 재사용이 많아지면서 타입 추론이 강한 React와 TypeScript 조합으로 바꿨습니다"라고 쓰면, 단순히 유행하는 기술을 따라간 게 아니라 직접 비교하고 판단했다는 게 드러납니다. 여기서 중요한 건 기술 자체의 화려함이 아닙니다. "왜 그 기술이 이 프로젝트에 맞았는가"를 설명할 수 있는지가 핵심입니다. 같은 React를 썼더라도, 그 이유를 설명하는 깊이에서 차이가 크게 벌어집니다.
 
**셋째, 트레이드오프 인식입니다**. 모든 프로젝트에는 제약이 있습니다. 시간, 경험, 리소스. 이걸 숨기지 않고 "이런 부분은 의도적으로 단순화했고, 이유는 이렇습니다"라고 말할 수 있는 지원자는 실무에서도 비슷하게 판단할 거라는 신뢰를 줍니다. 반대로 모든 게 완벽했다고 주장하는 포트폴리오는 오히려 의심을 받습니다. 한 시니어 개발자는 이렇게 말했습니다. "완벽한 프로젝트는 없습니다. 다 잘했다고 말하는 사람보다, 어디서 타협했는지 정확히 짚어내는 사람이 실무에 더 빨리 적응합니다."
 
**넷째, 실패와 한계를 인정하는 태도입니다**. "이 부분은 시간 안에 완성하지 못했습니다", "이 구조는 지금 다시 보면 잘못된 선택이었던 것 같습니다"라고 말할 수 있는 사람은 자신감이 없는 게 아니라, 자기 코드를 객관적으로 볼 줄 아는 사람입니다. 면접관들이 의외로 이 부분에서 좋은 인상을 받는다고 자주 언급합니다. 실패를 감추려는 지원자는 질문이 깊어질수록 점점 말이 궁해지지만, 한계를 먼저 인정한 지원자는 오히려 그다음 질문에서도 여유 있게 대답을 이어갑니다.
 
 
## 비슷한 결과물, 다른 합격 통지
여기 가상의 두 지원자가 있습니다. 둘 다 비슷한 시기에 비슷한 주제로 포트폴리오를 제출했습니다. 일정 공유 캘린더 앱이었습니다. 기능도 거의 같았습니다. 일정 등록, 공유, 알림. 화면 디자인도 둘 다 깔끔했습니다.
 
A 지원자의 README에는 기능 목록이 나열되어 있었습니다. "일정 등록 기능", "팀원 초대 기능", "알림 기능". 면접에서 "왜 이 앱을 만들었나요?"라고 묻자 "캘린더 앱이 흔한 주제라서 포트폴리오로 좋을 것 같았습니다"라고 답했습니다.
B 지원자의 README에는 짧은 배경 설명이 있었습니다. "동아리 일정 조율이 카카오톡 단체방에서 매번 흩어져서, 누가 언제 가능한지 한눈에 보기 힘들었습니다. 그래서 가능 시간을 표시하면 자동으로 겹치는 시간을 찾아주는 기능을 중심으로 만들었습니다." 면접에서 같은 질문을 받자 B는 실제 동아리에서 겪은 불편함과, 그걸 해결하기 위해 어떤 대안들을 검토했는지를 구체적으로 설명했습니다.
 
결과는 B 지원자의 합격이었습니다. 면접관은 후에 이렇게 평가를 남겼습니다. "기능은 거의 같았지만, B는 자기가 겪은 문제에서 출발했다는 게 분명했습니다. 같은 기능도 다르게 보였습니다." 같은 결과물이라도, 그 뒤에 어떤 이야기가 있느냐가 평가를 갈랐던 셈입니다.
 
 
## 포트폴리오에 남겨야 할 것
그렇다면 포트폴리오를 어떻게 준비해야 할까요? 핵심은 결과물이 아니라 기록입니다.
 
README에 기능 목록만 나열하지 말고, "왜"를 적어보세요. 어떤 문제를 봤고, 어떤 대안들을 고민했고, 왜 지금의 구조를 선택했는지. 형식을 굳이 거창하게 잡을 필요는 없습니다. "이 프로젝트를 시작한 이유", "고민했던 선택들", "한계와 다음에 시도하고 싶은 것" 정도의 소제목만 있어도 충분합니다. 예를 들어 "고민했던 선택들" 항목에는 "처음엔 전체 페이지를 서버 렌더링으로 만들려 했지만, 실시간 갱신이 많은 화면이라 클라이언트 렌더링으로 바꿨습니다. 초기 로딩은 조금 느려졌지만, 데이터 갱신 속도를 우선했습니다"처럼 한두 줄의 이유만 적어도 충분히 인상을 남길 수 있습니다.
 
커밋 메시지나 PR 설명도 마찬가지입니다. "버그 수정"이라고만 적는 것과, "N+1 쿼리 문제를 발견해서 인덱스를 추가했고, 응답 시간이 1.8초에서 0.4초로 줄었습니다"라고 적는 것은 전혀 다른 인상을 줍니다. 후자는 그 자체로 면접에서 훌륭한 이야깃거리가 됩니다. 면접관이 깃허브 커밋 로그를 들춰볼 때, 이런 기록이 쌓여 있으면 굳이 면접에서 캐묻지 않아도 이미 합격점을 받는 경우도 있습니다.
 
AI 활용은 숨길 필요가 없습니다. 오히려 투명하게 보여주는 게 낫습니다. "이 기능의 초안은 AI 도구로 생성했고, 이후 에러 처리 로직과 엣지 케이스를 직접 보강했습니다"라고 적을 수 있다면, 그게 바로 AI 시대에 요구되는 진짜 실력입니다. AI를 썼다는 사실이 약점이 아니라, AI가 만든 결과를 검증하고 다룰 수 있다는 증거가 되는 셈입니다.
 
요즘은 AI를 안 썼다고 말하는 지원자보다, AI를 어떻게 검증하면서 썼는지 설명하는 지원자가 더 인상적입니다. 전자는 거짓말이거나 비효율적인 거고, 후자는 도구를 다루는 법을 아는 거니까요. AI 사용 여부를 감추려는 태도보다, 어디까지 AI에게 맡기고 어디서부터 직접 판단했는지 경계를 명확히 설명하는 태도가 더 높은 점수를 받는다는 뜻입니다. 한 면접관은 이렇게 말했습니다. "AI를 잘 쓰는 것도 실력입니다. 다만 그 결과를 검증하지 못하면서 썼다고만 말하면, 거기서 신뢰가 깨집니다."
 
 
## 면접 전 준비할 질문 리스트
포트폴리오를 완성했다면, 스스로에게 미리 질문해 보세요.
 
**✅ 이 프로젝트에서 가장 어려웠던 의사결정은 무엇인가요?
✅ 지금 다시 만든다면 무엇을 바꾸고 싶은가요?
✅ 가장 자신 없는 부분은 어디인가요? 
✅ 이 코드에서 가장 마음에 들지 않는 부분은 어디고, 왜 그렇게 남겨뒀나요?**
 
이 질문들에 솔직하게 답할 수 있다면, 면접 자리에서 어떤 질문이 와도 흔들리지 않습니다. 한 가지 팁이 있다면, 답을 미리 글로 적어보는 것입니다. 머릿속으로 정리됐다고 생각해도, 말로 꺼내려는 순간 생각보다 막히는 경우가 많습니다. 짧게라도 문장으로 써보면 면접 자리에서 훨씬 매끄럽게 설명할 수 있습니다.
 
가능하다면 친구나 스터디 동료에게 면접관 역할을 부탁해 모의 면접을 해보는 것도 좋습니다. 직접 만든 프로젝트라도, 막상 "왜 그렇게 했나요?"라는 질문을 연달아 받으면 생각보다 쉽게 말문이 막히곤 합니다. 미리 그런 지점을 찾아 답변을 정리해두면, 실제 면접에서는 훨씬 여유 있게 답할 수 있습니다.
 
모르는 것을 모른다고 말하는 솔직함도, 변별력의 한 축입니다. "거기까진 미처 생각하지 못했습니다. 지금 생각해 보면 이런 방식이 더 나았을 것 같습니다"라고 즉석에서 사고하는 모습을 보여주는 것도, 완벽한 답변을 외워서 말하는 것보다 더 좋은 인상을 줄 수 있습니다.
 
 
## 결국 남는 것은 생각의 흔적
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/fb823df0-75b5-496d-948f-05e20bf7d906/image.png)
 
AI 시대의 포트폴리오는 "내가 무엇을 만들 수 있는가"를 보여주는 자리가 아닙니다. 이제는 누구나 무언가를 만들 수 있습니다. **진짜 보여줘야 하는 건 "내가 어떻게 생각하는가"입니다**. 같은 도구를 써도, 문제를 보는 눈과 선택의 이유는 사람마다 다릅니다. 그 차이가 결국 변별력이 됩니다.
 
다음 포트폴리오를 다듬을 때, 기능 하나를 더 추가하기 전에 README 한 줄을 먼저 고쳐보세요. "이걸 만들었습니다"가 아니라 "이런 이유로 이렇게 만들었습니다"로. 화려한 기능보다, 그 기능을 만들기까지의 고민이 더 오래 기억에 남습니다. 그 한 줄의 차이가, 면접관의 머릿속에 남는 이름이 되어줄 겁니다.
 
 
 

### 📌 함께 읽으면 좋은 글
* [개발자가 문서를 안 쓰는 이유](https://community.programmers.co.kr/post/13767?utm_source=&utm_medium=&utm_campaign=&utm_content=gocoder_13767)
* [코드는 잘 짜는데 발표만 하면 왜 이럴까](https://community.programmers.co.kr/post/13597?utm_source=&utm_medium=&utm_campaign=&utm_content=gocoder_13597)
* [개발자가 숫자로 말해야 하는 이유](https://community.programmers.co.kr/post/13498?utm_source=&utm_medium=&utm_campaign=&utm_content=gocoder_13498)

 
 

![고코더 작가님 프로필 카드.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/c227824e-8b30-4bd8-b5a3-233a53dc4546/%E1%84%80%E1%85%A9%E1%84%8F%E1%85%A9%E1%84%83%E1%85%A5%20%E1%84%8C%E1%85%A1%E1%86%A8%E1%84%80%E1%85%A1%E1%84%82%E1%85%B5%E1%86%B7%20%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%84%91%E1%85%B5%E1%86%AF%20%E1%84%8F%E1%85%A1%E1%84%83%E1%85%B3.png)

AI 시대의 포트폴리오

프로그래머스 프론트엔드 데브코스 1기 수료 후 카카오헤어샵에 개발자로 합격한 고종현 님과의 인터뷰입니다. 비전공자의 한계를 극복하고자 선택한 데브코스에서 치열한 몰입과 협업을 통해 프론트엔드 개발자로 성장한 종현 님의 이야기, 끝까지 읽어보세요!
 
 
# 안녕하세요 종현님, 프론트엔드 분야에 관심을 가지게 된 계기가 궁금합니다.
데브코스에 참여하기 전, 앱 서비스를 만들기 위해 한차례 창업을 했었어요. 저는 원래 디자인 전공자였기 때문에 앱 서비스의 기획과 디자인을 바탕으로 제품의 컨셉을 만들었는데, **결국 이를 동작하게 만드는 것은 개발자**라는 것을 절실히 느끼게 됐어요. 그때 유튜브, Udemy와 같은 곳에서 제가 한 디자인을 구현하기 위해 무작정 HTML, CSS, JavaScript를 보고 따라 하며 개발을 배우게 되었죠.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/a3502236-45d9-4954-b441-5c66b2f3f845/image.png)
👆 종현 님이 개발했던 앱 서비스
 
# 다양한 부트캠프 중 프로그래머스 데브코스를 선택한 이유는 무엇인가요?
프로그래머스에서 코딩테스트 연습을 하다가 데브코스 모집 배너를 보게 되었어요. 프로그래머스 데브코스 1기, **첫 기수라 아직은 갖춰지지 않은 곳에서 이곳의 문화를 같이 만들어 가볼 수 있겠다 생각**했어요. 저와 같은 마음을 가지고 지원하신 분들과 함께하면 재밌겠다고 생각하기도 했고요!
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/59aee588-36fb-45e4-9781-fec7f981ac14/image.png)
 
# 데브코스 과정 참여 전, 이루고자 했던 목표는 무엇이었나요?
**비전공자의 컴플렉스로부터 벗어나고 싶었어요**. 교육에 참여하는 현업 개발자 멘토님들과 전공자/비전공자 수강생들과 함께한다면 그럴 수 있을 거라 기대했습니다. 목표는 80% 이상 달성했다고 생각해요.
 
데브코스에 참여하며 익혀야 할 키워드가 워낙 많았기 때문에 머리가 터질 것 같을 때도 있었지만, 점심, 저녁을 먹을 때도 쉴 틈 없이 강의를 봤어요. **전공자분들도 계셨기 때문에 매번 목표치를 정하고, 그분들의 전공 지식을 따라가기 위해 노력**했어요. 지금도 부족한 부분을 채우고자 좋은 컨퍼런스들이나 전문 서적을 보며 기본기를 다지고 있어요.
 
# 데브코스를 하며 기억에 남는 활동이 있다면 무엇인가요?
**팀 프로젝트**가 가장 기억에 남아요. 저는 협업을 위한 기초적인 Git과 GitHub 사용법도 몰랐어요. 백엔드가 어떻게 일하는 지도 전혀 몰랐고요. 팀 프로젝트를 진행하며 **백엔드 수강생분들과 좋은 동료가 될 수 있었고, 프론트엔드에 더욱 집중해서 퀄리티 있는 프로젝트**를 만들어볼 수 있었어요. 데브코스 수료 이후에도 팀원들과 계속 프로젝트를 함께했어요. 데브코스를 통해 좋은 인연들을 만날 수 있어 좋았습니다.

👉 [깃허브 보러가기](https://github.com/slamapp)
 

<div style="position: relative; max-width: 100%; padding-bottom: 56.25%; height: 0;"><iframe width="560" height="315" src="https://www.youtube.com/embed/AUMn0NgEqf4?si=fbg3aACVFhYcyTec" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen="" style="position: absolute; position: absolute; top: 0; left: 0; width: 100%; height: 100%;"></iframe></div>

 
# 학습 중에 힘든 순간은 없으셨나요? 어떻게 극복하셨나요?
너무너무 힘들었지만, 또 너무너무 재미있었습니다. **재미를 느끼지 못했다면, 힘든 학습 과정을 극복하지 못했을 것 같아요**. 제가 만드는 서비스가 유저를 더 편하게 만들어준다고 생각하면 설레고, 이런 마음 때문에 힘들어도 계속 작업할 수 있었던 것 같아요.
 
요즘에는 규칙적인 생활을 하려고 노력하고 있어요. 길게 오랫동안 좋은 서비스를 만드는 개발자가 되고 싶어서요!
 
# 어떤 개발자로 성장하고 싶으신가요?
**유저들과 꾸준히 소통하는 개발자**가 되고 싶어요. **사용자와 대화하며 받는 피드백은 개발에 큰 동기부여**가 되는 것 같아요. 카카오헤어샵에 들어가기 전에도 미용실을 여러 군데 다니며 유저들이 느끼는 불편한 점들을 들으려고 했어요. 예약 서비스를 만들다가 힘들 때에도 대충 토이 프로젝트 수준으로 만족할 수 없었어요.
 
"내가 만드는 프로젝트가 프로덕션이었다면?", "내가 유저였다면?" 하는 생각들을 많이 떠올렸던 것 같아요. 유저들과 꾸준히 소통하며 동기부여를 받고, 더 나은 서비스로 개선해나가는 개발자가 되고 싶어요.
 
# 데브코스가 취업에 도움이 되었나요?
저는 비전공자였기 때문에 기초적인 부분이 많이 부족했었어요. 하지만 **데브코스를 통해 만난 멘토님, 동기들과 24시간 동안 기초적인 부분들을 이야기**할 수 있었어요. 데브코스 수료 이후에도 자바스크립트 기초 스터디, 코딩테스트 스터디, 프로젝트 스터디 등을 통해 이야기를 나눌 수 있었어요. 이분들이 없었다면 저는 개발에 필요한 다양한 키워드들을 들을 수 없었을 거예요.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/a47cf99e-82e7-4f3e-b257-de9b26ef42f6/image.png)
 
# 데브코스 후배 수강생들을 위한 응원의 한마디 부탁드려요!
**저는 비전공자에 이과 출신도 아니었어요**. 수학도 포기했던 사람이었죠. 하지만 데브코스를 통해 개발자로 성장할 수 있었습니다. 여러분도 노력한다면 좋은 개발자가 될 수 있을 거라 확신합니다!
 
 
*※본 글은 2022년 3월에 최초 작성된 콘텐츠입니다.*

 
 
[![FE_배너.jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/ba385368-3bed-4d40-9892-6e07a1977cec/FE_%E1%84%87%E1%85%A2%E1%84%82%E1%85%A5.jpg)](https://school.programmers.co.kr/learn/courses/25243?utm_source=prgmblog&utm_medium=social&utm_campaign=school_25243_blog&utm_content=25243_banner)

[데브코스 후기] 디자이너에서 프론트엔드 개발자로 성장할 수 있었던 비결! - 프론트엔드 1기 수료생 고종현 님

8/13~8/14 양 일간 부산 벡스코에서 진행된 2026년 한국컴퓨터교육학회 학술대회에 프로그래머스가 함께했습니다. 

대학교수님들과 교육 관계자분들과 직접 만나 프로그래머스 AI 교육 성장 로드맵을 소개했던 특별한 현장 후기를 지금 바로 소개합니다! 
![Group 1000004355.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/017197e0-8afc-4bb5-9097-1bad0ae9f1c7/Group%201000004355.png)
 
## 프로그래머스 부스 운영: 역량평가 기반의 맞춤 AI 교육!
프로그래머스 부스에서 대학교수님과 사업단 단장님, 교육 관계자분들까지 한 분씩 직접 마주하며 역량평가 기반의 맞춤 AI 교육 프로그램을 소개하는 뜻깊은 시간을 가졌습니다. 

이번 학회에서는 중·고등학생 교사 대상 AI 교육 상담도 활발히 이어졌는데요. 이제 대학생 뿐만 아니라 중·고등학생에게도 필수적인 기초 역량으로 자리 잡았음을 다시 한번 실감할 수 있었습니다. 특히 AI 역량평가를 통한 개인 맞춤형 교육 제공과 학습 성과를 다각도로 분석해 주는 사후 평가 리포트에 많은 관심을 보여주셨습니다. 
![Group 1000004356 (2).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/b0bc86db-a2b0-414f-82ac-6205e2c171f2/Group%201000004356%20%282%29.png)
 
## 현장에서 시연한 프로그래머스 LMS & AI 학습 솔루션
프로그래머스는 AI 기능이 탑재된 LMS 시스템을 통해 맞춤형 교육을 제공하고 있는데요. 이번 부스에서는 'AI 리터러시 실습 문제'를 예시로 실제 LMS 시스템을 선보이며 핵심 기능을 상세히 안내해 드렸습니다. 
![Group 1000004358.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/6b12df94-2c0e-4d5f-80cb-35104ac19159/Group%201000004358.png) 
프로그래머스 교육은 LMS 시스템의 AI 어시스트를 활용하여 문제마다 적절한 횟수 제한을 두어 스스로 문제를 해결하도록 돕습니다. 또한, 본인 제출한 코드를 분석하여 AI 코드 피드백을 통해 오답 원인과 정교한 개선 가이드를 정밀하게 제공합니다. 

학생의 자립적 학습과 교수진의 평가 효율을 동시에 높여주는 LMS 시스템에 대한 많은 질문과 관심을 보여주셨습니다. 
 
## 대학 맞춤형 AI 교육으로 완성하는 실전 성장을 프로그래머스와 함께!
이번 학회 현장에서 대학교수님들과 사업단장님들과 소통하며 대학 현장에 최적화된 실질적인 AI·SW 교육 체계가 얼마나 절실한지 다시 한번 깊이 체감했습니다. 

프로그래머스는 단순 이론 강의가 아닌 대학 교육의 든든한 파트너로서 맞춤형 AI 교육 프로그램으로 체계화된 커리큘럼을 제공하겠습니다.

역량평가부터 실습 시연까지! 2026 한국컴퓨터교육학회에서 마주한 프로그래머스 AI 교육

디지털 서비스의 성과를 높이기 위해 가장 널리 사용되는 실험 기법 중 하나가 바로 A/B 테스트입니다. 이번 포스팅에서는 A/B 테스트가 무엇인지, 실제로 어떻게 구성하고 분석하는지를 설명드리고자 합니다.
 
> *If you can't measure, you can't improve it. - Peter Drucker*

"측정할 수 없다면 개선할 수 없다"는 현대 경영학의 아버지로 불리는 세계적인 경영학자 피터 드러커가 한 말입니다. 감이 아닌 성공실패 지표를 바탕으로 개선 여부를 측정해야 한다는 것인데, 이것이 바로 A/B 테스트의 기본 원칙이라고 할 수 있습니다. A/B 테스트가 다른 테스트들과 다른 특징들 중 하나는 실제 사용자를 대상으로 한다는 점입니다.
 
# A/B 테스트란 무엇인가?
온라인 A/B 테스트는 **디지털 마케팅 및 웹/앱 개발에서 두 가지 이상의 웹 페이지 또는 앱 버전을 비교하여 특정 목표 관점에서 어느 버전이 더 나은 성과를 내는지 확인**하는 데 사용되는 방법입니다. 이 A/B 테스트의 원조는 무작위 대조 시험(Randomized Controlled Trial)이라고 볼 수 있는데, 보통 이는 제약업계에서 새로운 약품의 효과를 측정하는 연구 방법입니다. 예를 들어, 특정 질병을 앓고 있는 환자들을 랜덤하게 5:5로 나눈 후, 한쪽에는 기존 치료 방법을 제공하고 다른 쪽에는 새로운 치료 방법을 제공한 후에 완치율과 같은 중요 지표를 바탕으로 신약의 효율성을 더 객관적으로 비교해보는 것입니다.
 
이 무작위 대조 시험을 온라인 환경으로 옮긴 것이 바로 A/B 테스트라고 할 수 있습니다. 예를 들어, 이커머스 사이트의 구매 프로세스가 5단계로 구성되어 있어 과정이 길고 복잡하다고 느껴져 이탈률이 높고 구매 전환율이 낮은 상황이라면, 이를 3단계로 축소했을 때 구매 전환율(Conversion rate)이 높아질 것이라는 가설을 세울 수 있습니다.
 
이러한 가설을 A/B 테스트로 검증하는 과정은, 이커머스 사이트를 방문한 사용자들을 무작위로 1:1 비율로 나눈 뒤, 한 그룹(A)에게는 기존의 5단계 구매 프로세스를, 다른 그룹(B)에게는 새로운 3단계 구매 프로세스를 노출시키는 방식으로 진행됩니다. 이후, 각 그룹의 구매 전환율을 기록하고, 이 데이터를 바탕으로 통계적 검정을 통해 두 버전 간의 성과 차이를 분석하고 비교(귀무가설을 사용)해보는 것이 일반적인 A/B 테스트입니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/2f7f83ad-a0f6-4cf1-abbb-2e3f8d77ec04/image.png)
[출처](https://www.invespcro.com/ab-testing/)
 
A/B 테스트 결과를 해석하는 일은 과학보다는 오히려 예술에 가까운 영역입니다. 그만큼, 가설 수립부터 사용자를 편향 없이 A와 B그룹으로 나누는 과정, 데이터를 기록하고 해석하는 모든 단계에서 경험과 직관이 중요하게 작용합니다. 또한, 이 과정을 자동화하고 태블로(Tableau)와 같은 대시보드 도구를 활용해 결과를 시각적으로 쉽게 파악할 수 있도록 하는 것도 A/B 테스트의 효과적인 운영에 있어 중요한 요소입니다.
 
# A/B 테스트 시스템의 구성
A/B 테스트 시스템은 기존 기능과 새로운 기능을 무작위로 나눈 사용자들에게 노출시키고 그 기록을 남기는 "**런타임 시스템**"과 이 기록을 바탕으로 성공실패 지표를 바탕으로 비교해서 시각화해주는 "**분석 시스템**" 두 가지로 구성됩니다. 보통 A/B 테스트 분석 시스템의 구현을 데이터 팀에서 맡는 것이 일반적이고, A/B 테스트 런타임 시스템은 데이터 팀을 포함한 다수의 팀이 협업해서 구현하는 것이 일반적입니다.
 
## 1️⃣ A/B 테스트 런타임 시스템
이 부분은 실제 A/B 테스트가 구현되는 부분으로 사용자를 편향 없이 무작위로 A와 B 그룹으로 나눈 뒤, 각 그룹에 서로 다른 기능을 노출시키고 그 결과를 기록하는 역할을 합니다. 이 시스템에서 중요한 부분은 사용자를 어떻게 A와 B로 나누는가입니다.
 
보통 한 시점에 여러 A/B 테스트가 동시에 진행되기 때문에, 사용자 그룹을 적절히 분리하지 않으면 동일한 사용자가 여러 테스트에 중복 참여하게 되어 결과에 영향을 줄 수 있습니다. 따라서 사용자의 테스트 소속 정보를 체계적으로 관리하는 것이 매우 중요하며, 이 정보는 이후 분석 단계에서 핵심적으로 활용됩니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/e34d32a9-829d-4eda-917e-3658e7b8e4e5/image.png)
 
## 2️⃣ A/B 테스트 분석 시스템
이 부분은 전적으로 데이터 팀의 역할입니다. 먼저 데이터 엔지니어링 팀이 분석에 필요한 모든 데이터를 ETL을 통해 읽어옵니다. 이후, 데이터 분석가는 dbt와 같은 도구를 활용해 A/B 테스트 분석에 필요한 요약 테이블을 생성합니다. 마지막으로, 이 데이터를 기반으로 통계적인 분석을 수행하고, 결과를 보다 쉽게 이해할 수 있도록 태블로(Tableau)와 같은 데이터 시각화 도구를 활용해 대시보드를 구성하는 것이 일반적인 흐름입니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/b1a747e2-113b-4ae7-a45f-c76d4317139b/image.png)
 
# 관련 강의 추천 (프로그래머스)
## 프로그래머스 국비 지원 데이터 분석 과정
프로그래머스 데이터 분석 데브코스는 국비 지원 장기 과정으로, **데이터 분석에 필요한 기초부터 실무까지 폭넓게 학습**할 수 있는 커리큘럼으로 구성되어 있습니다.
 
Excel, SQL, Python, 통계, 머신러닝, A/B 테스트, 데이터 시각화 등 다양한 실습 중심의 강의를 통해 실무 역량을 강화할 수 있습니다.
 

| No. | 교과목명 |
| --- | --- |
| 1 | 과정 OT 및 소개 |
| 2 | 데이터 분석 소개 (응용 분야, 데이터 문해력, 발전 트렌드) |
| 3 | Excel 데이터 분석과 스토리텔링 |
| 4 | SQL 기초와 데이터 분석 |
| 5 | 고급 SQL 활용 |
| 6 | Python Pandas 활용하기 |
| 7 | Python 데이터 분석과 통계와 시각화 |
| 8 | 좋은 지표 설계와 대시보드 구성 (Tableau, Superset) |
| 9 | 머신러닝 기초 |
| 10 | 다양한 데이터 분석과 ML 모델 만들어보기 (Kaggle 중심) |
| 11 | 텍스트 데이터 마이닝 (NLP) |
| 12 | 데이터 분석을 위한 A/B 테스트 |
| 13 | Chat GPT 프롬프트로 데이터 분석 시스템 설계하기 |
| 14 | 최종 프로젝트 |
 
 
※*본 글은 한기용 개발자의 글 일부를 재편집한 콘텐츠입니다.*
 
 
[![da-coding-test2(729x90).jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/43cd477c-faf5-4df5-81d5-a2e863d2f3d1/da-coding-test2%28729x90%29.jpg)](https://school.programmers.co.kr/learn/courses/25254?utm_source=prgm&utm_medium=social&utm_campaign=school_25254_blog&utm_content=25254_banner)

A/B 테스트 완벽 가이드: 개념부터 실전 적용까지

## 📢 프로그래머스 데브코스, KCC2025 부스 참가!
지난 7월, 제주국제컨벤션센터(ICC)에서 열린 2025 한국컴퓨터종합학술대회(KCC2025)에 프로그래머스 데브코스가 참가해 성공적으로 부스를 운영했습니다.
 
3일간 진행된 이번 부스 운영은 학부생, 대학원생, 연구자, 기업 실무자 등 수많은 IT 관계자들의 관심 속에 마무리되었는데요. 현장 분위기만큼이나 데브코스에 대한 관심도 그야말로 후끈했습니다!
 
이번 참가를 통해 프로그래머스는 단순한 과정 소개를 넘어, 산학 협력 기회를 넓히고, 최신 기술 트렌드를 함께 공유하는 소통의 장을 만들고자 했습니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/dacc039c-2cbe-463f-a7ca-f83ce413dd68/image.png)
 
## 🔍 주요 활동과 현장 반응 살펴보기
### 800여 명이 찾은 부스, 상담 줄이 끊이지 않았어요!
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/03258e71-bdb7-40ed-96a3-e1e704de4ed8/image.png)
 
데브코스 부스는 KCC2025 현장에서 가장 눈에 띄는 인기 부스 중 하나였습니다. 총 800명 이상의 방문객이 다녀갔고, 유일하게 줄을 서서 상담을 받을 정도로 많은 분들이 관심을 보였어요.
 
학부생부터 대학원생, 취업 준비생, 기업 담당자, 교수님들까지 다양한 분들이 찾아와주셨고, 데브코스 교육 과정, 데브코스 참여 방법, 취업 연계 및 산학 협혁 방안 등 깊이 있는 상담을 진행했답니다!
 
### 퀴즈 이벤트로 더 가까이 다가간 데브코스
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/287949e8-eb99-4d8e-9398-a93249061b6b/image.png)
 
부스를 찾은 분들이 가장 반가워한 순간은 바로 퀴즈 이벤트!
간단한 퀴즈를 통해 데브코스를 더 잘 이해하고, 직접 뽑기를 통해 다양한 상품도 받아갈 수 있었습니다.
 
재미와 정보, 두 마리 토끼를 잡으로 부스의 활기를 더해준 즐거운 시간이었습니다. 🎁
 
### 학생 리셉션, 미래 개발자들과의 특별한 만남
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/5bbc366e-92c3-4f43-83bb-5ea01eedc96c/image.png)
 
7월 2일에 진행된 학생 리셉션은 잠재력 넘치는 미래 개발자들과 직접 소통하는 매우 의미 있는 자리였습니다. 개발자를 꿈꾸는 학부생과 대학원생을 직접 만나, 그들의 고민을 듣고 데브코스가 제안하는 실전 중심의 성장 경로를 함께 나눌 수 있었는데요. 단순한 교육 소개가 아니라 개인의 진로와 커리어에 대해 진심으로 공감하고 소통하는 자리가 되었습니다.
 
## 💬 데브코스를 더 많이 알리고, 더 가까이에서 만났습니다.
KCC2025 참가는 프로그래머스 데브코스에 있어 특별한 경험이었습니다.
 
이번 경험을 바탕으로 프로그래머스 데브코스는 앞으로도 더 많은 대학생, 대학원생, 취업 준비생, 그리고 IT 기업과의 연결을 통해 더 많은 성장과 기회를 만들어가고자 합니다.
 
부스를 방문해주신 모든 분들의 뜨거운 관심과 응원 덕분에 더욱 힘을 얻었습니다.
앞으로도 다양한 현장에서 만나고, 더 많은 이야기를 나눌 수 있기를 기대합니다.
프로그래머스 데브코스와 함께 성장하는 여정, 계속 함께해 주세요! 🙌
 
 
### 내일배움카드만 있으면 누구나 참여 가능한 실무 중심 부트캠프!
**👉 [프로그래머스 데브코스 자세히 알아보기](https://school.programmers.co.kr/learn/KDT)**

프로그래머스 데브코스, KCC2025 참가 성공적으로 마무리!

# 리시케시
 
인도의 명상 성지, 신성한 갠지스강이 흐르는 **리시케시**(**The Meditation Capital of the World**)는 '요가의 수도'이자 '명상의 수도'로 불립니다. 1968년 비틀즈가 이곳에서 마하리시 마헤시 요기와 함께 초월명상을 배웠던 일화는 전설이 되었습니다. 존 레논, 폴 매카트니, 조지 해리슨, 링고 스타는 이곳 마하리시 아쉬람에서 수개월간 머물며 명상을 통해 내면의 평화를 찾았고, 이 경험은 그들의 음악에 깊은 영향을 미쳤다고 합니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/e38fcfe0-0cdb-4187-a154-5591040f0eb4/image.png)
 
스티브 잡스는 20대 초반에 친구 다니엘 코트키와 함께 리시케시를 찾았습니다. 7개월간의 이 여정은 단순한 여행이 아닌, 깊은 자아발견의 시간이었습니다. 월터 아이작슨의 전기에서 잡스는 명상을 "자신을 온전히 알아가는 과정"이라고 정의했습니다. 그에게 명상은 내면과 외부 세계에 대한 자신의 반응을 이해하는 방법이었고, 문자 그대로 '자신을 즐기는' 시간이었습니다.

이 시기는 잡스가 힌두 문화를 처음 깊이 있게 접한 때였습니다. 그의 리시케시 방문은 우연이 아닌, 시대의 흐름과 맞닿아 있었습니다. 갠지스강가의 힌두 사원에서, 잡스는 단순히 명상만 배운 것은 아니었을 것입니다. 사원에서 제공하는 따뜻한 식사와 전 세계에서 모여든 자신과 같은 진리나 종교적인 깨달음을 얻기 위해 수행하는 구도자들과 교류하며 다양한 관점을 접했습니다. 이러한 **명상을 통한 다양한 관점을 경험한 스티브 잡스는 세계 최고의 IT 회사를 운영하는데 큰 도움**이 되었을 것입니다.
 
# 개발자의 리시케시
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/ec510643-fc1c-4799-bbe6-a39141802cb6/image.png)
 
저도 명상을 즐겨합니다. 계기는 그저 우연히 유튜브를 시청하다 알고리즘에 나타난 명상 음악이 참 오묘했기 때문입니다. 그 음악에서도 마음의 고요한 파도를 만든 소리는 싱잉 볼(Singing Bowl)의 울림이었습니다. 티베트 불교에서 유래한 이 악기는 깊고 진동감 있는 소리로 명상 중에 매우 효과적인 도구입니다. 다양한 크기의 볼을 두드리거나 문지르며 나는 소리는 심리적인 안정과 심신의 균형을 돕는다고 합니다. 이 소리가 너무 좋아 아무 생각 없이 멍하게 앉아 있기만 했을 뿐인데 하루 동안 쌓인 스트레스와 더러워진 생각들이 씻겨 내려가는 기분이 들기 때문입니다. 마치 욕조에 따뜻한 물을 가득 담아놓고 30분 정도 쉬고 나온 기분이랄까요? 참으로 기분 좋은 느낌입니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/ed54a6b8-1c5f-430a-bb36-e22fb65d11e7/image.png)
 
개발자는 매일 코딩을 합니다. 워라벨이 좋은 회사에 다니더라도 하루에 최소 6시간 이상은 코딩을 할 것입니다. 만약 야근이라도 한다면 10시간 넘기는 건 순식간입니다. 집중력이 좋은 개발자들은 긴 시간을 누리며 코딩을 열심히 할 수 있겠지만 저 처럼 집중력이 짧은 개발자들에게는 여간 고통이 아닐 수 없습니다. 마치 뜨거운 난로 위에 앉은 시간처럼 지루하고 길게 느껴지기 때문입니다. 그래서 제가 찾은 **지루한 코딩을 이기는 방법 중 하나가 바로 명상하듯 코딩을 하는 것**입니다. 음? 조금 이상하게 들리시나요? 하지만 이것은 제가 10년 넘게 코딩을 하면서 지금도 여전히 사용하는 방법입니다. 한번 이 흥미로운 주제에 집중해보시길 바랍니다.
 
개발자는 컴퓨터 앞에서 조용히 자신만의 시간을 가질 수 있는 직업입니다. 마치 매일 리시케시로 떠나온 여행자와 같은 신세라고 할 수 있죠. 출근한 사무실 앞 컴퓨터와 키보드는 매일 만나는 리시케시입니다. 굳이 혼자만의 시간을 찾아 떠나지 않아도 **언제나 개발자는 혼자 그곳에 앉아 컴퓨터와 대화**를 합니다. 그것이 개발자의 매력입니다. 그러므로 매일 우린 명상하듯 코딩을 할 수 있는 훌륭한 여건이 됩니다.
 
# 코딩을 명상처럼
과연 코딩을 명상처럼 할 수 있을까요? 처음 들으면 다소 엉뚱하게 들릴 수도 있습니다. 명상은 고요 속에서 자신을 돌아보는 시간이고, 코딩은 끊임없이 생각하고 문제를 해결해야 하는 지적 활동이니까요. 하지만 조금만 다른 관점에서 바라보면, 코딩과 명상은 놀랍도록 많은 공통점을 가지고 있습니다.
 
명상이 우리의 마음을 고요히 들여다보는 과정이라면, 코딩 역시 문제의 본질을 깊이 들여다보는 과정입니다. 명상을 통해 우리가 갖고 있던 잡념과 선입견을 내려놓듯이, 코딩할 때도 기존의 방식에 대한 고정관념을 내려놓고 새로운 해결 방법을 발견하게 됩니다. 또한 **명상이 꾸준한 수련을 통해 깊어지듯, 코딩 역시 지속적인 실천을 통해 더 깊은 통찰**을 얻게 됩니다.
 
이제 우리가 어떻게 코딩을 명상적 수행으로 바꿀 수 있는지, 그 구체적인 방법들을 하나씩 살펴보겠습니다. 이 방법들은 제가 오랜 시간 시행착오를 거치며 발견한 것들로, 여러분의 코딩 여정에도 작은 도움이 되길 바랍니다.
 
## 고요한 디지털 기기의 소리
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/c225ad11-ff8f-40d9-b1ed-450bc2903a50/image.png)
 
명상할 때 듣는 티베트 싱잉볼의 규칙적인 울림처럼, **코딩할 때의 키보드 타이핑 소리도 일종의 명상음**이 됩니다. 특히 기계식 키보드를 사용하는 개발자들은 공감하실 것입니다. 또한 코드를 입력하기 위해 **마우스 포커스를 이동할 때 나는 '딸칵'의 리듬감은 마치 싱잉볼의 울림이 심장을 파고들 때의 느낌**마저 듭니다. 잘 모르시겠다고요? 한번 코딩하는 고요한 시간 속에서 들리는 디지털 기기의 소리를 싱잉볼처럼 느껴보세요. 마치 인도 사원에서 울리는 종소리나, 자연 속에서 들리는 새소리처럼 평화로운 울림을 발견할 수 있습니다. 그러면 지루한 사무실의 좁은 내 자리도 어느새 평화로운 리시케시로 변할 것입니다.
 
## 반복
코딩은 반복의 연속입니다. 특히 프로젝트 중반이 넘어가면 비슷한 패턴의 코드를 작성하는 시간이 늘어납니다. 이런 반복이 지루하게 느껴질 수 있지만, 이 과정 자체가 하나의 명상이 될 수 있습니다. 얼핏 단순해 보이는 '반복' 속에서 우리는 새로운 통찰을 발견하게 됩니다. 매일 같은 코드를 들여다보다 보면, 전에는 보이지 않던 패턴이 눈에 들어오기 시작합니다. 수천 번 작성한 if문에서 더 나은 최적화 방법을 찾아내기도 하고, 반복적으로 만든 함수에서 새로운 설계 패턴을 발견하기도 합니다.
 
마치 명상에서 같은 동작을 반복하며 깊이를 더해가듯, 코딩의 반복도 단순한 되풀이가 아닌 깊은 통찰로 이어질 수 있습니다. 반복되는 코드 속에서 더 우아한 해결책을 발견하고, 더 효율적인 접근 방법을 찾아내는 것. 이것이 바로 코딩의 반복이 우리에게 주는 특별한 선물입니다. 그러므로 반복되는 코딩을 단순한 작업이 아닌, 새로운 발견을 위한 수행이라는 마음가짐으로 대해보시길 바랍니다.
 
## 알아차림
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/2f7e2565-d85b-4959-bfdd-fa4ac7522280/image.png)
 
명상의 핵심인 '알아차림'은 코딩에서도 중요한 역할을 합니다. 버그를 마주했을 때 당황하지 않고 차분히 코드를 살펴보는 능력, 복잡한 문제 앞에서도 침착하게 해결책을 찾아가는 태도는 마치 명상을 통해 내면의 평화를 찾아가는 과정과 닮아있습니다. 이러한 깨달음은 지속적인 명상적 코딩을 통해 자연스럽게 얻어지는 것들입니다.
 
복잡한 레거시 코드를 리팩토링할 때 우리는 종종 조급함을 느낍니다. "이걸 언제 다 고치지?"라는 생각이 마음 한켠을 계속 찌르곤 하죠. 하지만 이때 필요한 것이 바로 알아차림입니다. **코드의 흐름을 천천히 따라가며, 각 함수와 변수가 어떤 역할을 하는지, 왜 이렇게 설계되었는지를 깊이 있게 이해**하는 것입니다.
 
특히 버그 디버깅 과정은 알아차림의 진정한 가치를 경험할 수 있는 순간입니다. 에러 메시지가 화면에 떴을 때, 많은 개발자들은 즉각적으로 해결책을 찾으려 합니다. Stack Overflow를 급하게 검색하거나, 여러 가지 해결책을 무작정 시도해보곤 하죠. 하지만 진정한 알아차림은 그 순간을 있는 그대로 받아들이고, 문제의 본질을 이해하려 노력하는 것에서 시작됩니다. **에러 메시지를 천천히 읽고, 콘솔 로그를 차근차근 살펴보며, 코드의 실행 흐름을 하나씩 따라가는 것**입니다.
 
이렇게 코딩의 모든 순간에 알아차림을 적용할 때, 우리는 더 나은 코드를 작성할 수 있을 뿐만 아니라, 개발 과정 자체에서 더 큰 만족감을 얻을 수 있습니다. 지속적인 알아차림의 실천은 단순히 기술적 숙련도를 높이는 것을 넘어서, 개발자로서의 전반적인 성장을 이끌어주는 귀중한 도구가 됩니다.
 
## 플로우 상태
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/a81ca204-00da-4427-bf02-e7d58c09eabd/image.png)
 
'플로우(Flow)' 상태는 "완전한 몰입과 집중의 순간, 시간의 흐름을 잊게 되는 최적의 경험"입니다. 마치 요가 수련자가 한 동작에서 다음 동작으로 자연스럽게 흐르듯, 코딩에서도 이러한 황홀경을 경험할 수 있습니다. 저는 이런 플로우를 주로 새벽 출근한 고요한 사무실에서 만납니다. 조용한 공간에서 코드를 작성하다 보면, 어느 순간 키보드가 마치 제 손가락의 연장선처럼 느껴지기 시작합니다. 마치 시를 쓰듯 코드가 자연스럽게 흘러나오고, 복잡했던 알고리즘이 퍼즐처럼 맞춰지며, 시간의 흐름조차 잊게 됩니다. **이렇게 깊은 몰입 상태에서 작성된 코드는 놀랍게도 더 우아하고 효율적**인 경우가 많습니다. 요가 동작이 익숙 해지듯 코딩의 익숙해져서 자연스럽게 흘러가는 코딩을 즐겨 보시길 바랍니다.
 
## 비움
![Frame 1000003817.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/65dfc15d-a07b-463c-a663-61c19e36e2be/Frame%201000003817.png)
 
레거시 코드를 마주할 때는 명상의 핵심 가르침인 '비움'이 큰 도움이 됩니다. 복잡하게 얽힌 오래된 코드 앞에서 막막함을 느낄 때, 저는 모든 선입견과 기존 구조에 대한 집착을 내려놓는 연습을 합니다. 마치 명상에서 잡념을 비우듯, 코드에 대한 모든 가정을 비워내는 것입니다. 이렇게 마음을 비우고 코드를 바라보면, 신기하게도 새로운 관점이 열립니다. 복잡해 보이던 구조가 단순해지고, 얽혀있던 의존성이 명확해지는 것이죠. 이는 마치 명상 중에 복잡한 생각들이 정리되며 해답이 떠오르는 것과 같습니다.
 
명상에서 말하는 '비움'의 자세로 코딩에 임하면 여러 이점이 있습니다. **첫째, 기존 코드의 문제점을 더 객관적으로 볼 수 있습니다**. 기존의 구조나 패턴에 대한 선입견을 내려놓으면, 코드의 실제 문제점이 더 선명하게 보이기 시작합니다. **둘째, 새로운 해결 방법을 더 자유롭게 떠올릴 수 있죠**. 기존 방식에 얽매이지 않고 다양한 각도에서 문제를 바라보면, 더 효율적인 해결책이 떠오르기도 합니다.
 
**때로는 기존 코드 대부분을 과감히 지우고 처음부터 다시 작성하는 용기**도 생깁니다. 처음에는 두렵고 망설여지는 결정이지만, 비움의 자세로 접근하면 이런 과감한 결정도 자연스럽게 내릴 수 있습니다. 이런 과정을 거치면 더 견고하고 유지보수가 쉬운 코드를 만들 수 있습니다. 비움을 통해 더 나은 코드로 채워지는 것입니다.
 
# 명상과 코딩의 조화
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/30343be4-7c53-4a8d-8907-759c4d23607b/image.png)
 
리시케시에서 비틀즈와 스티브 잡스가 찾은 깨달음처럼, 우리 개발자들도 일상 속에서 자신만의 명상을 발견할 수 있습니다. 매일의 코딩이 단순한 작업이 아닌 깊은 통찰과 성장의 기회가 될 수 있다는 것, 바로 이것이 제가 전하고 싶은 메시지입니다. 지루하고 반복적으로 느껴지는 코딩 시간도, 마음가짐에 따라 우리에게 특별한 깨달음을 주는 순간이 될 수 있습니다.
 
**키보드를 두드리는 소리에서 명상의 울림을 찾고, 반복되는 코드에서 새로운 패턴을 발견하며, 플로우 상태에서 창의성을 경험**하는 것. 이러한 순간들이 모여 우리의 코딩 여정을 더욱 풍요롭게 만들어 줄 것입니다. 때로는 막막한 레거시 코드 앞에서도, 명상하듯 마음을 비우고 바라보면 새로운 해결책이 보이기 시작합니다. 복잡한 알고리즘도 차분히 바라보면 퍼즐이 맞춰지듯 해답이 떠오르곤 합니다.
 
여러분의 컴퓨터 앞이 바로 여러분만의 리시케시가 되길 바랍니다. **매일의 코딩이 단순한 업무가 아닌, 자아를 발견하고 성장하는 여정**이 되기를 희망합니다. 그곳에서 코딩의 즐거움과 내면의 평화를 동시에 찾으시길 진심으로 기원합니다. 우리 모두가 자신만의 방식으로 코딩과 명상의 조화를 이루며, 더 나은 개발자이자 더 나은 사람으로 성장할 수 있기를 바랍니다.
 
 
![고코더 작가님 프로필 카드.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/6070400e-42c8-41c6-8074-599a1c712637/%E1%84%80%E1%85%A9%E1%84%8F%E1%85%A9%E1%84%83%E1%85%A5%20%E1%84%8C%E1%85%A1%E1%86%A8%E1%84%80%E1%85%A1%E1%84%82%E1%85%B5%E1%86%B7%20%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%84%91%E1%85%B5%E1%86%AF%20%E1%84%8F%E1%85%A1%E1%84%83%E1%85%B3.png)

지루한 코딩을 이기는 방법: 코딩을 명상처럼

안녕하세요, 프로그래머스입니다! 
10/13부터 11/8까지 총 4주 동안 진행된 [프로그래머스 데브코스] 파이썬 코딩테스트 스터디의 생생한 후기를 공유하고자 합니다.
 
“파이썬 코테 뿌시기!”라는 목표로, 함께 달려온 모든 스터디원분들의 열정 덕분에 정말 값진 시간을 보낼 수 있었습니다!
 
 
## 📚 스터디 소개 및 커리큘럼: 4주 만에 파이썬 코테 뿌시기!
이번 스터디는 프로그래머스 데브코스 수료생만을 위한 맞춤형 성장 프로그램으로, 수료 이후에도 실력을 유지하고 취업 경쟁력을 높일 수 있도록 프로그래머스가 직접 알고리즘 스터디를 운영하였습니다. 
 
특별히 [**『코딩 테스트 합격자 되기 - 파이썬편』**](https://goldenrabbit.co.kr/product/pythonpass/)의 저자이자 오랜 알고리즘 스터디 경험을 바탕으로 수많은 취준생들의 코테 합격을 도와주신 멘토로 활동 중이신 삼성전자 머신러닝 개발자 박경록 멘토님과 함께 했는데요!
 
박경록 멘토님이 직접 설계해 주신 4주간 스터디 커리큘럼은 알고리즘/자료구조를 다시 한번 복기하고 코딩테스트 빈출 문제 위주로 전략적으로 구성되어 PCCP와 실전 입사 테스트를 체계적으로 준비할 수 있었습니다.
 
또한, 문제풀이뿐만 아니라 원리를 이해할 수 있도록 매주 월요일 LIVE 세션에서 상세히 설명해 주셔서 참여자들이 실전 감각과 코딩 실력을 동시에 끌어올리는 기회의 장으로 마련되었습니다.
 
총 4주간 빠르게 성장할 수 있는 커리큘럼으로 구성되어 진행했습니다.
 
- 1주차: 시간 복잡도 & 자료구조
- 2주차: 스택 & 큐
- 3주차: 그래프 탐색(BFS/DFS)
- [오프라인] 4주차: 최종 PCCP 모의고사
 
 
## 🧐 스터디는 어떻게 진행되었을까?
파이썬 코딩테스트 스터디는 1~3주차 온라인 세션, 4주차 오프라인 세션으로 진행되었습니다.
 
- **LMS에 등록된 주차별 알고리즘 과제를 개별적으로 풀이**
- 매주 금요일~일요일에는 팀별로 모여 각자가 풀이한 코드 공유 및 리뷰 진행
- 매주 **월요일 저녁 7시에는 온라인 LIVE 세션**에서 경록님의 문제 풀이 진행

 
개인이 성장하고, 팀이 성장하며 마지막으로 현직자 멘토님의 노하우까지 전수받을 수 있었습니다!
 
![파이썬 코테 이미지 가공 (1).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/b89509aa-687a-410d-a533-a807f6273e53/%E1%84%91%E1%85%A1%E1%84%8B%E1%85%B5%E1%84%8A%E1%85%A5%E1%86%AB%20%E1%84%8F%E1%85%A9%E1%84%90%E1%85%A6%20%E1%84%8B%E1%85%B5%E1%84%86%E1%85%B5%E1%84%8C%E1%85%B5%20%E1%84%80%E1%85%A1%E1%84%80%E1%85%A9%E1%86%BC%20%281%29.png)
 
 
## 🎯 라이브 세션은 어떻게 진행되었을까?
라이브 세션은 “답을 알려주는” 과정이 아닌 “스스로 생각하는 힘을 기르는 시간”이었는데요.
 
특히 "이 방식이 왜 더 빠를까?", “이걸 구현하려면 어떻게 해야 할까?” 등 단순히 해결 방법을 알려주는 게 아니라, “왜 이 상황에선 이 방식이 적절할까?”, “더 나은 방향성은 없을까?” 를 생각하며 문제 해결력까지 갖추도록 진행되었습니다. 
 
덕분에 답을 찾는 과정이 아니라 더 나은 해결책을 치열하게 고민하며 기본기를 탄탄하게 다지는 시간이 되었습니다.
 
![\[압축3\] video1344799650.gif](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/e8f606b9-7fe3-4643-b02d-284f9f879957/%5B%E1%84%8B%E1%85%A1%E1%86%B8%E1%84%8E%E1%85%AE%E1%86%A83%5D%20video1344799650.gif)
## ✍️ 오프라인 세션 현장 & 스터디 후기
![파이썬 코테 후기 이미지3 (2).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/3ff889f4-e594-4cde-a039-faf4a445406e/%E1%84%91%E1%85%A1%E1%84%8B%E1%85%B5%E1%84%8A%E1%85%A5%E1%86%AB%20%E1%84%8F%E1%85%A9%E1%84%90%E1%85%A6%20%E1%84%92%E1%85%AE%E1%84%80%E1%85%B5%20%E1%84%8B%E1%85%B5%E1%84%86%E1%85%B5%E1%84%8C%E1%85%B53%20%282%29.png)
 
11월 8일 강남 강의장에서 진행된 오프라인 세션에서는 PCCP 모의고사 과제를 함께 풀고, 네트워킹 시간을 가졌습니다. 이후, 자연스럽게 진로 상담과 취업 이야기로 이어졌는데요.
 
경록님이 실제로 개발자로서 겪은 시행착오, 그리고 삼성전자 등 주요 기업의 채용 문화와 코딩테스트 전략에 대한 솔직한 이야기도 들을 수 있었어요. 이런 대화 덕분에, 단순히 “코테 공부”를 넘어 “어떤 개발자가 되고 싶은가”를 스스로 돌아보는 계기가 되었다는 참가자들도 많았습니다.
 
![Frame 1000004328 (2).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/165a0af9-ad34-47e0-8c83-289504c4025a/Frame%201000004328%20%282%29.png)
 
이번 스터디에서 쌓은 실력과 자신감, 전략적인 문제 풀이 노하우를 바탕으로 앞으로의 도전에서도 한 단계 더 성장할 스터디원들을 항상 응원합니다! 😉
 
앞으로도 프로그래머스는 개발자를 꿈꾸는 여러분을 위한 다양한 학습 활동을 지원할 예정이니 많은 관심과 참여 부탁드립니다.
 
 
지금 바로 진짜 개발자로 성장하고 싶다면, 데브코스로 합류하세요!
 
 
[![DEV-AIBE-coding-test-02(1456x180).jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/d8a4113e-887f-4143-adde-1cdb7bbf3e4c/DEV-AIBE-coding-test-02%281456x180%29.jpg)](https://school.programmers.co.kr/learn/courses/25487?utm_source=prgmblog&utm_medium=social&utm_campaign=school_pythonstudy&utm_content=25487_AIBE)
[![DEV-DA-coding-test-02(1456x180).jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/a839ac22-951d-4207-b9e5-660d79acac87/DEV-DA-coding-test-02%281456x180%29.jpg)](https://school.programmers.co.kr/learn/courses/25485?utm_source=prgmblog&utm_medium=social&utm_campaign=school_pythonstudy&utm_content=25485_DA)
[![DEV-WFS-coding-test-02(1456x180).jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/9d47c3da-be87-4452-b605-755ce77b79ce/DEV-WFS-coding-test-02%281456x180%29.jpg)](https://school.programmers.co.kr/learn/courses/25486?utm_source=prgmblog&utm_medium=social&utm_campaign=school_pythonstudy&utm_content=25486_FS)

[프로그래머스 데브코스] 파이썬 코딩테스트 스터디, 열정 가득했던 4주간의 기록!

개발자라면 누구나 크고 작은 실수를 합니다. 
누군가는 서버를 멈추고, 누군가는 데이터를 날리고, 또 누군가는 한 줄의 코드로 사용자를 혼란에 빠뜨리기도 합니다.
중요한 건 그 실수를 어떻게 다루느냐이며, 이러한 경험을 발판으로 더 단단한 개발자가 될 수 있습니다.
오늘은 풀스택 시니어 개발자 고코더 님이 전하는 '실수로 성장하는 법', 그 생생한 경험과 배움을 나눠보겠습니다.
 
 
## 그날, 나는 운영 서버를 멈춰세웠다
새벽 2시 30분, 배포 버튼을 누른 순간 세상이 멈춘 것 같았습니다. Slack 알림이 폭포수처럼 쏟아졌습니다.
"사이트가 안 열려요", "로그인이 안 됩니다", "결제 오류가 발생했어요."
손이 떨렸고 식은 땀이 흘렀습니다. 개발 환경 설정 파일을 프로덕션에 그대로 배포한 것이었습니다.
 
그날 밤, 팀원 3명을 새벽에 깨워야 했고, 2시간 동안 서비스가 중단되었으며, 수천 명의 사용자가 피해를 입었습니다. 복구 후 작성해야 했던 사고 보고서는 제 개발자 인생에서 가장 괴로운 문서였습니다. 하지만 지금 돌이켜보면, 그날의 실수가 저를 더 나은 개발자로 만들었습니다.
 
개발자라면 누구나 실수를 합니다. 작은 버그부터 서비스 전체를 마비시키는 대형 사고까지, 그 스펙트럼은 다양합니다. 중요한 것은 실수 그 자체가 아니라, 실수를 어떻게 다루고 무엇을 배우느냐입니다. 이번 글에서는 **개발 현장에서 실제로 일어난 실수 사례들과, 그 실수를 성장의 발판으로 만드는 구체적인 방법**을 공유하겠습니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/e9b963a9-2a90-42b8-b1bc-fb9744d33a7c/image.png)
 
 
## 개발자들의 실수 이야기
### "DELETE FROM users" - WHERE 절을 잊다
선배 개발자 K씨의 이야기입니다. 데이터베이스 정리 작업 중, 테스트 계정을 삭제하려던 순간이었습니다. DELETE FROM users WHERE id = 12345 를 입력하려다가 WHERE 절을 쓰기 전에 실수로 엔터를 눌렀습니다. 화면이 잠깐 멈추더니 "3,247 rows affected"라는 메시지가 떴습니다.
 
순간 머릿속이 하얘졌습니다. 수천 명의 사용자 데이터가 순식간에 사라진 것입니다. 다행히 1시간 전 백업이 있었고, 빠르게 복구할 수 있었습니다. 하지만 그 1시간 사이에 가입한 신규 사용자 27명의 데이터는 영구 손실되었습니다.
 
이 사건 이후 팀에서는 운영 데이터베이스에 직접 쿼리를 실행하는 것을 원칙적으로 금지했습니다. 대신 쿼리 실행 전 반드시 SELECT로 영향 범위를 확인하고, 중요한 작업은 트랜잭션으로 감싸서 롤백 가능하도록 했습니다. 또한 모든 쿼리 실행 로그를 남겨 추후 추적 가능하도록 시스템을 개선했습니다.
 
 
### AWS 키를 GitHub에 올리다
신입 개발자 L씨는 개인 프로젝트를 진행하다가 환경 설정 파일을 실수로 GitHub에 커밋했습니다. 그 안에는 AWS 액세스 키가 포함되어 있었습니다. 커밋 후 불과 10분 만에 이상한 일이 벌어졌습니다. AWS에서 보안 경고 이메일이 날아왔고, 알 수 없는 EC2 인스턴스가 여러 개 생성되어 있었습니다.
 
누군가 자동화된 봇으로 GitHub를 모니터링하다가 노출된 키를 발견하고 즉시 악용한 것이었습니다. 다행히 빠르게 발견해서 키를 무효화했지만, 불과 몇 시간 만에 30만 원 상당의 과금이 발생했습니다. 회사에 솔직히 보고하고 사비로 처리했지만, 가슴이 철렁했던 경험이었습니다.
 
이후 L씨는 모든 프로젝트에 .gitignore를 철저히 설정하고, 시크릿 관리는 환경 변수나 AWS Secrets Manager를 사용하게 되었습니다. 또한 커밋 전에 민감 정보가 포함되지 않았는지 자동으로 검사하는 pre-commit 훅을 설정했습니다.
 
 
### 무한 루프가 만든 참사
백엔드 개발자 P씨는 배치 작업을 수정하던 중 실수로 무한 루프를 만들었습니다. 로컬에서는 데이터가 적어서 문제가 없었지만, 프로덕션에서는 수백만 건의 데이터를 처리하다가 메모리가 계속 쌓였습니다. 결국 서버가 다운되었고, 새벽 3시에 긴급 호출을 받았습니다.
 
황급히 서버를 재시작했지만, 배치 작업이 다시 실행되면서 또다시 서버가 다운되는 악순환이 반복되었습니다. 결국 해당 배치 작업을 완전히 비활성화하고, 코드를 수정한 후에야 서비스가 정상화되었습니다. 
 
이 경험 이후 팀에서는 모든 배치 작업에 타임아웃과 메모리 제한을 설정했습니다. 또한 서버 모니터링 시스템을 강화해서 CPU나 메모리 사용량이 임계치를 넘으면 즉시 알림을 받도록 했습니다. 로컬 테스트 환경에서도 프로덕션과 유사한 데이터 규모로 테스트하는 문화를 정착시켰습니다.
 
 
### 조건문의 작은 차이가 만든 큰 구멍
주니어 개발자 J씨는 프리미엄 사용자 검증 로직을 작성하면서 실수했습니다. if (user.isPremium == true) 대신 if (user.isPremium = true) 로 작성한 것입니다. 비교 연산자 대신 대입 연산자를 사용한 거죠. 이 코드가 배포되자, 모든 사용자가 프리미엄 권한을 갖게 되었습니다.
 
문제는 하루 만에 발견되었지만, 그 사이 수백 명이 무료로 프리미엄 기능을 사용했습니다. 매출 손실도 있었지만, 더 큰 문제는 신뢰 손실이었습니다. 일부 사용자는 "버그로 얻은 혜택을 왜 회수하느냐"라며 항의하기도 했습니다.
 
이 사건 이후 팀에서는 ESLint 같은 정적 분석 도구를 필수로 도입했습니다. 또한 중요한 비즈니스 로직에는 반드시 단위 테스트를 작성하도록 규칙을 정했습니다. 페어 프로그래밍도 주 1회 이상 진행하여 서로의 코드를 리뷰하는 문화를 만들었습니다.
 
 
## 실수 직후, 대응법
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/86fa4b7c-f570-4beb-b04a-91b35d9661cd/image.png)
 
### 1단계: 5분의 침착
실수를 발견한 순간, 대부분의 개발자는 패닉에 빠집니다. "끝났다", "어떡하지", "회사 그만둬야 하나"와 같은 생각이 머릿속을 휩쓸죠. 하지만 이 5분을 어떻게 보내느냐가 사고의 규모를 결정합니다.
 
먼저 심호흡을 세 번 하세요. 진부하게 들리지만, 실제로 뇌에 산소를 공급하고 이성적 사고를 돕습니다. 그리고 현재 상황을 객관적으로 파악하세요. "지금 무슨 일이 일어나고 있는가?", "영향 범위는 어디까지인가?", "즉시 롤백이 가능한가?"
 
패닉 상태에서 급하게 수정하려다가 문제를 더 악화시키는 경우가 많습니다. 차라리 **5분을 투자해서 상황을 정확히 파악**하는 것이 결과적으로 더 빠른 복구로 이어집니다.
 
 
### 2단계: 즉시 보고와 협업
많은 주니어 개발자들이 "혼자 해결해 보고 안 되면 보고하자"라고 생각합니다. 하지만 이는 최악의 선택입니다. 시간이 지날수록 피해는 커지고, 나중에 보고했을 때 "왜 진작 말하지 않았느냐"라는 질책을 받게 됩니다.
 
실수를 발견한 즉시 팀장이나 시니어 개발자에게 보고하세요. **명확하고 간결하게 상황을 전달하는 것이 중요**합니다. 다음과 같은 포맷을 사용하면 효과적입니다:
 
 
<div style="border-radius: 4px;padding:22px 20px; background: #F5F5F5; border: 1px solid #D6D6D6;">
[긴급] 배포 관련 장애 발생 
- 발생 시간: 2025-01-15 02:30 
- 영향 범위: 전체 사용자 로그인 불가 
- 현재 상태: 서비스 중단 중 
- 추정 원인: 환경 설정 파일 오류 
- 진행 중인 조치: 이전 버전으로 롤백 중 
- 예상 복구 시간: 10분 내 
- 도움 필요 여부: 데이터베이스 확인 필요 </div>

 
보고를 받은 시니어 개발자는 경험을 바탕으로 더 빠른 해결책을 제시할 수 있고, 필요하면 추가 인력을 투입할 수도 있습니다. 혼자 끙끙대며 1시간을 허비하는 것보다, 보고 후 팀과 협업해서 10분 만에 해결하는 것이 훨씬 낫습니다.
 
 
### 3단계: 복구 우선, 원인 분석은 나중에
사고 상황에서는 복구가 최우선입니다. 근본 원인을 파악하고 완벽한 해결책을 찾는 것은 서비스가 정상화된 이후의 일입니다. **가장 빠른 복구 방법은 대부분 롤백**입니다.
 
롤백이 불가능하거나 데이터 손실이 발생한 경우에는 백업을 활용하세요. 정기적인 백업이 없다면, 지금부터라도 백업 전략을 수립해야 합니다. 복구 과정에서 모든 행동을 기록하세요. 나중에 사고 경위를 작성할 때 정확한 타임라인이 필요합니다.
 
복구가 완료되면 서비스 상태를 모니터링하면서 재발하지 않는지 확인하세요. 때로는 복구했다고 생각했는데 다른 문제가 연쇄적으로 발생하는 경우도 있습니다.
 
 
### 4단계: 투명한 사후 대응
서비스가 정상화되면 사내에 공지하세요. 투명하게 상황을 설명하고 진심으로 사과하는 것이 신뢰를 지키는 방법입니다. "일시적인 시스템 오류"같은 모호한 표현보다는 "배포 과정에서 발생한 설정 오류로 인해 2시간 동안 서비스가 중단되었습니다"처럼 구체적으로 설명하세요.
 
내부적으로는 사고 보고서를 작성합니다. 이때 중요한 것은 개인을 비난하는 것이 아니라 시스템의 취약점을 찾아내는 것입니다. "누가 잘못했는가"가 아니라 "**무엇이 잘못되었고, 어떻게 개선할 것인가**"에 집중하세요.
 
 
## 실수를 예방하는 시스템 설계
### 1️⃣ 자동화로 사람의 실수 줄이기
사람은 실수하는 존재입니다. 아무리 주의해도 피곤하거나 급할 때는 실수가 나옵니다. 그래서 시스템이 사람의 실수를 막아줘야 합니다.
 
**배포 전 자동 검증 스크립트**를 만드세요. 환경 변수가 올바른지, 데이터베이스 마이그레이션이 안전한지, 테스트가 모두 통과했는지 자동으로 확인합니다. 사람이 체크리스트를 보며 하나씩 확인하는 것보다 훨씬 정확하고 빠릅니다.
 
**린터(Linter)와 정적 분석 도구**도 필수입니다. ESLint, Pylint, SonarQube 같은 도구들이 코드를 작성하는 순간 잠재적 버그를 잡아줍니다. =와 ==의 혼동, null 체크 누락, 사용하지 않는 변수 같은 흔한 실수들을 사전에 방지할 수 있습니다.
 
 
### 2️⃣ 체크리스트의 힘
항공기 조종사들은 이륙 전 반드시 체크리스트를 확인합니다. 수천 시간 비행한 베테랑도 예외 없습니다. 왜일까요? 사람의 기억은 불완전하고, 긴장하면 당연한 것도 놓치기 때문입니다.
 
개발자도 마찬가지입니다. 중요한 작업에는 체크리스트를 만드세요:
 
**📌 배포 체크리스트 예시**
<div style="border-radius: 4px;padding:22px 20px; background: #F5F5F5; border: 1px solid #D6D6D6;">
[ ] 모든 테스트 통과 확인 
[ ] 환경 변수 설정 확인 
[ ] 데이터베이스 마이그레이션 검토 
[ ] 롤백 계획 수립 
[ ] 모니터링 대시보드 준비 
[ ] 배포 시간대 확인 (트래픽이 적은 시간) 
[ ] 팀원에게 배포 알림 
[ ] 배포 후 로그 모니터링 (최소 10분) </div>

 
처음에는 귀찮게 느껴지지만, 한 번의 체크리스트가 한 번의 대형 사고를 막아줍니다.
 
 
### 3️⃣ 페어 프로그래밍과 코드 리뷰
혼자 코드를 작성하면 자신의 사각지대를 보지 못합니다. 하지만 다른 사람의 눈을 거치면 놓쳤던 문제를 발견할 수 있습니다.
 
**페어 프로그래밍**은 실시간으로 서로의 실수를 잡아줍니다. 한 사람이 코드를 작성하면 다른 사람이 로직을 검토하고 질문합니다. "이 경우는 어떻게 되나요?", "null일 때는요?", "사용자가 이렇게 입력하면요?" 이런 질문들이 버그를 사전에 방지합니다.
 
**코드 리뷰**도 마지막 안전장치입니다. 특히 프로덕션에 영향을 주는 중요한 변경은 반드시 2명 이상의 리뷰를 거치도록 하세요. 리뷰어는 단순히 코드 스타일만 보는 것이 아니라, 비즈니스 로직의 정확성, 예외 처리, 성능, 보안 등을 종합적으로 검토해야 합니다.
 
 
## 비난하지 않는 팀 문화 만들기
![15523.jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/fac16468-bb3a-4bf3-a77c-f693f52bfc62/15523.jpg)
 
### ✅ "누가"가 아닌 "왜"에 집중하기
장애가 발생하면 본능적으로 책임자를 찾게 됩니다. "누가 이런 코드를 작성했어?", "누가 이걸 배포했어?" 하지만 이런 질문은 문제 해결에 도움이 되지 않습니다.
 
대신 "왜 이런 일이 발생할 수 있었는가?"라고 물어야 합니다. 시스템적 관점에서 보면, 개인의 실수는 결과일 뿐 원인이 아닙니다. **진짜 원인은 실수를 가능하게 만든 프로세스, 도구, 문화**에 있습니다.
 
예를 들어, "왜 테스트를 안 했어?"라고 비난하는 대신 "왜 테스트 없이 배포가 가능했는가? CI/CD 파이프라인에 테스트 단계가 있었는가? 테스트 작성 시간이 일정에 포함되어 있었는가?"라고 질문해야 합니다.
 
 
### ✅ 실수를 공유하는 문화
실리콘밸리의 많은 회사들은 "failure party" 또는 "fuckup night"이라는 문화를 가지고 있습니다. **정기적으로 모여서 각자가 한 실수와 그로부터 배운 교훈을 공유하는 자리**입니다.
 
처음에는 부끄럽고 창피하게 느껴지지만, 팀원들도 비슷한 실수를 공유하면서 "나만 실수하는 게 아니구나"라는 안도감을 느낍니다. 더 중요한 것은, 한 사람의 실수에서 팀 전체가 배울 수 있다는 점입니다.
 
실수를 숨기는 문화는 같은 실수를 반복하게 만듭니다. 하지만 실수를 투명하게 공유하는 문화는 팀 전체의 면역력을 높입니다.
 
 
## 위대한 개발자들도 실수했다
혹시 자신의 실수 때문에 개발자로서 자격이 없다고 느끼시나요? 안심하세요. 세계 최고의 개발자들도 엄청난 실수를 했습니다.
 
2017년, 아마존 AWS의 S3 서비스가 4시간 동안 중단되었습니다. 원인은 엔지니어가 디버깅 명령을 잘못 입력해서 서버들을 대량으로 종료시킨 것이었습니다. 이 사고로 인터넷의 상당 부분이 마비되었고, 수백만 달러의 손실이 발생했습니다.
 
2014년, 애플의 iOS에서 "goto fail" 버그가 발견되었습니다. 단 한 줄의 중복된 코드 때문에 SSL 검증이 제대로 작동하지 않아 심각한 보안 취약점이 생긴 것입니다. 세계 최고의 개발자들이 모인 회사에서도 이런 단순한 실수가 발생합니다.
 
2021년, 페이스북(현 메타)은 전 세계 서비스가 6시간 동안 중단되는 대참사를 겪었습니다. BGP 라우팅 설정 변경 중 실수로 모든 데이터센터가 인터넷에서 사라진 것입니다. 수십억 달러의 손실과 함께 전 세계 수십억 사용자가 영향을 받았습니다.
 
이런 사례들은 두 가지를 말해줍니다. 첫째, **누구나 실수합니다**. 경력, 실력, 회사 규모와 무관하게 실수는 일어납니다. 둘째, 중요한 것은 **실수를 어떻게 다루느냐**입니다. 위 회사들은 모두 투명하게 사고를 공개하고, 재발 방지를 위해 시스템을 개선했으며, 그 과정에서 얻은 교훈을 커뮤니티와 공유했습니다.
 
 
## 당신의 실수 노트를 시작하세요
오늘부터 당신만의 실수 노트를 만들어보세요. 거창할 필요 없습니다. 간단한 메모장이나 노션 페이지면 충분합니다. 작은 실수라도 기록하세요. "오늘 변수명을 헷갈려서 30분을 허비했다"는 것도 훌륭한 기록입니다.
 
6개월 후 실수 노트를 펼쳐보면, 같은 실수를 반복하지 않는 자신을 발견하게 될 것입니다. 1년 후에는 후배 개발자에게 "나도 예전에 이런 실수했었는데..."라며 조언해 줄 수 있는 멘토가 되어 있을 것입니다.
 
완벽한 코드는 없습니다. 실수 없는 개발자도 없습니다. 하지만 실수에서 배우는 개발자와 같은 실수를 반복하는 개발자는 명확히 다릅니다. 당신의 실수는 당신만의 것이 아닙니다. 팀 전체가 함께 성장하는 귀중한 자산입니다.
 
실수를 두려워하지 마세요. 숨기지 마세요. 솔직하게 공유하고 함께 배우세요. 그것이 진정한 프로 개발자의 태도입니다. 당신의 실수 노트가 언젠가 가장 소중한 학습 자료가 되는 날이 올 것입니다.
 
 
### 📚 참고 문헌
* [Amazon explains big AWS outage, says employee error took servers offline, promises changes](https://www.geekwire.com/2017/amazon-explains-massive-aws-outage-says-employee-error-took-servers-offline-promises-changes/?utm_source=chatgpt.com)
* [The Apple goto fail vulnerability: lessons learned](https://dwheeler.com/essays/apple-goto-fail.html?utm_source=chatgpt.com)
* [More details about the October 4 outage](https://engineering.fb.com/2021/10/05/networking-traffic/outage-details/?utm_source=chatgpt.com)

 
 
### 📌 함께 읽으면 좋은 글
* [개발자의 인간관계: 코드보다 어려운 인간관계](https://community.programmers.co.kr/post/12607?utm_source=&utm_medium=&utm_campaign=&utm_content=gocoder_25oct)
* [개발자의 번아웃, 조용히 찾아오는 위험 신호들](https://community.programmers.co.kr/post/12542?utm_source=&utm_medium=&utm_campaign=&utm_content=gocoder_25aug)
* [개발자의 학습 곡선 정체기: 더 이상 실력이 늘지 않을 때](https://community.programmers.co.kr/post/12213?utm_source=&utm_medium=&utm_campaign=&utm_content=gocoder_25jun)

 
 
![고코더 작가님 프로필 카드.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/60171a84-84f6-4550-a558-cf2d2a5dde06/%E1%84%80%E1%85%A9%E1%84%8F%E1%85%A9%E1%84%83%E1%85%A5%20%E1%84%8C%E1%85%A1%E1%86%A8%E1%84%80%E1%85%A1%E1%84%82%E1%85%B5%E1%86%B7%20%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%84%91%E1%85%B5%E1%86%AF%20%E1%84%8F%E1%85%A1%E1%84%83%E1%85%B3.png)

개발자의 실수 노트: 실패에서 배우는 기술

KL Divergence는 인공지능이 예측과 실제 데이터 간의 차이를 학습하는 데 사용하는 핵심 수식입니다. 데이터 사이언티스트 정경문 님의 6월 아티클은 Haribo 곰돌이 젤리의 맛 분포를 예시로 들어, KL Divergence의 개념을 쉽고 재미있게 풀어냅니다. 엔트로피와 크로스 엔트로피, AI 모델 학습에서의 활용까지 궁금하다면, 지금 바로 글을 읽어보세요!

![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/49fcdbb5-8b40-4b23-b585-ecace1ba2cbc/image.png)
 
 
# 여러분은 어떤 색의 곰돌이 젤리 맛을 가장 좋아하세요?
Haribo 곰돌이 젤리에는 여섯 가지 맛이 들어있습니다. **라즈베리(빨강), 오렌지(주황), 레몬(노랑), 사과(초록), 파인애플(흰색), 딸기(짙은 빨강)** - 이렇게 여섯 색깔의 곰돌이들이 한 봉지 안에 섞여 있죠. 누군가는 빨간색 라즈베리 맛을 좋아하고, 또 누군가는 흰색 파인애플 맛을 최애 맛이라고 얘기합니다. 그런데 재미있는 사실은, 젤리 한 봉지 안에 들어 있는 각 맛의 개수가 제각각이라는 거예요. 어떤 맛이 몇 개나 들어 있을지는 랜덤이라서, 봉지를 열어보기 전까지는 아무도 알 수 없답니다. 그야말로 복불복이죠.
 
자, 그럼 한번 상상해 보세요. 당신은 평소 경험으로 Haribo 젤리 봉지에는 여러 가지 맛이 고르게 들어 있다고 생각합니다. 그래서 이렇게 예측해요.
 
* 빨강 20%, 주황 20%, 노랑 20%, 초록 20%, 흰색 20% → Q(x)
 

사실 라즈베리와 딸기는 둘 다 붉은 색상이기도 하니까, 설명의 편의상 다섯 가지 맛이라고 해볼게요. 그리고 우리는 이 집합을 Q(x)라고 부르겠습니다.
 
그런데 실제로 봉지를 열어보니 다음과 같았습니다.
 
* 빨강 40%, 주황 20%, 노랑 10%, 초록 10%, 흰색 20% → P(x)
 

이렇게 실제로 관찰한 확률을 P(x)라고 할게요. 당신의 예상 Q(x)과 현실 P(x)이 다르죠? 그럼 이 차이를 어떻게 수치로 표현할 수 있을까요?
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/2acdbdf7-b542-48fc-9d94-ea934870f3aa/image.png)
 
곰돌이 젤리에 대한 실제 분포 P(x)와 예측 분포 Q(x)
바로 여기서 등장하는 개념이 **KL Divergence**입니다.
 
# 확률 분포의 차이를 계산하는 수식, KL Divergence
KL Divergence는 아래처럼 생긴 수식으로 표현됩니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/08f7c016-f43c-4a7d-bd03-e8017c6ddc24/image.png)
 
이건 곰돌이 젤리처럼 개수를 셀 수 있는 것들, 즉 이산형(discrete) 확률 분포 간의 KL Divergence입니다. 그럼 이제 하나씩 차근차근 풀어볼게요. 앞서 이야기했던 개념을 조금 더 일반화해서 살펴보겠습니다.
 
* **P(x)**: 실제 젤리 봉지 안에 있는 각 맛의 비율 (진짜 모집단의 분포)
* **Q(x)**: 우리가 예측한 각 젤리 맛의 비율 (모델의 추측)
 

이 수식은 각 맛(x)에 대해, 실제(P)가 예측(Q)과 얼마나 다른지를 로그 비율로 측정하고, 그 차이에 해당 사건의 중요도인 P(x)를 곱해 전부 더한 값입니다.
 
예를 들어, 빨강 라즈베리 젤리의 경우 실제 비율이 40%인데 20%라고 예측했으므로,
 
P=0.4, Q=0.2 ⇒ log(0.4/0.2) = log 2 = +0.693
 
꽤 큰 차이가 있다는 뜻이죠.
 
반면, 흰색 젤리는 P=0.2, Q=0.2라면 log 1 = 0이므로 예측이 정확했다는 뜻이에요.
 
# 그런데 왜 어렵게 log를 쓸까요?
우리는 단순한 차이를 보는 것이 아니라, 두 확률이 몇 배 차이 나는지를 보고 싶습니다. 그래서 비율을 보는 것이고, 이때 log를 쓰면 비교가 훨씬 쉬워집니다.
 
예를 들어, 만약 P(x)/Q(x) = 2라면, 실제는 예측보다 2배 많다는 뜻으로 log 2 = +0.693입니다. 반대로 P(x)/Q(x) = 0.5라면, 실제는 예측보다 절반이라는 뜻으로 log 0.5 = -0.693이죠.
 
이처럼 log를 사용하면, 예측이 부족할 때도, 지나칠 때도 0을 기준으로 대칭적인 수치가 나오기 때문에 비교에 유리합니다. 그리고 P(x) = Q(x)일 경우 log 1 = 0이기 때문에, 예측이 정확하면 손실도 0으로 표기할 수 있습니다.
 
# 왜 분자에 P(x), 분모에 Q(x)일까?
우리는 "진짜 세계를 기준으로 예측이 얼마나 다른가"를 알고 싶기 때문에, 기준은 항상 실제 확률 분포 P(x)입니다. 그래서 수식에서 Q(x)/P(x)가 아니라 P(x)/Q(x)라는 점이 중요합니다. 기준에서 얼마나 어긋났는지를 정보량 관점에서 보는 함수이기 때문입니다. 정보량은 -log p(x)로 계산하는데, 사건이 드물수록 그것이 발생했을 때 더 많은 정보를 준다고 생각하는 원리입니다. 즉, 흔한 일은 예측하기 쉬우니까 정보가 적고, 드문 일이 발생하면 "헉, 그런 일이!" 하게 되며 정보량이 크다고 보는 것이죠.
 
예를 들어, 실제로 딸기맛이 40%인데 나는 20%라고 예측했다면, P(x)/Q(x) = 0.4/0.2 = 2, 예측이 부족했기 때문에 log 2 > 0 벌점이 나옵니다.
 
반대로 예측 Q가 실제 P보다 더 크면 log 값이 음수이고, 예측이 과장되었기 때문에 역시 벌점이 생기는 것이죠.
 
# 왜 앞에 P(x)를 곱할까요?
여기가 KL Divergence의 핵심 중 하나입니다. 실제로 중요한 맛, 즉 많이 나오는 젤리 맛이 더 중요하니까, 그 차이를 더 크게 반영하겠다는 의미입니다.
 
라즈베리 젤리(P=0.4)의 예측이 틀리면 → 점수에 미치는 영향이 크고,
레몬맛 젤리(P=0.1)는 예측이 틀려도 → 점수에 미치는 영향이 작습니다.
 
즉, 중요한 사건일수록 더 중요한 차이로 계산되도록 하는 가중치 역할을 하는 거죠. 이해되셨나요? 이제 복잡해 보였던 수식이 조금씩 이해가 되시죠?
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/061b5fc0-a377-47fd-9a10-b44c0b0fffe5/image.png)
 
# 그럼 연속형 확률분포에서는 어떻게 될까?
젤리처럼 하나하나 셀 수 있는(discrete) 경우가 아니라, 수치가 아주 촘촘하게 이어지는 경우가 있습니다. 예를 들어 "키가 170cm 일 확률", "171.1cm 일 확률"처럼 무한히 나뉘는 상황에서는 더 이상 하나하나 더할 수 없죠. 이럴 땐 **합(Σ)** 대신 적분(∫)을 사용해 KL Divergence를 계산합니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/12b24d03-d6f9-45db-9fc7-32de78c09871/image.png)
 
예를 들어, AI가 사람의 목소리 주파수를 모델링 한다고 할 때
 
실제 어떤 사람의 목소리는 평균 180Hz, 표준편차 20Hz인 분포를 가진다면 이것이 P(x)이고, AI가 이것을 흉내 내기 위해서 평균 200Hz, 표준편차 30Hz로 예측해서 멀티모달 음성 AI가 목소리를 생성했습니다. → 이게 바로 Q(x)죠.
 
이제, 두 분포가 얼마나 다른지를 KL Divergence로 계산하면,
→ AI가 실제 사람의 목소리를 얼마나 잘 따라 했는지를 수치로 알 수 있습니다.
 
# 엔트로피(Entropy)란 뭘까?
KL Divergence를 이해하기 위해선 **엔트로피(Entropy)** 개념도 함께 봐야 해요. 엔트로피는 이렇게 생긴 수식입니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/dbf924f1-22da-4785-a678-300533563952/image.png)
 
이건 "진짜 세상(P)"이 얼마나 **불확실한지, 예측하기 어려운지**를 나타냅니다. 예를 들어, 곰돌이 젤리 봉지에 들어있는 다섯 가지 맛 중에서 하나를 눈을 감고 먹어보는 거예요. 그리고 예측해 봐요. 만일 다섯 가지 맛이 20%씩 균등하게 들어 있다면 맛을 예측하기 어려워요. 이때는 엔트로피가 큽니다.
 
반대로, 90%가 빨간색 라즈베리 맛이고, 나머지는 아주 조금씩만 있다면? 빨강일 가능성이 높아서 예측이 쉽죠. 이 경우, 엔트로피가 낮습니다.
 
# Cross Entropy는 무엇인가요?
Cross Entropy는 예측(Q)이 진짜(P)를 얼마나 잘 설명했는지를 계산하는 함수로, 이렇게 생겼습니다.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/03aec535-8c69-4eaf-a545-686144483152/image.png)
 
이건 KL과 수식이 아주 비슷하죠. 실제로 관계도 있습니다. 즉, KL Divergence는 크로스 엔트로피에서 엔트로피를 뺀 값이에요. Cross Entropy는 예측이 얼마나 틀렸는지를, KL은 "틀림의 정도에서 원래 분포 자체의 복잡성은 제외하고" 비교만 본다는 뜻이에요.
 
![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/950e0973-35e1-4d65-bcd9-6c2eb173dbd3/image.png)
 
# 인공지능은 이걸 어떻게 쓰나고요?
이미지 생성 모델인 VAE(Variational Autoencoder)는 "생성된 이미지의 특징 분포"가 "기준 정규 분포"와 얼마나 다른지를 KL Divergence로 비교합니다. 이 모델은 입력 데이터를 압축하여 잠재 공간에 표현하고, 이를 다시 복원하는 과정을 통해 학습합니다. 이때, 잠재 공간의 분포가 사전에 정의된 분포(일반적으로 표준 정규분포)와 유사하도록 유도하기 위해 KL Divergence가 사용됩니다. 좀 더 이해가 필요하신 분은 다음 논문 링크에서 추가로 학습해 보시면 좋습니다.
🔗 [Deriving the Standard Variational Autoencoder (VAE) Loss Function](https://arxiv.org/abs/1907.08956)
 
KL Divergence는 대규모 언어 모델(LLM)의 파인튜닝 과정에서 모델의 안정성과 성능을 유지하는 데 핵심적인 역할을 합니다. 특히, 원래의 사전학습된 모델(GPT 등)과 새로운 파인튜닝된 모델 간의 예측 분포 차이를 측정하여, 모델이 급격하게 변하지 않도록 조절합니다. 이러한 방식은 정책을 보전하거나, 훈련 안전성을 향상시키는 동시에 출력 다양성을 확보하는데 활용됩니다.
🔗 [Preserving Diversity in Supervised Fine-Tuning of Large Language Models](https://openreview.net/forum?id=NQEe7B7bSw)
 
큰 모델의 지식을 작은 모델이 배우는 과정(지식 증류)에서도 KL Divergence는 중요한 역할을 합니다. Knowledge Distillation은 큰 모델(Teacher)의 지식을 작은 모델(Student)로 전달하는 기술입니다. 이 과정에서 KL Divergence는 두 모델의 출력 확률 분포 간의 차이를 측정하는 데 사용됩니다.
🔗 [Comparing Kullback-Leibler Divergence and Mean Squared Error Loss in Knowledge Distillation](https://arxiv.org/abs/2105.08919)
 
# 마무리하며
우리가 곰돌이 젤리 봉지를 열며 예상과 실제를 비교하듯, 인공지능도 자신이 생각한 확률 분포와 실제 데이터를 비교합니다. 그 방식이 바로 KL Divergence입니다. 그 수식 하나로, AI는 얼마나 많이 틀렸는지, 어느 부분에서 크게 틀렸는지, 얼마나 자신 있게 말해야 할지를 배워갑니다. 이렇게 KL Divergence는 인공지능이 더 똑똑해지기 위해 스스로 피드백을 받고 공부하는 손실함수의 핵심 메커니즘이죠.
 
다음에 곰돌이 젤리를 먹게 된다면, 눈을 감고 한 봉지에 어떤 맛이 몇 개 들어 있는지 맞춰보세요. 그리고 눈을 뜬 후, KL Divergence 값을 계산해보는 건 어떨까요?
 
 
![정경문 작가님 프로필 카드.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/e1d5786f-3e50-42e2-bb5e-dd0755a2a136/%E1%84%8C%E1%85%A5%E1%86%BC%E1%84%80%E1%85%A7%E1%86%BC%E1%84%86%E1%85%AE%E1%86%AB%20%E1%84%8C%E1%85%A1%E1%86%A8%E1%84%80%E1%85%A1%E1%84%82%E1%85%B5%E1%86%B7%20%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%84%91%E1%85%B5%E1%86%AF%20%E1%84%8F%E1%85%A1%E1%84%83%E1%85%B3.png)
 
 
[![da-coding-test2(729x90).jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/97d28ee0-8b99-488a-8733-c12d69e8acf4/da-coding-test2%28729x90%29.jpg)](https://school.programmers.co.kr/learn/courses/25254?utm_source=prgm&utm_medium=social&utm_campaign=school_25254_sales&utm_content=25254_poster)

곰돌이 젤리로 알아보는 인공지능 수학 KL Divergence

국민내일배움카드는 취업, 이직, 역량 강화를 위해 정부가 훈련비를 지원해 주는 핵심 제도입니다. 
가장 궁금한 국민내일배움카드 발급 조건, 신청 방법만 쏙 뽑아 정리해 드릴게요!
 
 
## 누가 받을 수 있나요?
**원칙적으로는 대한민국 국민 누구나 신청 가능합니다!**
 
- 실업자, 재직자, 대학생(일부), 자영업자, 특수형태근로종사자 등 신분과 관계없이 가능합니다.
- 카드의 유효기간은 **5년**이며, 이 기간 동안 훈련 지원금으로 **1천만 원 상당** 강의도 수강 가능합니다.
- 대부분의 국민이 신청 가능하지만, 아래 **제외 대상에 속한다면** 아쉽게도 카드를 발급받을 수 없습니다.
 
 * 발급 제외 대상자
 - 졸업까지 남은 수업 연한이 2년을 초과하는 대학/대학원 재학생
 - 사업 기간이 1년 미만이거나, 연 매출이 4억 원 이상인 자영업자
 - 대규모 기업에 고용된 만 45세 미만 근로자 중 월 평균 임금이 300만원 이상인 사람
 - 특수형태근로종사자 중 월 평균 소득이 300만원 이상인 사람
 - 현직 공무원 및 사립학교 교직원
 - 만 75세 이상인 사람
 - 국민기초생활보장법에 따른 생계급여 수급자 (단, 조건부 수급자 또는 조건부과 유예자는 지원 가능)
 - 다른 정부 부처 또는 지방자치단체로부터 교육/훈련비를 지원받고 있는 사람
 
## 국민내일배움카드 신청하기
국민내일배움카드는 고용24 온라인 신청 > 카드 발급 신청 > 실물 카드 수령으로 진행됩니다.
 
### **1. 고용24 회원가입 및 신청 페이지 이동**

발급 신청은 온라인 또는 고용센터 방문을 통해 할 수 있지만, **온라인 신청(고용24)** 이 가장 간편합니다. 
 
- 고용24(링크)에서 회원가입 및 로그인 진행
 
![내배카 로그인.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/93dfbd76-26f1-4f7e-bab5-4dfc872943f6/%E1%84%82%E1%85%A2%E1%84%87%E1%85%A2%E1%84%8F%E1%85%A1%20%E1%84%85%E1%85%A9%E1%84%80%E1%85%B3%E1%84%8B%E1%85%B5%E1%86%AB.png)
 
- 고용24 메인 화면 > [훈련 역량 강화] 클릭 > [국민내일배움카드] 클릭
 
![image (23).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/9d225f49-2348-4a04-aa73-29631b4dc7d4/image%20%2823%29.png)
 
### 2. 국민내일배움카드 발급 신청

- 국민내일배움카드 발급 설문 작성: 신청자격 확인 > 권리 및 의무사항 > 발급신청서 작성 > 동의 및 신청 > 발급신청 완료
 
![image (24).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/068ad17a-caba-44c0-a99d-3efbbd362778/image%20%2824%29.png)
 
- ⚠️ 국민내일배움카드 발급 신청서 작성 시
 - 신한카드, 우편(모바일 신청)으로 선택 추천: 신청 후 평균 3일 내 발급 승인 여부가 안내됩니다.
 - 모바일로 신청할 경우, 수강 신청은 가능하지만 개강일 전까지 실물 카드를 발급해 주세요.
 
![image (25).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/62df9984-bb7d-48ac-a79a-cdeeb8431ec6/image%20%2825%29.png)
 
 * NH농협카드의 신용카드를 신청하시는 경우, 우편(모바일 신청) 또는 은행방문 선택 가능

 
#### 카드 발급 TIP
 
 카드 발급을 위해 금융기관(카드사)에서 카카오톡 또는 문자로 홈페이지 연결 주소(URL)가 발송됩니다. (신한: 1544-7000, 농협: 1644 - 4000)
 
### **3. 모바일 카드 발급 및 수령**

#### 신한 은행 발급 기준

- 신한은행 카드사 앱(신한 SOL Pay) 설치
- 앱 메인 화면 우측 상단 돋보기 버튼 클릭 > “내일배움카드” 입력
- 3가지 카드 중 원하는 카드 선택
 
![image (26).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/e1f336bb-1605-46d1-9b16-715db3cfb1e1/image%20%2826%29.png)
 
- [온라인 신청] 버튼 클릭 > 훈련 대상자 확정 내용 확인 및 [예] 버튼 클릭
 
![image (27).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/ca421cca-dbc8-48f8-b46b-1ee01fad2004/image%20%2827%29.png)
 
- 카드 선택 옵션 확인 후, 다음 버튼 클릭 > 인적 사항 순차 입력 
 
![image (28).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/81be925c-6592-4120-8121-14fde63ca282/image%20%2828%29.png)
 
- 카드 발급 완료 후, 상단의 카드 탭 카드사용등록 클릭 > 카드 정보 기입
 
![image (29).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/f0840d4c-7831-4258-9367-ea2744cefecb/image%20%2829%29.png)

 
<div style="border-radius: 4px;padding:22px 20px; background: #F5F5F5; border: 1px solid #D6D6D6;">국민내일배움카드 발급 등록 후, 실제 훈련 결제에 사용 가능하기까지 약 1일(24시간)의 시간이 소요될 수 있습니다. 

 

## 고용24에서 프로그래머스 데브코스 과정 수강 신청 프로세스는?
과정 수강 신청은 랜딩페이지 내 지원 > 유선 인터뷰 > 최종 선발 > 고용 24 수강신청 순서로 진행되는데요. 최종 선발 후, 고용 24에서 어떻게 신청하는지 아래에서 단계별로 하나씩 확인해 볼게요!
 
- 고용24의 상단 카테고리 중 직업 능력 개발 선택 > 훈련 찾기·신청 > 국민내일배움카드 훈련 과정 클릭
 
![스크린샷 2025-11-18 오전 11.47.46 1.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/baab9833-3be3-4592-8713-49806c8387e7/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202025-11-18%20%E1%84%8B%E1%85%A9%E1%84%8C%E1%85%A5%E1%86%AB%2011.47.46%201.png)
 
- **국민내일배움카드 훈련과정 > 검색어 및 훈련 기관명에 희망 과정 및 운영 기관 입력**
 
![스크린샷 2025-11-19 오후 2.51.43 1.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/fde7a758-3a51-4dea-9639-9103d88d87e7/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202025-11-19%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%202.51.43%201.png)
 
👨🏻‍💻 **희망 과정 및 운영 기관 수강신청 방법**
 - 검색어 > **생성형 AI 백엔드,** 훈련 기관명 > **그렙 입력 후, [검색] 버튼 클릭**
 - **과정 기간(회차 포함) 확인 후**, 우측 수강신청 버튼 클릭 > 희망 과정 페이지 내 우측 수강신청 버튼 클릭
 
![image (31).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/b6da7065-ec25-43b7-8403-6629712aeb33/image%20%2831%29.png)
 
 

국민내일배움카드 발급은 복잡하게 느껴지지만, 생각보다 어렵지 않습니다!
지금 바로 온라인으로 간편하게 신청하고, 수강료 0원으로 역량을 키우는 첫걸음을 내딛어 보세요.
(*26년부터 자부담금 발생)
 
프로그래머스 데브코스는 여러분의 목표 달성을 위해 끝까지 함께하겠습니다.
국민내일배움카드 발급 과정이나 수강 신청에 대한 문의사항이 있다면 언제든 [채널톡](https://pf.kakao.com/_pxcLLxb)으로 문의 남겨주세요!
 
 
▼ 데브코스 과정을 자세히 알고 싶다면 아래 배너 클릭 ▼ 
 
[![image (32).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/43792cde-ebc7-4eb3-ba13-2a3e054a33e4/image%20%2832%29.png)](https://school.programmers.co.kr/learn/courses/25487?utm_source=prgmblog&utm_medium=social&utm_campaign=school_blog_12904&utm_content=25487_AIBE)
[![image (33).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/52a13127-559c-4e43-bc9d-cd4123d4eecb/image%20%2833%29.png)](https://school.programmers.co.kr/learn/courses/25485?utm_source=prgmblog&utm_medium=social&utm_campaign=school_blog_12904&utm_content=25485_DA)
[![image (34).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/aa44d25a-4fb9-4173-8447-1fd4ef4459e6/image%20%2834%29.png)](https://school.programmers.co.kr/learn/courses/25486?utm_source=prgmblog&utm_medium=social&utm_campaign=school_blog_12904&utm_content=25486_FS)
[![DEV-BE-DEEP--blog-banner(1456x180) (7) (1).jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/7e5a791d-ad10-491c-b2a5-0b1289b7fe7c/DEV-BE-DEEP--blog-banner%281456x180%29%20%287%29%20%281%29.jpg)](https://school.programmers.co.kr/learn/courses/25553?utm_source=prgmblog&utm_medium=social&utm_campaign=school_blog_12904&utm_content=25553_ADBE)

수강료 0원! 국민내일배움카드, 나도 받을 수 있을까?

네카라쿠배 포함, 성장하는 스타트업으로의 합류를 꿈꾸는 개발자를 위한 꿀팁 2탄! 이력서·포트폴리오 준비편에 이어, 이번 포스팅에서는 현직 개발자들이 말하는 '코딩 테스트 준비 꿀팁'과 '면접 준비 꿀팁'을 준비했습니다. 면접을 앞둔 분들이라면 특히 도움을 받을 수 있는 이야기들을 담았으니, 꼼꼼하게 살펴봐주세요! 😉
 
 
# 🍯 코딩 테스트 준비 TIP
> 합격한 분들의 공통점은 코딩 테스트 문제를 많이, 여러번 풀며 공부했다는 것이었어요. 코딩 테스트를 앞두고 있다면, [프로그래머스](https://school.programmers.co.kr/learn/challenges?order=acceptance_desc)처럼 많은 문제를 연습할 수 있는 사이트를 활용해 보세요!

 
### 💬 "자투리 시간을 활용해 코딩테스트를 준비했어요."
이직을 준비할 때, 점심시간이나 퇴근 후, 주말 등의 시간을 활용해 자기소개서를 작성하고 코딩 테스트를 준비했어요. **코딩 테스트 준비는 백준과 프로그래머스를 이용**했고요. 기업 채용 소식은 자소설닷컴, 원티드, 로켓펀치 등에서 매일 확인했어요. 같은 관심사를 가지고 있는 사람들이 모인 오픈 카톡방에서 모르는 것을 질문하거나, 공모전 팀원을 구하기도 했어요.
 
-박민서, 라인플러스 데이터엔지니어
 
### 💬 "매일 습관처럼 책상에 앉아 개발 공부를 했어요."
코딩 테스트는 특히 꾸준히 해야만 실력이 느는 분야인 것 같아요. 디자인 전공생이었던 저는 다른 취준생들과 비교해 사고력이 약하다는 것을 스스로 많이 느끼고 있었고, 최대한 많은 문제를 풀어보면서 이를 극복하고자 했어요. 풀이한 문제들의 수가 쌓이면서 어느 시점부터 코딩 테스트에서 풀었던 문제들과 비슷한 유형의 문제들을 만나기 시작했고, 그때부터 저만의 공부 방법을 찾은 느낌이었어요.
 
좋은 결과를 기대하지 않더라도 막상 코딩 테스트에서 떨어지면 멘탈이 많이 흔들렸어요. 이건 취업 준비를 해보신 모든 분들이 경험해 보셨을 거라 생각해요. 저는 취업 준비를 하며 **GitHub에 1일 1커밋을 실천**했었는데, 그게 당시에 흔들리는 멘탈을 많이 잡아줬던 것 같아요. 매일매일 습관처럼 개발을 하다 보니 불합격 통지를 받아도 멘탈의 흔들림과 관계없이 습관처럼 책상에 앉게 되더라고요. 그때는 사소한 습관이라 생각했었는데, 지금 생각해 보면 그 작은 학습량들이 모여서 큰 변화를 만들어냈던 것 같아요.
 
-신윤재, 카카오엔터프라이즈 서버 개발자
 
### 💬 "문제를 많이 풀어보고, 실제로 알고리즘 구현도 해보며 익혔어요."
저는 코딩 테스트 준비를 위한 서적은 따로 구입하진 않았어요. 문제 유형별로 필요한 알고리즘이 다르고, 알고리즘을 미리 공부했어도 실제 테스트에서는 생각이 잘 안 나거나 알고 있던 내용도 어려울 수 있잖아요. 그래서 **최대한 문제를 많이 풀어보고, 문제에 필요한 알고리즘을 찾고, 실제로 알고리즘을 구현**해보기도 하면서 눈에 익히려고 노력했어요.
 
코딩 테스트를 준비할 때 프로그래머스와 백준 사이트를 많이 활용했어요. **프로그래머스에서 문제를 풀어보고, 문제를 다 풀면 백준에서 찾아보는 식으로 공부**했습니다. 특히 프로그래머스와 백준에서 진행하는 대회나 챌린지에 여러 번 참여했는데요. 실제 코딩 테스트 환경을 느낄 수 있어서 많은 도움이 되었습니다.
 
-김찬우, 쿠팡 소프트웨어 개발 엔지니어
 
### 💬 "세 달 정도 매일 하루에 두세 문제씩 꾸준히 풀며 연습했어요."
제가 느낀 코딩 테스트 난이도는 중상 정도였어요. 처음 코딩 테스트를 준비할 때는 **유튜브를 참고해 알고리즘 공부**를 시작했고, **백준과 프로그래머스에서 하루에 두세 문제씩** 약 세 달간 꾸준히 풀며 실력을 쌓았습니다. 취업 직전에는 다른 사람들과 프로젝트 준비를 준비하느라 바빴기 때문에, 코딩 테스트를 미리 준비해두었던 것이 큰 도움이 되었어요.
 
유튜브에서는 동빈나님의 채널을 참고했어요. 주제별로 재생목록이 잘 정리되어 있어서, 필요한 내용을 체계적으로 공부하기에 좋았어요. 영상을 쭉 훑어보면서 개념을 익히고, 관련 문제를 풀어보면서 코딩 테스트에 대한 감각을 키울 수 있었습니다.
 
-이창엽, 넥슨코리아 웹 개발자
 
# 🍯 면접 준비 TIP
> 면접 준비는 채용 공고의 자격요건에 나온 기술 공부와 내가 했던 프로젝트 다시 살펴보기, 이 두 가지를 꼼꼼히 준비하는 것이 핵심!
> 면접을 앞두고 있다면 새로운 것을 급하게 공부하기보다는, 이전에 배웠던 내용이나 직접 경험한 프로젝트를 다시 정리해 보는 건 어떨까요?

 
### 💬 "내가 경험한 프로젝트와 알고 있는 내용을 명확히 말하는 준비가 중요했어요."
준비 과정의 8할은 **제가 진행했던 프로젝트를 명확히 설명할 수 있도록 정리하는 데 집중**했어요. 제가 진행한 프로젝트를 제대로 설명하지 못하면 전문성이 부족해 보일 수 있다고 생각했기 때문이에요.
 
**나머지 시간에는 기본적인 CS 지식을 준비**했습니다. 기술 면접 대비용으로 정리된 기출문제들이 깃허브나 블로그에 많이 공유되어 있어서, 그중에서도 제가 지원하는 포지션에 맞는 기술 스택 중심으로 공부했습니다.
 
라인 게임즈에서는 자격조건 및 우대사항에 Java, Spring, MySQL, AWS 등이 명시되어 있었기 때문에 해당 기술들 위주로 준비했어요. 완전히 새로운 개념을 외우려고 하기보다는, 제가 이미 경험했거나 알고 있는 내용을 잘 설명할 수 있는지를 중점적으로 점검했어요. 모르는 건 어쩔 수 없는 부분이지만, 알고 있는 것을 제대로 설명하지 못하면 학습의 깊이가 얕아 보일 수 있다고 생각했거든요. 
실제 면접에서 느낀 난이도는 생각보다 높지 않았어요. 기본적으로 알아야 할 HTTP 통신의 전체적인 흐름, Node.js를 사용한 이력을 언급하시면서 그 내부가 어떻게 실행되는지에 대한 질문을 받았어요. 단순히 언어를 사용해 봤는지 보다, 해당 기술을 잘 이해하고 있는지를 확인하려는 질문들이었어요.
 
무엇보다 좋았던 점은 면접을 통해 지원한 포지션의 실제 업무 내용을 구체적으로 들을 수 있었다는 거예요. 면접을 마치고 나서는 '이 회사에서 정말 많이 배울 수 있겠다'는 확신이 들었습니다.
 
-박경선, 라인게임즈 백엔드 개발자
 
### 💬 "평소에 '왜?'라는 질문을 자주 던지며 개발해왔다면, 기술 면접은 어렵지 않아요."
서류 접수 전에 먼저 코딩 테스트를 진행했는데, 따로 코딩 테스트를 준비하지는 않았어요. 대신 면접 준비에 집중했습니다.
 
면접 난이도는 중상 정도였고, 기술 면접 중심이었어요. 평소에 '왜 이렇게 구현했는가?', '왜 이런 선택을 했는가?'처럼 **스스로에게 질문을 많이 던지는 개발자라면 어렵지 않게 답할 수 있을 것 같아요**.
 
기억에 남는 질문은, 제가 진행했던 프로젝트에서 겪은 어려움과 이를 해결한 과정에 대해 묻는 질문이었어요. 보통은 지원자가 기억에 남는 프로젝트 중에서 선택해서 대답하는데, 이 면접에서는 특정 프로젝트를 면접관이 콕 집어서 질문을 주셔서 인상 깊었어요. 해당 프로젝트를 충분히 이해하고 면접을 준비했기에 잘 대답할 수 있었던 것 같아요.
 
-김하림, 우아한형제들 웹프론트엔드
 
### 💬 "면접 볼 회사에서 어떤 언어를 사용하고 있는지 미리 파악하는 것을 추천드려요."
쿠팡에서 주로 쓰는 언어 스택이 자바인데요. 자바를 한 번도 안 해본 상태에서 면접을 들어가게 되었어요. 그래서 기술 스택보다 제가 가지고 있는 코딩 역량을 더 어필했었는데, 이 부분이 좀 아쉬웠어요. **면접을 보기 전에 회사에서 어떤 언어를 사용하고 있는지 미리 알고 가는 것이 좋을 것 같다는 생각**을 했습니다.
 
결과적으로 저는 면접 당시에 Python을 사용했지만 통과할 수 있었고, 입사 후 회사 내부 교육 과정을 통해 Java를 학습했습니다.
 
-김찬우, 쿠팡 소프트웨어 개발 엔지니어
 
### 💬 "면접 준비에 필요한 것들을 리스트업하고, 꾸준히 실행했어요."
우선 **알고리즘 공부와 손코딩**을 했어요. 알고리즘은 프로그래머스나 백준 문제를 풀어보며 준비했어요. 그다음으로는 **프론트엔드와 CS 지식을 공부**했어요. 프론트엔드는 JavaScript 중심으로 웹의 전반적인 내용들을 공부했습니다. 구글에 '프론트엔드 면접 질문'이라고 검색하면 좋은 자료들이 많이 나오더라고요.
 
한편 CS 지식은 범위가 넓어서 많은 부분을 꼼꼼하게 준비하기 어려워요. 그렇기 때문에 많이 나올 만한 주제 위주로 정리하여 공부했고, 이 과정에서 재엽 님의 깃허브 자료를 많이 참고했습니다.
 
마지막으로는 **제가 했던 프로젝트들을 다시 한번 정리**했어요. 저에게는 너무나도 익숙한 프로젝트였지만 다른 사람에게 설명할 때 좀 더 효과적으로 설명할 수 있도록 준비했어요. 프로젝트에서 사용한 구조나 왜, 어떻게 그 기술 스택을 사용했는지 프로젝트에 대한 기술적 질문에 대비했어요.
 
면접을 준비하며 어려웠던 점은 생각보다 준비해야 할 것이 많았다는 점이에요. 위의 내용들을 제대로 준비하려면 꽤 오랜 시간이 걸리고, 중간에 지치기도 합니다. **준비할 것들을 리스트업하고, 오늘 해야 할 일을 묵묵히 해나가는 것**이 최선이라 생각합니다.
 
-앤드류, 카카오엔터프라이즈 프론트엔드
 
### 💬 "스스로 생각하는 과정이 필요한 질문들에 대한 답을 미리 준비해보세요."
우선 1차 면접은 실무진들과 온라인으로 진행됐어요. 면접관은 열 분 정도였고, **기술적인 부분 위주로 질문**해 주셨어요. 2차 면접은 1차 보다 높은 직급의 분들과 1대 1 면접을 보았습니다. 2차 면접도 기술적인 질문이 대부분이었어요. 1차 면접에서는 이 문제에 대해 잘 대답하지 못했는데 알고 있는지, 이에 대해 다시 대답해 줄 수 있는지 물어보기도 했고요. 전체적인 분위기는 1차와 2차가 비슷했던 것 같아요.
 
저의 **이력서를 보시면서 이 프로젝트에서는 왜 이런 기술을 썼는지에 대한 질문**을 많이 주셨어요. CS에 대한 질문도 있었고요. 면접을 본지 오래되어서 자세한 질문 내용은 기억이 잘 안나지만, 대부분 스스로 생각하는 과정이 필요한 질문들이었습니다.
 
-이창엽, 넥슨코리아 웹 개발자
 
### 💬 "기본적인 알고리즘 풀이법과 소통하는 방법이 핵심!"
1차 기술 인터뷰는 두 가지 세션으로 구성되어 있었는데, 1차는 라이브 코딩 진행이었어요. 면접관이 들어오셔서 지원자와 함께 라이브 코딩을 진행하는 형식인데요. **문제가 주어지면 이 문제를 어떻게 해결할지 면접관께 설명을 드린 후에 코딩을 하는 방식**이에요. 이 과정에서 다른 회사와 다르다고 느낀 것은 커뮤니케이션을 적극적으로 한다는 것이었어요. 지원자가 문제를 푸는 중에 잘못된 부분이 있으면 면접관께서 직접 이야기해 주시고, 해당 코드는 어떤 의미인지 소통하며 진행해 주셔서 어렵지 않게 풀어나갈 수 있었어요.
 
다음으로 아키텍처 인터뷰를 진행하게 되는데요. 기능을 만들 때 어떻게 효율적으로 설계할 것인지, 트래픽을 어떻게 처리할 것인지를 주로 물어보셨어요. **기본적인 알고리즘을 어떻게 풀어낼 것인지, 어떻게 소통하는지가 핵심**이었던 것 같아요. 면접을 위해 따로 특별히 준비한 것은 없고요. 알고리즘 문제를 해결하는 실력을 기르려고 노력했고, 라이브 코딩은 센드버드에서 사용하고 있는 툴에 대해 익숙해지려고 노력했어요.
 
-이길원, 센드버스 소프트웨어 엔지니어
 
 
현직자들의 코딩 테스트와 면접 준비 꿀팁, 모두 확인하셨나요? 개인마다 준비한 방법은 조금씩 다르지만 '꾸준함'이라는 공통점을 가지고 있는 것 같아요. 이번 글도 네카라쿠배를 준비하는 분들께 유용한 글이 되었기를 바라며, 다음에는 또 다른 커리어 콘텐츠로 돌아오겠습니다!
 
*※본 글은 2023년 1월에 최초 작성된 콘텐츠입니다.*
 
 
### 📌 함께 읽으면 좋은 글
* [네카라쿠배를 꿈꾸는 개발자를 위한 꿀팁: 이력서·포트폴리오 준비편](https://community.programmers.co.kr/post/11947)
 
 

[![AI BE_배너.jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/f2ef708f-59d8-4e51-a27e-49b0b60d77fe/AI%20BE_%E1%84%87%E1%85%A2%E1%84%82%E1%85%A5.jpg)](https://school.programmers.co.kr/learn/courses/25186?utm_source=prgmblog&utm_medium=social&utm_campaign=school_25186_blog&utm_content=25186_banner)

네카라쿠배를 꿈꾸는 개발자를 위한 꿀팁: 코딩테스트·면접 준비편

지난 7월 5일 토요일, **제5회 데브코스 커리어 TALK**(이하 데커TALK) 오프라인 세미나가 개최되었습니다. 이번 행사는 프로그래머스 강남 강의장에서 오프라인과 온라인 동시 진행되었으며, 무더운 날씨에도 많은 개발자 지망생 분들이 현장을 찾아주셨습니다.
 
이번 세미나의 주제는 바로 "**취업을 앞당기는 실전 전략과 커리어 인사이트**"였는데요. 실제 현업에서 활동 중인 개발자들이 전하는 생생한 이야기와 취업 전략을 들을 수 있었던 의미 있는 시간이었습니다.
 
![데커톡 (12).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/adcc699d-f1a9-430e-a6e4-15083f21fa46/%E1%84%83%E1%85%A6%E1%84%8F%E1%85%A5%E1%84%90%E1%85%A9%E1%86%A8%20%2812%29.png)
 
![데커톡 (7).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/2a0b418a-a5b6-41f2-876e-370fb5e447ba/%E1%84%83%E1%85%A6%E1%84%8F%E1%85%A5%E1%84%90%E1%85%A9%E1%86%A8%20%287%29.png)
👆 데커TALK이 진행되었던 프로그래머스 강남 강의장
 
 
# 🎯 프로그래머스 데브코스 소개
행사의 문은 프로그래머스 교육팀의 데브코스 소개로 열렸습니다. 
단순한 교육이 아닌, **실무 중심의 커리큘럼과 현업 멘토링을 통해 빠르게 성장할 수 있는 구조를 갖춘 데브코스의 장점들을 소개**하며, 참가자들이 이후 강연을 더욱 몰입할 수 있도록 준비하는 시간을 가졌습니다.
 
![데커톡 (14).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/1a7102a7-c2fb-4f7a-8b8f-4eeb55b7c041/%E1%84%83%E1%85%A6%E1%84%8F%E1%85%A5%E1%84%90%E1%85%A9%E1%86%A8%20%2814%29.png)
 
![데커톡 (2).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/660f08f7-f705-4474-8593-5e2bce7ac9ab/%E1%84%83%E1%85%A6%E1%84%8F%E1%85%A5%E1%84%90%E1%85%A9%E1%86%A8%20%282%29.png)
 
# 🧑‍🏫 신입 개발자 생존 전략 - 강대명 개발자
첫 번째 강연은 전)레몬트리 CTO이자 **21년차 개발자인 강대명 강사님**의 강의로 진행되었습니다. 
"취업난 속에서도 살아남는 신입 개발자의 전략: 멘토링 현장에서 찾은 생존 팁"을 주제로, 수많은 멘토링 경험을 바탕으로 **신입 개발자가 갖춰야 할 생존력과 태도, 실질적인 전략**들을 전달해주셨습니다. 
강연 이후에는 Q&A 시간을 통해, 개발자 커리어를 준비 중인 분들의 다양한 질문에 열정적으로 답변해주셨습니다.
 
![데커톡 (8).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/305ef72f-b8cd-4ba7-8ce8-7bbf426509f5/%E1%84%83%E1%85%A6%E1%84%8F%E1%85%A5%E1%84%90%E1%85%A9%E1%86%A8%20%288%29.png)
 
![데커톡 (1).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/662ab2bd-d72a-431d-8512-77e54be7ed79/%E1%84%83%E1%85%A6%E1%84%8F%E1%85%A5%E1%84%90%E1%85%A9%E1%86%A8%20%281%29.png)
 
![20250705_145548.jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/77bdd968-9848-4480-9a17-b3a0bac96548/20250705_145548.jpg)
 
# 🧑‍🏫 데브코스 수료생의 실전 취업 여정 - 박민수 개발자
두 번째 강연은 **SOCAR의 프론트엔드 엔지니어 박민수 강사님**의 이야기였습니다.
데브코스 수료생이기도 한 박민수 강사님은 **데브코스에서 어떻게 현업까지 이어졌는지**, 그리고 실제 취업 준비 과정에서 마주했던 고민과 극복법에 대해 솔직하게 풀어주셨습니다.
 
![데커톡 (5).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/b57588f8-5b9b-4563-b87d-276d3423555c/%E1%84%83%E1%85%A6%E1%84%8F%E1%85%A5%E1%84%90%E1%85%A9%E1%86%A8%20%285%29.png)
 
![데커톡 (9).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/0e8153b1-fa8e-4137-87a9-b31186e8140a/%E1%84%83%E1%85%A6%E1%84%8F%E1%85%A5%E1%84%90%E1%85%A9%E1%86%A8%20%289%29.png)
 
![20250705_151437.jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/d9b68a73-3d6b-43b9-a45a-402ab66e4403/20250705_151437.jpg)
 
# 🧑‍🏫 현업 개발자가 말하는 '내가 함께 일하고 싶은 신입 개발자' - Jason 개발자
마지막 세션은 **N사 소속의 백엔드 엔지니어 Jason님**이 진행해주셨습니다.
"내가 함께 일하고 싶은 신입 개발자"라는 주제 아래, 현업 개발자의 시선에서 보는 **신입 개발자가 갖춰야 할 역량**, 그리고 **좋은 동료의 기준**을 공유해주셨습니다.
 
![데커톡 (15).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/1d7ccbb4-1d72-4eec-a23a-acc26b48fae6/%E1%84%83%E1%85%A6%E1%84%8F%E1%85%A5%E1%84%90%E1%85%A9%E1%86%A8%20%2815%29.png)
 
![데커톡.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/477661a3-4e69-4f5c-b9df-6598d34f3e13/%E1%84%83%E1%85%A6%E1%84%8F%E1%85%A5%E1%84%90%E1%85%A9%E1%86%A8.png)
 
# 🔗 커넥트 타임: 개발자 유형 빙고 & 경품 이벤트
제5회 데커TALK에는 **참석자들이 서로 소통할 수 있는 프로그램**도 마련되었습니다. 개발자 유형 검사 결과를 바탕으로 빙고 게임이 진행되었고, 그 과정에서 나와 잘 맞는 유형의 개발자들을 찾아보며 재밌는 시간을 보냈습니다. 또한 마지막에는 다양한 경품이 걸린 추첨 이벤트도 진행되어, 현장의 분위기가 한층 더 뜨거워졌습니다! 
 
![데커톡 (3).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/723564a5-5713-49fc-a965-d9c9bd36863e/%E1%84%83%E1%85%A6%E1%84%8F%E1%85%A5%E1%84%90%E1%85%A9%E1%86%A8%20%283%29.png)
 
![데커톡 (13).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/dd139fa3-3667-44da-954e-813e6212cd68/%E1%84%83%E1%85%A6%E1%84%8F%E1%85%A5%E1%84%90%E1%85%A9%E1%86%A8%20%2813%29.png)
 
![데커톡 (4).png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/cde60349-3adf-4d18-ae6e-69144faa2f62/%E1%84%83%E1%85%A6%E1%84%8F%E1%85%A5%E1%84%90%E1%85%A9%E1%86%A8%20%284%29.png)
 
# ⭐ 만족도 최상! 참가자들의 생생한 후기
이번 세미나는 하반기 취업을 준비하는 개발자 지망생분들께 특히 큰 호응을 얻었습니다. 강연 후 진행된 만족도 조사에서도 "**실제 커리어 로드맵을 그려보는 데 큰 도움이 되었다**", "**막연했던 취업 준비가 명확해졌다**"는 피드백이 이어졌습니다!
 
 
## 🔍 데커TALK 참여 후기 살펴보기
* **함께 일하고 싶은 신입 개발자가 되기 위해 무엇을 준비해야하는지** 알 수 있었던 시간이었습니다.
* 전반적으로 유익한 행사였습니다. **개발자를 준비하는 모든 사람들에게 도움이 되는 내용**들로 구성되어 좋았습니다.
* 각 섹션마다 **실무자의 생생한 경험과 현실적인 조언**이 가득했고, 다양한 관점에서 신입 개발자들에게 요구되는 역량을 들을 수 있어 스스로를 점검해보는 시간이었어요
* **현직자와 직접 Q&A를 나눌 수 있는 점, 오프라인 참가자 간 네트워킹 기회**가 마련되어 있다는 점이 인상 깊었어요. 단순한 정보 전달에 그치지 않고 쌍방향 소통이 가능했던, 그리고 동료를 만날 수 있었던 의미 있는 행사였어요.

 
## 📌 데커TALK 참가자들의 생생한 블로그 후기
각 이미지를 클릭하여 후기를 자세히 읽어보세요!
 
[![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/79d67005-21bf-4613-bad3-01039593dc74/image.png)](https://hseongchan2.tistory.com/199)
👉 [후기 자세히 보기](https://hseongchan2.tistory.com/199)
 
[![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/b3f83770-c715-465e-ba31-d32a6b040119/image.png)](https://blog.naver.com/cho990924/223923597942)
👉 [후기 자세히 보기](https://blog.naver.com/cho990924/223923597942)
 
[![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/6a416d1d-03db-4253-8cd4-40459032fcbb/image.png)](https://sulsikanit.tistory.com/m/26)
👉 [후기 자세히 보기](https://sulsikanit.tistory.com/m/26)
 
[![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/1176cac5-071b-469e-9c30-0acee006e894/image.png)](https://guidey.tistory.com/78)
👉 [후기 자세히 보기](https://guidey.tistory.com/78)
 
[![image.png](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/fde3551b-e946-4ea0-9544-8f828bd9ae7b/image.png)](https://velog.io/@se_kite/%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%A8%B8%EC%8A%A4-%EB%8D%B0%EB%B8%8C%EC%BD%94%EC%8A%A4-%EC%BB%A4%EB%A6%AC%EC%96%B4-TALK-%EC%B0%B8%EC%97%AC-%ED%9B%84%EA%B8%B0)
👉 [후기 자세히 보기](https://velog.io/@se_kite/%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%A8%B8%EC%8A%A4-%EB%8D%B0%EB%B8%8C%EC%BD%94%EC%8A%A4-%EC%BB%A4%EB%A6%AC%EC%96%B4-TALK-%EC%B0%B8%EC%97%AC-%ED%9B%84%EA%B8%B0)
 
# 앞으로도 계속될 데커TALK, 기대해주세요!
프로그래머스 교육팀은 앞으로도 개발자의 성장을 돕는 데커TALK을 꾸준히 이어나갈 예정입니다. **실제 현업에서 바로 통하는 인사이트와 취업 전략을 직접 만나볼 수 있는 기회**! 다음 데커TALK에도 많은 관심과 참여 부탁드립니다.
 
 
### 🎬 제5회 프로그래머스 데브코스 TALK 다시보기
 
<div style="position: relative; max-width: 100%; padding-bottom: 56.25%; height: 0;"><iframe width="560" height="315" src="https://www.youtube.com/embed/_AHj_oZUpmE?si=JCAYPxrYeyzOZFS4" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen="" style="position: absolute; position: absolute; top: 0; left: 0; width: 100%; height: 100%;"></iframe></div>

 
 
[![DCT5-coding-test2(729x90)B.jpg](https://grepp-programmers.s3.ap-northeast-2.amazonaws.com/production/presigned_urls_with_path/blog_images/2b0b5ddb-3b81-4652-8bda-55f833d02d6b/DCT5-coding-test2%28729x90%29B.jpg)](https://youtu.be/_AHj_oZUpmE?feature=shared)