포트폴리오는 개발 일기가 아니다

게시 2026/01/20

By BLUEBUG

40 분읽는 시간

포트폴리오는 개발 일기가 아니다

요새 멘토링을 하고 있는데 개발자 취준생들이 가장 많이 저지르는 실수 몇가지 얘기해볼게요.
“React, Spring Boot 사용해서 게시판 만들었습니다.”
“AWS 배포 경험 있습니다.”
“팀원들과 소통하며 문제를 해결했습니다.”
냉정하게 말해서, 이건 ‘개발 일기’지 포트폴리오가 아닙니다. 채용 담당자가 보고 싶은 건 딱 하나예요.
“왜 React를 썼는가?” (다른 대안은 없었나?)
“로컬에선 잘 되는데, 배포 환경에서만 터진 에러는 어떻게 잡았나?
“소통 과정에서 설득은 데이터로 했나, 감으로 했나?”
기술 스택 나열하지 마세요. ‘생각’을 보여주세요. 코드는 누구나 짜지만, ‘근거’는 아무나 못 만듭니다.
맞아요. 예전엔 코드만 잘짜도 취업잘 됬는데, 이제는 코드를 AI가 짜주니까,
회사에서는 바이브코딩 말고,
유지보수와 확장성을 고려해서 AI를 통제하면서 개발하는 개발자를 원해요.
그래서 더더욱 스택나열보다는 어떤판단과 과정을 겪었는지를 더 봅니다~
https://www.threads.com/@tech_lead_cro/post/DTu4XHnkl_w

AI 시대, 채용 담당자가 진짜 보고 싶은 것

“React, Spring Boot 사용해서 게시판 만들었습니다.” “AWS 배포 경험 있습니다.” “팀원들과 소통하며 문제를 해결했습니다.” 멘토링을 하며 만난 수많은 취준생들의 포트폴리오에서 반복적으로 보게 되는 문장들이다. 언뜻 보면 문제가 없어 보인다. 기술 스택도 나열했고, 경험도 적었으며, 협업도 언급했다. 하지만 이것은 포트폴리오가 아니라 ‘개발 일기’에 가깝다. 오늘 무엇을 했는지는 적혀 있지만, 왜 그렇게 했는지, 어떤 고민을 했는지, 무엇을 배웠는지는 보이지 않는다.

2026년 현재, 개발자 채용 시장은 역사상 가장 흥미로운 전환점을 지나고 있다. AI가 코드를 작성하고, 바이브 코딩으로 비개발자도 프로토타입을 만들며, Claude나 ChatGPT가 복잡한 알고리즘을 순식간에 구현해낸다. 이런 시대에 기업들이 개발자에게 기대하는 것은 무엇일까? 단순히 코드를 작성할 수 있는 능력? 아니다. AI가 그것을 더 빠르고 정확하게 해낸다. 기업이 원하는 것은 ‘생각하는 개발자’다. 문제를 정의하고, 선택지를 비교하며, 근거를 가지고 판단하는 사람. 포트폴리오는 바로 그 생각의 과정을 보여주는 문서여야 한다.

기술 스택 나열의 시대는 끝났다

불과 몇 년 전만 해도 “Java, Spring, React, MySQL”이라는 기술 스택 목록만으로도 어느 정도 차별화가 가능했다. 하지만 2026년의 채용 시장은 완전히 다르다. 코드프레소의 2026년 채용 트렌드 분석에 따르면, 기업들은 이제 단순한 기술 스택이 아니라 “스킬 기반 평가”를 중시한다. 학위나 직함보다 실제로 무엇을 할 수 있는지, 어떤 문제를 해결했는지가 핵심 평가 기준이 되었다.

Stack Overflow의 2025년 개발자 설문조사 결과는 더욱 충격적이다. 응답자의 84%가 개발 중 AI 도구를 사용하고 있거나 사용할 계획이라고 답했다. 이는 전년 대비 76% 증가한 수치다. ChatGPT 사용률은 81.4%에 달한다. 즉, 코드 작성 그 자체는 더 이상 개발자만의 고유 영역이 아니게 되었다는 의미다.

그렇다면 무엇이 개발자를 차별화하는가? 바로 “왜 React를 선택했는가?”라는 질문에 답할 수 있는 능력이다. “다른 프레임워크와 비교했을 때 React의 어떤 장점이 이 프로젝트에 적합했는가?”, “Vue.js나 Svelte는 왜 고려하지 않았는가?”, “프로젝트 규모와 팀 구성을 고려했을 때 이 선택이 최선이었다고 생각하는 이유는?” 이런 질문들에 명확한 근거를 가지고 답할 수 있다면, 그것이 바로 AI가 대체할 수 없는 개발자의 가치다.

배포했다고 끝이 아니다, 진짜는 그 다음이다

“AWS 배포 경험 있습니다”라는 문장을 포트폴리오에서 수없이 봤다. 하지만 채용 담당자가 정말 알고 싶은 것은 배포했다는 사실이 아니다. “로컬에서는 잘 되는데 배포 환경에서만 터진 에러는 어떻게 해결했는가?”가 진짜 질문이다.

실제 개발 현장에서는 예상치 못한 문제가 끊임없이 발생한다. 개발 환경과 프로덕션 환경의 차이, 네트워크 지연, 동시 접속자 폭증, 메모리 누수, 데이터베이스 병목. 이런 문제들을 마주했을 때 개발자가 어떻게 사고하고 행동하는지가 그 사람의 진짜 실력을 보여준다.

2026년 채용 트렌드를 분석한 여러 자료들은 공통적으로 “문제 해결 능력”을 최우선 역량으로 꼽는다. 가트너의 전망에 따르면, 2026년까지 약 50%의 글로벌 조직이 지원자의 독립적이고 비판적인 사고를 평가하게 될 것이라고 한다. 단순히 기능을 구현하는 것이 아니라, 비즈니스 문제를 해결하고, 최적의 코드 구조를 고민하며, 복잡한 오류를 분석하고 해결하는 능력이 핵심이 되었다.

그래서 포트폴리오에는 트러블슈팅이 필수적으로 들어가야 한다. 그것도 단순히 “에러가 발생해서 해결했습니다”가 아니라, 명확한 구조로 기술되어야 한다. 문제 → 과정 → 해결 → 결과. 이 네 단계를 따라가면서 자신의 사고 과정을 투명하게 보여주어야 한다.

예를 들어보자. “무한 스크롤 구현 중 API 중복 호출 문제가 발생했습니다(문제). 네트워크 탭을 확인해보니 동일한 페이지 번호로 여러 번 요청이 가고 있었고, 스크롤 이벤트가 빠르게 발생할 때 상태 업데이트가 비동기적으로 처리되면서 생긴 문제로 파악했습니다(과정). 이를 해결하기 위해 현재 요청 중인 페이지 번호를 ref로 관리하고, 이미 요청 중이면 새로운 요청을 차단하도록 구현했습니다(해결). 그 결과 중복 호출이 완전히 제거되었고, 네트워크 트래픽이 약 40% 감소했습니다(결과).”

이런 식의 기술은 채용 담당자에게 여러 가지를 알려준다. 첫째, 문제를 정확히 진단할 수 있는 디버깅 능력. 둘째, 근본 원인을 파악하는 분석력. 셋째, 여러 해결 방안 중 적절한 것을 선택하는 판단력. 넷째, 정량적으로 성과를 측정하는 습관. 이 모든 것이 단 하나의 트러블슈팅 사례에 담겨 있다.

소통했다는 증거를 보여줘라

“팀원들과 소통하며 문제를 해결했습니다”라는 문장도 자주 본다. 하지만 이 역시 너무 추상적이다. 채용 담당자가 알고 싶은 것은 “설득은 데이터로 했나, 감으로 했나?”다.

실제 개발 현장에서 협업은 단순히 친절하게 대화하는 것이 아니다. 의견 충돌이 있을 때, 기술적 판단이 엇갈릴 때, 일정과 품질 사이에서 트레이드오프를 해야 할 때, 어떻게 팀을 설득하고 합의를 이끌어내는가가 진짜 협업 능력이다.

예를 들어 “백엔드 팀에서 API 응답 시간을 줄이기 위해 데이터 구조를 변경하자고 제안했는데, 프론트엔드 입장에서는 기존 코드를 전면 수정해야 하는 부담이 있었습니다. 이에 현재 API 응답 시간 분포를 측정해보니 95 퍼센타일에서 2.3초가 걸리고 있었고, 사용자 이탈률 데이터와 교차 분석한 결과 2초 이상 걸릴 때 이탈률이 35% 증가한다는 것을 확인했습니다. 이 데이터를 바탕으로 팀을 설득했고, 결과적으로 프론트엔드 리팩토링에 3일을 투자해 평균 응답 시간을 1.2초로 단축했습니다. 이후 한 달간 사용자 이탈률이 18% 감소했습니다.”

이것이 진짜 소통이다. 감이 아니라 데이터로, 주장이 아니라 근거로, 일방적 요구가 아니라 상호 이익을 보여주며 설득하는 것. 이런 경험을 포트폴리오에 담으면, 채용 담당자는 “이 사람은 실제 현장에서 일할 준비가 되어 있구나”라고 생각하게 된다.

AI 시대, 개발자의 역할이 바뀌었다

예전에는 코드를 빠르고 정확하게 짜는 것이 좋은 개발자의 조건이었다. 알고리즘을 잘 알고, 디버깅을 신속하게 처리하며, 최신 프레임워크를 빠르게 습득하는 사람. 하지만 AI가 등장하면서 게임의 룰이 바뀌었다.

이제 좋은 개발자는 “무엇을 만들 것인가”를 정의하는 사람이다. “왜 만들어야 하는가”를 설명하고, “어떤 제약 조건이 있는가”를 파악하며, “여러 대안 중 무엇이 최선인가”를 판단하는 사람. AI는 정의된 문제는 매우 잘 풀지만, 문제를 정의하는 것은 여전히 사람의 몫이다.

그룹바이의 2025년 채용 동향 분석을 보면 흥미로운 패턴이 발견된다. 투자 단계가 높아질수록 AI 및 데이터 관련 직군 비율은 15%에서 34%까지 급등한 반면, 웹·앱 중심 포지션(백엔드·프론트엔드·풀스택)은 점차 감소세를 보였다. 자금이 확보될수록 기업들은 신규 서비스 개발보다 AI 고도화와 운영 자동화에 집중한다는 의미다.

이것이 시사하는 바는 명확하다. 단순히 주어진 스펙대로 구현하는 개발자의 수요는 줄어들고, AI를 활용해 비즈니스 문제를 해결하고 시스템을 설계하는 개발자의 수요는 늘어난다는 것이다. 바이브 코딩으로 빠르게 프로토타입을 만드는 것도 중요하지만, 더 중요한 것은 “유지보수와 확장성을 고려해서 AI를 통제하면서 개발하는” 능력이다.

실제로 AI 기술을 요구하는 채용 공고가 그렇지 않은 공고보다 약 28% 높은 연봉을 제공한다는 라이트캐스트의 분석 결과도 있다. 하지만 여기서 말하는 ‘AI 기술’은 단순히 ChatGPT를 사용할 줄 아는 것이 아니라, AI의 한계를 이해하고, 프롬프트를 설계하며, AI API를 실무에 통합하고, AI가 생성한 코드의 품질을 검증할 수 있는 종합적인 역량을 의미한다.

채용 담당자의 눈으로 보기

포트폴리오를 작성할 때 가장 큰 실수는 “내가 무엇을 했는지”만 적는 것이다. 채용 담당자가 보고 싶은 것은 “이 사람이 우리 회사에 와서 어떤 가치를 만들어낼 수 있는지”다.

토스페이먼츠 개발자의 포트폴리오 작성 경험담을 보면 중요한 통찰이 담겨 있다. “00 페이지 개발”이라고 적었을 때 피드백은 “어떠한 페이지인지 잘 모르겠다”였다. “00 기능 개발”이라고 했을 때는 “해당 기능을 개발하면서 어려웠던 점을 작성해 주면 좋을 것 같다”는 코멘트를 받았다.

채용 담당자는 당신의 프로젝트를 처음 본다. 당신에게는 당연한 맥락이 그들에게는 전혀 보이지 않는다. 따라서 처음 보는 사람도 이해할 수 있게 작성해야 한다. 프로젝트 스크린샷을 첨부하고, 기술적 용어는 간단히 설명하며, 왜 이것이 중요한지 비즈니스적 맥락을 제공해야 한다.

그리고 가장 중요한 것은 “차별성”이다. 수십 명, 수백 명의 지원자가 모두 비슷한 프로젝트를 했다면, 무엇이 당신을 특별하게 만드는가? 바로 당신만의 문제 해결 과정, 당신만의 통찰, 당신만의 성장 스토리다.

포트폴리오는 “나의 커리어를 15초간 설명하는 티저”라는 표현이 있다. 티저는 흥미를 유발해야 한다. “이 사람과 면접을 해보고 싶다”, “이 사람의 이야기를 더 듣고 싶다”는 생각이 들게 만들어야 한다. 그러려면 기술 스택 나열이 아니라, 생각의 흔적을 보여줘야 한다.

숫자로 말하라

“성능을 개선했습니다”와 “응답 시간을 2.3초에서 1.2초로 47% 개선했습니다”의 차이를 생각해보라. 전자는 추상적이고 검증할 수 없지만, 후자는 구체적이고 측정 가능하다.

개발자는 엔지니어다. 엔지니어는 정량적으로 사고한다. 포트폴리오에서도 가능한 모든 것을 숫자로 표현해야 한다. API 응답 시간, 페이지 로딩 속도, 데이터베이스 쿼리 실행 시간, 메모리 사용량, 코드 커버리지, 버그 발생률, 사용자 증가율. 이런 지표들은 당신이 단순히 기능을 구현한 것이 아니라, 성과를 만들어냈다는 것을 증명한다.

“사용자 경험을 개선했습니다” 대신 “무한 스크롤 도입으로 페이지 이탈률을 35%에서 22%로 감소시켰습니다”라고 쓰면 어떨까? “데이터베이스를 최적화했습니다” 대신 “인덱스 재설계로 조회 쿼리 실행 시간을 평균 850ms에서 120ms로 개선했습니다”라고 하면? 후자가 훨씬 더 설득력 있고 신뢰할 수 있다.

물론 모든 프로젝트에서 화려한 숫자를 만들어낼 수는 없다. 특히 취준생이라면 실사용자가 있는 서비스를 경험하기 어렵다. 하지만 그럴 때도 방법은 있다. 테스트 데이터로 성능을 측정하거나, 코드 품질 지표를 제시하거나, 개발 시간 단축 효과를 계산할 수 있다. “팀 프로젝트 진행 중 공통 컴포넌트 라이브러리를 만들어 각 팀원의 반복 작업 시간을 평균 30% 단축했습니다”와 같은 방식으로 말이다.

실패도 자산이다

많은 취준생들이 포트폴리오에 성공 사례만 담으려 한다. 하지만 실패 경험도 중요한 자산이 될 수 있다. 물론 단순히 “실패했습니다”로 끝나면 안 된다. “실패했고, 그로부터 무엇을 배웠으며, 다음에는 어떻게 다르게 접근할 것인지”를 보여줘야 한다.

예를 들어 “초기에 NoSQL을 선택했는데, 프로젝트가 진행되면서 복잡한 관계형 쿼리가 필요해졌습니다. MongoDB의 lookup 연산으로 처리하려 했지만 성능이 심각하게 저하되었고, 결국 PostgreSQL로 마이그레이션해야 했습니다. 이 과정에서 3주의 시간이 소요되었지만, 데이터베이스 선택 시 미래의 확장성과 쿼리 복잡도를 미리 예측하는 것이 얼마나 중요한지 배웠습니다. 다음 프로젝트에서는 프로토타이핑 단계에서 예상되는 주요 쿼리들을 먼저 정리하고, 각 데이터베이스에서 어떻게 구현될지 비교 분석한 후 선택했습니다.”

이런 서술은 여러 측면에서 가치가 있다. 첫째, 실수를 인정할 수 있는 솔직함. 둘째, 실패로부터 배우는 성장 마인드셋. 셋째, 구체적인 개선 행동. 넷째, 시스템적 사고. 채용 담당자는 완벽한 사람을 찾는 것이 아니라, 성장할 수 있는 사람을 찾는다. 실패를 통해 성장했다는 것을 보여주면, 오히려 더 큰 신뢰를 얻을 수 있다.

코드도 보여주되, 맥락과 함께

GitHub 링크를 포트폴리오에 넣는 것은 좋다. 하지만 링크만 던져주면 안 된다. 채용 담당자가 코드를 다 읽어볼 시간이 없기 때문이다. 핵심적인 코드 몇 부분을 선별해서, 왜 이 코드가 중요한지, 어떤 고민이 담겨있는지 설명해야 한다.

“이 부분은 동시성 문제를 해결하기 위해 락 프리 알고리즘을 적용했습니다. 처음에는 synchronized를 사용했지만 경합 상황에서 성능이 크게 저하되어, AtomicReference와 CAS 연산을 활용한 방식으로 변경했습니다. 벤치마크 결과 높은 동시성 환경(1000 TPS)에서 처리 시간이 평균 45ms에서 12ms로 개선되었습니다.”

이런 식으로 코드에 담긴 의사결정과 그 근거를 함께 제시하면, 단순히 코드를 잘 짠다는 것을 넘어 엔지니어링 센스가 있다는 것을 보여줄 수 있다.

또한 코드 품질 관리 도구를 활용한 경험도 어필 포인트가 된다. “SonarQube를 도입해 코드 커버리지를 65%에서 85%로 높였고, 코드 스멜을 지속적으로 모니터링했습니다” 같은 내용은 단순히 기능 구현을 넘어 품질을 중시하는 개발자라는 인상을 준다.

지속적인 학습의 흔적

기술은 빠르게 변한다. 특히 AI 시대에는 그 속도가 더욱 가속화되고 있다. 2026년 채용 트렌드의 핵심 키워드 중 하나가 바로 “지속적인 학습과 적응력”이다. 기술 변화 속도가 빨라지면서 기업은 단순한 기술 역량을 넘어, 지속적으로 학습하고 적응할 수 있는 개발자를 선호한다.

포트폴리오에서 이것을 어떻게 보여줄 수 있을까? 기술 블로그, 오픈소스 기여, 컨퍼런스 참석, 온라인 강의 수강, 스터디 그룹 운영 등이 모두 증거가 될 수 있다. 하지만 여기서도 중요한 것은 “했다”는 사실이 아니라 “무엇을 배웠고 어떻게 적용했는지”다.

“Go 언어를 새로 학습해 기존 Python 마이크로서비스를 Go로 재작성한 결과, 메모리 사용량이 60% 감소하고 처리 속도가 3배 향상되었습니다. 이 과정에서 정적 타이핑과 컴파일 언어의 장점을 실감했고, 이후 성능이 중요한 서비스에는 Go를 우선 고려하게 되었습니다.” 이런 서술은 단순히 새로운 기술을 배웠다는 것을 넘어, 학습을 실제 가치로 전환할 수 있는 능력을 보여준다.

비즈니스를 이해하는 개발자

기술적으로 완벽한 솔루션이 항상 정답은 아니다. 때로는 80%의 품질로 빠르게 출시하는 것이, 100%를 추구하다가 시장 타이밍을 놓치는 것보다 나을 수 있다. 이런 비즈니스적 감각을 가진 개발자는 매우 귀하다.

포트폴리오에서 이것을 어떻게 드러낼까? “마케팅 팀의 요청으로 급하게 이벤트 페이지를 만들어야 했습니다. 완벽한 반응형 디자인과 최적화를 구현하려면 2주가 필요했지만, 이벤트 시작까지 5일밖에 없었습니다. 핵심 타겟인 모바일 사용자(전체의 85%)에 집중해 모바일 최적화만 완벽하게 구현하고, 데스크톱은 기본 레이아웃만 제공하는 방식으로 3일 만에 완성했습니다. 결과적으로 이벤트 기간 동안 목표 전환율 3%를 초과한 4.2%를 달성했고, 이후 여유가 생겼을 때 데스크톱 최적화를 진행했습니다.”

이런 사례는 기술력뿐 아니라 우선순위 설정, 리소스 관리, 비즈니스 목표 이해 등 다양한 역량을 보여준다. 단순히 코드를 짜는 개발자가 아니라, 비즈니스 가치를 만드는 개발자라는 인상을 준다.

협업 도구와 프로세스

현대의 개발은 혼자 하는 것이 아니다. Git, Jira, Slack, Notion, Figma 등 다양한 협업 도구를 활용하고, 애자일, 스크럼, 칸반 같은 방법론을 이해하며, 코드 리뷰와 페어 프로그래밍에 익숙한 개발자가 필요하다.

“Git Flow를 적용해 개발/스테이징/프로덕션 브랜치를 분리 관리했고, Pull Request에 최소 2명의 리뷰어 승인을 받도록 규칙을 정했습니다. 초기에는 리뷰 시간이 길어져 불편했지만, 3개월 후 프로덕션 배포 후 발견되는 버그가 70% 감소했습니다” 같은 경험은 체계적인 개발 프로세스를 이해하고 있다는 것을 보여준다.

또한 “Jira를 활용해 스프린트를 2주 단위로 진행했고, 매일 15분간 스탠드업 미팅으로 진행 상황과 블로커를 공유했습니다. 레트로스펙티브를 통해 Keep/Problem/Try 방식으로 프로세스를 지속적으로 개선했습니다” 같은 내용은 실제 개발 조직에서 일한 경험이 있거나, 그런 환경에 빠르게 적응할 수 있다는 신호를 준다.

포트폴리오는 살아있는 문서다

포트폴리오를 한 번 만들어놓고 끝이 아니다. 새로운 프로젝트를 진행하면 업데이트하고, 기술을 학습하면 추가하며, 면접 피드백을 받으면 개선해야 한다. 포트폴리오는 당신의 성장을 반영하는 살아있는 문서여야 한다.

그리고 회사마다 조금씩 커스터마이징하는 것도 좋은 전략이다. 스타트업에 지원한다면 빠른 실행력과 다양한 역할 수행 경험을 강조하고, 대기업에 지원한다면 체계적인 프로세스와 대규모 시스템 경험을 부각시키는 식이다. 핵심 내용은 같지만, 강조점을 달리하는 것이다.

또한 포트폴리오를 여러 사람에게 보여주고 피드백을 받는 것도 중요하다. 멘토, 현직 개발자, 동료 취준생 모두에게서 배울 점이 있다. 특히 “이 부분이 이해가 안 된다”, “이게 왜 중요한지 모르겠다”는 피드백은 금이다. 채용 담당자도 똑같이 느낄 것이기 때문이다.

결국 포트폴리오는 당신의 이야기다

기술 스택은 도구일 뿐이다. AWS, React, Spring Boot는 당신이 사용한 연장이다. 하지만 포트폴리오에서 정말 중요한 것은 그 연장으로 무엇을 만들었고, 왜 그렇게 만들었으며, 그 과정에서 무엇을 배웠는가다.

“React, Spring Boot 사용해서 게시판 만들었습니다”는 연장 목록이다. “게시판 프로젝트에서 실시간 댓글 알림 기능 구현 시 폴링 방식과 웹소켓 방식을 비교 분석했고, 서버 부하와 실시간성을 고려해 웹소켓을 선택했습니다. 하지만 초기 구현에서 연결 관리 문제로 메모리 누수가 발생해, 연결 풀링과 자동 재연결 로직을 추가해 해결했습니다. 결과적으로 100명의 동시 사용자 환경에서 평균 지연 시간 200ms 이하로 안정적인 실시간 알림을 제공할 수 있었습니다”는 당신의 이야기다.

포트폴리오는 개발 일기가 아니다. 그것은 당신이 어떤 개발자인지, 어떻게 사고하는지, 어떤 가치를 만들어낼 수 있는지를 보여주는 증거 문서다. AI가 코드를 짜주는 시대에, 채용 담당자가 진짜 보고 싶은 것은 바로 그것이다. 당신의 생각, 당신의 판단, 당신의 성장. 그리고 그것을 명확한 근거와 함께 설명할 수 있는 능력.

지금 당신의 포트폴리오를 다시 열어보라. “했다”는 문장들을 “왜 했고, 어떻게 했으며, 무엇을 배웠는가”로 바꿔보라. 기술 스택 나열을 의사결정의 근거로 바꿔보라. 추상적인 표현을 구체적인 숫자로 바꿔보라. 그렇게 하나씩 바꾸다 보면, 어느새 당신의 포트폴리오는 개발 일기가 아니라 진짜 포트폴리오가 되어 있을 것이다.

그리고 기억하라. 채용 담당자는 당신이 무엇을 했는지보다, 당신이 무엇을 할 수 있는 사람인지를 보고 싶어 한다. 과거는 증거일 뿐, 진짜 중요한 것은 미래다. 당신의 포트폴리오가 그 미래를 설득력 있게 그려낼 수 있다면, 그것이 바로 합격하는 포트폴리오다.

작성일자: 2026-01-20

TechStack, Story

AI vibe-coding Claude.write