IT/모바일
제공 : 한빛 네트워크
저자 : Simon St. Laurent
역자 : 조석규
원문 : Restructuring the Web with Git
웹 디자이너? Git? Github? 프로그래머용이 아닌가? Christopher Schmitt는 Artifact 컨퍼런스에서 얼마나 많은 동료 디자이너들이 Github를 쓰고 있고, 그걸로 뭘 더 할 수 있는지 발표했다. Github(그리고 아래의 Git 도구들)은 모든 종류의 사람들이 함께 일하는 방식을 바꿨다.
Git으로 공유하기
Git은 리눅스가 그랬던 것처럼 Linus Torvalds가 컴퓨터 세상에 공헌한 가장 중요한 일이라고 생각해왔다. 많은 사람들이 그저 소스 코드를 관리하는 도구라고 생각할 것이지만, Git은 분산된 환경의 프로젝트, 특히 텍스트를 사용하는 것들을 관리하는데 극단적으로 다른 (내 생각엔 훨씬 더 나은) 많은 것들을 할 수가 있다.
Git은 사람이 만들어낸 느슨하게 구조화된 문서들을 다루는 불편한 문제와 씨름한다. 텍스트 파일은 믿을 수 없을 정도로 유연해서, 아무거나 쓴 메모부터 형식이 꽉 짜여진 코드까지 모든 것을 저장할 수 있다. 텍스트 파일은 놀랍게도 읽고, 검색하고, 상대적으로 처리하기 편한 만큼, 양이 많아졌을 때, 엉망진창이 되는 경향이 있다.
[명령줄과 Git에 대한 Schmitt의 발표에 기반한 그림]
버전 관리 도구는 이런 문제를 누가 어떤 파일에 뭘 했는지 추적해서 정리해준다. 구형 버전 관리 도구는 체크인, 체크아웃이라는 개념으로 접근했다. 파일에 접근할 수 있는 사람을 제한하는 것으로 문제가 생기는 것을 방지한 것이다. 시간이 지나자, 그것은 필요없는 구속이고, diff를 이용하여 뭐가 실제로 바뀌었는지 보는 것이 더 명확하다는 것이 밝혀졌다.
Git은 이 논리를 더 발전시켜서, 중앙집중화되지 않은 구조를 만들어 사람들이 네트워크로 연결되지 않아도 사용할 수 있게 했다. 처음엔, 몇몇 하드코어 프로그래머들이 쓰는 복잡한 시스템(리눅스 커널이나 그 전용 드라이버 같은 거)에서나 필요할 것 같았다. Schmitt는 git 브랜치를 강조했다. 여전히 마스터, 배포 브랜치가 있지만, 그걸 배포할 필요는 없다. 자유롭게 브랜치를 만들고, 받아오고, 머지와 풀 요청을 통해 다른 사람들과 소통할 수 있다.
하지만, 하지만… 충돌이 난다! 충돌은 프로그래머가 처리하는 거 아닌가? 아니다. 그 파일에서 충돌이 나는 변경점이 뭔지 잘 알고 있는 사람이 처리하면 된다. 그게 코드라면, 프로그래머가 필요하다. HTML이나 CSS라면 대신에 웹 개발자가 필요할 것이고, 책에 들어갈 내용이라면, 저자나 편집자가 필요할 것이다.
데이터베이스는 어디에 있지? CMS는 또 어디에?
Git은 자체적인 데이터 구조로 돌아가는데, 데이터베이스나 XML과 전혀 비슷하지도 않다. Git은 사용자가 그 구조를 이해할 것이라 예상하지 않는다. 대신 그 안에 들어가는 것은 사용자가 알고 있는 구조로 되어있고, 사용자가 그 안에 들어가는 것들을 체크할 것이라 생각한다 Git은 누가, 뭘, 언제 바꿨는지 추적할 것이다.
대부분 데이터베이스와 다르게, 이미 있는 정보를 갱실할 때 있던 것이 지워지지 않는다. Git은 변경점을 추적한다. 돌아가기를 원치 않을 수도 있고, 돌아갈 필요가 있을수 도 있고, 돌아갈 수 있다. 심지어 다른 사람의 버전으로 갈 수도 있다.
문서는 대부분의 데이터베이스에 딱 맞지 않기 때문에, 콘텐츠 관리 시스템(CMS)는 예측한 항목을 서로 이어주는 방향으로 발전했다. 간단한 것은 text blob 형식에 메타 데이터를 더하는 식이지만, 더 복잡한 것은 다른 자료와, 워크플로우, 문서들간의 관계와 더 많은 것들이 있다. 그리고 세세한 단계가 인상깊을 수 있지만, 속박도 될 수 있다. 한번 컴퓨터가 뭔가에 의존하게 되면, 그 예측한 항목들을 바꾸기는 힘들다.
좋든 싫든, Git은 CMS에 비해 훨씬 덜 의존적이다. 내장된 형식이 없다. 권한 구조도 훨씬 덜 복잡하다. 조직구조에 딱 맞춘 제어구조를 필요로 한다면 상당히 힘들겠지만, 엄청나게 자유로울 수 있다.
웹 코드 관리
HTML과 CSS는 Git이 성장해 온 코드는 아닐 것이이지만, 관련된 코드 집합들에 잘 들어맞는다. 심지어 "보통" 웹 사이트는 더욱더 애플리케이션이나 그 비슷한 것에 가까워지고 있다.
보통 내가 일해왔던 사이트들은 사이트의 구조를 제공하는 코드와 그 내부를 채우는 콘텐츠가 분리되어 있었다. 구조는 파일의 집합이다. HTML, CSS, PHP나 Rails 애플리케이션이건 간에. 콘텐츠는 그 이외의 곳에 있다. 보통은 데이터베이스일 것이다. Git은 구조화된 파일에 아주 적합하다. 하지만 사람들은 이것을 데이터베이스는 버전 관리에 적합하지 않다는 말로 확신하는 경향이 있다.
Schmitt가 지목한 대다수의 디자이너들이 자기들이 관리하는 콘텐츠 중에 코드 같은 느낌이 드는 것과 거기 관련된 자료들을 관리하는 데 Git과 GitHub를 사용하게 될 것이라 생각한다. 납득할 만한 시작점이다.
흐릿한 코드/콘텐츠 경계
XML을 오래 써 와서 그런지, 코드와 콘텐츠가 비슷해 보이는 파일에 같이 있는게 전혀 이상해 보이지 않았다. 관계형 데이터베이스를 몇 년 썼는데, 기쁘게도 거기서 벗어나 문서 기반 유스케이스로 돌아오게 되었다. 내 블로그는 실제로 단순히 연결된 메타데이터를 가진 문서 집합이다. 내 책은 각 조각이 어떻게 연결되어 있는지에 대한 좀 더 많은 메타데이터를 가진 챕터의 모음이다.
Git으로 더 깊게 통합될 수 있을까? 가능하다. 모든 콘텐츠를 GitHub으로 올리고, Git의 견고한 정보공유 기반 소셜 도구의 장점을 취할 수 있을까?
그렇다.
GitHub는 자체적으로 Jekyll을 제공하는데, 스태틱 파일에서 블로그를 만들 수 있는 도구다. 물론, GitHub 페이지를 이용해서 GitHub내부에 사이트를 만들 수 도 있다. 이건 막 탐사를 시작한 열린 문이다.
내가 일하는 O"Reilly는 출판의 기본 작업에 Git을 사용한다. 여기서 몇 가지 결과를 볼 수 있고, 기술을 이용하여 만들어지는 더 많은 책들이 있다. 각 저자가 서로의 챕터에 관여하는 공동 저작물을 관리하고, 저자들은 어떻게 합칠지 걱정할 필요없이 자료를 여기저기 컴퓨터에 보관할 수 있다.
아직 초기단계인 것은 맞다. 쓰고 있던 CMS나 데이터베이스를 버릴 시기가 왔다고는 생각하지 않는다. 원하면 그래도 되지만. 하지만 지금은, 프로그래머건, 디자이너건, 콘텐츠 생산자건 관리자건, 이 모든 일을 다 하는 사람이건간에, 어떻게 정보를 저장하기를 원하는지 스스로에게 묻기에 적합한 때다. Git 방식은 리눅스 커널 해커가 아니더라도 당신에게 적합할 것이다.
저자 : Simon St. Laurent
역자 : 조석규
원문 : Restructuring the Web with Git
웹 디자이너? Git? Github? 프로그래머용이 아닌가? Christopher Schmitt는 Artifact 컨퍼런스에서 얼마나 많은 동료 디자이너들이 Github를 쓰고 있고, 그걸로 뭘 더 할 수 있는지 발표했다. Github(그리고 아래의 Git 도구들)은 모든 종류의 사람들이 함께 일하는 방식을 바꿨다.
Git으로 공유하기
Git은 리눅스가 그랬던 것처럼 Linus Torvalds가 컴퓨터 세상에 공헌한 가장 중요한 일이라고 생각해왔다. 많은 사람들이 그저 소스 코드를 관리하는 도구라고 생각할 것이지만, Git은 분산된 환경의 프로젝트, 특히 텍스트를 사용하는 것들을 관리하는데 극단적으로 다른 (내 생각엔 훨씬 더 나은) 많은 것들을 할 수가 있다.
Git은 사람이 만들어낸 느슨하게 구조화된 문서들을 다루는 불편한 문제와 씨름한다. 텍스트 파일은 믿을 수 없을 정도로 유연해서, 아무거나 쓴 메모부터 형식이 꽉 짜여진 코드까지 모든 것을 저장할 수 있다. 텍스트 파일은 놀랍게도 읽고, 검색하고, 상대적으로 처리하기 편한 만큼, 양이 많아졌을 때, 엉망진창이 되는 경향이 있다.
[명령줄과 Git에 대한 Schmitt의 발표에 기반한 그림]
버전 관리 도구는 이런 문제를 누가 어떤 파일에 뭘 했는지 추적해서 정리해준다. 구형 버전 관리 도구는 체크인, 체크아웃이라는 개념으로 접근했다. 파일에 접근할 수 있는 사람을 제한하는 것으로 문제가 생기는 것을 방지한 것이다. 시간이 지나자, 그것은 필요없는 구속이고, diff를 이용하여 뭐가 실제로 바뀌었는지 보는 것이 더 명확하다는 것이 밝혀졌다.
Git은 이 논리를 더 발전시켜서, 중앙집중화되지 않은 구조를 만들어 사람들이 네트워크로 연결되지 않아도 사용할 수 있게 했다. 처음엔, 몇몇 하드코어 프로그래머들이 쓰는 복잡한 시스템(리눅스 커널이나 그 전용 드라이버 같은 거)에서나 필요할 것 같았다. Schmitt는 git 브랜치를 강조했다. 여전히 마스터, 배포 브랜치가 있지만, 그걸 배포할 필요는 없다. 자유롭게 브랜치를 만들고, 받아오고, 머지와 풀 요청을 통해 다른 사람들과 소통할 수 있다.
하지만, 하지만… 충돌이 난다! 충돌은 프로그래머가 처리하는 거 아닌가? 아니다. 그 파일에서 충돌이 나는 변경점이 뭔지 잘 알고 있는 사람이 처리하면 된다. 그게 코드라면, 프로그래머가 필요하다. HTML이나 CSS라면 대신에 웹 개발자가 필요할 것이고, 책에 들어갈 내용이라면, 저자나 편집자가 필요할 것이다.
데이터베이스는 어디에 있지? CMS는 또 어디에?
Git은 자체적인 데이터 구조로 돌아가는데, 데이터베이스나 XML과 전혀 비슷하지도 않다. Git은 사용자가 그 구조를 이해할 것이라 예상하지 않는다. 대신 그 안에 들어가는 것은 사용자가 알고 있는 구조로 되어있고, 사용자가 그 안에 들어가는 것들을 체크할 것이라 생각한다 Git은 누가, 뭘, 언제 바꿨는지 추적할 것이다.
대부분 데이터베이스와 다르게, 이미 있는 정보를 갱실할 때 있던 것이 지워지지 않는다. Git은 변경점을 추적한다. 돌아가기를 원치 않을 수도 있고, 돌아갈 필요가 있을수 도 있고, 돌아갈 수 있다. 심지어 다른 사람의 버전으로 갈 수도 있다.
문서는 대부분의 데이터베이스에 딱 맞지 않기 때문에, 콘텐츠 관리 시스템(CMS)는 예측한 항목을 서로 이어주는 방향으로 발전했다. 간단한 것은 text blob 형식에 메타 데이터를 더하는 식이지만, 더 복잡한 것은 다른 자료와, 워크플로우, 문서들간의 관계와 더 많은 것들이 있다. 그리고 세세한 단계가 인상깊을 수 있지만, 속박도 될 수 있다. 한번 컴퓨터가 뭔가에 의존하게 되면, 그 예측한 항목들을 바꾸기는 힘들다.
좋든 싫든, Git은 CMS에 비해 훨씬 덜 의존적이다. 내장된 형식이 없다. 권한 구조도 훨씬 덜 복잡하다. 조직구조에 딱 맞춘 제어구조를 필요로 한다면 상당히 힘들겠지만, 엄청나게 자유로울 수 있다.
웹 코드 관리
HTML과 CSS는 Git이 성장해 온 코드는 아닐 것이이지만, 관련된 코드 집합들에 잘 들어맞는다. 심지어 "보통" 웹 사이트는 더욱더 애플리케이션이나 그 비슷한 것에 가까워지고 있다.
보통 내가 일해왔던 사이트들은 사이트의 구조를 제공하는 코드와 그 내부를 채우는 콘텐츠가 분리되어 있었다. 구조는 파일의 집합이다. HTML, CSS, PHP나 Rails 애플리케이션이건 간에. 콘텐츠는 그 이외의 곳에 있다. 보통은 데이터베이스일 것이다. Git은 구조화된 파일에 아주 적합하다. 하지만 사람들은 이것을 데이터베이스는 버전 관리에 적합하지 않다는 말로 확신하는 경향이 있다.
Schmitt가 지목한 대다수의 디자이너들이 자기들이 관리하는 콘텐츠 중에 코드 같은 느낌이 드는 것과 거기 관련된 자료들을 관리하는 데 Git과 GitHub를 사용하게 될 것이라 생각한다. 납득할 만한 시작점이다.
흐릿한 코드/콘텐츠 경계
XML을 오래 써 와서 그런지, 코드와 콘텐츠가 비슷해 보이는 파일에 같이 있는게 전혀 이상해 보이지 않았다. 관계형 데이터베이스를 몇 년 썼는데, 기쁘게도 거기서 벗어나 문서 기반 유스케이스로 돌아오게 되었다. 내 블로그는 실제로 단순히 연결된 메타데이터를 가진 문서 집합이다. 내 책은 각 조각이 어떻게 연결되어 있는지에 대한 좀 더 많은 메타데이터를 가진 챕터의 모음이다.
Git으로 더 깊게 통합될 수 있을까? 가능하다. 모든 콘텐츠를 GitHub으로 올리고, Git의 견고한 정보공유 기반 소셜 도구의 장점을 취할 수 있을까?
그렇다.
GitHub는 자체적으로 Jekyll을 제공하는데, 스태틱 파일에서 블로그를 만들 수 있는 도구다. 물론, GitHub 페이지를 이용해서 GitHub내부에 사이트를 만들 수 도 있다. 이건 막 탐사를 시작한 열린 문이다.
내가 일하는 O"Reilly는 출판의 기본 작업에 Git을 사용한다. 여기서 몇 가지 결과를 볼 수 있고, 기술을 이용하여 만들어지는 더 많은 책들이 있다. 각 저자가 서로의 챕터에 관여하는 공동 저작물을 관리하고, 저자들은 어떻게 합칠지 걱정할 필요없이 자료를 여기저기 컴퓨터에 보관할 수 있다.
아직 초기단계인 것은 맞다. 쓰고 있던 CMS나 데이터베이스를 버릴 시기가 왔다고는 생각하지 않는다. 원하면 그래도 되지만. 하지만 지금은, 프로그래머건, 디자이너건, 콘텐츠 생산자건 관리자건, 이 모든 일을 다 하는 사람이건간에, 어떻게 정보를 저장하기를 원하는지 스스로에게 묻기에 적합한 때다. Git 방식은 리눅스 커널 해커가 아니더라도 당신에게 적합할 것이다.
TAG :
최신 콘텐츠