AI 에이전트 정말 편리하죠.
프롬프트만 던져두고 커피나 마시며 기다리면, 구현부터 테스트까지 끝납니다. 최고예요. 저도 사용합니다.
다만 신입 엔지니어 여러분께 한 가지 전하고 싶은 것이 있습니다.
상사에게 '이거 완전 AI한테 다 맡긴 거 아닌가...'라는 생각을 받고 싶지 않다면, 생성된 코드는 제대로 읽어보세요.
이번에는 리뷰하는 입장이었던 제가 '아, 이거 아마 전부 AI에 맡겼구나'라고 느꼈던 코드 이야기를 해보겠습니다.
※실제 경험을 바탕으로 했지만, 서비스명이나 코드는 외부 공개용으로 일반화했습니다.
결론부터 말하자면, AI에게 맡겨도 좋은 부분은 '구현(implementation)'까지입니다. 하지만 '요구사항의 경계'와 '복구 조건'을 생각하는 것은 인간의 몫이었습니다.
어떤 화면에서 서비스 A와 서비스 B로부터 가져온 데이터를 나란히 표시하고 있었습니다.
그런데 B가 다운되면 A의 데이터까지 표시할 수 없게 되는 상황이 발생했습니다.
이건 곤란하기 때문에 요청 내용은 간단했습니다.
A: 정상 → 평소처럼 표시
B: 장애 중 → B만 '가져올 수 없습니다'라고 표시
요컨대, '한쪽이 다운되어도 데이터를 가져오는 쪽은 보여주고 싶다'는 내용이었습니다.
원래 B에 연결하는 클라이언트는 앱 시작 시점에 만들고 있었습니다.
b_client = ExternalApiClient(settings)
설정 미비 등으로 인해 생성하지 못하면, 앱 자체가 실행 실패했습니다.
그런데 이게 이런 코드로 바뀌어 있었습니다.
try:
b_client = ExternalApiClient(settings)
except Exception:
...
'아하.'
B의 초기화에 실패해도, 앱 자체는 실행되게 만들었습니다.
A 쪽 API는 B를 사용하지 않기 때문에 A의 데이터는 반환할 수 있습니다.
심지어 테스트도 있었습니다.
def test_b_init_failure_does_not_disable_a(monkeypatch):
monkeypatch.setattr(app_module,
테스트가 통과했다는 것은 '그 테스트에 작성된 대로 작동한다'는 의미일 뿐입니다.
테스트에 작성된 사양이 올바른지는 누군가가 생각해야 합니다.
이번이라면, 이렇게 작성하면 상당히 달랐을 것입니다.
앱의 정상 기동 후에 발생하는 A·B로의 HTTP 통신 장애를 분리해 주세요.
한쪽 통신이 실패했을 경우, 실패한 쪽만 에러 표시하고,
성공한 쪽 데이터는 화면에 표시해 주세요.
...
포인트는 'A와 B를 분리'하는 것이 아니라, 다음까지 작성하는 것입니다.
- 언제 발생하는 장애인지
- 무엇은 지속시키고, 무엇을 실패시킬 것인지
- 장애가 복구되면 어떻게 정상화할 것인지
AI는 쓰지 않은 부분을 임의로 빈칸으로 남겨두지 않습니다. 대개, 그럴듯하게 채워 넣습니다.
하지만 이것이 '프롬프트가 나빴네'라는 이야기로 끝나는 것도 아닙니다.
생성된 코드를 제대로 읽고,
`b_client`
이 `None`이 된 후, 언제 복구되는지?
라고 생각해보면 깨달을 수 있었습니다.
AI가 작성한 코드를 전부 손으로 다시 쓸 필요는 없습니다.
하지만 최소한 이 정도는 자신의 말로 설명할 수 없다면 위험합니다.
- 왜 이 `try/except`가 필요한지 - 어떤 예외를 잡고, 어떤 예외는 상위로 던질 것인지
- 장애를 누가 감지하는지
- 어떻게 복구할 것인지
- 이 테스트는 무엇을 올바른 사양으로 삼았는지
이 부분을 설명하지 못한 채 Pull Request를 제출하면, 리뷰하는 쪽에는 비교적 명확하게 전달됩니다.
'아, AI가 만든 코드를 그대로 가져왔구나.'라고요.
AI에게 구현을 맡기는 것은 전혀 좋다고 생각합니다. 오히려 사용하지 않을 이유가 없을 정도로 편리합니다.
하지만, '일임한 코드'를 '일임한 상태 그대로' 리뷰로 넘기는 것은 위험합니다.
이번 코드는 작동했습니다.
테스트도 통과했습니다.
코드 전체의 논리적 흐름도 맞았습니다.
다만, **잘못된 이해 속에서 완벽했던 것**입니다.
상사에게 '이거, AI한테 일임했네…'라는 생각이 들고 싶지 않다면, 최소한 이 세 가지는 해야 합니다.
- 프롬프트에 실패하는 타이밍과 복구 조건까지 작성하기
- 생성된 코드를 읽고 자신의 말로 설명할 수 있도록 하기
- 테스트가 통과했다는 것과 사양이 올바르다는 것을 혼동하지 않기
AI에게 코드 작성을 맡겨도, 생각하는 과정까지 일임해서는 안 됩니다.
결국, 그것뿐인 이야기입니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49