트위터에서 우연히 다음과 같은 이미지를 봤습니다. 이걸 깨닫는데 20년 이상이 걸렸다라는 부제가 있습니다.
스르륵 읽어보니 마음에 듭니다. 제 생각을 곁들여 우리말로 풀어 봅니다. 제가 이해한 대로 뜻풀이+제 생각 덧대기를 한 것이므로, 원 저자의 생각과 다른 부분이 있을 수 있습니다.
1. 단지 배우기만 하는 것에는 덜 집중하고, 행동으로 옮기는데 더 집중하라.
개발자가 새로운 기술을 익힐 때 종종 빠지는 함정이 있다. 튜토리얼을 완주하고, 문서를 읽고, 강의를 듣는 것으로 학습이 끝났다고 여기는 것이다. 하지만 실제로는 그때부터 진짜 학습이 시작된다.
우리가 무언가를 배운다는 것은 지금 알고 있는 지식으로 해결하지 못한 문제를 풀기 위한 것이다.따라서 Doing, 지식을 이용하여 문제를 해결하는데 좀 더 집중해야 한다. 학습이란 무언가를 배우는 행위(學)에 그것을 실제로 적용해 보면서 몸에 익히는 과정(習)이다.
<머신러닝 마스터클래스>의 저자 민재식 박사가 언급한 접근법이 인상적이었다. 머신러닝을 학습할 때 필요한 수학 분야를 먼저 파악하고, 해당 영역을 공부하면서 동시에 머신러닝을 익혔다는 것이다. 목적이 명확할 때 학습의 효율성이 달라진다는 점을 보여주는 사례다.
뭔가를 배울 때에는 배우는 목적을 상기할 필요가 있고(가르치는 사람 입장에서), 문제를 해결하기 위해 무엇을 배워야 하는지 순서를 바꿔보면 도움이 되겠다(배우는 사람 입장에서)는 생각이 든다.
2. 버그를 고치다보면 빠르게 배운다.
완벽한 코드를 처음부터 작성하는 개발자는 존재하지 않는다. 버그는 단순한 실수가 아니라 우리가 문제를 완전히 이해하지 못했다는 신호다.
디버깅 과정에서 우리는 처음 문제를 분석할 때 놓쳤던 부분들을 발견하게 된다. 이 과정에서 일어나는 학습은 일반적인 이론 학습보다 훨씬 깊은 이해와 통찰을 얻을 수 있고 지속적인 성장이 가능하다. 이 과정이 실제 맥락 안에서 일어나는 학습이기 때문이다.
3. 해결책은 항상 간단하게 시작해서 반복하면서 발전시켜나가자.
습(習)이라는 글자는 새끼 새가 날개짓을 연습하는 모습을 형상화한 것이라고 한다. 하얀 날개를 가진 새끼 새도 처음부터 완벽하게 날지 못한다. 작은 동작부터 시작해서 점진적으로 복잡한 비행을 익혀간다.
소프트웨어 개발도 마찬가지다. 처음부터 완벽한 아키텍처를 설계하려 하기보다는, 작동하는 최소한의 것부터 만들어서 점진적으로 개선해나가는 것이 현실적이다. 이런 접근법이 실패의 리스크도 줄이고 학습의 기회도 늘린다.
4. 자주 실패하는 것이 비싼 댓가를 치르지 않는다.
큰 단위로 개발하고 나서 실패하면 그 댓가는 크다. 시간, 비용, 그리고 심리적 타격 모두 상당하다. 반면 작은 단위로 자주 시도하고 빠르게 피드백을 받으면, 개별 실패의 비용은 작지만 전체적으로는 더 안전한 경로를 걸을 수 있다.
이론적으로는 당연한 이야기지만, 실제로 실행하기는 쉽지 않다. 특히 완벽주의 성향이 있거나 실패에 대한 두려움이 클 때는 더욱 그렇다. 하지만 경험상 미루고 묵혀두면 결국 더 큰 문제가 되는 경우가 많았다.
5. 계획을 세운 뒤 코드를 작성하자.
개발과 코딩은 다르다. 개발은 문제를 이해하고 해결 방법을 설계하는 것이고, 코딩은 그 설계를 프로그래밍 언어로 구현하는 것이다. 순서가 바뀌면 좋은 결과를 기대하기 어렵다.
키보드를 두드리기 전에 먼저 생각하는 시간을 갖는 것. 간단해 보이지만 실제로는 상당한 훈련이 필요한 습관이다.
6. 뭔가 잘 안된다면 새로운 것을 배우는 중이라는 뜻이다.
어려움에 부딪혔을 때 좌절하기보다는 성장의 기회로 받아들이는 관점이 중요하다. 모든 것이 순조롭게 진행된다면 새로 배우는 것이 없다는 뜻이기도 하다.
물론 일상적인 업무는 안정적으로 처리해야 하지만, 의도적으로 자신의 역량보다 조금 높은 수준의 도전을 찾아가는 자세도 필요하다.
7. 코드 품질이 중요하다. 의도가 명확히 드러나는 코드를 작성하자.
코드는 일종의 번역 작업의 결과물이다. 인간의 언어로 표현된 문제와 해결책을 컴퓨터가 이해할 수 있는 언어로 옮기는 것이다. 좋은 번역이 원문의 의도를 정확히 전달하듯, 좋은 코드는 개발자의 의도를 명확히 드러내야 한다.
의도가 명확한 코드는 별도의 문서 없이도 스스로를 설명한다. 이런 코드는 유지보수 비용을 크게 줄여준다.
8. 피드백을 받고, 도움을 요청하자.
성장의 핵심은 도전과 피드백의 순환 구조를 만드는 것이다. 혼자서 모든 것을 해결하려고 하는 것은 비효율적일 뿐만 아니라 성장 기회를 놓치는 일이기도 하다.
코드 리뷰, 페어 프로그래밍, 멘토링 등 다양한 형태로 피드백을 받을 수 있다. 중요한 것은 도움을 요청하는 것을 부끄러워하지 않는 것이다. 적절한 도움 요청은 프로페셔널의 자질이다.
9. 항상 작성한 코드를 테스트해보아야 한다. 테스트 자동화를 배워라.
AI가 코드 작성을 도와주는 시대가 되어도 테스트의 중요성은 변하지 않는다. 오히려 더 중요해질 수도 있다. 자신이 작성한 코드에 대한 책임은 여전히 개발자에게 있기 때문이다.
반복적인 테스트 작업을 자동화하는 것은 단순히 시간을 절약하는 것 이상의 의미가 있다. 코드의 품질을 지속적으로 보장하는 안전망 역할을 한다. 이광근 교수님이 운영하는 쉬운용어 사전에서 회귀 테스트를 퇴행 방지, 여전히 동작하는지 검사하는 것이라 풀어낸 것을 봤다. 우리가 작성한 코드가 쉽게 상하지 않도록 테스트하고, 자동화해야 한다.
10. 문제를 푼 다음에 코드를 작성하자.
코드를 작성하기 전에 해결하려는 문제를 정확히 이해해야 한다. 때로는 코드를 작성하지 않는 것이 가장 좋은 해결책일 수도 있다.
문제를 제대로 이해하지 못한 채 작성된 코드는 결국 다시 작성해야 할 가능성이 높다. 처음에 시간을 충분히 투자해서 문제를 분석하는 것이 전체적으로는 더 효율적이다.
11. 디버깅은 어렵다. 디버깅하는 방법부터 숙달하자.
코드를 작성할 때와 디버깅할 때는 다른 종류의 사고 과정이 필요하다. 전자는 구성적이고 창조적인 사고라면, 후자는 분석적이고 추론적인 사고다.
디버깅 능력은 단순히 도구 사용법을 아는 것 이상이다. 체계적으로 문제를 분석하고, 가설을 세우고, 검증하는 방법론을 익혀야 한다. 이런 프레임워크가 있으면 복잡한 문제 상황에서도 당황하지 않고 차근차근 접근할 수 있다.
이 11가지 관찰은 완성된 원칙이라기보다는 개발 과정에서 지속적으로 되돌아볼 만한 지점들이다. 기술은 빠르게 변하지만, 문제를 해결하는 근본적인 접근법은 상당히 일관된 면이 있다는 생각이다.
'2. 개발 > 2.0 개발 잡설' 카테고리의 다른 글
| Gemini CLI - (1)설치하기 (0) | 2025.06.26 |
|---|---|
| 현대 소프트웨어 공학 북토크 노트 (0) | 2025.05.07 |
| 코딩 보조 도구에 대한 여러 생각들 요약/1 (4) | 2025.05.06 |
| AI에게 코딩을 시키더라도 개발자는 설계를 해야 한다. (0) | 2025.05.03 |
| 오라일리 레이더 문서 번역 정리 (0) | 2025.04.08 |
