소통능력과 "자바공장" — 공장이 찍어내는 건 사람이 아니라 '질문 없이 만드는 습관'이다
개발자 커뮤니티에서 “자바공장”이라는 말은 대개 비꼬는 뜻으로 쓰인다. 짧은 과정에서 Java·Spring·JPA 로 게시판 CRUD 를 만드는 법을 배우고, 비슷한 포트폴리오를 들고 같은 시기에 시장에 나오는 개발자들을 가리킨다.
나는 이 말이 반은 맞고 반은 틀렸다고 생각한다. 틀린 쪽부터 말하면, Java 는 죄가 없다. 어떤 언어로 시작했느냐는 몇 년 지나면 아무도 묻지 않는다. 맞는 쪽은 이렇다. 공장식 학습이 정말로 찍어내는 건 특정 언어 개발자가 아니라 하나의 습관이다.
정해진 요구사항을, 질문 없이, 혼자서, 끝까지 구현하는 습관.
과제에서는 이게 미덕이다. 요구사항은 강사가 이미 정리해 줬고, 정답 화면이 있고, 마감까지 혼자 완성하면 점수가 나온다. 그런데 현업에서 이 습관은 정확히 반대로 작동한다.
현업의 요구사항은 항상 덜 정해져 있다
현업에서 처음 받는 요구사항은 이런 식이다.
“회원 탈퇴 기능 추가해 주세요.”
공장식 습관은 바로 DELETE FROM member WHERE id = ? 를 떠올린다. 하지만 이 한 문장 뒤에는 정해지지 않은 결정이 줄줄이 숨어 있다.
- 탈퇴한 회원의 주문 내역은? 정산은? 법적으로 보관해야 하는 기간은?
- 즉시 삭제인가, 유예 기간이 있는가? 재가입하면 같은 계정인가?
- 탈퇴 사유를 받는가? 받으면 누가 그 데이터를 보는가?
이 중 어느 것도 코드를 잘 짠다고 풀리지 않는다. 물어봐야 풀린다. 그리고 묻는 순간 기획자도 “아, 그건 생각 못 했네요”라고 답하는 경우가 많다. 요구사항은 처음부터 완성돼 있는 게 아니라 대화를 하면서 완성된다.
공장에서 배운 “질문 없이 끝까지”는 여기서 가장 비싼 실수가 된다. 2주 동안 혼자 만들고 나서야 처음의 가정이 틀렸다는 걸 아는 것이다.
구조는 결국 대화를 닮는다
1968년 Melvin Conway 는 「How Do Committees Invent?」에서 이렇게 썼다.
“organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.”
시스템을 설계하는 조직은 자기 조직의 소통 구조를 복사한 설계를 만들게 된다는 것이다. 흔히 “콘웨이의 법칙”이라 부른다.
이걸 개인 단위로 내려 보면 이렇다. 소통하지 않는 개발자가 만든 모듈은 다른 모듈과도 소통하지 않는다. 인터페이스가 어색하고, 이름이 팀의 언어와 다르고, 다른 사람이 손대기 어렵다. 코드는 그 사람이 일하는 방식을 그대로 닮는다.
AI 가 코드를 짜 주는 지금, 이 차이는 더 커졌다
CRUD 를 빠르고 정확하게 짜는 능력은 오랫동안 신입의 무기였다. 지금은 AI 코딩 도구가 그 일을 꽤 잘한다. 그러면 남는 건 무엇인가.
내가 하네스 주축으로 쓰는 Ouroboros 의 슬로건이 이 질문에 대한 답이라고 생각한다. “Stop prompting. Start specifying.” 에이전트에게 일을 잘 시키는 핵심은 프롬프트 기교가 아니라, 모호한 요구를 질문으로 쪼개서 명세로 굳히는 일이다(관련 글).
그 일은 결국 사람과의 소통과 같다. 기획자에게 “탈퇴한 회원의 주문 내역은 어떻게 할까요?”를 물을 수 있는 사람이 에이전트에게도 좋은 명세를 준다. AI 시대에 공장식 습관이 더 위험해진 이유가 여기 있다. 질문 없이 만드는 일은 이제 기계가 더 빨리, 더 싸게 한다.
공장을 빠져나오는 다섯 가지 습관
출신 과정이 무엇이든, 아래 습관은 몇 주면 몸에 붙는다.
- 만들기 전에 질문 세 개. 요구사항을 받으면 코드를 열기 전에 “누가, 언제, 예외일 때는?”을 적어서 확인받는다. 답이 다 있으면 그걸로 좋은 일이다.
- 막히면 30분 안에 묻되, 정리해서 묻는다. “안 돼요”가 아니라 “무엇을 하려 했고, 무엇을 해 봤고, 어디서 막혔는지”를 함께 말한다. (묻기 전 5분 글에서 자세히 썼다.)
- 중간에 보여 준다. 완성본이 아니라 30% 짜리를 보여 주고 방향을 확인한다. 틀린 방향의 2주를 2일로 줄이는 가장 싼 방법이다.
- 글로 남긴다. PR 설명, 결정 이유, 버린 대안을 적는다. 말은 사라지고 글은 다음 사람을 돕는다. 6개월 뒤의 나도 그 다음 사람이다.
- 용어를 맞춘다. 기획서에 “회원”, 코드에
User, DB 에member라고 되어 있으면 그 불일치가 버그의 씨앗이 된다. 팀이 부르는 이름으로 코드를 짠다.
정리
“자바공장 출신”이라는 꼬리표는 언어 이야기가 아니다. 질문 없이 만드는 습관에 대한 경고다. 그리고 그 습관은 학원 이름이 아니라 오늘 첫 요구사항을 받았을 때 무엇을 먼저 하느냐로 바뀐다.
코드를 찍어내는 능력은 점점 흔해진다. 무엇을 찍어낼지 함께 정하는 능력은 그렇지 않다.
References
- Melvin E. Conway, How Do Committees Invent?, Datamation, April 1968 — http://www.melconway.com/Home/Committees_Paper.html
- Ouroboros (Q00/ouroboros), “Stop prompting. Start specifying.” — https://github.com/Q00/ouroboros