2016년 4월 24일 일요일

시각적 검사 기계화

시각적 검사 기계화

안 읽고 묵혀둔 글 중에 디자인 어쩌구 하는 것들을 추려서 그 사이 낡았거나 관련성이 떨어진다 싶은 걸 정리했다.

그 와중에 자주 보이는 주제가 있었다. ‘~에서는 이렇게 디자인 해라 / 하지 마라’며 지침서를 자임하는 내용. 읽어보면 다들 좋은 말이다. 행간을 잘 구분해서 읽기 좋게 하고 네모와 동그라미를 같이 쓸 때는 시각적인 차이를 고려하고 그리드 배치가 어떻고 응답형이 되려면 어떤 패턴인 게 좋고 운운. 그걸 따르면 좋겠지만 막상 결과물이 그렇게 다 맞춰지긴 어렵다.

애초에 그걸 사람이 하나씩 기억해서 맞출 게 아니라 작업 도구가 보조해줘야 맞잖은가.
예시라고 하긴 모자라지만 맥 환경의 파워포인트에 해당하는 키노트의 경우에 뭘 하나 마우스로 끌어서 움직이면 주변의 다른 것들과 수직 혹은 수평에 가까워질 경우 노란 실선으로 일치되었음을 알려준다.

또, 아주 고급 편집기라고 할 수 있는 IDE라는 도구에는 글자를 잔뜩 쳐야 할 때 현재 문맥에 맞는 일종의 단어 후보들을 보여주거나 아예 문장 구조를 미리 맞춰서 그 안에 단어만 끼워넣도록 하는 기능이 있다. 같은 단어를 쓰는 다른 단락을 찾아 보여주거나 하는 것도 된다.
여기까지 생각이 미치고서 검색을 해보았다. 그래, 구글이 있었지, 참.

설명을 보면 시각적인 면을 세세하고 화려한 수준까지는 검토하지 않는 것 같다. 구글이 굳이 그렇게까지 할 필요는 없겠지.
디자인을 시각적인 면으로 접근하는 사람들이라면 구글보다 한 단계 더 들어가 기계적으로 결과물에 대한 시각적으로 복잡한 평가를 할 수 있다는 사실을 깨달아야 한다.
색 배합의 경우엔 적절한 색상을 제시해주는 도구가 많이 나와 있다. 사람이 만든 색 배합이 얼마나 좋고 나쁜지 사후 평가하는 것도 어렵지 않을 것이다.
가령 폰트를 만들어내는 사람이 디자인의 좋고 나쁨을 ‘판별하기 위해서는 글자가 인쇄된 종이를 잘라서 직접 배치해보는 훈련 등으로 여백(흰 공간)을 적절히 분배시키고, 조절하는 능력’이 있어야 하는 건 당연한 말이지만 그걸 매번 작업 때마다 사람이 ‘서체마다 값이 다르기 때문에 문자의 조합을 전부 눈으로 검사하는 과정이 필요합니다. 엑센트나 예외의 변수가 생기면 그 경우의 수가 훨씬 늘어나서 한 벌의 서체를 만드는데 보통 6개월에서 1년의 기간이 소요’되게 하는 건 너무했다. 당신이 눈으로 보고 머릿속으로 계산하는 걸 당신이 매일 쓰고 있을 컴퓨터는 훨씬 빨리 더 정확하게 해낼 수 있다. 그런 거 하려고 인류가 그 기계를 만들어낸 거다. 일을 시켜라.


https://www.youtube.com/watch?v=bcUo9ULvVq4
Project Faces - Adobe MAX 2015 - Sneak Peeks | Adobe Creative Cloud
어도브는 아예 폰트 자체를 실시간으로 만드는 도구를 보여줬다.

iKern이라는 프로젝트를 보면 자동 커닝을 처리하고, https://github.com/google/fonts/blob/master/ofl/cabin/METADATA.pb 에 기록이 있는 것으로 보아 실제 동작하는 결과물도 나와 있는 것 같다.
지켜야 할 원칙을 나열할 수 있다면, 애초에 모든 중간 과정이 디지털 기기 안에 논리적인 계산기로 처리되는 이 시대에 그 원칙 자체도 과정의 일부로 포함하지 못할 이유가 없다. 이래라 저래라 하지만 말고 그럴 수 있는 작업 도구를 만들 궁리를 해라.



디자이너로 치면 “재능 있는 디자이너라면 누구나 자신에게 꼭 맞는 포토샵 대체품을 만들어볼 마음을 품는다” 같은 얘기가 되며, 악기 연주자로 치면 “누구나 자신에게 꼭 맞는 악기를 만들어볼 마음을 품는다” 같은 얘기가 된다.

2016년 4월 6일 수요일

AWS Elasticsearch 서비스 기반으로 자체 도메인에서 검색 기능 제공

  1. ES 도메인 생성
  2. API Gateway 생성
  3. ES endpoint를 API Gateway에 연결하고 Request와 Response에서 필요한 형태로 transform 템플릿 적용
  4. Certificate Manager에서 사용할 도메인 생성
  5. CloudFront 생성
  6. CloudFront에 API Gateway의 endpoint를 Origin으로 지정
  7. CloudFront CNAME 항목에 앞서 생성한 도메인을 적용