Thursday, March 24, 2022

현업 개발자의 Git Log 활용 비급: 아무도 알려주지 않았던 고급 전략 총정리
  /   No comments   

소프트웨어 개발의 세계에서 버전 관리 시스템 Git은 더 이상 선택 사항이 아닌, 현대 개발의 근간을 이루는 핵심 기술입니다. 수많은 개발자가 매일 Git을 사용하지만, 그저 add, commit, push, pull의 반복에만 익숙한 경우가 많습니다. 하지만 Git의 진정한 힘은 단순히 코드 버전을 저장하는 것을 넘어, 프로젝트의 과거를 탐색하고, 문제의 근원을 추적하며, 팀의 협업 흐름을 명확하게 이해하는 데 있습니다. 이 모든 활동의 중심에는 바로 git log라는 명령어가 존재합니다.

많은 개발자들이 git log를 입력했을 때 터미널을 가득 채우는 방대한 텍스트의 장벽 앞에서 좌절합니다. '내가 원하는 정보는 이게 아닌데...'라고 생각하며, 결국 GUI 툴에 의존하거나 필요한 정보를 찾는 것을 포기하기도 합니다. 이 글은 바로 그런 분들을 위한 최종 가이드입니다. 우리는 git log의 기본적인 한계를 뛰어넘어, 원하는 정보만을 정제하여 보여주는 커스텀 포맷팅 기술, 수천 개의 커밋 속에서 단 하나의 커밋을 정확히 찾아내는 정교한 필터링 전략, 그리고 이 모든 것을 나만의 단축키로 만들어 개발 생산성을 극적으로 향상시키는 Git Alias 설정 방법까지, git log를 120% 활용하는 전문가 수준의 모든 것을 A부터 Z까지 상세하게 다룰 것입니다. 이 글을 끝까지 읽고 나면, 당신은 더 이상 프로젝트의 복잡한 히스토리 앞에서 길을 잃지 않고, 오히려 히스토리를 지배하며 문제 해결 능력을 한 차원 높인 개발자로 거듭나게 될 것입니다.

1. 과거로의 첫걸음: `git log` 기본 출력 완벽 분석

모든 여정은 첫걸음부터 시작됩니다. git log의 고급 기술을 배우기 전에, 가장 기본적인 형태의 출력이 어떤 정보를 담고 있는지 명확히 이해해야 합니다. 터미널에 아무 옵션 없이 git log를 입력해 봅시다.


commit a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0 (HEAD -> main, origin/main, origin/HEAD)
Author: Jane Doe <jane.doe@example.com>
Date:   Mon Oct 26 15:30:10 2023 +0900

    feat: Add user authentication feature

    - Implement user login and registration API
    - Add JWT-based token authentication

commit f1e2d3c4b5a6f7e8d9c0a1b2c3d4e5f6a7b8c9d0
Merge: 5a4b3c2 8f9e0d1
Author: John Smith <john.smith@example.com>
Date:   Fri Oct 23 11:20:45 2023 +0900

    Merge branch 'feature/new-login' into main

이 기본 출력은 네 가지 핵심 정보로 구성되어 있습니다. 각 요소의 의미를 깊이 있게 살펴보겠습니다.

  • Commit Hash (커밋 해시): a1b2c3d4...로 시작하는 40자리의 16진수 문자열입니다. 이는 SHA-1(Secure Hash Algorithm 1) 해시값으로, 해당 커밋의 모든 정보(변경 내용, 작성자, 시간, 부모 커밋 등)를 기반으로 생성된 고유 식별자입니다. 이 해시 덕분에 Git은 데이터의 무결성을 보장하며, 단 하나의 문자라도 다른 커밋은 완전히 다른 해시값을 갖게 됩니다. 실무에서는 보통 앞 7~10자리만으로도 커밋을 충분히 구분할 수 있습니다.
  • Author & Committer (작성자와 커미터):

    대부분의 경우 Author(작성자)와 Committer(커미터)는 동일 인물입니다. Author는 실제로 코드 변경 작업을 수행한 원작자를 의미합니다. 반면, Committer는 해당 코드를 브랜치에 최종적으로 포함시킨 사람을 의미합니다. 이 둘은 언제 달라질까요? 가장 흔한 경우는 다른 사람의 패치(patch)를 적용하거나, Pull Request를 리베이스(rebase)하여 병합할 때입니다. 예를 들어, 오픈 소스 프로젝트에서 개발자 A가 보낸 코드 변경 사항을 프로젝트 관리자 B가 검토 후 메인 브랜치에 커밋하면, Author는 A, Committer는 B로 기록됩니다. 이는 코드의 원작자와 프로젝트에 변경을 가한 책임자를 명확히 구분하기 위한 중요한 기능입니다.

  • Date (날짜): 커밋이 생성된 정확한 시간을 나타냅니다. 마지막의 +0900은 타임존 오프셋으로, UTC(협정 세계시)보다 9시간 빠른 시간대(예: 한국 표준시)임을 의미합니다. 이는 전 세계에 흩어져 있는 팀원들과 협업할 때 매우 중요한 정보입니다.
  • Commit Message (커밋 메시지): 해당 커밋이 어떤 변경 사항을 담고 있는지 설명하는 글입니다. 보통 첫 줄은 50자 이내의 요약(제목)으로, 한 줄을 띄우고 그 아래에는 상세한 설명(본문)을 작성하는 것이 좋은 컨벤션으로 여겨집니다. 커밋 메시지를 명확하고 체계적으로 작성하는 습관은 git log의 활용도를 극대화하는 첫 단추입니다.

이 기본 정보는 유용하지만, 프로젝트가 성장함에 따라 금세 '정보의 벽'에 부딪히게 됩니다. 한 화면에 고작 한두 개의 커밋밖에 볼 수 없어 전체적인 맥락 파악이 어렵고, 너무 많은 정보가 나열되어 정작 필요한 핵심을 찾기 어렵습니다. 이제 이 정보의 홍수를 통제하고, 의미 있는 통찰력을 얻기 위한 여정을 시작하겠습니다.

2. 정보의 홍수에서 통찰력의 흐름으로: 필수 로그 옵션

Git은 기본 로그의 장황함을 해결하고, 특정 관점에 집중할 수 있도록 다양한 옵션을 제공합니다. 복잡한 커스터마이징에 앞서, 모든 개발자가 반드시 알아야 할 가장 유용하고 기본적인 옵션부터 익혀보겠습니다.

--oneline: 히스토리를 한눈에 조망하는 가장 빠른 방법

가장 사랑받는 옵션 중 하나입니다. 각 커밋을 축약된 해시값과 커밋 메시지 제목만으로 구성된 한 줄로 요약해줍니다. 프로젝트의 전체적인 작업 흐름과 변화의 맥락을 빠르게 파악하는 데 이보다 더 좋은 옵션은 없습니다.


git log --oneline


a1b2c3d (HEAD -> main) feat: Add user authentication feature
f1e2d3c fix: Correct calculation error in payment module
5a4b3c2 docs: Update API documentation for login
8f9e0d1 feat: Add social login button
7c6b5a4 refactor: Refactor login form component
...

--graph: 브랜치의 얽힌 역사를 시각적으로 풀다

여러 브랜치를 넘나들며 작업하고 병합(merge)하는 것이 일상인 현대 개발 환경에서 --graph 옵션은 필수입니다. 이 옵션은 커밋 히스토리를 아스키(ASCII) 문자로 그려진 그래프와 함께 보여줌으로써, 브랜치가 언제, 어디서 분기(fork)되고 다시 합쳐졌는지 직관적으로 이해하게 해줍니다. --oneline 옵션과 함께 사용하면 그 위력이 배가됩니다.


git log --graph --oneline --decorate


*   a1b2c3d (HEAD -> main, origin/main) Merge branch 'feature/new-login'
|\
| * 8f9e0d1 (feature/new-login) feat: Add social login
| * 7c6b5a4 feat: Refactor login form
* | 5a4b3c2 fix: Update documentation for payment API
|/
* f1e2d3c fix: Correct calculation error
...

위 예시에서 *는 커밋을, |, /, \는 브랜치의 분기와 병합을 나타냅니다. --decorate 옵션은 (HEAD -> main)과 같이 브랜치나 태그의 이름을 함께 표시해주어 현재 상태를 파악하는 데 도움을 줍니다 (최신 Git 버전에서는 --oneline에 포함되는 경우가 많습니다).

--stat: 어떤 파일이 얼마나 바뀌었는가?

각 커밋이 어떤 파일을 수정했고, 대략 얼마나 많은 라인이 변경되었는지 요약 정보를 보고 싶을 때 --stat(statistics) 옵션을 사용합니다. 특정 기능 구현이나 버그 수정이 어떤 파일들에 영향을 미쳤는지 빠르게 확인할 수 있습니다.


git log --stat -1


commit a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0
Author: Jane Doe <jane.doe@example.com>
Date:   Mon Oct 26 15:30:10 2023 +0900

    feat: Add user authentication feature

 src/controllers/authController.js | 55 ++++++++++++++++++++++++++++++
 src/routes/authRoutes.js          | 12 +++++++
 src/models/User.js                | 24 +++++++++++++
 3 files changed, 91 insertions(+)

+++는 추가된 라인의 수를, ---는 삭제된 라인의 수를 시각적으로 나타냅니다.

-p 또는 --patch: 코드 변경 내용(Diff)을 직접 확인하다

--stat이 요약 정보라면, -p는 실제 코드의 변경 내용(diff) 자체를 보여줍니다. 어떤 코드가 추가되고(+), 어떤 코드가 삭제되었는지(-) 라인 단위로 상세하게 확인할 수 있어, 버그의 원인을 찾거나 동료의 코드를 리뷰할 때 결정적인 역할을 합니다.


git log -p -1


commit f1e2d3c4b5a6f7e8d9c0a1b2c3d4e5f6a7b8c9d0
Author: John Smith <john.smith@example.com>
Date:   Fri Oct 23 11:20:45 2023 +0900

    fix: Correct calculation error in payment module

diff --git a/src/services/payment.js b/src/services/payment.js
index 1a2b3c4..5d6e7f8 100644
--- a/src/services/payment.js
+++ b/src/services/payment.js
@@ -105,7 +105,7 @@
 function calculateTotal(price, quantity, taxRate) {
   const subtotal = price * quantity;
-  const tax = subtotal * taxRate; // Bug: Incorrect tax calculation
-  return subtotal + tax;
+  const tax = subtotal * (taxRate / 100); // Fix: Apply correct tax rate
+  return subtotal + tax;
 }

위와 같이 -p 옵션은 변경 전(---)과 변경 후(+++)의 코드를 명확하게 보여주어, 커밋의 의도를 정확히 파악하게 해줍니다.

3. 나만의 로그 포맷 창조하기: `--pretty=format` 완전 정복

기본 제공 옵션들만으로도 매우 강력하지만, 진정한 `git log` 전문가는 여기서 멈추지 않습니다. --pretty=format:"<포맷_문자열>" 옵션은 로그 출력을 완전히 내 마음대로 디자인할 수 있게 해주는 궁극의 커스터마이징 도구입니다. Git이 제공하는 다양한 '플레이스홀더(placeholder)'를 조합하여, 내가 원하는 정보만을, 원하는 순서와 형식으로 출력할 수 있습니다.

핵심 포맷 플레이스홀더 상세 가이드

다음은 --pretty=format에서 가장 자주 사용되는 플레이스홀더와 그 의미입니다.

플레이스홀더 설명 사용 예시
%H 전체 커밋 해시 (40자리) 디테일한 참조나 스크립팅에 사용
%h 축약된 커밋 해시 (기본 7자리) 일반적인 로그 확인 시 가장 유용
%T / %t 전체 / 축약된 트리 해시 커밋이 가리키는 파일 구조의 스냅샷 ID
%P / %p 전체 / 축약된 부모 커밋 해시 병합(Merge) 커밋의 경우 여러 개가 표시됨. 히스토리 추적에 중요
%an / %ae 작성자(Author) 이름 / 이메일 코드의 원작자 추적
%ad / %ar 작성일 (날짜) / (상대적 시간) %ad는 --date 옵션에 따라 형식이 바뀜. %ar은 "2주 전"과 같이 표시
%cn / %ce 커미터(Committer) 이름 / 이메일 코드의 최종 반영자 추적
%cd / %cr 커밋일 (날짜) / (상대적 시간) %cr은 "3 hours ago"와 같이 표시. 가장 흔하게 사용됨
%s 커밋 메시지 제목 (첫 줄) 로그의 핵심 내용 요약
%f 커밋 메시지 제목 (공백을 -로 변환) 파일명 등으로 사용할 때 유용
%b 커밋 메시지 본문 상세 설명 확인 시 필요
%d 브랜치, 태그 등 모든 참조 이름 (HEAD -> main, tag: v1.0, origin/main) 와 같이 표시됨
%D %d와 비슷하지만 HEAD 제외 조금 더 깔끔한 참조 이름이 필요할 때 사용
%n 줄바꿈(Newline) 문자 포맷 내에서 여러 줄로 출력 구성 시 필수
%C(<color>) 이어지는 텍스트 색상 지정 %C(red), %C(green), %C(reset) 등으로 가독성 향상
%C(auto) 터미널이 색상을 지원할 때만 색상 적용 스크립트나 파이프에서 색상 코드가 깨지는 것을 방지

실무에서 바로 쓰는 실용적인 포맷팅 레시피

이론을 알았으니, 이제 실제 현업에서 생산성을 극대화할 수 있는 강력한 포맷팅 예제들을 살펴보겠습니다.

레시피 1: "그래프 마스터" - 가장 대중적이고 강력한 조합

많은 개발자들이 자신만의 Alias로 만들어 사용하는, 가장 정보량이 풍부하고 가독성이 높은 포맷입니다. 그래프, 축약 해시, 참조 이름, 커밋 제목, 상대적 시간, 작성자 정보를 컬러풀하게 조합합니다.


git log --graph --pretty=format:'%C(yellow)%h%C(reset) - %C(cyan)%d%C(reset) %s %C(green)(%cr) %C(bold blue)<%an>%C(reset)' --abbrev-commit

이 명령어를 실행하면 다음과 같은 아름다운 로그를 볼 수 있습니다.


*   a1b2c3d - (HEAD -> main, origin/main) Merge branch 'feature/new-login' (2 days ago) <Jane Doe>
|\
| * 8f9e0d1 - (feature/new-login) feat: Add social login (3 days ago) <John Smith>
| * 7c6b5a4 -  feat: Refactor login form (4 days ago) <John Smith>
* | 5a4b3c2 -  fix: Update documentation for payment API (5 days ago) <Jane Doe>
|/
* f1e2d3c -  fix: Correct calculation error (6 days ago) <Jane Doe>

이 포맷은 각 정보가 색상으로 명확히 구분되어 한눈에 프로젝트의 구조와 최근 변경 사항을 파악하는 데 최적화되어 있습니다.

레시피 2: "팀 리뷰어" - 변경된 파일 목록을 함께 보기

특정 커밋이 어떤 파일들을 건드렸는지 함께 보고 싶을 때 유용한 포맷입니다. --name-status 옵션을 함께 사용합니다.


git log --pretty=format:'%C(yellow)%h %C(reset)%s %C(green)(%cr) %C(bold blue)<%an>%C(reset)' --name-status -3


a1b2c3d feat: Add user authentication feature (2 days ago) <Jane Doe>
A       src/controllers/authController.js
A       src/models/User.js
M       src/routes/index.js

f1e2d3c fix: Correct calculation error in payment module (6 days ago) <Jane Doe>
M       src/services/payment.js

...

A(Added), M(Modified), D(Deleted) 등의 상태와 함께 파일 경로가 표시되어 코드 리뷰나 변경 사항 추적에 매우 효과적입니다.

4. 수천 개의 커밋에서 원하는 정보만 쏙쏙: 정교한 로그 필터링 전략

아무리 로그를 아름답게 포맷팅해도, 수년 동안 수만 개의 커밋이 쌓인 거대 프로젝트에서는 원하는 정보를 찾는 것이 '건초더미에서 바늘 찾기'와 같습니다. Git은 이런 상황을 위해 특정 조건에 맞는 커밋만을 걸러내는 강력한 필터링 메커니즘을 제공합니다.

시간과 양으로 필터링

  • -<n>: 가장 최근 n개의 커밋만 표시합니다. (예: git log -5)
  • --since / --after: 특정 날짜/시간 이후의 커밋만 표시합니다. (예: git log --since="2 weeks ago")
  • --until / --before: 특정 날짜/시간 이전의 커밋만 표시합니다. (예: git log --until="2023-10-01")
  • 조합 사용: git log --since="2023-10-01" --until="2023-10-31" (10월 한 달간의 커밋)

작성자와 커밋 메시지로 필터링

  • --author="<pattern>": 작성자 이름이나 이메일에 특정 패턴이 포함된 커밋을 검색합니다. (예: git log --author="Jane")
  • --committer="<pattern>": 커미터로 검색합니다.
  • --grep="<pattern>": 커밋 메시지(제목+본문)에 특정 패턴이 포함된 커밋을 검색합니다. (예: git log --grep="login")
  • -i (ignore-case): --grep이나 --author와 함께 사용하여 대소문자를 무시하고 검색합니다.
  • --all-match: 여러 개의 --grep 또는 --author 조건을 AND로 묶어 모두 만족하는 커밋만 찾습니다. (기본은 OR)

파일과 코드 내용으로 필터링: 궁극의 추적 기술

이것이 `git log` 필터링의 진정한 힘입니다. 단순히 메타데이터가 아닌, 실제 코드의 변경 내용을 기반으로 커밋을 찾아냅니다.

  • -- <path>: 특정 파일이나 디렉토리의 변경 이력만 추적합니다. -- 뒤에 경로를 명시해야 합니다. (예: git log -- src/components/Button.js)
  • -S"<string>" (Pickaxe): 코드에서 특정 문자열의 추가 또는 삭제가 발생한 커밋을 찾아냅니다. 즉, 해당 문자열의 등장 횟수에 변화를 준 커밋을 검색합니다. 예를 들어, 특정 함수명이나 변수명이 언제 처음 도입되었거나 사라졌는지 찾을 때 매우 유용합니다. (예: git log -S"apiKey")
  • -G"<regex>": -S와 비슷하지만, 일반 문자열 대신 정규 표현식(regex)으로 검색합니다. 더 복잡한 패턴의 코드 변경을 추적할 수 있습니다.

💡 `--grep` vs `-S` vs `-G`: 무엇을 언제 사용해야 할까?

  • `--grep`: "무엇을 했는지(What)"가 궁금할 때. 커밋 메시지를 검색하여 특정 기능(`feat`), 버그 수정(`fix`) 관련 커밋을 찾습니다.
  • `-S`, `-G`: "어떻게, 어디가 바뀌었는지(How, Where)"가 궁금할 때. 실제 코드(diff)를 검색하여 특정 코드 라인이 변경된 커밋을 직접 찾아냅니다. 버그의 원인이 되는 코드가 언제, 누구에 의해 도입되었는지 추적하는 데 최고의 무기입니다.

커밋 범위로 필터링: 브랜치 비교의 핵심

  • branch1..branch2: `branch1`에는 없고 `branch2`에만 있는 모든 커밋을 보여줍니다. Pull Request를 생성하기 전에 내가 작업한 내역만 리뷰하는 데 가장 흔하게 사용됩니다. (예: git log main..feature/my-new-feature)
  • branch1...branch2 (세 개의 점): `branch1` 또는 `branch2` 중 한쪽에만 있는 모든 커밋(대칭 차이)을 보여줍니다. 두 브랜치가 서로 갈라진 후 각자 어떤 작업을 했는지 비교할 때 유용합니다.

필터링 종합 예제: "지난 2주 동안 `src/api` 디렉토리에서 `legacy`라는 단어가 포함된 코드를 변경했으며, 커밋 메시지에 'refactor'가 들어간 John의 커밋들을 그래프로 보여줘."


git log --graph --oneline --since="2 weeks ago" --author="John" --grep="refactor" -S"legacy" -- src/api/

이처럼 여러 필터를 조합하면 상상할 수 있는 거의 모든 조건의 커밋을 정확히 찾아낼 수 있습니다.

5. 전문가처럼 Git 사용하기: `Alias`로 나만의 초단축 명령어 만들기

지금까지 배운 강력하고 화려한 git log 명령어들은 매우 유용하지만, 매번 타이핑하기에는 너무 깁니다. Git의 `Alias`(별칭) 기능은 이 긴 명령어들을 나만의 짧은 명령어로 저장하여, 생산성을 비약적으로 향상시켜 줍니다.

예를 들어, 위에서 소개한 "그래프 마스터" 포맷을 git lg라는 명령어로 만들어 보겠습니다. 터미널에 다음 명령어를 입력하면 됩니다.


git config --global alias.lg "log --graph --pretty=format:'%C(yellow)%h%C(reset) - %C(cyan)%d%C(reset) %s %C(green)(%cr) %C(bold blue)<%an>%C(reset)' --abbrev-commit"

--global 옵션은 이 설정을 현재 컴퓨터의 모든 Git 저장소에 적용하라는 의미입니다. 이제 어떤 프로젝트 폴더에서든 git lg만 입력하면, 우리가 정의한 아름다운 로그가 즉시 출력됩니다. 인생이 편해지는 순간입니다.

나만의 Alias 스타터 팩

직접 ~/.gitconfig 파일을 열어 다음과 같이 더 많은 Alias를 추가할 수 있습니다. 아래는 현업 개발자들이 자주 사용하는 Alias 예시입니다.


[alias]
    # 기본 상태 확인
    st = status -s
    co = checkout
    br = branch

    # 로그 관련
    lg = log --graph --pretty=format:'%C(yellow)%h%C(reset) - %C(cyan)%d%C(reset) %s %C(green)(%cr) %C(bold blue)<%an>%C(reset)' --abbrev-commit
    hist = log --pretty=format:'%h %ad | %s%d [%an]' --graph --date=short
    ll = log --stat --abbrev-commit
    
    # 특정 파일의 변경 이력 추적
    filelog = log -u
    
    # 아직 push하지 않은 로컬 커밋 확인
    unpushed = log origin/main..HEAD

    # 마지막 커밋 수정 (메시지만)
    amend = commit --amend --no-edit

6. 로그를 넘어서: 히스토리 탐색을 위한 연관 고급 명령어

git log와 함께 사용하면 시너지를 내는 강력한 명령어들이 있습니다. 이들을 통해 히스토리 탐색 능력을 완성할 수 있습니다.

  • git shortlog: 로그를 작성자별로 그룹화하여 요약해줍니다. -s(summary) 옵션으로 커밋 수만 보거나, -n(numeric) 옵션으로 커밋 수에 따라 정렬할 수 있습니다. 프로젝트 기여도를 한눈에 파악하기 좋습니다.
  • git reflog: Git의 안전망. git log가 브랜치에 연결된 커밋의 역사라면, reflog는 HEAD와 브랜치 포인터가 이동한 모든 기록을 저장합니다. 실수로 reset이나 rebase로 커밋을 날렸을 때, reflog를 통해 '사라진' 커밋의 해시를 찾아 복구할 수 있습니다.
  • git blame <file>: "이 코드는 대체 누가 짠 거야?"라는 질문에 대한 답. 파일의 각 라인이 마지막으로 어떤 커밋에 의해, 누구에 의해 수정되었는지 보여줍니다. 특정 코드 라인의 컨텍스트를 이해하고 담당자에게 질문할 때 매우 유용합니다.
  • git bisect: 궁극의 버그 추적 도구. 수백 개의 커밋 사이에서 버그가 발생했다면, git bisect는 이진 탐색(binary search)을 통해 자동으로 커밋 히스토리를 절반씩 나눠가며 어떤 커밋이 버그를 최초로 유발했는지 찾아줍니다. git bisect start, git bisect good <commit>, git bisect bad <commit> 명령어로 버그를 품은 커밋을 빠르고 정확하게 찾아낼 수 있습니다.

결론: 히스토리를 지배하는 자가 프로젝트를 지배한다

git log는 단순히 과거를 기록하고 보여주는 수동적인 도구가 아닙니다. 어떻게 활용하느냐에 따라, 그것은 프로젝트의 맥박을 느끼게 하는 대시보드가 되고, 미스터리한 버그의 실마리를 푸는 탐정의 돋보기가 되며, 팀의 협업 품질을 높이는 소통의 창구가 됩니다.

이 글에서 다룬 다양한 옵션과 포맷팅, 필터링 기술, 그리고 Alias를 통한 자동화까지, 하나씩 당신의 개발 워크플로우에 녹여내 보십시오. 처음에는 조금 어색할지 몰라도, 곧 터미널에서 git lg를 치는 것이 당연해지고, 복잡한 필터링 조건을 조합하여 문제의 원인을 순식간에 찾아내는 자신의 모습에 놀라게 될 것입니다. 프로젝트의 역사를 손바닥 위에 올려놓고 보듯 명확하게 이해하는 능력, 그것이 바로 당신을 평범한 개발자에서 뛰어난 문제 해결사로 만들어 줄 핵심 역량입니다.


0 개의 댓글:

Post a Comment