텍스트 스크린샷이 싫어요

 (parkscomputing.com)
5P by GN⁺ | ★ favorite | 댓글 4개
  • 일상적인 업무 중 동료들로부터 텍스트를 스크린샷으로 찍어 보내는 경우가 빈번하며, 이는 코드 검색과 컨텍스트 파악을 극도로 어렵게 만드는 비효율적 방식
  • 스크린샷으로 받은 코드는 변수 정의, 모듈 위치, 예외 처리 등의 맥락을 전혀 알 수 없어, 검색창에 일일이 타이핑하거나 코딩 에이전트를 동원해야 함
  • 빌드 오류 로그를 스크린샷으로 보낼 경우, 빌드 대상, 실패 라인, 정확한 에러 메시지를 알 수 없어 문제 해결이 불가능
  • 텍스트 복사-붙여넣기나 파일/GitHub 링크 공유를 사용하면 IDE 검색 기능 활용과 전체 컨텍스트 확인이 가능해짐
  • 화면 표시 관련 문제가 아닌 이상, 텍스트는 스크린샷이 아닌 복사 가능한 형태로 공유해야 협업 효율성 확보

스크린샷 문제 사례 1: 코드

  • 동료로부터 코드 관련 이슈 논의 시 코드 스크린샷을 받게 됨
    • slug 변수 정의, baseUrl 생성 방식, 도메인 하드코딩 이유, 예외 처리 방식, 해당 모듈 위치 등 핵심 컨텍스트를 전혀 파악 불가
    • 스크린샷 속 코드를 검색창에 수동으로 타이핑하거나 코딩 에이전트를 사용해 관련 모듈을 찾아야 함
  • 복사-붙여넣기를 사용하면 동일한 라인이라도 더 많은 컨텍스트 확인 가능하며, IDE 검색 기능에 바로 붙여넣기 가능
  • 파일 자체나 GitHub 링크를 공유하는 것이 훨씬 효율적

스크린샷 문제 사례 2: 빌드 오류 로그

  • "빌드가 실패했는데 확인해줄 수 있나요?"라는 요청과 함께 오류 로그 스크린샷 수신
    • 무엇을 빌드했는지, 어느 라인에서 실패했는지, 정확한 에러 메시지가 무엇인지 전혀 알 수 없음
    • 본인 워크스테이션에서 전체 리빌드를 수행하면 성공하는 경우 발생
  • 전체 에러 로그를 복사하거나 로그를 파일로 덤프해서 보내면 간단히 해결 가능한 문제

올바른 텍스트 공유 방법

  • 텍스트를 스크린샷으로 보내지 말고, 복사 가능한 형태로 공유할 것
  • 스크린샷은 화면 표시의 미적 문제를 보여주거나, 순수 텍스트로는 손실되는 관련 정보가 있을 때만 사용
  • 파일 공유나 GitHub 링크 제공이 컨텍스트 파악과 코드 검색을 위한 최선의 방법
GeekNews Weekly에 포함된 글입니다. 에디터 코멘트 보기

함께 보면 좋은 글 β

tested   [-]

캡처했을 때 에디터에서 보여지는 가독성과 OS에서 기본 지원하는 캡처 단축키의 간편함을 이유로 코드를 캡처해서 올릴 때도 있는데

단축키 하나로 캡처된 이미지의 코드를 외부에 공유할 수 있는 Text fragments 등의 링크로 만들어주고 바로 붙여 넣을 수 있는 프로그램이 있으면 그걸 사용할 것 같네요.

Slack에 올렸을 때 미리보기로 보여주고 링크를 타고 들어가서 코드를 복사할 수 있게끔

답변달기
ndrgrd   [-]

요즘은 대부분의 브라우저에 Text Fragment라는 기능이 있는데 유용하게 사용하고 있습니다.

이 글의 하이라이트된 링크로 작동하는지 확인해보세요

답변달기
kunggom   [-]

어그로를 끌어보기 위해, 코드를 보기에 예쁜 이미지 스크린샷으로 바꿔주는 사이트를 드리겠습니다. ㅌㅌㅌ

https://ray.so/

저도 메신저나 메일로 뭐 보낼 때 최대한 텍스트 위주로만 사용하고 있긴 한데, 사실 경우에 따라서는 텍스트만 사용하는 쪽이 오히려 더 불편할 수도 있긴 하죠.
그에 비하여 스크린샷 캡쳐는 대충 단축키 하나 누르고 화면 긁은 다음 붙여넣기하는 것만으로 GUI 상에서 처리가 되니까, 보내는 입장에서는 더 편하게 느껴지긴 할 겁니다.
하지만 본문에서도 지적했듯이, 그걸 받는 입장에서는 스크린샷만으로 맥락이 다 전달되지도 않는 경우도 많고 검색이나 복사-붙여넣기 또한 불편하니까 불만이 생기는 것이라 생각합니다. 데이터 전송과 저장에 원래 필요한 것보다 훨씬 큰 오버헤드가 생긴다는 건 둘째치고라도 말이죠.
뭐 개인적으로 이런 걸 하나하나 따지자면 사내에서 내부 문서화를 위키 대신 워드 파일로 한다던가 하는 뭐 그런 것부터가 불만이기는 한데…

답변달기
GN⁺   [-]
Hacker News 의견

  • 다른 댓글에서도 언급되었듯이, Apple 플랫폼의 자동 OCR 기능은 정말 혁신적임
    이런 기능은 모든 플랫폼의 문서 뷰어에 기본으로 들어가야 한다고 생각함
    또 하나 바라는 점은 스크린샷에 메타데이터를 포함하는 것임. 예를 들어 인스타그램 사진을 캡처하면 해당 URL이 포함되고, 브라우저에서는 현재 보고 있는 URL과 DOM 경로, 지도 앱에서는 좌표, PDF 뷰어에서는 문서의 SHA1 해시와 오프셋을 포함하는 식임
    물론 프라이버시 문제는 있겠지만, 이런 아이디어는 이미 학계에서 다뤄졌을 것이라 생각함
    요즘은 파일 개념이 추상화되어서, 스크린샷이 모바일 컴퓨팅 시대의 공통 언어가 된 느낌임
    참고로 Screenshot Conf도 꼭 언급하고 싶음

    • 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

  • 내가 쓴 글 ‘Slack에서 도움 요청하는 법’의 7번째 규칙은 “텍스트 스크린샷을 올리지 말 것”임
    Apple의 OCR이 좋아도 검색 불가능성 문제는 여전함
    원문 링크

    • 하지만 Spotlight와 Photos는 스크린샷 속 텍스트도 검색 가능함

  • 나는 전체 문서나 코드 링크를 함께 보내면서, 관련 부분의 스크린샷도 첨부하는 방식을 선호함
    시각적 맥락이 남아 있어서 나중에 다시 볼 때 기억이 더 잘 남음

  • 신입 개발자들이 처음 몇 주 동안 자주 텍스트 스크린샷을 공유함
    하지만 모바일에서 읽기 불편하고, Slack은 이미지를 압축해서 확대도 안 됨
    그래서 결국 대부분은 텍스트로 공유하는 법을 배우게 됨

  • MS Teams에서는 코드 블록 지원이 너무 나빠서 스크린샷을 쓰는 경우가 많음

    • 나는 팀원들에게 Teams에서 Markdown 코드 블록 만드는 법을 가르치고 있음
      기능은 있지만 잘 드러나 있지 않음
    • Teams에서 스크린샷을 보면, 대부분 다른 채팅의 대화 일부를 캡처한 것임

  • 스크린샷은 빠르고 일관된 방법임
    웹앱, 네이티브 앱, 사이트 등 어디서나 같은 방식으로 작동함
    받는 사람에겐 불편할 수 있지만, 보내는 입장에서는 효율적임

  • 나는 Linux에서 xfce4-screenshooter의 사용자 정의 동작을 tesseract OCR 스크립트로 연결해둠
    선택 영역을 캡처하면 자동으로 텍스트가 클립보드에 복사됨
    인식이 어려운 경우에는 Gemma3-4B + llama.cpp를 사용함

답변달기