About

avatar

Seonghyeon Kim

Software Engineer
당근
mailgithublinkedinx
🇰🇷 한국어🇺🇸 English
Intro

주로 Typescript, React, NodeJS를 사용해서 개발을 하고 있어요. 새로운 기술에 대한 학습도 좋아하지만 정의한 문제를 해결하기에 적합한 기술을 학습하고 사용하려고 노력하고 있어요.

설계된 문제와 가설 아래에서 일하는 것을 선호해요. 데이터를 기반으로 가설을 검증하고 성공하고 실패하는 순환 안에서 가치를 키워나가기를 희망해요. 거창하지 않더라도 궁극적으로 세상에 좋은 가치를 만들어 내고, 밝고 좋은 에너지를 나누는 삶을 살고 싶어요.

Experiences
당근 22.09 ~ 현재
직무
Software Engineer, Frontend (22.09 ~ 24.01)
(Lead) Software Engineer, Frontend (24.01 ~ 현재)
담당제품
소상공인 광고주센터, 전문가 광고주센터, 광고 SDK, BFF
기술스택
typescript, react, relay, react-query, vanilla-extract, tailwindcss, node.js, fastify, graphql
담당 업무

당근 광고 플랫폼의 프론트엔드 개발 리드를 맡고 있어요. 소상공인부터 전문 광고주까지 다양한 고객층을 위한 광고 솔루션 구축을 담당하고 있어요. 기본적으로 제품 초기 설계부터 운영까지 전 과정에 참여하고, 더 나아가 팀의 기술 표준 수립과 개발 생산성 향상을 위한 노력도 지속하고 있어요.

주요 프로젝트
[BFF 에러 로그 및 알림 설정 개선]
배경
  • GraphQL 서버에서 status가 500인 경우만 카운트하고 그게 일정 수를 넘어가면 알림을 주고 있는 상황이 있었어요.
  • 통신하고 있는 서버들이 400번대의 에러들을 500번대의 에러로 response해주는 경우도 있었어요.
  • 트래픽이 올라가면 알럿이 당연히 발생할 수 밖에 없는 상황이었고, 팀 내에서 에러 알림이 울려도 심각하게 생각하지 않는 상황에 처해있었어요.
접근
  • 통신하는 서버에서 400번대의 에러를 500번대의 에러로 내려주는 경우들을 수집해서 서버팀에 개선을 요청했어요.
  • error 로그는 0으로 수렴해야되는 값이고, warn은 최근 추이보다 훨씬 더 많이 튀지 않는지 체크하는 방향으로 알럿 설정들을 점검했어요.
결과
  • 슬랙에 발송되는 BFF 관련 에러 알림에 대한 신뢰도가 상승했어요.
  • 각 레벨의 에러들을 어떻게 바라보고 관리해야할지 기준을 체계적으로 정리할 수 있었어요.
  • 신뢰가 없는 에러 알림은 에러 알림이 없는 것보다 더 나쁘다는 것을 한번 더 배울 수 있는 시간이었어요.
[리드폼 광고 상품 추가]
배경
  • 광고주들이 고객의 정보를 수집하기 위해서 아웃링크 광고를 사용하고 있었어요.
  • 아웃링크로 이동해서 유저들이 고객 정보를 제출하기 위해서 이미 당근앱에서 알고 있는 정보들을 유저들이 직접 다시 입력을 해야하는 상황이었어요.
  • 광고 전환율에 악영향을 끼치고 있는 상황이었어요.
접근
  • 당근에서 내부적으로 가지고 있는 정보를 prefill해서 고객 정보들을 수집할 수 있는 리드폼이라는 새로운 광고 상품을 개발했어요.
결과
  • 광고주들이 고객 정보 수집을 위해서 아웃링크가 아니라 리드폼을 활용할 수 있게 되었어요.
  • 리드폼 광고가 기존 아웃링크 광고와 비교했을 때 더 좋은 전환율을 기록하고 있어요.
  • funnel과 관련된 코드들의 응집성을 지키기 위해서 어떻게 코드를 관리하면 좋은지 고민했고, use-funnel 라이브러리를 활용하고 참고해서 코드를 작성했어요.
[AI 기반 광고 분석 기능 개발]
배경
  • 광고주들이 너무 작은 예산을 입력해서 광고 입찰의 기회도 얻지 못하고 예산을 소진하지 못하고 있었어요.
  • 설정값, 퍼포먼스 관련 정보들을 제공해도 소상공인 광고주들은 해당 정보들을 분석하기 어려워했어요.
  • AI를 활용하면 창의적이고 다양한 답변을 줄 수 있지 않을까하는 내부적인 논의가 있었어요.
접근
  • 설정값 및 퍼포먼스 수치를 AI 및 내부적으로 정한 규칙에 따라서 분석하고 결과를 제공하는 기능을 개발했어요.
  • AI를 활용할 때 프롬프트를 작성하고 개선해나가면서 최대한 유저들에게 도움이 되는 답변을 제공할 수 있도록 노력했어요.
  • AI에 단순히 프롬프트만 전달하는 것이 아니라 동종업계의 상위 광고주들의 정보들을 활용하여 최대한 플랫폼에서 효과를 볼 수 있는 방향으로 성과 분석을 제공하려고 노력했어요.
  • 성과 분석에서 추천하는 액션들을 최대한 편하게 적용시킬 수 있도록 UX를 설계했어요.
결과
  • 기존에 목표했던 성과 분석을 통한 추천 액션 적용을 유도함으로써 예산 미소진을 유발하는 작은 예산 입력을 방지하는 데에 개선을 이끌어냈어요.
  • 프롬프트 작성에 참여하면서 프롬프트 작성 노하우를 배울 수 있는 기회를 얻을 수 있었어요.
  • 서버의 응답이 비동기로 오는 형태였기 때문에, 관련해서 어떻게 UX로 풀 수 있을지 고민하면서 작업했고, 로딩과 알림을 적절히 처리하여 최적의 UX를 만들어내려고 노력했어요.
[소상공인 광고주센터 웹, 웹뷰 통합 프로젝트]
배경
  • 소상공인을 위한 광고주센터는 기존에 웹, 웹뷰가 따로 개발되고 관리되고 있었어요.
  • 상대적으로 웹뷰의 유저가 많아서 새로운 기능들은 웹뷰 우선적으로 개발이 되고 있었고, 웹 제품을 그에 비해서 뒤쳐지고 있었고, 스펙 싱크가 안맞는 부분들이 생기기 시작했어요.
접근
  • 스펙 격차가 생기는 문제를 해결하기 위해서 웹, 웹뷰의 클라이언트 코드를 한 벌의 코드로 작성하기로 결정하고 작업을 시작했어요.
  • 디자인은 모바일 퍼스트로 작업을 진행했고, 특수한 웹 디자인이 필요한 경우에는 반응형 디자인을 작업했어요.
  • 로직적으로 웹과 웹뷰의 코드가 차이가 있는 경우에는 두벌의 코드를 만들어서 관리했어요.
결과
  • 웹, 웹뷰의 코드가 하나가 되었고, 그 이후로 무조건 기능을 개발할 때 웹뷰, 웹 기능을 동시에 개발했어요.
  • 한 코드에 반응형 디자인과 런타임별로 다른 로직을 구현함으로써 코드베이스가 비대해지고 복잡해져서 관리가 어려워졌어요.
  • 웹의 좋은 사용자 경험과 웹뷰의 좋은 사용자 경험이 확연이 다른데도 불구하고 모바일 퍼스트로 디자인하고 웹의 사용성을 떨어트리는 경우가 많아졌어요.
  • 하나의 코드 베이스에서 관리한다고 치더라도 결국에는 두벌이 되어야하는 코드들이 존재하기도 하고, 각 플랫폼의 사용성에 최적화된 경험을 제공하기 위해서는 분리되어야하는 부분도 있다는 사실을 절실하게 깨달았어요.
  • 기존에 인식했던 문제를 단순히 하나의 코드베이스로 합치는 방향성이 아니라 프로젝트 관리 방식의 변경이나 공통로직 패키지 도입 등 다른 방식으로도 풀 수 있었을 거라는 아쉬움이 있었어요. 배경과 문제에 대한 깊은 이해를 바탕으로 적절한 솔루션을 잘 디자인하는 것이 가장 중요하다는 사실을 다시 한 번 배울 수 있었어요.
[광고 생성 퍼널 전환율 개선 실험]
배경
  • 소상공인 광고주센터 웹뷰 서비스에서 광고 생성을 할 때 설정해야하는 값들이 많았고, 그에 따라 퍼널이 깊어서 특정 퍼널의 전환율이 좋지가 않음을 관찰했어요.
  • 광고를 생성하는 것이 광고 매출로 가는 첫 단추였기 때문에 이 문제를 어떻게 개선할 수 있을까 팀 내에서 고민을 하고 있었어요.
접근
  • 여러가지 깊었던 퍼널을 혁신적으로 원페이지로 줄여서 광고 생성 기능을 제공하는 방향으로 개발을 진행했어요.
  • 광고 생성에 필요한 필수 기능만 원페이지로 구성해서 노출하고 구체적으로 커스텀할 수 있는 기능들은 뒷단에 숨겨두는 형태로 최대한 퍼널을 간소화했어요.
결과
  • 기존 퍼널보다 생성율이 더 좋아질 것이라고 직감적으로 생각하고 있었지만, 결과적으로는 기존 퍼널보다 생성율이 더 낮았어요.
  • 항상 퍼널을 줄이는 것이 좋은 결과로 이어진다고 생각해왔었는데, 그렇지 않을 수 있다는 점을 배웠어요. 퍼널의 깊이보다 페이지에서 유저가 알아야하는 정보를 간편하게 전달하고 액션을 유도하는 것이 더 중요하다는 사실을 배웠어요.
한국신용데이터 21.01 ~ 22.09
직무
Product Engineer
담당제품
캐시노트, 캐시노트마켓, 캐시노트마켓 파트너센터, MMP SDK
기술스택
typescript, react, next.js, tailwind, react-query, react-hook-form, react-testing-library, msw, jest, storybook, graphql, apollo-client
담당 업무

한국신용데이터에서 Product Engineer로 일하며 캐시노트 서비스의 기능들을 개발했어요. 캐시노트마켓 서비스의 경우 서비스 설계부터 프론트엔드 전반을 담당했어요.

주요 프로젝트
[캐시노트마켓 개발]
배경
  • 한국신용데이터 회사 내부적으로 다른 매출원을 찾고 있었어요.
  • 내부 트래픽을 활용해서 사업장들에게 제품들을 판매할 수 있는 커머스 개발 프로젝트가 시작되었어요.
접근
  • 2명의 인원으로 대고객용 커머스 웹뷰와 대판매자용 어드민을 작업하기 시작했어요.
  • 홈 화면의 경우 Server Driven UI 형태로 구현하여 운영하는 인력이 기획전이나 카탈로그를 자유롭게 운영할 수 있도록 개발했어요.
결과
  • 지속적으로 매출이 상승했고, 캐시노트 입장에서는 구독 요금 이외의 새로운 비즈니스 모델을 만들어낼 수 있었어요.
  • MVP를 잘 정의했고, 너무 많은 기능을 한번에 다 넣기보다 점진적으로 기능 개발을 했고 추가했어요.
  • 개발 차원에서는 NextJs를 본격적으로 많이 써보면서 렌더링 방식에 대한 이해도를 높일 수 있었어요.
  • NextJs를 Vercel이 아닌 내부 Infra를 구성해서 운영했어요. AWS Infra 관련 지식을 늘릴 수 있는 기회였어요. (ECS, Fargate 등)
티페이 20.02 ~ 21.01
직무
Frontend Developer
담당제품
가맹점 관리/계약 어드민
기술스택
typescript, react, styled-component, swr, react-hook-form
담당 업무

티페이에서 Frontend Developer로 가맹점 관리 어드민과 계약 어드민 시스템을 개발했어요.

주요 프로젝트
[가맹점 관리 어드민 물류 파트 리팩토링]
배경
  • 기존에 만들어져있던 물류 어드민 사용이 불편해서 개선이 필요하다는 요청들이 있었어요.
  • 물류/재고 서비스들은 수 많은 Input이 있는 폼을 다루어야했고, 퍼포먼스 문제가 발생하고 있었어요.
접근
  • 많은 Input이 있는 상황에서도 어드민이 느려지지 않고 작동이 되도록 퍼포먼스를 챙기면서 작업했어요.
  • 데이터 Row 수가 100개가 넘는 것들을 다루어야하는 경우가 있었어요. Shift + Click을 통해서 여러 Row을 한번에 선택하기 쉽게 도와주는 기능 등을 고려하면서 작업했어요.
결과
  • React로 웹앱을 개발하면서 많은 Input을 다루는 일이 처음이었고 이런 문제를 어떻게 대응할 수 있는지에 대해서 고민하고 배울 수 있는 기회였어요.
스타일쉐어 19.04 ~ 20.02
직무
Frontend Developer
담당제품
스타일쉐어 웹, 스타일쉐어 검색웹뷰
기술스택
typescript, react, next.js, styled-component
담당 업무

스타일쉐어에서 Frontend Developer로 스타일쉐어 웹과 스타일쉐어 검색웹뷰 개발을 담당했어요.

주요 프로젝트
[스타일쉐어 검색웹뷰]
배경
  • 빠른 실험과 개선이 필요한 검색 기능을 네이티브 앱에서 분리하여 유연성 확보가 필요했어요.
접근
  • 네이티브 앱과의 브릿지 통신을 구현했어요.
  • 웹뷰 기반 검색 서비스를 개발하여 빠른 배포와 A/B 테스트를 가능하게 했어요.
결과
  • 웹뷰 개발에 대한 경험을 처음 해볼 수 있었어요.
  • 네이티브앱 배포와는 별개로 기능을 배포할 수 있었고 자주 실험을 진행할 수 있는 환경을 만들었어요.
[웹 스토어 리뉴얼]
배경
  • 스타일쉐어 스토어 메인 홈 디자인 개편이 필요하다는 논의가 진행되었어요.
  • jQuery로 구현되어있던 코드라 React를 사용해서 리뉴얼하는게 좋겠다는 논의가 있었어요.
접근
  • 새로운 디자인과 완전히 새로운 코드 베이스로 해당 페이지를 리뉴얼하기로 결정했어요.
  • 한번에 모든 페이지를 개발할 수 없었기에 점진적으로 리뉴얼 하기 위해서 특정 route만 갈아끼울 수 있도록 고려하면서 infra를 구축하고 한 페이지씩 점진적으로 작업했어요. (Load Balancer → NextJs or Flask Server)
결과
  • 큰 리소스를 들이지 않고 점진적으로 마이그레이션을 할 수 있는 출발점을 만들었어요.
  • 혼자서 하나의 프로젝트를 작업하다가 3명의 FE가 같이 해본 작업이었어요. 혼자하는 작업과 여러 동료와 같이 작업하면서 겪는 문제들을 통해서 교훈들이 있었어요.
  • 프론트엔드 개발자는 본인의 구현을 세심하게 체크할 줄 아는 사람이 협업하기 좋은 동료라는 생각을 하게 되었어요.
아파트멘터리 17.09 ~ 18.12
직무
Software Engineer
담당제품
랜딩페이지, 커머스 웹, 커머스 백오피스, 상품 정보 크롤링 크롬 익스텐션
기술스택
javascript, react, redux, nodejs, express, mongodb
담당 업무

아파트멘터리에서 Software Engineer로 커머스 웹, 커머스 백오피스, 상품 정보 크롤링 크롬 익스텐션 개발을 담당했어요.

주요 프로젝트
[상품 정보 크롤링 크롬 익스텐션]
배경
  • 타사의 제품을 폐쇄몰 형태로 내부에서 판매하려고자하는 니즈가 있었어요.
  • 커머스 관련 기능을 내부적으로 구현할 수는 있지만 상품 등록과 같은 과정이 필수였어요.
  • API 연동, csv로 데이터 공유와 같은 지원을 받을 수 없었고, 파트너 웹사이트에서 내용을 그대로 가져가서 사용하라고 했고 따로 지원이 없었어요.
접근
  • 크롬 익스텐션을 개발해서 파트너사 상품 상세 페이지에서 활성화되도록했고, 원클릭으로 우리 DB에 채울 수 있는 정보들을 웹사이트에서 크롤링할 수 있는 기능을 추가했어요.
결과
  • 운영을 맡고 있는 담당자가 직접 기록할 필요가 없었고, 크롬 익스텐션을 사용해서 일부 수정만 해서 빠르게 제품을 등록할 수 있는 프로세스를 만들 수 있었어요.
  • 비즈니스적으로 폐쇄몰이 성공하지 못해서 오랫동안 해당 프로젝트를 유지하지 못했어요. 점진적인 개발 및 배포로 비즈니스 성공 가능성을 체크가 필요했어요.
  • 크롬 익스텐션 개발에 대한 경험을 할 수 있었고, 문제를 푸는 방식의 다양성을 넓힐 수 있는 기회였어요.
  • 한계점으로 초기 DB에 적재하는 작업은 가능했지만, 지속적으로 변경되는 상품의 정보를 Sync 시키는 작업까지는 고려하지 못했었어요.
스포카 15.12 ~ 17.08
직무
Brand Success Manager, Business Intelligence Developer
담당제품
전사 데이터 대시보드 구성
기술스택
python, flask, sql
담당 업무

스포카에서 Brand Success Manager와 Business Intelligence Developer로 일하며 데이터 기반 의사결정 체계를 구축했어요.

주요 프로젝트
[전사 대시보드 제작]
배경
  • 직감이나 경험 기반의 의사결정이 좋은 의사결정의 병목이 되고 있었어요.
  • 전 직군의 데이터 가시성에 대한 중요성이 대두되었어요.
  • 테크 직군이 아닌 경우에 데이터를 얻기 위해서는 개발자를 무조건 통해서 얻어야하는 문제가 있었어요.
접근
  • 직접 데이터 시각화 제품을 개발하기보다 기존 SaaS(Periscope)를 활용하여 데이터 대시보드를 만들었어요.
  • 동료들의 요청 혹은 주도적으로 아이디어를 발굴하여 관련 데이터들을 전사 직원들에게 제공했어요. (SQL, 외부 데이터소스 연동)
결과
  • 내부 동료들이 서비스에 대한 기본 지표들에 쉽게 접근할 수 있어졌어요.
  • 정기적으로 경영진들에게 발굴한 데이터 인사이트를 공유하는 시간을 가졌어요.
  • 데이터에 대한 가시성은 좋은 의사결정을 위해서는 정말로 중요한 부분이라는 것을 처절하게 깨달은 순간이었어요.
  • 초기 목표와는 달리 전 직군의 데이터에 대한 가시성과 접근성을 기본 지표 이상으로 확대하지 못한 한계점이 있었어요.

Communities

Presentations

Lecture

Education

경희대학교

  • (10.03 ~ 16.02) 경영학 / 한국어학