“기능은 고쳤는데, 문서도 같이 바뀌었나요?” 코드는 저장소에 있고, 요구사항은 다른 문서에 있고, 시험 기록은 또 따로 있습니다. 작은 변경 하나를 설명하려고 여러 파일을 오가다 보면, 어디까지 확인했는지부터 헷갈리기 쉽습니다. 특히 인증·인허가를 준비하는 개발팀은 지금 문서가 어떤 코드와 자료를 바탕으로 작성됐는지, 아직 확인하지 못한 부분은 무엇인지 설명해야 합니다. 저는 개발자 문서 자동화 도구 Specify를 만들고 있습니다. 오늘은 공개 예제인 MedRelay Demo를 바탕으로, 코드에서 문서 초안을 만들고 팀이 검토하는 흐름을 소개해보려고 합니다. 1. 빈 문서보다 먼저 준비할 것 문서의 첫 문장을 쓰기 전에 재료를 모아야 합니다. 어떤 기능이 구현돼 있는지, 어느 파일에서 확인할 수 있는지, 기존 설명과 달라진 부분은 어디인지부터 살펴보는 것이죠. Specify의 의료기기 소프트웨어 활용사례는 GitHub 저장소와 제품 정보를 연결하는 데서 시작합니다. 제품의 용도와 범위 등을 정리한 ‘인증 프로필’을 준비하고, 이를 바탕으로 요구사항 명세서와 아키텍처 설계 문서의 초안을 만듭니다. 코드에서 읽을 수 있는 구현 내용에는 관련 파일 경로를 연결합니다. 대상 시장, 의도한 사용 목적, 안전 등급처럼 사람이 결정해야 하는 정보는 담당자가 확인할 항목으로 남깁니다. 자료가 부족한 부분까지 그럴듯하게 채우면 이후 검토가 더 어려워지기 때문입니다. 2. MedRelay Demo의 기능 하나를 따라가 보면 MedRelay Demo는 장치에서 보낸 합성 데이터의 형식과 순서를 확인하고, 메모리에 저장한 뒤 CSV로 내보내는 공개 예제입니다. 실제 환자 데이터나 임상 결과를 다루는 사례는 아닙니다. 먼저 Specify에 예제 저장소를 연결하고 제품 정보를 정리한 뒤, 요구사항과 설계 문서 초안을 만듭니다. 여기서 데이터 형식을 검사하는 요구사항 하나를 골라봅니다. 요구사항 초안에는 항목별 ID와 구현 근거 파일, 검증 후보가 함께 담깁니다. 연결된 파일을 열어 입력을 어떻게 검사하는지 보고 문서의 설명과 맞는지 확인합니다. 이어서 설계 문서에서 같은 기능을 찾아, 해당 요구사항이 어떤 구성요소로 이어지는지 따라갑니다. 이렇게 살펴보면 “문장이 자연스러운가?”에 더해 “이 설명을 코드에서 확인할 수 있는가?”를 검토할 수 있습니다. 검증 후보는 다음에 무엇을 시험할지 정하는 출발점입니다. 실제 시험 기록과 결과를 더해가며, 코드에서 시작한 초안을 팀이 검토하고 보완할 수 있는 문서로 구체화합니다. 3. 여러 문서를 만들었다면 연결도 확인하기 요구사항 문서와 설계 문서가 각각 잘 읽혀도 둘 사이의 연결은 빠져 있을 수 있습니다. 요구사항에서 가리키는 설계 항목이 실제로 존재하는지, 같은 기능을 서로 다르게 설명하지 않는지도 확인해야 합니다. 공개 활용사례에서는 요구사항·아키텍처 초안, 외부 소프트웨어 구성요소를 정리하는 SOUP 목록, 문서 묶음의 누락 검토 보고서를 순서대로 보여줍니다. 누락 검토는 빈 항목, 미확인 정보, 끊어진 항목 ID 참조 등을 모아줍니다. 공개 데모에서도 설계와 연결되지 않았거나 일부만 연결된 요구사항, SOUP 항목의 설계 참조 등이 검토 대상으로 나왔습니다. 보고서를 읽으면서 무엇을 더 확인해야 하는지, 누가 보완해야 하는지 정리할 수 있습니다. 의료기기 문서팩은 개발 계획·요구사항·설계·안전 분류·SOUP·위험관리·사용적합성·사이버보안 관련 문서 8종에, 인증 프로필 수집과 누락 검토를 더한 총 10개 스킬로 구성돼 있습니다. 4. 코드가 바뀐 다음에도 남겨야 할 정보 문서 자동화를 켜두더라도 기존 문서에 사람이 보완한 근거와 검토 기록은 중요합니다. 현재 공개 안내에서 의료기기 문서팩의 개발 문서 8종과 누락 검토 보고서는 문서 전체를 다시 작성하는 방식을 사용합니다. 재생성 전후에는 확정된 제품 정보, 기존 항목 ID, 사람이 추가한 근거와 검토 기록이 일관되게 유지되는지 확인해야 합니다. 규격 라이브러리도 라이선스 확인을 거쳐 단계적으로 제공됩니다. 사용할 수 없는 워크스페이스에서는 팀 자료를 바탕으로 작성하며 규격 인용을 붙이지 않습니다. 필요한 규격 원문은 적법하게 확보한 해당 판본으로 확인해야 합니다. 생성 문서는 제출 전 규제·품질 전문가의 검토가 필요한 초안입니다. 초안 생성과 누락 검토만으로 인증 취득이나 제출 준비 완료를 판단할 수는 없습니다. 5. 첫 시도는 최근 변경 한 건부터 도입을 검토한다면 최근 변경 하나와 관련 문서 몇 개를 골라 아래 질문에 답해보면 좋겠습니다. • 이번 초안은 어느 코드 버전과 자료를 바탕으로 했나? • 바뀐 설명의 근거를 원문에서 다시 확인할 수 있나? • 미확인 정보와 확인한 사실이 구분돼 있나? • 남은 질문을 누가 검토하고 보완할지 정했나? 문서 자동화를 평가할 때는 완성된 페이지 수만큼이나 검토하기 쉬운지도 중요합니다. 다음 사람이 근거를 따라가고, 남은 질문을 찾고, 필요한 결정을 이어갈 수 있어야 하니까요. 첨부 이미지 1은 글의 요약, 2는 자료→초안→검토의 개념도, 3은 공개 예제의 코드·문서 검토 흐름입니다. 실제 제품 화면이 아닌 설명용 이미지입니다. Specify 살펴보기 https://specify.app/?utm_source=jocohunt&utm_medium=community&utm_campaign=specify_20261009_jocohunt_01&utm_content=article 공개 예제로 자세히 보기 https://docs.specify.app/en/guides/medical-device-docs 규격 라이브러리 제공 조건 https://docs.specify.app/en/knowledge/standards
게시글이며 이미지며 앱까지 다 클러드 코덱스가 만들긴하는데 아무래도 영상없이 올리니까 보는사람이 적고 홍보가 안되는것같아요 ㅠㅠ 그래도 꾸준히하는 유저들이 있어서 힘은 나지만... 혹시 영상만들만한 ai 추천좀해주세요.
FitHelix(구 Nourai)의 개발자입니다. 오늘 1.3.0을 공개했습니다. 식사 전체를 한 장 찍고, 같은 접시를 가까이에서 다시 찍는 경우가 있습니다. 사진마다 기록을 만들면 같은 음식을 두 번 셀 수 있어서, 이번에는 한 끼의 사진을 묶어서 초안을 만드는 흐름을 추가했습니다. 같은 음식은 중복되지 않도록 모아 제안합니다. 첨부한 식사 확인 화면은 사진 2장을 음식 3개로 정리한 데모입니다. 음식 이름이나 분량이 다르면 각 항목을 눌러 고친 뒤 저장할 수 있습니다. 사진을 더 받는 것과 별개로, 저장 전 확인 단계는 유지했습니다. 바코드·영양성분표·음식 검색으로도 기록할 수 있고, 식사 일지와 iPhone·Apple Watch 운동 기록도 함께 지원합니다. 한국어 지원, iOS 26 이상입니다. 무료로 시작할 수 있으며 일부 기능과 이용 횟수 확대는 Pro입니다. 첨부 이미지는 영어 표시의 1.3.0 데모 화면입니다. 여러 장으로 한 끼를 기록할 때 음식 합치기와 분량 수정 중 어느 쪽이 더 헷갈리는지 궁금합니다. 사용해 보신 분의 구체적인 사례를 듣고 싶습니다. 제품 페이지: https://jocohunt.com/p/n3neetbj
요즘 AI로 제품만들면서 느끼는건데 월 구독제 만들려는데 무료체험기간이니, 환불정책이니 결제 실패했을때 언제까지 재시도하고 기능 이용가능기간은 또 언제까지 살려야하고 이런거 고민하다보면 오히려 서비스만드는거보다 시간 더가는거같아요 토스페이도 자동결제만 지원하고 결제 취소정책이나 구독은 직접 만들어야한다하고 혹시 다른분들은 어떻게 해결하고계신가요?
공공데이터로 만든 판정 도구를 만들고 있습니다. 처음부터 써 보신 분들께 질문 하나 드립니다. 정부24 서비스가 2천 개가 넘는데 전부 정리하긴 어려워서, 연도별 고시에서 조건을 뽑아 판정하는 쪽으로 접근하고 있습니다. 파싱하느라 고생한 게 대략 이 부분입니다. 정리하고 보니 두 가지가 계속 걸립니다. 첫째, 같은 혜택이라도 지역마다 기준이 다르고, 급여에 자체분임금이 들어가면 값이 갈립니다. 한 화면에서 다 보여주려면 표가 아니라 판정 로직을 짜야 했습니다. 두 번째는 애매한 조건입니다. 기준이 딱 떨어지지 않으면 확인이 필요한 것으로 따로 빼고, 뭘 확인해야 하는지 알려 줬습니다. 제가 드리는 질문은 이겁니다. 이런 종류의 도구를 쓰시면서 가장 불편했던 순간이 어디였는지 궁금합니다. 저는 자료를 긁어오는 구조를 어떻게 잡으셨는지, 아니면 처음부터 손으로 정리하시는 쪽이신지요. 다른 분들 것도 보면 좋은 점이 많겠습니다.
안녕하세요. Prelulu를 만드는 팀의 Tony입니다. 오늘 제품을 등록했고, 한국어로 AI 캐릭터와 영상통화를 처음 해 보는 분들의 구체적인 의견을 듣고 싶어 글을 남깁니다. Prelulu는 가상의 AI 캐릭터의 얼굴을 보며 실시간으로 대화하는 서비스입니다. 영상통화를 지원하는 캐릭터를 고르고 Video를 선택해 한국어로 말을 걸 수 있고, 텍스트 채팅과 음성통화도 함께 제공합니다. 실제 사람과 연결되는 서비스는 아닙니다. 처음 사용하는 입장에서 특히 이 세 가지가 궁금합니다. 1. 캐릭터를 고를 때, 얼굴·소개·목소리 중 무엇을 먼저 확인하고 싶으신가요? 2. 마이크 권한과 통화 크레딧 안내가 어느 단계에 있어야 이해하기 쉬울까요? 3. 첫 말을 꺼내기 어렵다면 어떤 짧은 예시가 도움이 될까요? 예를 들어 “오늘 하루가 길었어. 잠깐 이야기할래?”처럼 시작할 수 있습니다. 이 문장은 사용법 예시이며 실제 이용자의 대화나 후기가 아닙니다. AI 답변이나 기억은 틀릴 수 있고, 일부 캐릭터 소개는 영어로 표시될 수 있습니다. 텍스트에는 매일 무료 제공량이 있고 통화에는 크레딧이 사용됩니다. 이용 전 현재 요금과 잔액을 확인해 주세요. 가상의 AI 캐릭터와 대화하는 성인 대상 엔터테인먼트 서비스입니다. 한국어 영상통화 안내: https://prelulu.ai/ko/ai-video-chat?utm_source=jocohunt&utm_medium=social_owned&utm_campaign=kr_entry_202610&utm_content=first_video_feedback 제품 소개와 공식 소개 영상: https://jocohunt.com/p/mi6twwdk 좋다는 평가보다 “여기서 무슨 버튼을 눌러야 할지 모르겠다” 같은 구체적인 지적이 도움이 됩니다. 공개 댓글에는 계정 정보나 사적인 대화 내용은 남기지 말아 주세요. 계정별 문의는 [email protected]로 부탁드립니다.
맥미니에서 오픈웨이트 AI로 맞춤형 휴식 오디오를 만드는 앱 ‘숨’을 개발했습니다. 현재 무료 MVP이며 Google Play 비공개 테스트 심사 중입니다. 정식 출시를 위해 만 18세 이상 Android 사용자 12명 이상이 비공개 테스트에 참여해 14일 동안 참여 상태를 유지해야 합니다. 함께 써보고 음성 입력·오디오 재생·사용 경험에 대해 솔직하게 피드백 주실 분을 찾습니다. 실제 결제는 없습니다. 참여를 원하시면 [email protected]으로 ‘숨 테스트 참여’라는 제목의 메일을 보내 주세요. 본인이 Play 스토어에서 쓰는 Google 계정을 알려주시면 심사 승인 후 테스터 목록에 추가하고 참여 링크를 안내하겠습니다. 이메일 주소는 공개 댓글에 적지 마세요. 지금 웹에서 먼저 체험할 수 있습니다: https://soum-healing-macmini.vercel.app/ 제품 소개와 실제 화면: https://jocohunt.com/p/4gpdhqj1 의료·상담 서비스가 아닌 휴식용 앱입니다. 초기 운영 중이라 맥미니 서버 접속이 일시적으로 끊길 수 있습니다.
안녕하세요, 저는 현재 고등학겨 2학년 수험생활중인 개발자 진혁입니다. 저는 오늘 여러분께 토스같은 영상 티저를 만드는 법을 알려드리고자 글을 씁니다. 이미 이렇게 만드는 분이 계실수도 았지먼, 제가 혼자 생각해본 방법이기에 이렇게 공유합니다. 일단 제가 제 학교 세특을 위해 만든 사이트의 홍보영상부터 공유해봅니다. https://youtube.com/shorts/dW-hBsKPsnY?si=cnbRvmFuzmp0NiNi 이 영상을 그저 2시간도 안되는 시간만에 딸깍 해냈습니다. 방법은 쉬운데요, 우선 사이트를 만든 프로젝트 폴더에서 Codex의 새 에이전트를 실행합니다. 그다음 TypeScript 기반으로 타이포그래피와 모션 이펙트를 구현하고, 최종 결과물을 MP4 형식으로 렌더링하도록 요청하면 됩니다. 바로 제작에 들어가기보다는 먼저 토스 광고 스타일의 영상과 모션 디자인 가이드라인을 조사하게 한 뒤, 각 장면의 움직임에 어떤 의미를 담을지 기획하도록 하는 것이 좋습니다. 전체 연출이 정리되면 기존 사이트 파일을 참조하게 하고, 별도의 디렉터리에 실제 사이트 UI가 등장하는 장면을 추가해 서비스의 주요 기능을 설명하도록 요청하면 됩니다. 구체적으로 어떤 UI와 기능을 보여줄지는 GPT와 상의하면서 정하면 됩니다. 제작 중에는 영상 전체를 매번 렌더링하지 말고, 주요 구간의 일부 프레임만 이미지로 렌더링해 직접 확인하게 해야 합니다. 렌더링된 프레임을 이미지 인식으로 분석하고, 타이포그래피의 위치·크기·간격과 모션의 속도·타이밍을 반복적으로 수정하도록 지시하면 완성도가 훨씬 높아집니다. 이 과정을 거치면 Codex가 약 1시간 동안 스스로 렌더링과 피드백을 반복하며 영상을 완성합니다. 마지막으로 Suno에서 제작한 음악을 입히고, 무료 TTS로 생성한 내레이션을 장면별 타이밍에 맞춰 추가하면 됩니다.
한국 무대에서 멈추지 않고, 세계 무대까지 나아가길 진심으로 응원합니다. 유튜브 영상이 올라올 때마다 많은 정보를 얻고 있습니다. 항상 감사합니다!
개발자가 아닌 사람인데 기본적인 용어 하나하나 설명하고 이해 시켜 준 조코딩에 감사드립니다. 우리나라의 AI에 대한 이해와 전국민 실력향상에 큰 역할을 하고 있다고 생각합니다. 지금은 작은 서비스 만들어서 시작했는데 언젠가 함께 할 날이 오면 좋겠습니다!
