✅ 페어 프로그래밍
🤝 새로운 만남
레벨1에서는 페어가 같은 마을 내부에서만 정해졌는데 그러다보니, 다른 마을의 백엔드 크루와는 교류가 너무 적다는 느낌이 들었다.
다양한 사람들과 친분을 쌓고 싶었기 때문에 이점이 아쉬웠는데,
다행히 레벨2부터는 기존 마을 내부에서 페어가 정해지는게 아니라 백엔드 전체 마을에서 랜덤으로 정해진다.
그렇게 해서 정해진 내 페어는 11층 구리마을의 '시오'였다. (닉네임의 의미는 시오 라멘의 시오라고 한다.) 만나서 이런 저런 이야기를 나눴는데 말도 시원시원하게 너무 잘하고 재밌는 사람이라고 느껴졌다.
또한 별개로 11층 크루들은 데일리 활동을 마을 단위로 해서 서로서로 다 친하다고 하는데 우리 마을은 대부분 조 단위로 이루어지다보니 조끼리만 끈끈한 느낌이 있어서 부럽기도 했다.
👍 순조로웠던 페어 프로그래밍
페어프로그래밍의 시작은 미션을 시작할 베이스코드를 고르는 것이었다. 이번 미션이 이전 미션에서 각자 작성한 코드에서 이어서 하는거라 각자 코드를 보며 어떤 코드로 시작할지 이야기를 나눴는데, 그때 시오가 자신의 코드에 대해서 굉장히 깔끔하게 설명해주었다. 물론 당연히 코드자체도 너무 좋았다.
대표적으로 에러 코드 Enum에 상태코드를 넣지 않는 이유에 대해 물어봤는데, 추후 웹이 아니라 gRPC로 변경되었을 때는 상태코드가 필요없기 때문에 상태코드를 넣게 되면 추후 변경에 약해진다고 설명해주었다.
public enum ErrorCode {
INVALID_RESERVATION_ID("예약 id는 비어 있을 수 없습니다."),
INVALID_RESERVATION_NAME("예약자 이름은 비어 있을 수 없습니다."),
INVALID_RESERVATION_DATE("예약 날짜는 비어 있을 수 없습니다."),
... 생략
}
대신, 다음과 같은 Mapper 클래스로 풀어낸 점이 인상깊었다.
public class ErrorStatusMapper {
public static final Map<ErrorCode, HttpStatus> statusByErrorCode = new EnumMap<>(ErrorCode.class);
static {
statusByErrorCode.put(ErrorCode.INVALID_RESERVATION_ID, HttpStatus.BAD_REQUEST);
statusByErrorCode.put(ErrorCode.INVALID_RESERVATION_NAME, HttpStatus.BAD_REQUEST);
statusByErrorCode.put(ErrorCode.INVALID_RESERVATION_DATE, HttpStatus.BAD_REQUEST);
.. 생략
}
🤖 AI 사용에 대한 생각의 변화
처음에는 나도 OpenAI의 Codex나 Anthropic의 Claude Code 같은 AI 코딩 에이전트에 대해 꽤 회의적인 편이었다.
“직접 코드를 쳐봐야 실력이 느는 거 아닌가?”라는 생각이 강했다.
반면 시오는 AI 코딩 에이전트를 굉장히 적극적으로 활용하는 스타일이었다. 그래서 페어 프로그래밍 초반에는 솔직히 조금 긴가민가했다.
‘이렇게까지 AI에 의존해도 괜찮은 건가?’ 싶은 생각도 있었다.
그런데 같이 미션을 진행하면서 생각이 많이 바뀌었다.
실제로 미션을 하다 보면 반복적으로 작성해야 하는 코드가 정말 많이 나온다. 테스트 코드 세팅이나 비슷한 패턴의 DTO, 단순 매핑 로직 같은 것들 말이다. 이런 작업은 직접 손으로 타이핑한다고 해서 큰 학습이 일어나기보다는, 오히려 시간과 집중력을 꽤 많이 소모한다는 느낌을 받았다.
오히려 AI를 활용해 반복 코드를 빠르게 작성하고, 남은 시간에 설계를 고민하거나 리팩토링을 시도해보는 쪽이 훨씬 생산적이었다.
‘어떻게 구현할까’보다 ‘왜 이렇게 설계할까’를 더 오래 고민할 수 있게 된 느낌이었다.
물론 AI가 작성한 코드를 그대로 믿는 건 위험하다고 생각한다.
결국 중요한 건
- AI가 만든 코드를 검증할 수 있는가
- 그 코드를 이해하고 설명할 수 있는가
- 왜 이런 구조가 나왔는지 판단할 수 있는가
인 것 같다.
그런 점에서 시오는 AI를 굉장히 잘 활용하고 있었다. 단순히 생성된 코드를 가져다 쓰는 게 아니라, 왜 이렇게 구현했는지에 대해 명확한 근거를 가지고 설명해줬기 때문이다.
덕분에 나도 자연스럽게 AI를 “대신 코딩해주는 도구”가 아니라, 생산성을 높여주는 협업 도구처럼 바라보게 되었다.
✅ 조영호님 강연
우테코 8기에서 개인적으로 가장 대단하다고 느끼는 크루는 ‘벨로’이다.
원래도 객체지향이나 Spring Framework에 대한 이해도가 높다고 생각했는데, 같이 지내면서 더 크게 느낀 건 학습 능력보다도 실행력이었다. 이번에는 '오브젝트'의 저자인 '조영호'님을 직접 링크드인으로 연락을 드리면서 강연까지 성사시켰다.(진짜 어케했냐...) 이전 선수타 때, 은사님을 초대하는 것에 대한 이야기가 잠깐 나왔었는데 그때 섭외를 해야겠다고 마음먹었다고 한다.
덕분에 좋은 강연을 들을 수 있어서 고마웠다.

⌛️ 변화와 역사
개발자는 결국 변화에 적응하는 사람이라는 말을 이번 강연에서 정말 많이 느꼈다.
조영호님은 어린 시절 단순히 “게임을 만들어보고 싶다”는 마음 하나로 프로그래밍을 시작했다고 한다. BASIC으로 처음 코드를 접했고, 더 좋은 게임을 만들기 위해 Pascal, C, 어셈블리까지 계속 새로운 기술을 배워나갔다.
인상 깊었던 건, 기술을 공부한 이유가 단순히 “최신 기술이라서”가 아니었다는 점이다.
항상 더 좋은 구조를 만들고, 더 원하는 것을 구현하기 위해 자연스럽게 다음 기술로 넘어갔다.
군대에서는 COBOL과 객체지향을 접했고, 이후 C++을 공부하면서 “기능 구현뿐 아니라 이해하고 수정하기 쉬운 구조가 중요하다”는 걸 깨달았다고 한다. 특히 C로 작성된 복잡한 게임 코드를 보다가, 상속과 다형성으로 구조화된 C++ 코드를 보고 큰 충격을 받았다는 이야기가 기억에 남는다.
이후에도 개발 세계는 계속 변했다.
DOS에서 Windows로, 인터넷과 Java의 등장, 모바일 시대, NoSQL, 클라우드, 그리고 지금의 AI까지.
그런데 조영호님은 그 긴 변화 속에서도 본질은 크게 달라지지 않았다고 말했다.
결국 중요한 건:
- 얼마나 이해하기 쉬운 코드인가
- 얼마나 수정하기 쉬운 구조인가
- 얼마나 안전하게 변경 가능한가
즉, 유지보수라는 것이다.
특히 AI 시대에 대한 이야기도 인상 깊었다.
나 역시 요즘 AI 때문에 개발자의 역할이 많이 바뀌고 있다고 느끼는데, 조영호님은 AI를 “개발자를 대체하는 존재”라기보다 “잘 활용해야 하는 도구”에 가깝게 바라보고 있었다.
코드 작성 비용은 줄어들 수 있지만, 결국 좋은 설계와 구조가 없다면 AI도 제대로 활용하기 어렵다는 말이 특히 공감됐다.
최근 나도 AI 코딩 도구를 사용하면서 비슷한 걸 느끼고 있었기 때문이다. 구조가 잘 잡혀 있는 프로젝트에서는 AI가 굉장히 강력하지만, 구조가 복잡하고 맥락이 꼬여 있으면 오히려 더 엉뚱한 결과를 내놓는 경우가 많았다.
이번 강연을 들으면서 결국 중요한 건 “특정 기술” 자체가 아니라, 변화 속에서도 계속 배우고 적응하는 태도라는 생각이 들었다.
기술은 계속 바뀌지만, 좋은 구조를 고민하고 유지보수를 고려하는 개발자의 역할은 여전히 중요하다는 점이 가장 오래 남았다.

'우테코 8기 > 본과정 회고' 카테고리의 다른 글
| [우테코 8기 - 레벨2] 4주차 회고 (0) | 2026.05.26 |
|---|---|
| [우테코 8기 - 레벨2] 3주차 회고 (0) | 2026.05.18 |
| [우테코 8기 - 레벨2] 1주차 회고 (0) | 2026.05.03 |
| [우테코 8기 - 레벨1] 레벨 1 전체 회고 (0) | 2026.04.20 |
| [우테코 8기 - 레벨1] 7주차 회고 (1) | 2026.04.12 |