비트[비트컴퓨터] 신사업 풀스택 개발자 (Product Engineer)
2.4 (281)비트컴퓨터
경력근거: 신사업을 기존 사업·시스템과 통합하는 설계와 개발
18일 전 확인채용 공고 보기
비트컴퓨터의 이 자리는 정해진 스펙을 받아 구현하는 자리가 아니라 문제 정의와 스펙 작성부터 초기 고객 대응까지 주도하는 자리라서, 기능 목록의 나열보다 작은 화면 하나를 혼자 배포까지 끌고 간 완결 경험이 그대로 증거가 됩니다. 공고가 신사업을 기존 사업·시스템과 통합하는 설계와 개발을 첫 업무로 못박았기 때문에, 기존 접수 프로그램에서 내려받은 명단을 그대로 받아들이는 입구를 화면의 첫 관문으로 둡니다. 우대사항의 알림톡과 SMS 발송은 발신번호 사전등록이, 결제 연동은 가맹점 심사가 필요해 개인 포트폴리오에는 넣지 않고, 그 직전 단계인 연락 대상 목록과 문안 초안까지를 완결해 회사 채널이 생기면 연동만 더하면 되는 상태를 보입니다. 이 포트폴리오가 보여주는 것은 명단 입력부터 목록 화면과 배포까지 작은 서비스를 혼자 완결하는 웹 풀스택 기술이며 의료 도메인 전문성은 주장하지 않습니다. 모르는 깊이는 면접에서 모른다고 말하는 편이 낫습니다.
문제 정의와 스펙 작성부터 코드와 초기 고객 대응까지 한 사람이 끌고 가는 자리라서, 잘게 쪼갠 기능 목록 대신 혼자 배포까지 끝낸 작은 화면 하나로 그 역량을 보입니다.
새 것만 만드는 게 아니라 40년치 자산 위에 얹는 일이 업무의 절반이라서, 기존 접수 프로그램에서 내려받은 명단 파일을 그대로 받아들이는 입구를 화면의 첫 관문으로 둡니다.
AI 도구를 일상적으로 쓰되 그 결과물을 스스로 검증하는 방식을 요구하는 자리라서, 문안 초안과 표기 정규화만 LLM 에 맡기고 연락 대상과 순서는 규칙이 정하게 나눠 그 검증 감각을 제품 구조로 보입니다.
동네 의원 데스크가 기존 접수 프로그램에서 내려받은 예약 명단을 올리면, 전화번호가 없거나 날짜가 지났거나 중복인 예약을 사유별로 걸러내고, 나머지는 초진 여부와 과거 취소와 노쇼 이력 기준의 우선순위로 정렬된 내일 연락 목록이 되는 작은 웹 화면입니다. 각 환자 옆에는 진료과와 시간에 맞춘 안내 문안 초안이 붙어 데스크가 복사해 전화 안내나 기존 문자 채널에 그대로 씁니다. 발송과 결제처럼 회사 명의가 있어야 계정이 열리는 연동은 넣지 않고, 그 직전 단계인 연락 준비까지를 완결합니다.
진료 전날 마감 후에 내일 예약자 명단을 접수 프로그램에서 뽑아 순서 없이 위에서부터 확인 전화를 돌리고 안내 문구를 매번 새로 쓰던 의원 데스크 담당자가, 명단만 올리면 누구부터 연락할지와 무엇이라고 안내할지가 정리된 화면을 보고 싶은 사람입니다.
예약 명단을 올리는 것만으로 연락 우선순위와 제외 대상과 안내 문안이 정리되면, 데스크가 같은 시간 안에 무응답 위험이 큰 예약부터 챙기게 되어 빈 진료 시간을 줄일 준비가 된다는 가정입니다.
기존 접수 프로그램에서 내려받은 예약 명단을 올리면, 전화번호가 없거나 날짜가 지났거나 중복인 예약을 사유별로 제외하고, 나머지를 초진 여부와 과거 취소와 노쇼 이력 기준의 우선순위로 정렬해 연락 목록으로 내는 웹 화면이며 배포를 마친 완결품입니다. 각 환자 옆에는 진료과와 시간에 맞춘 안내 문안 초안이 붙고 데스크는 복사 버튼으로 가져다 씁니다. 만드는 덩어리는 연락 목록과 문안 초안 둘이며 평일 5일에 혼자 끝나는 범위입니다.
데스크가 연락 목록에서 확정과 취소와 무응답을 체크하면 내일 시간표에 빈 시간이 표시되어 당일 대기 환자를 채울 준비가 되는 응답 기록 기능입니다. 이 주차부터 서비스를 AWS 에 올려 실제 주소로 운영합니다.
여러 날의 명단과 응답 기록을 쌓아 시간대별과 진료과별 취소와 무응답 비율을 차트로 보여주고, 다음 주 명단에서 어느 시간대를 먼저 챙길지 짚어 주는 주간 리포트 화면입니다.
기존 접수 프로그램에서 내려받은 형태의 예약 명단을 올리면 우선순위가 매겨진 연락 목록과 환자별 문안 초안이 나오는 흐름을 처음부터 끝까지 시연합니다.
전화번호 결측과 지난 날짜와 별칭 목록에 없는 진료과 표기와 중복 예약을 심어 둔 명단에서 그 네 유형이 모두 제외와 사유로 잡히고, 과거 노쇼 이력이 있는 예약이 목록 위쪽에 오는 것을 보입니다. 다만 정답과 데이터를 작성자가 만든 합성 기준이라 성능 검증이 아니라 데모 조건 동작입니다.
전화번호 표기가 깨졌거나 날짜 형식이 제각각이거나 진료과 표기가 처음 보는 것인 명단 30종을 올려도 화면이 죽지 않고 예약 한 건마다 등록 거절 사유를 남깁니다.
위 수치는 더미데이터 자가채점이며, 실제 노쇼 감소와 연락 시간 단축은 비트컴퓨터가 닿는 실제 의원의 명단과 데스크의 실제 사용이 있어야 측정 가능합니다. 이 포트폴리오는 그 검증을 바로 돌릴 수 있는 상태로 만듭니다.
수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서는 데모가 도는 상태와 실검증 준비 상태로 솔직히 설명합니다.
정답을 작성자가 만들었으니 잘 맞는 것이 당연합니다. 전화번호가 빠진 행과 날짜가 지난 행과 별칭 목록에 없는 진료과 표기와 중복 예약과 동명이인 이력을 더미에 일부러 섞어 두었습니다.
우대사항의 알림톡과 SMS 발송은 발신번호 사전등록이, 결제 연동은 가맹점 심사가 필요해 개인은 계정을 열지 못하므로 범위에서 뺐습니다. 이 제품은 그 직전 단계인 대상 목록과 문안 초안까지 만들며, 실제 발송과 결제는 회사 명의 채널이 생긴 뒤의 도입 과제입니다.
환자 이름과 전화번호는 민감한 개인정보라서 실제 도입에서는 수집과 보관과 파기 규정 검토가 선행되어야 합니다. 이 포트폴리오는 더미 명단으로만 돌며 의료 도메인 전문성은 주장하지 않습니다.
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
기존 접수 프로그램에서 내려받은 내일 예약 명단을 흉내 낸 더미입니다. 전화번호와 날짜와 진료과 표기가 흔들리는 행에서 연락 대상과 제외 사유를 가르기 위한 입력입니다.
| reservation_id | patient_name | phone_raw | dept_raw | dept_id | reserved_at_raw | visit_type | memo |
|---|---|---|---|---|---|---|---|
| R-101 | 강지후 | 010-2345-1234 | 내과 | D-int | 2026-08-12 09:30 | 재진 | — |
| R-102 | 서은우 | 01034561234 | 내과(외래) | D-int | 2026-08-12 10:00 | 재진 | 하이픈 없는 전화번호 표기 |
| R-103 | 민하린 | — | 피부과 | D-derm | 2026-08-12 10:30 | 재진 | 전화번호 미기재라 제외 대상 |
| R-104 | 조태오 | 010-4567-2345 | IM | D-int | 2026-08-12 11:00 | 재진 | 진료과 영문 약어 표기 |
| R-105 | 백서율 | 010-5678-3456 | 통증클리닉 | — | 2026-08-12 14:00 | 초진 | 별칭 목록에 없는 진료과 표기 |
아래 JSON Schema에 맞는 의원 예약 명단 행을 30건 더 만들어 주세요. {"type":"object","properties":{"reservation_id":{"type":"string"},"patient_name":{"type":"string"},"phone_raw":{"type":["string","null"]},"dept_raw":{"type":"string"},"dept_id":{"type":["string","null"]},"reserved_at_raw":{"type":"string"},"visit_type":{"type":"string","enum":["초진","재진"]},"memo":{"type":["string","null"]}},"required":["reservation_id","patient_name","dept_raw","reserved_at_raw","visit_type"]} 쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라. 첫째 phone_raw가 null이거나 하이픈과 국가번호 표기가 흔들리는 행, 둘째 reserved_at_raw가 이미 지난 날짜이거나 연도 없는 표기이거나 한글 시간 표기인 행, 셋째 dept_raw가 별칭 목록에 없는 표기라 dept_id가 null인 행, 넷째 같은 환자와 같은 시각이 겹치는 중복 등록 행. 형식을 깨뜨리는 시도는 3건까지 별도로 만들어 주세요.{"type":"object","properties":{"reservation_id":{"type":"string"},"patient_name":{"type":"string"},"phone_raw":{"type":["string","null"]},"dept_raw":{"type":"string"},"dept_id":{"type":["string","null"]},"reserved_at_raw":{"type":"string"},"visit_type":{"type":"string","enum":["초진","재진"]},"memo":{"type":["string","null"]}},"required":["reservation_id","patient_name","dept_raw","reserved_at_raw","visit_type"]}환자별 과거 방문과 취소와 노쇼 기록을 흉내 낸 더미입니다. 연락 우선순위를 이력 기준으로 매기고 3주차의 시간대별 차트를 그리기 위한 입력입니다.
| history_id | patient_name | phone_raw | dept_raw | visited_on | outcome | canceled_before_hours | memo |
|---|---|---|---|---|---|---|---|
| H-201 | 강지후 | 010-2345-1234 | 내과 | 2026-05-14 | 노쇼 | — | 연락 없이 미방문 |
| H-202 | 강지후 | 010-3345-0001 | 내과 | 2026-03-10 | 방문 | — | 동명이인이라 전화번호로 구분해야 하는 기록 |
| H-203 | 오시완 | 010-2234-9012 | 내과 | 2026-06-02 | 취소 | 2 | 예약 두 시간 전 취소 |
| H-204 | 오시완 | 010-2234-9012 | 내과 | 2026-07-07 | 취소 | 0 | 당일 진료 시각에 취소 |
| H-205 | 노아인 | +82 10-8901-6789 | 안과 | 2026-05-30 | 방문 | — | 국가번호 포함 표기가 그대로 저장된 기록 |
아래 JSON Schema에 맞는 환자 방문 이력 행을 30건 더 만들어 주세요. {"type":"object","properties":{"history_id":{"type":"string"},"patient_name":{"type":"string"},"phone_raw":{"type":["string","null"]},"dept_raw":{"type":"string"},"visited_on":{"type":"string"},"outcome":{"type":"string","enum":["방문","취소","노쇼"]},"canceled_before_hours":{"type":["number","null"]},"memo":{"type":["string","null"]}},"required":["history_id","patient_name","dept_raw","visited_on","outcome"]} 쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라. 첫째 phone_raw가 null이거나 명단과 표기만 다른 같은 번호인 행, 둘째 canceled_before_hours가 0인 당일 취소 행과 취소가 아닌데 값이 null인 행, 셋째 내일 명단에 없는 환자의 기록, 넷째 이름이 같고 전화번호가 다른 동명이인 기록. 형식을 깨뜨리는 시도는 3건까지 별도로 만들어 주세요.{"type":"object","properties":{"history_id":{"type":"string"},"patient_name":{"type":"string"},"phone_raw":{"type":["string","null"]},"dept_raw":{"type":"string"},"visited_on":{"type":"string"},"outcome":{"type":"string","enum":["방문","취소","노쇼"]},"canceled_before_hours":{"type":["number","null"]},"memo":{"type":["string","null"]}},"required":["history_id","patient_name","dept_raw","visited_on","outcome"]}| Java / Spring Boot | 명단 업로드 API 와 제외와 우선순위 판정 규칙과 응답 기록 처리를 포함한 서비스 백엔드를 구현합니다. |
| Python | 접수 프로그램마다 다른 명단 파일의 전화번호와 날짜와 진료과 표기를 적재 형태로 정규화하는 변환 스크립트를 만듭니다. |
| AWS | 2주차부터 서비스를 AWS 에 올려 실제 주소로 운영하고 3주차 리포트까지 같은 환경에서 돌립니다. |
| 웹 풀스택(화면·API·데이터·배포) | 명단 업로드부터 연락 목록과 시간표와 리포트 화면까지 화면과 API 와 데이터와 배포를 혼자 끝냅니다. |
| AI 활용 개발환경 | 안내 문안 초안과 표기 정규화 후보를 Claude 로 만들고 그 결과를 규칙과 사람 확인으로 검증하는 작업 방식을 저장소의 커밋과 문서로 남깁니다. |
| 기존 시스템 통합(Integration) | 접수 프로그램은 손대지 않고 거기서 내려받은 명단 파일을 그대로 입력으로 받아, 레거시 위에 얹는 통합을 작은 규모로 구현합니다. |
✓ pass → 그대로 멈춰도 완결입니다. 더 키우려면 2주차에서 연락 결과 기록과 내일 시간표 화면을 붙입니다.
✓ pass → 여기까지도 완결입니다. 더 키우려면 3주차에서 쌓인 기록을 차트와 주간 리포트로 만듭니다.
예약 한 건에 대한 연락 계획입니다. 연락 여부와 우선순위와 그 근거와 안내 문안 초안을 담아 데스크가 목록 위에서부터 그대로 처리하게 합니다.
{"type":"object","properties":{"reservation_id":{"type":"string"},"action":{"type":"string","enum":["contact","exclude"]},"exclude_reason":{"enum":["phone_missing","past_date","duplicate",null]},"priority":{"type":["integer","null"]},"priority_reasons":{"type":"array","items":{"type":"string"}},"draft_message":{"type":["string","null"]},"hedge":{"type":["string","null"]}},"required":["reservation_id","action","priority_reasons"]}[
{
"reservation_id": "R-101",
"action": "contact",
"exclude_reason": null,
"priority": 1,
"priority_reasons": [
"같은 전화번호의 과거 기록에 노쇼 1회가 있습니다.",
"오전 첫 시간대 예약이라 무응답이면 빈 자리를 채우기 어렵습니다."
],
"draft_message": "내일 12일 오전 9시 30분에 내과 진료가 예약되어 있습니다. 방문이 어려우시면 미리 말씀해 주세요.",
"hedge": "우선순위는 합성 이력 기준 추정이라 실제 의원의 노쇼 분포와 다를 수 있습니다."
},
{
"reservation_id": "R-107",
"action": "contact",
"exclude_reason": null,
"priority": 2,
"priority_reasons": [
"초진이라 위치와 접수 절차 안내가 필요합니다."
],
"draft_message": "내일 12일 오후 2시 30분에 이비인후과 진료가 예약되어 있습니다. 처음 방문이시면 접수 마감 10분 전까지 와 주세요.",
"hedge": null
},
{
"reservation_id": "R-103",
"action": "exclude",
"exclude_reason": "phone_missing",
"priority": null,
"priority_reasons": [
"전화번호가 비어 있어 연락 수단이 없습니다."
],
"draft_message": null,
"hedge": null
},
{
"reservation_id": "R-106",
"action": "exclude",
"exclude_reason": "past_date",
"priority": null,
"priority_reasons": [
"예약 날짜가 이미 지나 연락 대상이 아닙니다."
],
"draft_message": null,
"hedge": null
}
][자동 검증] 1. 계획 JSON이 위 스키마를 통과하는지 확인합니다. action이 두 값 밖이면 그 행을 버립니다. 2. action이 exclude면 exclude_reason이 있어야 하고 draft_message는 null이어야 합니다. 연락하지 않을 예약에 문안이 붙는 일을 막기 위해서입니다. 3. action이 contact면 priority가 1 이상이고 priority_reasons가 비어 있지 않아야 합니다. 4. draft_message에 담긴 진료과와 시간이 원본 예약 행과 글자 그대로 일치하는지 확인합니다. 문안 초안의 환각을 거르기 위해서입니다. [수동 검증] 1. 우선순위 상위 20건을 뽑아 초진과 과거 이력 근거가 실제 입력 행과 맞는지 확인합니다. 2. 문안 초안 20건을 데스크 시선으로 읽어 어색하거나 과한 표현이 없는지 확인합니다.