날짜 : 2008. 7. 17 늦은 8시 ~ 10시 / 뒷풀이(10시 ~ )
장소 : TOZ 신촌 본점
좌장 : 신현석
부좌장 : deute
참석 : 부엉, celina, 서정민, 진달래, 루미렌트, headvoy, kjy2143, hwzzang, nothinking, soul.

부엉, celina

전에 근무하던 회사에서 웹표준을 하긴 했는데 다른 파트의 분들은 전혀 모르고 듣긴하는데 관심이 없다. 퍼블리셔만 한다고 해서 되는게 아닌데.기존의 회사는 시스템에 내가 맞춰야 했다. 그래서 계획을 하고 있는건 실무자들을 대상으로 프로젝트가 진행되기전에 교육을 하려고하는 데 다른 회사의 분들은 어찌 하시는지 다른 직군의 사람들과 커뮤니케이션을 어찌 진행 하는지 알고 싶다.
현재 실무자들 대상으로 하고있다. 웹 표준,웹 접근성이 뭔지 아느냐. 물어보면 대답 못한다. 개발의 경우 업무 공통화팀이 있어서 교육도 있고 그런데 이부분은 그런것이 없다. 교육의 경우 실무자들은 좋아하나 사장님들은 좋아하지 않는다.
업계에 아직 인식이 부족하다 우리가 무슨일을 하고있는지 알고 얘기할 수 있어야 하는데 그런것을 교육을 통해서 알려주고 싶다. 교육을 부탁받은적이 있는데 해본적도 없고 어찌해야 할지도 몰라서 인터뷰 형식으로 진행을 했다. 대부분의 사람이 HTML은 알고있으나 웹표준은 들어본적 있고 특징도 대충들었는데 듣기많이 들었는데 감이 잘안오고 어찌 실마리를 풀어야할지 모르겠다 라길래 인터뷰 하길 잘했다. 교육을 하게 되면서 커리큘럼을 짜려고 하고 있는데 다른사람의 얘기를 듣고 싶다.

현재 프로젝트의 개요에 대해 사전 리뷰를 한다. 개발쪽이나 기획쪽은 사전 교육을 하는걸로 아는데 디자인이나 퍼블리싱은 그런적이 없다. 교육의 대상은 실무자만 생각 했었는데 사람들에게 얘기를 들어보니 클라이언트를 교육 시켜야 한다고 들었다. 클라이언트가 모르는건 클라이언트만 탓할수는없고 현재의 웹퍼블리셔들의 문제도 크다고 생각한다… 웹표준 왜 해야하냐고 물으면 좋으니까 코드가 줄고 뭐 이런 얘기들을 하는데 클라이언트는 그런것에 신경쓰지 않는다.

• 돈이 이런게 관련되어 있지 않으면 클라이언트들은 아예 신경을 쓰지 않는다. 그래서 나는 실무에 관련된, 기간에 관련된 줄이는 얘기를 한다. 그리고 table 보다 cSS방식이 소스의 재활용이 용이하다. 그렇게 지금 진행중이다.
• 소스의 재활용이 필요한 경우가 별로 없다. 대부분의 리뉴얼시에 기능이 많이 바뀌고 컨텐츠도 새로 구성한다.
• 은행권의 경우 기능과 컨텐츠모두를 재활용 하는 경우가 분명히 있다. 하지만 한국의 대부분의 회사 소개 사이트의 경우 1년에 두번 정도 리뉴얼을 진행하고 컨텐츠마저 매번 바뀌고있다. 오랫동안 한사이트를 오랫동안 작업하는 경우가 아니라면 소스의 재활용은 힘들것이다. 또한 태그의 순서나 용도가 일치하는지 확인하는 수고를 가지기 때문에 더욱 힘들어질수있다.
• 클라이언트를 설득하기 위해 제일 좋은 방법은 비용과 관련된 얘기를 소스의 절감 으로인한 트래픽 축소, 서버 비용의 절감등의 얘기로 설득할수 있을것같다. 또한 장차법관련 된얘기도 있을 수 있고 , 멀티 디바이스들을 이용해 잠재된 고객을 유치하는게 더 좋다.

그럼 모든 내용의 제안서에 웹 표준의 장점을 항상 같은걸 적을수 밖에 없다. 사이트의 성격에 다라서 제안하는 방식이 다른데 항상 같은 얘기를 하는건 좋은 방법은 아니라고 본다.

• 실제로 성격에 상관없이 틀린 장점이 아니라면 항상 같은걸 적어줘도 무리가 없지않은가?

문제는 없지만 뭔가 새로운 정보가 필요하고 케이스가 많았으면 좋겠다.

• 명확히 예를들어 최적화에 촛점을맞춰야하는경우라면 웹 표준은 그것에 대한 제일 확실한 제안 점이 될 수 있지 않은가.
• 클라이언트 웹표준에 대한 인식이 어느정도 있어서 웹 표준을 하면 뭐가 좋냐고 물어보는경우가 많은데 이에 대해 웹 퍼블리셔가 준비를 해야 할 것 같다.
• 웹표준을 설득하는것이 상당히 힘들다라는 얘기가 나오는게 표준을 적용을 해야 한다라고 시작을 하기 때문에 그게 힘든건다 표준은 그냥 따로 있는거고 표준을 통해서 뭔가를 하는건데, 그 뭔가가 경우마다 다른건데 대부분의 작업자들은 웹 표준자체에 목표를 가지고 있는경우가 많다.. 웹 표준을 지켜서 접근성을 향상시키겠다. 웹 표준을 지켜서 소스의 절감을 가져오겠다 등의 목표를 성취하기 위해 웹 표준이 수단으로 정하는 것 좋다.

표준은 웹에 대한 근간이다.

서정민

CSS3 연말에 다 적용된다고 하는데 이것을 어디까지 지원을 해야 하는것 일까?

• CSS3는 Recommendation이 되지도 않은 부분이 대부분이다. 표준이 아니다.. Recommendation이 안되면 언제 바뀔지 모른다.
• 좋은걸 계속 쓰면 표준이 된다. innerHTML이 좋은예가 되는게 아닐까?
• 구현되지 않은 표준은 표준이 아니다.
• innerHTML의 경우와 CSS3의 경우는 많은 차이가 있다. innerHTML의 경우 상당히 오래전부터 대부분의 브라우저에서 사용을 하고있다. 그러나 CSS3의 경우는 이제 막 사용을 시작하게 되었을뿐이다. 한10년후에 CSS3가 표준이 되지 않았는데 사람들이 모두 사용하고 있다 그러면 같은 성격의 문제가 될지는 모르겠지만. 그리고 앞으로 나올 ie8의 점유율이 기존의 IE6,7 을 다 흡수 할수 있으면 모르겠지만 하위호환성을 생각해야 한다. 아직 IE6를 제일많이 사용하고있다.
• 제일 적합한예가 first-child다 너무 좋은기능이고 최신 브라우저에서 모두 지원하고있지만 사용할 수 없다. ie6 에서 지원하지 않기 때문이다.'

Progressive Enhancement의 입장에서 동일한 사용자 접근을 지원하면 되기 때문에 CSS3를 지원해도 컨텐츠에 영향은 없으므로 동일한 사용자 접근을 유도 할수 있다.

• 그렇다고 해서 동일한 화면을 보여줄 수 있는데 그 노력을 하지 않으면 안된다. 클라이언트쪽 개발을 하는 사람이라면 100%는 아니더라도 적어도 99,98%의 동일한 사용자 경험을 지원해야 하는게 상식인데 CSS3를 사용하겠다는것은 그 %를 절반도 안되게 낮추겠다는것이다. 표준보다는 사용자를 생각해야 한다.

진달래

CSS파일을 어떻게 최적화 할수있느냐? 올바르게 정의하는 방법에 대해 고민해 보고 싶다. 현재 내가 두개의 사이트를 통합하고 있는데 CSS파일이 50개 정도 된다. 그걸 어떻게 정리해야 될지 모르겠다. 또한 html4.0,이랑 XHTML1.0 을 통합할때 어떤것이 효율적인지…

• 메뉴가 18~20개 공통 파일, 이메일 등등으로 정의되어있다.
• CSS 파일하나가 4096줄을 넘어갈경우 IE에서 4096줄을 넘어가는 경우 작동하지 않는다.
• 포털들이 메인에 그냥 internal 방식으로 style을 넣는 이유는 external을 사용하는경우 몇천번에 한번씩 CSS파일을 읽지못하는경우가 있따. 하지만 캐시를 사용할수없기 때문에 적절한 판단을 필요로 한다.
• 포털의 메인 같은 업데이트 빈도가 잦고 트래픽이 꽤 많은 페이지의 경우 internal 을 많이 사용한다. external은 캐시를 저장 해두기 때문에 오히려 위험할수있다.
• CSS파일에 대한 Guideline이 원래는 있어야 한다. WSG 분석을 할필요가 있어 보이는데 여러개의 CSS파일을 합치는것은 대단히 어렵고 위험할수가 있다. 셀렉터가 중복되어 충돌이 날 경우가 있을수도 있고, 효율성마저 떨어진다. 새로이 구조를 다시 만들고 그것에 합치는것이 낫다…
• 합치는것보다 페이지 별로 CSS파일을 따로 불러주는 작업이 오히려 나을수도 있다.

루미렌트

업무효율을 높이는 방법에 대해서 제일 민감한 부분이 일정을 효율적으로 짜는 방법에 대해서 얘기해 보고 싶은데 페이지당 시간 이나 각 모듈별로 일정을 짜는걸 생각해 본적이 있는데 어지 생각하느냐.

• 모 업체에서는 실제로 메인 탑 네비 등등으로 일정을 책정해서 업무 일정을 부여하는걸로 알고있다. 관리 입장에서 더욱 피곤할것 같으나 업무의 입장에서는 좋은방법 일것 같다. 자기만의 룰을 가지고 표준 작업 시간을 책정해서 가지는것이 좋다.
• 공장같다. 자기관리하는데는 좋겠지만 .퀄리티 측정을 시간으로 해서는 안된다.
• PSD가 나오기전에 미리 작업할수있는건 한다.
• WSG 가이드가 나오면 작업 효율을 높일 수 있다. 페이지를 먼저 디자이너가 치는것보다 WSG를 만들고 작업을 진행하는게, 더욱 효율적인 프로세스가 될수있다. 지금은 작업의 낭비가 심하다.
• WSG자체도 기획서와 같이 작업해야한다.
• 디자인과 마크업을 동시에 진행할 수 있는 프로세스를 구성해보는것도 좋은 방법이 될 수 있다.
• 선 마크업 후 디자인의 경우 방법 수정 사항이 너무 많아서 힘들 수 있다. 개발자들이 머라한다.
• 기본적으로 업무효율을 높이는 제일 좋은 방법은 좋은 사람이다.
• 수정하는 기간도 정해놓고 해야한다. 수시로 버그를 수정하는것이 아니라 일정 기간 일정을 확보하고 버그 수정 기간을 잡는것이 좋다.
• 퍼블리셔들 일정이나 사전회의 빠지지 마라 가서 자신의 목소리를 키우는것도 중요하다. WSG만들어달라고 졸라라~
• 개발 프로세스를 약간 익히는것도 중요하다. 약간의 제어문이라도 알아야 논리적이고 구조적인 페이지가 나온다.
• 위지윅 에디터를 쓰는것도 업무효율을 높이는데 도움이 된다. 드림위버 같은경우 생각보다 강력한 기능들을 지원하고 있다.
  

속도를 높이는걸 고려해 보고자 한다면 위지윅이나 태그 자동 완성이 되는 툴을 써보는것이 큰 도움이 될수있다.

headvoy

위젯에 대해서 얘기해 보고싶다. 현재 위젯을 만드는 직업을 가지고 있다. 브라우저 개발사에서 퍼블리셔가 할수있는 일들이 무엇일까 고민해 보고싶다.

• 오페라에서 위젯 서비스를 하고 있는데 많은 수요창출이 기대된다. 물론 모바일쪽에서도 많은 수요가 생기고 있다. 위젯은 HTML JS CSS로 구성되어 있다.
• html 한페이지에서 모든 동작을 해야하기때문에 javascript 작업이 많이 필요하게 된다. 모바일쪽에서도 서서히 풀 브라우징도 지원하고 있으니 자바 스크립트를 많이 공부 하는 준비를 하는것이 좋지 않을까 생각해본다.
• 자바스크립트를 하는것도 좋지만 프로토타입같은 자바스크립트 프레임워크를 사용할 줄 알아도 될것 같다.

위젯이 업체에서 말하듯 그렇게 가능성이 보이는 분야인가?

• 에이전시의 고객 같은 경우에 매리트가 있다 CDK의 RSS를 받을수도 있고 영어학원의 오늘의 영어 한마디 같은 이런걸 만들 수 있다. 강력하면서 간단한 기능 같은거를 만들수있는데 풀브라우징이 지원된다하더라도 모바일쪽에서는 간단한인터페이스가 지원되는 위젯쪽이 좀더 가능성이 있어 보인다.
• 간단한 어플리케이션의 발전방향에 대해서는 아직 예상이 되지않는다. 웹 클립같은 페이지에서 동작하는경우도 있는데 보기에 상당히 막강한 기능을 사용할 수있다고 생각된다. 오페라 위젯 같은 경우 오페라에 종속적 이다 라고 알고 있다. 동작 플랫폼을 통합할 필요가 있어 보인다.
• 여러종류의 모바일 브라우저가 많이 나오고 있는데 브라우저 엔진에 종속적인 위젯보다는 독립적으로 돌아갈 수 있게끔 발전 방향으로 가져 가는것이 더 좋다고 생각이 든다.
• W3C 위젯 표준이 만들어지고 통합이 된다면 그 문제는 해결되지 않을까 생각이 든다.

soul

CSS를 작성하는 효율적인 방법에 대해 얘기하고 싶다.

• 가독성을 높이기 위해 탭으로 구분을 하거나 속성별로 줄을 나눈다거나 하는 방법을 해달라고 하는 개발자가 있어서 논쟁이 일었는데. 어느것이 더 좋은 방법인지 궁금하다.
• 사용하는 사람의 자유이다. 최적화를 위해 고민해볼수는있다. 개발버전과 배포버전을 사용할수도 있다.

디자인된 셀렉트박스 어찌하는가?

• 무시한다는 의견 대부분;
• 스크립트나 htc 등 여러가지 작업을 해서 셀렉트박스를 사용하는건 보안적으로 나쁜 이유도 있고 키보드 접근 등등 여러가지 위험한 요소가 문제될 수 있다.
• 디자인적으로 조금 좋아 질수 있으나 접근성, 사용성, 사용자 경험, 상호 운용성 모두 떨어진다.