신입의 첫번째 ‘업무’ 소스 코드 분석하기

소스코드

소스 코드를 분석 한다는 것은 어떤 것일까? 🧐

회사에서 진행중인 프로젝트의 구조, 기능을 친절히 설명해줄 시간은 없다.
다른 사람의 소스 코드를 분석해본 경험이 없는 신입 개발자는 어떻게 코드를 읽고, 적응하면 좋을까?

소스코드와 오픈소스

소스코드란?
컴퓨터 소프트웨어의 제작에 사용되는 설계도이다. 개념만 나타낸 추상적인 설계도가 아니라, 당장 컴퓨터에 입력만 하면 진짜로 프로그램을 완성할 수 있는 매우 세밀하고 구체적으로 짜인 설계도이다.

첫 입사 후 내가 만나게 된 기존 코드들이 소스코드라고 할 수 있다.
업무에 들어가기 전 이 소스코드를 이해해야지만 기능 구현, 수정 또한 모두 할 수 있다.

소스코드 중 가장 많이 접하게 되는 것은 오픈소스 이다.

오픈소스란?
오픈 소스 소프트웨어는 소스 코드를 공개해 누구나 특별한 제한 없이 그 코드를 보고 사용할 수 있는 오픈 소스 라이선스를 만족하는 소프트웨어를 말한다. 통상 간략하게 오픈 소스라고 말하기도 하며 대한민국의 공공기관에서는 공개 소프트웨어라는 표현을 사용한다.
쉽게 말해 공개적으로 모두가 사용하고, 수정할 수 있는 설계도인 것이다.

오픈소스가 중요한 이유

오픈 소스의 아이디어는 기술 커뮤니티에서 나왔습니다. 기술 혁신이 발전하려면 글로벌 협업이 필요합니다. 예를 들어, 미국의 프로그래밍 팀이 금융 애플리케이션을 위한 새로운 오픈 소스 기술을 개발한다고 가정해 보겠습니다. 호주의 다른 프로그래밍 팀이 의료 부문에 더 적합한 새로운 기능으로 기술을 수정합니다. 그리고 아시아의 또 다른 팀은 원천 기술을 핵심 구성 요소로 사용하는 새로운 오픈 소스 제품을 개발합니다.

이러한 지식 공유와 집단적 혁신은 전체 커뮤니티에 도움이 됩니다. 특허, 저작권과 값비싼 라이선스로 기술을 제한하면 발전이 저해됩니다. 많은 인기 있는 오픈 소스 프로젝트가 지난 수십 년간 전 세계적으로 급속한 기술 발전으로 이어졌습니다.

출처 : AWS

소스 코드를 읽으면 좋은 점

  1. 코드 퀄리티 향상
    • 여러 종류의 프로그래밍 방식에 대해 알 수 있다.
    • Low Level에서 코드를 어떻게 추상화하는 지 파악할 수 있다.
  2. 다양한 지식 추가 습득
    • 코드를 작성하는 방식에 대한 기준을 가질 수 있다.
    • 코드 작성에 대한 키워드를 찾을 수 있다.
  3. 메타인지를 가질 수 있다
    • 코드의 길을 따라가며 여러가지 생각을 가질 수 있다.
    • ‘이걸 왜 이렇게 구현 했을까?’
    • ‘다른 방식으로 구현하면 어떨까?’

소스 코드를 읽는 방법

소스코드 나눠 읽기

  1. 배경지식을 갖출 것
    • 소스 코드에 사용 되는 언어와 라이브러리에 대한 배경 지식을 가지고 있지 않으면, 소스 코드를 분석하는 것은 불가능하거나 엄청난 시간이 필요하다.
  2. 소스의 목적을 명확히 이해할 것
    • 어떤 서비스, 어떤 기능을 하는 지 이해하지 못하면 삽질밖에는 할 수 없다. 주석과 파일명, 함수명, 호출 위치등에서 최대한 정보를 얻어내어 어떤 역할을 하는 소스 코드인지를 파악해야한다.
  3. 스타일을 파악 할 것
    • 같은 언어와 기능이라고 해도 작성자에 따라 스타일과 의도한 바가 다르다. 속도를 중요하게 생각 할 수도 있고, 직관적으로 보이는 것을 중요하게 생각 할 수도 있는 것이다. 변수나 함수 작명법, 에디팅 스타일, 유틸 함수, 에러 처리 등등 그 사람의 스타일을 이해하면 소스를 한층 더 정확하고 빠르게 읽을 수 있게 된다.
  4. 코드의 길을 따라 읽을 것
    • 길은 여러 방식이 있을 수 있다. 기능, 파일이나 폴더 등 큰 틀을 먼저 살핀 후 작은 함수 단위로 쪼개서 보는 게 좋다. 또는 기능 하나를 정한 후 기능의 진행 방향으로 코드를 읽어보는 것도 도움이 된다.

나에게 도움이 된 분석 태도와 팁

  1. 목적을 정하자
    • 처음 시작하면 너무 막막할 수 있다. 그럴때는 소스 코드를 실제로 실행시켜서 보면서 특정 기능이나 데이트를 찾아서 따라가는 것이 도움이 된다. 콘솔을 찍어가면서 실제로 어떤 데이터가 움직이는 지, 어떤 라이프사이클을 가지는 지 파악하는 게 첫 시작으로 좋았다.
  2. 코드를 한땀 한땀 분석 할 필요는 없다
    • 코드를 100% 이해 할 수 없다. 내가 짠 코드도 1년 뒤에 이해 안되는 데, 다른 사람이 짠 코드를 완전히 이해하는 게 가능 할까?
    • 회사에서 코드를 분석한다는 건, 사실 어떤 방식으로 코드를 작성하고 있는 지, 어떤 기능을 구현할 지를 보는 것이 아닐까 하는 생각을 하게 되었다.
  3. 조급해 하지 말자
    • 개발자는 마치 작가같다. 빨리보다 정확하게, 조금 더 나은 코드를 작성하기 위해 충분한 시간을 제공한다. 이 시간은 다시 오지 않을 시간이므로 소중하게 천천히 정확하게 알아가도록 해야한다. 너무 빨리 개발에 들어가고 싶어 할 필요는 없는 것 같다.
  4. 파일의 크기를 보고 겁먹지 말 것
    • 내가 경험해 본 사이드 프로젝트들과 다른 크기와 많은 라이브러리에 처음부터 겁을 먹을 필요는 없는 것 같다. 생각해보면 한 기능이 아무리 커봤자 눈앞에 있는 모든 코드에 관여해 있을 리는 없으니까!
  5. 모르는 부분은 메모하고, 찾아보고, 물어보자
    • 기능을 기준으로 코드를 분석하다보면 라이브러리 사용법이나 변수, 함수등에 막히는 경우가 생긴다. 이럴때는 메모를 해 두고 끝까지 읽는다. 가는 길에 해결책이 있는 경우도 있고, 인터넷이나 gpt를 통해 답을 얻는 경우도 있다. 하지만 그래도 모를 경우는 ‘어떤 것이 어려운지’, ‘어디까지 알아봤는 지’를 가지고 질문을 하자.
    • 그런데 좋은 질문을 하는 건 어렵더라…
  6. 용어를 정리하자
    • 변수명, 함수명, 어쩌면 편하게 사용하는 은어까지도 받아 적고 찾아보는 과정이 중요하다. 내가 놓친 지식을 더 알수도 있고, 코드를 읽을 때 다시 만나면 반갑기도 하다.
    • 또, 정리하는 과정에서 작성자의 습관을 알아내게 되는 것도 큰 도움이 되었다.
  7. 이전에 했던 방식 잊기
    • 내가 신입이라 베이스가 없어 이 부분은 문제가 없을 것이라 생각했었다. 그런데 오히려 이전 혼자서 작업 했던 방식이 전부일 것이라는 바보같은 생각으로 시야가 편협할 수 있더라. 개발의 세계에는 한개의 기능을 구현하더라도 수백, 수천개의 이유와 방식이 있을 수 있다는 것을 실제로 체감하게 되었다.




Reference