코드는 컴퓨터가 실행하지만 읽는 것은 사람입니다. 동료 개발자가 내 코드를 읽고 이해하고 수정하는 시간이 작성하는 시간보다 10배 이상 깁니다. 코딩 괴물은 타고나는 것이 아니라 만들어지는 것입니다. 연봉 앞자리를 바꾸는 사소하지만 강력한 습관 7가지를 공개합니다. 성장이 정체된 것 같아 불안한 주니어 개발자, 좋은 평가를 받고 싶은 취준생이라면 반드시 알아야 할 내용입니다. 시니어 개발자와 주니어 개발자의 차이는 단순히 시간이 가져오는 것이 아닙니다. 자신이 하는 일에서 얼마나 깊이 있는 성장을 이루고 그 과정을 통해 자신의 역량을 어떻게 확장하는지가 중요합니다. 이 글에서는 코딩 실력보다 중요한 습관, 변수명 짓기와 커밋 메시지와 문서화 같은 기본기, 코드 리뷰를 두려워하지 않는 협업 태도, 기술 부채 관리와 비즈니스 가치 이해 마인드셋, 시니어가 되기 위해 오늘부터 바꿔야 할 한 가지까지 개발자 커리어 코치가 알려드립니다.
윈도우 AI 에이전트 시대가 온다 NPU 탑재 AI PC가 필요한 이유와 온디바이스 AI 완벽정리 https://techbridgep.blogspot.com/2025/11/ai-npu-ai-pc-ai.html 연금저축 vs IRP 차이점 완벽정리 연금저축보험 펀드 이전 방법과 세액공제 극대화 전략 https://techbridgep.blogspot.com/2025/11/vs-irp.html
코딩 실력보다 중요한 것은 습관이다
습관이 실력을 만듭니다. 하루에 10분씩 변수명을 고민하는 습관이 1년이면 60시간이 됩니다. 60시간 동안 의미 있는 네이밍을 연습하면 코드 가독성이 몇 배 향상됩니다. 반대로 변수명을 a, b, c로 짓는 습관이 1년 쌓이면 동료가 내 코드를 이해하는 데 600시간을 낭비하게 만듭니다. 좋은 습관은 복리로 쌓이고 나쁜 습관도 복리로 쌓입니다. 주니어 개발자가 시니어로 성장하려면 기술 스택을 늘리는 것보다 좋은 습관을 들이는 것이 먼저입니다.
시니어 개발자는 그동안의 경험을 통해 문제 해결 능력은 물론 팀과의 원활한 소통 능력 그리고 효율적인 코드 작성 방법에 있어 노하우를 가지고 있습니다. 하지만 주니어 개발자가 이러한 시니어 개발자의 경험과 노하우를 자신의 것으로 만드는 것은 쉽지 않습니다. 시니어가 되는 지름길은 시니어의 습관을 따라하는 것입니다. 시니어는 코드를 짜기 전에 설계를 하고 코드를 짠 후에는 리팩토링을 하며 커밋하기 전에 코드를 다시 읽습니다. 이런 사소한 습관들이 모여 시니어를 만듭니다.
기술 부채는 나쁜 습관이 쌓여 만들어집니다. 오늘 10분 아끼려고 복사 붙여넣기 하면 3개월 뒤 버그를 찾는 데 3시간이 걸립니다. 오늘 변수명 짓기 귀찮다고 temp로 하면 6개월 뒤 그 코드를 이해하는 데 30분이 걸립니다. 오늘 주석 달기 귀찮다고 넘어가면 1년 뒤 그 로직을 수정하는 데 하루가 걸립니다. 기술 부채의 이자는 복리로 불어나 결국 프로젝트를 망칩니다. 좋은 습관은 기술 부채를 예방하는 최고의 방법입니다.
성장하는 개발자는 매일 조금씩 나아집니다. 어제보다 오늘 조금 더 나은 코드를 짜고 어제보다 오늘 조금 더 명확한 변수명을 짓고 어제보다 오늘 조금 더 자세한 커밋 메시지를 씁니다. 보이스카우트 규칙을 기억하세요. 코드를 체크아웃할 때보다 체크인할 때 조금 더 깨끗하게 만들면 됩니다. 매일 1%씩 성장하면 1년 뒤에는 37배 성장합니다. 습관이 쌓이면 실력이 되고 실력이 쌓이면 연봉이 됩니다.
| 구분 | 주니어 개발자 | 시니어 개발자 |
|---|---|---|
| 코딩 전 | 바로 코딩 시작 | 설계와 계획 먼저 |
| 변수명 | a b temp data | user_age total_price is_valid |
| 커밋 메시지 | 수정 완료 | feat: 사용자 인증 로직 추가 |
| 코드 리뷰 | 지적받기 두려움 | 공짜로 배우는 기회 |
| 리팩토링 | 나중에 하면 돼 | 지금 바로 정리 |
| 기술 부채 | 인식 못함 | 적극적으로 관리 |
변수명 짓기 커밋 메시지 문서화로 다지는 기본기
변수명 고민 없이 a, b로 짓는 습관이 동료의 시간을 얼마나 뺏는지 아시나요. 변수명 하나 때문에 동료가 10분을 낭비하고 그게 하루에 10번 반복되면 100분입니다. 한 달이면 2,000분, 1년이면 24,000분입니다. 400시간입니다. 변수명을 의미 있게 짓는 습관만으로 동료의 400시간을 절약할 수 있습니다. 의도가 드러나는 네이밍 습관은 팀 전체의 생산성을 높입니다. 변수명은 주석 없이도 무엇을 담고 있는지 알 수 있어야 합니다.
좋은 변수명 짓는 습관을 들이세요. 첫째, 해당 언어에 맞는 변수명 규칙을 먼저 숙지하세요. 파이썬은 스네이크 케이스, 자바는 카멜 케이스를 사용합니다. 둘째, 이름에 의미를 넣으세요. 변수명이 길어지더라도 다른 사람이 이름만으로 바로 이해할 수 있게 쉽고 명료한 단어로 네이밍하세요. 셋째, 함수 이름에 함수가 하는 일을 정확히 드러내세요. 함수는 한 가지 일만 수행해야 하며 함수의 역할을 이름에 정확히 표현해야 합니다. 넷째, 불린 변수는 is나 has로 시작하면 가독성이 높아집니다.
커밋 메시지는 미래의 나를 위한 메모입니다. 수정 완료, 버그 수정, 코드 변경 같은 커밋 메시지는 6개월 뒤 무슨 수정을 했는지 알 수 없습니다. 좋은 커밋 메시지는 무엇을 왜 바꿨는지 명확히 알려줍니다. feat: 사용자 인증 로직 추가, fix: 로그인 시 세션 만료 버그 수정, refactor: 결제 모듈 단일 책임 원칙 적용처럼 타입과 내용을 명확히 쓰세요. 커밋 메시지를 제목과 본문으로 구성하면 더 좋습니다. 제목은 50자 이내로 요약하고 본문에는 왜 이렇게 수정했는지 설명하세요.
커밋 메시지 규칙을 정하세요. 팀마다 다르지만 일반적으로 feat(새 기능), fix(버그 수정), refactor(리팩토링), docs(문서), test(테스트), style(코드 포맷) 같은 타입을 사용합니다. 커밋 메시지는 명령형으로 쓰세요. Fix bug로 적어야지 Fixed bug나 Fixes bug가 아닙니다. 이는 git merge나 git revert 같은 명령어에 의해 생성된 커밋 메시지와 일치하게 됩니다. 자기 전에 커밋 한 번 더 확인하는 습관을 들이세요.
문서화는 미래의 팀원을 위한 배려입니다. 주석 없이 코드를 짜는 습관은 동료에게 해독 작업을 떠넘기는 것입니다. 하지만 주석을 무조건 많이 달면 안 됩니다. What을 설명하는 주석은 나쁜 주석입니다. 코드만 봐도 무엇을 하는지 알 수 있어야 합니다. Why를 설명하는 주석은 좋은 주석입니다. 왜 이렇게 구현했는지, 왜 이 알고리즘을 선택했는지, 왜 이 예외 처리가 필요한지를 설명하세요. README 파일도 성심성의껏 작성하세요. 프로젝트 설명, 설치 방법, 사용 예시, API 문서를 포함하세요.
| 습관 | 나쁜 예 | 좋은 예 |
|---|---|---|
| 변수명 | a b temp | user_age total_price is_valid |
| 함수명 | calc do | calculate_total validate_user |
| 커밋 메시지 | 수정 완료 | feat: 사용자 인증 로직 추가 |
| 주석 | 나이 증가 | 생일 지나면 자동으로 나이 업데이트 |
코드 리뷰를 두려워하지 않는 협업 태도와 남의 코드 읽기
코드 리뷰는 지적받는 시간이 아니라 공짜로 배우는 시간입니다. 시니어가 내 코드를 리뷰해주면 시니어의 지식을 무료로 배울 수 있습니다. 코드 리뷰를 두려워하는 주니어는 성장이 느리고 코드 리뷰를 환영하는 주니어는 성장이 빠릅니다. 코드 리뷰는 내가 작성한 코드를 다른 사람에게 검사받는 시간이 아니라 최선의 코드를 작성하기 위한 공동의 노력입니다. 코드 리뷰를 통해서 다른 개발자들의 시각을 배우고 더 나은 코드를 작성하는 방법을 익힙니다.
코드 리뷰 요청에 정성을 담으세요. 코드 리뷰를 요청한 사람이 본문에 내용을 잘 담아주면 코드 리뷰어가 방향성을 잡고 리뷰를 해주기 참 좋습니다. 무엇을 구현했는지, 왜 이렇게 구현했는지, 어떤 부분을 특히 봐주면 좋을지 설명하세요. 코드 리뷰는 즉시 시작하세요. 코드 리뷰를 높은 우선순위로 두면 저자는 리뷰가 종료될 때까지 대기하지 않아도 됩니다. 리뷰를 바로 시작하면 선순환이 됩니다. 코드를 읽고 피드백을 줄 때는 시간을 가지고 진행해도 되지만 시작은 바로 하세요.
코드 리뷰 피드백을 긍정적으로 받아들이세요. 피드백은 공격이 아니라 선물입니다. 여기 이상한데요가 아니라 이 부분을 이렇게 바꾸면 더 좋을 것 같아요로 받아들이세요. 고수준의 피드백이 처리된 후에 저수준 이슈를 처리하세요. 선택적인 설계 개선, 변수명 변경, 주석을 명확하게 하는 것 등은 나중에 해도 됩니다. 예제 코드 제공에 관대하세요. 저자를 기분 좋게 하기 위한 방법입니다.
남의 코드 읽는 습관을 들이세요. 코드를 보는 안목을 기르려면 좋은 코드를 많이 봐야 합니다. 기존에 있던 잘 돌아가는 코드, 선배들의 코드가 답이 아닙니다. 기존 코드를 마냥 우수하다고 생각하면 안 됩니다. 기존 코드에는 다양한 요구사항, 수많은 히스토리, 빡빡한 일정, 비즈니스 예외사항 등이 숨겨져 있습니다. 안목이 없으면 현실적인 코드(매우 많은 if-else 등)에 익숙해지게 됩니다. 불편함을 느낄 수 있는 안목을 길러야 합니다.
평소에 쓰는 오픈소스 코드를 열어 보세요. Spring, Kafka 같은 유명한 오픈소스 코드를 통째로 받아서 공부하세요. 소스코드 가독성, 리팩토링, 디자인 패턴을 다루는 책을 다양하게 읽어보세요. 평소에 코딩 70%, 리팩토링 30% 시간을 쓰세요. 취미로 시간 날 때마다 예전에 본인이 짠 다른 사람이 짠 소스코드를 리팩토링하세요. 남의 코드를 읽는 습관이 쌓이면 좋은 코드와 나쁜 코드를 구분하는 안목이 생깁니다.
| 협업 습관 | 주니어 태도 | 시니어 태도 |
|---|---|---|
| 코드 리뷰 | 지적받기 두려움 | 공짜로 배우는 기회 |
| 피드백 | 방어적 태도 | 감사하며 수용 |
| 질문 | 모르는 것 숨김 | 적극적으로 질문 |
| 지식 공유 | 혼자만 알고 있음 | 문서화하여 공유 |
기술 부채 관리와 비즈니스 가치 이해하는 마인드셋
기술 부채는 소프트웨어 개발 프로젝트에서 매우 중요한 문제이며 기술 부채가 높아질수록 프로젝트 진행에 대한 위험이 높아질 수 있습니다. 높은 기술 부채는 미래에 프로젝트를 더욱 복잡하게 만들어서 수정과 유지 보수 비용이 늘어날 수 있으며 회사와 고객에게 추가적인 비용과 불편함을 초래할 수 있습니다. 또한 품질이 낮아질 가능성이 높아져서 불편한 사용자 경험과 기능 오류를 초래할 수 있습니다. 기술 부채를 적절하게 관리하고 최소화하는 것이 매우 중요합니다.
기술 부채를 발생시키는 원인을 파악하고 관리할 수 있는 프로세스를 도입하여 최소화하세요. 기술 부채를 쌓이지 않도록 예방하고 발생했을 때는 빠르게 대처하여 안정적인 소프트웨어 개발을 진행할 수 있도록 노력해야 합니다. 개발 시간의 20~30%를 기술 부채 관리에 할당하세요. 이 부채 상환 계획은 혁신을 저해하지 않으면서 코드 건강을 유지합니다. 프로젝트 성숙도에 따라 조정하세요. 새 프로젝트는 덜 필요할 수 있고 레거시 시스템은 더 필요할 수 있습니다.
정기적인 부채 스프린트를 운영하세요. 한 달에 한 번 기술 부채만 해결하는 스프린트를 진행하면 누적된 문제를 체계적으로 해결하는 데 도움이 됩니다. 기술 부채를 이슈 트래커에 등록하고 우선순위를 정하세요. 치명적인 버그는 즉시 수정하고 성능 문제는 다음 스프린트에 수정하며 개선 사항은 여유 있을 때 수정하세요. 기술 부채를 방치하면 복리로 불어나 결국 프로젝트를 재작성해야 하는 상황까지 갑니다.
비즈니스 가치를 고려하여 기술 부채를 관리하세요. 단순히 기술적으로 우아한 코드가 아니라 비즈니스 가치(일정, 비용)를 고려하여 기술 부채를 관리하는 것이 진짜 시니어의 역량입니다. 완벽한 코드를 짜려다 일정을 놓치면 비즈니스에 손해가 됩니다. 반대로 일정만 맞추려다 기술 부채를 쌓으면 나중에 더 큰 비용이 듭니다. 균형을 맞추는 것이 중요합니다. 중요한 기능은 완벽하게 짜고 덜 중요한 기능은 빠르게 짜세요.
비즈니스 도메인을 이해하세요. 코드만 잘 짜는 개발자는 주니어이고 비즈니스를 이해하는 개발자가 시니어입니다. 내가 만드는 기능이 회사의 매출에 어떻게 기여하는지, 사용자에게 어떤 가치를 주는지 이해하세요. 기획자, 디자이너, 마케터와 소통하며 비즈니스 관점을 배우세요. 기술적으로 완벽하지만 사용자가 원하지 않는 기능은 의미가 없습니다. 사용자가 원하는 기능을 빠르게 만드는 것이 더 중요합니다.
| 마인드셋 | 주니어 사고 | 시니어 사고 |
|---|---|---|
| 기술 부채 | 인식 못하거나 방치 | 적극적으로 관리 |
| 완벽함 | 완벽한 코드 집착 | 적절한 타협점 찾기 |
| 비즈니스 | 코드만 관심 | 비즈니스 가치 이해 |
| 일정 | 무조건 지켜야 함 | 협상 가능한 것으로 인식 |
업무일지 작성 지식 정리 최신 트렌드 학습 습관
업무일지를 무조건 기록으로 남기세요. 오늘 무슨 일을 했는지, 어떤 문제를 해결했는지, 무엇을 배웠는지 기록하세요. 업무일지를 쓰면 성과 정리가 쉬워지고 연말 평가 때 유용합니다. 또한 같은 문제를 다시 만났을 때 빠르게 해결할 수 있습니다. 시퀀스 다이어그램을 미리 그리는 습관 덕분에 실 개발에 들어가기 전 논리적 오류를 빠르게 발견할 수 있고 시각적인 자료가 준비되어 있으니 타팀과 협업할 때도 명확하게 정리할 수 있어 커뮤니케이션이 원활합니다.
한 주의 기록일지를 복기하고 체계화하세요. 금요일 오후에 이번 주 업무일지를 정리하며 무엇을 배웠고 무엇을 개선할지 생각하세요. 복기하는 습관이 쌓이면 성장 속도가 빨라집니다. 매주 조금씩 개선하면 1년 뒤 완전히 다른 개발자가 됩니다. 블로그나 노션에 정리하면 나중에 포트폴리오로 활용할 수도 있습니다. 면접 때 내가 어떤 문제를 해결했고 어떤 성장을 했는지 구체적으로 말할 수 있습니다.
새로 알게 된 내용을 정리하세요. 사내 교육 시스템에서 배운 선임이 알려준 내용을 찾아보기 쉽게 정리해야 합니다. 메모장을 활용해도 되지만 어디서든 볼 수 있도록 OneNote나 EverNote 같은 앱을 활용하세요. 구글링해서 찾은 해결책도 정리하세요. 같은 문제를 다시 만났을 때 구글링하지 않고 내 노트를 보면 됩니다. 시간이 절약되고 지식이 체계화됩니다. 남에게 설명할 수 있을 정도로 이해했다면 진짜 내 것이 된 겁니다.
개발 서적을 가까이 하세요. 책보다 구글링이죠. 대부분이 이렇게 생각하고 그렇게 하고 있을 겁니다. 맞습니다. 빠르게 알아보고 샘플 코드 복붙하고 하면 금방 막힌 부분이 처리되죠. 하지만 책은 체계적인 지식을 제공합니다. 구글링은 단편적인 해결책만 주지만 책은 원리와 배경까지 알려줍니다. 클린 코드, 리팩토링, 디자인 패턴, 도메인 주도 설계 같은 고전을 읽으세요. 책 한 권이 시니어의 10년 경험을 압축해 담고 있습니다.
최신 트렌드를 학습하세요. 무엇을 모르는지 알기 위해 얇은 책이나 오버뷰를 읽으세요. 이 기술이 왜 필요한지 기존 기술보다 왜 좋은지 학습하세요. 튜토리얼 코드를 짜보면서 경험의 크기를 늘리세요. 경험이 쌓이면 책 보고 이론 쌓으며 경험을 다듬으세요. 하지만 최신 트렌드에 너무 집착하지 마세요. 기본기가 탄탄하면 새로운 기술도 빠르게 습득할 수 있습니다. 기본기 80%, 최신 트렌드 20% 비율로 학습하세요.
| 학습 습관 | 효과 |
|---|---|
| 업무일지 작성 | 성장 추적 성과 정리 용이 |
| 주간 복기 | 개선점 파악 빠른 성장 |
| 지식 정리 | 체계적 지식 구축 |
| 독서 | 원리 이해 깊이 있는 학습 |
| 트렌드 학습 | 최신 기술 습득 |
시니어가 되기 위해 오늘부터 바꿔야 할 한 가지
하루에 한 가지씩 바꾸세요. 일곱 가지 습관을 한 번에 바꾸려고 하면 실패합니다. 오늘은 변수명 짓기에 신경 쓰고 내일은 커밋 메시지 잘 쓰고 모레는 코드 리뷰 적극적으로 하세요. 하루에 한 가지씩 바꾸면 일주일이면 일곱 가지 습관이 됩니다. 한 달이면 자연스러워지고 3개월이면 완전히 내 것이 됩니다. 습관을 바꾸는 것은 어렵지만 하루에 한 가지씩 바꾸면 쉽습니다. 작은 성공이 쌓여 큰 성공이 됩니다.
가장 쉬운 것부터 시작하세요. 변수명 짓기가 어렵다면 커밋 메시지부터 시작하세요. 커밋 메시지도 어렵다면 주석부터 시작하세요. 가장 쉬운 것부터 시작해서 성공 경험을 쌓으세요. 성공 경험이 쌓이면 자신감이 생기고 더 어려운 습관도 도전할 수 있습니다. 완벽하게 하려고 하지 마세요. 70%만 해도 충분합니다. 완벽주의는 실행을 막는 최대의 적입니다. 일단 시작하고 조금씩 개선하세요.
동료와 함께 바꾸세요. 혼자 습관을 바꾸기 어렵다면 동료와 함께 바꾸세요. 코드 리뷰를 서로 해주고 변수명 짓기를 같이 고민하고 커밋 메시지 규칙을 팀에서 정하세요. 팀 전체가 좋은 습관을 가지면 프로젝트 품질이 급격히 향상됩니다. 또한 서로 피드백을 주고받으며 빠르게 성장할 수 있습니다. 좋은 습관은 전염됩니다. 내가 먼저 좋은 습관을 보여주면 동료도 따라합니다.
좋은 습관이 쌓여 실력이 됩니다. 1년 뒤 나를 위해 오늘부터 좋은 습관을 들이세요. 변수명을 의미 있게 짓고 커밋 메시지를 자세히 쓰고 코드 리뷰를 적극적으로 하고 기술 부채를 관리하고 업무일지를 작성하세요. 이런 사소한 습관들이 모여 시니어를 만듭니다. 구체적인 코드 작성 원칙은 클린 코드 편을 참고하세요. 주니어와 시니어의 차이는 타고난 재능이 아니라 만들어진 습관입니다. 오늘부터 시니어의 습관을 따라하세요.
자주 묻는 질문 10가지 완벽 정리
야근하느라 리팩토링할 시간이 없는데 어떡하죠?
개발 시간의 20%만 리팩토링에 할당하세요. 하루 8시간 일하면 1.6시간입니다. 리팩토링은 투자입니다. 지금 1시간 투자하면 나중에 10시간을 절약합니다.
독학 개발자도 좋은 습관을 가질 수 있나요?
네 가능합니다. 오픈소스 프로젝트에 기여하며 코드 리뷰를 받고 유명한 개발자의 코드를 읽으며 좋은 습관을 배우세요.
알고리즘 공부가 도움이 되나요?
네 알고리즘은 문제 해결 능력을 키워줍니다. 하지만 코딩 테스트용 알고리즘보다 실무에서 쓰는 자료구조와 알고리즘을 먼저 공부하세요.
변수명 짓는 데 시간이 너무 오래 걸려요
처음에는 느리지만 연습하면 빨라집니다. 변수명 사전이나 네이밍 가이드를 참고하세요. 좋은 변수명은 나중에 시간을 절약해줍니다.
커밋 메시지를 어떻게 써야 할지 모르겠어요
팀의 커밋 컨벤션을 따르세요. 없다면 feat fix refactor docs 같은 타입을 사용하고 무엇을 왜 바꿨는지 쓰세요.
코드 리뷰에서 지적받으면 기분이 나빠요
코드 리뷰는 개인 공격이 아닙니다. 코드를 평가하는 것이지 사람을 평가하는 게 아닙니다. 피드백은 성장의 기회로 받아들이세요.
기술 부채를 어떻게 관리하나요?
기술 부채를 이슈 트래커에 등록하고 우선순위를 정하세요. 한 달에 한 번 부채 스프린트를 진행하며 체계적으로 해결하세요.
업무일지를 쓸 시간이 없어요
하루 10분이면 충분합니다. 퇴근 전 10분만 투자하면 됩니다. 나중에 성과 정리할 때 10배 시간을 절약할 수 있습니다.
책 읽기가 지루해요
한 번에 다 읽으려고 하지 마세요. 필요한 챕터만 골라 읽어도 됩니다. 코드를 짜다가 막히면 관련 챕터를 찾아 읽으세요.
좋은 습관을 어떻게 유지하나요?
21일만 지속하면 습관이 됩니다. 달력에 체크하며 스스로 보상하세요. 동료와 함께하면 더 쉽게 유지할 수 있습니다.
좋은 습관이 쌓여 실력이 됩니다
코드는 컴퓨터가 실행하지만 읽는 것은 사람입니다. 동료를 배려하는 코드를 짜는 습관이 시니어를 만듭니다. 변수명 짓기, 커밋 메시지 쓰기, 문서화 같은 기본기 습관, 코드 리뷰를 환영하고 남의 코드를 읽는 협업 습관, 기술 부채를 관리하고 비즈니스 가치를 이해하는 마인드셋 습관, 업무일지 작성과 지식 정리 습관이 모여 시니어를 만듭니다. 이 모든 습관의 핵심은 미래의 나와 동료를 배려하는 것입니다.
오늘부터 하루에 한 가지씩 바꾸세요. 가장 쉬운 것부터 시작해서 성공 경험을 쌓으세요. 동료와 함께 바꾸면 더 쉽습니다. 좋은 습관이 쌓여 실력이 되고 실력이 쌓여 연봉이 됩니다. 매일 1%씩 성장하면 1년 뒤에는 37배 성장합니다. 주니어와 시니어의 차이는 타고난 재능이 아니라 만들어진 습관입니다. 구체적인 코드 작성 원칙이 궁금하면 클린 코드 편을 다시 보세요. 코딩 괴물은 타고나는 것이 아니라 만들어지는 것입니다.
공식참고링크안내
좋은 git 커밋 메시지 8가지 약속 · Uno's Blog
.jpg)
0 댓글