2026-03-29 (일) 개발일지
오늘의 TIL: 개발자에서 B2B 영업 지원자로, 관점의 전환
포트폴리오를 영업 관점으로 리팩토링하기
오늘은 LG유플러스 B2B영업 직무에 지원하기 위해 포트폴리오를 완전히 뜯어고치는 작업을 했다. 원래는 개발자 포트폴리오처럼 기술 스택과 구현 디테일을 강조했는데, 피드백을 받고 보니 완전히 잘못된 접근이었다는 걸 깨달았다.
문제: 면접관(특히 B2B영업)이 원하는 건 내가 어떤 기술을 얼마나 잘 다루는지가 아니라, 그 기술이 비즈니스 문제를 어떻게 해결하는지였다. 내 포트폴리오는 “FastAPI로 API 만들었어요” 수준이었는데, 영업 직군은 “고객의 어떤 문제를 해결했고, 그로 인해 어떤 가치를 창출했나”를 보려 한다.
시도: 처음에는 그냥 표현만 바꾸면 되겠지 싶었다. “API 개발” → “솔루션 설계” 이런 식으로. 하지만 AI 튜터가 준 피드백을 보니 근본적인 문제가 있었다.
“B2B영업 면접관은 ‘FastAPI’, ‘API 명세서’, ‘모델 경량화’ 같은 단어를 보면 ‘이 사람 개발 직무 지원해야 하는 거 아닌가?’라고 생각합니다.”
이 말에 정말 찔렸다. 내가 쓴 글을 다시 읽어보니 완전히 개발자 시선이었다.
해결: 모든 프로젝트 설명을 문제 → 해결 → 가치 구조로 완전히 재작성했다.
- CodeFill 프로젝트 (AI 코딩 튜터)
- 기존: “Next.js로 프론트엔드 개발, FastAPI 백엔드, GPT API 연동…”
- 변경: “교육 기관의 코딩 학습 효율성 문제 인식 → end-to-end AI 튜터 솔루션 기획 및 RFP 설계 → 실제 서비스 배포까지 전 과정 주도”
- OpenTelemetry APM 플랫폼
- 기존: “OTLP 프로토콜 구현, ClickHouse 도입, ML 엔진 연동…”
- 변경: “엔터프라이즈 고객사의 온프레미스 환경 모니터링 니즈 파악 → 경제성 분석을 통한 아키텍처 제안 → MVP 개발을 통한 검증”
가장 중요한 건 정량적 성과를 강조한 점이다. 사무자동화 프로젝트에서는 “매일 2시간 걸리던 작업을 15분으로 단축(87.5% 효율 향상)”이라고 구체적으로 적었고, 이게 조직 전체(사무보조 4명)에 확산되어 연간 과제로 채택된 점을 강조했다.
배운 점: 같은 경험이라도 누가 보느냐에 따라 완전히 다른 스토리가 된다는 걸 뼈저리게 느꼈다. 개발자 동료에게는 기술적 도전과 해결 과정이 중요하지만, 비즈니스 측면의 의사결정자에게는 ROI와 확장성이 훨씬 중요하다. 이 차이를 이해하지 못하면 아무리 좋은 경험도 제대로 전달할 수 없다.
금융 도메인 지식의 전환
졸업 논문이 금융 관련이어서 이 부분을 강조하려고 했는데, 여기서도 함정이 있었다.
문제: 처음에는 “금융 기본 지식이 있습니다” 수준으로만 썼다. 하지만 이건 너무 추상적이다. AI 튜터가 “금융 고객사에게 AI·클라우드 솔루션의 가치를 어떻게 설명할 것인가?”라고 물었을 때, 막상 명확하게 답변하기 어려웠다.
시도: 단순히 지식의 나열(“금융시장론 수강, 펀드 분석 경험”)에서 벗어나, 그 지식이 실제 비즈니스 소통에서 어떻게 활용되는지를 보여주려고 했다.
해결: 다음과 같이 재구성했다:
- “단순 기술 설명을 넘어, 금융 도메인의 경제성 분석 관점에서 솔루션의 가치를 설명할 수 있습니다.”
- “교수님과의 지속적 소통을 통해 정답이 없는 연구 주제를 구체화해나가며, 이해관계자와의 협업 능력을 키웠습니다.”
- “중국인 교수님과 학우들 앞에서 중국어로 발표한 경험은 복잡한 내용을 다양한 배경을 가진 상대에게 전달하는 소통 능력을 증명합니다.”
핵심은 지식 자체가 아니라, 그 지식을 활용해 소통하고 문제를 해결하는 능력을 보여주는 거였다.
배운 점: 도메인 지식은 그 자체로 끝나는 게 아니다. 그 지식을 바탕으로 고객의 언어로 말할 수 있는 능력이 진짜 경쟁력이다. 금융권 고객에게 기술 솔루션을 팔려면, 기술적 장점보다 “투자 대비 성과(ROI)”, “리스크 관리”, “규제 준수” 같은 그들의 언어로 말해야 한다는 걸 배웠다.
공동과업의 어려움을 비즈니스 시나리오로 풀기
Talet 프로젝트(다문화 가정 AI 동화 서비스)에서의 팀 협업 경험을 자소서에 적었는데, 여기서도 관점의 전환이 필요했다.
문제: 원래는 “디자이너, 개발자, AI 엔지니어 간의 이해관계 조율”이라는 기술 팀 내부 문제로 서술했다.
시도: AI 튜터의 조언을 따라, 이 경험을 B2B영업의 RFP 설계 및 제안서 작성 과정에 빗대어 설명했다.
해결:
- 어려움: 서로 다른 직군(UI/UX 디자이너, iOS 개발자, 백엔드, AI)이 각자 다른 우선순위(사용자 경험 vs 성능 vs 효율성)를 고수
- 해결 과정: Figma로 요구사항을 시각화해 공통의 목표를 설정 → 각 파트의 제약조건을 명확히 문서화 → 타협점을 찾기 위한 반복적인 프로토타이핑
- 배운 점: 이 과정이 고객사의 다양한 부서(IT, 비즈니스, 재무)를 설득해 하나의 솔루션 방향으로 합의하는 B2B 영업 과정과 유사하다는 점을 강조
배운 점: 협업의 어려움은 모든 직군에서 발생한다. 하지만 그 어려움을 어떻게 비즈니스 문제 해결 능력으로 연결시키느냐가 중요하다. 개발 팀 내부의 갈등 조율 경험이, 고객사 내부의 다양한 이해관계자 조율 능력으로 이어질 수 있다는 걸 보여줘야 한다.
오늘의 한줄
같은 경험이라도 면접관의 렌즈를 통해 바라보는 법을 배웠다 - 개발자의 솔루션은 영업 직군의 가치 제안이 되어야 한다.