포기는 배추 셀 때만 하는 말이 아니다

2022.02.27.

포기는 보통 부정적인 의미로 사용된다. "포기란 배추 셀 때나 하는 말이다" 표현은 포기하지 못하도록 만드는 대표적인 표현이다.

'N포 세대'라는 표현에도 부정적인 의미로 포기가 사용된다. 여기서 말하는 포기(暴棄)는 자포자기의 줄임말이다.

오늘 집중하고 싶은 의미는 포기(抛棄)의 다른 의미로 '하려던 일을 도중에 그만두어 버림'을 의미한다.

포기가 필요한 순간

나는 포기라는 표현을 자주 쓰는 편이다. "포기하면 편해"라는 회의적인 의미가 아니다.

집중하기로 정한 일을 더 잘하기 위해 방해되는 행동을 계속 그만두고 있다는 의미다.

포기할 수 있다는 건 무엇에 집중해야 할지 안다는 의미다.

포기는 집중할 것을 정한 사람이 할 수 있는 멋진 선택이다. 동시에 포기는 자신의 한계를 잘 아는 사람이 할 수 있는 용기 있는 행동이다.

오늘은 보통 내가 어떤 것을 포기하는지 나눠보려 한다.

글쓰기

지난 글에서 일하는 방법을 소개하며 의도적으로 특정 개념을 설명하길 포기했었다.

처음부터 목적이 분명했기 때문이다. 개발자가 아니어도 이해할 수 있는 글을 쓰고 싶었다.

따라서 개발자들만 이해하는 어려운 개념은 설명하길 포기했다. 만일 개발에서 사용하는 개념을 설명하고 시작했다면 독자는 글의 핵심 메시지를 이해하기 힘들었을 거다.

이 글을 쓰는 순간에도 불필요한 개념이나 용어를 사용하지 않으려고 애쓰고 있다. 쓰려던 표현을 사용하지 않음으로써 반복적으로 포기하고 있다. 무엇에 집중해야 하는지 분명히 알기 때문이다.

이번 글은 배추를 세지 않을 때도 '포기'를 쓰는 게 얼마나 유용한지 설명하고 싶은 글이다. 이 때문에 중요하지 않은 요소는 최대한 포기하려고 노력하고 있다.

모든 글이 마찬가지다. 예상 독자와 핵심 메시지를 생각하며 계속 포기해야 한다.

코드 리뷰

개발자는 소프트웨어를 개선하기 위해 소스 코드를 수정하고 동료 개발자에게 리뷰를 요청한다. 이 과정을 '코드 리뷰'라고 부른다.

버튼의 문구를 수정하는 상황이라고 가정하자. <확인>을 <완료>로 바꾸기만 하면 된다.

기존에 <확인> 버튼을 클릭하는 함수의 이름은 handleConfirm이었다. 확인(confirm)을 완료(complete)로 바꿨기 때문에 함수 이름도 바꿔야 한다. 함수 이름을 handleComplete로 바꿨다. 끝이다.

그런데 옆에 있는 <취소> 버튼 클릭 함수는 이름이 onCancel이다. 참을 수 없다. 모든 함수가 handle-로 시작해야지 왜 이 함수만 on-으로 시작하는가! 일관성은 포기할 수 없다. handleCancel로 바꿨다.

그러고도 일관성이 없는 함수가 있어서 몇 개를 더 바꿨다. 이제 코드 리뷰를 받으면 된다.

함수 이름을 바꾸느라 변경 사항이 많아진 탓에 동료는 무엇을 위한 리뷰 요청인지 이해하기 어려워졌다. 변경 사항을 이해하기 위해 여러 줄을 오가며 코드를 확인해야 했다.

리뷰를 마치며 동료가 이렇게 말한다. "그래서 <확인>을 <완료>로 바꾸시려는 거죠?"

위 상황에서는 목적에 맞는 한 가지 일만 리뷰를 요청했어야 했다. 일관성을 맞추는 일을 잠시 포기했어야 했다.

버튼의 텍스트와 함수 이름을 바꾸고 다른 함수의 이름도 일관성을 맞추고 싶었다면 리뷰 요청을 두 번으로 나눠야 했다.

모든 코드 리뷰가 마찬가지다. 코드 리뷰를 요청할 때는 리뷰를 여러 번 요청하더라도 동료가 본질에 집중할 수 있도록 배려해야 한다.

서비스 개발

쇼핑몰을 만들어야 한다고 가정하자. 처음부터 만들어야 한다. 일정은 정해져 있다.

제한된 일정에 모든 걸 만들려면 개발자 모두가 몇 날 며칠 밤을 새워도 될 것 같지 않다. 무엇을 포기하면 목표를 달성할 수 있을까?

만약 개발 인원을 늘릴 수 있거나 나보다 더 잘하는 사람이 있다면? 인원은 늘리고 내가 하려던 걸 넘겨주고 직접 만들길 포기할 수도 있다. 하지만 지금 그럴 수 있는 상황이 아니다. 기획을 살펴보자.

쇼핑몰에서 포기할 수 없는 사용자 경험은 무엇일까. 아무리 못해도 유저가 상품 선택부터 결제까지 가능한 경험을 제공해야 한다. 결제 수단이 다양할 필요도 없다. 우선 가장 많이 사용되는 결제 수단 몇 개만 선택해서 결제가 가능하게 하자.

신규 브랜드의 자사몰이라 초기에 상품이 10개 정도다. 그럼 검색 기능도 당장은 필요 없다. 사내 유저를 위한 상품 관리 서비스가 필요할까? 아니다. 당장 급한 건 쇼핑몰 그 자체다. 상품 선택부터 결제까지 가능한 경험이 가장 중요하다. 그 외의 요소는 최대한 포기하자.

처음부터 한 번에 완벽한 쇼핑몰을 만들 수 없음을 인정하고 시작하자. 정리한 요구사항을 우선 빠르게 개발해보자. 일단 작게 시작하고 점진적으로 개선해 나가면 된다.

가만 보니 이 정도면 직접 만드는 것보다 이미 만들어진 도구를 쓰는 게 낫겠다는 판단이 들 수도 있다. 그렇다면 직접 만드는 걸 포기하고 당장 좋은 솔루션을 찾아보자. 하지만 지속해서 개선하고 최적화하기 위해 직접 구현이 필요하다고 한다면 직접 구현하면 된다.

맺음

누구나 완벽한 결과를 만들고 싶어 한다. 그래서 포기하는 법을 잊을 때가 있다.

한 번에 완벽하게 할 수 있다면 포기하지 않아도 좋다. 하지만 분명 한계라는 건 분명 존재한다.

한계를 분명하게 인지하고 있다면 어디까지 수용하고 어디부터 포기할지 결정할 수 있다.

우리는 경험이 쌓일수록 자신의 한계를 잘 알게 된다. 경험이 더 쌓이면 팀의 한계까지 알게 된다. 시니어는 한계를 알고 무엇을 포기해야 할지 아는 사람이 아닐까.

일을 시작하기 전에 질문하자. 무엇이 가장 중요한지. 무엇을 포기할 수 있는지.

포기란 배추 셀 때만 쓸 수 있는 말이 아니다. 포기할 수 있다는 걸 늘 잊지 말자.