얼핏보면 개발자는 각자 컴퓨터랑만 일하는거 같아 보인다. 하지만 보이지 않는 팀워크가 조직의 실행력 뿐 아니라 코드 품질과 개인의 성장까지도 결정한다. 여러 팀을 거치며 동료를 다양하게 많이 만날수록 팀 스포츠를 하고 있다는 생각을 한다. 똑같은 프론트엔드 개발자라 하더라도 누군가는 손이 빠르고, 누군가는 설계를 잘하고, 누군가는 UI를 매우 잘 만들고, 누군가는 멘토링을 잘하고, 누군가는 분위기 메이커 역할을 잘하는 등 여러 포지션을 나눠 가지고 있다. 그리고 의사결정을 할 때도 기술적으로 딱 떨어져서 만장일치가 되는건 환상에 가깝다. 팀이 처한 상황에 따라, 경험이나 능력에 따라, 또는 누군가의 영향력에 따라 유동적이다. 같은 문제라도 팀마다 다른 해결책을 도출해낸다.

그래서 중요한게 팀워크인거 같다. 문제 상황이 닥쳐도 유연하게 대처하고 빨리 회복하게 해주는 원동력이다. 그리고 팀워크의 기초는 안전감과 신뢰라고 생각한다.

개인을 탓하지 않는 분위기

문제가 발생했을때 일을 맡았던 담당자나 문제 코드를 작성한 개발자를 탓하는건 쉽다. 하지만 이건 심리적 안전감을 해치는 정말 나쁜 문화다. 게다가 개인의 잘못이나 실수라고 여기고 끝내면 그 팀은 똑같은 유형의 문제를 나중에 또 겪을거다. 문제 자체보다는 ‘누가’ 일으켰는지만 기억에 남기 때문이다. 문제와 사람을 분리하지 않고 문제 자체를 더 깊게 파고 들어가보지 않았을 것이다. 그러면 팀원들은 이번엔 나만 아니길 바라며 조마조마한다.

예전 조직장님은 문제를 수습한 이후에 꼭 팀을 모아놓고 이렇게 말하셨다. “문제를 피하고 싶으면 아무것도 안하면 된다. 레거시도 잘 돌아가니까 그냥 두고 새로운 도전도 하지 말고. 그런데 우리는 그러면 안된다. 계속 발전하고 성장해야 한다. 문제를 겪었으면 재발 방지책을 철저히 세우고 또 도전하면 된다”고 독려했다.

예전 매니저도 문제 발생 상황시 팀 전체가 모여 해결책을 논의하는 자리는 언제나 이런 말로 회의를 열었다. “누구를 탓하고 추궁하려고 모인게 아니다. 여기 있는 누구라도 이런 실수를 할 수 있었고 그렇기 때문에 앞으로 똑같은 실수를 우리 팀에서 원천 차단할 수 있는 해결책을 마련하기 위해 모인 미팅이다.”

자신이 문제를 일으켰다는게 밝혀지면 사람은 본능적으로 자신을 방어하게 된다. 다른 사람이 하는 말들이 자신과 자신의 능력에 대한 비판으로 들린다. 그래서 리더가 더 적극적으로 이런 분위기를 만들어서 문제와 사람을 분리하게끔 유도하면, 개인은 안전감을 느끼고 이걸 토대로 팀 차원에서 문제를 해결하고 방지책을 세울 수 있다.

머리로 하는 회고

문제와 사람을 분리하고나서 하는 냉철한 회고는 성장통과 같다. 당사자 입장에서는 부끄럽고 곤욕스러울 수 있으나 자신의 인격에 화살이 향하는게 아니라는 안전감이 있으므로 문제 해결과 재발 방지를 위해 무슨 일이 있었는지 투명하게 공개해서 팀이 함께 대처하고 회복할 기회를 얻을 수 있다.

그랩에서는 핫픽스를 하게 되면 몇 주 내로 공개적인 회고를 한다. 회고에 앞서 미리 사후 보고서를 양식에 맞게 채워놓아야 한다. 문제 조치한 시각표, 사고의 영향, 원인, 방지 대책 등 최대한 구체적이고 자세히 적는다. 그리고 1시간의 회고 시간 동안 개발자 수십명이 모여 날카로운 질문을 던지고 해결책을 제안을 하며 집단 지성을 발휘한다. 얼버무리면서 넘어갈 틈은 없다.

처음 참석했을 때는 제 3자가 들어도 살벌하다고 느낄 정도로 직설적이어서 흠칫하기도 했다. 하지만 계속 듣다보니 모두가 한 마음으로 모였다는 걸 알 수 있었다. 청문회가 아니라 작전 회의인거다. 최대한 감정을 빼고 차갑게 회고를 하면 함께 성장할 수 있다.

같이 성장하려는 자세

오랜 멘토님은 프로그래밍 실력을 언급할 때마다 개인이 아니라 팀을 주어로 놓고 말씀할 때가 많았다. 전체적인 코드의 품질이나 코드 리뷰의 수준은 가장 잘하는 개발자가 아니라 팀의 평균 실력을 따라간다는 것이다. 그래서 우리가 문제를 더 잘 해결하려면 누군가 혼자만 잘해서는 안되고 팀원 전체가 같이 성장해야 한다. 스터디를 지속적으로 만들고, 또 열심히 참여해서 지식을 나누는 개발자들은 이걸 아는게 틀림없다.

아주 가끔씩 그런 개발자가 있다. 새로운 팀에 오자마자 레거시의 잘못된 부분을 죄다 지적하고, 본인의 기준에만 맞춰 코드 리뷰를 하면서 기존 팀원들을 깎아 내린다. 레거시란 어제까지는 최선의 선택이었다는 말이 있다. 자신이 새롭게 기여할 점이 보인다면 팀원들을 설득하고 지식을 전파해서 팀의 평균을 끌어 올리는게 맞다고 생각한다. 자신과 팀을 분리해서 생각하면 양쪽 모두에게 이로운게 없다.

사람들은 혼자 돋보이려는 사람과 진심으로 팀을 위해 헌신하는 사람을 아주 잘 구분할 수 있다. 선의와 친절로 서로를 대하는 사람들 사이에는 신뢰가 생기고, 반면에 혼자만 잘하려고 하는 사람은 팀워크를 해친다. 그래서 어떤 선배 개발자는 채용할 때 인성이 제일 중요하다고 말하고, 어떤 유명 코치는 개인의 능력이 아니라 그 사람의 태도를 보고 채용해야 한다고 말하는 것 같다.

At a glance, each developer seems to be working with a computer. But there is an invisible teamwork that decides not only the organization’s executive force but also code quality and personal growth. As I go through many teams and meet various colleagues, I think I’m playing a team sport. Even if they’re the same front-end developers they play different roles. Someone has fast hands, someone makes good design, someone is very good at making UI, someone is a good mentor, and someone acts as a mood maker. Even when making decisions, it’s almost like a fantasy to have everyone technically agree on something. Depending on the team’s situation, experience, capability, or someone’s influence, it is subject to change. Given the same problem, every team comes up with different solutions.

I think that’s why teamwork is important. It is the driving force to respond with flexibility and recover quickly even during a problem. I believe the basis of teamwork is a sense of security and trust.

An Environment Where an Individual is not Blamed

When there’s a problem, it’s easy to blame someone who was in charge of the work or the developer who wrote the code. But this is a very bad culture that hurts psychological safety. Moreover, if you end up thinking that it’s an individual’s fault or mistake, the team will experience the same problem again in the future because they’ll only remember ‘who’ caused the problem, and not the problem itself. They wouldn’t separate the problem from the person and wouldn’t go deeper into the problem itself. Then the team members will get anxious hoping that they won’t become the next target.

After solving a problem, the former head of the organization always said this to encourage us, “Don’t do anything if you want to avoid the problem. Legacy works well, so just leave it be and do not engage in new challenges. But we shouldn’t do that. We must continue to grow. If you have a problem, you can come up with measures to prevent it from happening again and try again.”

My former manager also started meetings where the whole team gathered to discuss solutions for a problem by saying, “We are not meeting to blame anyone and question them. Anyone here could have made this mistake and that’s why we’re meeting to come up with a solution to prevent the same mistake from happening again in our team.”

When it gets revealed that someone was the cause of the problem, that person will defend himself by instinct. What other people say about him will sound like criticism toward him and his abilities. So if a leader creates an atmosphere where the problem gets separated from the person, an individual will feel a sense of security, and the team will be able to solve the problem and establish preventive measures based on this.

A Retrospective Done with Your Head

A cool-headed retrospective done after separating the problem from the person is just like growing pains. It may be embarrassing from that person’s perspective, but there is a sense of security that the arrow is not directed at himself, so there’s a chance for the team to deal with the problem together and recover by transparently disclosing what has happened to solve the problem and to prevent it from happening again.

In Grab, an open retrospective is done in a few weeks after a hotfix. A post-report needs to be filled out in advance before the retrospective. It needs to include the time the problem was dealt with, the impact of the accident, the cause, and preventive measures with as much detail as possible. During the one-hour retrospective, dozens of developers gather around and ask each other sharp questions and suggest solutions, and display collective intelligence. There is no room for equivocation.

When I attended the retrospective for the first time, it was so straightforward that even someone who isn’t related to the incident would feel it was brutal. But as I kept on listening, I could see that everyone was there with the same purpose. This is not a hearing, but a strategy meeting. If you take out your emotions and retrospect with a cool head, you can grow together.

The Attitude to Grow Together

Whenever my old mentor talked about programming skills, many times he would speak with the word ‘team’ as the subject instead of an individual. The overall code quality or the level of code review follows the team’s average level of skill rather than the best developer in the team. So in order to better solve the problem, not only does one person need to be good, but the whole team needs to grow together. Developers who constantly hold study sessions and are eager to participate in them to share their knowledge must know this.

Rarely, there is a developer like this. As soon as he joins a team, he would point out all the wrong parts of the legacy, do code reviews only based on his own standards and criticize the other team members. There is a saying that legacy was the best option until yesterday. If you see something you can contribute to the team, I think it’s right for you to persuade your teammates and spread your knowledge to raise the team’s average. If you separate yourself from the team, nothing will be beneficial for both sides.

People can very well distinguish someone who wants to stand out alone from someone who is truly dedicated to the team. There is trust between people who treat each other with good intentions and kindness, while someone who wants to do things well alone harms teamwork. That’s why a senior developer once said that character is the most important thing he sees when hiring someone, and a famous coach once said that you should hire someone not based on their abilities, but based on their attitude.

UITableView는 당연히 사용할 줄 알아야 하는 필수적인 클래스인만큼 잘못 사용되는 경우도 잦은 클래스다. 컨텐츠가 화면에 다 담기지 않아 스크롤이 발생하는 레이아웃을 만들어야할 때 별 고민없이 테이블뷰가 사용되는 상황을 많이 봤다. 심지어 스크롤이 발생하지 않더라도 단지 같은 뷰가 여러번 반복된다는 이유로 테이블뷰를 사용하기도 한다. 하지만 테이블뷰를 사용하기로 쉽게 결정하기 전에, 정말 뷰를 재사용하는 컴포넌트가 필요한지 짚어봐야 한다.

테이블뷰의 장점: 구조화된 데이터 표현 및 메모리 효율

테이블뷰는 데이터가 일관된 구조를 가지고 있고 계층화되어 있을 때 가장 유용하다. iOS의 설정 앱이나 연락처 앱이 대표적인 예시다. 내비게이션 뷰컨트롤러와 함께 사용하면 계층적인 구조를 정말 잘 나타낼 수 있다. 그리고 뷰(UITableViewCell)를 재사용하기 때문에 보여줘야 할 데이터가 수 백, 수 천 개여도 화면을 채울 만큼만 인스턴스가 만들어지기 때문에 데이터의 사이즈가 커도 메모리 걱정을 하지 않아도 된다.

테이블뷰의 단점: 복잡한 코드 + ⍺

프로그래밍과 관련된 거의 모든 결정에는 트레이드오프가 발생하는 거처럼, 테이블뷰도 뚜렷한 단점이 있다. 뷰 인스턴스를 재사용하는 장점을 얻는 대신 구조가 더 복잡해지고 코드가 길어지고 버그에 취약해진다.

UITableView를 설정해주고, UITableViewCell을 상속하고, DataSource와 Delegate를 구현해야 한다. 또한 셀 인스턴스가 재사용되면서 발생할 수 있는 이상한 동작을 방지하기 위해 추가되는 코드가 소소하지만 꽤 많다. 셀에 필요한 UI 데이터(이미지 등)를 비동기로 불러와야 경우, 외부의 사건(유저 액션 등)으로 인해 셀의 UI가 바뀌어야 하는 경우 등등에 추가적인 검사 로직을 넣어줘야 한다. 게다가 뷰의 레이아웃이나 크기를 동적으로 바꾸거나 애니메이션을 넣는 간단한 일도 테이블뷰가 연관되면 잘 안되고 귀찮아질 때가 많다.

테이블뷰 필요없는 경우 🔴

글의 시작 부분에서 언급한 오용이란 장점을 제대로 누리지 못하는 상황을 말한다. 대표적으로 셀이 재사용될 필요가 거의 없거나 재사용이 안되는 경우다. 테이블 열의 갯수가 적으면 메모리 걱정을 할 필요가 없다. 또한 테이블뷰의 열이 10개인데 10개가 다 다른 종류의 셀이라면 아무것도 재사용되지 않는다. 굳이 테이블뷰를 쓸 이유가 없다.

테이블뷰 필요한 경우 🟢

반대로 테이블뷰를 꼭 써야하는 경우는 데이터가 많을 때다. ‘많다’를 판별하는 절대 기준이 있는건 아니다. 하지만 너무 보수적으로 잡을 필요는 없다고 생각한다.

고민이 필요한 경우 🟠

개발하다보면 중간지대의 상황도 자주 맞닥뜨린다. 데이터는 적당히 많으면서 셀 종류도 두어개, 많게는 10개 정도. 유저 인터랙션도 있고 그에 따른 상태 변화와 UI 변화도 있는 경우. 그럴땐 뷰 재사용이 꼭 필요한지, 아니면 간단하고 안전한 코드가 더 이득일지 판단을 내려야 한다. 경험적으로 두 페이지가 넘어가지 않는 경우나, 필요한 뷰들을 한꺼번에 생성해도 메인쓰레드가 블락되지 않는 정도라면 간결한 코드의 장점이 더 크다.

대안: UIStackView + UIScrollView

뷰 재사용이 필수적인 요구사항이 아니라면 스택뷰 단독이나 스택뷰+스크롤뷰 조합을 이용해 훨씬 간결한 코드로 UI를 만들수 있다. 이 방식은 뷰를 직접 참조하여 들고 있을 수 있어서 언제든 간단하게 변화를 줄수도 있고, 테이블뷰처럼 의무적으로 호출해야 하는 메서드도 없어서 실수도 덜하고 디버깅도 쉽다.