You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
*`4단계`: 메타 프로그래밍 도입 - 위의 문제를 해결하기 위해 `메타 프로그래밍` 기법을 도입한다.
114
+
#### `4단계`: 메타 프로그래밍 도입
115
+
116
+
* 위의 문제를 해결하기 위해 `메타 프로그래밍` 기법을 도입한다.
109
117
110
118
*`메타 프로그래밍` 이란 코드 자체를 데이터로 보고 **실행 중에 동적으로 변경시킬 수 있도록 하는 기법**을 의미한다.
111
119
@@ -163,26 +171,170 @@ author: devFancy
163
171
164
172
* 주석을 작성하는 곳은 개발자가 작업하는 동안 자연스럽게 볼 수 있는 곳이어야 한다.
165
173
166
-
### 세션 리뷰
174
+
### 세션에 대한 리뷰
175
+
176
+
* 해당 세션은 빠르게 변화하는 서비스 환경에서 **코드의 확장성과 유지보수성을 높이는 설계 전략**을 다룬 점에서 매우 유익했다.
177
+
178
+
* 예전에는 `당근`은 중고거래 서비스를 중심으로 운영되었다면, 이제는 비즈프로필, 알바, 중고차, 부동산 등 다양한 서비스가 추가되면서 복잡한 운영 도메인을 관리해야 하는 상황이 되었다.
179
+
180
+
* 발표에서는 새로운 서비스 코드를 적용하는 과정에서 발생할 수 있는 문제를 구체적으로 설명하고, 이를 해결하는 과정을 **처음 도메인을 접한 사람도 이해할 수 있도록 간단하고 명확하게** 전달해 주셔서 인상 깊었다.
181
+
182
+
* 특히, 새로운 서비스 추가 시 필요한 정보만 가져오도록 설계하고, 이를 코드로 구현하는 과정을 통해 **효율적이고 확장 가능한 시스템을 설계하는 방식**에 대한 인사이트를 얻을 수 있었다.
183
+
184
+
* 데이터를 요청하는 코드를 `Client` 클래스로, 데이터를 가공하는 코드를 `Presenter` 클래스로 분리하여 역할과 책임을 명확히 하는 과정이 인상적이었다.
185
+
186
+
* 또한, 처음 들어본 `메타 프로그래밍`은 실행 중에 동적으로 동작을 변경할 수 있는 기법으로, 복잡한 로직에서 **단순화와 확장성을 모두 잡을 수 있는 가능성**을 보여줘서 신기했다.
187
+
188
+
## 당근알바 초기 엔지니어링 전략: 빠르게, 빠르게, 더 빠르게
189
+
190
+
> 부제목: 빠르게, 빠르게, 더 빠르게
191
+
>
192
+
> 발표자: `Mark` (당근 - 당근알바팀)
193
+
>
194
+
> 새로운 제품이 겪는 Cold Start 문제를 해결하는 과정에서 어떤 엔지니어링을 했는지, 생산성과 사용자에게 전달된 가치 측면에서 소개합니다. 또한 초기 엔지니어링 전략이 팀과 제품에 어떠한 영향을 미쳤는지 공유합니다.
195
+
196
+
### 세션에 대한 메모
197
+
198
+
*`당근알바`란 ?
199
+
200
+
* 동네, 근거리를 핵심 가치로 일손과 일자리가 필요한 이웃을 연결하는 서비스
201
+
202
+
* 초기에 제품을 빠르게 만드는 것이 **초기 사용자에게 더 많은 가치를 전달해주는 것**이라 생각했다.
203
+
204
+
* 이러한 제품에 대해 `빠르게 만들기` 라는 미션을 달성하기 위해 `제품의 생산성`을 고민하게 되었다.
205
+
206
+
#### 빠르게 데이터 분석하기
207
+
208
+
*`데이터 분석`은 **사용자의 피드백**을 가장 빠르게 얻을 수 있는 수단이다.
209
+
210
+
* 가설 -> 실험 -> 검증의 루프를 돌면서 **빠른 의사결정**에 도움을 준다.
211
+
212
+
* 하지만 제품 구현 이외에 데이터 분석에 필요한 추가적인 엔지니링으로 인해 **산성이 저하**되는 문제가 발생했다.
213
+
214
+
* 이러한 문제를 해결하기 위해 두 가지로 나눠서 보기로 했다.
215
+
216
+
*[1] 데이터 분석에 드는 `비용` -> (1) 데이터 분석을 위한 엔지니어링 비용, (2) 데이터 분석 활동에 드는 비용 -> 이러한 비용 문제를 해결하기 위해 **이벤트 기반 분석 서비스**를 활용했다.
217
+
218
+
* 데이터 분석을 위한 별도의 **저장 공간이 필요 없다.**
219
+
220
+
* 원하는 시점에 API를 호출함으로써 **간편하게 데이터를 저장**한다.
221
+
222
+
* SQL이 아닌 웹에서 **직관적으로 데이터를 조합**한다.
223
+
224
+
* 데이터 분석 결과를 **간편하게 시각화**한다.
225
+
226
+
* 데이터 분석 도구: Amplitude, Mixpanel
227
+
228
+
*[2] 데이터 분석으로 부터 얻는 `생산성`
229
+
230
+
* 사용자 피드백을 빠르게 확인하여 가설과 실험에 대한 **의사결정 비용 감소**
231
+
232
+
* 데이터 분석 결과를 통해 사용자에 대한 이해를 바탕으로 팀 구성원 간 **효율적인 의사소통**
233
+
234
+
#### 필요한 것만 구현하기
235
+
236
+
* 실험 목적 달성에 **필요한 만큼**만 구현하고, **실험 결과에 따라** 추가로 구현한다.
237
+
238
+
* 현재 가용 가능한 엔지니어링 리소스를 최대한 효율적으로 활용하기 위해 **현재**에 필요한 기능만 구현한다.
239
+
240
+
#### 효율적으로 에러 대응하기
241
+
242
+
* 에러 대응에 드는 비용을 두 가지라고 생각한다.
243
+
244
+
*[1] 현재 하고 있던 작업에서 에러를 대응하기 위한 **컨텍스트 전환 비용** -> 컨트롤 할 수 있는 영역
245
+
246
+
* 원인 파악 -> 원인 파악 후 수정
167
247
168
-
* 이번 세션은 빠르게 변화하는 서비스 환경에서 **코드의 확장성과 유지보수성을 높이는 설계 전략**을 다룬 점에서 매우 유익했습니다.
248
+
*[2] 에러 대응에 걸리는 시간 -> 컨트롤 할 수 없는 영역
169
249
170
-
*예전에는 `당근`은 중고거래 서비스를 중심으로 운영되었다면, 이제는 비즈프로필, 알바, 중고차, 부동산 등 다양한 서비스가 추가되면서 복잡한 운영 도메인을 관리해야 하는 상황이 되었습니다.
250
+
*에러 대응 프로세스를 다음과 같이 진행한다.
171
251
172
-
* 발표에서는 새로운 서비스 코드를 적용하는 과정에서 발생할 수 있는 문제를 구체적으로 설명하고, 이를 해결하는 과정을 **처음 도메인을 접한 사람도 이해할 수 있도록 간단하고 명확하게** 전달해 주셔서 인상 깊었습니다.
252
+
* (에러 리포트를 받으면) 하고 있던 작업을 멈추고
173
253
174
-
* 특히, 새로운 서비스 추가 시 필요한 정보만 가져오도록 설계하고, 이를 코드로 구현하는 과정을 통해 **효율적이고 확장 가능한 시스템을 설계하는 방식**에 대한 인사이트를 얻을 수 있었습니다.
254
+
* 발생 빈도와 당근알바의 핵심 기능에 미치는 영향을 먼저 확인한다.
175
255
176
-
* 데이터를 요청하는 코드를 `Client` 클래스로, 데이터를 가공하는 코드를 `Presenter` 클래스로 분리하여 역할과 책임을 명확히 하는 과정이 인상적이었습니다. 앞으로 개인 프로젝트에서 이 방식을 적용하며 더 깊이 이해하고, 이를 통해 사고력을 키우고 싶습니다.
256
+
* 발생 빈도가 높지 않거나 핵심 기능에 미치는 영향이 적다면 바로 대응하지 않고 모니터링을 걸어둔 채, 현재 하고 있던 작업을 빠르게 마치도록 한다.
177
257
178
-
* 또한, 처음 들어본 `메타 프로그래밍`은 실행 중에 동적으로 동작을 변경할 수 있는 기법으로, 복잡한 로직에서 **단순화와 확장성을 모두 잡을 수 있는 가능성**을 보여주어 신기했습니다.
* 이 에러 대응 프로세스에서 가장 중요했던 지점은 **이 에러가 어떠한 양상으로 서비스에 영향을 미치는지 파악**하는 것이다.
267
+
268
+
* 그래서 이 부분에 대한 **가시성**을 최대한 많이 확보하기 위해 Sentry, Grafana, Datadog, Apollo Studio 등 모니터링 툴을 활용한다.
269
+
270
+
* 그리고 서비스 로그를 최대한 활용해서 현재 서비스의 상태를 빠르게 파악한다.
271
+
272
+
* 우리에게 중요한 것은 제품의 퀄리티가 아닌, **현재 작업에 집중하는 것**이다.
273
+
274
+
* 제품을 빠르게 만들어서 제품의 가치를 사용자에게 인정 받고 시장에 성공해서 안정적인 궤도로 오르는 것이 중요하다.
275
+
276
+
#### 클라이언트와 효율적으로 협업하기
277
+
278
+
* 서버와 클라이언트는 서로간의 관점 부분에 있어 차이가 있다.
279
+
280
+
*`서버` - 다양한 환경에서 사용될 수 있도록 목적에 맞는 데이터를 반환한다.
281
+
282
+
*`클라이언트` - 네트워크 비용, 사용자 경험 등을 위해 한 번에 관련 데이터를 가져온다.
283
+
284
+
* 이 논의에서 핵심은 응답의 데이터 구조가 **정해져 있다는 것** 이다.
285
+
286
+
* 응답의 데이터 구조가 정해져 있기 때문에, 응답의 데이터 구조를 바꾸기 위해 서버와 클라이언트가 지속적으로 의논한다.
287
+
288
+
* 해결책은 응답의 데이터 구조를 **유연하게 가져가는 것** 이다.
289
+
290
+
* 따라서 제품의 `서버`와 `클라이언트`가 데이터를 유연하게 가져가기 위해 `GraphQL`를 도입했다.
291
+
292
+
*`클라이언트`에게 데이터를 가져오는 것에 대한 **책임**을 맡김으로써 **서버와 클라이언트 간 논의가 불필요**하게 되었고,
293
+
294
+
*`클라이언트`는 더욱 **능동적으로 화면 구성 변경에 대응**할 수 있게 되었다.
295
+
296
+
### 세션에 대한 리뷰
297
+
298
+
* 해당 세션을 들으면서 '효율적으로 에러 대응하기' 부분에서 기존에 내가 하는 작업 방식과는 전혀 다른 접근법을 접하면서 큰 충격을 받았다.
299
+
300
+
* 특히, `Mark` 님이 당근알바팀에서 처음으로 "**가장 중요한 것에 집중하고, 덜 중요한 것은 잠시 미뤄두는**" 경험을 하셨다는 이야기가 인상 깊었다.
301
+
302
+
*`Mark` 님도 처음에는 에러 대응을 바로 하지 않고 우선순위를 설정하는 과정이 낯설고 찜찜했지만, 결과적으로 **제품을 빠르게 개선하며 사용자 만족도를 높이는 데 성공했다는 점**을 말씀하시면서 그 부분이 나에게 많은 깨달음을 줬다.
303
+
304
+
* 나 또한 에러가 발생하면 무조건 우선적으로 해결해야 한다는 강박에 사로잡혀 있었다.
305
+
306
+
* 해당 세션을 들으면서, 현재 하고 있던 작업이 에러를 대응하는 작업, 둘 중 누가 더 사용자에게 더 큰 가치를 전달하는 것인지를 고민하고 그 과정에서 현재의 작업이 더 중요하다면 현재의 작업에 집중하기로 해야겠다고 생각의 전환을 하게 되었다.
307
+
308
+
* 이 세션을 통해, 에러 대응과 현재 작업 중 **어느 쪽이 더 사용자에게 가치를 제공하는지**를 고민하고, 필요하다면 현재 작업에 집중하는 선택이 중요하다는 점을 배웠다.
309
+
310
+
* 또한, `GraphQL` 을 도입해 서버와 클라이언트 간 협업을 효율화한 사례를 보면서, 기술적 관심이 생겼다.
311
+
312
+
* 이 기술을 학습해 현재 회사에서 적용 가능한 상황을 탐색해보고 싶다는 생각이 들었다.
313
+
314
+
## Review
315
+
316
+
* 두 세션만 들었지만, 현재 내 상황에 적합하고 실질적으로 도움이 되는 내용이 많았다.
317
+
318
+
* 이러한 유익한 세션을 `당근` 회사가 유튜브에 무료로 들을 수 있음에 정말 감사했다.
319
+
320
+
* 앞으로 기회가 된다면 실무나 개인 프로젝트에서 이 기술들을 활용해보고, 이를 통해 깊은 이해와 사고력을 키우고 싶다.
321
+
322
+
* 최근에 현 회사에서 깊은 기술적 고민을 한지가 오래되기도 하고, 일에 있어서 큰 재미를 느끼지 못했다. 평일 출퇴근 시간과 주말에 다른 회사에서 발표한 영상을 들으면서 마음 속에 있던 불씨가 조금씩 생기게 되었고, `뭐라도 시도 해보자` 하는 의지와 도전심이 생겼다.
323
+
324
+
* 현재 참여중인 IT 커뮤니티 SIPE 동아리에서 스프링 퍼포먼스 트랙 스터디를 진행하고 있는데, 현재 진행 중인 [주문 API 설계](https://github.com/sipe-team/3-1_spurt/issues/22) 과정에 위의 기술들을 적용해 볼 수 있다면 시도해 봐야 겠다는 생각이 들었다.
325
+
326
+
* 위의 두 가지 세션 이외에도 `SEVER` 파트와 관련된 다양한 세션 내용들이 있지만, 해당 부분들에 대해 관심있는 세션이 있다면 추후에 정리해보려고 한다.
327
+
328
+
* 그리고 `PLATFORM` 파트에서도 개인적으로 눈길이 가는 '비용이 왜 튀었는지 저도 몰라요' 세션과 '온콜, 알림만 보다가 죽겠어요' 세션도 출퇴근 길 or 주말에 보면서 인상 깊은 부분이 있다면 정리해 보려고 한다.
183
329
184
330
## Refernece
185
331
186
-
*[빠르게 변하는 운영 도메인에서 살아남는 코드 만들기 | 2024 당근 테크 밋업](https://www.youtube.com/watch?v=wQIjeVyVU5s&ab_channel=당근테크)
332
+
*[빠르게 변하는 운영 도메인에서 살아남는 코드 만들기, 2024 당근 테크 밋업](https://www.youtube.com/watch?v=wQIjeVyVU5s&ab_channel=당근테크)
333
+
334
+
*[1,800만이 쓰는 서비스 운영하기, 당근 SERVER 밋업 2회](https://www.youtube.com/watch?v=hzWkKb2lAno&ab_channel=당근테크)
335
+
336
+
*[당근알바 초기 엔지니어링 전략: 빠르게, 빠르게, 더 빠르게, 2024 당근 테크 밋업](https://www.youtube.com/watch?v=qRXbPTHJW38&ab_channel=당근테크)
337
+
338
+
*[비용이 왜 튀었는지 저도 몰라요, 2024 당근 테크 밋업](https://www.youtube.com/watch?v=523tajUabV0&ab_channel=당근테크)
187
339
188
-
*[1,800만이 쓰는 서비스 운영하기 | 당근 SERVER 밋업 2회](https://www.youtube.com/watch?v=hzWkKb2lAno&ab_channel=당근테크)
0 commit comments