오랬동안 여러가지 이유로 쓰지 못했던 생각을 적어본다.

웹표준, 웹접근성을 어떻게 효과적으로 안착시킬지에 대한 얘기는 항상 큰 이슈이다. 특히나 요즘같이 웹접근성이 크게 부각되고 있는 시점에서는 더욱 현실적으로 부딪치는 문제이다. "사장이 의지를 가지고 있어야 한다.", "기획자가 바뀌어야 한다.", "전문 부서가 있어야 한다." 등 조직적인 부분이나 외부에서 해결점을 찾으려 하는 생각이 많다. 정말로 외부의 변화가 선결해야 하는 과제일까. 또한 외부가 바뀌면 이 문제가 영속적으로 해결될 수 있을까.

상위 조직이나 전담부서가 있어서 품질 관리를 지속적으로 수행한다면 효과가 있을 것이다. 실제로 이렇게 접근해서 성과를 내고 있는 회사도 있다. 하지만 상당수의 회사는 가시적인 이득이 도출되지 않는 한 이렇게 접근하기가 힘들다. 뜻있는 일부 사람에 의해서 도입되었다가 구심점이 없어지면 사그러지게 될 가능성이 높다. 내부적으로 이러한 조직을 꾸려왔던 큰 회사에서도 조직이 분리되는 모습을 보면서 그 구심점을 유지하고 이득을 도출하는 일이 쉽지 않음을 느꼈다.

그 원인이 뭐였을까를 고심하다가 눈에 들어온 것이 아웃소싱 형태의 업무 프로세스였다. 유독 이쪽 업무는 아르바이트도 많고 아웃소싱도 많다. 작년 웹표준의 날에 김현진님이 이에 대한 설문조사를 한 적이 있는데 절반정도는 버전 관리 시스템을 사용하고 나머지는 이메일이나 FTP를 이용한다는 결과를 본적이 있다. 버전 관리 시스템을 사용하더라도 단일화된 코드베이스를 사용하지 않고 HTML/CSS 파일을 관리하는 용도로만 운영을 하고 막상 파일 전달은 수동으로 하는 경우도 있었다.

수정 작업이 있을 때마다 변경된 내역을 따로 정리해서 이메일이나 메신저로 주거니 받거니하는 과정은 상당한 자원을 소모하는 비효율적인 업무 방식이다. 특히나 코드 변경내역이 웹접근성이나 호환성 향상 작업같이 잘 모르는 분야라면 이를 손으로 머지하는 사람 입장에서는 굉장히 비싸고 불필요한 작업이라고 느낄 수 밖에 없다. 반면에 프로세스 안에 들어가 있다면 이슈를 등록하고 수정하고 커밋하면 모든 과정이 끝난다. 다른 자원을 추가적으로 소비해야할 필요도 없다. 단지 웹표준이나 웹접근성을 잘 아는 전문가만 있으면 된다.

실제 업무 프로세스 안에 들어가 있지 않고 외부 인력같이 코드를 같이 섞지 않는 상황에서는 아무리 웹표준과 웹접근성이 좋아도 부차적인 일로 여겨질 수 밖에 없다. 결국에는 품질 향상으로 연결되지 않고 기업이윤 논리에 밀려나게 된다. 물론 로컬 환경을 설정하고 버전 관리 시스템을 사용하는 일이 쉽지는 않다. 서버 개발자의 지원도 많아야 한다. 하지만 이를 풀어내지 못하면 코드 품질은 영원히 잡을 수 없다. 내 코드를 내가 직접 수정하지 못하는데 누가 대신 그 일을 해줄까. 회사 차원에서도 이런 분절된 환경을 최대한 통합하고 같이 협업할 수 있게 지원하는 것이 결국 제품의 품질 향상과 발전된 개발 문화 형성에 도움을 줄 것이라고 생각한다.

더이상 중간자, 주변인으로 남지말고 개발 프로세스 안으로 들어가자.