first-contributions/docs/additional-material/translations/Korean/Things a non Programmer can do.kr.md

오픈소스 프로젝트는 프로그래머만 기여할 수 있는 것이 아닙니다. 코딩 실력이 없어도 오픈소스 프로젝트에 참여하고 기여할 수 있는 다양한 방법들이 있습니다.

경청하기

오픈소스의 모든 것은 다른 사람들과의 상호작용을 포함합니다. 여러분은 팀에 합류하려는 것이므로, 커뮤니티와 그 작동 방식을 이해하는 것이 중요합니다. 프로젝트에 불쑥 끼어들어 "안녕하세요, 이 프로젝트는 이렇게 해야 한다고 생각합니다"라고 말하는 것은 일반적으로 좋게 받아들여지지 않습니다. 그런 접근 방식을 환영하는 프로젝트도 있겠지만, 프로젝트가 오랫동안 진행되어 온 경우 그러한 태도가 받아들여질 가능성은 적습니다. 경청하는 것이 프로젝트에 필요한 것을 아는 가장 좋은 방법입니다.

1. 메일링 리스트 가입하기: 많은 프로젝트에서 메일링 리스트는 프로젝트 개발에 대한 주요 커뮤니케이션 수단입니다. 대규모 프로젝트에는 선택할 수 있는 메일링 리스트가 많습니다. 예를 들어, PostgreSQL 프로젝트는 메일링 리스트 페이지에 사용자 중심 리스트 12개 이상과 개발자 리스트 6개를 보유하고 있습니다. 시작하려면 주요 사용자 중심 리스트와 핵심 개발자 리스트를 팔로우하여 경청하는 것을 추천합니다.

2. 블로그 팔로우하기: 핵심 개발자들이 운영하는 블로그는 종종 향후 릴리스에 대한 정보와 그 과정에 대한 정보를 제공합니다. 플래닛 사이트는 프로젝트와 관련된 여러 출처의 뉴스 및 블로그 게시물을 모아 보여줍니다. planet.gnome.org나 planet.mysql.com과 같은 플래닛 사이트가 있다면 거기서부터 시작하세요. Google에서 "planet <프로젝트 이름>"으로 검색해보세요.

3. IRC 채널 가입하기: 많은 오픈소스 프로젝트에는 개발자와 사용자가 문제 및 개발에 대해 논의하는 전용 IRC(Internet Relay Chat) 채널이 있습니다. 프로젝트 웹사이트에서 채널 이름과 IRC 네트워크 세부 정보를 확인하세요.

티켓 작업하기

코드는 모든 오픈소스 프로젝트의 핵심이지만, 코드를 작성하는 것만이 기여하는 유일한 방법이라고 생각하지 마세요. 코드 유지 보수 및 코드를 둘러싼 시스템은 새로운 기능을 만들고 버그를 수정하는 데 급급하여 종종 소홀히 다루어집니다. 이러한 영역을 프로젝트에 발을 들여놓을 수 있는 쉬운 방법으로 살펴보세요. 대부분의 프로젝트에는 프로젝트 웹사이트 첫 페이지에 링크되어 있고 문서에 포함된 공개적으로 볼 수 있는 문제 티켓 시스템이 있습니다. 이는 사용자와 개발자 간의 주요 커뮤니케이션 수단입니다. 이를 최신 상태로 유지하는 것은 프로젝트를 돕는 좋은 방법입니다. 티켓 시스템에서 특별한 권한을 얻어야 할 수도 있는데, 대부분의 프로젝트 리더는 티켓 정리를 돕고 싶다고 말하면 기꺼이 권한을 부여할 것입니다.

4. 버그 진단하기: 버그는 종종 제대로 보고되지 않습니다. 버그를 진단하고 분류하는 것은 개발자가 문제의 세부 사항을 파악하는 데 드는 수고를 덜어줄 수 있습니다. 사용자가 "X를 하면 소프트웨어가 작동하지 않습니다"라고 보고했다면, 그 문제의 구체적인 내용이 무엇인지 파악하는 데 시간을 투자하세요. 반복 가능한가요? 문제를 반복적으로 발생시킬 수 있는 일련의 단계를 만들 수 있나요? 특정 브라우저에서만 발생하거나 특정 배포판에서만 발생하는 등 문제를 좁힐 수 있나요?

문제의 원인을 모르더라도, 상황을 좁히기 위해 기울인 노력은 다른 사람이 문제를 해결하는 것을 더 쉽게 만듭니다. 발견한 모든 것을 모든 사람이 볼 수 있도록 버그 시스템의 티켓에 추가하세요.

5. 수정된 버그 닫기: 종종 버그는 코드베이스에서 수정되지만, 이에 대해 보고된 티켓은 티켓 시스템에서 업데이트되지 않습니다. 이러한 불필요한 것들을 정리하는 것은 시간이 많이 걸릴 수 있지만, 전체 프로젝트에 매우 중요합니다.

먼저 1년 이상 된 티켓을 티켓 시스템에서 쿼리하여 버그가 여전히 존재하는지 확인하세요. 프로젝트의 릴리스 변경 로그를 확인하여 버그가 수정되었고 닫을 수 있는지 확인하세요. 수정된 것으로 알려져 있다면 티켓에 버전 번호를 기록하고 닫으세요.

소프트웨어의 최신 버전으로 버그를 재현해보세요. 최신 버전으로 재현할 수 없다면 티켓에 기록하고 닫으세요. 여전히 존재한다면 티켓에 기록하고 열어 두세요.

코드 작업하기

모든 경험 수준의 프로그래머가 프로젝트의 코드를 도울 수 있습니다. 좋아하는 프로젝트에 실질적인 기여를 하기 위해 코딩 천재가 되어야 한다고 생각하지 마세요.

작업에 코드 수정이 포함된다면, 프로젝트가 기여자로부터 코드를 받는 데 사용하는 방법을 조사하세요. 각 프로젝트마다 고유한 워크플로우가 있으므로, 코드를 제출하기 전에 어떻게 해야 하는지 물어보세요.

예를 들어, PostgreSQL 프로젝트는 매우 엄격한 프로세스를 따릅니다. 코드 수정은 핵심 개발자들이 변경 사항의 모든 측면을 면밀히 조사하는 메일링 리스트에 패치 형태로 전송됩니다. 반대편에는 Parrot과 같이 코드베이스에 커밋 권한을 쉽게 얻을 수 있는 프로젝트도 있습니다. 프로젝트가 GitHub를 사용하는 경우, GitHub의 풀 리퀘스트 기능을 사용하는 워크플로우가 있을 수 있습니다. 어떤 프로젝트도 똑같지 않습니다.

코드를 수정할 때마다 커뮤니티의 책임 있는 구성원으로서 행동하고 코드 스타일을 나머지 코드베이스와 일치시키도록 하세요. 추가하거나 수정하는 코드는 다른 코드와 같아야 합니다. 중괄호 스타일이나 들여쓰기를 위한 공백 처리가 마음에 들지 않을 수도 있지만, 기존 표준과 일치하지 않는 코드 변경을 제출하는 것은 무례한 행동입니다. 이는 "당신의 스타일이 마음에 들지 않고 내 스타일이 더 낫다고 생각하므로 내 방식대로 해야 합니다"라고 말하는 것과 같습니다.

6. 베타 또는 릴리스 후보 테스트하기: 여러 플랫폼에서 실행되도록 설계된 모든 프로젝트는 온갖 종류의 이식성 문제를 겪을 수 있습니다. 릴리스가 다가오고 베타 또는 릴리스 후보가 게시되면 프로젝트 리더는 많은 다른 사람들이 많은 다른 플랫폼에서 테스트하기를 바랍니다. 여러분은 그 사람들 중 한 명이 되어 패키지가 자신의 플랫폼에서 작동하는지 확인하는 데 도움을 줄 수 있습니다.

일반적으로 소프트웨어를 다운로드, 빌드 및 테스트하기만 하면 되지만, 흔하지 않은 배포판이나 하드웨어를 사용하고 있다면 프로젝트에 엄청난 가치를 제공할 수 있습니다. 빌드 및 테스트가 작동한다고 보고하는 것만으로도 프로젝트 리더는 임박한 릴리스가 견고하다는 것을 알 수 있습니다.

7. 버그 수정하기: 이것은 일반적으로 코드 작업을 시작하려는 기여자들의 시작점입니다. 간단합니다. 티켓 시스템에서 흥미롭게 들리는 버그를 찾아 코드에서 수정하려고 시도하세요. 적절하다면 코드에 수정 사항을 문서화하세요. 수정한 코드 부분을 테스트하기 위해 테스트 스위트에 테스트를 추가하는 것이 좋습니다. 일부 프로젝트에서는 버그 수정에 테스트를 포함하도록 요구합니다. 이 익숙하지 않은 코드베이스를 살펴보면서 메모를 계속 작성하세요. 버그를 수정할 수 없더라도 수정 시도의 일환으로 발견한 내용을 티켓에 문서화하세요. 여러분이 발견한 내용은 다음에 오는 사람들에게 도움이 됩니다.

8. 테스트 작성하기: 대부분의 프로젝트에는 코드를 테스트하는 테스트 스위트가 있지만, 더 많은 테스트를 추가할 수 없는 테스트 스위트는 상상하기 어렵습니다. C 언어용 gcov 또는 Perl용 Devel::Cover와 같은 테스트 커버리지 도구를 사용하여 테스트 스위트에서 테스트되지 않는 소스 코드 영역을 식별하세요. 그런 다음, 테스트를 스위트에 추가하여 해당 영역을 커버하세요.

9. 컴파일러 경고 잠재우기: 많은 C 기반 프로젝트의 빌드 프로세스는 종종 이상한 컴파일러 경고 플래그를 화면에 뿜어냅니다. 이러한 경고는 일반적으로 문제의 지표는 아니지만 그렇게 보일 수 있습니다. 너무 많은 경고는 컴파일러가 거짓 경고를 하는 것처럼 들리게 할 수 있습니다. 코드가 실제로 버그를 숨기고 있는지 확인하세요. 그렇지 않다면, 소스를 수정하여 잠재우는 것은 이러한 오탐을 숨기는 데 도움이 됩니다.

10. 주석 추가하기: 코드를 살펴보는 동안 혼란스러운 부분이 있을 수 있습니다. 여러분이 혼란스러웠다면 다른 사람들도 마찬가지일 가능성이 높습니다. 코드에 문서화하고 패치를 제출하세요.

문서 작업하기

문서는 일반적으로 프로젝트에서 소홀히 다루어지는 부분입니다. 또한 프로젝트에 익숙한 사람들의 관점에서 작성되어, 막 시작하는 사람의 관점이 아닌 경우도 있습니다. "이 매뉴얼은 내가 이미 이 패키지를 사용하는 방법을 알고 있다고 기대하는 것 같아"라고 생각한 적이 있다면 제가 무슨 말을 하는지 아실 겁니다. 종종 새로운 시선은 프로젝트와 가까운 사람들이 알아차리지 못하는 문서의 결함을 지적할 수 있습니다.

11. 예시 만들기: 예시가 너무 많은 프로젝트는 없습니다. 웹 API든, 루틴 라이브러리든, Gimp와 같은 GUI 앱이든, 명령줄 도구든, 올바른 사용법에 대한 좋은 예시는 수백 페이지의 문서보다 더 명확하고 빠르게 소프트웨어의 올바른 사용법을 설명할 수 있습니다. API나 라이브러리의 경우, 도구를 사용하는 예시 프로그램을 만드세요. 이는 여러분이 작성한 코드에서 최소한의 필수적인 부분만 추출하여 만들 수도 있습니다. 도구의 경우, 일상생활에서 어떻게 사용했는지에 대한 실제 사례를 보여주세요. 시각적인 것을 선호한다면, 애플리케이션 설치 방법과 같은 중요한 프로세스의 화면 캡처를 만드는 것을 고려해 보세요.

커뮤니티와 함께 작업하기

오픈소스는 코드에 관한 것만이 아닙니다. 커뮤니티가 오픈소스가 작동하도록 만듭니다. 커뮤니티를 구축하는 데 도움을 줄 수 있는 방법은 다음과 같습니다.

12. 질문에 답하기: 커뮤니티를 구축하는 가장 좋은 방법은 다른 사람들을 돕는 것입니다. 특히 막 시작하는 사람들의 질문에 답하는 것은 프로젝트가 성장하고 번성하는 데 매우 중요합니다. 초보자를 돕는 데 시간을 투자하는 것은, 비록 "RTFM(매뉴얼을 읽으세요)"이라고 간단히 대답할 수 있는 질문일지라도, 나중에 또 다른 활발한 커뮤니티 구성원을 얻는 데 도움이 됩니다. 모든 사람은 어디서든 시작하며, 프로젝트는 활력을 유지하려면 꾸준한 인력 유입이 필요합니다.

13. 블로그 게시물 작성하기: 블로그가 있다면, 사용하고 있는 프로젝트에 대한 경험에 대해 글을 써보세요. 소프트웨어를 사용하면서 직면했던 문제와 그것을 해결하기 위해 무엇을 했는지 이야기해 주세요. 이렇게 하면 두 가지 방식으로 도움이 됩니다. 하나는 프로젝트를 주변 사람들의 마음에 계속 각인시키는 데 도움이 되고, 다른 하나는 미래에 여러분과 같은 문제를 겪고 웹에서 해결책을 검색하는 모든 사람을 위한 기록을 만드는 데 도움이 됩니다. (기술적인 모험에 대한 블로그는 나중에 해당 소프트웨어를 사용하는 직업을 찾을 때 실제 경험을 보여주는 훌륭한 방법이기도 합니다.)

14. 웹사이트 개선하기: 웹 디자인 기술이 있고 웹사이트를 개선하여 프로젝트의 대중적인 이미지를 향상시킬 수 있다면, 이는 잘 보낸 시간입니다. 아마도 프로젝트는 그래픽 전면 개편이나 프로젝트를 식별할 로고가 필요할 수도 있습니다. 이러한 기술은 커뮤니티에 부족할 수 있습니다. 저도 제 프로젝트 웹사이트에 그래픽 디자인 지원을 받을 수 있다면 좋을 것 같습니다.

15. 기술 문서 작성하기: 애플리케이션이나 소프트웨어가 어떻게 작동하는지 설명할 수 있다면, 그것에 대한 기술 문서를 작성할 수 있습니다. 특히 일반 대중이 읽을 수 있도록 기술 문서를 업데이트, 개편, 확장 또는 만들고자 하는 오픈소스 프로젝트라면 더욱 그렇습니다. 일반 영어로 더 많이 쓸수록 좋습니다. 가장 좋은 점은 기술 문서를 작성하기 위해 프로그래머가 될 필요가 없다는 것입니다.

무엇보다도, 주변 사람들이 논의하는 내용을 경청하세요. 절실한 필요를 알아볼 수 있는지 살펴보세요. 예를 들어, 최근 Parrot 개발자 메일링 리스트에서 기존 Trac 설치를 버리고 GitHub를 문제 티켓 시스템으로 사용하기로 결정했습니다. 일부 사람들은 티켓을 GitHub 시스템으로 변환할 방법이 없었기 때문에 이 결정에 반대했습니다. 하루 동안 논쟁이 오고 간 후, 제가 끼어들어 "제가 변환기를 작성하면 어떨까요?"라고 말했습니다. 사람들은 그 아이디어에 열광했습니다. 저는 450개 이상의 티켓에 대한 변환 프로그램을 작성하는 데 시간을 보냈고, 그래서 티켓 기록을 하나도 잃지 않았습니다. 큰 성공이었습니다. 저는 참여할 수 있었고, 핵심 개발자들은 Parrot 작업에 집중할 수 있었습니다.

16. 다른 사람들을 가르치고 돕기: 어떤 주제에 대해 더 많이 배우는 가장 좋은 방법은 그것을 가르치려고 노력하는 것입니다. 최고의 교사는 복잡한 내용을 간단한 예시로 설명할 수 있는 사람입니다. 따라서 최고의 학습자가 되고 프로그래밍 세계에서 최고가 되려면 최고의 교사가 되기 위해 노력해야 합니다. 다른 사람들을 가르치는 것은 자신에 대해 더 나은 기분을 느끼게 하고 직업에서 더 나은 기술과 지식을 얻는 데 도움이 될 것입니다. 누군가에게 도움을 받으면 혼자 간직하지 말고 다른 사람들과 공유하세요. 세상을 더 살기 좋은 곳으로 만드세요.