포지션 상세
■ 이런 포지션이에요
킵그로우는 5천 곳이 넘는 유료 쇼핑몰이 매일 쓰는 서비스입니다. 이 자리는 그 서비스를 받치는 기술 기반의 방향을 정하는 시니어 엔지니어 자리입니다. 아키텍처와 신뢰성 체계, 여러 세대가 섞인 스택의 전환 순서를 설계하고, 신상품의 기술 설계를 주도합니다.
대표 상품인 1초 회원가입 하나만 해도 수천 개 쇼핑몰에 심는 스크립트, 쇼핑몰 운영자가 쓰는 웹 Admin, 백엔드 API, 카카오싱크·네이버 로그인과 쇼핑몰 솔루션 연동에 걸쳐 있습니다. 큰 회사라면 여러 팀이 나눠 볼 범위를 한 사람이 처음부터 끝까지 보고, 그 전체 그림 위에서 기술 결정을 내립니다.
적은 인원이 이 범위를 감당하는 방법은 AI입니다. 개발 도구는 Claude Code로 통일했고, 커밋 대부분을 AI와 함께 씁니다. 팀 공용 하네스에는 운영 지식과 안전장치가 쌓여 있고, 매일 오전 11시에는 AI 루틴이 워크봇 실패를 요약해 올립니다.
현재 킵그로우의 운영 안정성은 사람의 대응 속도에 기대고 있는 상황으로, 운영 대응도 동료 개발자와 나눠서 맡게 됩니다. 이 자리의 목표는 그 대응이 반복되지 않는 구조를 만드는 것입니다. 외부 플랫폼은 정책과 화면, 인증 방식을 예고 없이 바꾸고, 코드에는 여러 세대가 섞여 있습니다. 그래서 정해진 길을 따르기보다 방향을 직접 세워야 하는 자리이고, 책임이 큰 만큼 바꿀 수 있는 것도 많습니다.
■ 킵그로우는 이런 곳이에요
킵그로우는 온라인 쇼핑몰을 위한 ‘AI 직원'을 만듭니다. 고객은 카페24·아임웹·메이크샵·고도몰로 자사몰을 운영하거나 네이버 스마트스토어를 하는 쇼핑몰이 고객인데, 마케터나 개발자를 따로 두기 어려운 작은 팀이 매일 손으로 하던 일을 이 ‘AI 직원'이 대신합니다.
회원은 ‘1초 회원가입'이 모으고, 재구매는 카카오톡 메시지가 유도하고, 광고와 리뷰, SNS 운영은 네이버·인스타그램·메타를 다루는 AI 매니저가 맡습니다. 이렇게 쇼핑몰 운영을 대신 돌려주는 서비스를 유료로 구독하는 곳이 5천 곳을 넘고, 봇이 쇼핑몰 대신 처리하는 작업은 한 달에 10만 건이 넘습니다.
그중 대표가 ‘1초 회원가입'입니다. 결제 직전 가입 폼 앞에서 떠나던 고객이 카카오·네이버 계정 동의 한 번으로 가입과 배송 정보 입력을 끝내고 바로 구매로 넘어가도록 돕고, 지금 수천 개 쇼핑몰의 가입 화면에서 이 스크립트가 돌아갑니다.
킵그로우는 이미 자리 잡은 서비스입니다. 이제는 그 기반을 발판 삼아 다음 상품과 새로운 성장으로 나아가고 있습니다.
1. 킵그로우의 기술 방향을 정합니다.
20개가 넘는 서비스 레포가 Java·Spring Boot, Python, JavaScript(React·Next.js)로 나뉘어 있고, 같은 언어 안에서도 런타임과 프레임워크의 세대가 다릅니다. 배포 경로도 CodeDeploy 기반 EC2, Terraform으로 관리하는 EKS, AMI 베이크 방식으로 갈라져 있습니다. 서비스 간 의존성과 운영 리스크를 진단해 런타임·프레임워크 업그레이드와 배포 파이프라인 표준화의 순서를 정하고, 운영 중인 서비스를 멈추지 않고 단계적으로 옮겨 갑니다.
2. 외부 플랫폼 위에서도 무너지지 않는 신뢰성 체계를 설계합니다.
킵그로우가 연동하는 외부 플랫폼은 카페24·메이크샵·고도몰·아임웹 같은 쇼핑몰 솔루션, 네이버(스마트스토어·커머스 API·검색광고·네이버 로그인), 카카오(카카오싱크·알림톡·친구톡·카카오 비즈니스), Meta(Facebook·Instagram)입니다. 연동 방식은 세 갈래이고, 갈래마다 깨지는 지점이 다릅니다.
- 공식 API 연동 (예: 메타 구매전환 추적 AI 매니저): OAuth 토큰의 수명 주기, 호출 한도, API 버전 변경
- 브라우저 자동화 (예: 네이버 리뷰 노출 AI 매니저): Playwright 기반 봇의 로그인 세션과 인증 상태, 예고 없는 화면 변경
- 임베디드 스크립트(예: 1초 회원가입): 쇼핑몰마다 다른 스킨과 DOM에서의 호환성, 플랫폼별 번들 배포와 롤백
세 갈래 모두에 적용할 신뢰성 지표와 알림 기준, 실패 유형 분류와 재시도·격리 정책, 사람 손을 거치지 않는 인증·세션 관리 방식을 설계합니다.
3. 신상품의 기술 설계를 주도합니다.
신상품 하나는 쇼핑몰에 주입되는 클라이언트 스크립트, 운영자용 웹 Admin(React·Next.js), 백엔드 API(Java·Spring Boot), 외부 플랫폼 연동, SQS·Redis 기반 비동기 처리에 걸쳐 있습니다. 기획 단계에서 기술 타당성과 운영 비용을 검토하고, 서비스 경계와 데이터 모델, 연동 방식을 설계해 직접 구현합니다.
4. AI로 일하는 방식을 설계합니다.
Claude Code를 표준 개발 도구로 쓰고, 팀 하네스(스킬·서브에이전트·hook 기반 안전장치)로 운영 지식과 개발 컨벤션을 코드처럼 버전 관리합니다. 워크봇 실패 요약과 매니저 초대 재확인 같은 반복 운영을 AI 워크플로로 옮겨 왔고, 어디까지 자동화하고 어디부터 사람이 판단할지의 경계를 동료 개발자와 함께 설계합니다.
결정 권한과 팀 구성
• 직접 결정합니다: 아키텍처와 신뢰성 체계, 반복 운영을 무엇으로 자동화할지, 운영에서 AI와 사람의 역할 경계, 맡은 신상품의 기술 설계를 직접 정합니다.
• 함께 일하는 사람: 킵그로우 사업부는 책임리더, 기획운영, 개발, 마케팅(제휴)으로 구성된 팀입니다. 업무와 일정은 책임리더에게 보고하고, 성장과 평가는 개발 챕터 리드가 맡습니다. 의사결정은 책임리더와 대표 두 단계 안에서 끝나기 때문에 사람을 관리하는 자리가 아니라 기술 방향을 이끄는 시니어 엔지니어 자리입니다.
• 합의해 결정합니다: 인프라와 기술 스택의 방향은 직접 설계해 제안하고, 개발 챕터와 합의해 결정합니다. 일정과 우선순위는 책임리더가 최종 결정하고, 이 자리는 기획 단계부터 기술 근거를 내어 결정에 참여합니다.
입사 후 첫 3개월은 아래 흐름으로 자리 잡습니다.
• 1개월(진단): 서비스 간 의존성, 배포 경로, 장애·실패 이력을 파악하고, 기술 부채와 운영 리스크를 정리한 진단 문서를 냅니다.
• 2개월(방향): 신뢰성 지표와 스택 전환의 우선순위를 정해 사업부·개발 챕터와 합의하고, 첫 구조 개선에 착수합니다.
• 3개월(첫 결과): 첫 개선의 효과를 지표로 보고합니다.
6개월 뒤에는 합의한 개선 로드맵의 첫 단계가 적용돼 있는 상태를 목표로 합니다. 그 결과로 외부 플랫폼이 바뀌어도 워크봇 전체 실행 실패율을 1% 이하로 유지합니다.
• 6년 이상의 실무 경력
• 여러 서비스로 구성된 시스템에서 서비스 경계와 데이터 흐름을 설계하고, 기술 선택을 주도해 보신 분
• 운영 중인 서비스의 런타임·프레임워크 업그레이드나 아키텍처 전환을 무중단으로 진행해 보신 분
• 장애 회고를 바탕으로 관측(로그·메트릭·트레이스), 알림, 복구 절차를 체계로 만들어 보신 분
• Java·Spring Boot 서비스를 AWS 위에서 운영하고, Kubernetes(Amazon EKS 등)와 Terraform 같은 IaC로 인프라를 직접 바꾸고 배포해 보신 분
* 본 포지션은 포트폴리오 제출이 필수입니다.
킵그로우는 5천 곳이 넘는 유료 쇼핑몰이 매일 쓰는 서비스입니다. 이 자리는 그 서비스를 받치는 기술 기반의 방향을 정하는 시니어 엔지니어 자리입니다. 아키텍처와 신뢰성 체계, 여러 세대가 섞인 스택의 전환 순서를 설계하고, 신상품의 기술 설계를 주도합니다.
대표 상품인 1초 회원가입 하나만 해도 수천 개 쇼핑몰에 심는 스크립트, 쇼핑몰 운영자가 쓰는 웹 Admin, 백엔드 API, 카카오싱크·네이버 로그인과 쇼핑몰 솔루션 연동에 걸쳐 있습니다. 큰 회사라면 여러 팀이 나눠 볼 범위를 한 사람이 처음부터 끝까지 보고, 그 전체 그림 위에서 기술 결정을 내립니다.
적은 인원이 이 범위를 감당하는 방법은 AI입니다. 개발 도구는 Claude Code로 통일했고, 커밋 대부분을 AI와 함께 씁니다. 팀 공용 하네스에는 운영 지식과 안전장치가 쌓여 있고, 매일 오전 11시에는 AI 루틴이 워크봇 실패를 요약해 올립니다.
현재 킵그로우의 운영 안정성은 사람의 대응 속도에 기대고 있는 상황으로, 운영 대응도 동료 개발자와 나눠서 맡게 됩니다. 이 자리의 목표는 그 대응이 반복되지 않는 구조를 만드는 것입니다. 외부 플랫폼은 정책과 화면, 인증 방식을 예고 없이 바꾸고, 코드에는 여러 세대가 섞여 있습니다. 그래서 정해진 길을 따르기보다 방향을 직접 세워야 하는 자리이고, 책임이 큰 만큼 바꿀 수 있는 것도 많습니다.
■ 킵그로우는 이런 곳이에요
킵그로우는 온라인 쇼핑몰을 위한 ‘AI 직원'을 만듭니다. 고객은 카페24·아임웹·메이크샵·고도몰로 자사몰을 운영하거나 네이버 스마트스토어를 하는 쇼핑몰이 고객인데, 마케터나 개발자를 따로 두기 어려운 작은 팀이 매일 손으로 하던 일을 이 ‘AI 직원'이 대신합니다.
회원은 ‘1초 회원가입'이 모으고, 재구매는 카카오톡 메시지가 유도하고, 광고와 리뷰, SNS 운영은 네이버·인스타그램·메타를 다루는 AI 매니저가 맡습니다. 이렇게 쇼핑몰 운영을 대신 돌려주는 서비스를 유료로 구독하는 곳이 5천 곳을 넘고, 봇이 쇼핑몰 대신 처리하는 작업은 한 달에 10만 건이 넘습니다.
그중 대표가 ‘1초 회원가입'입니다. 결제 직전 가입 폼 앞에서 떠나던 고객이 카카오·네이버 계정 동의 한 번으로 가입과 배송 정보 입력을 끝내고 바로 구매로 넘어가도록 돕고, 지금 수천 개 쇼핑몰의 가입 화면에서 이 스크립트가 돌아갑니다.
킵그로우는 이미 자리 잡은 서비스입니다. 이제는 그 기반을 발판 삼아 다음 상품과 새로운 성장으로 나아가고 있습니다.
주요업무
■ 이런 일을 함께 해요1. 킵그로우의 기술 방향을 정합니다.
20개가 넘는 서비스 레포가 Java·Spring Boot, Python, JavaScript(React·Next.js)로 나뉘어 있고, 같은 언어 안에서도 런타임과 프레임워크의 세대가 다릅니다. 배포 경로도 CodeDeploy 기반 EC2, Terraform으로 관리하는 EKS, AMI 베이크 방식으로 갈라져 있습니다. 서비스 간 의존성과 운영 리스크를 진단해 런타임·프레임워크 업그레이드와 배포 파이프라인 표준화의 순서를 정하고, 운영 중인 서비스를 멈추지 않고 단계적으로 옮겨 갑니다.
2. 외부 플랫폼 위에서도 무너지지 않는 신뢰성 체계를 설계합니다.
킵그로우가 연동하는 외부 플랫폼은 카페24·메이크샵·고도몰·아임웹 같은 쇼핑몰 솔루션, 네이버(스마트스토어·커머스 API·검색광고·네이버 로그인), 카카오(카카오싱크·알림톡·친구톡·카카오 비즈니스), Meta(Facebook·Instagram)입니다. 연동 방식은 세 갈래이고, 갈래마다 깨지는 지점이 다릅니다.
- 공식 API 연동 (예: 메타 구매전환 추적 AI 매니저): OAuth 토큰의 수명 주기, 호출 한도, API 버전 변경
- 브라우저 자동화 (예: 네이버 리뷰 노출 AI 매니저): Playwright 기반 봇의 로그인 세션과 인증 상태, 예고 없는 화면 변경
- 임베디드 스크립트(예: 1초 회원가입): 쇼핑몰마다 다른 스킨과 DOM에서의 호환성, 플랫폼별 번들 배포와 롤백
세 갈래 모두에 적용할 신뢰성 지표와 알림 기준, 실패 유형 분류와 재시도·격리 정책, 사람 손을 거치지 않는 인증·세션 관리 방식을 설계합니다.
3. 신상품의 기술 설계를 주도합니다.
신상품 하나는 쇼핑몰에 주입되는 클라이언트 스크립트, 운영자용 웹 Admin(React·Next.js), 백엔드 API(Java·Spring Boot), 외부 플랫폼 연동, SQS·Redis 기반 비동기 처리에 걸쳐 있습니다. 기획 단계에서 기술 타당성과 운영 비용을 검토하고, 서비스 경계와 데이터 모델, 연동 방식을 설계해 직접 구현합니다.
4. AI로 일하는 방식을 설계합니다.
Claude Code를 표준 개발 도구로 쓰고, 팀 하네스(스킬·서브에이전트·hook 기반 안전장치)로 운영 지식과 개발 컨벤션을 코드처럼 버전 관리합니다. 워크봇 실패 요약과 매니저 초대 재확인 같은 반복 운영을 AI 워크플로로 옮겨 왔고, 어디까지 자동화하고 어디부터 사람이 판단할지의 경계를 동료 개발자와 함께 설계합니다.
결정 권한과 팀 구성
• 직접 결정합니다: 아키텍처와 신뢰성 체계, 반복 운영을 무엇으로 자동화할지, 운영에서 AI와 사람의 역할 경계, 맡은 신상품의 기술 설계를 직접 정합니다.
• 함께 일하는 사람: 킵그로우 사업부는 책임리더, 기획운영, 개발, 마케팅(제휴)으로 구성된 팀입니다. 업무와 일정은 책임리더에게 보고하고, 성장과 평가는 개발 챕터 리드가 맡습니다. 의사결정은 책임리더와 대표 두 단계 안에서 끝나기 때문에 사람을 관리하는 자리가 아니라 기술 방향을 이끄는 시니어 엔지니어 자리입니다.
• 합의해 결정합니다: 인프라와 기술 스택의 방향은 직접 설계해 제안하고, 개발 챕터와 합의해 결정합니다. 일정과 우선순위는 책임리더가 최종 결정하고, 이 자리는 기획 단계부터 기술 근거를 내어 결정에 참여합니다.
입사 후 첫 3개월은 아래 흐름으로 자리 잡습니다.
• 1개월(진단): 서비스 간 의존성, 배포 경로, 장애·실패 이력을 파악하고, 기술 부채와 운영 리스크를 정리한 진단 문서를 냅니다.
• 2개월(방향): 신뢰성 지표와 스택 전환의 우선순위를 정해 사업부·개발 챕터와 합의하고, 첫 구조 개선에 착수합니다.
• 3개월(첫 결과): 첫 개선의 효과를 지표로 보고합니다.
6개월 뒤에는 합의한 개선 로드맵의 첫 단계가 적용돼 있는 상태를 목표로 합니다. 그 결과로 외부 플랫폼이 바뀌어도 워크봇 전체 실행 실패율을 1% 이하로 유지합니다.
자격요건
■ 이런 분을 찾아요 (필수)• 6년 이상의 실무 경력
• 여러 서비스로 구성된 시스템에서 서비스 경계와 데이터 흐름을 설계하고, 기술 선택을 주도해 보신 분
• 운영 중인 서비스의 런타임·프레임워크 업그레이드나 아키텍처 전환을 무중단으로 진행해 보신 분
• 장애 회고를 바탕으로 관측(로그·메트릭·트레이스), 알림, 복구 절차를 체계로 만들어 보신 분
• Java·Spring Boot 서비스를 AWS 위에서 운영하고, Kubernetes(Amazon EKS 등)와 Terraform 같은 IaC로 인프라를 직접 바꾸고 배포해 보신 분
* 본 포지션은 포트폴리오 제출이 필수입니다.
