소스코드가 상당히 긴 경우에도 보통 다보고 이해하시나요???

다 이해 못하죠
짧은 개발 일정에 오픈소스 몇만줄 다 보고 이해하고 만드는 사람이 얼마나 있겠습니까.
오픈소스의 인터페이스와 중요한 시퀀스정도 파악한 다음에 고쳐야할 부분과 그렇지 않은 부분을 나누고 고쳐야할 부분을 파악해나가면서 하는거죠.
xylosper님의 말씀처럼 보는 사람의 능력이 아니라 소스코드를 만드는 사람의 능력인 부분이 큽니다.

제 기준입니다만, 오픈소스를 사용할 때 소스코드를 어느정도 읽어보고 파악하기 쉬운가 구조가 잘 짜여져 있는가를 판단한 다음에 사용할지 버릴지를 선택합니다.
지금 필요한 기능이 다 구현되어 있는 오픈소스라고 해서 무턱대고 사용하다가 크게 데입니다.
사실 몇번 있었습니다.
필요한 기능중 주요 기능이 구현되어 있고 잘 짜여진(것 처럼 보이는) 오픈소스를 가져와서 거기에 구현이 안된 기능을 몇가지 추가해서 만드는게 더 나은 경우도 많습니다.

비슷한 내용의 글을 연달아서 올리신 정도면...

Source 라는 것은 결국 같은 문법으로 만들어 진 것이기 때문에 영문을 사전찾으면서 번역하듯 천천히 찾으면 다 파악 할 수 있습니다.

하지만 "이 Source는 왜 이렇게 짜여졌는가? 이 프로그램은 왜 이렇게 구현하도록 만들어 졌는가?" 는 당연히 인수인계나 메뉴얼이 없다면 누구에게다 다 어렵습니다.

어딜 가더라도 기존에 선배들이 짜 놓은 프로그램은 길겁니다. 그걸 곧이 곧대로 다 읽어서 이해하는것은 정말 무식하고 힘든 방법입니다. 그런데 예를 들어 공격자 입장에서 방어자 입장의 회사 프로그램을 리뷰하거나 이해해야 할때는 코드와 다큐멘트 해 놓은걸 보는 수 밖에 없지요.

허나, 질문하신 내용으로 봐서 순수 개발자 입장에서 선배 개발자들이 짜 놓은 어마무시하게 긴 코드 (몇십만 ~ 몇천만 스텝) 를 받아 이해 하고 덧붙여 수정이나 개발을 해야 하는것 같은데, 그럴땐 의외로 간단한 방법 - 뭐 다들 아시는 뻔한 방법입니다.

제 경우는 그냥 실행해 봅니다. 그래서 수정요구된 부분을 집중해서 디버깅을 하지요. 그리고는 수정하면 쉽습니다. 물론 그 전에 이게 당최 뭐 하는 프로그램인지 알게 되는게 중요한데, 그건 코드 한줄 한줄 봐서 이해하는게 아니라 실행시켜서 하는 일과 결과, 로그를 보면서 대충 이해하게 되는겁니다.

글쎄요, 그냥 제 경우 그렇다는 이야기이고 또 다른 분들의 더 좋은 답이 있을지도 모르지요.