서비스 URL의 중요성 및 변경의 비용

today 2016-05-18 face Posted by appkr turned_in Work & Play forum 0

웹 서비스를 하다 보면 마이그레이션을 해야 할 때가 반드시 찾아 온다. 트래픽 양이 변해서 더 큰 또는 작은 서버로 이전한다거나, 다른 프로그래밍 언어 또는 다른 프레임워크로 갈아타야 한다거나..

나에게도 찾아 왔다. 라라벨 온라인 강좌의 라이브 데모 사이트를 AWS(Amazon Web Service)에서 서비스하고 있었는데, 요금이 꽤 나와서 Github Page로 옮겼다. 회원 가입등 서버가 필요한 동적 기능은 버리고, HTML로 강좌만 서비스하는 정적 웹 페이지로 바꾸었다. 이 과정에서 어쩔 수 없이 URL을 변경했다.

변경 전 변경 후
/lessons/01-welcome.md /lessons/01-welcome.html

Jigsaw라고 하는 정적 사이트 빌더를 이용했는데, 로컬 컴퓨터에서 마크다운으로 작성한 강좌를 정적 HTML 파일로 전부 트랜스파일한 다음, Github Page에 올리는 방식이다. Jekyll을 이용한 이 블로그와 빌드 도구만 다를 뿐 똑같은 방식이다.

AWS 라이브 데모를 닫은 지 2주일 정도됐다. 사용자가 구글 검색 엔진을 통해 들어온다면, 기존의 URL은 당연히 열리지 않는 황당한 경험을 하게 된다. 구글로부터 최근에 404 응답이 많아졌다는 메일을 받았지만, 아무 생각없이 그냥 무시했었다. 커뮤니티에서 같이 활동을 하는 김종운님과 어제 대화를 나누기 전까지는 말이다.

URL이 바꼈던데, 그간에 쌓아 놓은 구글 검색 순위가 아깝지 않으세요?

김종운님

Google Search Console로 확인해 보니 다행히 그간에 검색 엔진을 통해 들어온 사용자는 그리 많지 않았고, 순위도 그리 높지 않았을 것이라 생각한다. 그러나, 2 주간 불편을 겪었을, 또 앞으로 불편을 겪을 수도 있는 사용자를 생각하면 고치지 않을 수 없었다.

이 포스트는 다음 내용을 다룬다. SEO(Search Engine Optimization, 검색 엔진 최적화)라는 관점에서 공통점이 있다.

  1. Github Page에서 URL Redirect를 구현한 로그
  2. SEO 관점에서 URL의 중요성 및 일반적인 URL Rewrite 방법

Git Flow

today 2016-05-04 face Posted by appkr turned_in Work & Play forum 0

Git Flow 는 Vincent Driessen이 제안한 깃 브랜칭 전략을 실행할 수 있도록 돕는 Git 확장 프로그램이다. 이 전략은 masterdevelop을 각각 배포 및 개발 브랜치로 사용하면서, feature, release, hotfix 등을 위한 임시 브랜치를 사용한다.

아래 그림은 Git을 소개하는 웹 문서나 서적에서 한번은 본 그림일 것이다. 많은 개발자들이 이 전략을 모범 사례로 인식하고, 따르고 있다는 방증이다.

이 포스트는 Git Flow의 기본적인 사용법을 담고 있다. 사실 여기 수록한 내용이 전부인 듯 하다.

소프트웨어 개발 비용

today 2016-04-27 face Posted by appkr turned_in Learn & Think forum 0

소프트웨어 개발 비용은 ‘돈’ 보다는 ‘시간’의 의미가 더 크다. 개발 비용은 크게 보면 다음 세 가지로 구분할 수 있다.

  1. 도입 비용
  2. 수정 비용
  3. 소유 비용

각 비용을 적절히 배분해야 전체 비용이 줄어든다. 가령, 성공을 확신할 수 없는 새 제품이나 서비스를 개발하는데, 오버 엔지니어링해서 많은 도입 비용을 쓰는 사례를 들 수 있다. 또는 도입 비용을 너무 싸게 예측해서 급히 개발했는데, 시장 반응이 좋은 상황이다. 분명 개발의 훌륭함보다는 아이템의 승리다. 수정해야하는데, 팀의 빨리빨리 문화에 회의를 느낀 초기 개발자는 회사를 떠났고, 스파게티 코드만 남아 누구도 손댈 수 없는 사례도 생각해 볼 수 있다. 내 일천한 경험에 비추어 보면 이런 코드로 램프 업한 사업은 곧 망하더라(대규모 투자를 받아 팀을 리빌드한 경우는 제외).

깃(git)을 꽤 오랫동안 썼지만 잘 모르는 기능 중에 하나가 리베이스(rebase)다. 사실 리베이스를 할 줄 알고 모름에 따라, 초급과 중급으로 구분된다고 해도 과언이 아니다. 리베이스를 꽤 오랫동안 썼지만, 주로 하는 것은 커밋 합치기(fixup, or squash)와 커밋 메시지 바꾸기(reword) 정도였다.

이번에 예전에 커밋한 내용을 수정할 일이 있어서 수정(edit) 기능을 처음 써봤다. 최종 목표는 이렇다.

  1. 이전에 커밋한 내용을 수정하고, 그 뒤에 연속되는 커밋에 변경 내용을 모두 반영한다.
  2. 리베이스하기 전의 전체 커밋 로그를 리베이스 후에도 그대로 유지한다.

말로는 쉬워보이지만, 2번이 정말 어려웠다.

예를 들어, foo -> bar -> baz 커밋 로그가 있다고 하자. 리베이스로 foo 커밋의 내용을 수정했는데 bar에서 충돌이 발생했다. bar 커밋에서 발생한 충돌을 해결하고 나면, bar 커밋은 foo 커밋으로 합쳐지고, bar 커밋 로그는 남지 않는다.

‘최종 커밋만 있으면 되지~’, ‘중간 커밋을 살리는 것이 무슨 의미가…?’라는 의문이 생길 수 있다. 맞다. 최종 커밋만 있으면 된다. 그런데, 나는 이번에 나올 책에서 챕터별로 예제 코드를 커밋했고, 커밋 로그 하나가 사라지면 챕터에 해당하는 소스코드의 이력이 사라지기 때문에 이 문제를 꼭 해결해야만 했다.

이 고생을 한 이유는 책을 쓰는 도중 라라벨 프레임워크의 수버전이(유의적 버전은 주.부.수로 쓴다) 변경되었고, 이번 버전 업에서는 라우트 사용법이 변경되었기 때문이다. 라우트는 웹 서버와 라라벨의 경계에 해당하는 부분이라 아주 아주 아주 중요할뿐더러, 책의 가장 첫 부분이기도 하다. 독자들은 새 버전의 프레임워크로 프로젝트를 시작할테고, 바뀐 사용법을 적용하지 않으면 책의 시작부터 작동하지 않는 소스코드를 만나게 되는 셈이다.

어쨌든… 이 포스트는 이 문제점을 해결한 이력이다.

엄청나게 빠른 버그 감지, 디버그, 코드 배포

today 2016-03-03 face Posted by appkr turned_in Work & Play forum 0

어제 있었던 일이다. 저녁에 있을 모임에 나가기 위해 하던 일을 슬슬 정리하려던 차였다. 그런데, 슬랙으로 날아온 버그 메시지. 버그를 감지하고 바로 고친후 프로덕션에 배포했는데, 이 모든 과정이 딱 10분 걸렸다. 어떻게 가능했을까?

이 포스트는

  • 라라벨1 프레임워크의 우수성을 알린다.
  • 가난한 개발자가 자신의 서비스를 지키는 방법과 몇가지 개발 도구를 소개한다.

라는 목적을 가진다. (이 블로그의 포스트들의 방문자가 갑자기 많아졌다. 그래서 웃고 운다.)

이 포스트의 대상이 되는 프로젝트는 내가 쓴 라라벨 5 온라인 강좌임을 미리 밝힌다. 해당 강좌를 통해 개발한 최종 결과물은 현재 아마존웹서비스(AWS)에서 올려 라이브데모라며 서비스하는데, 이 포스트는 라이브데모의 방문자 중 한분이 겪은 문제에 대한 해결 이력이다. 그런데 불편함을 겪었던 그 분은 ‘그냥 안되네~’라며 페이지를 떠나신 것 같다. 내 메일 주소를 찾아 가면서 문제점을 기술(description)하면서 고쳐달라고 말하는 친절을 베풀지는 않았지만, 버그를 만들어 주셨으니 나한테는 고마운 분이다.

이 포스트의 내용과는 조금은 다른 관점인데.. 서비스에 문제가 생겼을 때 사용자가 별 노력 없이도 문제점을 개발자에게 알릴 수 있는 사용자인터페이스(UI)나 장치를 만드는 것도, 서비스의 품질을 높일 수 있는 좋은 방법이다. 이런 옵트인(opt-in) 방식의 리포팅은 팝업 형태로 표시되어 사용자의 동의를 받아 전송하는 것이 일반적이다.

가능한 모든 경우의 수를 따져서 개발자는 프로그래밍하고 테스트를 하려고 하지만, 세상에 ‘완벽’이란 단어는 없다. 구현이 조금 부족하고 테스트가 덜 됐을 수 있지만, 버그를 리포팅하는 장치를 프로그램에 심어서 배포하고, 리포트된 버그를 분석하고 코드를 고쳐서 빠르게 안정화하며, 초기 사용자의 반응을 관찰하는 것이 더 낫다는 것이 나의 생각이다. 완벽주의 개발자들로 포진된 스타트업들이 오버 엔지니어링을 하다가 실기(失期)하는 사례를 여러번 봤다.

keyboard_arrow_up