오픈소스 소프트웨어 코드읽기

우리는 일반적으로 코드쓰기에 익숙합니다. 학교에서든 학원에서든 코드를 쓰는법에 대해서는 가르치지만 그 어디에서도 코드를 읽는 방법에 대해서는 가르치지 않습니다. 그래서 오늘은 코드읽기에 대해서 알아보겠습니다. 그중에 특히 오픈소스 소프트웨어 코드읽기에 관하여 알아보겠습니다.

 

일반적으로 우리는 기존 코드를 수정하거나, 검토하거나, 개선해야 한느 경우라면 선택의 여지없이 코드를 읽어야 합니다. 또는 무언가의 작동 방식을 배우기 위해서 코드를 읽어야 할 수도 있습니다. 뚜껑을 열 수만 있다면 어떤 것이든 그 내부를 들여다보고 싶어하는 엔지니어들처럼, 소프트웨어 엔지니어들 역시 코드를 들여다보고 뭔가를 배우고 싶어합니다. 또한 재사용할 수 있는 뭔가를 찾아보려는 심산으로 코드를 읽을 수도 있습니다. 그리고 상대적으로 드문 일이긴 하지만, 그냥 즐거움을 위해서 마치 문학 작품을 읽듯이 코드를 읽는 경우도 있습니다. 어쨋든 코드를 읽는 이유는 다양하며, 그런 다양한 이유에 따라 코드 읽기의 기법이나 강조점도 달라지기 마련입니다.

 

첫번째로 문학으로서의 코드읽기입니다. Dick Gabriel은 창조적인 직업들 중 저자가 다른 이들의 작품을 읽는 것이 허용되지 않는 몇 안 되는 직업이 바로 프로그래밍이라고 지적한 바 있습니다.

 

소유권 규범의 효과는 문학으로서의 어떠한 소프트웨어도 존재하지 않게 만들었습니다. 이는 마치 모든 작가들이 자신의 개인 회사를 가지고 있으며, 멜빌 사의 사람들만 "백경"을 읽을 수 있고 헤밍웨이 사의 사람들만 "태양은 다시 떠오른다"를 읽을 수 있는 것과 같습니다. 그런 상황에서 문학이 풍부하게 발전할 수 있을까요? 그런 조건 하에서는 문학의 교과 과정 같은 것이 생겨날 수 없으며, 글쓰기를 가르칠 방법도 없습니다. 그런데 우리는 바로 그런 조건 하에서 사람들이 프로그래밍을 배울 수 있을 거라고 기대하고 있습니다.

 

이런 상황을 바꾼 것이 오픈소스 소프트웨어입니다. 오픈소스 소프트웨어 덕분에 이제는 읽고, 검토하고, 개선하고, 우리가 뭔가 배울 수 있는 수백만 줄의 코드가 존재합니다. 사실 과학적인 의사소통 수단으로서의 수학 정리들의 성공에 기여한 사회적인 절차들 중 많은 것들이 오픈소스 소프트웨어에도 적용됩니다. 대부분의 오픈소스 소프트웨어 프로그램들은 소스 코들의 형태로 문서화되고, 발행되고 검토되었으며 논의되고, 내부화되고, 일반화되고, 쉽게 바꿔 쓰였으며 실제의 문제를 해결하는 데 사용되었습니다.

 

다른 사람들이 작성한 고품질의 코드를 읽는 데 시간을 투자하는 것을 습관화해야 합니다. 고품격의 산문을 읽는 것이 어휘를 풍부하게 만들고, 상상력을 촉발시키고, 의식을 확장시키듯이, 잘 설계된 오픈소스 소프트웨어 시스템의 내부를 속속들이 조사함으로써 우리는 새로운 구조적 패턴과 자료구조, 코딩 방법, 알고리즘, 스타일과 문서화 관례, 응용 프로그래밍 인터페이스(API)를 배울 수 있으며, 심지어는 새로운 컴퓨터 언어도 배울 수 있습니다. 고품질 코드를 읽는 것은 또한 자신이 생산하는 코드에 대한 스스로의 기준을 높이기도 합니다.

 

코드 읽기의 모험 속에서 우리는 반드시 피해야 할 반례로 받아들이는 게 최선인 코드도 만나게 됩니다. 좋은 코드와 나쁜 코드를 빠르게 구분하는 능력은 매우 가치 있는 것입니다. 그리고 그런 능력을 키우는 데에는 건전한 코딩 반례들을 살펴보는 것이 도움이 됩니다. 코드에 다음과 같은 징후들이 나타난다면 저품질의 코드일 가능성이 높습니다. 코딩 스타일이 일관되지 못하거나 구조가 불필요하게 복잡하거나 읽기 힘들고 명백한 논리적 오류나 누락된 부분이 존재하고 이식성이 없는 구문들을 남용하고 유지보수가 부족한 경우가 저품질의 코드의 징후들입니다.

 

그러나 서투르게 쓰인 코드로부터 건전한 프로그래밍을 배울 수는 없는 노릇입니다. 코드를 문학으로서 읽는다면, 그런 코드를 읽는 것은 시간 낭비입니다. 특히 고품질의 코드를 얼마든지 구할 수 있는 지금으로서는 더욱 그렇습니다.

 

스스로에게 이런 질문을 던져 봅시다. 지금 내가 읽고 있는 코드가 해당 분야에서 최상급에 속할만한 것인가? 오픈소스 운동의 한 가지 이점은, 성공적인 소프트웨어 프로젝트들과 아이디어들이 경쟁을 불러일으키며, 그런 경쟁은 오픈소스 소프트웨어들의 구조와 기능의 향상으로 이어진다는 점입니다. 우리는 종종 두 번째 혹은 세 번째로 완전히 개정된 오픈소스 소프트웨어 설계들을 보는 호사를 누리곤 하는데, 그런 오픈소스 소프트웨어에서는 대부분 이후 설계가 이전 버전들보다 훨씬 더 나은 향상을 보입니다. 원하는 기능을 검색어로 사용해서 웹을 검색해보면 서로 경쟁 관계인 구현들을 쉽게 찾을 수 있을 것입니다.

 

코드를 읽을 때에는 대상을 잘 골라야 하며, 또한 목표를 염두에 두고 읽어야 합니다. 새로운 패턴이나 코딩 스타일, 또는 어떠한 요구사항을 만족시키는 새로운 방법을 배우기 위해 코드를 읽을 수도 있고, 아니면 뭔가 멋진 부분을 발견하길 기대하면서 그냥 코드를 읽어 나갈 수도 있습니다. 후자의 경우 자신이 잘 몰랐던 흥미로운 부분을 세부적으로 파고들 준비가 필요합니다. 그런 흥미로운 부분으로는 언어의 어떤 기능들, API, 알고리즘, 자료구조, 아키텍처, 설계 패턴 등을 꼽을 수 있습니다.

 

코드의 특정한 비기능적 요구사항이 어떤 구체적인 구현 스타일로 이어지는 측면을 인식하고 음미해보면 이식성이나 시간 또는 공간 효율성, 가독성같은 비기능적인 요구사항들 때문에 코드에 매우 독특한 개성이 생기기도 합니다.

 

가끔은 자신에게 생소한 환경의 코드를 읽게 되는 경우도 있는데, 프로그래밍에 익숙하며 기본적인 전산학 개념들을 가지고 있는 사람이라면 소스 코드를 통해서 새로운 환경의 기본적인 사항들을 배울 수도 있을 것입니다. 그러나 그렇다 하더라도 일단은 작은 프로그램으로 시작을 해야 할 것입니다. 즉시 커다란 오픈소스 소프트웨어 시스템으로 뛰어드는 일은 피하는 것이 좋습니다. 작은 프로그램들을 읽고, 직접 빌드해서 실행해 보십시오. 그러면 코드가 어떻게 작동할 것인가에 대한 추측을 직접 확인 할 수 있으며, 또한 일종의 성취감도 얻을 수 있습니다. 그 다음으로 해볼 일은 코드를 적극적으로 변경하면서 코드에 대한 자신의 이해를 시험해보는 것입니다. 이 역시 작은 변경들로 시작해서 점차 범위를 넓혀 나가야 합니다.

 

진짜 코드를 적극적으로 읽고 바꾸고 시험해보면 새로운 환경의 기초를 빠르게 배울 수 있습니다. 어느 정도 숙달되었다고 느낀다면 그 환경을 좀 더 체계적인 방식으로 배우기 위해 시간을 투자해보는 것도 나쁘지 않습니다. 관련 서적이나 문서, 메뉴얼 페이지들을 읽는다거나 강좌를 수강하는 등, 그 두 학습 방법은 서로를 보완합니다.

 

문학으로서의 코드 읽기의 또 다른 적극적 방법으로 들 수 있는 것은 바로 코드의 개선입니다. 다른 문학 작품들과는 달리, 소프트웨어 코드는 끝없기 개선되는, 살아있는 문헌입니다. 코드가 독자나 독자의 공동체에 가치 있는 것이라면 그 코드를 어떻게 개선할 것인가를 고민해야 합니다. 코드의 개선은 더 나은 설계나 알고리즘을 도입하는 것일 수도 있고, 코드의 어떤 부분을 문서화하는 것일 수도 있고, 아니면 새로운 기능성을 추가하는 것일 수도 있습니다. 오픈소스 소프트웨어 코드는 문서화가 잘 되어 있지 않은 경우가 많습니다. 코드에 대한 자신의 이해를 개선된 문서화로 재투자하는 것을 고려해 보십시오. 기존 코드를 다룰 때에는 원 저자나 유지보수 관리자와의 협동에 신경을 써야합니다. 그렇지 않으면 노력이 중복이 되거나 서로 기분이 상할 수 있습니다. 코드에 어떠한 실질적인 변경을 가하는 수준이라면 CVS의 제출자가 되는 것, 즉 프로젝트의 소스 기반에 코드를 직접 올리는 권한을 얻는 것도 생각해봐야 할 것입니다. 오픈소스 소프트웨어로부터 받은 이익을 일종의 대출금이라고 생각해야 합니다. 그 대출금은 오픈소스 공동체에 자신의 노력을 되돌려 줌으로써 갚아 나갈 수 있습니다.

 

두번째로는 본보기로서의 코드읽기입니다. 소프트웨어의 어떤 특정한 기능성을 실현하는 방법이 궁금한 경우가 있습니다. 응용 분야의 성격이나 종류에 따라서는 그런 의문의 답을 표준적인 교재나 전문 분야의 간행물, 연구 논문들에서 얻을 수도 있습니다.

 

그러나 많은 경우 "남들은 어떻게 하나"라는 의문에 답을 얻는 가장 좋은 방법은 코드를 읽는 것입니다. 코드 읽기는 또한 어떤 주어진 구현과 호환되는 소프트웨어를 만드는 가장 확실한 방법일 가능성도 큽니다.

 

코드를 본보기로서 사용할 때의 핵심은 유연해야 한다는 것입니다. 어떠한 코드의 작동방식을 이해하기 위해서는 다양한 전략과 접근방식을 적절히 사용해야 합니다. 우선 찾을 수 있는 문서들로부터 시작해보는 것이 좋습니다. 공식적인 소프트웨어 설계서가 있다면 가장 좋겠지만, 사용자용 문서도 도움이 될 수 있습니다. 시스템을 실제로 사용해보면서 시스템의 외부 인터페이스에 익숙해져야 합니다. 그리고 자신이 찾고 있는 것이 정확히 무엇인지, 예를 들어 시스템 호출인지, 알고리즘인지, 코드 시퀀스인지, 아키텍처인지 등을 확실하게 파악해야 합니다. 그리고 그 대상을 찾아내기 위한 적절한 전략을 고안해야 합니다. 검색 전략은 목적에 따라 다릅니다. 명령 수행의 흐름을 추적해야 할 수도 있고, 프로그램을 실행하고 전략적인 위치에 중단점(breakpoint)을 설정해야 할 수도 있습니다. 이 때 도구들이 도움이 될 수 있는데, 특정 도구 하나에만 의존하는 것은 피해야 합니다. 어떤 한 전략으로 원하는 결과를 빠르게 얻을 수 없다면 그 전략을 폐기하고 다른 방법을 생각해보아야 합니다. 명심할 것은 어딘가에는 찾고자 하는 코드가 틀림없이 있으니 어떻게든 찾아내야 한다는 점입니다.

 

원하는 코드를 찾았다면 그것을 연구하되, 관련이 없는 요소들은 무시할 수 있어야합니다. 이는 몸소 체득해야 하는 기술입니다. 찾아낸 코드를 그 자체의 맥락 하에서 이해하는 게 어렵다면, 그 코드를 임시 파일로 복사하고 관련이 없는 부분을 모두 제거하는게 좋습니다. 이런 절차를 공식적으로는 분할이라고 부릅니다.

 

세번째로는 유지보수를 위한 코드읽기입니다. 코드가 따라 배울만한 본보기가 아니라 수정과 교정이 필요한 어떤 것일 수도 있습니다. 어떤 커다란 시스템에서 버그를 발견했다고 해봅시다. 그런 경우라면 버그를 일으키는 문제를 발견할 때까지 세부 수준을 증가시켜 가면서 코드를 읽고 이해하는 어떠한 전략전술들이 필요합니다. 이 때의 핵심은 도구를 적절히 사용하는 것입니다. 디버거나 컴파일러의 경고 메시지 또는 기호 코드 출력, 시스템 호출 추적기, 데이터베이스의 SQL 기록 기능, 패킷 덤프 도구, Windows 메시지 스파이 프로그램 등 적절한 도구를 통해서 버그의 위치를 찾아내야 합니다. 코드를 조사하면서 문제의 표현으로부터 문제의 원천을 찾아나가야 합니다. 이 때 관련이 없는 경로를 따라가서는 안 됩니다. 디버깅을 활성화시킨 상태에서 프로그램을 컴파일하고, 디버거의 스택 추적 기능이나 단계별 실행 기능, 그리고 데이터 및 코드 중단점들을 이용해서 검색의 범위를 좁혀나가야 합니다.

 

디버거가 별 도움이 안된다면 프로그램 실행 결로의 전략적 지점들에 출력문을 집어넣는 방법도 고려해야 합니다. Java 코드를 조사한다면, AspectJ를 이용해서 오직 특정한 상황에서만 실행되는 프로그램 코드 요소들에 출력문을 집어넣는 것도 좋은 방법입니다. 문제가 운영체제의 인터페이스와 관련되어 있다면, 시스템 호출 추적 기능을 통해서 문제의 근원에 접근할 수 있는 경우가 많습니다.

 

네번째는 코드의 진화를 위한 코드읽기입니다. 대부분의 경우는 어떤 결함을 고치기 위해서 코드를 읽기보다는 새로운 기능을 추가하거나, 기존 기능을 수정하거나, 코드를 새로운 환경과 요구사항에 적응시키거나, 또는 비기능적인 품질들의 개선을 위한 리팩토링 목적으로 코드를 읽습니다. 그런 경우 핵심은 조사하는 코드의 범위 안에서 최대한 선택적이 되어야 한다는 점입니다. 대부분의 경우 전체적인 시스템의 구현 중 매우 낮은 비율만 이해해도 충분합니다. 즉, 단지 한두 개의 파일만 선택적으로 이해하고 수정하는 것으로도 백만 줄짜리 시스템을 수정하거나 개선할 수 있는 것입니다. 그리고 그런 일을 해내게 되면 매우 통쾌한 기분을 느낄 수 있는데, 그런 느낌을 여러분도 꼭 한 번 체험해봤으면 좋겠습니다. 커다란 시스템의 부분들을 선택적으로 조사할 때 유효한 전략으로는 흥미가 가는 코드 부분들을 찾고, 그 특정한 부분들을 고립시켜서 이해하고, 그 부분들과 나머지 부분 사이의 관계를 추론하는 것입니다.

 

시스템에 새로운 기능성을 추가할 때 제일 먼저 해야 할 일은 추가하고자 하는 기능성과 비슷한 기능의 구현을 찾는 것입니다. 어떤 기능의 기능적 명세로부터 코드 구현으로 나아가는 일은 문자열 메시지를 따라가거나 핵심어로 코드를 검색하는 것으로 시작해야 합니다. 예를 들어 ftp 명령의 코드에서 사용자 인증부분을 찾고자 한다면 Password라는 문자열을 검색하면 될 것입니다.

 

해당 기능을 찾았다면 그 구현을 연구하고, 새로운 또는 추가적인 기능을 설계하고, 새로운 코드가 형향을 미칠 영역, 즉 새 코드와 상호작용하는 다른 코드 부분들을 찾습니다. 대부분의 경우는 그 코드 부분들만 상세하게 이해하면 됩니다.

 

코드를 새로운 환경에 적응시키는 일은 기능 추가와는 또 다른 과제이며, 따라서 전략 역시 달라야 합니다. 종종 두 환경들이 비슷한 기능들을 제공하는 경우가 있습니다. 예를들어 Sun Solaris용 코드를 GNU/Linux로 이식할 수도 있고, 어떤 Unix 시스템의 코드를 Microsoft Windows로 이식할 수도 있습니다. 그런 상황에서는 컴파일러가 가장 큰 도움이 됩니다. 이런 접근방식을 사용해보십시오. 우선, 처음부터 이식 과제가 완성되었다고 가정하고 시스템을 컴파일해봅니다. 당연히 수많은 경고와 오류 메시지들이 나올 것입니다. 그 메시지들이 지적하는 사항들을 꼼꼼히 하나씩 고쳐나가다 보면 결국은 깨끗한 빌드가 만들어질 것입니다. 그런 후에는 시스템의 기능성을 확인해봅니다. 실제로 이런 방식을 따라가 보면 읽어야 할 코드의 양이 크게 줄어든다는 점을 깨달을 수 있을 것입니다. 어떤 함수나 클래스, 템플릿, 자료구조의 인터페이스를 수정할 때에도 이와 비슷한 전략을 사용하는 것이 가능합니다. 대부분의 경우 변경의 영향을 직접 찾아서 교정하는 것보다는 컴파일러의 오류나 경고 메시지를 이용해서 문제가 생긴 부분을 찾게됩니다. 그런 부분을 고치면 새로운 오류들이 생기기도 하는데, 역시 마찬가지 방법으로 코드를 찾고 수정하다 보면 새 코드가 영향을 미치는 다른 코드들을 모두 찾아서 고칠 수 있습니다.

 

코드의 새 환경이 기존 것과 완전히 다르다면 앞에서 말한 것과는 다른 접근방식을 택해야 합니다. 이런 경우 코드 읽기 노력을 최소화하기 위한 핵심은 기존 코드와 새 환경 사이의 인터페이스가 다른 지점들에 집중하는 것입니다. 명령행 도구를 GUI 환경으로 이식하는 경우라면 사용자 상호작용 코드에 집중하고 시스템의 알고리즘 측면은 무시하는 것이 될 것입니다.

 

지금까지 이야기한 코드 진화들과는 완전히 다른 부류의 코드 진화가 있는데, 바로 리팩토링입니다. 리팩토링을 위한 코드 변경의 경우 익스트림 프로그래밍이나 애자일 프로그래밍 같은 방법론들을 채용한 일부 개발 공정에서 그 중요성이 증가되고 있습니다. 리팩토링을 간략히 이야기하자면 시스템의 정적인 외부 행동방식은 바꾸지 않고 단순성이나 유연성, 이해 가능성, 성능 같은 비기능적 품질들을 개선시키기 위한 것입니다. 리팩토링은 성형수술과 비슷한 면이 있습니다. 리팩토링은 잘 작동하는 시스템으로 시작하며, 결과 역시 잘 작동하는 시스템이어야 합니다. 즉 리팩토링 때문에 시스템의 기능성이 훼손되어서는 안 된다는 뜻인데, 이를 보장하기 위해 필요한 것이 적절한 테스트 케이스들의 모음입니다. 따라서 리팩토링은 테스트 케이스들부터 작성하는 것으로 시작해야 합니다. 리팩토링 중에는 이미 알려진 문제 지점을 고치기 위한 것도 있습니다. 그런 경우 기존 코드 부분을 읽고, 이해하고, 새 구현을 설계하고, 새 코드가 그에 접하고 있는 다른 코드에 미치는 영향을 연구하고, 변경을 실제로 실현합니다.

 

리팩토링에는 또한 코드를 적극적으로 살펴보면서 소프트웨어 시스템의 품질을 위해 개선할 만한 부분을 찾는 것도 포함됩니다. 이는 시스템의 설계와 구조의 전반적인 상이 필요한 몇 안 되는 경우들 중 하나입니다. 이러한 대규모의 리팩토링은 소규모의 리팩토링보다 더 많은 이익을 제공할 가능성이 큽니다. 리팩토링 기회를 찾기 위해 코드를 읽을 때에는 시스템의 아키텍처로부터 세부 수준을 증가시켜 가면서 아래로 내려가는 방식이 더 큰 성과를 얻을 수 있습니다.

 

다섯번째는 재사용을 위한 코드읽기입니다. 재사용할 수 있는 요소를 찾기 위해 코드를 읽기도 하는데, 이 때의 핵심은 기대를 작게 가지는 것입니다. 코드 재사용성은 솔깃하지만 이루기 힘든 개념입니다. 기대를 작게 가지면 그만큼 실망도 작습니다. 재사용할 수 있는 코드를 작성하는 것은 매우 어려운일입니다. 수년 동안 시간의 검증을 통과해서 여러 가지 서로 다른 상황들에 다시 스이는 소프트웨어들의 수는 상대적으로 매우 적습니다. 일반적으로, 소프트웨어 부품들이 재사용 후보가 되기 위해서는 적어도 두세 개의 다른 시스템들 상의 작업에 대해서 우아하게 확장되고 반복적으로 적응되어야 합니다. 대충 즉자적으로 개발된 소프트웨어가 그렇게 확장, 적응되는 경우는 드믑니다. COCOMO 소프트웨어 비용 모형에 따르면, 재사용 가능한 소프트웨어를 만드는 것은 개발 노력에 50프로까지의 이득이 된다고 합니다.

 

자신이 마주하고 있는 특정 문제에 대해 재사용할 수 있는 어떤 코드를 찾는다면, 우선 문제를 해결하는 코드를 격리시켜야 합니다. 이 때 대부분의 경우는 시스템 코드에 대한 핵심어 기반의 검색을 통해서 해당 구현 부분을 찾을 수 있습니다. 재사용하고자 하는 코드가 다루기 힘들다면, 즉 이해하기도 어렵고 격리시키키도 어렵다면 좀 더 큰단위의 패키지를 살펴보거나 다른 코드를 살펴보아야합니다. 예를 들어 코드 조각 하나와 그것을 둘러 싼 다른 요소들 사이의 복잡다단한 관계를 이해하는 데 힘을 빼기보다는 그 코드가 있는 전체 라이브러리나 구성 요소, 프로세스, 심지어는 시스템 전체를 살펴보는 것이 좋습니다.

 

특정한 목적 없이 그냥 코드를 읽어가면서 재사용 가능한 보석들을 찾을 수도 있습니다. 이런 때에는 이미 재사용되는 코드를 살펴보는 것이 좋을 것입니다. 적절한 패키징 방법들이나 구성 메커니즘을 살펴보면 재사용 가능한 코드를 찾게 될 가능성이 큽니다.

 

마지막으로 검토를 위한 코드읽기입니다. 작업 설정에 따라서는 코드 읽기가 정규 업무의 일부일 수도 있습니다. 코드 훑기, 조사, 라운드로빈 검토, 기타 여러 종류의 기술적 평가를 개발 공정에 통합된 한 부분으로 사용하는 소프트웨어 개발 방법론들은 많이 있습니다. 더 나아가 익스트림 프로그래밍 방법론을 적용할 때 쓰이는 짝 프로그래밍에서는 한 사람이 코드를 작성하는 동안 다른 한 사람이 코드를 읽는데, 이런 상황에서의 코드 읽기에는 다른 차원의 이해와 판단, 경각심이 필요합니다. 이 경우의 핵심은 철저함입니다. 이 때에는 함수나 로직의 오류를 집어내기 위해 코드를 조사합니다. 그리고 눈에 보이지 않는 것들에 대해 논의를 할 준비도 필요합니다. 즉, 코드가 그 코드에 적용되는 모든 요구사항들을 만족하는지 확인해야 하는 것입니다.

 

코드의 비기능적 문제들에도 기능적인 문제들과 같은 양의 주의를 돌려야 합니다. 예를 들면 코드가 조직의 개발 표준과 스타일 지침을 만족하는가, 리팩토링 기회가 있는가, 어떠한 요소가 기존의 라이브러리나 구성 요소를 재사용할 수 있는가 등의 문제들을 고민해야 합니다. 소프트웨어 시스템을 검토할 때에는 소프트웨어 시스템이라는 것이 실행 가능한 명령문들 이외에도 많은 요소들로 이루어져 있다는 점을 염두에 두어야합니다. 파일과 디렉터리 구조, 빌드 및 구성 과정, 사용자 인터페이스, 시스템의 문서화 등도 조사해야 합니다.

 

소프트웨어 검토와 관련 활동에는 사람들 사이의 상호작용이 많이 연관됩니다. 소프트웨어 검토를 배우고, 가르치고, 서로 도움을 주고받을 수 있는 기회로 사용하십시오.