개발자가 ‘일’ 잘하는 방법

블로그나 SNS 등에서 보면 많은 개발자들이 개발을 더 잘하기 위한 고민 상담을 하는 것을 볼 수 있다. 나는 이러한 고민 속에 개발 실력뿐만 아니라 일을 잘하는 방법에 대한 고민거리도 녹아 있다고 생각한다. 내가 개발 커뮤니티에서만 이러한 고민을 보게 되다 보니 그런 것일 수도 있지만 개발자들이 질문하는 고민은 유독 “개발 실력”이라는 것에 국한되어 있어 보인다. “개발을 잘하려면 어떻게 해야 할까요?”, “좋은 개발자가 되려면 어떻게 해야 할까요?”, “어떻게 하면 코딩 실력을 키울 수 있을까요?” 등등 말이다.

하지만 나는 개발자도 결국 다른 직업과 마찬가지로 한 명의 직장인이라 생각한다. 직장인으로서 능력을 인정받으려면 “개발 실력” 뿐만 아니라 의사소통, 업무 우선순위 파악, 문제 인식, 작업에 대한 이해도 등 “일”을 잘하기 위해 고민을 하고 이를 위한 능력을 키우기 위해 노력을 해야 한다고 생각한다.

이 글을 최근 읽은 “일 잘하는 사람은 단순하게 말합니다” 책을 바탕으로 코드를 어떻게 작성하면 좋을지, 개발 실력을 어떻게 기르면 좋을지에 대해 이야기하는 것이 아닌 “일”을 잘하기 위한 여러 가지 방법들을 이 책에서 나온 일부 주제들을 바탕으로 이야기해 보고자 한다.

단순하고 명확하게 이야기 하세요.

프로젝트를 진행하다 보면 의사소통의 오류로 인해 곤욕을 치러본 개발자가 많을 것이다. 특히 요구사항이 복잡한 도메인의 경우 더욱 그런데, 보통 의사소통 주체 간의 이해도가 서로 다르기 때문에 전달하고자 하는 이야기를 단순하고 명확하게 말하지 않으면 서로 간의 오해로 인해 만들어진 기능이 고객이 원했던 바가 아니라서 전면적으로 갈아엎거나 제품 품질이 현격히 떨어지는 등 비싼 비용을 치러야 할 수도 있다.

사람은 누구나 자신만의 필터(해석, 기억, 판단)를 가지고 있으며 골치 아픈 생각은 피하는 경향을 가진다. 또한 확실한 것보다 모호하고 복잡하게 말하는 것을 선호하기 때문에 의도적으로 단순하고 명확하게 이야기하려는 노력을 기울이는 것이 좋다.

사례)

Q: 개발일정이 얼마나 걸리나요?

A: 약 5일 정도 예상됩니다. (단순/명확)

A: 꽤 걸립니다. (복잡/모호)

문제는 해결책과 함께 얘기하는 겁니다.

프로젝트를 진행하면서 개발 초기에는 생각하지도 못한 설계적 결함을 발견하거나 의사소통의 오류를 나중에야 발견하는 등 여러 가지 문제를 겪게 된다. 이러한 문제가 발생했을 때 앞서 말한 것처럼 단순하고 명료하게 현상을 이야기하는 것도 중요하지만 여러분이 생각하고 있는 해결책을 제시하는 것 또한 일을 잘하는 방법의 하나이다.

사례) 해결책이 제시되지 않은 문제 제기

개발자: PM님. 주문서를 수정하는 기능에 문제가 있습니다.

PM: 아 그래요? 어떤 문제가 있는데요?

개발자: 동일한 주문서를 동시에 여러 사람이 수정하면 주문서가 원치 않게 수정될 수 있어서요. 주문서 수정 기능을 넣으면 안 될 거 같아요.

PM: 아…. 주문서 수정 기능은 꼭 필요한 기능인데요. 다른 방법은 없을까요?

개발자: ….

M: 이거 프로젝트 회의 때 다시 한번 이야기해 보시죠.

위 사례를 보면 개발자가 문제는 제기했지만, 해결책은 제시하지 않아 의사소통 비용이 증가하는 전형적인 사례를 보여준다. 사례에서는 개발자와 PM 간의 관계에서 이야기되었지만, 만약 개발자와 팀장 혹은 그 외 상급자와 이야기하는 상황이었다면 어떻게 되었을까? 아마 상급자는 가뜩이나 바쁜 업무 중에 그 개발자가 가지고 온 문제를 고민해야 해서 더욱더 골치아파 할 것이다. 아마 해당 개발자에게 좋은 평가를 주기엔 어려울 것이다.

반대 사례를 살펴보자

사례) 해결책이 제시된 문제 제기

개발자: PM님. 동일한 주문서를 동시에 여러 사람이 수정하면 주문서가 원치 않게 수정될 수 있는 이슈가 있습니다. 해결 방법은 여러 가지가 있겠지만 일단 제가 생각하는 가장 손쉽게 해결할 방법은 낙관적 잠금을 이용해서 여러 사용자가 동시에 주문서를 수정하는 경우 사용자가 인지할 수 있도록 하는 것입니다. 다만, 이렇게 조치하면 동시에 주문서가 수정될 때 특정 사용자는 수정하지 못하는 불편함이 생길 수 있습니다.

PM: 아 그래요? 그럼, 일단 그렇게 조치해 주세요. 동시에 주문서를 수정하는 경우가 많지 않으니 그 정도 불편함은 감수할 수 있을 거 같아요.

문제를 제기할 때 상대방이 불편해하는 이유는 문제 상황만 전달하기 때문이다. 문제 해결의 책임을 상대방에게 떠넘긴 격이 되어버렸기 때문이다. 꼭 정답이 아니어도 되니 문제 해결에 대한 노력이라도 보여주는 것은 일 잘하는 개발자가 되려는 방법의 하나이다.

복잡할수록 단순하게 쪼개주면 쉬워집니다.

리펙터링 기법 중에 단계 쪼개기(Split Phase)라는 기법이 있다. 하나의 큰 함수를 작업 단계별로 작은 함수로 분리해서 추출하는 리펙터링 기법인데 단순히 하나의 큰 함수 내 코드를 작은 함수들로 나누다 보면 코드 조각들의 역할이 분명해지고 문맥이 명확해지다 보니 코드 읽기가 쉬워지고 복잡한 논리가 단순해져 이해하기 쉬워지는 효과를 누릴 수 있다.

업무도 이와 같은 방법을 적용할 수 있다. 복잡하고 큰 기능을 개발하는 프로젝트를 진행할 때, 개발한 복잡한 기능을 설명할 때 등등 크고 복잡한 것들은 작은 단위로 나누고 묶어주면 훨씬 이해하기 쉽게 진행할 수 있게 된다.

먼저 복잡하고 큰 기능을 개발할 때 예를 들어보자. 복잡하고 큰 기능을 개발할 때는 우리가 흔히 말하는 역할별로 도메인을 나누는 것이 중요하다. 각각의 도메인이 역할과 책임이 명확하다면 아무리 기능이 얽히고설켜 있더라도 손쉽게 풀어낼 수 있는 실마리를 찾아낼 수 있기 때문이다. 그리고 세세하게 구현을 이야기하기 전에 추상화된 모듈끼리 어떻게 상호작용하고 데이터를 주고받을지 논의한 후 구현에 대해 고민한다면 구체적인 구현에 매몰된 나머지 나무는 보고 숲을 보지 못하는 상황은 피할 수 있다.

업무 프로세스 또한 마찬가지이다. 세세한 작업 단위부터 신경 쓰기 시작하면 어디서부터 시작해야 할지 막막하기 마련이다. 그래서 세세하게 작업 단위를 신경 쓰기보다 작업을 모아 그룹으로 나누고 각 그룹의 우선순위를 정하면서 단계별로 어떤 순서로 처리할지 나누다 보면 크고 복잡한 작업 프로세스가 한결 단순하게 보이기 시작할 것이다.

이렇듯 개발과 마찬가지로 업무를 진행하는 데 크고 복잡한 것들을 단순화하고 적절하게 우선순위를 선정하는 능력을 기르는 것이 일 잘하는 방법의 하나이다.

간접적이고 비언어적인 표현은 해석하기 어렵습니다.

책에서는 세대 간의 문화 충돌이 발생하는 이유는 고맥락 문화와 저맥락 문화의 충돌로 인해 발생한다고 한다. 고맥락 문화는 사무실이 더울 때 손으로 부채질하며 “여기 너무 덥지 않나요?”와 같이 말하는 것처럼 말 자체뿐만 아니라 전후 맥락, 분위기, 의도 등과 같이 간접적이고 비언어적 표현을 많이 사용하는 반면 저맥락 문화는 “지금 너무 더우니 에어컨 좀 틀어주세요”와 같이 직접적이고 언어적인 표현을 사용한다.

친한 지인들과 농담을 주고받거나 사적인 이야기를 할 때에는 고 맥락 문화와 같이 비언어적이고 간접적인 표현이 서로 간의 배려 또는 유머 있는 표현으로 더 좋은 관계 유지에 도움이 될 수 있겠지만 업무를 수행함에 있어서는 오히려 사람마다 각자 다른 해석으로 인해 의사소통 비용이 증가하는 결과를 초래할 수도 있다.

사례) 간접적이고 비언어적인 표현

개발자 A: (곤란한 표정을 지으며) 아…이번에 이슈가 많아서 제 시간 안에 프로젝트를 마무리 지을 수가 없네요… 아무래도 밤을 새워야겠어요.

개발자 B: …

사례) 직접적이고 언어적인 표현

개발자 A: 개발자 B 님 제가 아무래도 이번에 이슈가 많아 프로젝트를 제시간 안에 마무리 지을 수 없을 것 같은데요. TASK-1과 TASK-2만 좀 도와주실 수 있으신가요? 다음에 개발자 B 님이 바쁘실 때 제가 꼭 도와드리겠습니다.

개발자 B: 네. 작업 내용 알려주시면 도와드리겠습니다.

업무 요청은 디테일하게, 이게 매너입니다.

다른 직군과 마찬가지로 개발자도 같은 팀 혹은 다른 팀의 개발자와 협업을 위해 업무 요청을 해야 하는 경우가 비일비재하다. 큰 회사나 메일로 주로 의사소통하는 회사와 달리 Slack과 같은 메신저를 사용하는 회사에서는 아무래도 업무 요청 시 요청 사항을 부족하게 전달하고 진행하는 경우가 많이 발생한다.

사례)

개발자 A: 개발자 B 님, 이번에 저희 정산 API에 요청 매개변수 하나가 추가되어서요. 정산 API 호출하실 때 transactionId를 함께 보내주세요.

개발자 B: 네? 정산 API 중 어떤 API를 말씀하시는 걸까요? transactionId 매개변수는 필수값일까요? 어떤 상황에 필요해서 해당 매개변수를 보내게 된 걸까요?

개발자 A: 아. 정산 저장 API에요. 거래별로 정산 데이터를 묶어서 보여주려고 하는데 해당 매개변수가 있으면 좋아서요.

개발자 B: 저희가 transactionId가 존재하는 경우도 있고 존재하지 않는 경우도 있어서요. 필수로 전달해야 하는 값일까요?

개발자 A: 필수값은 아니에요. 그래도 거래별로 묶어서 정산데이터를 보여주면 장점이 많아서 보내주시면 좋을 것 같아요.

최근 많은 IT 회사에서 의사소통 수단으로 Slack과 같은 메신저를 적극 활용하고 있다. Slack에서 제공해 주는 수많은 통합(Integration)기능과 자동화 기능은 우리들의 업무 효율성을 크게 향상해 주었다. 다만, 이러한 장점과 함께 수많은 부작용도 초래했는데 그중 하나가 바로 위에서 보여준 사례와 같이 휘발성 높은 업무 요청과 부족한 요청 사항이다.

업무 요청은 같은 팀이어도 마찬가지이지만 다른 팀이라면 더더욱 풍부한 요청사항과 함께 휘발되지 않는 방식으로 업무 요청을 하는 것이 좋다. 이메일도 좋지만, 회사에서 JIRA와 같이 작업관리 도구를 적극 활용하고 있다면 이러한 도구를 활용해서 업무를 요청하는 습관을 들이자.

사례)

개발자 A: 개발자 B 님, 이번에 저희 정산 API에 요청 매개변수 하나가 추가되었는데요. 이에 아래와 같이 업무 요청을 드리고자 합니다. 자세한 사항은 작업 본문란을 참고해 주시기를 바랍니다. 혹시 궁금한 사항이 있다면 말씀해 주세요.

제목: 정산 저장 API에 'transactionId' 매개변수 추가 요청 건

내용:

1. 취지 및 목적
최근 정산팀에서 거래별로 정산데이터를 묶어서 보여주면 고객에게 좀 더 명확하게 정산데이터를 보여줄 수 있을 것이라는 가설을 기반으로 프로젝트를 진행하고 있습니다.
그래서 현재 정산 저장 API를 사용하고 있는 모든 부서에서 'transactionId'를 수집해야 할 필요성이 생겼습니다.

2. 요청 사항
현재 사용하고 있는 정산 저장 API에 아래와 같이 매개변숫값을 추가해서 보내주시기를 바랍니다.

매개변수명: transactionId
타입: String
필수값 여부: N
길이 제한: 255 byte

3. 기한
우리 팀에서 이번에 새롭게 변경되는 정산 저장 API를 10월 1일에 배포할 예정입니다.
이후 유관부서에서 변경된 API로 변경하는 작업을 한 달 정도면 진행할 수 수 있을 것으로 판단하여 10월 31일까지 변경 작업을 진행해 주시기 바랍니다.
그렇다면 우리 팀에서는 11월 1일부터 거래별로 정산데이터를 묶어서 보여줄 수 있다고 판단하여 대시보드를 제공할 수 있도록 조치할 수 있을 것입니다.

개발자 B: 네 알겠습니다. 내용 보고 궁금한 점 있으면 댓글로 남겨두겠습니다.

상대방을 바꾸려 하지말고 같은 편에 섭니다.

우리는 보통 설득하는 상대방을 다른 편처럼 대하곤 한다. 개발자가 코드의 품질을 위해 촉박한 개발 일정을 늘려달라고 말하는 과정에서 보면 촉박한 일정을 독려하는 팀장이나 PM이 마치 개발자의 고충을 이해하지 못하고 자신들의 성과를 위해 개발자를 희생시키는 사람처럼 생각하는 경우가 있다.

사례) 상대방을 다른 편처럼 대하는 경우

개발자: PM님 개발 일정이 너무 촉박해요.

PM: 개발자님 미안해요. 위에서 지시한 사항이라 어쩔 수가 없어요. 이번에 출시하는 기능이 경쟁사보다 빠르게 출시하려면 어쩔 수가 없네요.

개발자: 촉박한 거였으면 기획 단계에서부터 빠르게 진행했으면 좋았을 것 같아요. 이렇게 급하게 개발하면 코드 품질이 좋을 수가 없어요. 계속 이런 식으로 개발하면 저는 너무 힘들 거 같아요.

PM: …

하지만 설사 그런 감정이 들더라도 상대방을 설득하기 위해서는 상대방과 같은 편이 되어야 한다. 해결 방법이 딱히 없는 상황에서 얼굴을 붉혀봤자 서로에게 좋은 것은 없을 것이기 때문이다. 코드 품질의 향상이 개발자인 나에게 이득이 되는 것만이 아니라 코드 품질의 향상이 곧 제품의 품질로 이어지고 장애 및 버그 빈도를 낮춰 주므로 제품에 대한 고객 신뢰도가 높아질 수 있음을 어필하는 것이 좋다.

사례) 상대방을 같은 편으로 대하는 경우

개발자: PM님. 목표 제품 출시일이 정해졌다고 들었어요. 제품 출시 준비로 바쁘시죠?

PM: 네… 개발자님 미안해요. 개발 일정이 촉박하시죠? 위에서 지시한 사항이라 어쩔 수가 없네요. 경쟁사보다 기능을 빠르게 출시하려다 보니 어쩔 수 없이 목표 일이 촉박하게 잡혔네요.

개발자: 솔직히 촉박하긴 합니다. 잘 아시겠지만 바쁘게 코드를 작성하다 보면 코드 품질이 떨어지게 되고 코드 품질이 떨어지면 결국 제품에까지 영향이 가니까요… 이번에는 결정된 사항이니 어쩔 수 없지만 프로젝트가 끝나고 나면 코드 정리할 시간을 조금 내어줄 수 있을까요? 코드 품질이 좋아지면 제품의 품질도 향상될 테니 모두에게도 좋은 영향을 미칠 거라 생각돼요.

PM: 네 물론이죠. 잘 부탁드릴게요.

모든 주장에는 근거가 있어야 합니다.

상대방을 설득하려면 명확한 근거가 있으면 좋다는 말은 너무나 당연한 이야기이다. 하지만 새로운 제품을 만들기 위한 의견 수렴 회의에서 혹은 디자인 리뷰나 코드 리뷰에서 자신이 원하는 바를 주장할 때 명확한 근거를 제시하지 않고 고집스럽게 자기주장을 내세우는 경우를 종종 볼 수 있다.

사례) 근거가 없는 주장

팀원1: 이번에 상품 이미지를 표시하는 영역을 왼쪽에서 오른쪽으로 변경하는 게 좋겠습니다.

팀원2: 저는 왼쪽이 더 좋아 보이는데요. 왜 오른쪽으로 변경하게 된 거죠?

팀원1: 오른쪽으로 변경하는 게 시선 처리도 좋고, 편리해서입니다.

팀원2: 왼쪽은 어떤 점이 불편했을까요?

팀원1: 그렇다는 의견이 많았어요.

팀원2: 혹시 어떤 분들이 불편하다고 하였을까요? 고객 설문조사가 있었나요?

팀원1: 아뇨. 그런 건 아닌데 요즘 디자인 추세상 왼쪽보다 오른쪽이 좋기도 하고…

위와 같은 주장을 보면 답답하기까지 하다. 명확한 근거도 없이 자신의 주장만 반복적으로 내세우기 때문이다. 이런 식의 논의는 생산적으로 진행되기도 어렵다. 회의 참가자들은 금방 회의 주제에 흥미를 잃어버리고 집중력을 다른 곳에 두게 되고 결국 그 논의는 목소리 큰 사람(?)의 주장으로 결정될 가능성이 높다.

사례) 근거있는 주장

개발자1: 개발자2님 이번에 올려주신 Pull Request에서요. 하나의 클래스가 너무 많은 책임을 지고 있는 것 같아서요. 책임을 여러 개로 나누는 게 좋아 보이는데 어떠세요?

개발자2: 제가 생각하기에는 클래스가 조금 크기는 하지만 하나로 두면 코드가 여기저기 흩어지지 않아 좋을 것으로 생각합니다.

개발자1: 단일 책임 원칙을 보면 하나의 클래스는 하나의 책임을 지는 것이 좋다고 하는데요. 저는 그러한 관점에서 보면 해당 클래스는 하나 이상의 책임을 지고 있다고 생각이 들어서요.

개발자2: 저는 응집도를 중요하게 생각했어요. 비록 책임이 크다고 할 수 있지만 각각의 기능이 서로 연관된 책임을 지기 때문에 …

개발자들은 특히 코드 리뷰에서 서로 간에 주장이 다른 경우가 많이 발생한다. 각자가 주장을 펼칠 때는 그 주장에 대한 명확한 근거와 출처를 밝히는 게 건강한 리뷰 문화를 조성하는 원동력이 된다.

모르는 걸 솔직히 말하면 더 매력적입니다.

나도 그렇지만 개발자 입장에서 자신의 전문 분야를 모른다고 말하는 것은 쉽지 않다. 개발자뿐만일까? 많은 사람들이 ‘모른다’라는 말을 하기 싫어한다고 한다. 무책임하거나 바보 같아 보일까 바여서라고 한다. 조심해야 하는 점은 앞서 말한 것처럼 단순하고 명료하게 자기가 모르는 것을 모른다고 이야기하지 않는다면 의사소통에 큰 문제를 일으킬 수 있다는 것이다.

사례) 솔직하지 못한 대답

PM: 개발자님 이번에 변경한 주문 수정 기능에서요. 주문 품목이 하나도 없는 경우 어떻게 동작하나요?

개발자: (정확히 기억나지 않음) 음…그거 그냥 주문 수정은 되지만 아무 일도 일어나지 않을걸요?

PM: (며칠 뒤) 개발자님…. 그때 주문 품목이 하나도 없는 경우 주문수정에 아무 일도 일어나지 않는다고 말씀해 주셔서 해당 기능을 바탕으로 기획했었는데요. 확인해 보니 주문 품목이 존재하지 않으면 오류가 발생하도록 처리되어 있어서 기획을 전면적으로 수정해야 할 것 같아요.

개발자: 아…죄송합니다.

그렇다면 과연 사람들은 ‘모른다’라는 대답을 싫어할까? 아니다. 사람들이 싫어하는 것은 ‘모른다’가 아니라 ‘무책임함’이다. 모르는 것은 죄가 아니라 생각한다. 전문 분야라도 누구나 모르는 것이 있을 수 있다. 여기서 일을 잘하는 사람과 그렇지 않은 사람의 차이는 자기가 모르는 것에 끝나지 않고 다음 행동을 취하느냐 아니냐의 차이이다.

사례) 무책임한 대답

PM: 개발자님 이번에 변경한 주문 수정 기능에서요. 주문 품목이 하나도 없는 경우 어떻게 동작하나요?

개발자: 음… 저도 잘 모르겠네요.

PM: 모르시나요? 이번에 개발자님이 프로젝트에 참가하신 거로 아는데요.

사례) 책임있는 대답

PM: 개발자님 이번에 변경한 주문 수정 기능에서요. 주문 품목이 하나도 없는 경우 어떻게 동작하나요?

개발자: 음… 정확하게 잘 모르겠네요. 코드 한번 봐야 할 거 같은데요. 코드 한번 확인해 보고 말씀드릴게요. 10분 안에 답변드릴게요.

협상을 겁내지 마세요, 대부분 가능합니다.

일을 하다 보면 요구사항이 터무니없거나 기존 구현 설계상 좋지 않은 방향으로 가는 경우라도 별다른 조율 없이 무조건 수용하는 개발자(혹은 팀장, PM)를 만나곤 한다. 이런 경우 상당히 곤란한 상황이 펼쳐지고는 하는데 본인이 해당 요구사항을 개발하는 경우라면 그나마 다행인데, 본인이 해당 요구사항을 개발하지 않거나 개발하다가 다른 개발자에게 도움을 요청하거나 도망치는 경우이다. 요구사항을 전달한 상대방 입장에서는 이미 수용하였으니 당연히 해당 요구사항이 충족될 것이라 기대하고 있는데 개발자들은 억지스러운 구현으로 요구사항을 구현해 내거나 도저히 구현 방법을 떠올리지 못해 고객에게 사과해야 하는 상황이 펼쳐지기도 한다.

만약 사건의 당사자가 퇴사하고 없다면 어쩔 수 없겠지만 계속해서 같은 팀원으로 있는 상황이라면 신뢰는 이미 바닥에 있을 가능성이 크고 앞으로 함께 일하려고 하지 않을 가능성이 크다. 여러분이 이런 사람이 되지 않으려면 터무니없는 요구사항을 무조건 수용할 게 아니라 가능한 부분과 불가능한 부분을 잘 타협하는 협상 능력을 키워야 한다. 무조건 수용하면은 안 되지만 반대로 무조건 수용하지 않는 것 또한 협업에서는 좋지 않은 방법이다. 대신에 현재 자신의 상황을 솔직하고 설명하고 상대방의 요구를 수용할 수 있는 제3안을 제시해 보는 것이 방법이다.

사례) 무조건 승락

PM: 전자금융법 개정으로 인해 정산 방식을 새로운 방식으로 변경해야 합니다. PG사의 지급 대행 서비스를 이용해서 정산금을 지급하면 될 거 같은데요. 자세한 내용은 문서를 참고해 주세요. 법 시행 일정으로 인해 이번 주 내에 개발을 완료해야 합니다.

개발자: 개발 일정이 너무 촉박한데요…일단 해보겠습니다.

사례) 협상

PM: 전자금융법 개정으로 인해 정산 방식을 새로운 방식으로 변경해야 합니다. PG사의 지급 대행 서비스를 이용해서 정산금을 지급하면 될 거 같은데요. 자세한 내용은 문서를 참고해 주세요. 법 시행 일정으로 인해 이번 주 내에 개발을 완료해야 합니다.

개발자: 개발 일정이 너무 촉박해서요. 일단 그러면 PG사의 지급 대행 서비스 API를 연동하기보다 수동으로 지급 대행 서비스를 이용할 수 있도록 먼저 조치한 다음에 API 연동은 나중에 진행하는 방법은 어떨까요? 재무팀에서 조금 수고스럽겠지만 고객사에 정산금 지급도 원활하게 수행할 수 있고 전자금융법도 위반하지 않고 정산을 진행할 수 있을 것 같습니다. 무엇보다 수동으로 지급 대행 서비스를 이용할 수 있도록 하는 방법은 API 연동방식보다는 손쉽게 개발할 수 있을 것 같아서 무리하게 개발하지 않을 수 있고요.

위와 같이 협상하면 대부분의 경우 개발자의 의견을 수용한다. 그래서 개발자는 앞선 사례와 비교해서 결과는 비슷한데 초과 근무를 하지 않아도 되니 덜 고생하고 상대방이 원하는 바를 충족해 준 결과를 얻게 되는 것이다.

거절할까 봐 겁나서 혹은 말주변이 없어서와 같은 이유로 협상해야 하는 상황에서 협상을 시도하는 것을 꺼리지 말자. 오히려 무리한 부탁을 들어줘서 결과물이 좋지 않은 것보다 적절한 협상을 통해 원만하게 문제를 해결하는 것이 일을 잘하는 방법이다.

마무리

지금까지 “일 잘하는 사람은 단순하게 말합니다” 책 내용을 기반으로 개발자가 일 잘하는 방법에 관해 이야기해 보았다. 이 글에서는 9가지 내용만 다루었는데 책에는 일을 잘하기 위한 더 많은 조언이 있으니, 일을 잘하는 방법이 궁금하다면 꼭 읽어보면 좋겠다.

사실 일을 잘하는 데 있어서 정답은 없다고 생각한다. 회사마다 다르고 팀마다 다르고 상황, 문화마다 다르기 때문에 위에 이야기한 내용들이 무조건 일을 잘할 수 있는 정답이 될 순 없다고 생각한다. 하지만 적어도 좀 더 일을 잘할 수 있기 위한 가이드라고 생각해 주면 좋을 것 같다.