찍은 것을 올릴 수 있는 상태로 만드는 순서대로 묶었어요 — 열리는 포맷으로 바꾸고, 무게를 줄이고, 색을 맞추고, 여러 장을 하나로 묶고, 도달할 길을 만들어요.
아이폰이 기본으로 찍는 HEIC 는 같은 화질을 JPG 의 절반 무게로 담는 좋은 포맷이에요. 문제는 받는 쪽이에요 — 오래된 윈도우, 관공서 업로드 창, 일부 편집 프로그램이 아직 못 열어요.
그래서 «올리기 전에 JPG 로 바꾸기» 가 실무의 첫 단계가 돼요. 화질 손실이 걱정된다면 순서를 기억하세요: HEIC → JPG 변환은 한 번만 하고, 그 뒤의 크기 조정·압축은 그 JPG 하나에서 이어서 하는 게 좋아요. 변환을 두 번 거치면 그때마다 다시 인코딩돼서 손실이 쌓여요.
투명도가 필요하면 JPG 가 아니라 PNG 예요. 로고나 잘라낸 인물처럼 배경이 비어야 하는 이미지를 JPG 로 바꾸면 빈 곳이 흰색으로 채워져요.
웹에 올리는 이미지의 목표는 «최대한 예쁘게» 가 아니라 «필요한 만큼만» 이에요. 본문 사진 한 장이 3MB 면 모바일에서 그 페이지는 느려지고, 느린 페이지는 검색에서도 밀려요.
기준을 잡아 두면 매번 고민하지 않아요. 본문 이미지는 가로 1,200~1,600px, 200KB 안팎. 섬네일은 400px 대, 50KB 이하. 인쇄가 아니라면 그 이상은 대체로 낭비예요.
그리고 크기부터 줄이고 그다음에 압축하세요. 4,000px 짜리를 화질만 낮추면 여전히 무겁고 지저분해지지만, 1,600px 로 줄인 뒤 압축하면 같은 무게에서 훨씬 깨끗해요.
화면에서 예뻐 보이는 배색이 읽히지 않는 경우가 많아요. 회색 배경 위의 연회색 글씨는 디자이너의 큰 모니터에서는 멀쩡하고, 밖에서 보는 휴대폰에서는 안 보여요.
그래서 색을 고를 때 대비율을 같이 봐요. 본문 글씨는 배경과 4.5:1 이상, 큰 제목은 3:1 이상이 접근성 기준이에요. 이건 취향이 아니라 측정값이라, 눈으로 판단하지 말고 숫자를 보세요.
표기법을 오가는 일도 잦아요. 디자인 도구는 HEX, CSS 는 요즘 OKLCH 를 쓰고, 협업 문서에는 RGB 가 적혀 있어요. 같은 색을 세 표기로 옮기는 데 시간을 쓰지 않는 게 좋아요.
배색을 처음부터 만들 때는 한 색에서 파생하는 편이 안전해요. 보색은 강조 하나, 유사색은 같은 계열의 층, 삼각 배색은 셋이 각각 역할을 갖는 구성 — 감으로 고르는 것보다 관계가 명확해요.
동작을 보여줘야 하는데 영상은 과할 때 GIF 가 답이에요. 버튼을 눌렀을 때 뭐가 바뀌는지, 세 단계짜리 과정이 어떻게 흘러가는지 — 자동 재생되고 소리가 없어서 문서와 잘 맞아요.
대신 GIF 는 무거워요. 색을 256개로 줄여 저장하는 옛 포맷이라, 실사 영상을 넣으면 몇 MB 가 금방 나와요. 프레임 수와 가로 크기를 먼저 줄이는 것이 화질을 지키면서 무게를 줄이는 유일한 방법이에요.
증명사진처럼 규격이 정해진 경우는 또 달라요. 여권·비자·이력서마다 얼굴 비율과 여백이 정해져 있어서, 예쁘게 자르는 게 아니라 그 규격에 맞게 자르는 게 목적이에요.
QR 코드는 «화면 밖에서 화면 안으로» 데려오는 유일하게 확실한 방법이에요. 포스터, 명함, 전시 패널, 발표 슬라이드 — 주소를 손으로 치게 하면 대부분 안 쳐요.
인쇄할 거라면 크기를 넉넉히 잡으세요. 종이에서는 대략 한 변 2cm 이상, 그리고 코드 주변에 여백(조용한 구역)을 남겨야 인식돼요. 배경 위에 딱 붙여 놓으면 스캔이 안 되는 일이 흔해요.
코드에 넣는 주소는 짧을수록 좋아요. 긴 추적 파라미터가 붙으면 격자가 촘촘해지고, 그만큼 인쇄와 촬영 조건에 예민해져요.
편집을 대신하지 않아요. 자르고, 줄이고, 바꾸고, 재는 도구들이지 보정 도구가 아니에요.
그리고 파일을 서버로 보내지 않아요. 변환·압축·GIF 합치기가 전부 브라우저 안에서 돌아가서, 남의 사진이나 미공개 자료를 다루는 사람에게 이게 실질적인 차이예요. 업로드가 없으니 대용량 파일도 인터넷 속도에 안 묶여요.
대신 브라우저 메모리를 쓰기 때문에, 아주 큰 파일 여러 장을 한 번에 넣으면 탭이 버거워질 수 있어요. 그럴 때는 나눠서 처리하는 편이 빨라요.