소타텍코리아
경력근거: 원격 개발팀(ODC)과의 기술 협업 및 개발 업무 조율
※ 실제 산출물이 아닌 AI 예측 시안입니다.
소타텍코리아는 베트남 IT 아웃소싱 기업 SotaTek 의 한국 법인이에요. 한국 기업이 맡기는 웹·모바일 앱·백엔드 개발을 한국어와 영어가 되는 PM 이 받아, 베트남 개발팀·서울 인력·고객사 상주 인력 가운데 하나로 프로젝트나 전담 인력(ODC) 단위로 수행해요.
공고는 이 자리가 할 일로 '고객 요구사항 분석부터 설계, 개발, 배포, 운영까지 End-to-End 업무 수행'과 '원격 개발팀(ODC)과의 기술 협업 및 개발 업무 조율'을 꼽아요. 고객사에 상주하는 사람이 고객과 요구사항을 정하고 바꾸는 동안 개발 일부를 원격 개발팀(ODC)이 맡으니, 요구사항이 바뀐 사실이 개발 작업까지 넘어가야 해요. 바뀌기 전 내용으로 시작한 작업이 끝나고 운영에 배포까지 되면, 작업과 배포 기록만 봐서는 바뀐 요구사항도 다 된 것처럼 보여요.
공고는 원격 개발팀(ODC)과 기술 협업을 하고 개발 업무를 조율하는 일을 이 자리의 담당업무로 적었어요. 우대사항에도 고객사 상주 프로젝트나 원격 개발팀(ODC)과 협업한 경험을 꼽았어요.
공고는 고객 요구사항 분석부터 설계, 개발, 배포, 운영까지 처음부터 끝까지 맡는 일을 담당업무로 적었어요. 자격요건에는 고객과 직접 소통하며 요구사항을 기술적인 해결 방안으로 구체화할 수 있는 사람을 꼽았어요.
근무형태는 자사 사무실 또는 고객사 상주(온사이트)이고 프로젝트에 따라 달라요. 담당업무로는 관리자 시스템과 모바일 서비스 백엔드 개발을 적었어요.
고객사에 상주하는 FDE 엔지니어가 고객 담당자·ODC 리더와 매주 하는 회의 전에 여는 관리자 페이지예요. 이번 개발 범위의 요구사항마다 ODC 가 개발을 맡았는지, 마지막으로 바뀐 내용까지 개발에 넘어갔는지, 개발이 끝났는지, 운영에 배포됐는지 알려 줘요. 그래서 회의에서 고객에게 요구사항마다 어디까지 됐는지 바로 말할 수 있어요. 받은 데이터를 담을 DB 설계와 기술·구조는 지원자가 정해요.
고객사에 상주하며 고객과 요구사항을 정리하고 직접 개발도 하면서, 원격 개발팀(ODC)에 맡긴 개발을 조율하는 FDE 엔지니어예요. 요구사항을 바꾼 기록과 ODC 의 개발 작업, 배포 기록이 서로 다른 곳에 남으면 주간 회의 전에 요구사항마다 어디까지 됐는지 하나씩 맞춰 봐야 하고, 그러다 바뀐 요구사항이 개발에 넘어가지 않은 걸 놓치게 돼요.
FDE 엔지니어가 고객 담당자·ODC 리더와 매주 하는 회의예요. 한 행이 회의 한 번이고 meeting_id 가 키예요. phase 는 그 회의에서 보는 개발 범위로 requirements.phase 와 같은 값으로 적혀 있고, 회의 하나는 개발 범위 하나만 봐요. held_at 은 회의 일정에 잡힌 시작 시각(한국 시간)이고, 이 기능이 '지금'으로 삼는 시각이에요. 이 데이터는 마지막 회의가 있던 2026년 10월 28일 18시까지의 기록이라, 마지막 회의가 시작된 뒤에 생긴 요구사항 기록·작업·배포도 들어 있어요. 큰 데이터는 2024년 10월부터 2026년 10월 28일까지 매주 수요일에 열린 회의 전부이고, 시작용은 그 가운데 2026-Q4 개발 범위의 회의를 같은 ID·같은 값으로 잘라 낸 것이에요.
전체 4행 가운데 앞 4행이에요.
| meeting_id | phase | held_at |
|---|---|---|
| MT-0106 | 2026-Q4 | 2026-10-07T10:00:00+09:00 |
| MT-0107 | 2026-Q4 | 2026-10-14T10:00:00+09:00 |
| MT-0108 | 2026-Q4 | 2026-10-21T10:00:00+09:00 |
| MT-0109 | 2026-Q4 | 2026-10-28T10:00:00+09:00 |
4행 전부를 JSON 파일 하나로 받을 수 있어요.
같은 형식으로 만든 109행이에요. 위 데이터가 이 안에 그대로 들어 있어요(한 줄에 한 행, gzip 압축).
미리보기와 내려받는 데이터 모두 이 형식(JSON Schema)을 따라요.
{
"type": "object",
"description": "주간 회의 한 번. 키는 meeting_id.",
"additionalProperties": false,
"required": [
"meeting_id",
"phase",
"held_at"
],
"properties": {
"meeting_id": {
"type": "string",
"pattern": "^MT-[0-9]{4}$",
"description": "회의 번호. 이 표의 키예요."
},
"phase": {
"type": "string",
"pattern": "^[0-9]{4}-Q[1-4]$",
"description": "이 회의에서 보는 개발 범위(분기). requirements.phase 와 같은 값으로 적혀 있고, 회의 하나는 개발 범위 하나만 봐요."
},
"held_at": {
"type": "string",
"format": "date-time",
"description": "회의 일정에 잡힌 시작 시각. 한국 시간(+09:00) ISO 8601, 초 단위. 이 기능이 '지금'으로 삼는 시각이에요."
}
}
}고객과 정한 요구사항 목록이에요. 이 표의 요구사항은 모두 ODC 에 개발을 맡기기로 한 것이에요. 한 행이 요구사항 하나이고 req_id 가 키예요. phase 는 고객과 이 요구사항을 넣기로 합의한 분기 개발 범위(예: 2026-Q4)이고, 요구사항 하나는 개발 범위 하나에만 속해요. area 는 관리자 시스템과 모바일 서비스 백엔드 가운데 어느 쪽 기능인지, title 은 요구사항 이름이에요. 내용이 바뀌어도 이름은 그대로이고, 언제 정했고 어떻게 바뀌었는지는 requirement_changes 에 있어요. 이 데이터에서는 개발 범위가 끝난 뒤 더 바꾸고 싶은 내용이 생기면 다음 범위의 새 요구사항으로 들어와요. 이름 뒷부분이 같은 다른 요구사항(회원 목록 엑셀 내려받기와 주문 목록 엑셀 내려받기 같은)과, 마지막 회의가 시작된 뒤에야 처음 정한 요구사항이 들어 있어요. 큰 데이터는 2024-Q4 부터 2026-Q4 까지 9개 개발 범위의 요구사항 전부이고, 시작용은 그 가운데 2026-Q4 요구사항 전부를 같은 ID·같은 값으로 잘라 낸 것이에요.
전체 17행 가운데 앞 5행이에요.
| req_id | phase | area | title |
|---|---|---|---|
| REQ-0419 | 2026-Q4 | 관리자 시스템 | 상품 목록 검색 조건 추가 |
| REQ-0420 | 2026-Q4 | 관리자 시스템 | 주문 목록 엑셀 내려받기 |
| REQ-0421 | 2026-Q4 | 관리자 시스템 | 회원 목록 엑셀 내려받기 |
| REQ-0422 | 2026-Q4 | 모바일 서비스 백엔드 | 로그인 토큰 재발급 API |
| REQ-0423 | 2026-Q4 | 관리자 시스템 | 공지사항 예약 게시 |
17행 전부를 JSON 파일 하나로 받을 수 있어요.
같은 형식으로 만든 435행이에요. 위 데이터가 이 안에 그대로 들어 있어요(한 줄에 한 행, gzip 압축).
미리보기와 내려받는 데이터 모두 이 형식(JSON Schema)을 따라요.
{
"type": "object",
"description": "고객과 정한 요구사항 하나. 키는 req_id.",
"additionalProperties": false,
"required": [
"req_id",
"phase",
"area",
"title"
],
"properties": {
"req_id": {
"type": "string",
"pattern": "^REQ-[0-9]{4}$",
"description": "요구사항 번호. 이 표의 키예요."
},
"phase": {
"type": "string",
"pattern": "^[0-9]{4}-Q[1-4]$",
"description": "고객과 이 요구사항을 넣기로 합의한 분기 개발 범위. 요구사항 하나는 개발 범위 하나에만 속해요."
},
"area": {
"type": "string",
"enum": [
"관리자 시스템",
"모바일 서비스 백엔드"
],
"description": "이 요구사항이 관리자 시스템 기능인지 모바일 서비스 백엔드 기능인지."
},
"title": {
"type": "string",
"description": "요구사항 이름. 내용이 바뀌어도 이름은 그대로이고, 같은 이름의 다른 요구사항은 없어요."
}
}
}요구사항을 처음 정하거나 바꿀 때마다 남긴 기록이에요. 한 행이 기록 하나이고 change_id 가 키예요. req_id 는 requirements.req_id 를 가리키고, 요구사항마다 가장 이른 행이 처음 정한 기록, 그 뒤 행이 바꾼 기록이에요. summary 는 그때 정하거나 바꾼 내용 한 줄이에요. changed_at 은 FDE 엔지니어가 그 내용을 협업 도구에 올린 시각으로, odc_tasks 의 시각과 같은 협업 도구 서버가 한국 시간(+09:00)으로 찍었어요. 한 요구사항의 기록끼리 시각이 같은 경우는 없고, 그 요구사항 작업의 시작 시각과 같은 경우도 없어요. 작업을 시작하기 전에 바뀐 요구사항, 작업을 시작한 뒤에 바뀐 요구사항, 바뀌기 전 내용이 이미 운영에 배포된 뒤 바뀐 요구사항, 마지막 회의가 시작된 뒤에 바뀌거나 처음 정한 요구사항이 들어 있어요. 큰 데이터는 9개 개발 범위 요구사항의 기록 전부이고, 시작용은 2026-Q4 요구사항의 기록 전부예요.
전체 22행 가운데 앞 5행이에요.
| change_id | req_id | changed_at | summary |
|---|---|---|---|
| CH-00561 | REQ-0419 | 2026-10-01T09:40:48+09:00 | 상품 목록 검색 조건에 판매 상태와 카테고리 추가 |
| CH-00562 | REQ-0420 | 2026-10-02T14:20:32+09:00 | 주문 목록을 엑셀 파일로 내려받기 |
| CH-00563 | REQ-0420 | 2026-10-05T11:05:41+09:00 | 내려받는 기간 최대 3개월 |
| CH-00564 | REQ-0421 | 2026-10-05T15:30:40+09:00 | 회원 목록을 엑셀 파일로 내려받기 |
| CH-00565 | REQ-0422 | 2026-10-06T11:00:35+09:00 | 만료된 로그인 토큰을 재발급해 주는 API |
22행 전부를 JSON 파일 하나로 받을 수 있어요.
같은 형식으로 만든 582행이에요. 위 데이터가 이 안에 그대로 들어 있어요(한 줄에 한 행, gzip 압축).
미리보기와 내려받는 데이터 모두 이 형식(JSON Schema)을 따라요.
{
"type": "object",
"description": "요구사항을 처음 정하거나 바꾼 기록 하나. 키는 change_id.",
"additionalProperties": false,
"required": [
"change_id",
"req_id",
"changed_at",
"summary"
],
"properties": {
"change_id": {
"type": "string",
"pattern": "^CH-[0-9]{5}$",
"description": "기록 번호. 이 표의 키예요."
},
"req_id": {
"type": "string",
"pattern": "^REQ-[0-9]{4}$",
"description": "정하거나 바꾼 요구사항. requirements.req_id 를 가리켜요."
},
"changed_at": {
"type": "string",
"format": "date-time",
"description": "FDE 엔지니어가 정하거나 바꾼 내용을 협업 도구에 올린 시각. 한국 시간(+09:00) ISO 8601, 초 단위. odc_tasks 의 시각과 같은 협업 도구 서버의 시계예요."
},
"summary": {
"type": "string",
"description": "그때 정하거나 바꾼 내용 한 줄."
}
}
}원격 개발팀(ODC)이 요구사항을 맡아 시작한 개발 작업이에요. 한 행이 작업 하나이고 task_id 가 키예요. req_id 는 requirements.req_id 를 가리키고, 작업 하나는 요구사항 하나에만 속하며 요구사항 하나에 작업이 여러 개일 수 있어요. started_at 은 ODC 개발자가 작업을 시작한 시각, done_at 은 개발을 끝냈다고 표시한 시각이고, 둘 다 협업 도구 서버가 한국 시간(+09:00)으로 찍었어요. 베트남 팀이 남긴 기록도 한국 시간으로 적혀 있어요. done_at 이 비어 있으면 데이터를 뽑은 2026년 10월 28일 18시까지 끝나지 않은 작업이에요. 요구사항이 바뀌기 전에 시작한 작업과 바뀐 뒤 새로 시작한 작업, 한 요구사항에서 하나는 끝났고 하나는 진행 중인 작업, 바뀌기 전 내용으로 끝냈지만 운영에 나가지 않은 작업, 마지막 회의가 시작된 뒤에 시작하거나 끝난 작업이 들어 있어요. 큰 데이터는 9개 개발 범위의 작업 전부이고, 시작용은 2026-Q4 요구사항의 작업 전부예요.
전체 19행 가운데 앞 5행이에요.
| task_id | req_id | title | started_at | done_at |
|---|---|---|---|---|
| TK-00625 | REQ-0419 | 상품 목록 검색 조건 구현 | 2026-10-02T10:15:53+09:00 | 2026-10-06T17:30:11+09:00 |
| TK-00626 | REQ-0420 | 주문 목록 엑셀 내려받기 구현 | 2026-10-06T09:50:23+09:00 | 2026-10-12T16:40:44+09:00 |
| TK-00627 | REQ-0421 | 회원 목록 엑셀 내려받기 구현 | 2026-10-06T10:30:34+09:00 | 2026-10-12T18:10:16+09:00 |
| TK-00628 | REQ-0422 | 로그인 토큰 재발급 API 구현 | 2026-10-07T10:00:33+09:00 | 2026-10-08T18:00:10+09:00 |
| TK-00629 | REQ-0421 | 회원 목록 엑셀 화면 연동 | 2026-10-08T09:40:11+09:00 | 2026-10-13T15:20:22+09:00 |
19행 전부를 JSON 파일 하나로 받을 수 있어요.
같은 형식으로 만든 643행이에요. 위 데이터가 이 안에 그대로 들어 있어요(한 줄에 한 행, gzip 압축).
미리보기와 내려받는 데이터 모두 이 형식(JSON Schema)을 따라요.
{
"type": "object",
"description": "원격 개발팀(ODC)이 맡아 시작한 개발 작업 하나. 키는 task_id.",
"additionalProperties": false,
"required": [
"task_id",
"req_id",
"title",
"started_at",
"done_at"
],
"properties": {
"task_id": {
"type": "string",
"pattern": "^TK-[0-9]{5}$",
"description": "작업 번호. 이 표의 키예요."
},
"req_id": {
"type": "string",
"pattern": "^REQ-[0-9]{4}$",
"description": "이 작업이 맡은 요구사항. requirements.req_id 를 가리켜요. 작업 하나는 요구사항 하나에만 속해요."
},
"title": {
"type": "string",
"description": "작업 이름."
},
"started_at": {
"type": "string",
"format": "date-time",
"description": "ODC 개발자가 작업을 시작한 시각. 한국 시간(+09:00) ISO 8601, 초 단위. 협업 도구 서버의 시계이고, 베트남 팀이 남긴 기록도 한국 시간으로 적혀 있어요."
},
"done_at": {
"type": [
"string",
"null"
],
"format": "date-time",
"description": "ODC 개발자가 개발을 끝냈다고 표시한 시각. 한국 시간(+09:00) ISO 8601, 초 단위. 비어 있으면 데이터를 뽑은 2026-10-28 18:00 까지 끝나지 않은 작업이에요."
}
}
}배포 도구가 작업을 스테이징이나 운영 환경에 배포한 기록이에요. 배포 실행 한 번에 작업 여러 개가 함께 실릴 수 있어서, 한 행은 그 실행에 실린 작업 하나이고 run_id 와 task_id 묶음이 키예요. task_id 는 odc_tasks.task_id 를 가리키고, 같은 run_id 의 행은 env·result·deployed_at 이 모두 같아요. env 는 staging(스테이징)이나 production(운영), result 는 succeeded(배포가 끝까지 됨)나 failed(배포가 실패로 끝남)예요. deployed_at 은 배포 도구가 실행을 마친 시각으로 한국 시간(+09:00)이고, 협업 도구의 시각과 같은 기준으로 견줄 수 있어요. 스테이징에만 배포된 작업, 끝났는데 배포 기록이 하나도 없는 작업, 운영 배포가 실패로 끝난 뒤 다시 배포한 작업, 마지막 회의 시작 바로 앞이나 뒤에 운영에 배포된 작업이 들어 있어요. 실행 하나에 서로 다른 개발 범위의 작업이 함께 실린 경우는 없어요. 큰 데이터는 9개 개발 범위 작업의 배포 기록 전부이고, 시작용은 2026-Q4 작업의 배포 기록 전부예요.
전체 28행 가운데 앞 5행이에요.
| run_id | task_id | env | result | deployed_at |
|---|---|---|---|---|
| RUN-00744 | TK-00625 | staging | succeeded | 2026-10-07T11:00:00+09:00 |
| RUN-00745 | TK-00625 | production | succeeded | 2026-10-08T21:00:00+09:00 |
| RUN-00746 | TK-00628 | staging | succeeded | 2026-10-12T11:00:00+09:00 |
| RUN-00747 | TK-00626 | staging | succeeded | 2026-10-13T11:00:00+09:00 |
| RUN-00748 | TK-00627 | staging | succeeded | 2026-10-14T11:00:00+09:00 |
28행 전부를 JSON 파일 하나로 받을 수 있어요.
같은 형식으로 만든 1,274행이에요. 위 데이터가 이 안에 그대로 들어 있어요(한 줄에 한 행, gzip 압축).
미리보기와 내려받는 데이터 모두 이 형식(JSON Schema)을 따라요.
{
"type": "object",
"description": "배포 실행 하나에 실린 작업 하나. 키는 (run_id, task_id) 묶음.",
"additionalProperties": false,
"required": [
"run_id",
"task_id",
"env",
"result",
"deployed_at"
],
"properties": {
"run_id": {
"type": "string",
"pattern": "^RUN-[0-9]{5}$",
"description": "배포 실행 번호. 한 실행에 작업 여러 개가 함께 실릴 수 있고, 같은 run_id 의 행은 env·result·deployed_at 이 모두 같아요."
},
"task_id": {
"type": "string",
"pattern": "^TK-[0-9]{5}$",
"description": "이 실행에 실린 작업. odc_tasks.task_id 를 가리켜요."
},
"env": {
"type": "string",
"enum": [
"staging",
"production"
],
"description": "배포한 환경. staging 은 스테이징, production 은 운영이에요."
},
"result": {
"type": "string",
"enum": [
"succeeded",
"failed"
],
"description": "succeeded 는 배포가 끝까지 된 실행, failed 는 배포가 실패로 끝난 실행이에요."
},
"deployed_at": {
"type": "string",
"format": "date-time",
"description": "배포 도구가 실행을 마친 시각. 한국 시간(+09:00) ISO 8601, 초 단위. 협업 도구의 시각과 같은 기준으로 견줄 수 있어요."
}
}
}