-. 대상 : 전체검색(/bbs/search.php)
-. 특징 : 웬만한 내용은 다 찾아낸다.
(예) 현재 관련 스킨에서 지원하는 기능은 제목, 내용, 글쓴이 등 국한적인 기능만 명시되어 있으나,
사용자에게 직접 보여지는 부분 외 해당 소스파일은 아이피, 작성일시 등을 기본으로 갖고 있습니다.

-. 보드 프로그램을 선호하는 이유가 과연 무엇일까요?

오랜기간동안 비슷한 유형의 처리방식이 눈에 인식된 부분도 있겠으나,
근본적으로는 Database툴과 함께 자료의 효율적인 관리라 볼 수 있겠습니다.
보드 프로그램의 효율적인 기능에 대해 그 경중을 일일이 따지기는 그렇지만,
자료를 찾을 수 있는 검색관련 부분은 그중에서도 더더욱 빛을 발하는 기능이라 하겠습니다.

그런데 현재의 추세는 구체적인 형태의 파일 자료가 많이 다루어지고,
사용자의 욕구 또한 실질적으로 가시화 될 수 있는 자료를 찾아볼 수 있기를 기대합니다만,
현재까지의 자료 검색방식은 텍스트 형태의 자료를 위주로 많이 다루어져 있어서,
사용자의 욕구에는 미치지 못하고 있는 것이 현실입니다.

-. 형태가 구체화 된, 즉 파일 자료 또한 검색할 수 있는 기능이 도입되어야 한다고 봅니다.

기술적으로는 가능하다구요?
단, 시설이나 장비, 실질적인 운용경비 측면의 문제가 크게 발생하기 때문에?!
...

그것이 검색기능의 구조 자체에 수정을 가하는 방향이든지,
아니면 특정한 스킨이나 여분필드 등을 활용하는 것과 같은,
마치 확장된 형태로 제공이 될 것인지에 대한 방향성은,
먼저 실행된 후 결정해야 할 사항이라고 봅니다.

사용자의 욕구를 파악하고 구체적으로 실현시키는 것에 있어서는,
개발자 자체가 모든 것을 짊어지고 갈 필요는 없다고 봅니다.
개발자의 몫은 구조와 효과성을 기반으로 적절한 산물을 만들어 내고,
운용 측면의 적절한 검토 및 사용자와의 원활한 연계를 통해,
그 산물의 효율성과 효과성을 검토해야 할 것은 아닌가 생각됩니다.

물론 사용자 입장 또한 '최종 사용자(end-user)'라는 주장만을 내세운다면,
운용 측면과의 적절한 연계는 기대할 수 없겠지요.
연계를 원천적으로 막아두고 '혜택을 누리기만 하겠다'는 것은,
마땅히 사용자라고 얘기할 수는 없겠지요.
그것은 엄연히 말 뜻 그대로 '수혜자'일 뿐이니까요.

혹시라도 아무런 의미도 없는 반응을 보이던,
즉, 사용자가 아니라 수혜자는 아니었는지 돌아보게 되어,
지금부터라도 일방적인 수혜자가 아니라,
잘 사용하고자 하는 '사용자'가 되고자 합니다.