AI로 Mac 앱 만들기, Lacuna는 왜 문서 전체 대신 빈칸 하나를 골랐을까요?

핵심 요약 (TL;DR)

Lacuna의 제작자 Jack Damon은 지난주 프롬프트로 자신이 매일 쓰는 도구를 만들었다고 소개했습니다.[1] 이메일 전체를 대신 쓰는 큰 서비스가 아니라, 작성 중인 문장의 빈 부분에 표현 후보를 넣는 Mac 앱입니다. 첫 MVP의 출발점을 찾는다면 기능 목록보다 ‘내가 자꾸 멈추는 순간’을 관찰해 볼 만한 사례입니다.

제작자가 줄이려던 불편은 무엇이었나요?

제작자는 이메일 초안을 쓰다가 짧은 표현을 다듬고 싶을 때 자주 사용한다고 말합니다. 문장 안에 중괄호로 요청을 적고 단축키를 누르면, 그 부분을 바꿀 표현 세 개를 제안하는 방식입니다. 키보드로 선택할 수 있으며, 창 정리 도구 Rectangle에서 영감을 받았다고 설명합니다.[1]

Hacker News 소개 시각은 한국 시간 10월 10일 오전 4시 31분입니다.[2] 이는 소개 글의 시각이지 앱을 처음 만든 날짜가 아닙니다. 제작자가 프롬프트로 만들었다고 밝힌 것은 확인했지만, 어떤 코딩 모델이 어느 비율의 코드를 작성했는지는 공개 글만으로 알 수 없습니다.

왜 문서 전체보다 빈칸 하나가 좋은 시작일까요?

빈칸을 채우는 행동은 사용자가 결과를 비교하기 쉽습니다. 이미 쓰던 문장이 있고, 바꾸고 싶은 부분이 있으며, 마음에 드는 표현을 고르는 순간이 분명합니다. AI가 메일의 목적이나 발송 대상까지 대신 결정하는 구조와는 다릅니다.

여러분이 첫 도구를 만든다면 실제로 반복하는 문장 하나를 골라 보세요. ‘고객 답장을 자동화해 주세요’보다 ‘가짜 문의문에서 인사말 한 부분만 제안하고, 선택 전에는 원문을 바꾸지 않게 해 주세요’처럼 좁힐 수 있습니다. 이 예시는 Lacuna의 구현 설명이 아니라, 사례를 작은 실습으로 옮기는 제안입니다.

빈칸만 바꾸는데 주변 글도 전송되나요?

제작자 설명은 중괄호 안의 요청과 주변 텍스트를 설정한 LLM에 전달한다고 명시합니다.[1] 저장소는 제안을 요청할 때 설정한 제공사로 직접 전송하며, API 키는 macOS Keychain에 보관한다고 안내합니다.[3] 따라서 화면에서 바뀌는 범위와 외부로 보내는 범위가 같다고 생각하면 안 됩니다.

Mac에 설치되는 앱이라고 모든 처리가 기기 안에서 끝나는 것도 아닙니다. 공식 README는 OpenAI·Anthropic API 또는 호환 서버를 연결하도록 안내합니다.[3] 고객 메일로 바로 시험하기보다, 무해한 샘플을 넣고 어떤 문맥을 보내는지 확인하는 편이 좋겠습니다.

첫 작동 뒤에는 무엇을 검수해야 할까요?

앱은 macOS 접근성 API를 사용하며, 입력란이 필요한 정보를 제공하는지에 따라 지원 범위가 달라집니다.[3] ‘어디서나 쓴다’는 아이디어가 모든 앱의 모든 입력창에서 같은 동작을 보장하지는 않습니다. 처음에는 자주 쓰는 입력창 하나에서 생성·선택·취소를 확인해 보세요.

원문이 원치 않게 덮어써지지 않는지, 요청이 실패하면 다시 편집할 수 있는지, 후보를 고르지 않고 닫아도 내용이 유지되는지를 완료 조건으로 적어 두면 좋습니다. 이 글은 제작자 글과 저장소를 읽은 소개이며, 앱 설치나 입력 호환성을 직접 시험한 후기는 아닙니다.

FAQ: 오픈소스면 모델 사용도 무료인가요?

아닙니다. 코드의 공개 라이선스와 모델 제공사의 이용료는 별개입니다. 자신의 API 키나 호환 서버를 연결하는 방식이므로 선택한 제공사의 과금 조건을 확인해야 합니다.[3]

FAQ: 바로 업무용 Mac에 설치해도 될까요?

현재 README는 미리보기 배포본에 Apple Developer ID 서명과 공증이 없다고 밝힙니다.[3] 접근성 권한도 필요한 만큼 조직의 설치 정책부터 확인하세요. 보안 경고를 단순한 설치 방해로 보고 무조건 넘기는 방식은 권하지 않습니다.

출처
[1] https://jackdamon.org/blog/lacuna/
[2] https://news.ycombinator.com/item?id=50025559
[3] https://github.com/jdamon96/lacuna