# 텍스트 스크린샷이 싫어요 > Clean Markdown view of GeekNews topic #24310. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=24310](https://news.hada.io/topic?id=24310) - GeekNews Markdown: [https://news.hada.io/topic/24310.md](https://news.hada.io/topic/24310.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-11-12T09:55:35+09:00 - Updated: 2025-11-12T09:55:35+09:00 - Original source: [parkscomputing.com](https://parkscomputing.com/page/i-hate-screenshots-of-text) - Points: 5 - Comments: 4 ## Summary 개발자라면 한 번쯤 겪어봤을 **“텍스트 스크린샷”의 악몽**을 다룬 글입니다. 코드나 **빌드 오류 로그를 이미지로 공유**하면 변수 정의나 에러 라인 같은 핵심 맥락이 사라져, 결국 상대방이 **검색창에 다시 타이핑**하거나 전체 리빌드를 해야 하는 비효율이 발생합니다. 반면 **복사 가능한 텍스트나 GitHub 링크 공유**만으로도 IDE 검색과 컨텍스트 파악이 즉시 가능하죠. 단순한 매너처럼 보이지만, 이런 작은 습관이 팀의 **협업 속도와 품질**을 결정합니다. ## Topic Body - 일상적인 업무 중 동료들로부터 **텍스트를 스크린샷으로 찍어 보내는 경우**가 빈번하며, 이는 코드 검색과 컨텍스트 파악을 극도로 어렵게 만드는 비효율적 방식 - 스크린샷으로 받은 코드는 **변수 정의, 모듈 위치, 예외 처리 등의 맥락**을 전혀 알 수 없어, 검색창에 일일이 타이핑하거나 코딩 에이전트를 동원해야 함 - 빌드 오류 로그를 스크린샷으로 보낼 경우, **빌드 대상, 실패 라인, 정확한 에러 메시지**를 알 수 없어 문제 해결이 불가능 - 텍스트 복사-붙여넣기나 **파일/GitHub 링크 공유**를 사용하면 IDE 검색 기능 활용과 전체 컨텍스트 확인이 가능해짐 - **화면 표시 관련 문제**가 아닌 이상, 텍스트는 스크린샷이 아닌 복사 가능한 형태로 공유해야 협업 효율성 확보 --- ### 스크린샷 문제 사례 1: 코드 - 동료로부터 코드 관련 이슈 논의 시 **코드 스크린샷**을 받게 됨 - `slug` 변수 정의, `baseUrl` 생성 방식, 도메인 하드코딩 이유, 예외 처리 방식, 해당 모듈 위치 등 **핵심 컨텍스트를 전혀 파악 불가** - 스크린샷 속 코드를 **검색창에 수동으로 타이핑**하거나 코딩 에이전트를 사용해 관련 모듈을 찾아야 함 - 복사-붙여넣기를 사용하면 **동일한 라인이라도 더 많은 컨텍스트 확인 가능**하며, IDE 검색 기능에 바로 붙여넣기 가능 - 파일 자체나 **GitHub 링크를 공유**하는 것이 훨씬 효율적 ### 스크린샷 문제 사례 2: 빌드 오류 로그 - "빌드가 실패했는데 확인해줄 수 있나요?"라는 요청과 함께 **오류 로그 스크린샷** 수신 - 무엇을 빌드했는지, 어느 라인에서 실패했는지, **정확한 에러 메시지가 무엇인지** 전혀 알 수 없음 - 본인 워크스테이션에서 전체 리빌드를 수행하면 성공하는 경우 발생 - **전체 에러 로그를 복사**하거나 로그를 파일로 덤프해서 보내면 간단히 해결 가능한 문제 ### 올바른 텍스트 공유 방법 - 텍스트를 스크린샷으로 보내지 말고, **복사 가능한 형태로 공유**할 것 - 스크린샷은 **화면 표시의 미적 문제**를 보여주거나, 순수 텍스트로는 손실되는 관련 정보가 있을 때만 사용 - 파일 공유나 GitHub 링크 제공이 **컨텍스트 파악과 코드 검색을 위한 최선의 방법** ## Comments ### Comment 46235 - Author: tested - Created: 2025-11-12T12:20:49+09:00 - Points: 1 캡처했을 때 에디터에서 보여지는 가독성과 OS에서 기본 지원하는 캡처 단축키의 간편함을 이유로 코드를 캡처해서 올릴 때도 있는데 단축키 하나로 캡처된 이미지의 코드를 외부에 공유할 수 있는 Text fragments 등의 링크로 만들어주고 바로 붙여 넣을 수 있는 프로그램이 있으면 그걸 사용할 것 같네요. Slack에 올렸을 때 미리보기로 보여주고 링크를 타고 들어가서 코드를 복사할 수 있게끔 ### Comment 46227 - Author: kunggom - Created: 2025-11-12T10:31:40+09:00 - Points: 1 어그로를 끌어보기 위해, 코드를 보기에 예쁜 이미지 스크린샷으로 바꿔주는 사이트를 드리겠습니다. ㅌㅌㅌ https://ray.so/ 저도 메신저나 메일로 뭐 보낼 때 최대한 텍스트 위주로만 사용하고 있긴 한데, 사실 경우에 따라서는 텍스트만 사용하는 쪽이 오히려 더 불편할 수도 있긴 하죠. 그에 비하여 스크린샷 캡쳐는 대충 단축키 하나 누르고 화면 긁은 다음 붙여넣기하는 것만으로 GUI 상에서 처리가 되니까, 보내는 입장에서는 더 편하게 느껴지긴 할 겁니다. 하지만 본문에서도 지적했듯이, 그걸 받는 입장에서는 스크린샷만으로 맥락이 다 전달되지도 않는 경우도 많고 검색이나 복사-붙여넣기 또한 불편하니까 불만이 생기는 것이라 생각합니다. 데이터 전송과 저장에 원래 필요한 것보다 훨씬 큰 오버헤드가 생긴다는 건 둘째치고라도 말이죠. 뭐 개인적으로 이런 걸 하나하나 따지자면 사내에서 내부 문서화를 위키 대신 워드 파일로 한다던가 하는 뭐 그런 것부터가 불만이기는 한데… ### Comment 46223 - Author: neo - Created: 2025-11-12T09:55:35+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=45883124) - 다른 댓글에서도 언급되었듯이, **Apple 플랫폼의 자동 OCR** 기능은 정말 혁신적임 이런 기능은 모든 플랫폼의 문서 뷰어에 기본으로 들어가야 한다고 생각함 또 하나 바라는 점은 스크린샷에 **메타데이터**를 포함하는 것임. 예를 들어 인스타그램 사진을 캡처하면 해당 URL이 포함되고, 브라우저에서는 현재 보고 있는 URL과 DOM 경로, 지도 앱에서는 좌표, PDF 뷰어에서는 문서의 SHA1 해시와 오프셋을 포함하는 식임 물론 **프라이버시 문제**는 있겠지만, 이런 아이디어는 이미 학계에서 다뤄졌을 것이라 생각함 요즘은 파일 개념이 추상화되어서, 스크린샷이 모바일 컴퓨팅 시대의 공통 언어가 된 느낌임 참고로 [Screenshot Conf](https://screenshot.arquipelago.org)도 꼭 언급하고 싶음 - OCR 기능에는 전적으로 동의하지만, 메타데이터 삽입은 **프라이버시 악몽**이 될 수 있음 스크린샷은 OS 레벨에서 처리되는데, 앱이 자신이 찍혔다는 사실이나 위치 정보를 알게 되는 건 위험함 Evernote나 CloudApp 같은 회사들이 시도했지만, 결국 실패했음. 스크린샷은 단순해야 유용함 - 나는 글의 작성자인데, 웹페이지 스크린샷에 URL이 빠지는 문제를 언급했어야 했음 내가 만드는 시스템은 URL에 많은 **컨텍스트 정보**를 담는데, 스크린샷에는 그게 포함되지 않음 그래서 항상 URL을 **텍스트로 따로 요청**해야 함 - 요즘 Google과 Apple도 이 흐름을 인식하고 있음 스크린샷 후 UI에 **AI 인사이트, 상품 검색, Gemini/LLM 대화** 같은 기능을 넣고 있음 모두가 스크린샷을 정보 저장이나 검색용으로 쓰기 때문임 - 인스타그램 사진의 URL을 스크린샷에 포함하자는 아이디어는 **프라이버시 악몽** 그 자체임 - 재미있는 사실로, 초기 **MacPaint** 개발 버전에는 간단한 OCR 복사 기능이 있었음 하지만 사람들이 워드프로세서로 쓸까봐 출시 버전에서는 빠졌음 - 나는 스크린샷을 자주 쓰는 편임 이유는 80자 폭을 유지해 **가독성**이 좋고, **모노스페이스 폰트**와 구문 강조가 그대로 보존되기 때문임 코드나 터미널 출력이 이메일이나 모바일 채팅에서 망가지지 않게 하려면 스크린샷이 가장 확실함 물론 전체 파일이 필요할 때는 첨부하지만, 관련 부분은 스크린샷으로 함께 보냄 - 채팅에서는 **복사·검색 가능성**이 더 중요함 스크린샷은 확대해야 하고, 접근성에도 불리함 텍스트로 보내면 검색과 복사가 쉬움 - “80자 폭” 같은 건 개인 취향임 대부분의 시스템은 이미 모노스페이스 폰트를 지원하고, 문제는 오히려 **Gmail 렌더링** 같은 환경적 요인임 GMail은 폭 제한도 없고 폰트 크기도 제각각이라 읽기 힘듦 - 이런 포맷 선호는 개인적이므로, 스크린샷으로 강요하면 안 됨 긴 URL이나 넓은 화면에서는 오히려 **가독성 저하**가 심함 - 나도 스크린샷을 선호함 색상, 포맷, 문맥이 그대로 보이기 때문임 문제를 설명할 때는 **“그림 한 장이 천 마디 말보다 낫다”** 는 말이 맞음 - 나는 코드가 텍스트로 오는 게 훨씬 낫다고 생각함 그래야 내 에디터에서 **폰트, 폭, 색상**을 내 취향대로 볼 수 있고, 검색과 수정도 가능함 스크린샷은 결국 다른 사람에게 불편을 줌 - Mac과 iOS의 **텍스트 인식 및 복사 기능**은 정말 혁신적임 스크린샷이나 사진 속 텍스트를 바로 복사해 메모에 붙여넣을 수 있음 - Windows의 **Snipping Tool**도 텍스트 추출 기능이 있음 - 누군가 iMessage로 전화번호 사진을 보냈는데, 그냥 눌렀더니 바로 전화 걸기 창이 뜸 그 순간 정말 **미래에 살고 있는 느낌**이었음 - MacBook과 iPhone 간의 **복사·붙여넣기 연동**은 작업 흐름을 완전히 바꿔줌 - 이 기능이 좋은 이유는 시스템 전반에 **일관되게 통합**되어 있기 때문임 Safari에서는 이미지 속 텍스트 번역도 가능해서, 특히 일본어 웹페이지 번역에 유용함 - 나는 **Shottr**을 써서 스크린샷을 찍자마자 “O”를 눌러 OCR을 바로 실행함 파일 저장 없이 바로 처리돼서 편함 - 예전에는 스크린샷을 Word 문서에 붙여서 보냈음 그런데 이제 **LLM으로 텍스트를 다시 추출**하자는 제안은 너무 낭비임 결국 필요한 건 텍스트를 스크린샷만큼 쉽게 공유할 수 있는 **UI 혁신**임 - 더 심한 경우도 있음. 어떤 사람들은 화면을 직접 **사진으로 찍어서** 보냄 프로그래머 지망생들이 이런 걸 하는 걸 보면 답답함 - 어떤 회사에서는 Word 문서를 **폴더처럼 사용**했음 문서 안에 다른 Word 파일들을 실제 객체로 붙여넣는 식이었음 - 관련된 XKCD 만화도 있음 → [xkcd 2116](https://xkcd.com/2116/) - 내가 쓴 글 ‘Slack에서 도움 요청하는 법’의 7번째 규칙은 “**텍스트 스크린샷을 올리지 말 것**”임 Apple의 OCR이 좋아도 **검색 불가능성** 문제는 여전함 [원문 링크](https://thundergolfer.com/communication/slack/2021/02/24/how-to-ask-for-help-in-slack/) - 하지만 Spotlight와 Photos는 스크린샷 속 텍스트도 검색 가능함 - 나는 전체 문서나 코드 링크를 함께 보내면서, **관련 부분의 스크린샷**도 첨부하는 방식을 선호함 시각적 맥락이 남아 있어서 나중에 다시 볼 때 **기억이 더 잘 남음** - 신입 개발자들이 처음 몇 주 동안 자주 **텍스트 스크린샷**을 공유함 하지만 모바일에서 읽기 불편하고, Slack은 이미지를 압축해서 확대도 안 됨 그래서 결국 대부분은 텍스트로 공유하는 법을 배우게 됨 - **MS Teams**에서는 코드 블록 지원이 너무 나빠서 스크린샷을 쓰는 경우가 많음 - 나는 팀원들에게 Teams에서 **Markdown 코드 블록** 만드는 법을 가르치고 있음 기능은 있지만 잘 드러나 있지 않음 - Teams에서 스크린샷을 보면, 대부분 다른 채팅의 대화 일부를 캡처한 것임 - 스크린샷은 **빠르고 일관된 방법**임 웹앱, 네이티브 앱, 사이트 등 어디서나 같은 방식으로 작동함 받는 사람에겐 불편할 수 있지만, 보내는 입장에서는 **효율적**임 - 나는 Linux에서 **xfce4-screenshooter**의 사용자 정의 동작을 **tesseract OCR 스크립트**로 연결해둠 선택 영역을 캡처하면 자동으로 텍스트가 클립보드에 복사됨 인식이 어려운 경우에는 **Gemma3-4B + llama.cpp**를 사용함 - 참고 스크린샷: [https://0x0.st/K9hq.png](https://0x0.st/K9hq.png) ### Comment 46232 - Author: ndrgrd - Created: 2025-11-12T11:29:41+09:00 - Points: 2 요즘은 대부분의 브라우저에 [Text Fragment](https://developer.mozilla.org/en-US/docs/Web/URI/Reference/Fragment/Text_fragments)라는 기능이 있는데 유용하게 사용하고 있습니다. 이 글의 하이라이트된 [링크](https://news.hada.io/topic?id=24310#cid46230:~:text=%ED%95%B4%EA%B2%B0%20%EA%B0%80%EB%8A%A5%ED%95%9C%20%EB%AC%B8%EC%A0%9C-,%EC%98%AC%EB%B0%94%EB%A5%B8%20%ED%85%8D%EC%8A%A4%ED%8A%B8%20%EA%B3%B5%EC%9C%A0%20%EB%B0%A9%EB%B2%95,%EC%BD%94%EB%93%9C%20%EA%B2%80%EC%83%89%EC%9D%84%20%EC%9C%84%ED%95%9C%20%EC%B5%9C%EC%84%A0%EC%9D%98%20%EB%B0%A9%EB%B2%95)로 작동하는지 확인해보세요