acc 회고 내용 수정

Author: constmoon

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

@@ -60,22 +60,14 @@ category: "blog"
 
 아직은 모든 상황마다 최적의 추상화를 한다고 할 수는 없지만, 적어도 어떤 부분에서 왜 이렇게 추상화를 했는지는 설명할 수 있게 되었다.
 
-**그렇다면 언제 추상화를 해야 할까?**
-
-코드를 보면 고치고 싶은 곳이 눈에 띄기 시작했다. 그런데 무작정 손을 대다 보면 기능 구현은 늦어지고 리팩토링은 끝이 없었다. 코스에서는 이 질문에 대한 답으로 FoM(Fundamentals of Modularization)을 제시한다.
-
-- **명확한 신호로부터 출발하는가?** 패턴이 발견되기 전에 섣불리 추상화부터 하려는 건 아닌가?
-- **결과에 기여하고 있는가?** "이 분리를 통해 무엇이 더 쉬워지는가"를 한 문장으로 설명할 수 없다면, 아직은 아니다.
-
-요리를 잘하는 사람은 중간중간 설거지를 하지만, 초보는 나중에 몰아서 하느라 주방이 복잡해지는 것과 같은 원리였다. 마찬가지로 리팩토링도 작은 단위로, 신호가 왔을 때, 결과에 기여하는 방향으로 진행해야 한다.
 
 ### 페어 프로그래밍 — 관찰
 
 코드를 잘 작성하는 것만큼 중요한 게 있었다. 내 코드에서 **무엇이 문제인지를 스스로 발견하는 것**.
 
 코스 동안 2인이 짝을 지어 페어 프로그래밍을 진행했다. 다만, 일반적인 페어 프로그래밍과는 달랐다. 구현자와 관찰자로 역할을 나눠, 구현자는 평소대로 코딩을 하고 관찰자는 코드가 아닌 사람을 본다. 어디서 막히는지, 어떤 패턴으로 문제에 접근하는지를 관찰하면서 병목을 발견하고 함께 해결 방법을 찾아가는 방식이다.
 
-나의 병목은 '말이 없어짐'이었다. 복잡한 문제를 마주하면 해석하는 시간이 길어졌고, 그 사이 방법만 고민하다 시간을 흘려보내는 패턴이었다. 나를 관찰하던 파트너는 "지금 어떤 문제를 겪고 계세요?", "이 문제를 어떻게 쪼갤 수 있을까요?" 같은 질문을 던졌다. **질문에 답하는 과정이 곧 정적을 부수는 과정이었다**. "지금 ~를 해야 하는데 ~때문에 막혔어요." "가장 단순한 방법부터 해보고 이후에 리팩토링할까요?"와 같이 내 문제를 말로 꺼내면서 병목을 해소할 수 있었다.
+나의 병목은 '말이 없어짐'이었다. 복잡한 문제를 마주하면 해석하는 시간이 길어졌고, 그 사이 방법만 고민하다 시간을 흘려보내는 패턴이었다. 나를 관찰하던 파트너는 "지금 어떤 문제를 겪고 계세요?", "이 문제를 어떻게 쪼갤 수 있을까요?" 같은 질문을 던졌다. **질문에 답하는 과정이 곧 정적을 부수는 과정이었다**. "지금 ~를 해야 하는데 ~때문에 막혔어요." "가장 단순한 방법부터 해보고 이후에 리팩토링할까요?"와 같이 내 문제를 말로 좁히면서 병목을 해소할 수 있었다. 말이 없어진다면 일단 생각을 멈추고, 가설을 세워 문제를 좁히고, 가장 작은 가설부터 세우고 검증해나가는 방법을 관찰을 통해 알게되었다.
 
 ### 일일 점검 — 발견