좋은코드란 무엇인가?
1 
이번 포스팅에서는 개발자라면 평생 생각해봐야 할 고민거리인 좋은 코드란 무엇인가에 대해서 필자가 고민한 부분들을 공유해보려고 한다.
이 고민은 개발자로 취준을 시작한 2021년부터 쭉 고민해왔고, 현재는 2년차 개발자로 접어들게 되면서 회사 상황으로 인해 생긴 코드 품질과 비즈니스의 타협점을 찾아야 하는 상황들로 인해 더욱 많은 고민을 하게 되었다.
앞서 소개할 주제는 개개인의 가치관, 신념 등에 따라서 여러 방면으로 의견이 갈릴만한 주제이긴 하지만 필자는 주니어 시절 때 했던 이런 고찰들을 기록해보고 싶었고, 이런 기록들을 통해 나중에 배울 부분이 있을 것이라 생각해서 나름의 용기를 내어 적어본다. ( 매도 먼저 맞는 게 낫다라는 속담이 괜히 있는게 아닌것처럼 😅 )
따라서 아래 내용들은 지극히 필자의 주관적인 내용이 주를 이루고, 1년정도 스타트업에서 굴러본 주니어의 의견으로 가볍게 봐주시면 감사하겠다라는 말씀 드린다.
좋은 코드란?
보통 좋은 코드란 무엇인가? 라는 질문을 던졌을 때 읽기만 해도 이해되는 가독성 좋은 코드, 효율적인 성능을 뽑아내는 코드 등을 생각할 것이다. 다 맞는 말들이고 개발자라면 충분히 고려해야할 요소들이다. 하지만 이런 고려사항들은 리소스가 제한적인 상황에서 이익을 창출해야하는 집단에서는 틀릴 수도 있고 맞을 수도 있는 대답이다.
틀릴 수 있다는게 단순히 고려하지 않는다가 아니라, 한정적인 리소스 내에서는 다 해볼 수는 없으니 상황에 따라서 우선순위를 정해야 한다는 것이다. 그래서 만약 필자가 이 질문에 대답한다면, “내가 코드를 작성하는 상황에 따라서 답변이 달라질 것 같다” 라고 말할 것이다.
어떤 상황들이 있을까? 필자가 생각했을땐 크게 2가지로 나뉠 것 같다. 나의 개인 프로젝트를 위해 코드를 짜는 상황, 회사에서 기능을 구현하기 위해 코드를 짜는 상황 이렇게 두개로 말이다.
개인 프로젝트에서
내 개인 프로젝트를 위해 코드를 짜야하는 상황이라면 필자가 생각하는 좋은코드는 위에서 예시로 들었던 항목들일 것이다. ( 위 예시들에서 성장할 부분이 있었던 코드 도 추가되면 좋을 것 같다. )
어떻게 보면 당연한 말일 수도 있다. 취미로 하는 개발, 성장하기 위해 하는 개발 등 같은 내 개인적인 상황 또는 사유로 인해 작성하는 코드들은 의무적으로 이익을 우선시 해야할 이유가 없기 때문에 더 우선순위가 높은건 내 개인적인 동기일 것이다. ( 여러명에서 하는 사이드 프로젝트에서는 말이 달라질 수 있다. )
좀 더 원론적으로 설명하자면, 개인적인 목적으로 인해 작성된 코드는 학습, 창의성, 또는 개인적 성취감이 더 중요한 요소가 될 수 있고, 따라서 다음 상황에서 말하는 좋은 코드는 특정 기준을 따르기보다는 자신이 바라는 목표를 얼마나 충실하게 달성했는지가 중요한 것이다.
회사에서
개인 프로젝트에서의 좋은 코드란 무엇인지 알아보았으니 회사라는 집단에서의 좋은 코드란 무엇인지 알아보자.
이 궁금증은 회사는 우리를 왜 개발자로 고용하였을까? 라는 질문에서 부터 시작하여 고민하면 이해가 조금 빨라질 수 있다. 필자가 예전에 썼던 글 반짝 빛난 나의 2023년 회고를 읽어보면 알 수 있듯이, 회사는 회사의 이익을 위해 우리의 노동력을 돈주고 산 것이기 때문에 우리의 고용 자체는 회사의 이익 추구가 대전제로 깔려 있는 것이다.
따라서 회사에서는 비즈니스 임팩트가 우선시 되고, 좋은코드는 자연스럽게 비즈니스 임팩트에 집중한 코드가 좋은 코드가 될 것이다. 하지만 누구는 이렇게 질문 할 수 있다.
“위에서 든 예시들 (
읽기만 해도 이해되는 가독성 좋은 코드,효율적인 성능을 뽑아내는 코드)도 비즈니스에 임팩트를 줄 수 있는 부분들 아닌가요?”
합리적인 질문이다. 코드를 읽기만해도 맥락 파악이 쉽고, 맥락에 맞게 폴더를 분리한 코드는 갑자기 다른 개발자가 고용되어 해당 코드를 손 봐야하는 상황에서 맥락을 파악하는 시간을 줄여줄 수 있고, 나중에 발생할 유지보수 비용을 미리 줄여줄 수 있기에 간접적으로 회사의 이익이 될 수 있다.
또 짧은 쿼리 응답시간, 화면 렌더링 시간 같이 성능을 뽑아내는 코드들은 제한적인 리소스를 최대한 효율적으로 활용한 것이기 때문에 회사의 이익이 될 수 있다.
위 내용에 따르면 모든 부분들이 다 어느정도 비즈니스 임팩트를 줄 수 있는 코드들인 것 같은데 왜 필자는 상황에 따라 틀릴 수도 있다고 했을까?
바로 회사의 규모에 따라서 필요한 직/간접적인 비즈니스 임팩트의 비율이 다르기 때문이다. 말이 좀 추상적일 수 있을 것 같다. 간단한 예시를 들어보자.
스타트업/중소기업
여기 Seed 단계 투자를 받은 지 9개월이 된 B2B 스타트업 A에서 일하는 개발자 B가 있다고 하자. B는 최근 고객사 20군데를 유치할 수 있는 기능에 인볼브 되었다.
고객사 유치뿐만 아니라 다른 투자사의 시리즈 A 투자를 받을 수도 있을만한 임팩트를 가지고 있었다. 해당 기능은 데드라인이 1주뒤 정도로 잡혀있는 우선순위가 높은 태스크였다.
B는 처음에 다른 기능의 구조와 비슷한 패턴이 많아서 코드를 나중에 재사용 할 수 있도록 공통화하면서 개발하는 방식을 고민했지만, 배포가 갑자기 당겨지면서 어쩔 수 없이 기존 코드에서 변수명만 바꾸고 거의 그대로 복사해서 새로운 기능을 추가하는 방식을 선택했다. 다행히 데드라인 안으로 기능을 배포했지만, 기술부채가 쌓이게 되었다.
만약 B가 다른 선택을 했다면 어떻게 됐을까? B가 다른 방안을 선택했다면, B의 회사는 런웨이를 더 연장할 수 없었을 것이고, 망하는 길을 걸었을 것이다. B가 고집했던 좋은 구조의 코드들도 다 휴지조각이 되어버리는 것이다.
예시가 너무 극단적이라고 생각할 수도 있지만, 필자가 말하고 싶은 것은 비교적 회사의 존망 여부가 쉽게 왔다갔다하는 스타트업/중소기업의 경우에는 일반적으로 직접적인 비즈니스 임팩트를 훨씬 더 필요로 한다는 것을 말하고 싶었고, 주니어 개발자인 필자의 경우에도 꽤나 그런 부분들은 쉽게 접할 수 있었다. ( 특히 개인보다 어느정도 더 큰 영향력을 행사할 수 있는 회사라는 집단을 고객으로 하는 B2B에서는 더 그런 부분이 있는 것 같다. )
위에서 필자는 회사의 규모에 따라서 직/간접적인 비즈니스 임팩트의 비율이 달라진다고 말했다.
이 문장에 대해서 누구는 이렇게 질문할 것이다.
어느정도 여유가 있는 스타트업/중견기업/대기업/빅테크기업 같은 기업도 본질은 회사이기에 이익을 우선시 하는건 다를게 없을 거 같은데 왜 달라지는 거죠?
어느정도 여유가 있는 스타트업/중견기업/대기업/빅테크기업
스타트업의 경우에는 한정적인 리소스에서 우선순위를 정해야하는 상황이지만, 어느정도 규모가 있는 기업은 다르다.
리소스가 비교적 여유롭기 때문에 기술과비즈니스 두가지 측면을 적절히 비율을 맞춰서 관리 할 수 있다. 보통은 플랫폼팀과 피쳐팀을 나눠서 관리하기도 한다. 피쳐팀은 지속적으로 들어오는 요구사항을 개발하고, 플랫폼팀은 그런 피쳐팀의 생산성을 높이기 위해 디버깅 툴, Third-party 라이브러리, 디자인시스템 등을 구축하고 제공한다.
또 규모가 큰 조직은 어느정도 기반이 안정화 되었기 때문에, 프로덕트의 안정성 또는 개발 인프라 구축에 집중할 수 있다. 위에서 말했던 코드를 읽기만해도 맥락 파악이 쉽고, 맥락에 맞게 폴더를 분리한 코드 같은 간접적인 이익을 낼 수 있는 액션도 직접적인 이익을 낼 수 있는 시점이 된다.
결론적으로 총 정리를 하자면 회사는 돈으로 운영되는 집단인 만큼 돈을 벌 수 있어야 하며, 돈을 얼마나 잘 버는가에 대해서 내가 작성할 수 있는 좋은 코드에 대한 기준이 달라진다.
라고 정리할 수 있겠다.
마치며
글을 쓰면서, “아 내가 아직 경험이 많이 부족하구나” 라는 생각이 정말 많이 들었던 것 같다.
특히 어느정도 여유가 있는 스타트업/중견기업/대기업/빅테크기업 섹션을 작성할 때는 직접적인 내 경험이 아니라, 간접적으로 접한 얘기 또는 겉으로 보이는 것만으로 글을 작성햇던지라, 어떤 독자께서는 너무 단편적으로 보였을 수도, 별로 공감이 되지 않을 수도 있을 것 같다.
하지만 이 글을 작성한 목적은 “좋은 코드란 무엇인가?” 라는 주제처럼 꽤나 추상적인 주제를 필자만의 고찰로 정의해보고 기록해보고 싶었기 때문에 단편적이었던 부분도, 극단적이었던 부분도 이 글의 목적에 알맞는 부분이라는 생각한다. ( 개인적으로 이런 추상적인 주제에 대해서 정의할때는 trade-off 상태로 생각해보는 것이 유리하다고 생각한다. )
필자는 이번 고찰 덕분에 개발자가 왜 계속 성장을 해야하는 직업인지도 다시 한번 느낄 수 있었다. 위 스타트업/중소기업섹션에서 필자가 들었던 극단적인 상황에서 개발자 D가 실력이 꽤나 좋아서, 무엇 하나 포기하지 않고 코드퀄리티, 데드라인 모두 챙겼다면 가장 베스트였을 것이다. 하지만 필자가 생각하기엔 필자는 그에 반해 둘 중에 하나를 포기해야하는 상황을 꽤 마주하는 것 같다. 따라서 아직 더 성장해야하고 배워야할 부분이 많다는걸 느낄 수 있었다.
글을 마치면서, 4차 산업혁명을 겪고 있는 현재의 우리들은, 시간이 지날수록 비즈니스가 우리에게 요구하는 요구사항들은 더욱 더 복잡하게 다가올 것이라고 생각한다. 따라서 이번 글의 주제인 좋은 코드란 무엇인가? 라는 질문의 배울점들은 현재의 우리 뿐만 아니라, 미래의 우리에게도 도움이 되줄거라는 말을 마지막으로 포스팅을 마친다.