acc 회고 내용 수정

Author: constmoon

src/content/blog/toss-acc-review.md

@@ -8,10 +8,10 @@ category: "blog"
 
 ## 신청 전
 
-13명의 프론트엔드 개발자와 일하던 커머스를 거쳐, 프론트엔드 개발자가 2명 뿐인 언론사에서 일하고 있다. 불행히도, 비슷한 연차의 프론트엔드 개발자 2인은 각각 담당하는 제품이 달라, 거의 1인 체제로 개발을 하게 되었다.
+13명의 프론트엔드 개발자와 일했던 커머스를 거쳐, 프론트엔드 개발자가 2명 뿐인 언론사에서 일하고 있다. 그마저도 비슷한 연차의 프론트엔드 개발자 2인은 각각 담당하는 제품이 달라, 거의 1인 체제로 개발을 하게 되었다.
 
-규모가 큰 조직에서 작은 조직으로 옮겨갔을 때 가장 크게 마주하는 문제는 바로 **의사결정**이었다.
-코드 리뷰를 진행해도 서로의 제품에 대한 이해도가 낮았고, 리뷰에 쏟는 시간이 많아질수록 리뷰의 우선순위가 낮아지고, 자연스레 LGTM(Looks Good To Me)으로 일을 하고 있었다.
+규모가 큰 조직에서 작은 조직으로 옮겨갔을 때 가장 크게 마주하는 문제는 바로 **의사결정**이다.
+코드 리뷰를 진행해도 서로의 제품에 대한 이해도가 낮았고, 리뷰에 쏟는 시간이 많아질수록 리뷰의 우선순위가 낮아졌다. 리뷰에 드는 비용이 늘어갈수록 LGTM(Looks Good To Me)으로 일을 하고 있었다.
 
 결국, 복잡한 문제를 마주했을 때 내 해결책에 대한 판단 기준조차 찾기가 어려워졌다. 인원이 많은 팀에서 근무했을 때는 시니어나 여러 동료들의 리뷰를 통해 고민이 해결되었지만, 소규모 주니어 팀에서는 서로 검증해줄 수 있는 경험이 부족해 내 해결법이 맞는지 확신하기가 어려웠다. 오픈소스 코드를 들여다보기도 했으나, 라이브러리마다 설계 패턴이 달라 무엇을 기준으로 선택해야 할지 고민만 커졌다.
 
@@ -28,7 +28,7 @@ category: "blog"
 - 디스코드에서 프리코스 참여자들과 피드백 주고 받기
 - 피드백을 통해 제출한 코드를 리팩토링하기
 
-과제 난이도는 평이했으나, 생각을 입 밖으로 내뱉는 것과 영상 속 내 모습을 받아들이는 게 제일 어려웠다. 평소 신중하다는 이야기를 듣지만, 이는 결국 고민의 시간이 길고 이를 드러내지 않는다는 뜻이기도 하다. 답답함으로 이어질 수 있는 이런 모습이 마음에 들지 않았고, 그래서 더 받아들이기 어려웠던 것 같다.
+과제 난이도는 어렵지 않았으나, 생각을 입 밖으로 내뱉는 것과 영상 속 내 모습을 받아들이는 건 무척이나 어려웠다. 평소 신중하다는 이야기를 듣지만, 이는 결국 고민의 시간이 길고 이를 드러내지 않는다는 뜻이기도 하다. 답답함으로 이어질 수 있는 이런 모습이 마음에 들지 않았고, 그래서 더 받아들이기 어려웠던 것 같다.
 
 이런 내 모습과 달리 다른 참가자들은 디스코드에서 활발하게 고민을 나눴다. 내가 한참 생각하는 사이 누군가는 이미 답을 내리거나 새로운 질문을 던지고 있었다. 리팩토링 횟수도 다른 참여자들에 비해 적었다. 프리코스 내내 뒤처지는 느낌이 들었고, 이번엔 안 되겠다는 생각이 자연스럽게 따라왔다.
 
@@ -38,23 +38,25 @@ category: "blog"
 
 ## 본코스
 
-불합격을 예상한 것과 다르게 감사히 합격을 하게되어 본코스를 듣게 되었다. 본코스라고 해서 프리코스에서 다룬 내용과 크게 다르지는 않았다. 두 코스 모두 ‘추상화 능력’을 기르는 법에 대해 다루었다.
+불합격을 예상한 것과 다르게 감사히 합격을 하게되어 본코스를 듣게 되었다. 본코스라고 해서 프리코스에서 다룬 내용과 크게 다르지는 않았다. 두 코스 모두 **추상화 능력을 기르는 방법**에 대해 다루었다.
 
 ### 추상화 — 사고
 
 코스에서 말하는 추상화는 아래와 같다.
 
 > 번잡한 세부사항(How)에 가려진 본질(What)을 드러내는 행위
 
-코스를 듣기 전, 추상화라고 하면 무작정 로직을 컴포넌트로 분리하는 방식을 생각했었다. 코드가 안 보이면 일단 정리된 것처럼 느껴졌기 때문이다. 하지만 그건 추상화가 아니라 은닉이었다. 나중에 그 파일을 열면 여전히 복잡했다.
+코스를 듣기 전, 추상화라고 하면 무작정 복잡해보이는 부분을 함수나 컴포넌트로 분리하는 방식을 생각했었다. 코드가 안 보이면 일단 정리된 것처럼 느껴졌기 때문이다. 하지만 그건 추상화가 아니라 은닉이었다. 나중에 그 파일을 열면 여전히 복잡했다.
 
-제대로 된 추상화는 순서가 달랐다. 먼저 코드를 펼쳐놓고, 사용하는 곳 근처로 옮기고, 요구사항의 언어로 이름을 붙이는 것. 화면을 기준으로 UI와 요구사항이라는 본질이 코드와 1:1 매칭이 되어야 한다는 기준이 생기고 나서야, 경계를 어디에 그어야 할지가 보이기 시작했다.
+이 습관이 드러난 건 페이지 컴포넌트를 작성할 때였다. 최상위에서 데이터를 한꺼번에 페칭하고 하위 컴포넌트로 내려보내는 식으로 코드를 작성했다. 데이터 선언은 파일 상단에 몰려 있고, 실제 사용은 한참 아래에 있었다. 정리된 것처럼 보였지만, 읽는 사람 입장에서는 선언과 사용 사이를 오가며 머릿속에서 연결해야 하는 코드였다.
+
+제대로 된 추상화는 순서가 달랐다. 먼저 코드를 펼쳐놓고, 데이터와 로직을 실제 사용되는 곳으로 옮겨 선언과 사용의 거리를 좁히고, 요구사항의 언어로 이름을 붙인다. 그렇게 완성된 코드가 UI와 요구사항이라는 본질과 1:1 매칭이 되어야 한다는 기준이 생기고 나서야, 경계를 어디에 그어야 할지가 보이기 시작했다.
 
 잘 된 추상화인지 확인하는 기준도 생겼다.
 
 - 함수나 변수의 이름이 약속을 지키는가?
 - 파일이나 함수로 나뉜 경계 바깥에서 안쪽을 몰라도 되는가?
-- 같은 레벨의 코드들이 비슷한 수준으로 말하고 있는가? (어느 한 쪽이 수다스럽지는 않은가?)
+- 같은 레벨의 코드들이 비슷한 수준으로 말하고 있는가? (어느 한 쪽만 수다스럽지는 않은가?)
 
 아직은 모든 상황마다 최적의 추상화를 한다고 할 수는 없지만, 적어도 어떤 부분에서 왜 이렇게 추상화를 했는지는 설명할 수 있게 되었다.
 
@@ -69,7 +71,7 @@ category: "blog"
 
 ### 페어 프로그래밍 — 관찰
 
-코드를 잘 작성하는 것만큼 중요한 게 있었다. 내 코드에서 무엇이 문제인지를 스스로 발견하는 것.
+코드를 잘 작성하는 것만큼 중요한 게 있었다. 내 코드에서 **무엇이 문제인지를 스스로 발견하는 것**.
 
 코스 동안 2인이 짝을 지어 페어 프로그래밍을 진행했다. 다만, 일반적인 페어 프로그래밍과는 달랐다. 구현자와 관찰자로 역할을 나눠, 구현자는 평소대로 코딩을 하고 관찰자는 코드가 아닌 사람을 본다. 어디서 막히는지, 어떤 패턴으로 문제에 접근하는지를 관찰하면서 병목을 발견하고 함께 해결 방법을 찾아가는 방식이다.
 
@@ -95,10 +97,6 @@ category: "blog"
 
 ## 코드만큼 중요한 사고 과정
 
-코스를 통해 배운 것을 한 문장으로 정리하면 이렇다.
-
-_"가고자 하는 방향을 정의하고, 병목을 찾고, 제거하는 것."_
-
 코스 이전의 나는 문제를 마주하면 해결책부터 찾았다. '왜 막히는지'보다 '어떻게 풀지'를 먼저 생각했다. 그러다 보니 같은 자리에서 맴도는 일이 많았다. 병목을 해결한 게 아니라 병목을 피해 간 것이었다. 내 해결책이 맞는지 확신할 수 없었던 이유도 거기 있었다.
 
 코스는 그 순서를 바꿨다. 먼저 멈추고, 지금 어디서 막혀있는지를 정의하는 것. 그게 추상화와 같은 원리였다. 복잡한 세부사항 뒤에 숨은 본질을 찾는 것. 코드에서는 세부 구현(How) 뒤에 숨은 본질(What)을 찾는 일이었고, 일상에서는 막히는 순간들 뒤에 숨은 패턴을 찾는 일이었다. 찾고 나면 가장 작은 단위로 쪼개서 움직일 수 있었다.