[카테고리:] 작게 기록

대충대충 대강대강 써내려가는 글.

  • 콘텐츠 입장에서 구성하고 작성하라

    철저히 콘텐츠 입장에서 콘텐츠가 보이는 사람에게 어떻게 전달될지 고민하라. 내가 보는 콘텐츠 관점을 버려라. ‘내’가 콘텐츠를 관리하는 주체라고 생각하여 콘텐츠를 보는 사람과 콘텐츠 사이에 중개체로 나를 끼우는 것은 곤란하다.

    언제나 콘텐츠 스스로가 콘텐츠의 관점에서 스스로의 정보를 설명하게 하라. 내가 그 콘텐츠라면? 나를 소개하는 설명서가 이 콘텐츠라면? 이라고 상상해보자.

  • ownCloud에서 NextCloud로 전환

    둘이 은근히 비슷한 점이 있는 것 같은데… ownCloud보다 NextCloud가 훨씬 더 많은 것을 할 수 있는 것 같다. 이제 ownCloud 보다 NextCloud를 사용한다.

  • 혼잣말

    당뇨는 습관의 질병.

  • 혼잣말

    즐거운 삶을 살자.

  • 혼잣말

    나는 뮐 위해 사는 건지?

  • 혼잣말

    검색엔진이 사랑하는 내 블로그. 아니 검색엔진만 사랑하는 내 블로그. ㅋㅋ.

  • 혼잣말

    나는 귀찮은 것이 싫다. 뭐든 대충대충 하는 것이 좋다.

  • 워드프레스 코어 #3

    2020년 08월 04일 네번째 모임 발표 자료

    워드프레스 데이터베이스와 회원 로그인에 대한 자료입니다.

    슬라이드 링크

  • 워드프레스 개발자 관련 커뮤니티를 만들고 싶습니다

    강력한 워드프레스 개발자 커뮤니티를 구축하고 싶습니다.

    워드프레스 개발자니까 기반은 워드프레스로 작성하고 싶습니다. 탄탄한 사이트를 원합니다. 그래서 테마와 플러그인은 직접 개발하고 싶습니다. 개발자끼리 정보를 공유하고 개발 관련 이슈를 많이 논하는 커뮤니티로 만들고 싶습니다.

  • 내가 CPT UI나 ACF를 싫어하는 이유

    CPT UI의 문제점

    CPT UI를 쓰면 커스텀 포스트나 택소노미를 빠르게 생성할 수 있다. 하지만 빠른 것이 무조건 좋은 것만은 아니다. 콘텐츠의 성격이 커스텀 포스트로 잘 반영되어야 한다. 즉 커스텀 포스트 생성시 여러 속성을 통해 조절해야만 하지만 UI로 접근하는 사람들은 그런 디테일을 잘 고려하지 않는다.

    다만 CPT UI에서는 충분히 그런 디테일을 제공한다. 누차 얘기하지만 툴을 비난하는 것이 아니다. 나는 쓰는 사람들의 무심함을 꼬집어 이야기하고 싶은 것이다. 대개 이 플러그인을 쓰는 사람들은 디테일에 지나치게 무심하다.

    이름, 여러 레이블, 공개 여부, 쿼리 변수나 다시쓰기 슬러그, 위계성, 편집 화면의 지원 요소, 그리고 RSS 피드 제공 여부… 많은 요소들이 있지 않은가?

    한편 택소노미와 포스트 타입 생성을 위한 파라미터들은 정형화되어 있으므로 적절히 샘플 코드 정도로 을 만들어 두면 된다. 조금 길어 보일 수는 있어도 콘텐츠에 대한 상세한 고려를 위해서는 이렇게 하는 것이 좋다. 또 다르지만 비슷한 타입들도 굳이 UI를 통해 일일이 클릭하는 것보다는 코드로 빠르게 복제하는 것이 능률적이다. 굳이 플러그인까지 도입해서 처리해야 만들어야 하는 건지?

    ACF의 문제점

    ACF는 CPT UI보다 문제가 심각하다. ACF를 사용하면 나름 깔끔한 관리자 UI를 생성할 수 있다. 그러나 쉽고 편한 것이 반드시 좋다고 말하기는 어렵다. 사이트의 기능이 많고 복잡할수록 ACF는 그 복잡합을 더 증가시킨다.

    ACF의 가장 나쁜 점은 코드 곳곳에 흐름의 공백을 만들어낸다는 점이다. 개발자는 코드를 보면서, 코드의 흐름을 따라가면서 프로그램을 완성시킨다. ACF가 생성하는 커스텀 필드는 그 실체가 모두 데이터베이스에 저장되어 있다. 그래서 커스텀 필드를 이해하려면 관리자 페이지에서 ACF UI를 보면서 그 설계를 이해해야만 한다. 코드를 읽다가 UI로 넘어가는 일이 잦다는 점. 사이트가 커지면 커질 수록 이 문제는 점차 감당하기 쉽지 않게 된다.

    또한 데이터와 UI가 ACF에서 강하게 결합되어 버린다. 대개 ACF의 유연한 옵션 때문에 일반적으로는 나름 괜찮은 UI로 결론이 나지만, 때때로 복잡하거나 특정한 상황에서는 좀 더 효율적인 형태로 만들어져야 할 때가 있다. 그럴때 ACF는 개발자의 창의력을 붙잡아버린다. 더 이상의 무엇이 나오지 않는 것이다.

    뭐가 불만이었니?

    CPT UI, ACF(Advnced Custom Field)는 워드프레스 개발하면서 많이 찾는 플러그인이고, 인기 있는 플러그인이다. 둘을 쓰면 쉽고 빠른 제작에 도움이 된다.

    그러나 그럼에도 불구하고 나는 CPT UI, ACF를 좋아하지 않는다. 아, 그러나 오해는 없기를 바란다. 나는 그 두 플러그인 제작자에 대한 폄하는 추호도 없다. 내 호불호를 떠나 객관적으로 이 둘은 멋진 플러그인이다. 진심으로 나도 이런 플러그인을 만들면 좋겠다. 비유를 들면 CPT UI, ACF는 마치 칼 같은 그저 도구라는 것. 이 칼들에 그렇게 심각한 문제가 있다고는 생각하지 않는다. 다만 이 칼이 너무나 무분별하게 남용하고 있다는 것.

    이들은 작은 웹사이트, 혹은 사이트의 소유자가 직접 관리하면서 개발하려는 의지가 있을 때 엄청난 축복이다. 그러나 웹사이트를 전문적으로 제작하려는 사람, 좀 더 고도화된 기능을 개발하려는 사람에게는 이들은 좋은 옵션이 될 수 없다고 생각한다. 불행하게도 나는 후자에 있고, 후자의 시선으로 판단하기에 이런 의견을 블로그에 포스팅하는 것이다.

  • 보호된 글: 배철수의 음악캠프 30주년 Live at the BBC 녹음본

    이 콘텐츠는 비밀번호로 보호되어 있습니다. 이 콘텐츠를 보려면 아래에 비밀번호를 입력해주세요:

  • 워드프레스 개발 키워드: 문자열

    프로그래밍에서 상수와 참조는 중요하다. 변하지 않는다는 약속을 하는 상수는 에러로 가득한 코드에서 유일한 희망이고, 참조는 효율적인 관리를 위한 기본이다.

    그런데 곰곰히 생각하면 상수은 변하지 않는다는 약속을 전제로 정의하긴 하지만, 그 기반이 부서지면 상수는 효력을 발휘하기 어렵다. 참조 또한 마찬가지. 참조의 대상이 되는 원본이 변화하는 상황이면 참조는 신뢰를 잃게 된다.

    데이터베이스는 ID, 주 키 (primary key)를 기준으로 참조를 진행한다. 해당 데이터베이스 상에서는 유일한 식별자이기 때문에 의미가 있다. 그러나 워드프레스 입장에서 볼 때 이것이 유일하다는 보장을 하기 어렵다. 여러 워드프레스 사이트가 있다고 하자. 각 사이트끼리 비슷한 DB 테이블 구조와 스키마를 가지고 있다. 사이트간에는 이런 ID는 큰 의미가 없다. 그 레코드의 유일함을 보장할 수 없기 때문이다.

    그러므로 우리는 워드프레스에서 유사한 개체임을 식별하기 위한 수단으로 문자열을 사용하게 된다. 텀에서는 슬러그, 포스트에서는 메타 키나 포스트 타입을 이용하게 된다.

    결국 이런 것들은 문자열이다. 규약은 사람들의 약속으로 이뤄지며 중복의 방지는 제안하는 이가 최대한 중복되지 않도록 노력해야 한다.

    개발을 진행하며 플러그인과 테마를 개발할 때도 이 사실은 매우 중요하다. OOP나 기타 세련된 개발 기법을 적용할 때 이 관점을 잘 녹여내는 것이 매우 중요하다. 워드프레스가 가진 기능을 액션, 필터의 콜백을 이용해 확장할 시 깔끔하게 각각의 기능을 모듈화하는 것이 매우 어려워 보인다. 결국 이런 기능들이 여러 조각으로 분산되며 프로그래머들은 이런 분산이 불편해 보일 수도 있다.

    그러나 완벽한 구조는 존재하지 않는다. 워드프레스의 기본은 결국 문자열도 된 식별자이다. 정의된 문자열에 의한 식별자를 통해 각각의 모듈은 서로 교차되고 상호 작용할 수 있다고 생각해야 한다.

  • 테마 만지는 거 재밌네

    요즘 내 블로그에 이것저것 건드리는 게 많아졌다. 테마를 TwentyTwenty로 바꾸고 나서 여러 가지 바꾸고 있다. 일단 이 테마, 글씨가 커도 너무 크다. 장난하나? 싶을 정도로 크다. 글씨 크기 좀 조정하고 색상 같은 것 좀 취향에 맞게 바꾸고 스크린샷을 찍었다. 블로그 기념 사진 같은 걸로 해서 남겨 둬야지.

    (더 보기…)
  • 지메일의 ‘별’ 기능으로 이메일 업무 효율 늘리기

    지메일 > 설정 > 기본 설정에 보면 아래 그림처럼 “별” 항목이 있습니다. 별을 클릭하면 순서가 변경되는데, 이 별을 잘 활용하면 이메일 업무 효율이 상당히 좋아집니다. 요령을 간단하게 기록해 둡니다. 유용하게 활용되었으면 좋겠습니다.

    (더 보기…)
  • 옵션 테이블을 수동으로 정리해 보다

    블로그를 운영하는 서버가 열악해서 블로그 또한 가능한 만큼 가볍게 만들어야 한다. 그러나 운영한 기간만큼은 꽤 되어서 이런저런 시도를 꽤 했었다고 기억한다. 과연 사용량에 비해 옵션 테이블의 사이즈가 너무 커 보였다.

    옵션테이블을 직접 수동으로 점검하고 정리해 봤다. 도대체 그동안 어떤 찌꺼기들이 사라지지 않고 고스란히 남아서 성능에 영향을 준 것인가? 대부분의 플러그인과 테마들은 삭제되면서 자신의 옵션을 철저하게 지우지 않는 편이다. 애초에 테마는 삭제 옵션이 없기도 하고. 대략 옵션 이름을 보면서 없어진 플러그인에서 사용했던 것들은 다 지워 보았다.

    물론 프로그래머가 플러그인에서 필요하니까 옵션을 사용하지만, 좀 과한 것들이 있다. 우선 젯팩. 옵션이 젯팩 투성이였다. Enlighter 라는 코드 하이라이트 플러그인도 심각했다. 너무 많은 옵션 항목을 생성하고 있다. 그리고 테마. 테마를 이것저것 설치하고 활성하면 그 테마의 옵션, 테마가 만드는 위젯 등등 여러 값들이 생성된다.

    그리고 이 값들이 지워지지 않고 영속하고 있다. 이게 문제였다. 그동안 재미삼아 여러 테마, 플러그인을 깔고 지우고를 반복했다. 그 결과 꽤 사용하지도 않지만 남아 있는 옵션들이 테이블 안에 덕지덕지 남아 있었고, 이런 값들이 워드프레스 로딩 때 같이 불려오고 있었다.

    모든 값들을 다 알고 고칠 수 없겠지만 대략 접두사로 추측하여 불필요한 옵션들을 제거했다. 그리고 젯팩과 Enlighter도 사용을 해제하고 옵션 테이블에서 값을 제거해 봤다. 그 결과 관리자 페이지에서도 페이지 로딩이 좀 더 빨라진 느낌이 든다. 아마도 젯팩이 제거되어 퍼포먼스 향상이 더 컸을지도. 제대로 퍼포먼스를 비교하면서 체계적으로 진행한 것이 아니니까 확신하기는 어렵다. 그러나 옵션값을 정리한 것이 나름 의미는 있을 것으로 보인다. 한 번 실험해 볼 만한 주제가 되지 않을까?

  • 워드프레스 개발자로 고인물

    다른 분야의 개발자들이 얼마나 치열하게 사는지 모른다. 그들의 전문 지식은 어떤 것들인지 또 어떤 일들을 하는지 모른 채 살고 있다.

    CMS 하나로도 의미가 있을 수도 있을 것이다. 또한 모든 것을 알 수는 없겠지만, 너무 모른 채 살고 있는 것 같다.

  • 미립자팁: 플러그인 설문 폼 안 보고 비활성화하기

    가끔 보면 플러그인 비활성화 할 때 순순히 비활성화가 되지 않고 어떤 설문 폼을 띄우는 녀석들이 있다. 이런 녀석들의 귀찮은 설문 폼을 안 보고 비활성화하는 방법이 하나 있긴 하다.

    (더 보기…)
  • 내 이메일이 이렇게 많이 털렸구나!

    내 이메일이 이렇게 많이 털렸구나!

    패스워드에 좀 더 주의를 기울여야 한다는 자극을 받아 포스팅한다. 이전 포스트 [워드펜스 “유출된 패스워드” 경고를 실제 체험하다]에 이은 포스트이다. 최근 파이어폭스 웹브라우저를 다시 셋팅하면서 이런 배너를 발견하였다.

    (더 보기…)
  • 워드펜스 “유출된 패스워드” 경고를 실제 체험하다

    워드펜스 “유출된 패스워드” 경고를 실제 체험하다

    워드프레스의 유명한 보안 플러그인 워드펜스, 이 플러그인의 보안 옵션 중 유출된 패스워드에 대한 무작위 대입 방지 옵션이 있다.

    보안 사고로 인해 유출된 패스워드를 사용하지 못하게 하는 옵션이 존재한다.

    이 옵션을 체크하면 포스트 대표 이미지처럼 패스워드 변경시 에러를 만나게 된다. 솔직히 그동안 이 옵션이 귀찮았고 왜 굳이 써야 하는지 몰랐다, 오늘까지는.

    (더 보기…)