웹 에이전시에서 웹 표준하기

며칠 전 현실과 이상이라는 글을 보니 공감가는 부분도 많고 이런 저런 생각이 많이 들어 결국 포스트를 쓰기 시작했지만… 지금 나는 아마도 타칭 웹 퍼블리셔라는 직업을 가진 사람이 된 것 같다. 최근에 나가고 있는 강의에서 참 많은 분들을 만나고, 커뮤니티에서 읽는 글을 보면서 여러 가지 생각을 하게되는 요즘인 것 같다. 블로깅을 하면서 웹 표준이나 웹 접근성에 대해 주로 다루고 있지만 내가 이런 것들에 대해 알게 돼서 직접 코드를 작성하고 써본건 아직 4년이 채 안된다. 내 경우를 돌아보니 그 시작은 2005년 5월 쯤이었던 것 같다.

사전 경고: 혹시라도 어떤 방법론을 기대하고 오셨던거라면 그냥 돌아가시는 편이 좋을 듯

그 분의 이름이나 얼굴은 기억나지 않지만

한번은 나와 같이 일할 사람을 뽑기 위해서 면접을 봤었는데 오신 분이 div를 이용한 코딩을 알고 있냐고 물어보셨다. 당연히 나는 모르고 있었고, 그 점에 대해서 그 분은 실망을 하셨던 것 같다. 면접이 끝난 후에 그 분이 거론했던 사이트를 좀 찾아보게 되었고, 참 재밌는 방식의 코딩이라고 생각했다. 해서 이런 저런 단어로 검색하고 찾아보고 해도 당시에는 관련 서적이나, 잘 정리되어있는 사이트가 국내에서 찾아보기 어려운게 실정이었다.

국내 최초의 웹 표준 세미나

그렇게 한달 좀 더 지났을까, CSS를 이용한 웹 사이트 디자인 전략 세미나라는게 열린다는 소식을 접했고, 회사에 졸라서 개발자 한명과 같이 갔던게 내가 웹 표준에 관한 제대로된 정보를 처음 접한 때라 할 수 있다. 꽤 규모 있는 강당을 가득 메운 사람들(여성 비율이 압도적이었던 것으로 봐서 대부분 디자이너들이라고 추측했었다)과 함께 들었던 당시의 세미나에서는 웹 표준의 효용에 관한 이야기를 중심으로, 어떤 어떤 개념이다라는 내용이 주를 이루었다.

세미나를 가기 전에는 내가 수집한 자료를 A4지 몇장에 정리해서 소속(당시에 나는 디자인팀이었다) 팀장님께 제출하고 내가 그 세미나에 가야할 이유를 설명해야 했고, 다녀온 후에는 배워온 방법들을 업무에 적용하기 위해 고민해야 했다. 물론, 세미나에 다녀와서는 사내에 그 내용을 전파하기 위해 직접 사내에 배포할 자료를 준비해서 지속적으로 알리는 과정도 필요했다.

웹 퍼블리셔라고 불리기까지

2005년

당시 그 세미나에 같이 갔던 동갑내기 개발자도 나름 고민이 많은 친구였고 이런 저런 이야기를 하면서 조금씩 조금씩 우리가 만들던 웹 사이트에 적용해보기 시작했다. 내가 웹 표준에 맞는 코드를 작성하기까지 알게 모르게 내 실험의 대상이 되었던 페이지가 많다. 몇 페이지로만 작성되는 프로모션 페이지라던지, 콘텐츠가 얼마 안되는 작은 사이트들까지 꽤 많은 사이트들이 내 실험의 대상이었고, 그런 사이트가 실험 대상이 되어도 괜찮았던 건 최종 결과물의 모양새만 멀쩡하다면 문제가 제기될 이유도, 제기할 사람도 없었기 때문이다.

내게는 새로운 방식이 너무도 재미있었고 놀라운 일의 연속이었던 것 같다. 그렇게 연습해서 어느 정도 감을 잡았다고 생각했던 시점에 제대로 된 적용을 해볼 기회가 생겼다. 대형 사이트 프로젝트가 두 개 정도 들어왔고, 하나는 내가 직접, 다른 쪽은 경력이 충만한 계약직을 뽑아서 진행하게 되었다. 두 사이트 모두 웹 표준을 지켜서 만드는 것이 제안서 상의 요건이었고 각각 3~5개월간 프로젝트를 진행하면서 복잡한 구조의 페이지를 제대로 구성하기 위해 많은 시도와 고민을 해야했었다.

한가지 여담이라면, 내가 직접 담당하지 않았던 쪽은 진행 초반에 웹 표준에 맞는 마크업이 되질 않아서 당시까지 진행됐던 수백페이지를 내 말 한마디에 다 버려야하는 상황이 벌어졌었다. 그리고 작업자를 옆에 앉혀두고 표준 코드로 레이아웃팅하는 방법부터 보여주면서 어떤 방식으로 작업이 진행되어야 하는지 이야기했었는데, 전문 코더로 경력을 쌓아오신 - 태그와 CSS에 대한 기본적인 이해가 있는 - 분들이라 쉽게 받아들이실 수 있었던 듯 하다. 거의 한달 이상 작업한 결과물을 헌신짝처럼 버리게 했던 점은 좀 미안하지만, 그렇게 강행하지 않았다면 그 사이트나 그 작업자분들이 변화하기 어려웠을거라 생각한다.

2006년

업무를 진행하는 동안 겪었던 수많은 충돌. 지금도 많은 사람들이 하소연 하고 있는 ‘우리 회사는 웹 표준에 대한 인식이 부족해서…‘라는 과정을 나 역시 충분히 겪었다.

큰 프로젝트를 진행한 후라 나름의 자신감이 좀 붙었달까. 스스로 더욱 전문화되기 위한 노력이 필요했는데 나 혼자서는 어떻게 해도 힘들었다. 프로젝트에 투입되는 많은 사람들을 불러서 웹 표준이나 웹 접근성에 대한 세미나를 진행한 것만 수차례¹, 그 과정에 나와 함께 그룹지어지던 코더들에 대한 마크업 교육. 결국 실력있는 몇 사람도 함께 하게 되고 코더 스스로가 만드는 결과물의 품질은 괜찮다고 말할만한 수준에 올랐지만, 구조적으로 문제가 있는 기획, 디자인. 잘 만들어진 페이지를 파괴하는 개발자. 대리라는 직급으로 전 부서의 업무 프로세스를 변화시키는 일은 끝끝내 성공할 수 없었다.

개인적으로는 하반기부터 블로그를 쓰기 시작했고고, 여러 오프모임에도 다니기 시작했다. 웹 표준이라는 걸 알고, 사용해 볼 때마다 더 많은 것에 관심이 가고 알고 싶었기 때문이다. 특히 워프모임 날 현석님, 대석님, 훈님, 쿠키님을 만나게 된 것도 그렇지만, 보잘 것 없는 발표자료를 들고 찾았던 BarCampSeoul에서 알게된 웹은 내가 아는 것보다 훨씬 넓은 곳이었다. 행사 시즌이었는지 첫번째 웹 표준의 날 행사도 같은 달에 있었고 그 시기에 정말 많은 사람들과 넓은 세상에 대해 배울 수 있었던 것 같다.

2007년

회사에 팀이라는 형태를 처음 만들었던 해이기도 하다. 디자인실 소속이었기 때문에 진행하기 힘들었던 부분들이 너무 많았고 하는 일의 성격 자체 또한 디자인 보다는 개발에 어울린다고 생각해서, 개발실로 소속을 옮겼다.² 하지만, 업무를 진행하는 과정 자체가 달라지는 것이 아니었기 때문에 전문 퍼블리셔들의 목소리를 내기 위한 장치가 필요했고, 결국 사내 조직 개편을 기회로 퍼블리시팀의 방을 하나 배정받을 수 있었다.

하지만 그렇게 만들어가기까지, 또 그렇게 팀을 만들고 난 후에도 프로젝트에 투입된 팀원들이나 문서 작업이나 가이드라인 작성 쪽에 힘을 쏟았던 나는 숱한 야근과 철야, 휴일 반납으로 인한 피로에 시달릴 수밖에 없었다. 문제는 조직 구조에 있었던 것이 아니라 업무에 대한 이해와 그 진행 방식에 있었던 것이다.³ 기업은 이윤을 추구하고, 다른 기업과 경쟁하며 적은 투자를 통해 더 많은 이익을 창출하려고 한다. 아무리 생각해봐도 프로젝트를 진행하는 구성원이 넉넉했던 적은 없는 것 같다. 동시 진행되는 프로젝트의 수가 적었던 적은 있어도 진행을 여유롭게 했던 일은 생각나지 않는다.

개인적으로는 현석님, 훈님의 추천으로 2006년 후반부터 웹 표준에 관한 크고 작은 강의를 맡게되었고, 웹 접근성 평가 작업이라던지 회사 밖의 일을 시작하면서 웹 표준을 하는 분들과의 교류도 잦아졌고 회사의 이해를 구해 외부 활동을 좀 더 왕성하게 할 수 있었던 시기였기도 하다. 회사와 약간의 관련이 있는 월간 w.e.b.이라는 잡지에 웹 표준에 관한 기고를 하기도 했는데, 기술자가 글을 쓰는게 결코 쉽지만은 않더라.

2008년

2007년 하반기에 진행되었던 대형 프로젝트가 연초까지 진행되었다. 끊임없이 발생하는 크고 작은 사고들. 팀장이라는 직책을 맡고서 ‘관리’라는 일이 정말 어렵다는걸 절실히 느끼게된 것 같다. 내 체질엔 맞는 일이 아니라는 것도 말이다. 내가 다른 사람들 이상으로 나를 혹사했다고 생각하지는 않는다. 하지만 나는 그렇게 건강한 편은 아니었나보다. 나 홀로 시작한 일이 하나의 팀을 구성할 때까지 약 3년이 걸렸고, 그 기간동안 소진된 체력과 건강을 회복하기 위해서 회사를 그만두고 현재는 잘 쉬면서 이런 저런 생각을 정리하고 있다.

지금 나는

웹 퍼블리셔도 팀장도 아니다. 회사를 그만두고 나선 몇달간 미친듯이 쉬었고, 주머니가 궁한 관계로 지금은 소소한 몇가지 일로 입에 풀칠을 하고 있다. 그러니 지금은 백수란 단어(프리랜서⁴는 싫어서)가 더 어울리는 사람이다.

나중에 우스개처럼 한 이야기지만 나에겐 ‘서비스를 직접 운영하는 작은 회사’가 어울릴지도 모르겠다. 만들 수 있는 것을 만들고, 보다 많은 가능성을 고민하고, 적절한 협의와 협업을 통해서 추구하는 바를 구현할 수 있는 그런 회사 말이다. 내가 원하는 회사가 너무 거창한건가? 굳이 작은 회사를 말하는 이유는, 전에 소속된 회사가 입사 당시와 퇴사 때의 규모가 확연히 달라졌기 때문이다. 문서 업무라는 것이 무조건 효율적이거나 비효율적이라는 건 아니지만, 회사의 규모가 커질 수록 늘어나는 것 중의 하나는 실제 업무와 관계가 있는 듯 없는 듯한 문서 작업이다. 특히 나중엔 실무팀을 담당했던 내 입장에선 그런 관리 업무가 가장 힘들기도 했고 말이다.

그래서 결론은

없다… 라고 하면 허무하실까? 후후

한 회사를 다니면서 몇 년간 겪었던 일을 간단히나마 글로 쭉 정리하고 나니, 내가 참 많이 부족했구나 하는 생각이 든다. 요즘들어 강의도 가끔 나가고 하면 지난 이야기를 웃으며 하지만, 단지 지난 이야기이기 때문에 웃을 뿐인거다. 내 입으로 꺼내기엔 민망한 이야기지만 당시엔 너무 힘이 들어 서럽게 울었던 적도 몇 번 있었다. 하지만, 돌이켜보니 좀 더 나은 방법이 있어서 보다 나은 결과를 만들 수 있었을 것도 같다는 생각도 든다. 결과적으론 내가 여러 가지 착오를 해왔기 때문에 그렇게 생각하는 거겠지만.

퍼블리셔와 HTML코더를 차별하는 풍토, 실력과는 상관없이 웹 표준이 대세일 때 고액의 프리랜서가 되고 싶은 사람들, 울며 겨자먹기로 그런 사람들을 써야하는 회사들, 해야된다고 하니까 덤비고 있는데 뭘해야하는지 몰라서 헤메는 사람들. 이런 건 언제나 있었던 문제고 당분간은 계속될 일이라고 생각한다.⁵

개인적인 이야기를 늘어놓다가 싸잡아 욕하는 게 썩 좋은 모양새는 아니라 쿡쿡 찔러대는 일은 그만하련다. 내가 굳이 내 경험담을 늘어놓은 이유라면 밥숟갈에 밥, 반찬 다 올려서 떠먹여주는 걸 원하는 사람이 너무 많아 보이기 때문이다. 받아먹는 그 한 술 밥에 배부를까. 결국 배가 고프니 다른 숟가락을 또 찾는다. 마크업을 밥 짓는 법이라고 치면, CSS는 반찬 만드는 법 쯤으로 치자. 스크립트로 국끓이는 법까지 배워두면 배고플 땐 언제든지 밥 해먹을 수 있다. 처음엔 간도 좀 안맞고 하겠지. 자꾸 하다보면 맛도 좋아지고 깔끔한 밥상이 되는거다.

웹 표준이라는 걸 새로 시작하는 사람들은 여전히 많고, 그 사람들이 뭐부터 해야하는 지 모르는 건 당연하다. 그리고 보다 자세한 자료를 얻길 원하는 심정도 잘 이해한다. 하지만 이런 점도 있다. 나와 비슷한 시기나 그 보다 먼저 웹 표준을 공부한 사람들은 서적과 자료에 목말라 있었는데 지금은 조금만 둘러봐도 관련 서적이나 자료가 널렸다. 20년 전에는 어땠는데 지금은 세상 좋아졌다라는 투의 말을 하고 싶은게 아니다. 앞선 사람들이 뒤에 올 사람들을 위해서 꼭 뭔가를 준비거나 가르쳐줘야한다는 법 조항이라도 있는가.⁶ 다른 사람에게 투정할 것이 아니라 스스로 공부하고 노력하는 것이 가장 확실하고 빠른 길이라는 이야기를 하고 싶은 것이다.

모르겠다

3~4년 사이 나를 따라다니게 된 호칭이 많다. ‘웹 퍼블리셔’, ‘과장’, ‘팀장’, ‘강사’, 무슨 ‘위원’, ‘웹 접근성 전문가’ 등등. 예전엔 나도 스스로를 웹 퍼블리셔라 부르기에 주저하지 않았는데, 지금은 웹 페이지를 다루는 개발자 정도로 해두고 싶다. 그게 정말 내가 할 수 있는, 하고 있는, 하는 일이니까.

글을 쓰다보면 주절주절하다가 이상하게 마무리 되는 건 여전하다. 불친절해보여도 그러려니 하시길.