소프트웨어 공학의 사실과 오해 Facts and Fallacies of Software Engineering

우리가 미처 알지 못한 소프트웨어 공학의 사실과 오해우리가 미처 알지 못한 소프트웨어 공학의 사실과 오해, by Robert L. Glass

Robert Glass의 이 책은 내가 읽은 소프트웨어 엔지니어링에 관한 문헌들에서 자주 인용되기에 꼭 한번 읽어봐야지 하고 생각하고 있던 책이다.

제목 그대로 이 책은 소프트웨어 엔지니어링에 관한 사실들과 오해들을 열거하고, 각각에 관한 논쟁과 저자의 의견들을 정리해놓은 책이다. 각각의 항목들은 다른 유명한 저작들에서 언급된 내용이 많아서 ‘집대성’의 느낌이 든다. 이 책의 가장 큰 목적은 저자가 서론에 언급한대로 ‘기본적이면서도 중요’한 사실들인데도 ‘자주 잊혀지’는 사실들을 사람들이 ‘반복해서 배우게’하는 것일 것이다. 한편으로는 사실들의 원저작에 해당하는 개개의 저작들을 읽을 때와는 다르게, 여러 사실들과 논쟁을 한곳에 정리해놓음으로써, 소프트웨어 엔지니어링에 대한 생각을 정리하고 관점을 만들어낼 수 있도록 도와준다.

대부분의 사실들은 말그대로 ‘사실’로 통용되는 것들이지만, 몇몇은 아직 논쟁거리인 경우도 있고, 개인적으로 동의하고 싶지 않거나 또는 그동안 믿지 않았던 것들도 있었다. 사실 이러한 점들을 읽는 도중에 메모를 해서 정리했어야 하는데, 그러지 못한 것이 후회된다. 하지만, 이 책은 한번 더 읽어볼 기회가 있을 듯하고, 그 때는 반드시 그에 관한 글을 따로 써야겠다.

저자가 채택한 사실에서 몇가지 경향을 찾아본다면, 다음과 같다.

  • 사람이 중요하고 도구와 기술은 그보다 중요하지 않다.
  • 어떤 문제에서든 은탄환은 없다.
  • 소프트웨어 개발 프로세스의 초기 단계들(요구사항, 설계)은 중요하다.
  • 소프트웨어 개발 프로세스의 몇몇 단계들은(테스팅, 검토, 유지보수)은 대단히 중요하지만 과소평가되고 있다.
  • 대규모 또는 범용적인 재사용은 어렵다.

저자는 소프트웨어 엔지니어링 학계에서 널리 받아들여지고 있는 사실들은 단정적으로 받아들이고 있으며, 소프트웨어 엔지니어링에 있어서의 최근의 변화에 대해서는 어느 정도 긍정적인 점들은 인정하기는 하나 약간 망설이는 느낌이 든다. 한마디로 말해 보수적이다. 어떻게 보면, 학계가 바라보는 현재의 소프트웨어 엔지니어링에 대한 시점이 이 책에 그대로 반영되어있다는 느낌이 든다. (이를테면, 학계에서도 인정이 되고 있는 패턴에 대해서는 항목을 하나 할애해서 재사용에 대한 해법 중 하나로 인정하고 있다. 반면 오픈소스나 XP에 대해서는 약간 방어적이다.)

하지만, 그러한 태도가 이 책의 단점이라기보다는 장점이라고 생각한다. 소프트웨어 엔지니어로서 우리는 새로운 기술, 도구, 프랙티스가 우월하므로 도입해야만 한다는 강박관념에 항상 시달려왔다.  우린 오히려 좀 더 신중해야할 필요가 있다.

이 책을 읽으면서 자꾸만 내가 겪었던 현실들이 떠오르면서 나 또는 다른 사람들이 기본적이면서도 중요한 사실들을 얼마나 자주 잊고 있는가를 되돌아보게 되었다. 저자에게 동의하지 않을 수 없는 것은 이러한 사실들은 정말로 반복해서 배우는 수밖에 없을 것이라는 점이다.

소프트웨어 공학의 사실과 오해 Facts and Fallacies of Software Engineering 더 읽기"

Monopoly and Innovation

플랫폼이든 데이터든 독점하는 것은 사회적으로 바람직하지 못하다는 생각을 가지고 있고 많은 사람들도 그렇게 (또는 그들은 악하다고) 생각하고 있지만, 현실적으로, 플랫폼 또는 데이터의 독점이 창출하는 수익을 포기하고 불확실한 수익에 리스크를 걸 정도로 멍청하거나 용감한 경영진은, 그리고 그것을 용납할만한 주주들은 드물 것이다. 그리고, 그것이 바로 혁신은 다른 곳에서 이루어지는 (Innovation Happens Elsewhere) 이유일 것이다.

Monopoly and Innovation 더 읽기"

JRuby 1.0 assumes Ruby string to be UTF-8

Charles Nutter가 Paving the Road to JRuby 1.0: Unicode 글에서 JRuby 1.0에서는 Java와 Ruby 사이에 문자열이 전달될 때는 Ruby 문자열이 UTF-8로 인코딩되어있다고 가정하는 정책으로 가겠다는 의지를 밝혔습니다. Charles Nutter가 설명하는대로, Java 문자열과 Ruby 문자열의 고유한 방식을 보존하는 한, 이러한 방식이 거의 유일한 방식이 아닌가 합니다.

  • Ruby strings are byte[] and conform to Ruby string semantics
  • Java strings passing into Ruby code will be encoded as UTF-8, with the implication that you should expect to be working with UTF-8 byte[] in the receiving code
  • Ruby strings passing out of Ruby into Java libraries will be assumed to be UTF-8, and the resulting string on the Java side of the call will reflect that assumption.

JRuby 0.9.x의 Non-Ascii 문자열 처리 방식에 실망하고, 당분간 아예 Unicode 지원에 대한 의지가 전혀 없는 줄 알았는데, 그나마 다행입니다. JRuby에서의 Ruby 2.x 문자열 구현을 시작한다는데, Ruby 2.x 문자열의 Unicode 지원은 어떻게 될 지 궁금하군요.

JRuby 1.0 assumes Ruby string to be UTF-8 더 읽기"

스프링노트: 첫 인상

Wiki는 널리 사용되는 웹 애플리케이션 형태 중 하나다. 내가 Wiki를 사용하는 용도를 적어보면 참으로 다양하다는 것을 알 수 있다.

  • 메모: 단순한 형태의 정보를 저장.
  • 수정하기 쉬운 목록: 할 일, 살 물건들의 목록.
  • 리서치: 특정 주제에 대한 정보를 (지속적으로) 수집, 정리.
  • 소프트웨어 프로젝트 문서화: 설계 및 구현 문서, 토론의 기록, 기술적인 사실의 기록, 사용자 매뉴얼, 프로젝트에 관련된 리소스로의 접근.

이 글에서 Wiki의 특성에 유래하는 편리함들을 새삼스레 다룰 필요는 없을 것 같다.

스프링노트를 처음 본 사람들은 누구나 Wiki를 떠올릴 것이다. 당연하게도 Wiki의 특성들을 공유하고 있기 때문이다. 스프링노트는 애초에 Wiki를 목표로 만들어 졌으리라고 생각한다.

Wiki나 스프링노트 모두 정보의 생산 도구에 해당한다. 이러한 도구들의 혁신은 반 정도는 "얼마나 쉽게"라는 구호에 달려있다고 본다. 전통적인 Wiki의 formatting 문법은 직관적이지 않는데다가 Wiki 구현에 따라 서로 다른 문법을 사용하는 바람에 보통 사람들은 물론 Wiki를 자주 쓰는 사람들조차도 사용하기 쉽지 않았던 것이 사실이다. 이러한 점에서 BackPack, Writely 또는 Google Docs가 스프링노트를 언급할 때 빠질 수 없을 듯 하다.

스프링노트가 오픈된 지 어느 정도 지난 시점에서 기능적인 면들을 세세하게 짚고 넘어갈 필요는 없을 듯하다. (이를 위해서는 JayZ님의 개인 위키 서비스의 등장이란 글을 참고.)

스프링노트는 기능적인 면에서는 너무 마음에 들어서 내가 사용하는 Wiki를 버리고 스프링노트로 옮겨갈지도 모르겠다는 생각이 든다. 그럼에도 불구하고 스프링노트는 아직 부족한 점들이 많다. 베타 테스트 당시에는, 정말 멋지긴 하지만, 사용 가능한가 하는 의문이 들 정도였다. 스프링노트 개발자들의 노고를 어느 정도는 들어서 알고 있기 때문에, 이러한 지적을 하는 것은 대단히 꺼려지는 일이지만, 이러한 지적을 통해 좀 더 나은 모습의 스프링노트 더 나아가서는 후속작들을 기대해본다.

  1. 페이지 로딩이나 단축키 반응 등이 느리다. 베타 테스트 당시에는 서비스가 굉장이 느렸는데, 지금은 많이 나아진 것 같다.
  2. WYSWYG 에디터의 버그가 많다. 잘 동작하지 않는 경우도 있고, 브라우저에 따라 다르게 동작하는 경우도 있다.
  3. WYSWYG 에디터의 사용자 인터페이스 (버튼, 단축키)가 충분히 편리하지 않다. 버그에 해당할 지도 모르겠지만, Bold나 Italic과 같은 텍스트 속성을 토글할 수 없다든가, Undo에 해당하는 Ctrl-Z를 두번 눌러야 하는 경우가 많다는 것들은 자잘하지만 상당히 불편함을 야기한다.
  4. 사용자 인터페이스가 충분히 편리하지 않다. 예를 들면, 상대적으로 자주 사용될 것이라 생각되는데도 불구하고 공개되어있지 않은 페이지를 공개하기 위해서는 세번이나 클릭해야한다.

추가할만한 기능이라면 다음을 들고 싶다.

  • 맞춤법 검사: 불행하게도 아직 국내 웹 서비스 중에서 맞춤법 검사를 해주는 곳이 없다.
  • 외부 블로그 포스팅: 이미지 업로드 등이 걸리긴 하겠지만, 맞춤법 검사가 된다면 아마 텍스트 지향 사용자들은?
  • CSS 테마: 모양새 까지는 아니더라도 색상이나 폰트를 변경할 수 있었으면 좋겠다. 개인적인 취향이지만, XHTML 포맷에서도 굴림 폰트로 고정해놓아서 마음에 안든다. (나는 브라우저 기본 설정을 사용할 수 있도록 하는 것을 선호한다.)
  • 공개된 페이지의 URL에 페이지 제목을 사용하기: 한글 URL에 관한 복잡한 이슈 때문에 스프링노트와 같은 서비스에서 한글을 URL에 사용하는 것은 아직은 힘들 것 같다.
  • 함께 위키 만들기: 혼자서 쓰는 위키라는 느낌이 강하다. 다른 사람들의 공개된 페이지에 좀 더 쉽게 접근할 수 있도록 하고 링크하기도 쉽게 만들었으면 좋겠다.

스프링노트: 첫 인상 더 읽기"

Demonstration

Episode 1.

2005년 회사에서 일하다가 학생의 신분으로 돌아간 나는 예전에 내가 학생으로서 권리를 주장하던 것들을 학교로 떠나 다른 위치에 있을 때는 완전히 까맣게 잊었다는 사실을 깨달았다. 물론 회사에서는 노동자로서의 권리에만 관심이 있고 그것을 찾는데에만 급급하기 때문이었다.

그러던 중 2005년 초여름에 고등학생들이 교육 문제에 관한 몇번의 시위를 한 적이 있다. 당시에 듣던 역사 강의의 교수님은, 학생은 공부를 해야하지 시위를 해서는 안된다라는 요지의 말씀을 하셨다. 몇가지 부연 설명 (학생이 공부를 할 수 있게 해주는 환경도 중요하다는 식의 얘기)도 하신 것 같지만, 기본적으로 학생 시위 자체에 대해서는 바람직하게 여기지는 않으시는 것 같았다. 아무개가 그런 소리를 했다면 그냥 넘어갔겠지만, 역사 교수님께서 그런 얘기를 하신 것은 어쩐지 실망스러웠다.

궁극적으로는 자기 자신 외에는 아무도 자신의 권리를 대변해줄 수는 없다. 학생이 공부를 하는 것은 물론 사회적으로나 개인적으로나 바람직한 일인 것은 당연하나, 바로 학생만이 학생을 대표하고 학생의 권리를 주장할 수 있다. (물론 조력자들이 있을 수 있다. 하지만, 조력자들의 주장은 수많은 주장들 중의 하나일 뿐이다.)

학생은 공부를 해야한다고? 한 사람 한 사람의 목소리를 모아서 자신들의 목소리를 오롯히 낼 수 있다는 것을 경험하는 것은 영어 단어 몇개 수학 공식 몇개보다 훨씬 삶에 도움이 될 것이다.

특히나 사회적 약자 중 하나인 학생들의 목소리는 그들은 자신의 권리에 대해 판단할 수 있는 능력이 없다는 이유로 그동안 무시되어온 것이 사실이다. 내게는 학생들의 시위가 그들의 정당한 권리이면서도 그들의 처절한 현실로 비춰진다.

Episode 2.

2006년 늦가을 한창 FTA 반대 농민 시위의 분위기가 격렬해가던 때, 방화 사건이 일어난 적이 있다. 당연히 언론 기사들은 과격 시위를 비판하는 논조 일색이었고 짜증내하는 시민들의 의견을 곁들였다. 점심 식사 시간에 사람들과 그러한 소식에 대해 얘기를 나누던 중, 동료 한명이 한 말은 내 심장을 얼어붙게 만들었다.

“저 정도면 발포해야하는 거 아냐?”

대한민국의 근대사를 아는 사람이라면, 하다 못해 영화 Bloody Sunday (2002)를 본 사람이라면 절대 그런 말을 입에 담을 수 없을 것이다.

일단은 폭력을 써서 문제를 해결하려는 생각이, 또는 폭력에는 무조건 폭력으로 대응해야한다는 생각이 우리 모두를 전범으로 만드는 것이다.

Demonstration 더 읽기"

황색 저널리즘이 만연한 신문 사이트들 Yellow Journalism Widespread in the Korean Newspaper Sites

황색 저널리즘(Yellow Journalism)이라는 잘 알려진 개념이 있다. 황색 저널리즘이 생산하는 선정적인 기사들은 사람들의 주목(attention)을 불필요하게 점유함으로써 좀 더 생산적인 언론의 기능들 예를 들면, 의제 설정 기능(agenda-setting function)과 같은 기능을 방해할 수 있다. 황색 저널리즘 자체가 가질 수 있는 장점들이 있을 수 있겠지만, 그러한 장점은 선정성을 통한 이익 추구에 의해서 가려지게 마련이다. (이 글에서 선정적인 기사란 무엇인가 또는 선정적인 기사가 가지는 가치 등에 관해서 논하지는 않겠다. 우리는 우리에게 좀 더 이득이 되는 기사를 접할 수 있는 기회를 박탈하는 선정적인 기사에 대한 어느 정도의 공감대를 가지고 있다고 가정한다.)

인터넷 매체가 주요한 매체가 되기전부터 황색 저널리즘의 경계는 언론사, 매체, 기사들 사이에 뚜렷한 경계가 있었다. 주요 신문들의 헤드라인과 소위 ‘스포츠 신문’들의 헤드라인은 누가봐도 구분할 수 있다. 인터넷 매체가 점점 발전하면서 최근 1-2년 사이에 소위 ‘주류’ 신문이라고 부를 수 있는 신문사의 사이트- 인터넷 신문들이 변화하고 있다. 사이트의 첫 화면에 내거는 기사들의 반 정도는 선정적인 기사들에 속한다. 물론 종이 신문에서는 아직도 전통적인 의미의 헤드라인을 고수하고 있고, 웹 사이트에서도 그 기사들을 헤드라인이라는 분류를 통해서 접근할 수 있다. (수년간 조선일보의 첫 페이지를 현재의 것과 비교해보라.)

아마 이러한 변화의 경향은 주요한 포털 사이트의 뉴스 서비스와의 경쟁에서 비롯되었으리라고 생각한다. 뉴스 서비스의 소비가 인터넷으로 옮겨가기 시작하면서 전통적인 신문사들은 포털 사이트와의 경쟁에서 압박을 느끼기 시작했을테고, 결국은 이들을 베끼는 전략을 사용하기 시작한 것으로 보인다. 오히려 현재는 포털 사이트의 뉴스 서비스의 첫 페이지보다 주요 신문사의 인터넷 뉴스 서비스에서 선정적인 기사를 찾아보기 쉽다.

종이 신문이 인터넷 신문을 대체할 것인가 하는 문제는 또다른 흥미로운 문제지만, 그 문제를 논외로 하고서라도, 인터넷 신문이 우리 생활에 막강한 영향을 미치고 있다는 것은 사실이다. 언론을 접하는 대중들의 태도는 대체로 수동적인 것이 현실이기 때문에, 대중들이 ‘무엇을 선택하느냐’ 이전에, ‘무엇이 주어지는가’하는 문제는 중요한 문제라고 생각한다.

이런 문제는 법이나 규제로 해결되지는 않는다. 언론사들의 책임 의식과 지식인과 시민 단체들의 언론사들에 대한 감시와 비판을 통해서 해결할 수 있을 것이다. 물론 대중들의 교육은 언제나 빼놓을 수 없는 해결방법이다.

무엇보다도 인터넷 매체를 기반으로 하는 언론들은 – 주요 포털 사이트들을 포함한 인터넷 뉴스 서비스들은, 설령 기사의 생산을 담당하지 않는다고 하더라도, 이미 기사의 선별 과정을 통해 언론의 기능을 수행하고 있는 만큼 언론으로서의 책임 의식을 자각할 필요가 있다.

한편, 포털 사이트의 뉴스 서비스들이 수익을 창출하기 위해서 어느 정도 선정성을 활용할 수 밖에 없다고 한다면, 그것을 원하지 않는 사람들을 위한 다른 성격의 서비스의 가능성은 없는가 하는 의문이 든다.

황색 저널리즘이 만연한 신문 사이트들 Yellow Journalism Widespread in the Korean Newspaper Sites 더 읽기"

Tool for Writing a Blog Post

MovableType에 내장된 에디터는 WordPress 처럼 WYSWYG 에디터가 아닙니다. WordPress 에디터를 싫어하는 사람도 있지만, MT 사용자의 입장에서 WP의 에디터는 부러운 점입니다. 특별한 markup을 사용하는 formatter도 사용해보고, mshtml을 사용한 툴, Google DocsWindows Live Writer, Performancing도 사용해보았지만, 모두 마음에 들지 않는군요.

마음에 안 드는 점들을 들자면 다음과 같습니다.

  • 사용자 인터페이스
  • 문서의 구조화
  • XHTML 표준과의 호환
  • 맞춤법 검사

사용자 인터페이스

일단 WYSWYG이 아니면 모두 탈락. 물론, 직접 HTML 코드를 수정할 수 있어야하는데, WYSWYG과 제대로 연동이 되지 않는 경우가 많습니다. 자주 사용하는 에디팅 기능들이 없거나 불편하게 되어있는 경우도 많습니다.

문서의 구조화

그나마 최근에 나온 툴들은 HTML 문서 내에 presentation 정보를 넣지 않는 경향이 강합니다. mshtml의 경우에는 최악이었죠. presentation이 빠졌다고 해도, 문서 내용을 구조화하는 것은 여전히 불편합니다. Microsoft Word 인터페이스처럼 현재 커서 위치의 ‘문단 스타일’을 설정하는 방식으로는 부족합니다.

XHTML 표준과의 호환

소위 제 블로그는 XHTML 표준 호환을 표방하고 있는데, 최근에 Windows Live Writer를 사용하면서 호환되지 않게 되었습니다. HTML을 생산하는 에디터들이 호환성 있는 HTML을 생산하지 않으면 표준 호환성으로의 길은 요원할 것입니다.

맞춤법 검사

사소한 맞춤법이 잘못 되어서 글을 다시 수정해야하는 경우가 자주 일어납니다. 영문 맞춤법 검사는 찾아볼 수가 있긴 하지만, 한글 맞춤법 검사는 웹상의 에디터에서는 거의 전무합니다.

앞으로의 대책

제가 만들어서 쓰고 있던 MovableTypeWriter를 다시 사용하면서 좀 더 개선해 볼 계획입니다.. 기본적으로 위의 문제점들을 해결하고, 다른 툴들의 장점들도 도입해볼 생각입니다.

Tool for Writing a Blog Post 더 읽기"

Problems of Political Philosophy, Chapter 1, Section 1

제게는 이상한 습관이 한가지 있습니다. Computer Science나 Programming에 관련된 책을 읽으면 거의 빠지지 않고 서평을 쓰지만, 문학이나 인문-사회-자연과학 도서들을 읽고나서는 글을 쓰지 않는 것이 그것입니다. 하지만, 쓰지 않으면 아무리 세심하게 책을 읽고, 그 책을 읽을 당시에는 이해했다고 하더라도, 그 책이 가지고 있는 가치를 잊어버리게 마련입니다. 그래서, 앞으로는 모든 책에 대해서 서평 또는 요약에 가까운 정리를 해 볼 생각입니다.

일단 그 첫번째로 D. D. Raphael의 Problems of Political Philosophy를 번역한 ‘정치 철학의 문제들’을 읽으면서 장절 단위로 정리해볼 생각입니다. 한국어로 된 좋은 정치 철학 입문서는 거의 없는 듯 합니다. 번역된 정치 철학 입문서라고 해야 2-3권에 불과하구요. 이 책을 추천한 분이 계셔서 일단은 일독하면서 정리해볼 생각입니다. 잘못된 것이 있으면 얼마든지 지적해주세요.

다음은 제1장 ‘정치철학이란 무엇인가?’의 제1절 ‘과학적 이론과 철학적 이론’의 요약입니다. 너무 짧아서 맛보기에 불과하군요. 일단 1장은 오늘 안으로 모두 올리도록 하죠.

정치학-사회학과 정치철학-사회철학의 차이

정치학-사회학의 이론은 하나의 과학적 이론이며, 개별적인 사실을 기록하고 설명하며, 일반적인 설명의 법칙을 제공하려고 시도한다. 그러한 법칙들은 실례를 통해 증명되거나 반증될 수 있다. 반면, 정치철학-사회철학의 이론은 ‘그 경우는 어떻게 되어야 하는가’ 또는 ‘우리가 무엇을 해야하는가’를 말해주는 교설, 이데올로기, 규범 또는 이상적인 표준이다.

이러한 의미에서 정치학-사회학은 실증적(positive)이고, 정치철학-사회철학은 규범적(normative)라고 얘기할 수 있다.

정치철학의 정의

한편, 정치철학은 국가(the state)에 대한 관념에 철학적 사유를 적용하는 철학의 한 분야라고 정의할 수 있다. 그렇다면 철학이란 무엇인가?

철학의 목적

철학의 목적은, 특히 전통적인 철학의 목적은 다음의 두가지로 요약될 수 있다.

  • 신념에 대한 비판적 평가(critical evaluation of belief)
  • 개념의 명료화(clarification of concept)

Problems of Political Philosophy, Chapter 1, Section 1 더 읽기"

My Career Experiences and Goals

Career Experiences

  • High-Performance Asynchronous Network Client-Server (Jaguar 2000 in Aratech)
  • Distributed Component Framework (NCM in Neowiz)
  • Portable System Facade Library (NCL in Neowiz)
  • Multithreaded/Asynchronous Network Server Framework (Spring/Summer in Neowiz)
  • Web Crawler (Super100 in NHN)

Career Goals

  • High-level Software Architecture Design
  • Quality System Software Construction
  • Distinguished Domain Knowledge in Search Engine

My Career Experiences and Goals 더 읽기"

dp.SyntaxHighlighter

블로깅 하다보면, 코드를 적어야 하는 경우가 자주 발생하고, 하이라이팅을 하기 위한 편리한 방법이 필요합니다.

하이라이팅을 위해 HTML로 변환하는 툴이야 많지만, 중요한 requirement들은 다음과 같습니다.

  1. Presentation의 분리: 코드 텍스트를 (가능한 한) 원래의 형태로 저장할 것.
  2. XHTML 표준의 사용:  예를 들어, <font /> element 보다는 <span /> element, class attribute, CSS를 활용할 것.

Presentation 분리는 대체로 Textile과 같은 formatter를 따로 사용해서 얻을 수 있는데, 블로깅 툴들이 기본적으로 제공하는 경우는 없고, 글 전체에 특정 format을 사용해야하기 때문에 맘에 안듭니다. 조그만 악을 해치우기 위해 더 큰 악을 불러들여오는 꼴이랄까요. 그리고 아쉽게도 기존의 툴들은 대부분 <font /> element를 사용하는 경우가 많습니다.

겐도사마를 통해 알게 된 dp.SyntaxHighlighter를 사용해보았습니다. dp.SyntaxHighlighter의 장점은 코드 텍스트를 그대로 유지하면서, javascript와 CSS를 통해 하이라이팅을 하기 때문에 위의 requirement들을 모두 만족한다고 볼 수 있습니다.

dp.SyntaxHighlighter 더 읽기"