꼰대 개발자
개발을 하다보면, 다양한 개발자들을 만나고, 다양한 개발지식을 알게 되고, 다양한 팁을 알게 된다.
꼰대 개발자
개발을 하다보면, 다양한 개발자들을 만나고, 다양한 개발지식을 알게 되고, 다양한 팁을 알게 된다.
그중에서도 특히 선배, 교수, 멘토, 혹은 나보다 경험이 많은 개발자들이 해준 몇 가지 팁이 기억에 남는다.
- 마우스 없이 개발을 해봐라 (VIM을 써봐라)
- 알고리즘을 컴퓨터가 아닌 손으로 코딩해봐라
- 라이브러리나 프레임워크 없이 기본적인 CRUD를 구현해봐라
- CLI 프로그램을 만들어봐라
- TDD를 해봐라
- 도망쳐라, 개발자
등..
정말 좋은 팁이라 생각한다. 물론 개발일 1도 몰랐을 때는 왜 필요한지 모르니까 와닿지 않았던 조언들이었다. 개발을 처음 시작할땐 그저 내가 쓰는 언어를 공부하고, 어떻게 돌아가는지 아는것만으로도 어려웠기 때문이다.
하지만 시간이 지나고 개발 지식이 쌓이다 보니, 왜 그런 조언들이 필요한지 느끼게 된다. 확실히 당해봐야 느끼는 것 같다.
개발을 하면서 이런 의견도 있었다:
- UI와 비즈니스 로직을 분리하기 위해 요즘에는 클린 아키텍처가 좋다 ⇒ 안정적인 설계를 위한 큰 그림인가?
- 백오피스는 방향성이나 기획보다는 API 먼저 만들어야 한다 ⇒ 개발자는 코드로 말한다는 게 이런 건가?
이러한 의견들도 앞선 팁들처럼 어느 정도 일치하는 부분이 있었으니, 존중하고 의견을 받아들이며 개발을 했다.
하지만, 이게 왠걸? 좋은 의견일 거라 생각했던 것들이 10개월을 발목 잡는 문제를 만들었다.
왜 10개월이나 시간을 낭비했을까? 그건 내가 어떤 것이 실용적인 팁인지 아닌지 몰랐던게 아닐까?
이번 글은 Google meet 시간이 초과되어도 결코 스터디를 멈추지 않는 CSS(Code Slice Study)라는 스터디 그룹에서 읽었던 책 <실용주의 프로그래머> 읽고 감명깊게 읽었던 부분을 정리한 내용이다.
일단은 해봐라?
이론이 무엇인지, 결과가 어떻게 되는지 잘 말해주지 않고 일단 시도를 해보라고 말하는게 어떻게 보면, 꼰대같은 말이라고 생각할 수 있다.
하지만 꼰대랑 실용주의는 조금 다르다.
우선 실용주의(pragmatism)라는 어원자체가, 관념론의 현학적이고 꼰대스러움을 반박하면서 생겨난 철학 사조이기 때문이다.
다만 실용주의는 <실험, 실천, 행위>를 통해 구체적이고 현실적인 결과를 만드는것이 중요하다라 생각한다. 그리고 꼰대라는 말 자체도 “내가 해봤으니, 내가 잘 알아, 내가 옳아” 라는 식 행위를 뜻한다.
그러다보니 “실행(do)”이 실용주의나, 꼰대에서 교집합처럼 있다보니, 이게 정말 실용적인 팁인지..? 아니면 그냥 꼰대같은 팁인지..? 알기가 어렵다는것이다.
그렇다면 어떤게 실용적인 팁일까?
실용주의 프로그래머의 팁은 뭘까?
실용주의 프로그래머는 일단 문제를 더 큰맥락에 놓고 더 큰 그림을 보려 노력한다. 그리고 모든일에 책임을 지려 한다. 마지막으로 외부와 단절된 채로 일하지 않는다.
더큰 맥락
프로그램이 지금 당장 잘 돌아가는 것보다, 개발하는 과정에서 유지 보수하기 좋고 변화에 유연한 코드를 짤 수 있게끔 만드는 것이다.
이를 위해 다양한 아이디어와 프로세스들이 있다.
- ETC (Easier to Change)
- DRY (Don’t Repeat Yourself)
- 직교성
- 가역성
- 예광탄
등등이 있다.
이런 기본 원리들을 유념하면 더 좋은, 더 빠른, 더 강력한 코드를 작성할 수 있을 것이다.
예시로 ETC와 가역성에 대해 설명해보겠다.
ETC ( Easier to Chage)
코드를 쉽게 바꿀 수 있도록 만드는 것이다.
이를 위해 결합도를 줄이고, 단일 책임 원칙을 지키며, 변수명을 알맞게 짓는 방법들이 있다. 사실 우리가 작성하는 모든 코드는 언젠가 레거시가 되고, 교체해야 할 날이 온다. 따라서 언제든 교체할 수 있게 만들어 놓는 것이 중요하다.
가역성
앞서 말했듯이, 코드는 항상 변한다. 영원한 것은 없기에 당신이 사용하는 코드도 언젠가 변할 것이다. 특정 업체의 데이터베이스나 아키텍처 패턴, 라이브러리에 종속되는 순간, 그 변화에 발목을 잡힐 수 있다.
하지만 가역성을 중시했다면, 그런 종속성을 최소화하고 코드가 더 유연하게 설계될 수 있었을 것이다. 예를 들어, 데이터베이스나 라이브러리를 추상화해서 사용했다면, 상황이 변해도 유연하게 대처할 수 있었을 것이다.
🙋♂️ “개발 환경이 변해서 지금 당장 개발을 못해요.”
이것은 가역성을 지키지 못한 것이다. 특정 IDE에 종속되지 말고, 그보다 더 추상적인 도구를 사용할 줄 안다면 새로운 개발 환경에 적응하는 데 걸리는 시간을 줄일 수 있다. 예를 들어, 텍스트 에디터인 VIM을 사용할 줄 안다면 이런 문제에서 자유로울 것이다.
⇒ 텍스트 에디터를 연습하자!
🙋♂️“새로운 기능을 추가했는데 기존 기능에서 버그가 생겨요.”
이것은 직교성을 지키지 못한 것이다. 결합도를 줄이고 테스트를 추가하여 기존 기능의 안정성을 높인다면, 새로운 기능에만 집중할 수 있을 것이다.
⇒ TDD를 연습하자!
책임감
여러분은 완벽한 소프트웨어를 만들수 없다
완벽한 소프트웨어는 만들 수 없다. 실용주의 프로그래머는 자신의 실수에 대해 방어책을 마련하고, 버그 상황에서도 피해를 최소화하려 한다.
어떻게 준비할까? 대표적인 예로 DBC (Design By Contract)가 있다.
DBC (Design By Contract)
계약에 의한 설계로, 프로그램의 정확성을 보장하기 위해 모듈의 권리와 책임을 문서화하고 합의하는 것에 초점을 맞춘다. 루틴이 작동하기 위해 요구되는 조건(선행조건), 작업 후 보장되는 조건(후행조건), 클래스 불변식 등을 명확히 해두는 것이다.
소프트웨어의 시스템의 모든 함수와 메서들은 ‘뭔가를 한다’ 그렇다면 그 뭔가를 하기전, 하고난뒤에 대한 조건이나 상태가 있을텐데 이러한것들을 ‘계약’을 하는것이다
- 선행조건: 루틴이 호출되기 위해 참이어야 하는것
- 후행조건: 루틴이 자기가 할 것이라고 보장하는 것
- 클래스 불변식: 호출자의 입장에서 볼 때 언제나 참인 것을 보장함, ( like 순수함수)
이런식으로 계약을 코드에 주석이나 단위테스트를 넣어둘 수 있고, 단정문을 통해서 “일찍 멈출 수 있다” 에러가 나면 핸들링으로 숨기지 말고 확실하게 에러를 만들고, 사용하는 호출자가 핸들링 할 수 있게 만드는것이 좋다.
🙋♂️ ”다른 동료가 만든 코드를 사용했다가 버그가 날거 같아 못쓰겠어요”
해당 코드에 대한 계약을 모르기 때문에 생겨나는 문제다, 해당 코드를 어떤 계약이 있는지 + 예시가 있는지를 모르기 때문이다
그래서 DBC와 Test code가 있다면 호출하는 쪽이 해당 코드에 대해 이해를 할 수 있고, 호출되는 루틴은 이미 선행조건의 정보를 제공함으로서 안전하게 설계를 할 수 있게된다.
헤드라이트를 앞서가지마라
예측은 힘들다, 특히 미래에서는..
작은 단계를 밟아라, 더 진행되기 전에 피드백을 확인하고 조정해야한다
예를 들어
- REPL의 결과는 API나 알고리즘을 제대로 이해하고 있는지 피드백을 준다
- 단위 테스트는 직전에 고친 코드에 대한 피드백을 준다
- 사용자 데모 및 사용자와의 대화는 기능이나 사용성에 대한 피드백을 준다
어떤 작업이 시작할 때 그기 작을 수도 클 수도 있다. 아무리 미래를 확신하더라도 억측이 될 수 있기에 코드를 바꾸기 쉽게 설계하고, 지속적인 피드백을 받으며 조정해 나가야 한다.
🙋♂️ 화면 개발까지 끝났는데, 필요가 없다 하네요
사용자 데모를 고려하지 않은것이다. 개발자 본인이 생각하는게 무조건 정답이라고 생각하는건 지나친 억측이다. 개발을 진행하기전, 진행하는중, 진행하고 나서 모두 사용자에게 데모를 보여줘야한다.
소통
프로젝트에 참여하는 사람이 복수가 되면 기본적인 규칙 몇 가지를 정립하고 그에 따라 프로젝트의 각 부분을 위임해야 한다.
실용주의 프로그래머는 올바른 소프트웨어 방법론을 찾아가고 있는지, 안정적인 소프트웨어를 지속적으로 생산하기 위해서 어떻게 준비해야 하는지, 사용자를 어떻게 해야 기쁘게 하는지, 그리고 자신의 작업에 자부심을 가질 수 있는지를 고민하고 준비한다.
- 팀의 존재를 소통하라
외부 사람들에게 무뚝뚝하고 과묵해 보이는 프로젝트팀 이야말로 최악의 팀이다. 이러한 팀은 문서마다 생김새도 제각각이고, 서로 다른 용어를 사용한다.
- 반복하지 말라
팀원간의 중복된 일을 제거해야한다. 그러기 위해선 좋은 의사소통을 통해 질문을 하거나, 상황 공유를 즉각적으로 할 수 있는 분위기를 만들어야한다.
그래서 팀원 서로간 어떤 일을 하는지 알 수 있게 된다
- 멈춰야 할 때를 알라
각 팀원이 자신의 방식대로 빛나게 해야한다. 팀원들이 지원하기에, 그리고 프로잭트가 가치를 만들어 내기 딱 좋을 만큼 구조를 제공하자, 멈추지 않고 한명이 화가 처럼 계속 덧칠하면 다른 팀원들은 계속해서 기다려야하기 때문
- 사용자를 기쁘게 하라
결국 개발자로서의 목표는 사용자를 기쁘게 하는것이다. 사용자가 원하는 것은 코드가 아니다. 프로젝트를 진행하면서도 계속 사용자의 기대에 대하여 생각하라
다시 돌아와서
그렇다면 앞서 들었던 팁을 다시 봐보자
- 요즘 유행하는 클린아키텍처로 구성하자 ⇒ 큰 그림 인가?
- 백오피스는 방향성, 기획보단, API 먼저 만들어야돼 ⇒ 개발자는 코드로 말한다가 이런건가?
라는 말은 사실
- UI와 비지니스 로직을 분리하기 위해선 요즘엔 클린아키텍처가 좋다
⇒ 더 큰 맥락을 위한것 처럼 보이지만, 어떤 미래가 펼치질지 모르는 상황에서 유행을 좇아 가면 안된다. 프로젝트 상황에 알맞는 설계가 필요하다 (클린아키텍처가 나쁘다는게 아니다)
- 백오피스는 방향성, 기획보단, API 먼저 만들어야돼 ⇒ 개발자는 코드로 말한다가 이런건가?
⇒ 헤드라이트를 앞서갔다. 기획부터 사용자와 같이 소통을 하며 설계를 했어야 했다. 개발자가 만든 코드가 무조건 정답인 아니다.
라고 말할 수 있다.
이러한 실용주의적 사고방식을 알았다면, 이러한 의견들을 그대로 받아들이지 않고 한번 더 의견을 나눠 볼 수 있었지 않았을까?
반대로 좋은 실용주의 팁들을 적용해 보려 노력해 봐야겠다. TDD라던지, CLI 프로그램을 만들어본다던지, 마우스 없이 개발을 해본다던지.
그렇게 시도하고 행동하다 보면 좋은 실용주의 프로그래머가 되어 있지 않을까?
참고
메타데이터
- post_id
- 08d60081676c
- slug
- 꼰대-개발자-08d60081676c
- url
- https://medium.com/@dndb3599/%EA%BC%B0%EB%8C%80-%EA%B0%9C%EB%B0%9C%EC%9E%90-08d60081676c
- canonical_url
- https://medium.com/@dndb3599/%EA%BC%B0%EB%8C%80-%EA%B0%9C%EB%B0%9C%EC%9E%90-08d60081676c
- author_url
- https://medium.com/@dndb3599
- status
- ok
- fetched_at
- 2026-07-22 20:22:31
